I’ve seen proposals where the pricing section is literally one number at the bottom of a Word doc. And then the agency wonders why the client “went silent.”
Here’s the thing: a single number gives the client exactly two options — accept or reject. And a client presented with those two options invariably picks a third: “I’ll think about it.” Which is just a polite version of “I’m not sure what to do with this number, so I’m going to do nothing.”
Pricing isn’t a number. It’s a decision structure. And most agencies treat it like accounting homework.
The Four Problems (in One)
Everything that goes wrong with proposal pricing traces back to four things:
One number, zero context
When a proposal shows a single price, the client has nothing to compare it to. They don’t know if it’s high or low — only that it’s more or less than what they vaguely expected. In both cases, the answer is “I’ll think about it.”
Worse: if the client pushes back on a single price, your only move is “we’ll reduce it.” Which immediately signals you were padding it. Now instead of negotiating scope, you’re negotiating your rates. That’s a losing game.
Default pricing model
Most agencies default to one model — always fixed price or always T&M. Fixed price scares no one on the client side, but it puts all the estimation risk on you. One poorly scoped module and your margin vaporizes. T&M protects your margin, but it spooks clients who want a predictable total.
The problem isn’t either model. It’s picking one without thinking about whether it fits the project. Clients don’t buy a pricing model — they buy certainty and control. If you’re offering the wrong one, they feel it.
The magic number problem
The scope section describes modules and features in detail. Then the pricing section says “total cost: $180,000.” Nothing connects them. The client can’t defend that number to their board or compare it against other proposals. They don’t know if $180K is justified or pulled from the air.
When price doesn’t flow from the estimate — scope x roles x rates x time — you have two problems: you can’t justify it, and you can’t verify it’s even right. A ballpark estimate is a lottery where the prize is your margin.
Excel hell
Every proposal built from scratch in Excel means hours of typing, inevitable typos, forgotten items (QA, DevOps, documentation — the overhead that nobody bills for but always costs). And the result is a price that probably doesn’t match your actual costs. Want to test a different pricing structure? That’s another half day of manual work. So you don’t bother.
What Actually Works
Give them a choice (Good / Better / Best)
One price gives the client one question: “yes or no?” Three prices give them a different question: “which one?”
Good = core MVP. Better = recommended. Best = full scope. The middle option does the heavy lifting — it looks reasonable next to the premium one, and the basic one makes the client feel in control. This isn’t theory. Agencies using tiered pricing close more often and at higher average values.
Critical rule: the variants must differ in scope, not discount. Selling the same work at three different prices isn’t tiered pricing — it’s negotiating against yourself with extra steps.
Match the model to the uncertainty
Instead of thinking “what do we always use?”, ask “how much uncertainty is in this project, and what does this particular client need?”
- Fixed price — scope is clear, you’ve done this kind of project before, you have data. The client gets certainty; you build in a risk buffer and live with it.
- T&M — requirements will evolve, it’s a long engagement. The client gets flexibility; you give them control (weekly budget reports, clear boundaries).
- Hybrid — fixed budget, variable scope. When uncertainty is high but the client needs a single number for the contract. Best of both worlds, hardest to execute well.
Drop one sentence into the proposal explaining why you chose the model. “We’re going fixed price here because the scope is well-defined and you need a firm number.” That single sentence does more than a page of reassurance. If a client understands the logic, they won’t feel cheated when a scope change shows up.
Show where the number came from
You don’t have to expose your hourly rates. But show the structure: “module A: 3 weeks, module B: 5 weeks, QA: 15% of time, PM: 10%.” Two things happen. First, the price becomes defensible — when the client asks “why so much?” you point to the breakdown. Second, you catch mistakes: if the total hours don’t match the scope, you see it before the client does.
Use anchoring and packaging
People don’t evaluate prices in a vacuum. They compare against the first number they see. Use this:
- Show the premium option first. That number sets the anchor. Everything after looks reasonable by comparison.
- Package work as outcomes, not hours. “API integration including testing: $6,000” beats “5 hours of API integration: $2,000.” The client buys results, not time. And you negotiate scope, not rates.
- State assumptions next to each item. “Assumes: API documentation provided by client. Excludes: data migration.” This kills scope disputes before they start.
Stop building from scratch
If every proposal is handmade in Excel, you’ll never develop a pricing strategy — because you have no data on what works. Automation doesn’t mean templates. It means:
- A component library from your own projects (how long did that integration, dashboard, or report actually take?)
- Standard rates per role, adjustable per project
- Good/Better/Best variants generated from one estimate, not rewritten by hand
- A sanity check that catches missing items before the proposal goes out
Once you have that, you can experiment. Change the tier structure, the anchor, the packaging — and see in the data what actually closes deals. Without automation, every experiment costs you half a day.
About Apropo
We built Apropo to connect estimation directly to proposal pricing. Upload the brief, the tool builds scope with modules and tasks, and the price comes out the other end. Good/Better/Best variants are generated from the same estimate without rewriting. The component library draws on your actual project history — your integrations, your dashboards, your reports — so pricing is based on what you’ve actually done, not what someone guessed. The sanity check catches the forgotten QA and documentation before the client sees a number you can’t defend.
I started the company because I got tired of watching agencies lose margin on the same things: heroic Excel, disconnected estimates, and pricing that had no relationship to actual costs. The only fix is making the connection automatic and transparent.
An agency that treats pricing as a decision structure doesn’t negotiate rates. It negotiates scope. And that’s the difference between a proposal that lands in the trash and one that closes.