Use this workflow when you need a first proposal draft that traces back to what the customer said, asked for and agreed. It is for sales representatives and solutions consultants who need a document ready for internal review, not a document ready to send without checks.
The result is a proposal draft with a clear scope, commercial summary, assumptions, open questions and named approval points. You keep control of commitments, pricing and technical claims.
Key point
Draft from evidence, not memory
Give the model a structured evidence pack and require it to mark anything that is missing, uncertain or awaiting approval.
1. Build the evidence pack
Create one working document called Proposal evidence pack - [Customer] - [Opportunity]. Do not begin with a loose prompt or a folder of unlabelled meeting notes.
Add these sections in this order:
Customer and opportunity
- Customer name, business unit and country or region.
- Buyer, sponsor, technical contact and procurement contact.
- Opportunity name, intended start date and proposal deadline.
- The customer problem in their own words, with the source meeting or email.
Discovery evidence
- Notes from each discovery call, labelled with date and attendees.
- Confirmed business outcomes and success measures.
- Current process, systems, constraints and dependencies.
- Direct customer quotations where wording matters.
Requirements
- Functional requirements.
- Technical, security, integration and implementation requirements.
- Items marked
confirmed,requested,assumedorunknown.
Commercial points
- The agreed offer, quantity, term, billing basis and commercial timing.
- Approved pricing inputs or a clear note that pricing is pending.
- Any discount, pilot, renewal or procurement condition already agreed.
- Internal deal desk, finance or leadership instructions.
Reference material
- Your approved proposal template.
- Approved product descriptions, case material and statement-of-work wording.
- The current approval policy and required signatories.
Remove personal data, confidential material and customer information you are not authorised to use with the tool. Check your organisation's approved use rules before uploading or pasting material. Use the controls and current product guidance described in the xAI documentation overview, as availability and handling options are version-dependent.
Watch out
Do not fill gaps with plausible details
A proposal can sound complete while quietly adding a feature, delivery date or commercial commitment that nobody approved.
2. Convert notes into a fact table
Before asking for a draft, ask the model to create a table from the evidence pack. Use this prompt:
Create a proposal fact table from the evidence below. Do not infer missing facts.
For every item, return: topic, statement, source, status (confirmed/requested/assumed/unknown), and proposal treatment (include, ask, exclude, or approval required).
Flag conflicts between sources. Keep customer wording where it affects scope or commitment.
[EVIDENCE PACK]
Read the table before moving on. Correct wrong source labels and resolve obvious contradictions. For example, a requirement mentioned by an evaluator is not necessarily an agreed scope item. A target launch month is not a committed delivery date.
| If you see this | Treat it as | What to do next |
|---|---|---|
| Customer states a need in a meeting | Requested requirement | Include it as proposed scope only if it is feasible and approved |
| Your team says a feature is available | Internal claim | Check the approved product material before stating it to the customer |
| No quantity, term or price is recorded | Unknown commercial point | Put it in open assumptions or approval points |
| Two notes disagree | Conflict | Ask the account owner or customer contact, do not choose one silently |
Check
The fact table is usable when every scope statement has a source
If you cannot point to a note, requirement or approved reference, it belongs in an open question, not the proposal body.
3. Set the proposal frame
Decide the document structure before drafting. Use the customer-facing template if one exists. Otherwise, use this order:
- Executive summary.
- Customer objectives and current context.
- Proposed solution and scope.
- Delivery approach, responsibilities and indicative milestones.
- Commercial summary.
- Assumptions, exclusions and dependencies.
- Open questions.
- Approval points and next steps.
Tell the model who will read it. State whether the audience is an economic buyer, technical evaluator, procurement team or a mixed group. Also state the proposal's purpose: first response, post-discovery proposal, pilot outline, revision or renewal.
Do not ask for legal terms, binding commitments or final pricing language unless those texts are supplied and already approved. The draft supports internal review. The appropriate commercial, technical and legal reviewers decide what may be sent.
4. Generate the first draft
Use the fact table and approved reference material, not the raw notes alone. Ask for visible uncertainty. A suitable prompt is:
Draft a customer proposal using the structure below and the supplied fact table.
Rules:
- Use only confirmed facts and approved reference material as statements of fact.
- Label requested items as proposed, subject to validation where needed.
- Do not invent capabilities, integrations, dates, quantities, pricing, outcomes or commitments.
- Put missing or conflicting information in Open questions or Approval points.
- Keep the tone direct and specific to the customer's stated objectives.
- For each assumption, state the effect if it proves false.
Structure: [PASTE STRUCTURE]
Fact table: [PASTE FACT TABLE]
Approved material: [PASTE APPROVED EXCERPTS]
Request the output in the same headings as the final document. This makes comparison and editing easier. Keep the initial draft separate from the approved template until the review is complete.
5. Check the draft against the evidence
Run three checks yourself. Do not rely on fluent prose as proof that the content is correct.
- Traceability check: Highlight each customer-specific claim. Match it to a row in the fact table or an approved reference.
- Commitment check: Search for words such as
will,guarantee,included,compatible,complete,by, andfixed. Confirm that each is authorised. - Commercial check: Compare quantities, term, currency, payment wording, discount and dates with the approved commercial inputs.
Then ask the model for a structured review:
Compare this proposal draft with the fact table. Return only:
1. unsupported claims,
2. missing confirmed requirements,
3. statements that sound like commitments,
4. commercial fields that are absent or inconsistent,
5. assumptions that need an owner and due date.
Do not rewrite the proposal.
Stop
Do not send the draft because it has no tracked changes
A clean document can still contain an unapproved promise. Review the meaning, not just the formatting.
6. Finish the handover
Save three items in the opportunity record:
Proposal draft - [Customer] - [date]Proposal evidence pack - [Customer] - [date]Proposal review log - [Customer] - [date]
In the review log, list each open assumption, its owner, the evidence needed, and the deadline. List approval points separately, such as pricing approval, solution design confirmation, delivery capacity confirmation and customer confirmation of scope.
Send the internal reviewer a short handover: what changed, what remains unknown, which claims need approval, and the date by which the customer needs an answer. The account owner decides when the reviewed proposal is ready to share.
When the workflow does not work
If the output is generic, the evidence pack is usually too thin or the prompt lacks the customer objective. Add the actual discovery statements and success measures. If the draft invents details, reduce the source material to approved excerpts and require a source for every claim. If commercial fields keep changing, stop redrafting and get a single approved commercial input sheet. If reviewers disagree on scope, record the conflict as an approval point and resolve it before producing another customer-facing version.