How to Dictate Sales Proposals in One Sitting

Short answer: Dictate a sales proposal by speaking the prose sections and typing the numbers. Record or dictate the problem restatement right after the discovery call, then narrate the approach, scope, and exclusions. Speech runs 130-150 words per minute against roughly 40 typed, so the draft takes minutes.

Here is a gap that anyone who has ever sent a proposal will recognise.

You get off the discovery call. If a colleague stopped you in the corridor right then and asked what the deal was, you could explain it in about four minutes. What the customer is actually trying to fix. Why they are trying to fix it this quarter rather than next year. What you would do first. Where you think the risk is. What you would deliberately leave out of a first phase.

Then you sit down to write the proposal, and it takes the rest of the afternoon.

The usual explanation for that gap is discipline. You should have blocked time. You should have a better template. The real explanation is arithmetic.

The proposal problem is an input cost

Run the numbers with well-established ranges rather than anything invented.

An average adult types at around 40 words per minute. A proficient office typist runs 80 to 100. Ordinary speech runs 130 to 150 words per minute, and has done since you were a child.

A modest proposal is perhaps 1,200 words of actual prose, setting aside the boilerplate and the pricing table. At 40 words per minute that is roughly 30 minutes of pure keystrokes, before a single moment of thinking, revising, or staring at the screen. Spoken, the same 1,200 words take somewhere around nine minutes.

That is the whole story. You are not slow at proposals. You are converting something you can say in minutes into a medium that costs half an hour of mechanical effort to produce, and doing it at the end of a day already full of calls.

Why expensive prose makes worse proposals

This matters more than it first appears, because the cost does not distribute evenly. It gets rationed.

When writing is expensive, you do not write a shorter version of the good proposal. You write the sections that feel obligatory and skip the sections that feel optional. And the sections that feel optional are, almost without exception, the ones that win deals:

• The restatement of the customer's problem in their own words. The single most persuasive paragraph in most proposals, and the first thing cut, because reproducing someone's exact framing from memory is slow to type.
• The why-now. A proposal that explains what you would do is a quote. A proposal that explains why this is worth doing this quarter is an argument.
• What is out of scope. The cheapest insurance in professional services, and the section people skip most often, because writing out everything you are not doing feels like effort spent on nothing.
• Assumptions and dependencies. Three sentences that prevent a six-week dispute.

What gets sent instead is the previous proposal with the client name swapped. Everyone in sales has done it. Nobody does it because they think it works better. They do it because at 6pm on a Thursday it is the only version that exists.

Change the input cost and the rationing stops. That is the actual argument for dictating proposals, and it is a bigger one than speed.

Which parts of a proposal are actually prose

Take a normal proposal apart and count.

• Executive summary. Prose.
• Problem restatement. Prose, and the most valuable prose in the document.
• Proposed approach. Prose.
• Scope and deliverables. Mostly prose, with some structure.
• Out of scope. Prose.
• Timeline and milestones. Mixed. The phases are prose, the dates are values.
• Pricing. Values, plus one or two sentences of prose sitting next to them.
• Assumptions and dependencies. Prose.
• Team and relevant experience. Prose.
• Terms and legal. Neither. This is a lawyer's text, reused verbatim.
• Next steps. Prose.

Eight of those eleven sections are sentences you would happily say out loud to a colleague. One is copied. Only two are genuinely made of values. That ratio is the opportunity, and it is roughly the same ratio we found when looking at dictating product requirements documents, which is a different artifact with an identical structural problem.

The one rule: speak the prose, type the values

Before any workflow advice, this rule, because in a priced document it is not optional.

A misheard word in a sentence is visible. You read it back, it looks wrong, you fix it. A misheard number is invisible. If you say fourteen thousand five hundred and the document receives forty thousand five hundred, nothing about that looks wrong. It is a number, formatted like a number, sitting where a number belongs. It survives the proofread, it goes out under your name, and it is a commitment.

The same applies to payment terms, effective dates, headcount, hours, percentages, and discount figures. Net 30 arriving as net 13 reads as perfectly ordinary.

So the rule:

• Speak every paragraph, every explanation, every bit of reasoning, every section that a human being reads rather than checks.
• Type every figure, rate, date, term, and legal reference. Then read the pricing section once more, out loud, against the source.

This costs you almost nothing, because the values are a small fraction of the document and they were never the slow part.

The change that matters most is timing, not tooling

Most people, if they adopt dictation for proposals at all, use it the same way they used typing. They sit down on Thursday afternoon, open the template, and start dictating from a cold start.

That is better than typing, and it misses most of the benefit.

The real change is when you capture, not how fast you produce. The best version of the problem restatement exists in your head for about ten minutes after the discovery call ends, and then it degrades into notes. By Thursday you are not writing, you are doing archaeology on your own calendar and sent folder, trying to reconstruct what the customer said.

So do this instead: in the ten minutes after the call, before the next one starts, speak the problem restatement. Not polished. Not structured. Just say what they told you, in the words they used, with the emphasis they gave it.

