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.

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:
| Principle | What it asks of you |
|---|---|
| Connect | Show you understand the customer's present situation and hot buttons, so they feel recognized |
| Hold attention | Watch the level of detail: neither drowning the reader nor skimming over what matters |
| Be easy to grasp | Make the story simple to understand and easy to recall later |
| Believe it | Write with conviction and a positive tone about what you offer |
| Show the route | Lay out a clear, simple path to the outcomes the customer wants |
| Show why you | Make 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:
- Life before: what the customer struggles with today.
- 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).
- 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.

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.

Passive voice still has two proper uses:
- When the reader doesn't need to know who acts: "The data is encrypted at rest."
- When it is the only way to keep a paragraph's sentences on the same subject. If a paragraph is about the backup system, "The backup system is checked every night" can keep the focus where it belongs.
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.
| Tip | Instead of | Write |
|---|---|---|
| Prefer short, common words when the meaning holds | utilize, facilitate, in order to | use, 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 tone | do not, will not | don't, won't |
| Vary punctuation | Only full stops and commas | A 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.

Paragraphs
- Lead with the idea and make everything after it relate to it.
- Give each paragraph one topic and state it in the first sentence.
- Keep paragraphs short; it keeps the tone conversational.
- Connect the sentences so each one builds on the last and the paragraph reads as one line of thought.
Sentences and words
| Problem | Example | Fix |
|---|---|---|
| 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 product | Pick "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.

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 idea | Example | Plain 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.
A proposal is an argument, not a legal document
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.
- 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.
- Leave a gap between writing and editing. Time away from a draft lets you find errors and test ideas without attachment.
- Trade edits with peers. Review a colleague's section and ask them to review yours, looking at substance, grammar and style.
- 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.

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:
| Test | Question to ask of your draft |
|---|---|
| Sentence length | Do 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 rule | Does each paragraph start with the client and their need before turning to you? |
| Client-centric | Does the client's name, or "you", appear more often than your name or "we"? |
| Answer the question | Have 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 answers | Does the answer work without sending the reader to an appendix, a brochure or a website? |
| Active headings | Do headings tell the story when scanned? (More in episode 18.) |
| Bold statements | Have you cut hedges such as "we believe" unless they protect you from a real commercial risk? |
| No clichés or jargon | Are acronyms rare and spelled out on first use? |
| Prove it | Are differentiators backed by case studies, references or data, without attacking competitors? (See episode 10.) |
| Picture it | Would a graphic make this point faster? |
Three misconceptions
- "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.
- "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.
- "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
- Write the customer's story in three lines: life before, the turning point, life after.
- Check the subject of every sentence. Is it a person or team, and does the verb say what they do?
- Swap long words for common ones and remove jargon the least technical evaluator wouldn't know.
- Open every paragraph with its point, and keep one topic per paragraph.
- Break up noun stacks and nominalizations into verbs with people as subjects.
- Pick one term for each thing and record it in the style sheet.
- Aim for 12 to 15 words per sentence in most sentences.
- Cut hedges, and make every answer complete without references elsewhere.
- 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.
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.