The objects the system is built from
Four objects, and naming them separately is most of the design. The rate card: what your time and your named deliverables cost, decided from your economics rather than from a buyer's face. The engagement shapes: three to five defined packages of work, each with a scope boundary, a price or price range, and a written statement of who it is wrong for. The estimate: an internal record of what a specific piece of work will take. The proposal: the client-facing artifact that communicates a selected shape.
Most businesses have only the fourth, which is why the other three get invented inside it every time. The proposal becomes the only place any of these decisions is ever made, and it makes them under time pressure at night.
The shapes are the highest-leverage object and the one founders resist, usually with the objection that every engagement is different. Test it: take the last twenty engagements and sort them. In most service businesses, sixteen collapse into three shapes and four are genuinely bespoke. Design for the sixteen and route the four to an exception path.
The architecture: from qualified to sent
Stage one is triggered by a deal reaching qualified with a scoping call completed. Entry condition: the scoping record is filled in — what they need, what success looks like in their words, their timeline, and the constraint they named. Owner: whoever ran the call. This is data capture, not writing, and it takes four minutes immediately after the call while it is fresh.
Stage two is shape selection. Somebody picks one of the defined engagement shapes, or flags the deal as an exception. This is a decision that takes under a minute when the shapes exist and takes two hours when they do not, and it is the single biggest saving in the system.
Stage three is estimation, and it only runs for exceptions or where a shape has a variable component. The estimate works from a component library — named units of work with historical durations — rather than from a fresh guess. Owner: whoever will deliver, not whoever sold, which is a rule worth enforcing because the seller's estimate is systematically optimistic.
Stage four is assembly, triggered by shape selection. The proposal is generated from the shape plus the scoping record: standard structure, standard terms, standard pricing, with the client's situation and language injected. Target is fifteen minutes.
Stage five is the send gate. One review for accuracy and tone, then out — with the target being the same day as the call, because enthusiasm peaks at the end of the conversation and only decays from there. Stage six records what was sent, at what price, in what shape, so the win rate by shape and by price band becomes a number rather than an impression.
The exception path, and why it needs a gate
Genuinely bespoke work exists and should be quoted bespoke. The failure is when the exception path becomes the default wearing a different name, which happens quietly and takes about a year.
So the exception is a deliberate act with an owner and a threshold. Somebody marks the deal as an exception and records why in one sentence. That sentence is the whole control, because it forces the question of whether this is genuinely different or merely unfamiliar.
Then measure the exception rate. Under a quarter of deals is healthy. Above that and the shapes are wrong — and the recorded reasons tell you exactly how, because a recurring exception reason is a missing shape announcing itself. That feedback loop is the mechanism by which the system gets better rather than ossifying.
The exception path also gets a longer clock, honestly stated. A bespoke quote takes days and the client should be told that on the call, because an unset expectation is what turns a three-day quote into a lost deal.
The failure edges
The first: the rate card is decided in the presence of a client. Once that happens the card is no longer a card, it is a starting point for negotiation with yourself, and within a quarter you have as many rates as clients. The decision has to be made in daylight, against your economics, and written down.
The second: shapes with no stated exclusions. A shape that says what is included and not what is excluded does not survive first contact, because scope arguments happen at the boundary and the boundary was never drawn. Every shape needs its what this does not cover paragraph.
The third: estimates from the seller. Optimism is structural rather than dishonest — the person in the sales conversation is exposed to the client's enthusiasm and not to the delivery team's queue. Route estimates to delivery and the accuracy changes immediately.
The fourth: no win-rate data by shape. Without it, pricing changes are guesses. With it, you can see that one shape wins seventy percent at its current price and should probably cost more, which is the highest-return finding this system produces and the one it produces automatically.
The fifth: the assembly step still requires judgment. If generating the proposal means deciding what to include, nothing has been separated and you are back to an evening per deal with extra steps.
Where it lives, and the reporting it produces
The shapes, rate card and component library live as records rather than as a document, because assembly needs to read them. In practice that means structured records in the CRM or in Notion, with the assembly step pulling from them — a rate card in a PDF cannot be assembled from, and a rate card in someone's head cannot be audited.
Assembly runs from the deal record, which is what makes same-day sending achievable: the scoping data is already attached, so generating the document is a selection plus an injection rather than a search across three tools. In GoHighLevel this is a document template driven by custom fields; in a lighter stack it is a document generator triggered from the CRM.
The reporting this produces is the most under-anticipated part of the system. Win rate by shape, win rate by price band, median time from call to sent, and exception rate with reasons. Those four numbers turn pricing from an annual act of nerve into a quarterly decision — and the most common finding is that the shape winning seventy percent of the time has been underpriced for two years.
What done looks like, and what it takes to build
Done is a proposal that leaves the same day as the call, in under twenty minutes of work, at a price you can state out loud without hedging because you decided it a quarter ago.
The checklist: a written rate card; three to five engagement shapes with scope, price, and exclusions; a component library with historical durations for estimating; a scoping record captured at the call; an assembly step that produces the document; an exception gate with a recorded reason; and a sent record carrying shape, price and outcome.
The build is usually one to two weeks once the shapes exist, and defining the shapes is the actual work — it is a decision-making exercise rather than a technical one, and it is the part that cannot be outsourced because it encodes what your business sells.
The prerequisite worth naming: a scoping call that captures structured information. If the scoping record is a paragraph of notes in someone's own shorthand, assembly cannot be automated, and the system degrades into a nicer template.
The pricing decision and the pricing document are different objects. Decide shapes and rates in daylight; make the proposal a fifteen-minute assembly step that ships the same day.