LearnGrok
Workflows
WorkflowIntermediateGrok Bot basics

Proposal draft from discovery evidence

Create a review-ready customer proposal from discovery notes, requirements and commercial points for sales teams.

6 min read

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:

  1. 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.
  2. 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.
  3. Requirements

    • Functional requirements.
    • Technical, security, integration and implementation requirements.
    • Items marked confirmed, requested, assumed or unknown.
  4. 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.
  5. 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:

  1. Executive summary.
  2. Customer objectives and current context.
  3. Proposed solution and scope.
  4. Delivery approach, responsibilities and indicative milestones.
  5. Commercial summary.
  6. Assumptions, exclusions and dependencies.
  7. Open questions.
  8. 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, and fixed. 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.

Last checked against xAI’s own pages on 2026-08-21. Grok changes quickly; anything version-specific should be confirmed upstream before you rely on it.

More in Grok Bot basics

Found something out of date?

Grok changes quickly and this page is a snapshot. If something here is wrong, or you know a better resource, send it over.

Suggest a link →

Advertise on LearnGrok

$420.69one-time, for a 30-day run

Square works best. PNG, JPEG or WebP, up to 2 MB.

Stripe on the next step. Live once approved.