How to Build a Discovery → Proposal Draft Bot (Scope, Estimate & Human Approval)

Quick answer: A discovery → proposal draft bot should turn call notes (or a structured intake form) into a scoped brief, match packages against your rate card, draft proposal sections, run validators, and stop for human Approve/Edit before anything is emailed as a PDF or portal link. Never let the model invent prices, timelines, or deliverables your studio does not sell. Build it as Notes → Extract → Package match → Draft → Validate → Approve → Send — with tools + rules + LLM assist, not unbounded chat.

This is Part 6 of Build Real AI Automations. Parts 1–5 covered lead qualification, support triage, Shopify order status, content ops, and an appointment-booking agent. After the call is booked and discovery happens, this bot drafts the commercial next step — without auto-sending a hallucinated quote.

At Let Start Design we write proposals weekly for web, WordPress, Shopify, SEO, and AI automation work. The pain is consistent: notes live in Notion, pricing lives in someone’s head, and a freelancer “AI proposal GPT” invents a $4,800 timeline that your team never approved. Below is the architecture, guardrail list, build steps, MVP plan, and how we outperform freelancers and chatbot shops when proposal accuracy matters on bigger projects.

What the proposal draft bot should (and should not) do

It should:

• Accept discovery notes, call transcripts, or a structured intake form
• Extract goals, audience, must-haves, nice-to-haves, constraints, and success metrics into a brief schema
• Match work to approved packages / SKUs from your rate card (not free-form invention)
• Draft proposal sections: summary, scope, phases, timeline bands, investment, assumptions, out-of-scope, next steps
• Flag missing information instead of guessing
• Stop for human Approve / Edit / Escalate before client send
• Log the opportunity stage in your CRM and attach the draft artifact

It should not:

• Invent line items, discounts, or “special” prices
• Promise launch dates the calendar and capacity plan cannot support
• Auto-email PDFs or DocuSign envelopes without approval
• Quote legal language it cannot cite from your approved template library
• Ignore conflict signals (enterprise compliance asks on a starter package)

If you are still choosing product shape, revisit AI agents vs chatbots vs copilots. This build is a copilot with tools that becomes agentic only after validators pass — and still refuses to send alone.

Architecture

Treat the system as six layers:

1. Intake — Notion/Google Doc paste, Fireflies/Grain transcript, or web form fields from discovery.
2. Extract — LLM maps messy notes into a typed brief (JSON schema). Missing fields become null + questions, not fiction.
3. Package matcher — deterministic rules (and optional embeddings) select 1–3 packages from your catalog.
4. Draft writer — LLM fills your proposal template slots using brief + selected packages only.
5. Validators — price totals must equal package sums; banned phrases blocked; required sections present; confidence thresholds.
6. Human gate + send — Approve/Edit/Escalate UI, then PDF/portal export, email, CRM stage update.

Same discipline as Part 4’s content ops bot and Part 2’s support triage: the model drafts; policy and people commit.

Guardrails checklist (non-negotiable)

• Rate card as source of truth — every price comes from package IDs with versioned amounts.
• No free-form line items unless a human adds them in the edit UI.
• Discount caps — e.g. max 10% requires manager role; above that escalate.
• Timeline bands only — “3–5 weeks” from package config, not “we’ll launch Friday.”
• Assumptions mandatory — hosting, content readiness, stock photos, third-party licenses called out.
• Out-of-scope mandatory — what this package explicitly does not include.
• Conflict detection — enterprise SSO, HIPAA, multi-language, custom ERP — force package upgrade or escalate.
• Currency + tax rules — display currency from config; never invent tax advice.
• Template library only — legal/boilerplate paragraphs from approved snippets.
• PII hygiene — do not paste full payment card data into prompts; redact secrets in logs.
• Idempotent opportunity key — one draft thread per CRM deal ID to avoid duplicate proposals.
• Send lock — API rejects outbound email unless approved_by is set.

Step-by-step build guide

Step 1 — Define your package catalog

Before any prompt work, publish a machine-readable catalog. Example fields per package:

