Writing Clearly: Help Evaluators Understand You on the First Read

Junho Cho · · 13 min read

Contrl is built by Cliwant, the company that leads the APMP Korea Chapter.

Read this sentence once: "Optimization of incident escalation procedures will be implemented in coordination with stakeholder groups to ensure enhanced service continuity." Now this one: "Your on-call engineer will reach our specialist within 15 minutes, so outages end sooner." The first takes two reads and still doesn't say who does anything. The second says it in one. That gap is what this episode is about.

Illustration: a tangled knot of gray thread on the left; one thread runs out straight, turns orange and leads into an open document that an evaluator reads with ease
The evaluator should follow one thread, not untangle a knot.

Clear writing means the evaluator understands you on the first read, so their time goes into judging your solution instead of decoding your sentences. The APMP Body of Knowledge treats this as a competitive advantage, not as polish: many bids are lost to vague, dense, over-complicated prose, and a proposal that is easy to see, follow and understand makes "yes" easier to say. Its diagnosis is worth remembering. The root cause of unclear business writing is not grammar or format but style, the way we put words together in sentences and paragraphs.

This series works through the APMP Body of Knowledge as summarized in the APMP Foundation Study Guide. Episode 16 was about persuading: choosing what each sentence is for, so the reader cares and agrees. This one is about being understood. A sentence can be aimed at exactly the right pain and still fail if the reader has to read it twice.

Tell a story the reader can follow

The chapter opens with storytelling, because a story is the easiest structure for a reader to follow and remember. The Study Guide lists six principles. In my words:

PrincipleWhat it asks of you
ConnectShow you understand the customer's present situation and hot buttons, so they feel recognized
Hold attentionWatch the level of detail: neither drowning the reader nor skimming over what matters
Be easy to graspMake the story simple to understand and easy to recall later
Believe itWrite with conviction and a positive tone about what you offer
Show the routeLay out a clear, simple path to the outcomes the customer wants
Show why youMake plain why you are the right guide for that path, which sets you apart

A quick test from the guide is S.T.A.R.: "Something They'll Always Remember." If an evaluator closes your proposal and can't name one thing from it, the story didn't land.

Tell their story, not yours

The most common mistake is a story about your own company. A proposal story puts the customer at the center and fits your offer into it. It has three parts:

  1. Life before: what the customer struggles with today.
  2. The turning point: what the customer needs to do to get past it, described through the features and benefits that answer those struggles (see episode 9).
  3. Life after: what things look like once the struggle is over, told through your value proposition (see episode 4).

Here is a short example written for this article. "Your inspectors re-enter every site report by hand at the end of the day, and corrections take a week to reach the field. With mobile forms that sync on submission, the report is in the system before the inspector leaves the site. A comparable county inspection office cut its correction cycle from five days to one in the first quarter. We expect a similar result for your team, and propose a three-phase rollout starting with the two busiest districts." Before, turning point, after, proof, next step: the reader never has to wonder where they are.

Illustration: a winding path labeled Before, Turning point and After; a worried person at a cluttered desk under a gray cloud, an orange signpost at the bend, and the same person relaxed at a tidy desk under an orange sun
The customer is the hero of the story. Your offer is the turning point.

The guide also names three kinds of story. The big story is the whole case for choosing you over the competition, with every element in place: features, benefits, discriminators, value propositions and visuals. The back story is about your company itself: how it works and how it behaves. Stories within the story are short anecdotes that add context or build a connection, and they are especially useful in pitches. Stories help the customer relate to what you offer quickly, and they connect separate parts of a proposal so it reads as one piece.

Put people in your sentences: active voice

A proposal is an action document. The customer pays for things to get done, so your sentences should show people doing them. The Study Guide's advice is to use human subjects wherever you can and to write mainly in active voice.

In an active sentence, the one acting is the subject, the action is the verb, and what is changed comes after. In a passive sentence, the order flips: the thing acted on becomes the subject, and the actor fades or disappears.

Passive: who does it?

"User acceptance testing will be conducted prior to deployment, and identified defects will be resolved."

Active: people doing things

"Your users test each release before it goes live. Our developers fix every defect they find within two days."

The active version is direct and shorter, and it makes a commitment the evaluator can score. The passive version could be signed by anyone. Active voice is also the voice of good storytelling, which is why the two sections belong together.

Illustration: a sentence drawn as three blocks labeled Who, Does and What, holding a person, an orange action arrow and a gear; below, a faded copy of the row where the person block is an empty dashed outline
An active sentence names who acts. In a passive one, the person slot is often left empty.

Passive voice still has two proper uses:

Write like you talk

Everyone appreciates clarity, including specialists. The Study Guide recommends writing in the register you'd use in conversation, which opens a proposal to the wider group of people who read it.

TipInstead ofWrite
Prefer short, common words when the meaning holdsutilize, facilitate, in order touse, help, to
Avoid jargon unless every reader is a specialist"leverage a best-of-breed stack""use proven tools"
Use personal pronouns"The contractor shall provide the client…""We will give you…"
Use contractions if you want a warmer tonedo not, will notdon't, won't
Vary punctuationOnly full stops and commasA colon to set up a list, a dash for an aside, a question the reader is already asking

