Proposal generation looks like an obvious job for AI.
Give it the notes from a discovery call. Ask it to summarise the customer's needs. Add some information about the service and produce a professional document.
The first result can feel magical.
Work that used to take hours appears in minutes.
But writing the document was never the hardest part of producing a good proposal.
The hard part is turning a customer conversation into a commitment the whole business can keep.
That requires more than good writing.
The easiest version of a proposal agent creates Sales Fan Fiction: a persuasive story the customer wants to buy and the rest of the business cannot profitably deliver. It's one of the six AI agent failure modes I see most often. A useful proposal agent has to connect the sales promise to margin, capacity, terms and delivery reality.
A proposal sits between sales promise and delivery reality
A proposal has to do several jobs at once.
It needs to reflect what the customer said. It needs to make the offer compelling. It needs to protect the organisation's commercial position. It needs to promise work delivery can actually perform. It needs to look and sound like the business.
Those goals can pull in different directions.
Sales wants to win the opportunity. Delivery wants a feasible scope. Finance wants to protect margin. The customer wants confidence, value and often more than the standard offer includes.
A generic proposal generator optimises for the visible artefact.
A genuinely useful proposal agent has to optimise across the business.
A useful proposal agent does not optimise for winning the sale in isolation. It optimises for a sale the whole business can succeed with.
First decide which commercial rules are real
A proposal agent cannot safely work from a pricing policy the organisation routinely overrides.
If the official calculator says one thing, sales regularly does another and delivery absorbs the difference, the agent has no neutral pattern to copy. Following the calculator may make it commercially useless. Learning from the overrides may make it consistently unprofitable.
That conflict needs to be settled by the people who own the commercial outcome. It is not a gap for the model or implementation team to fill.
I explore that management problem, and the quotation process that made it visible, in Your AI problem might actually be a management problem.
Here, the useful question is what the agent needs once the business has made those choices.
Start with the outcome, not the document
If the instruction is “generate a proposal,” the agent will optimise for completing a proposal.
That is too narrow.
The specification should begin with the business outcome. For example:
Create a clear, persuasive offer that meets the customer's stated needs, protects the organisation's commercial position and commits delivery only to work it can reasonably fulfil.
That outcome gives the agent a way to reason about trade-offs.
Winning the sale matters. So do profitability, delivery feasibility, customer fit and the quality of the eventual relationship.
The agent should know which of those outcomes can flex and which must be protected.
What context does the agent need?
A useful proposal agent needs more than a transcript and a prompt template.
The commercial goal
What kind of business is the organisation trying to win?
The agent should understand the intended customer, offer, revenue model and strategic goal. A proposal for a premium advisory service should not be optimised in the same way as a standardised high-volume product.
The protected economics
The agent needs the commercial boundaries that must hold.
These may include:
- standard prices and assumptions;
- target and minimum margins;
- mandatory inclusions;
- payment and contract conditions;
- costs that are easy for sales to overlook; and
- which economics can only be changed by an authorised person.
This should not be hidden inside a spreadsheet only one team understands.
The available trade-offs
“Do not go below this price” is not enough context for intelligent work.
The agent should know what can change when the standard offer does not fit.
Can scope be narrowed? Can delivery timing move? Can an optional service be removed? Can the work be staged? Is there a lower-risk alternative that still addresses the customer's need?
A good proposal agent should not simply say no when the first version falls outside the guardrails.
It should find viable ways to bring the opportunity back inside them.
Delivery reality
The proposal agent needs enough product and delivery context to know what the organisation can actually fulfil.
That includes current offers, standard ways of working, important dependencies, capacity constraints and risks that affect feasibility.
Without that context, the agent becomes a very efficient way for sales to make promises delivery has to renegotiate later.
The customer's journey
The customer should not have to explain themselves again because the proposal stage uses a different tool.
The agent may need:
- discovery-call transcripts;
- CRM records;
- emails and submitted requirements;
- questions raised during the sales process;
- previous proposals or purchases;
- the people involved in the decision; and
- the language the customer uses to describe the problem.
This context helps the proposal feel like the next step in a conversation rather than a generic document with the customer's name inserted.
Brand and approved assets
The agent should use current messaging, case studies, service descriptions and visual assets without asking someone to find and paste them into a chat window.
The output still needs human taste and judgement where appropriate. But a person should not spend their time acting as the integration between a transcript, a chatbot, a slide deck and a document template.
Humans should not be the copy-and-paste layer between the systems that know the customer and the document that commits the business.
What should happen when the standard answer does not fit?
Exceptions are not a failure of the agent.
They are where human authority becomes useful.
The proposal agent should know:
- which decisions salespeople can make;
- which decisions require the sales manager;
- when delivery must be consulted;
- what finance or leadership must approve; and
- which boundaries cannot be waived through the proposal process.
When it reaches a genuine decision, it should not return a vague warning or ask a manager to start the analysis again.
It should present:
- the customer need or commercial opportunity;
- the reason the standard offer does not fit;
- the boundary or goal affected;
- the available options;
- the effect of each option on price, margin, scope and delivery risk; and
- the person authorised to decide.
The human provides judgement and authority.
The agent provides context and coordination.
An approved exception is not automatically a new rule
Imagine a sales manager approves a lower margin for one strategically important customer.
The agent should record what was decided and why. It should not immediately conclude that every future customer can receive the same concession.
The exception may be:
- a one-off decision;
- part of an explicit experiment;
- evidence that the current pricing approach needs review; or
- a durable change the organisation should adopt.
Only the last of those belongs in the proposal specification as a new standard rule.
AI can surface the pattern and prepare the evidence. The accountable people decide what the organisation has learned.
Otherwise, the proposal agent will slowly automate every workaround until the official process becomes the collection of exceptions it was meant to control.
The learning should continue after the proposal is sent
A proposal does not become successful when the PDF is generated.
The organisation should learn from:
- whether the customer accepted it;
- which questions or objections followed;
- whether the final contract changed;
- whether the proposed margin survived delivery;
- whether the scope was interpreted consistently;
- whether delivery completed the work as expected; and
- whether the customer achieved the promised outcome.
An agent can bring these signals together and identify patterns that are hard to see across systems.
But the feedback should serve the full business outcome.
If the agent learns only from win rate, it may recommend concessions that create problems later. If it learns only from delivery efficiency, it may produce offers customers do not value.
The proposal specification should improve from sales and delivery reality together.
What does success look like?
A genuinely useful proposal agent should produce more than an attractive document.
The finished proposal should be:
- aligned with what the customer actually said;
- consistent with the organisation's offer and brand;
- commercially viable;
- feasible for delivery;
- explicit about any exception and its owner;
- created without manual context shuttling; and
- connected to learning from later sales and delivery outcomes.
There should also be a human benefit.
Salespeople spend more time understanding the customer and shaping the opportunity. Delivery becomes involved through clear boundaries rather than late surprises. Managers receive fewer routine approvals and better-framed commercial decisions.
The agent carries the administrative and coordination burden without separating people from the outcome.
A practical first version
Do not begin by asking the agent to price, approve, negotiate and learn across every kind of opportunity.
Start small and whole.
A useful first version might:
- collect the discovery call and relevant customer context;
- identify missing information before drafting;
- generate a proposal using the standard offer and pricing;
- check mandatory inclusions, margin and delivery boundaries;
- offer scope trade-offs where the standard approach does not fit;
- route genuine exceptions to the authorised person with options; and
- produce the finished document using approved brand assets.
The beginning, outcome and human handoff are all clear.
Later versions can add negotiation support, deeper performance analysis and deliberate specification updates after the organisation has learned how the core Loop behaves.
The proposal loop on one card
Written as a compact six-question loop specification, Proposal to Commitment looks like this:
- Name and owner: Proposal to Commitment, owned by the sales or commercial leader.
- Starts when: the opportunity is qualified, required discovery is present and the opportunity is marked proposal-ready.
- Definition of done: the customer need is addressed, margin is protected, delivery is feasible, claims and terms are approved, the proposal is sent, the CRM and forecast are updated and the next action is owned.
- When done: the customer has a proposal it can accept and the business has a commitment it can deliver profitably.
- Available: CRM, discovery record, pricing and margin rules, delivery capacity, case studies, standard terms and pricing-check, feasibility, legal-terms and proposal-generation sub-loops.
- Guardrails: act inside standard scope, price and terms; ask about discounts, novel scope, unusual risk, capacity conflict and non-standard terms; stop when need, pricing authority or delivery capacity cannot be established.
The upstream version of this loop, sales follow-up, follows the same pattern.
Questions to settle before building
Before implementing a proposal agent, bring sales, delivery and the commercial owner into the same conversation.
Ask:
- What is a successful proposal for the whole organisation?
- Which margins or terms must always be protected?
- What can sales change without asking?
- Which scope trade-offs are genuinely available?
- What must delivery validate before commitment?
- Who can approve each kind of exception?
- What customer context must be present before drafting begins?
- What must be true before a proposal can be sent?
- Which questions are still undecided?
Do not ask the AI builder to fill the gaps.
The act of answering these questions creates two gains: a workflow that can be automated and teams that are working from the same commercial logic.
That second gain may be the more valuable one.
How BusyWork Dispatch fits
BusyWork Dispatch treats the proposal agent as more than a prompt attached to a template.
The Workbook can hold the durable context: the commercial goal, offer, language, guardrails, ownership and open decisions. The proposal Loop defines the trigger, required context, outcome, definition of done, handoff and resources used to carry out the work.
Customer and operational systems remain the source for the live information the proposal needs. Completed work can surface learning back to the people who own the specification.
The practical starting point is not “automate proposals.”
It is to define one proposal the whole business would be happy to win and deliver, then build the smallest end-to-end Loop capable of producing it.
Bottom line
A genuinely useful proposal agent does not simply turn notes into a polished document. It connects customer need, sales intent, profitability and delivery reality; works within explicit commercial boundaries; and returns genuine exceptions to the people authorised to decide.
Its purpose is not to help sales promise more work faster.
It is to help the organisation make better commitments with less manual coordination.
A proposal is the moment a customer conversation becomes a promise the whole business has to keep.
That is the outcome the agent should be built to protect.
BusyWork Dispatch helps businesses turn repeated work such as proposal creation into owned, context-rich Loops connected to the people responsible for the outcome. See how BusyWork works or book a call with Ben.
