Examples / Sales
Quote & Proposal Drafter
This is not an AI that sends quotes. It is a proposal organizer: it rebuilds the state of a deal from your own records and drafts a cited proposal a rep reviews and sends. It never quotes a price you didn't set, and it never hits send.
Shown on a realistic sample dataset — real CRM and pricing formats, an invented company (“Northwind Interiors”), no real customer data.
The leverage point
The stall isn't writing the proposal. It's re-gathering the deal.
Before a rep can quote, they reconstruct the deal by hand: dig the thread out of email, check what was promised on the last call, find the current price for this configuration, confirm the discount this account already has, and remember which terms legal approved last time. The writing is ten minutes. The gathering is an hour, it happens on every quote, and it's where deals go cold.
The information to write the proposal already exists — it's just scattered across the inbox, the CRM, and a pricing sheet. That's the signature of a leverage point: a front-of-workflow bottleneck where a flag-and-draft, not a decision, unlocks the work behind it.
So we don't automate judgment about the deal. We automate the assembly, and hand the rep a draft they can trust because every line points back to a source.
The build
What the AI does. What stays human.
The whole design is a boundary. The system prepares; the person decides and sends.
The AI does
Rebuilds the deal timeline from the thread and CRM. Pulls the current price for the exact configuration from your pricing sheet. Applies only the discount the account already holds. Drafts the proposal from your approved template, with every figure cited to its source. Flags anything missing or contradictory as a question.
The human does
Reviews the draft against the flagged questions, sets any price or term that requires judgment, approves or edits, and sends. Nothing leaves the building without a person. Discounts beyond the account's standing, new terms, and anything with a signature stay a human decision.
How it runs
A short, inspectable chain — no black box.
Ingest with anchors
Pull the thread, CRM record, and pricing sheet into plain records — each fact tagged with where it came from (message ID, CRM field, price-sheet row) so it can be cited later.
Reconcile the deal
Assemble one deal ledger: configuration, quantities, list price, the account's standing discount, and prior approved terms. Where the email and the CRM disagree, that mismatch becomes a named review question — it is not silently guessed.
Price from the source of truth
Every number comes from your pricing sheet, not the model's memory. If a configuration has no listed price, the system stops and asks rather than inventing one.
Draft, cited
Fill your approved proposal template. Each price and claim carries a citation back to its anchor, so the rep can verify a line in seconds instead of re-deriving it.
Stop at the human gate
Export an editable draft plus the list of open questions. The system does not send, does not commit a price to the CRM, and does not touch anything that carries a signature.
The test it has to pass
We write the pass/fail bar before we build.
A proposal drafter that looks great on one polished deal can quietly misprice the next. So the value isn't the demo — it's the test set. On the sample dataset we score the build against concrete right-and-wrong cases, and it ships only when it clears them:
- Every price traces to the sheet. No figure appears in a draft without a citation to a real pricing-sheet row. Target: 100% — an uncited number is an automatic fail.
- No invented discount. When a case gives an account no standing discount, the draft applies none. A hallucinated discount fails the case.
- Gaps get flagged, not filled. When a configuration or term is missing, the build raises a question instead of guessing. Silent guesses fail.
- Contradictions surface. When the email and CRM disagree on quantity, the mismatch appears as a review question in the draft.
- The send boundary holds. Across every case, zero sends, zero CRM writes, zero signatures. One breach fails the whole build.
Cases live beside real formats but invented people, so we can prove the pipeline without touching anyone's live pipeline.
The result
Measured, not promised.
This build is a real runnable pipeline, not a mockup. The figures below come from its actual run over three sample deals, with a test set that has to stay green before it ships:
100% cited
Measured: every price in every draft traces to a pricing-sheet row — an uncited number fails the build.
0 auto-sends
Measured across all cases: nothing sent, committed to the CRM, or signed without a person. Enforced by the test suite.
~55 min → ~6 min
Per-quote prep time: assembling the deal drops from about an hour to a review pass. Illustrative of the target we'd measure on your cases.
The cited-coverage and zero-send figures are measured by the build's own passing test set on the sample data. Time-saved is the target we'd measure against your real cases in a Pilot Build.
Why this repeats
The same skeleton fits your workflow next.
Nothing here is quote-specific except the anchors and the ledger. Ingest-with-citations, reconcile-into-a-ledger, act-from-the-source-of-truth, draft-cited, stop-at-the-human-gate is the same chain we point at invoice-approval chasing, support-access triage, and inbox commitments. Change the documents, keep the architecture. That's how a second build costs a fraction of the first — and why the example you're reading is also the starting point for yours.
Is this your workflow?
If your reps rebuild the deal before every quote, this build starts from here — pointed at your data instead of the sample. Tell us where the gathering hurts.
Get in touch See other examples →