Why I Don't Send Proposals to Convince

Most proposals fail before anyone reads them.

Not because the formatting is wrong or the scope is unclear. They fail because the consultant is still selling on paper. The client opens the document, sees three pages of "why you need us," and checks out. They already know they have a problem — that's why they took the call. What they needed was someone to organize what they already said back to them with a path forward.

That's the only job a proposal has.

The Case Was Already Made

Blair Enns wrote something years ago that changed how I think about this: the proposal is not the close. The conversation is the close. By the time a proposal lands in someone's inbox, one of two things is true — either both parties already agree on the problem and the general shape of the solution, or the conversation wasn't finished.

If it's the second one, sending a proposal doesn't fix it. It just delays the inevitable "let me think about it" email.

I don't send proposals to convince. I send them to confirm.

What the Intake Call Actually Does

When I talk to a potential client — whether it's a GC bleeding margin on change orders or a developer sitting on a site with no feasibility model — the first call has one purpose: name the pain with enough specificity that they hear their own situation described back to them.

Not generalities. Not "you probably struggle with operational efficiency." The actual thing. The estimate that lost them a $4M bid last quarter. The superintendent doing invoicing at 9pm instead of running the field. The site they've been holding for fourteen months because nobody built the pro forma.

When you name the real problem, two things happen. First, trust accelerates — because you clearly understand their world. Second, the scope of work becomes obvious to both parties before anyone writes it down.

The proposal just documents what was already agreed upon in conversation.

What This Looks Like on Paper

A client reads one of my proposals and sees their own words reflected back — structured, sequenced, and tied to deliverables. The diagnosis section isn't generic. It names the three or four things we discussed, in order of priority, with the language they used.

The phased scope follows directly from the diagnosis. Phase 1 is always a standalone diagnostic — because I don't prescribe solutions before I've done the work. Phase 2 builds on what Phase 1 reveals. The client can see the logic. There's nothing to "sell" because the structure sells itself.

The investment table is clean. No hidden fees, no ambiguous line items. If they read the diagnosis and the scope and nodded along, the number at the bottom isn't a surprise — it's a confirmation.

Speed Is a Byproduct, Not a Feature

I generate proposals in under five minutes. People hear that and assume the point is speed. It's not.

The point is that when the conversation was good — when the pain was named, the scope was shaped, and the client said "yes, that's exactly it" — the proposal writes itself. There's no staring at a blank page trying to figure out how to frame the value. The value was framed live, in conversation. The proposal is just the written record.

I use AI to handle the assembly — structuring the brief, routing to the right framework based on the client vertical, producing a responsive HTML page the client can open on their phone. The system is fast because the inputs are clean. Clean inputs come from a conversation that did its job.

If the conversation didn't do its job, no amount of AI makes the proposal better. You just get a well-formatted document that still fails to land.

The Real Test

Here's how I know a proposal worked: the client responds within 24 hours, and the response is short. "This looks right. Let's start." Or "One question on the Phase 2 timeline."

They don't ask what the deliverables mean. They don't request a second call to "walk through" the document. They don't forward it to three people for opinions. They read it, recognized their own situation, and moved.

That's not because the proposal was persuasive. It's because the conversation was.

If your proposals need to convince, the problem isn't the document. Go back to the call.