Contractions are a matter of tone and of the customer's culture. Some public buyers expect a formal register; others welcome a friendlier one. Decide once per proposal and record it in the style sheet described below.

Write tight

Writing tight means giving readers everything they need in as little space as possible, which is a form of respect for their time. The Study Guide's advice falls into two groups.

Illustration: orange scissors trim a long strip of paper with gray text lines; the cut-off piece falls away and a shorter, neat strip sits to the right
Everything the reader needs, in the least space it takes.

Paragraphs

Sentences and words

ProblemExampleFix
Redundancy (words that repeat each other)"future plans", "end result", "completely eliminate""plans", "result", "eliminate"
Noun stacks (nouns piled in a row)"network outage incident response time improvement program""a program to restore the network faster after an outage"
Inconsistent terms (one thing, several names)"portal", "platform", "system" for the same productPick "portal" and use it everywhere
Negative phrasing"We will not fail to notify you""We will notify you"

Inconsistent terms deserve special attention in proposals. A careful evaluator who sees "portal" in one section and "platform" in the next may reasonably ask whether you are offering two products.

Illustration: a tall, leaning tower of gray boxes beside a person who takes the boxes down and lays them in a neat row on the floor, with one orange box at the front
A noun stack makes the reader rebuild the sentence. Unstack it for them.

Show the structure, briefly

Evaluators look for reasons to drop bidders, so a proposal that is easy to navigate makes choosing you easier. The Study Guide lists five ways to make structure visible: informative headings; numbered and bulleted lists where they help; transitions that end a section by previewing the next and open the next by recalling what the reader already knows; graphics that give content a spatial layout; and a familiar schema, a repeatable pattern so returning readers know where to look. Headings get their own episode next, in episode 18.

Jargon: experts read plain writing faster too

Many contributors believe that because technical specialists evaluate the bid, the proposal should read like a technical manual. Usually that's wrong. Finance, management, quality and executive readers also read some or all of a proposal, and the guide makes a sharp point: anyone reading outside their own expertise is a novice.

The Study Guide also notes that technical readers value clear writing as much as non-specialists. Clear writing doesn't dumb anything down. It says who does what, explains how the technology operates in the reader's own setting, and defines terms that fall outside any reader's field. It also removes four things that hide ideas:

What hides the ideaExamplePlain version
Jargon"zero-touch provisioning""new devices set themselves up when plugged in"
Nominalizations (actions turned into nouns)"performance of a review of the configuration""we review the configuration"
Conceptual shorthand"a cloud-first approach""we move the three billing systems to hosted servers first"
Stacked nouns"user access request approval workflow""the steps to approve a user's access request"

Once these are gone, an idea stands or falls on its merits, and every reader can judge it. When you must use an acronym, spell it out on first use. Not every evaluator has a technical background.

Because proposals lead to contracts, many professionals write them in an impersonal, legalistic style. The Study Guide pushes back: a proposal is first a sales document, and selling happens between people. It is a written argument that asks the buyer to agree with you and to work with you on a problem, as episode 16 describes. Stripping out the sense of people helping people weakens the trust and cooperation that make an argument succeed. "The contractor shall" puts distance between you and the reader; "we will" closes it.

Plan to revise

Clear writing rarely comes out right the first time. Build revision time and cycles into the schedule from day one. Revising early lowers the cost of rework, tests whether your ideas hold up once they're stated plainly, and keeps the content honest.

  1. Agree a style sheet. Large companies usually have a house style; if yours doesn't, start from a published style guide. For each bid, record the team's choices on usage, punctuation, capitalization, and industry acronyms and terms, including the one name you'll use for each product.
  2. Leave a gap between writing and editing. Time away from a draft lets you find errors and test ideas without attachment.
  3. Trade edits with peers. Review a colleague's section and ask them to review yours, looking at substance, grammar and style.
  4. Use functional reviews. Reviewers who aren't working on the bid check drafts for accuracy, persuasiveness and fit, ideally more than once while time allows.
Illustration: two colleagues at a table; one hands a printed draft to the other, who marks it with an orange pen, with a coffee cup and a wall clock between them
A pause, then a second pair of eyes. Both find what the writer can't.

Self-assessment: test your own draft

Writers should also check their own sections against the bid's writing guidelines. The Study Guide's list, summarized as questions:

TestQuestion to ask of your draft
Sentence lengthDo most sentences stay within 12 to 15 words?
No "I"Outside a cover letter, foreword or direct comment, have you kept "I" out?
Left-hand ruleDoes each paragraph start with the client and their need before turning to you?
Client-centricDoes the client's name, or "you", appear more often than your name or "we"?
Answer the questionHave you answered the specific question, completely, and stayed on point?
"So what?"Is the benefit to the client stated, not left for the reader to work out? (See episode 9.)
Stand-alone answersDoes the answer work without sending the reader to an appendix, a brochure or a website?
Active headingsDo headings tell the story when scanned? (More in episode 18.)
Bold statementsHave you cut hedges such as "we believe" unless they protect you from a real commercial risk?
No clichés or jargonAre acronyms rare and spelled out on first use?
Prove itAre differentiators backed by case studies, references or data, without attacking competitors? (See episode 10.)
Picture itWould a graphic make this point faster?

