A team asks an AI assistant to make a proposal clearer and more persuasive. The approved scope says “two workshops, with dates to be agreed.” The polished draft offers “a complete transformation programme delivered within four weeks.”
This is an illustrative example, not a client story. The problem is easy to miss because the new sentence sounds better. It also describes a different offer.
Before an AI-assisted proposal leaves the organisation, review what the recipient could reasonably expect you to deliver. Grammar, tone and presentation matter, but they do not establish that the scope, timing and conditions are approved.
My workshop material treats clear tasks, context and reference information as foundations for useful AI assistance. My VORTA material connects scope boundaries, stakeholder expectations and approval workflows. Applied to proposal writing, those ideas suggest a practical discipline: compare the promises in the draft with the offer that the team is authorised and able to make.
Look for changes in meaning, not just new facts
A proposal can drift without adding a visibly false number. A qualification disappears. An optional service becomes part of the package. A customer’s hoped-for outcome becomes something the provider appears to guarantee.
Pay particular attention to these changes:
- Possibility becomes commitment. “We can explore integration” becomes “We will integrate.”
- A dependency disappears. A delivery date remains, but the requirement for the customer to provide approved data is removed.
- A boundary widens. “One department” becomes “across the organisation.”
- An option becomes included. Follow-on support moves from a separately discussed service into the main deliverables.
- An objective becomes a promised result. “Identify opportunities to reduce handling time” becomes “Reduce handling time.”
These are commercial and delivery questions before they are writing questions. An AI assistant can help locate them, but the people responsible for the offer must resolve them.
Start from an approved offer, not a persuasive example
Give the drafting process an authoritative source for this particular proposal: the agreed scope brief, current pricing, approved delivery assumptions and permitted claims. Separate those inputs from example proposals used only to demonstrate tone or structure.
An old proposal can be useful as a writing reference while containing the wrong service package, dates or support terms. Tell the assistant which parts may influence style and which facts must not be carried over. Use only material authorised for the tool and this recipient; another customer’s proposal is not automatically suitable reference material.
If a detail has not been decided, keep it visibly unresolved in the working draft. Do not invite the assistant to make the document “complete” by inventing a price, naming an owner or choosing a deadline. An internal question is more useful than a plausible commitment nobody approved.
For the upstream brief, see AI Task Briefs: Define Done Before You Write the Prompt. The review here concerns a different point in the workflow: what the finished proposal actually offers to its recipient.
Review a short commitment map
For a short proposal, a few annotated lines may be enough. For a larger offer, keep a simple review sheet outside the customer-facing document. Record four things for each material commitment:
- Draft wording: the sentence or section that describes what will happen.
- Approved basis: the source and version that support the offer.
- Difference or gap: anything added, omitted, strengthened or still undecided.
- Review decision: retain, correct, remove or obtain a decision from the authorised owner.
Read across the whole document. A cautious scope section does not fix an unconditional promise in the executive summary. Check headings, captions, timelines and pricing notes as well as the main paragraphs.
This map is a practical review aid, not a legal assessment or a prescribed VORTA template. It helps expose decisions that polished prose can otherwise conceal.
An example: a workshop offer that quietly expands
Consider this fictional approved brief:
“Two remote workshops for the operations team. The customer supplies the process descriptions beforehand. A prioritised opportunity summary follows the workshops. Implementation and ongoing support are outside this offer. Dates will be agreed after input availability is confirmed.”
An AI-assisted draft says:
“Our programme will transform your operations through tailored workshops, a complete implementation roadmap and ongoing expert support, delivered in four weeks.”
The reviewer should not merely replace “transform” with a more restrained adjective. Several decisions need attention:
- “Complete implementation roadmap” is a larger deliverable than an opportunity summary.
- Ongoing support has been added despite an explicit exclusion.
- A four-week timetable has been introduced without approved dates.
- The customer’s responsibility for supplying process information has disappeared.
A corrected draft should restore the approved deliverables and dependencies. If the sales team wants to include a roadmap or support, that is a proposed change to the offer. Delivery capacity, scope and commercial approval need to be settled before the revised promise is sent.
The useful distinction is between improving how an offer is explained and changing the offer itself.
Use AI to assist the comparison, not certify the proposal
A bounded review instruction can help:
“Compare this draft with the approved scope brief. List statements about deliverables, timing, customer responsibilities, exclusions and expected outcomes. Identify unsupported additions and missing qualifications. Quote the relevant wording from both documents. Do not invent missing terms or rewrite the offer.”
Treat the resulting list as a starting point. Check its findings against the actual sources and read the proposal yourself; an automated comparison may miss a subtle change or flag a harmless wording difference. Asking the same assistant whether its own draft is accurate does not provide independent confirmation.
The NIST AI RMF Core emphasises clear roles and responsibilities for human–AI configurations. That broader principle supports assigning the commercial and delivery decisions to identifiable people. NIST does not prescribe the proposal-review method described here.
Approve the version that will be sent
Keep writing review and offer approval distinct. A colleague may improve readability without having authority to approve a new delivery commitment. Route unresolved scope, pricing and timing questions to the appropriate owners under the organisation’s existing process.
Then check the final customer-facing version. Changes made after approval, including a last-minute request to make the summary more compelling, can reintroduce an unsupported promise. Keep the approved source and final version together so the team can explain what it offered.
For sensitive commercial terms, use the organisation’s established legal and commercial review; this checklist does not replace it. If source material itself is unsuitable for the assistant, first apply the business-data boundary checks.
AI can help a team express an offer clearly. The leadership responsibility is to ensure that clarity describes an offer the organisation has actually chosen to make. Before sending, ask: “Which sentence would surprise the person who has to deliver this?” Resolve that sentence first.
If you need to define where AI can assist proposal workflows and where people must retain approval, you can schedule a consultation.