How to Turn Discovery Call Notes Into a Proposal Scope With AI
Summary
- Start by converting raw discovery notes into a structured “source of truth” (goals, constraints, scope candidates, risks, decisions, open questions).
- Use AI to extract scope items and rewrite them into proposal-ready statements with clear boundaries, assumptions, and acceptance criteria.
- Produce a scope section that is easy to sign: in-scope, out-of-scope, deliverables, timeline approach, responsibilities, and change control.
- Run review checks that catch the common failure modes: vague deliverables, missing exclusions, unowned dependencies, and misaligned success metrics.
- Use a repeatable prompt set: one for extraction, one for scope drafting, one for risk/assumption surfacing, and one for final QA.
Discovery calls generate messy, high-signal notes: half-finished sentences, “we should” ideas, constraints mentioned once, and decisions buried in side comments. A proposal scope needs the opposite: crisp deliverables, boundaries, assumptions, responsibilities, and a way to handle changes.
This guide shows a practical, AI-assisted workflow to turn discovery call notes into a proposal scope. You’ll see (1) example inputs (labeled as invented), (2) prompts you can reuse, (3) a proposal scope output structure you can paste into your template, and (4) review checks to reduce misunderstandings before you send the proposal.
What “proposal scope” needs that discovery notes don’t
Discovery notes capture what was said. A proposal scope captures what will be delivered and under what conditions. The gap is where proposals go wrong.
Discovery notes are usually:
- Unstructured (topics jump around).
- Ambiguous (“improve onboarding,” “clean up reporting”).
- Missing boundaries (what’s excluded, what’s a later phase).
- Missing ownership (who provides data, who approves, who implements).
- Missing acceptance criteria (how you’ll know it’s done).
A proposal scope should include:
- In-scope deliverables written as outcomes and artifacts.
- Out-of-scope exclusions to prevent assumption creep.
- Assumptions that must be true for the plan to work.
- Dependencies and responsibilities (client vs. provider).
- Acceptance criteria (what “done” means).
- Change control (how new requests are handled).
Step 1: Prepare your notes so AI can reliably extract scope
AI performs better when the input is clearly labeled and complete. You do not need perfect notes, but you do need a consistent wrapper.
Minimum input package
- Call context: client name, date, attendees, call purpose.
- Raw notes: paste as-is.
- Any artifacts mentioned: links, screenshots, existing docs (if you have them).
- Your interpretation (optional): “My read is…” for anything you suspect is important but unclear.
Example input (invented)
INVENTED EXAMPLE: Discovery call notes (raw)
- Goal: reduce time to onboard new customers; current onboarding is “too manual.”
- They use HubSpot + internal admin tool; want fewer handoffs.
- Need: onboarding checklist, email sequences, and a dashboard for onboarding status.
- Constraints: legal review required for emails; brand team must approve templates.
- Timeline: “ideally in 6 weeks” because next cohort starts.
- Data: onboarding status currently tracked in spreadsheets; some fields missing.
- Success: “cut onboarding time from ~14 days to under 7” (not sure baseline is accurate).
- Out of scope? They asked about billing automation too, but sounded like later.
- Stakeholders: Ops lead (owner), Marketing (emails), Legal (review), Sales (handoff).
- Risks: internal tool has limited API; they’re not sure what’s possible.
Step 2: Use AI to extract “scope candidates” (not final scope yet)
Your first AI pass should not draft the proposal. It should convert messy notes into a structured map: goals, constraints, decisions, unknowns, and a list of candidate deliverables. This reduces the chance that the model “fills in” missing details.
Prompt 1: Extraction into a structured brief
Copy/paste prompt (edit bracketed parts):
Task: Convert the discovery call notes into a structured scope brief for proposal drafting.
Input: I will paste raw notes. Do not invent details. If something is unclear, list it as an open question.
Output format:
1) Business goals (ranked)
2) Current state summary
3) Constraints (legal, brand, technical, timeline)
4) Stakeholders and responsibilities (if stated)
5) Scope candidates (deliverables/features/workstreams) with short descriptions
6) Risks and unknowns
7) Assumptions implied by the notes
8) Open questions to confirm before finalizing scope
Raw notes:
[PASTE NOTES HERE]
What you’re looking for in the extraction output
- Deliverables separated from goals (goal: “reduce onboarding time”; deliverable: “onboarding status dashboard”).
- Constraints captured as constraints, not ignored (legal/brand approvals become timeline and dependency items).
- Unknowns surfaced explicitly (baseline metrics, API limits, data completeness).
Step 3: Turn scope candidates into proposal-ready scope statements
Now you draft the scope section. The key is to force specificity: each deliverable should have boundaries and acceptance criteria. If you skip this, the proposal reads well but fails during delivery.
Prompt 2: Draft the scope section with boundaries and acceptance criteria
Copy/paste prompt (edit bracketed parts):
Task: Draft a proposal scope section from the structured brief below.
Rules: Do not add new deliverables not supported by the brief. Use clear “In scope / Out of scope” boundaries. Include assumptions, dependencies, and acceptance criteria for each deliverable. If a detail is missing, write a bracketed placeholder like [TBD] and list it in “Open questions.”
Output sections:
A) Scope overview (2-4 sentences)
B) In-scope deliverables (bulleted; each includes: description, boundaries, acceptance criteria)
C) Out of scope (explicit exclusions)
D) Assumptions
E) Client responsibilities / inputs required
F) Timeline approach (phases; no dates unless provided)
G) Change control (how scope changes are handled)
H) Open questions
Structured brief:
[PASTE THE EXTRACTION OUTPUT HERE]
Example output structure (invented)
INVENTED EXAMPLE: Proposal scope (excerpt)
A) Scope overview
This project will redesign and operationalize the customer onboarding workflow to reduce manual handoffs and improve visibility into onboarding status. The scope focuses on checklist-driven onboarding, email communications (subject to legal/brand review), and a status dashboard using the client’s existing tools where feasible.
B) In-scope deliverables
-
Deliverable 1: Onboarding workflow map and checklist design
Description: Document the current onboarding steps and design a standardized checklist with owners and handoff points.
Boundaries: Covers onboarding from “deal closed” to “customer live” as defined by [TBD definition]. Does not include billing automation.
Acceptance criteria: Checklist includes step name, owner, required inputs, and completion definition for each step; reviewed and approved by Ops lead. -
Deliverable 2: Email sequence drafts for onboarding communications
Description: Draft onboarding email templates and sequence logic aligned to the checklist milestones.
Boundaries: Copy and structure included; final legal/brand approval is required before sending. Translation/localization not included unless added.
Acceptance criteria: Templates delivered in an editable format; includes subject lines, body copy, and trigger conditions; Marketing and Legal provide written approval or feedback within [TBD timeframe]. -
Deliverable 3: Onboarding status dashboard specification (and implementation approach)
Description: Define the dashboard fields, data sources, and reporting views needed to track onboarding progress.
Boundaries: Implementation depends on internal tool/API feasibility; if API access is limited, deliverable becomes a manual or semi-manual reporting workflow proposal.
Acceptance criteria: Dashboard spec includes field definitions, source-of-truth system per field, and sample views; feasibility confirmed with technical owner.
C) Out of scope
- Billing automation and invoicing workflow changes.
- Net-new CRM migration.
- Custom engineering beyond agreed integration feasibility.
D) Assumptions
- Client provides access to HubSpot and the internal admin tool (or equivalent exports) within [TBD].
- Legal and brand reviewers are available to review email templates within the project timeline.
- Baseline onboarding duration and definition of “onboarded” will be confirmed in week 1.
E) Client responsibilities / inputs required
- Provide current onboarding spreadsheet(s) and definitions for each status field.
- Assign an Ops owner for approvals and decision-making.
- Confirm technical constraints (API availability, permissions, data access).
F) Timeline approach
- Phase 1: Discovery validation and baseline confirmation
- Phase 2: Checklist + email drafts
- Phase 3: Dashboard spec + feasibility decision
- Phase 4: Final revisions and handoff
G) Change control
Requests outside the “In-scope deliverables” will be documented as change requests. Each change request will include impact on timeline, dependencies, and effort, and will require written approval before work begins.
H) Open questions
- What is the agreed definition of “onboarded” and the baseline onboarding duration?
- What API access exists for the internal admin tool, and who can confirm it?
- Who are the approvers for email templates, and what is the review SLA?
Step 4: Add the missing pieces AI will not reliably infer
Even with good prompts, there are scope elements that require your judgment. Use AI to surface gaps, then you decide what to include.
Common “missing pieces” to add deliberately
- Definitions: What does “launch,” “live,” “onboarded,” or “done” mean in this client’s context?
- Decision points: Where do you need a go/no-go (e.g., “If API access is limited, we deliver a spec + workaround instead of a build”)?
- Ownership: Who signs off on what, and by when?
- Inputs: Access, data exports, brand guidelines, legal constraints, existing templates.
Step 5: Run review checks before sending the proposal
Use these checks as a final QA pass. You can do them manually or ask AI to evaluate your draft against them.
Scope clarity checks (fast, practical)
- Deliverable test: Can each deliverable be handed to someone and verified without interpretation?
- Boundary test: Does each deliverable say what it does not include?
- Dependency test: Are client inputs and approvals explicitly listed?
- Acceptance test: Is “done” defined (approval, artifact delivered, system behavior confirmed)?
- Timeline realism test: Do constraints (legal/brand review) appear in the timeline approach?
- Risk test: Are technical unknowns framed as risks with mitigation or decision points?
- Change test: Is there a clear process for new requests?
Prompt 3: AI-based scope QA (red-team your draft)
Copy/paste prompt:
Task: Review the proposal scope draft below for ambiguity, missing exclusions, unowned dependencies, and weak acceptance criteria.
Rules: Do not rewrite the whole scope. Provide a punch-list of issues and suggested edits. Flag any statement that could be interpreted in multiple ways.
Output format:
1) Ambiguities (quote the line + why it’s ambiguous + suggested fix)
2) Missing out-of-scope items (based on what’s implied)
3) Missing assumptions/dependencies (what must be true, who must do what)
4) Acceptance criteria gaps (what can’t be verified)
5) Risk/unknowns not reflected in scope
Scope draft:
[PASTE YOUR SCOPE HERE]
Practical patterns for turning notes into strong scope language
These patterns help you translate conversational statements into proposal-ready scope without adding unagreed work.
Pattern 1: Convert goals into measurable outcomes (without inventing numbers)
- Notes: “Reduce onboarding time.”
- Scope language: “Define baseline onboarding duration and target metric with the client in Phase 1; design workflow changes intended to reduce manual steps and handoffs.”
Pattern 2: Convert “we should” ideas into options or phases
- Notes: “Maybe add billing automation too.”
- Scope language: “Billing automation is out of scope for this phase; we can provide a separate estimate upon request.”
Pattern 3: Convert constraints into dependencies and timeline gates
- Notes: “Legal must approve emails.”
- Scope language: “Email templates require legal approval; timeline assumes legal feedback within [TBD] business days per review round.”
Pattern 4: Convert technical uncertainty into a decision point
- Notes: “Internal tool API might be limited.”
- Scope language: “Deliver dashboard specification and feasibility assessment; implementation approach depends on confirmed API capabilities.”
Deliverable: A reusable proposal scope template (copy/paste)
Use this structure as your default output target when converting discovery notes into a proposal scope.
Proposal Scope Template
- Scope overview: What this project will accomplish and for whom.
- In-scope deliverables:
- Deliverable name
- Description (what you will produce/do)
- Boundaries (what’s included/excluded)
- Acceptance criteria (how it’s verified)
- Out of scope: Explicit exclusions and “not in this phase” items.
- Assumptions: Conditions that must hold true.
- Dependencies and client responsibilities: Access, data, approvals, SMEs, tools.
- Timeline approach: Phases and gates; avoid dates unless confirmed.
- Risks and mitigations: What could derail scope and how you’ll handle it.
- Change control: How new requests are evaluated and approved.
- Open questions: Items to confirm before finalizing.
Frequently Asked Questions
FAQ 1: What should I ask AI to do first: summarize the call or draft the scope?
Answer: Start with extraction into a structured brief (goals, constraints, stakeholders, scope candidates, risks, assumptions, open questions). Then draft the scope from that brief. This two-step flow reduces the chance that the draft scope includes details that were never stated.
Takeaway: Use AI to structure the notes first, then write scope from the structure.
FAQ 2: How do I prevent AI from inventing deliverables that were not discussed?
Answer: Put explicit rules in the prompt: “Do not invent details; if unclear, list as an open question; use [TBD] placeholders.” Also separate “scope candidates” from “final in-scope deliverables” so you can approve what makes it into the proposal.
Takeaway: Constrain the model with rules and a staged workflow.
FAQ 3: What is the minimum information a scope deliverable needs to be proposal-ready?
Answer: At minimum: (1) a clear description of what you will produce, (2) boundaries (what is included and excluded), (3) acceptance criteria (how it will be verified), and (4) dependencies or client inputs required. Without these, the deliverable can be interpreted multiple ways.
Takeaway: Description + boundaries + acceptance criteria + dependencies is the baseline.
FAQ 4: How do I turn vague goals (like “improve onboarding”) into scope without making promises?
Answer: Convert the goal into a scoped approach: define baseline and success metrics in Phase 1, deliver specific workflow artifacts (checklists, templates, dashboard spec), and state what you will validate versus what you will implement. Avoid committing to numeric outcomes unless the baseline and levers are confirmed.
Takeaway: Scope the work you control, and validate metrics before committing to targets.
FAQ 5: How do I write out-of-scope items without sounding unhelpful?
Answer: Tie exclusions to focus and sequencing: “Out of scope for this phase” plus an option like “can be estimated separately” or “can be considered in a later phase.” Keep it specific (billing automation, migration, custom engineering) rather than vague (“anything else”).
Takeaway: Use out-of-scope to clarify sequencing, not to shut down requests.
FAQ 6: How should I handle technical unknowns (APIs, data quality) in the scope?
Answer: Turn unknowns into explicit risks, assumptions, and decision points. For example: “Deliver dashboard specification and feasibility assessment; implementation depends on confirmed API capabilities.” This keeps the proposal honest while still moving the project forward.
Takeaway: Don’t hide unknowns; scope them as validation steps and gates.
FAQ 7: What review checks catch the most common scope problems before sending a proposal?
Answer: Run a deliverable test (verifiable artifacts), boundary test (explicit exclusions), dependency test (client inputs and approvals), acceptance test (clear “done”), and change test (how new requests are handled). These checks catch ambiguity and unowned work that can derail delivery.
Takeaway: A short QA checklist can prevent scope misunderstandings.
FAQ 8: Can AI generate acceptance criteria, or should I write them myself?
Answer: AI can draft acceptance criteria as a starting point, but you should review them for measurability and ownership. Good acceptance criteria match the deliverable type (document approved, templates delivered, feasibility confirmed, workflow implemented) and reflect real constraints like legal review or data availability.
Takeaway: Let AI draft; you finalize acceptance criteria based on real delivery conditions.