Three misconceptions

  1. "Plain writing looks less expert." The opposite is usually true. Plain writing shows you understand the subject well enough to explain it, and it lets experts check your claims quickly.
  2. "Formal means impersonal." You can be precise and respectful while writing "you" and "we". Formality is about accuracy and courtesy, not about hiding the people involved.
  3. "Passive voice is always wrong." It has two legitimate uses, described above. The aim is a proposal where people do things, not a ban on a grammatical form.

The Study Guide's summary adds two broader points. Know your readers well enough to meet their expectations and their communication and cultural preferences. And look for ways to use newer media, such as video, animation and interactive demonstrations, where the customer will accept them.

Checklist for your next proposal

  1. Write the customer's story in three lines: life before, the turning point, life after.
  2. Check the subject of every sentence. Is it a person or team, and does the verb say what they do?
  3. Swap long words for common ones and remove jargon the least technical evaluator wouldn't know.
  4. Open every paragraph with its point, and keep one topic per paragraph.
  5. Break up noun stacks and nominalizations into verbs with people as subjects.
  6. Pick one term for each thing and record it in the style sheet.
  7. Aim for 12 to 15 words per sentence in most sentences.
  8. Cut hedges, and make every answer complete without references elsewhere.
  9. Schedule a break, a peer edit and a functional review before the final version.

Where Contrl fits

Contrl writes each section's slides in your company's design system, and the clarity standards in this episode are things you can check directly on those pages: whether each sentence has a person or team as its subject, and whether most sentences stay short. When a page fails the test, you don't have to rewrite it sentence by sentence. One line of chat feedback, such as "say who does each step and keep sentences under 15 words", rewrites the page, which still cites the RFP requirements it answers. The standard is yours to set, and the same line can name the terms from your style sheet so the page uses them.

Sentence-length profile of one page before and after one line of chat feedback. Before: four sentences averaging 34 words, with subjects such as Implementation and Monitoring. After: nine sentences averaging 11 words, all under the 15-word line, each with a person or team as subject
Same page, same content. Shorter sentences, and people doing the work.

Next in the series

A clear page still has to be found and scanned before it is read. Episode 18 covers Headings: how informative, active headings tell the story to an evaluator who is only skimming.

This article is an independent study companion based on the APMP Foundation Study Guide, version 4.2 (© 2025 APMP), which summarizes the APMP Body of Knowledge. It paraphrases and comments on that material and is not endorsed by APMP. The opening sentence pair, the inspection-office story, the active and passive examples and all the tables of examples (plain words, redundancies, noun stacks, jargon and their fixes) were written for this article, and their figures are illustrative; no customer is named. For the authoritative text and certification information, see apmp.org.

FAQ

What is clear writing in a proposal?
Clear writing makes its points simply, so evaluators understand them on the first read and spend their time judging the solution rather than working out what a sentence means. In the APMP Body of Knowledge, unclear writing is mainly a problem of style, meaning how words are combined at the sentence and paragraph level, not of grammar or format. In practice it means active sentences with human subjects, common words, short sentences and paragraphs, one term per concept and the main point first.
Should proposals be written in active or passive voice?
Mostly active, with a human subject. A proposal promises action, and an active sentence names who acts, what they do and what changes as a result: "Our engineers test every release with your users" rather than "Releases are tested." Passive voice is still the better choice in two cases: when the reader doesn't need to know who performs the action, and when it is the only way to keep the same subject running through a paragraph.
How long should sentences be in a proposal?
The APMP Foundation Study Guide suggests a maximum of about 12 to 15 words per sentence as a self-assessment target. Treat it as a ceiling for most sentences rather than a rule for every one: a page of short, active sentences is easier to scan and score than a page of long, layered ones.
Doesn't plain language make a technical proposal look less expert?
No. Proposals are read by financial, managerial, quality and executive readers as well as technical experts, and anyone outside their own specialty reads as a novice. The Study Guide notes that technical readers value clear writing as much as non-specialists, because plain writing states who does what, shows how the technology works in the workplace and defines terms. It removes jargon, hidden actions and stacked nouns so ideas are judged on their merits.
How do you build revision into a proposal schedule?
Plan revision time and review cycles from the start. Agree a style sheet for usage, punctuation, capitalization and acronyms; leave a gap between writing and editing so you return to the draft with fresh eyes; trade edits with peers; and use functional reviews by people not working on the proposal. Writers can also check their own drafts against simple tests such as sentence length, client-first paragraphs, the "so what?" test and complete, stand-alone answers.

You make the call. AI writes the proposal.

Upload an RFP and Contrl works through it with you, from analysis and strategy to the slides. Your first proposal is free.

Get started free →