SOW Drafter from Discovery Transcript

The job is to fill your statement of work from a discovery transcript: deliverables, exclusions, assumptions, and client responsibilities. It is not to emit an executable contract.

After a long call, nobody should rebuild scope from memory and Slack notes. The cost of that speed is a draft that looks complete and is still a guess. Treat it as extraction until someone who was on the call, or owns the commercial relationship, signs off.

Meeting recorders such as Gong, Fireflies, and Otter produce the transcript. Drafting happens in Word Copilot or a custom GPT constrained to the firm's SOW template. A contract lifecycle system such as Ironclad is where the final SOW may live for review, versioning, and signature. It is not the drafter. File a guessed scope there and it becomes the record.

This is not a RAG proposal draft generator. That use case retrieves past proposals to answer an RFP. This one reads this call. Mixing them is how last year's deliverables for another client appear under a new name.

Settle recording consent before the call, and refuse to draft from a transcript you cannot quote.

Some clients prohibit recording. Some allow it only with named attendees. Some require a basis in the master agreement before a recorder joins. If you cannot record, this use case does not run. Write the SOW from notes. Do not paste a secret recording into a model.

Transcript quality sets the ceiling. A draft SOW from a messy discovery call will be messier than the call. Unlabeled speakers, talk-over on the out-of-scope sentence, twenty minutes of small talk and a rushed "we will also" at the end: the model will still emit tidy numbered lists. Tidy is not accurate.

A usable transcript needs speaker labels you trust, enough concrete language to fill a deliverable (artifacts, workshops, reviews, timeboxes), and a pass over speech-to-text errors on numbers, system names, sites, and legal entities. "We want to transform operations" is not a scope. If the call never named work, do not run the drafter.

Force the model to fill your sections. Do not let it invent a table of contents.

Your template already has the schema: background, objectives, in-scope, out of scope, assumptions, client responsibilities, dependencies, timeline shape, acceptance. Freeform memos omit exclusions, bury assumptions in prose, and add workstreams that usually show up in this kind of job.

Extract and place:

• In-scope: only what someone asked for, with a quote or timestamp when you can.
• Out of scope: what someone declined, plus standing firm exclusions for this offer type, labeled said on the call versus firm standard.
• Assumptions: explicit sentences, not implied conditions inside a deliverable.
• Client responsibilities: named actions (data access, workshop attendance, a single point of contact).

Leave hours, fees, rate cards, and liability language out of the generated draft.

If you need to see how this firm writes a diagnostic, use a comparable past scope retriever. Do not paste that past SOW in as if it were this client's agreement.

The useful draft lists paper deliverables, the VP's exclusions, and the huddle as an open item, not as invented or dropped work.

This is an illustrative scenario, not a case study.

A proposal lead and an engagement manager run a 45-minute discovery with the VP of Operations and a plant manager at a mid-market manufacturer. The ask is an eight-week operating-model diagnostic: current-state assessment, a target operating model on paper, and a 90-day roadmap. The VP does not want implementation, system selection, or a PMO stood up. Near the end the plant manager adds, "we will also need you to sit in on the weekly ops huddle for a couple of months so this does not die."

The transcript is typical: overlapping talk, a garbled ERP name, and no restatement of the huddle as a deliverable.

What a constrained draft should hold

Mapped to the firm's diagnostic template:

• Deliverables: current-state assessment (interviews plus a sample of existing reports), target operating model document, 90-day roadmap, a readout with the VP.
• Exclusions, from the call: implementation, system selection, standing up a PMO.
• Exclusions, firm standard: software licenses; running the weekly meeting as an ongoing service unless separately scoped.
• Assumptions: access to the plant manager and a named ops analyst; a single site; advisory only.
• Open item, quoted: plant manager, late call: sit in on the weekly ops huddle "for a couple of months."

That last line is the point. It is not yet in or out of scope. It becomes a deliverable, an exclusion, or a paid extension. The draft should surface it, not decide it quietly.

What the unconstrained model will do instead

Left to write a professional SOW, the same transcript often makes two errors in one document.

It invents deliverables the client never asked for: change-management, town halls, a RACI for every forum, a quick-win implementation sprint, because those sections exist in other diagnostics. The VP asked for paper: assessment, target model, roadmap, readout. Town halls were never on the table.

It misses the verbal "we will also." The huddle request is informal, late, and unrepeated. Models that extract agreed scope from clean language skip asides. Two months of weekly attendance is real delivery. Leave it out and the client still expects it. Silently add it as in-scope and you have staffed an eight-week diagnostic as an embedded operating cadence.

The partner who was on the call should mark both in one pass: strike the invented workstream, and force a decision on the huddle.

A named reviewer (engagement manager or partner) reads every exclusion and every in-scope line against the transcript before the draft leaves the team.

Exclusions are where disputes start. The model will under-exclude (the client said no implementation, the draft still lists standing up new forums) and over-exclude (a standing exclusion that contradicts the call). Both are commercial positions. Confirm the exclusions section line by line.

Review checklist:

1. Invented work. Any deliverable with no supporting utterance is deleted or moved to "optional, not discussed."
2. Missed add-ons. Search for "also," "as well," "while you're here," "we will need you to," and timeboxed ongoing attendance. If the draft is silent, add an open item.
3. Exclusions vs. asides. Every "we don't want" becomes an exclusion or a recorded disagreement. Every "we will also" becomes in-scope, out-of-scope, or an open commercial question.
4. Named entities. Fix legal names, sites, systems, and dates. Speech-to-text will get them wrong.
5. Assumptions vs. commitments. Data extracts by week two, if never promised, are an assumption to confirm, not an agreed client responsibility.

Then run the draft through an assumption gap detector so unstated conditions (single site, advisory-only, data quality, who chairs the huddle) are explicit. Ambiguous leftovers can go through a scope risk classifier. Neither replaces the exclusion review.

Keep effort, price, and the executable contract off this path.

Transcripts are a bad source of hours. People say "this should be quick" and "we need you through the quarter" in the same breath. Staffing and fees come from effort estimation from historical actuals against a cleaned scope, not from optimism on the call.

Once a human has locked deliverables, exclusions, and assumptions, the commercial partner prices the work. Legal puts the agreed scope into the firm's contract template. If you use a contract lifecycle system such as Ironclad, that is when the document becomes the record: versioned, routed, signed. The model does not write indemnity, limitation of liability, or payment terms. If they appeared in a generated draft, strip them.

The system is working when the day after discovery you have a structured first cut, quote-backed open items, and a partner still decides what you will and will not do. It is failing when a tidy SOW ships a deliverable nobody asked for, or omits the huddle the plant manager thought they had bought.