The right to quote is earned, not assumed

The most expensive scoping mistake is not underpricing. It is quoting before the investigation has earned the right to send a quote. In one recorded case, a proposal was revised until it covered one hundred percent of the customer's stated list, and it was still rejected on the day it arrived or the next, with no reason given. The plan had been five months. The project never started. Proposal coverage was not the missing ingredient.

Four translations

A customer describes a problem in the language of how it feels. A quote has to be written in the language of what gets measured. Four translations do most of that work:

• Efficiency becomes median time. Not "faster", not an average dragged upward by a few good days. The median of the specific step the customer complains about.
• Cost becomes money. Not a percentage saved, not "significant". An amount in the customer's currency, computed from the customer's own records.
• Satisfaction becomes observable behaviour. Not a score on a form filled in at the review. What people do: which step they skip, which channel they still use in parallel, whether they ask for the old tool back.
• Revenue becomes a baseline comparison. Measured against the customer's own prior period, not against an industry average that neither side can verify.

Each translation has one test: can the customer's own data produce this number before the project starts? If not, the number is a promise about the future wearing a metric's clothes.

Four blocks of a quote

Every quote carries four blocks: the goal, the deliverables, the price and payment, and what is out of scope. The fourth block is not a footnote. A quote without an explicit out-of-scope section is a quote whose scope will be decided later, by whoever asks last.

A defensive clause belongs inside the quote rather than in a side letter. Payment is tied to milestones, never to person-days; charging by the day is a named failure mode because it prices the FDE's time instead of the customer's outcome. One recorded contract used a non-refundable first payment followed by 20, 25, 25, 20 and 10 percent against requirement confirmation, two preliminary acceptances, final acceptance and a warranty retention. That split is an example, not a template; the principle is that each payment should follow a verifiable event.

Investigation and eligibility are different permissions

The investigation answers one question: what does the customer need. Eligibility answers another: on what basis will this customer pay for what. The second question is a self-check with four parts — how the customer is willing to pay, why they would pay, what they refuse to pay for, and whether the overlap between what they will pay for and what can be delivered is non-empty.

The rejected proposal failed on the last two. It was a complete answer to "what do you need" and a poor answer to "what will you pay for". A different recorded case shows the correction in action: a first business interview overturned the assumption that the customer wanted a platform, and the quote that survived was a narrower custom engagement with an explicitly reduced first payment, defensive pricing for ongoing compute and remote support, and a written list of what would not be promised.

The order matters: interview, boundary, cooperation structure, then a delivery that can be judged in four weeks. Reversing it produces a proposal that is technically correct and commercially dead.

What is not in the annex is not an obligation

A contract is not the contract. The annex is. The sentence to include is blunt: functions, performance characteristics or pages not recorded in the annexes are not delivery obligations. Five properties make an annex usable:

1. Granularity down to page, threshold and operation path.
2. The exclusion sentence above, in the body text.
3. Responsibility split specific enough to cover compliance and operations.
4. The external dependency list cleared before signing.
5. The fallback written into the contract or the annex, not the todo list.

A complete demo does not close the definition stage; the annex does. One contract put an eight-module mock demo into the annex unchanged as the acceptance baseline, which is the strongest version of that move. The weaker version, where a polished demo is shown and the annex stays vague, converts a demonstration into an unpriced obligation.

When price tracks the outcome

Outcome-based pricing runs along four rungs: per usage, per task, per result, per share of value. Each rung moves the billing unit closer to something the customer already cares about, and each makes attribution harder. The four-rung ladder is only as good as the clause underneath it, which needs five parts: the metric definition, the baseline and measurement window, the judge and data source, the dispute arbiter and an abortion clause. The last one is the most often omitted and the most damaging when a result never arrives.

None of this is separate from the metric table; the pricing clause and the acceptance test should be the same sentence read twice. Nor is it separate from the prototype, which is how a four-week judgeable delivery gets demonstrated before the full build. A quote that cannot point at both is a proposal, not an offer.