• id, name, service_line (web design, WordPress, Shopify, SEO, AI automation)
• price_min, price_max or fixed price
• timeline_weeks_min, timeline_weeks_max
• includes[], excludes[], assumptions[]
• fit_rules — budget band, page count, integrations, compliance flags
• version — so old drafts stay auditable when prices change

If your website already models packages, align with the Project Builder so marketing and sales quote the same numbers.

Step 2 — Schema the discovery brief

Use a strict JSON schema the extractor must satisfy. Core fields we use:

• Company, contact, industry, timezone
• Primary goal (leads, ecommerce, redesign, automation, white-label delivery)
• Current stack and pain
• Must-have features vs nice-to-haves
• Budget signal (band, not invented number)
• Deadline / event date if any
• Decision makers and success metrics
• unknowns[] — explicit gaps to ask before finalizing

If budget is missing, the bot proposes a discovery follow-up question list — it does not invent a number to “sound complete.”

Step 3 — Match packages with rules first

Prefer deterministic matching:

• If Shopify + catalog > 200 SKUs + subscriptions → ecommerce package tier B+
• If “WordPress migration” + “keep rankings” → include SEO-safe migration add-on from catalog
• If “AI chatbot that books meetings” → link modules from Parts 1 and 5 packages, not a vague “AI fee”
• If compliance keywords fire → block starter SKUs and escalate

Optional: embed package descriptions for semantic ranking, then intersect with hard rules. Never let semantic similarity alone set price.

Step 4 — Draft into a locked template

Give the writer model:

• The structured brief JSON
• The selected package objects (includes, excludes, prices, timelines)
• Approved boilerplate snippet IDs
• Tone guide (clear, commercial, no hype adjectives)

Output slots: Executive summary · Recommended approach · Scope (mapped to includes) · Phases · Investment table · Timeline band · Assumptions · Out of scope · Next steps · Open questions.

Ban phrases like “guaranteed #1 ranking,” “unlimited revisions,” or exact ship dates unless those strings exist in package config.

Step 5 — Validators before the human sees it

• Arithmetic: line items sum to package totals (±0)
• Schema: every required section non-empty
• Policy: regex/deny-list for banned claims
• Coverage: every must-have either in scope or listed under open questions / out-of-scope
• Confidence: if extractor confidence < threshold, force Escalate path

Failed validators return to draft with error codes — they do not “hope the human notices.”

Step 6 — Human Approve / Edit / Escalate UI

Mirror Part 2’s support triage gate:

• Approve — marks approved_by, unlocks send
• Edit — human adjusts scope/price in UI; recalculates totals; re-validates
• Escalate — senior review for custom/enterprise deals

Store a diff of human edits. That dataset trains better extractors later — and proves who changed what if a client disputes scope.

Step 7 — Send + CRM + follow-through

• Export PDF or client portal link from the approved artifact
• Email via your ESP with tracked open (optional)
• CRM: stage → Proposal Sent, attach file, set follow-up task
• Optional WhatsApp nudge only with templates you already use commercially

Connect this to Part 1’s lead bot and Part 5’s booking agent so Hot leads → booked discovery → proposal draft become one pipeline, not three orphan tools.

Pseudo-flow (tool calling)

Illustrative tool sequence (names vary by stack):

1. get_opportunity(deal_id) — CRM context
2. ingest_notes(source, text) — store raw artifact
3. extract_brief(text) → Brief — schema-constrained
4. list_packages(filters) → Package[]
5. match_packages(brief) → MatchResult — rules engine
6. draft_proposal(brief, packages, template_id) → Draft
7. validate_proposal(draft) → ValidationReport
8. request_human_review(draft_id)
9. send_proposal(draft_id) — only if approved
10. update_crm(deal_id, stage, attachments)

The LLM never calls send_proposal directly from a free-form chat turn without the approval flag. Tool permissions enforce that at the API layer.

2-week MVP plan

• Days 1–2 — Package catalog JSON + brief schema + 10 anonymized past proposals labeled with winning package IDs
• Days 3–4 — Extractor prompt + evaluation (field accuracy on the 10 samples)
• Days 5–6 — Rules matcher + investment table renderer (no LLM pricing)
• Days 7–8 — Draft writer into template + validators
• Days 9–10 — Approve/Edit UI for internal users only
• Days 11–12 — CRM attach + PDF export
• Days 13–14 — Shadow mode: bot drafts while humans still write proposals; compare edit distance and win rate

