The demo video is always the same. Somebody pastes a meeting transcript, hits a button, and thirty seconds later there is a fourteen-page PDF with the client logo, three references and a pricing table. Applause. What the video leaves out is that the PDF cannot be sent yet: somebody still has to decide whether the scope is right, whether the price holds, and what gets conceded when the client pushes on Thursday afternoon. Nobody has touched that part.
The thesis in one line: a sales proposal has two halves that look alike in the finished document and are alike in nothing else. One is company memory — standard scope, terms, deliverables, references, legal boilerplate — and it can be automated end to end, today, with no argument. The other is market judgement — the discount, this client’s risk, the opportunity cost of saying yes — and automating it does not save hours: it transfers margin. Automate the document. Not the decision behind it.
Automating sales proposals without losing margin starts by separating assembly from decision
The industry sells speed because speed demos well and judgement does not. "Proposals in thirty seconds" fits on a slide; "a person with context still sets the discount" does not. So the pitch organises itself around the writing, which is the visible part of the work, and leaves out the part that decides whether you make money on the deal.
The slow part of a proposal is almost never the writing. It is the gathering: digging up the scope from the similar project that went well, retrieving the payment terms legal signed off on, finding the case study from the right sector, checking what price this client got last time so you do not contradict yourself. That is archive work, not sales talent. And it is precisely what a machine does better than you, because it does not forget and it does not lose folders.
How heavy that back-office load is can be read off a hard source rather than an agency estimate. Salesforce’s State of Sales — seventh edition, a survey of 4,050 sales professionals across 22 countries including Spain and the US, fielded August to September 2025 and published February 2026 — finds the average seller spends 40% of their time selling. The other 60% goes to admin: data entry, hunting for information, building documents, chasing follow-ups. It is a global figure and it does one job here: it sizes the problem. It says there is a large pocket of assembly work in the sales cycle. It does not say that we, or anybody, will remove all of it.
Which blocks of a proposal are assembly
The practical test for classifying a block is a single question: does the correct answer already exist written down somewhere in your company? If yes, it is assembly and it gets automated. If it has to be invented while looking at this specific client, it is a decision and it does not. On that test, the list of what ships itself is longer than people expect:
- Standard scope of the service: what is in, what is out, in how many phases and with what deliverables. This lives in your catalogue, or it should.
- Terms: payment schedules, validity of the offer, penalties, ownership of the work, data protection. Legal wrote it once and it gets reused word for word.
- References and case studies: the one from the client’s sector, of a comparable size, with a result you are allowed to tell. Picking the right one is a query, not a judgement call.
- The summary of the conversation: what the client said hurts, in their words, lifted from the call and returned on page one. It is the part that stops the proposal sounding like a template, and it is pure transcription.
- The line maths: hours by role, units, extensions, totals, tax. Arithmetic against a price list, not negotiation.
- The format: cover, contents, typography, version, numbering. Nobody ever won a deal on layout, and entire afternoons die there.
Which blocks are decisions, and why the price is the most expensive one to delegate
On the other side sit four things, and all four share a trait: you do not answer them by looking at your archive. You answer them by looking at the market and at this client. How much discount applies. What risk this client carries and whether that gets priced. What comes out of the scope if the budget will not stretch. And whether to take the work at all, because sometimes the right answer is no.
Of those four, the discount is the most expensive to hand over, and there is a classic number that explains why. In "The power of pricing" (McKinsey Quarterly, February 2003), Marn, Roegner and Zawada calculated on the average income statement of an S&P 1500 company that a 1% price rise, with volumes stable, lifts operating profit by 8%. And that the sword cuts both ways: a 1% fall in average prices takes that same 8% back out. The same article carries a more uncomfortable figure: offsetting the profit impact of a 5% price cut would take 18.7% more volume, which almost no market returns.
The scope of that number is explicit and worth not stretching: it is the average structure of large US listed companies in 2003, not your mid-market firm in 2026. What survives the trip is not the exact figure, it is the asymmetry. Price is the most leveraged line in the income statement, which makes it the last place to install a machine optimising for "close fast". An agent told to get the yes will learn what any unsupervised rep learns — that cutting the price gets the yes. The difference is that it never tires, never feels embarrassed, and does it across every proposal at once.
| Block of the proposal | Nature | Who does it |
|---|---|---|
| Summary of the client need | Assembly (transcription) | System |
| Scope, phases and deliverables | Assembly (catalogue) | System |
| Terms and legal boilerplate | Assembly (literal reuse) | System |
| Sector references and cases | Assembly (query) | System |
| Line maths and totals | Assembly (arithmetic) | System |
| Discount and special terms | Decision (margin) | Person |
| Client risk and whether it is priced | Decision (judgement) | Person |
| Cutting scope when the budget is short | Decision (strategy) | Person |
| Taking the work or walking | Decision (business) | Person |
The control point goes before sending, not after
Almost every implementation we have watched fail on this axis makes the same sequencing error: it lets the system generate and send, and puts the review in next month’s report. By then the proposal is in the client’s hands with a price nobody approved, and a discount that slipped through cannot be withdrawn without burning the relationship. A control that arrives after an irreversible act is not a control. It is an autopsy.
The right placement is boring and it works: the system assembles the whole document, calculates list price, and stops. What reaches the person is not a blank form — it is a finished proposal with exactly one open field, the price adjustment, and the context to settle it in two minutes: what margin is left at list, what this client paid last time, what discount went out on the three comparable deals. Deciding with that in front of you takes less time than hunting for it, and that is the difference between reviewing and starting over.
Where exactly that person sits without becoming the brake on everything else is a design problem with a name, and we work it through in human in the loop: where to put validation without killing the saving. The short rule: validation goes where an error costs money, not everywhere. In a proposal, that is the price and not much else.
Living template versus catalogue: the pattern that holds
The pattern that breaks within three months is the living template: a master document that gets edited, copies spawned off it, and every rep’s private tweak baked in. It is comfortable at first because there is nothing to build. Later you have four versions of the legal text in circulation, two different prices for the same service, and no way of telling which is current. AI on top of that does not fix the mess. It reproduces it faster and with better typography.
The pattern that holds inverts the relationship: the document is not the source, it is a view. The source is a catalogue with one version of each thing, and the proposal is composed by querying it. In working order:
- A service catalogue with scope, deliverables and list price. One entry per service, with an owner and a last-reviewed date.
- A library of reusable text blocks — terms, legal, methodology, references — versioned, not copied.
- Written pricing rules: what discount each role can apply without asking, and above what amount a signature is required. In euros, not in judgement.
- A composer that reads the CRM and the catalogue and produces the document without anybody opening a Word file.
- A record of what was sent, at what price and who approved it. Without this there is no way to learn anything from the proposals you lose.
The last three are not administrative decoration: they are what makes this a system instead of a loose script. A log of what was done, scoped permissions, and the ability to reconstruct a decision months later are the mechanics we lay out in governance and control of AI automation. Applied to proposals it has one concrete and rather pleasant consequence: next time the board asks why margin is sliding, there is an answer with data instead of a theory.
What to measure to know whether it worked
This is where you should not copy the vendor’s dashboard, because the vendor measures what flatters it: drafting minutes. The four metrics that actually say something are different:
- Hours from meeting to proposal sent. Not generation minutes: the clock starts when you hang up and stops when the client has it. That is where you see whether the bottleneck moved or just changed costume.
- Average discount granted, by person and by service. The metric nobody wants to look at, and the only one that catches whether automating the document loosened pricing discipline.
- Share of proposals sent at list price. If it rises, the system is working where it matters. If it falls while speed improves, you bought pace with margin.
- Proposals withdrawn or corrected after sending. Anything other than zero means the control point is in the wrong place.
Our commitment on a project like this is measured with those four, not with a savings percentage promised up front. The third-party figures in this piece size the problem — how much time goes to back-office work, what a point of price costs; they are not our result or anybody else’s, and anyone presenting them as theirs is selling you a source dressed up as a case study.
Where to start
Not with the whole proposal. With the block that eats the most time and needs the least judgement, which in almost every company is the same one: standard scope and terms. You build the catalogue for the five or six services that make up 80% of what you sell, wire it to the CRM, and let the system produce the document up to the pricing table with the discount field left open. Two weeks of work, and the clock on the first metric is already running.
Once that leg runs itself, the next step depends on what you sell. If the pain is the long, argued proposal, the piece is writing the sales proposal in an afternoon, not three days. If what they ask you for is a price and what you lose is work by being slow, it is quotes in minutes, not the next day. And if the document is only a symptom and what is collapsing is the whole back office of the cycle — CRM out of date, follow-ups unchased, deals going cold — the fit is the AI sales agent on your pipeline.
The line worth taking away is the one we opened with, and it holds in any process with a negotiable number at the end: automate the document, not the decision behind it. Delegating the writing gives you afternoons back. Delegating the price gives you a client’s yes and takes 8% of operating profit for every point you conceded, and that never shows up in a productivity report.