Two things happen. First, Thursday becomes an editing job instead of a writing job, and editing is dramatically faster than generating. Second, and more importantly, you preserve their actual phrasing. When a buyer reads their own words back in a proposal, it lands differently from your paraphrase of their words. That fidelity is what decays fastest and it is exactly what a ten-minute capture protects.

Capturing the call itself

Meeting Mode on the Mac takes this further. It detects speakers, captures the conversation, and produces AI notes, and it can pick up meetings from your calendar automatically. For a discovery call, that means the customer's own framing of their problem is preserved rather than remembered.

Two boundaries we would insist on. Say out loud that you are capturing the call, at the start, every time. Consent rules vary by jurisdiction and the professional norm is stricter than the legal minimum anyway. And treat the output as raw material, never as a deliverable. Meeting notes are input to a proposal. They are not a proposal, and a customer can tell the difference instantly.

Section by section

Write the executive summary last

It is the first thing read and it should be the last thing written, because until the rest of the document exists you do not actually know what you are summarising. Dictate it after everything else, in one continuous pass, as though you were telling the buyer's boss what this is in thirty seconds. If it takes you more than thirty seconds to say, the proposal is not clear yet and the summary is not the problem.

Say the problem back the way you would say it to them

The test for this section is simple. Imagine the buyer is on the call and you are saying it directly to them. Would they nod, or would they correct you?

Dictation is unusually good here precisely because speaking is the natural register for this. Typed problem statements drift into abstraction almost automatically, because abstract sentences are shorter to type than concrete ones. Spoken, you tend to say the concrete thing.

Narrate the first thirty days

For the approach section, do not describe your methodology. Describe what happens. What you do in week one, who you talk to, what exists at the end of the first month that does not exist today.

Narration is very hard to fake, which is the point. If you cannot narrate the first thirty days out loud, you do not yet know how you would run the engagement, and it is much better to discover that now than in a kickoff meeting.

Out of scope is a list of temptations declined

The most efficient framing we know: this section is not a list of things you cannot do. It is a list of reasonable things a buyer might assume are included, that are not.

Speak them as full sentences with the reason attached. "We are not migrating historical data in this phase, because the cleanup effort is not knowable until we see the source system, and we would rather scope that separately than guess at it now." That sentence takes eleven seconds to say and about ninety seconds to type, which is precisely why it usually does not get written.

Pricing needs one sentence, not a table alone

Type the numbers. Then dictate the sentence that goes next to them, the one explaining what drives the figure and what would change it. A price with no reasoning attached invites negotiation on the number. A price with reasoning attached invites negotiation on the scope, which is a conversation you can actually win.

Assumptions, in the voice of someone who has been burned

Speak these as conditionals, because conditionals are cheap to say and expensive to type. "This assumes we get access to a test environment in week one. If that slips, the timeline slips with it." That is the entire section, three or four sentences long, and it is the single highest-return-per-word part of the document.

Two passes, and the second one is mostly deleting

Do not try to dictate a finished proposal. Run two passes.

Capture pass. Speak everything, in whatever order it comes. Overshoot. Say the thing twice if you are not sure which way is better. The output will be messy and it will be complete, and complete is the harder of the two properties to achieve.

Shape pass. Cut, reorder, tighten. Choose between the two versions of the sentence you said twice.

The reason this works is that it converts a generation problem into a cutting problem. Staring at a blank section is slow and unpleasant. Deleting a redundant sentence is fast and mildly satisfying. Most of the pain in proposal writing lives in the first mode, and the capture pass gets you out of it in minutes.

A side effect worth naming: proposals that sound like a person

Typed proposals drift toward a particular register. Passive constructions, nominalisations, "leveraging" and "utilising", sentences with no human being in them. This is not because salespeople like writing that way. It is a typing artifact: the stiff version is shorter and more formulaic, so it is cheaper to produce.

Dictate the same content and it comes out in your speaking voice, which is the voice the buyer already knows from the call. The document sounds like the person they talked to. That continuity is worth more than any amount of polish, and you get it for free by changing the input method.

You will need to tidy the result. Speech has filler and false starts. But tidying a human sentence is a much better starting point than trying to inject humanity into a corporate one.

Where the hours actually go

Fixating on the proposal document misses most of the writing in a sales cycle. Look at a normal week and count the prose:

• Follow-up emails after every call, which are the single largest volume of writing in most sales roles.
• Recap notes sent to the buyer confirming what was agreed.
• CRM notes, which is where the honest detail either gets recorded or lost. Our guide to dictating in Salesforce covers the field-by-field mechanics, and the pattern generalises to any CRM.
• Internal deal reviews and forecast commentary.
• Objection responses, which are frequently better written than anything in the proposal, because you write them while genuinely engaged with the question.
• The statement of work, which is the proposal again with more precision.
• Explaining a redline back to your own team.

Every one of those is prose. Several of them are things you would say better than you write, particularly the objection responses. There is a specific pattern worth noticing here: the detailed answer you give a prospect in an email is often a better piece of writing than the corresponding section of your proposal, because you wrote it in response to a real question from a real person. Capture those. They are proposal sections that already exist. The broader case for voice in this role is covered in voice to text for salespeople.

Tool traps in proposal software and documents

