Use checked discovery notes to define the problem, proposed deliverables, dependencies, and acceptance criteria. Ask the client to confirm material assumptions before treating the proposal as an approved work plan.
In this guide
What should the proposal retain from the meeting transcript?
The source is meeting-transcript-practice.md, whose T-prefixed IDs differ from project-notes-example.md and its N-prefixed IDs. Do not mix the Friday condition into the N-note project, which has no agreed draft due date. The sample is a proposal outline rather than a legal contract; pricing and binding terms must come from your own authorized business process.
| Proposal section | Practice wording | Transcript evidence |
|---|---|---|
| Initial deliverable | One-page onboarding checklist covering account setup and support contact. | T01, T07 |
| Draft timing | Maya can draft by Friday if access returns Wednesday; confirm calendar dates. | T02 |
| Client decision | Please identify the person who approves the final version. | T08 |
| Optional work | A welcome video can be discussed separately; it is outside the initial scope. | T05 |
Collect the facts that a proposal needs
Keep the client's stated problem, desired outcome, approved constraints, participants, source notes, and unresolved decisions. Distinguish a person's request from an agreement by the authorized client owner. A suggestion during brainstorming may belong in an options section instead of the base scope.
Add the commercial terms your business has actually approved, or leave them for the responsible person to complete. AI should not infer a fee, guarantee, delivery date, or acceptance condition because the document format usually contains one. Use your own contracting and review process for the final agreement.
- State the client's problem and the proposed outcome, with their source notes.
- Define each deliverable and the criteria a reviewer can use to assess it.
- List inputs, access, approvals, and other dependencies required from each party.
- Keep optional ideas and unresolved assumptions in labeled sections.
- Build a tentative sequence from the dependencies and supplied availability rather than inventing dates.
- Review the proposal with the responsible owner, then ask the client to confirm the specific outstanding decisions.
Does every section keep the same commitment?
Compare the summary, deliverable table, timeline, and closing call to action. A condition stated in one section can disappear in another and create a misleading promise. Keep the proposed work and confirmed work distinguishable throughout.
Review the client's change requests against the same scope map. If a revision adds work or moves a dependency, ask the responsible owner to assess its effect before updating a delivery commitment. Save the approved version and the client's responses together.
Request a proposal with traceable assumptions
Draft a proposal outline from REVIEWED DISCOVERY NOTES: [IDs + passages]. CLIENT PROBLEM AND CONFIRMED SCOPE: [state] APPROVED COMMERCIAL TERMS: [supplied terms or pending] DEPENDENCIES, OPTIONS, AND OPEN QUESTIONS: [list] Return problem, proposed deliverables, acceptance criteria, dependency-based sequence, options, and client confirmation questions. Attach source IDs to scope statements. Keep missing fees, dates, and approvals pending. Do not turn a suggestion into an agreed deliverable or remove a prerequisite to make the proposal sound decisive.
Hand over an approved scope, not a prettier transcript
The team should receive the confirmed deliverables, acceptance criteria, dependencies, and remaining questions as a working handoff. Keep the discovery evidence available for later scope discussions while presenting the client with a clear, concise proposal.