Do not turn on client-facing auto-send in week two. Shadow mode is the product until edit rates drop and validators stay green.

Quality metrics

• Extractor field accuracy — % of brief fields correct vs human gold
• Package match accuracy — % of drafts where the human kept the suggested SKU
• Edit distance — how much humans rewrite before approve
• Validator fail rate — should fall as catalog and prompts improve
• Time-to-proposal — minutes from discovery end to approved send
• Proposal win rate — vs pre-bot baseline (guard against quality drop)
• Pricing incidents — count of wrong prices that reached a client (target: zero)

Common failures

• Prompt-only pricing — “You are a sales expert, invent a fair quote” → commercial liability
• Transcript garbage in, confidence out — no unknowns list; bot hallucinates requirements
• One mega-package for everything — matcher too coarse; humans always override
• Auto-send to impress stakeholders — one bad PDF burns trust forever
• Ignoring capacity — bot proposes 3-week delivery while the studio is fully booked
• Legal copy from the model — always pull from approved snippets
• Orphan tool — no CRM link; sales loses the thread after the PDF leaves Slack

Freelancer vs chatbot agency vs specialist studio

	Solo freelancer	Typical chatbot agency	Let Start Design
Pricing source	Prompt guesswork	Generic “quote bot”	Versioned rate card + validators
Human gate	Optional / informal	Often missing	Approve/Edit/Escalate required
CRM + PDF pipeline	Manual Slack files	Chat transcript only	Deal attach, stages, follow-ups
Website + sales system	Split vendors	Widget bolted on	Site, Project Builder, and agent under one team
Big-project capacity	Single point of failure	Juniors on “AI sales”	Structured build, QA, launch support
Commercial clarity	Hourly surprises	Opaque bot retainers	Scope via Project Builder + fixed proposals
Best for	Toy demos	FAQ bots that never quote	Studios where wrong quotes cost real revenue

How Let Start Design stands out

1) Agents with product discipline

We ship proposal copilots the same way we ship booking and support bots: schemas, tools, tests, and human gates — not a personality prompt. See what clients should expect from an AI website agency in 2026.

2) Rate card alignment with the site

Our Project Builder already models packages clients explore publicly. Proposal bots should speak the same commercial language — we connect marketing estimates to sales drafts so numbers do not drift.

3) Guardrails before eloquence

A beautiful proposal with a wrong total is worse than a plain one that is correct. Validators and approval locks ship before tone polishing.

4) End-to-end funnel, not orphan widgets

We wire qualification → booking → discovery → proposal into one delivery when you need it — often alongside AI website development so the site and the sales agent share data models.

5) Capacity agencies can white-label

Partners can offer proposal automation under their brand through our white-label program — useful when clients ask for “AI sales ops” and you need a studio that still answers in week eight.

6) Portfolio proof, not slideware

Browse the portfolio. We finish production systems — including messy AI starts — instead of abandoning demos when real pricing hits.

Key takeaways

• Rate cards and package IDs are the source of truth; LLMs extract briefs and write prose into locked templates.
• Validators + Approve/Edit/Escalate prevent commercial hallucinations from reaching clients.
• Connect this bot to lead qualification and booking so discovery notes do not die in Notion.
• Measure extractor accuracy, edit distance, time-to-proposal, win rate, and pricing incidents.
• For bigger projects, hire a studio with integration capacity — Let Start Design combines agent engineering, website conversion, pricing clarity, and partner delivery.

Want a discovery → proposal pipeline that protects your margins? Talk to Let Start Design, explore AI website development, or model related site scope in the Project Builder.

Series: Part 1 — Lead qualification · Part 2 — Support triage · Part 3 — Shopify order status · Part 4 — Content ops · Part 5 — Appointment booking · Part 6 — Discovery → proposal draft

Related: Agents vs chatbots vs copilots · White label in the age of AI · AI-agent ready websites

Sources: Structured outputs; Tool / function calling; JSON Schema.