Wherever you are actually writing, a few mechanical things catch people out.

• Selection is not insertion. Clicking a block, a card, or a table cell often selects it without giving you a caret. Dictation needs an insertion point. Before you speak, press one character and confirm it appears.
• Return submits. In many proposal tools, comment boxes, and CRM fields, Return commits the field rather than starting a new line. One dictated paragraph becomes three separate saved entries. Dictate one field as one continuous utterance, then commit deliberately.
• Auto-formatting fires on leading characters. A sentence starting with a dash, a number and a full stop, or a hash can convert into a list or a heading. Auto-numbering also loves to double up when a dictated "one" meets an already-numbered list.
• Slash and at-sign menus. In block editors, a dictated slash or "at" can open a command menu that then swallows the rest of your sentence.
• Single-key shortcuts. Web applications bind bare letters to actions when no field is focused. Put your dictation trigger on a key nothing competes for. F13 through F19 is the standard answer on a Mac.

Keeping names right

Proposals are full of proper nouns that general transcription has no reason to know: the buyer's company, their product names, your own SKUs, the acronyms specific to their industry.

Smart Vocabulary in Voice Keyboard Pro is a personal dictionary with replacement rules, so a correction you make once applies from then on. The way to build it that actually works is not to sit down and brainstorm. Work normally for two days, notice which corrections you keep making by hand, and add those. Fifteen real entries earn their keep. A hundred guessed ones do not.

Getting the buyer's company name spelled correctly and identically throughout is a small thing that is very noticeable when it is wrong. One caveat: keep entries to things you would actually say out loud. Mixed-case product codes and identifiers belong in the type-the-values half of the rule.

On the phone, between meetings

The ten-minutes-after-the-call capture rarely happens at a desk. It happens in a car park, a lobby, or the gap between two meetings in someone else's office.

Voice Keyboard Pro on iPhone is a keyboard with a microphone button built in, so you can dictate into whatever app you already use for notes without switching to a separate recorder. Voice Edit is genuinely useful here: instead of tapping to place a cursor and fixing a word by hand on a small screen, you speak the change you want and the text updates.

For international deals, two-way translation while dictating covers 24 languages, which is helpful for a first draft or for reading a buyer's note back in your own language. One firm caveat, and we mean it: never send a machine-translated priced document without a fluent human reviewing it. People sign what is in front of them. A translation error in a scope or payment clause is not a typo, it is a commercial commitment.

Honest limits

• Dictation does not decide your pricing, your scope, or your strategy. It removes the cost of writing down what you have already decided.
• It does not structure the document. You still need a template and an argument.
• Do not dictate legal terms. Contract language is reused verbatim for good reasons and a reworded clause is a liability, not an improvement.
• It types text. It does not drive your CRM or proposal tool, and that is deliberate.
• Voice Keyboard Pro's transcription engine needs a network connection.
• Dictation is audible. Customer names, pricing, and deal detail are not things to say out loud in a shared office or a train carriage. That is a room problem, not a software problem.
• On privacy: the server stores only operational pings. No audio and no transcript content is retained. If you handle confidential client information, read the privacy policy yourself rather than taking our word for it.

A realistic first week

Do not try to change everything at once.

• Day one. Set the trigger key to something nothing competes for and dictate your follow-up emails only. Nothing else. Get comfortable.
• Day two. Start the ten-minute capture after every call. Just the problem restatement, in their words. Do not write a proposal yet.
• Day three. Add the corrections you have been making by hand to Smart Vocabulary.
• Day four. Take one real proposal and dictate the approach, out-of-scope, and assumptions sections. Type the pricing. Notice how long it took.
• Day five. Do a full proposal in two passes.

The test at the end of the week is not a stopwatch. Put the proposal you sent on Friday next to one you sent a month ago and compare two things: whether the out-of-scope and assumptions sections exist, and whether the problem statement sounds like the customer or like you. Those are the sections that get rationed away when writing is expensive, and they are the honest measure of whether this changed anything.

Frequently asked questions

Will a dictated proposal sound unprofessional?

Only if you send the capture pass. Dictated prose needs a shape pass, same as any first draft. What you get after that edit usually reads better than a typed equivalent, because it is in the same voice the buyer heard on the call.

Should I dictate the pricing section?

Dictate the sentence that explains the price. Type the price. A misheard figure in a proposal looks exactly like a correct one and becomes a commitment.

What about the statement of work?

Same method, higher stakes. Speak the descriptive sections, type every date, rate, and quantity, and get a second reader on anything that defines an obligation. An SOW is read literally by people who were not in the room.

Does this replace proposal templates or automation software?

No, and it is not trying to. Templates handle structure and boilerplate. Automation handles assembly. Neither of them writes the four paragraphs that are specific to this customer, which is the part that takes the time and the part that decides the outcome. That is the gap this fills. For a related artifact with a similar structure, see dictating grant proposals.

Is it faster to just reuse the last proposal?

To send, yes. To win, no. Reuse exists because writing is expensive, not because it works. Once the four customer-specific paragraphs cost you nine minutes of speaking instead of half an hour of typing, the reason to send a swapped-name document mostly disappears.