LearnGrokUse this pack after discovery, when you need to turn scattered call notes into a proposal structure that another person can review. It is for account executives preparing a tailored proposal and sales managers checking that the document does not outrun the evidence.
The pack produces an internal outline, not a final promise to the buyer. It keeps confirmed requirements, assumptions, commercial gaps and approval-sensitive claims separate.
Key point
Start with evidence
Build the source register before drafting. A neat proposal built on an untested call note is still wrong.
Prepare the source material
Collect the material into four labelled blocks before you paste anything:
- Discovery call notes: include attendees, direct buyer wording, decisions, objections, deadlines and actions.
- Account research: include only research your team is prepared to rely on. Mark the source and date in your own notes if possible.
- Approved pricing inputs: include approved packages, units, quantities, currency, terms, discounts and validity rules. Do not substitute a previous deal's numbers.
- Buyer-stated requirements: include emails, requirements documents and meeting notes. Keep the original wording where it matters.
Remove personal data or confidential material that your company policy does not permit you to enter into a tool. Input handling and available features can be version-dependent, so check the xAI documentation overview before using sensitive opportunity material.
Watch out
Do not fill pricing gaps
An outline may show a pricing gap. It must not turn an absent figure into an estimate or a commercial commitment.
Run the prompts in order
- Start with Source facts and gaps register. Paste every source block, even if some are thin. This prompt distinguishes what the buyer actually said from what your notes imply.
- Read the requirements table before proceeding. Resolve obvious duplicates, such as two notes describing the same integration need. Do not merge statements that differ in scope or priority.
- Run Requirement-to-approach map. Add only approved information about what your team can offer. This is where a requirement can correctly remain
not mapped. - Use Proposal outline draft once the map is broadly complete. Set the proposal objective precisely, for example, a decision on a defined pilot rather than a vague request for approval.
- Run Claims and approval review against the resulting outline. Send the claims register to the relevant commercial, delivery, product or security owner.
- Run Final outline completeness check after reviewers have responded. Its release decision tells you whether the document is ready for internal approval, not whether it is ready to send without your judgement.
If you only have ten minutes, run the first, third and fifth prompts. You will still expose the most costly problems: missing requirements, unapproved scope and unsupported claims.
Use the outline as a review document
The Confirmed requirements and proposed approach table is the centre of the document. Each buyer requirement should have an ID and a visible proposed response. A manager should be able to ask about R-04 and trace it from the call note to the proposed approach without reading the whole proposal.
Keep these categories distinct:
| Category | What belongs there | What to do next |
|---|---|---|
| Confirmed need | A requirement explicitly stated by the buyer | Map it to scope, deliverable or a question |
| Assumption | A working interpretation not confirmed by the buyer | Label it and ask for confirmation |
| Missing commercial input | A price, quantity, term or approval not supplied | Assign an internal owner |
| Approval-sensitive claim | A promise about outcome, timing, capability or compliance | Obtain written internal approval or soften the wording |
Do not hide an unresolved point in a polished paragraph. Put it in Items requiring buyer confirmation or Claims and commitments requiring internal approval. Those headings make review quicker and reduce the chance that a conditional statement becomes a promise in the final version.
Check
Check traceability, not prose
Pick three buyer requirements at random. You should be able to find the source, the mapped approach, the evidence or deliverable, and any open question for each one.
Know when the output is wrong
The output is unreliable when it sounds more certain than the source material. Watch for these signs:
- A timeline appears although no approved delivery plan was pasted.
- A business outcome is written as guaranteed rather than as a buyer objective or proposed measure.
- A feature, integration or service commitment appears without a source in the approved capability information.
- A commercial table contains a number, unit or term absent from the pricing input.
- A requirement has been silently dropped because it was awkward, vague or outside current scope.
- A research statement is presented as something the buyer confirmed.
Correct the source material first. Then rerun the affected prompt. Do not merely edit the final wording, because the unsupported statement may also appear in the requirement map, commercial section or approval register.
Note
Preserve ambiguity
Needs clarification is useful output. It is better than a confident interpretation that the buyer never made.
When the pack does not work
If the first prompt returns mostly gaps, stop drafting and arrange a short internal review or a buyer follow-up. Ask for the missing decision, quantity, timeline, scope boundary or commercial term by name.
If the proposal draft is generic, the usual cause is weak source material. Paste direct buyer wording and specific approved delivery information, then rerun the requirement map before drafting again. If the claims review marks too many items as unsupported, reduce the proposed scope to what is evidenced and route the rest for approval.
