name: scope-to-sow-converter description: > Turn a prospect conversation into a scoped, sendable proposal in minutes. Paste call notes, email threads, or voice transcripts — get back: what they need, what to propose, the actual SOW ready to send, and the scope creep risks to watch before the engagement starts. The proposal that usually takes a weekend now takes a conversation and a paste. Triggers: "scope to sow", "write a proposal", "SOW", "statement of work", "proposal", "scope this", "turn this into a proposal", "prospect conversation", "write the SOW", or any request to convert a prospect conversation into a scoped proposal. metadata: author: Kathryn Brown, Advisory OS version: "1.2.0" updated: "2026-04-16"

Scope-to-SOW Converter

Turn a prospect conversation into a scoped proposal you can send today. Paste the conversation, get the SOW.

Core Principle

Speed closes deals. Delay kills them. A great discovery call on Tuesday becomes a stale email thread by Friday when the proposal takes a week to write. Practice owners don't lose deals to competitors — they lose them to their own proposal delay. This skill eliminates the gap between "good conversation" and "proposal sent."

What This Skill Does

Setup (30 seconds). Before pasting the conversation, answer two questions. The skill needs these because your pricing, services, and relationship history can't be extracted from the prospect's words — only yours.

1. What does your practice do, and what do you typically charge? (e.g., "Operations consulting for accounting firms. Retainers $2-5K/mo, projects $3-10K." or "Fractional CFO services. $1,500/mo for growing firms, $3-5K for complex." or "Wealth management coaching. $500/session or $2K/mo advisory.")

1. Is this a new prospect or an existing/returning client? If returning, what have they paid you for previously? (e.g., "New prospect, first conversation." or "Returning — she did a $500 blueprint session in January and a 2-month consulting engagement after that, ~$3,500 total.")

If you skip Question 1, the skill produces the SOW with a pricing placeholder. If you skip Question 2, the skill treats the conversation as a first contact — the SOW tone will be neutral rather than warm.

Then paste the conversation. Email thread, call notes, voice memo transcript, text messages, Zoom chat — anything that captures what the prospect said and what they need. Messy is fine. Partial is fine. The skill extracts what's there and flags what's missing.

The skill reads the input and produces a proposal package that does 3 jobs:

Job 1: Conversation Read — What the prospect actually said they need, in their words. Not your interpretation. Their problem, their desired outcome, where they are on the urgency ladder (crisis, active problem, growth mode, or vision stage), and every budget signal in the conversation. This is the raw intelligence the SOW is built on — and the mirror that shows you whether you heard them correctly.

Job 2: The SOW — A complete, formatted, ready-to-send proposal. Opening context that uses the prospect's own language. Phased deliverables scoped to what they said, not what you wish they'd said. Investment tied to the problem, not a rate card. One clear next step. The document you'd normally spend 2-4 hours writing — built from the conversation in minutes.

Job 3: Scope Protection — The internal playbook for this engagement. Top scope creep risks for this type of work, the boundary language for each, and a clear test for when to re-scope vs. absorb. This is the section that saves you money 3 months into the engagement. Not in the proposal itself — this is for you.

The Proposal Package: Section by Section

1. Conversation Extract

The skill's read of what the prospect said. This section exists so you can verify the skill heard the conversation correctly before trusting the SOW it produces.

4 extractions:

The Urgency Ladder:

2. Service Recommendation

Based on the conversation extract, what to propose.

3. Scope Definition

What's in and what's out. This is the backbone of the SOW — get this wrong and the engagement starts with ambiguity.

What's Included:

A numbered list of deliverables. Each one gets:

• Deliverable name — specific enough to be verifiable ("Onboarding process document" not "onboarding support")
• What it contains — one line describing what the client receives
• Completion criteria — how both sides know it's done ("Delivered when client confirms the process covers all current roles")

Extract deliverables from what the prospect described needing. If they said "I need help with onboarding and maybe some process documentation," that's two deliverables, not one bundled engagement.

What's Not Included:

3-5 items that a reasonable person might assume are included but aren't. This is where scope protection starts — in the proposal itself.

Rules for exclusions:

• Each exclusion must be plausible. "Nuclear reactor design" is not a useful exclusion. "Ongoing revisions after final delivery" is.
• Frame exclusions as clarity, not limitation. "This engagement covers the onboarding process build. Ongoing training for new hires using the process is available as a separate engagement."
• If the conversation hinted at adjacent needs beyond the core ask, name them as exclusions with a note: "This came up in our conversation and is worth addressing — I'd recommend tackling it after [the core deliverable] is in place."

4. The SOW

The actual proposal document. Formatted, ready to copy into an email or attach as a PDF. This is what the prospect sees.

Structure:

[Provider Name] — Statement of Work Prepared for: [Prospect name/company, from conversation] Date: [Today's date]

Where We Are

2-3 sentences using the prospect's own language. Reference what they said, the problem they named, and what prompted this conversation. The prospect should read this and think "they were actually listening."

Do not start with your credentials, your services, or your methodology. Start with their situation.

What I Recommend

The deliverables from Section 3, organized into phases if the engagement has a natural sequence. If it's a single-phase project, no phases needed — just the deliverable list.

For phased engagements:

For single-phase:

Deliverables:

1. [Deliverable] — [one line]
2. [Deliverable] — [one line]

How We'll Work

3-4 lines. Meeting cadence, communication channel, what you need from them, expected time commitment on their side. Be specific: "2 60-minute working sessions per week via Zoom. You'll need 30 minutes of prep before each session — I'll send you exactly what to prepare."

Investment

One number. Not a range (ranges make people pick the bottom), not options (options create decision paralysis), not hourly rates (hourly rates invite scope math). One number tied to the outcome they described.

Format:

• Investment: $[amount]
• Includes: [one-line summary of what's covered]
• Timeline: [start to finish]
• Terms: [payment structure — e.g., "50% to start, 50% at completion" or "$X/month for Y months"]

If the setup question provided pricing: use it, calibrated to the scope. If no pricing was provided: write "[YOUR INVESTMENT]" and add a note in the Confidence Check that pricing needs to be set.

Tie the investment to the problem, not the service. Not "Operations consulting, $3,000/month." Instead: "Investment for the complete onboarding system build, including process documentation, team training materials, and two rounds of revision: $4,500."

What's Not Included

Pull directly from Section 3's exclusion list. One sentence each. Keep it factual, not defensive.

Next Step

One clear action. Not "let me know what you think" — that's a dead end. A specific next step with a specific mechanism.

Examples:

• "If this looks right, reply 'go' and I'll send the scheduling link for our kickoff session."
• "I'll hold the week of April 14 for our kickoff. Confirm by Friday and I'll send the prep materials."
• "Reply with any questions. If the scope looks right, I'll send a payment link and we start [date]."

5. Scope Protection Notes

Internal — do not include in the proposal.

For this type of engagement, the 3 most common ways scope creeps:

Rules for scope protection notes:

• Each creep risk must be specific to this engagement type, not generic. "Client asks for more" is not useful. "Client asks you to also train the team on the new process — which wasn't scoped" is useful.
• Boundary language must be ready to say out loud. "That's a great idea — it's outside the current scope. I can add it as a Phase 2 deliverable, or I can show your team how to do it themselves in our next session."
• The re-scope vs. absorb test prevents over-policing and under-protecting. Small, one-time asks get absorbed gracefully. Recurring or large asks get re-scoped professionally.

6. Confidence Check

What the skill is confident about and what needs verification before sending.

If any element is Low confidence: The skill adds a specific instruction — what to ask or verify, and who to ask. "Call the prospect and confirm budget range before sending. The conversation didn't surface any pricing signals."

If all elements are High: "This SOW is ready to send. Review the language, confirm it sounds like you, and send it today."

Quality Check (Internal — never shown to the user)

This section is an internal gate. Run it silently before presenting. Use it to correct the proposal package. Do not include the Quality Check in the output.

The Confidence Check (Section 6) IS user-facing — it tells the user what to verify before sending. Keep it in the output. This Quality Check is different — it verifies output quality internally and is never shown.

Before presenting, verify internally against five checks:

Enforcement rules:

1. Failed checks: If any element fails, fix it before presenting. The output contains only the corrected version — no flag, no note.

1. Weakest element: Identify internally the weakest part of the proposal package and rewrite it before presenting. Verify the rewrite internally.

What the user sees: The Conversation Extract, Service Recommendation, Scope Definition, the SOW, Scope Protection Notes, and Confidence Check. No Quality Check section.

Rules

• No dollar amounts without basis. If the user provided pricing in the setup question, use it calibrated to scope. If the conversation contained budget signals, use those. If neither exists, use a placeholder and flag it. Never fabricate pricing.
• No paragraphs in sections 1-3 or 5-6. Tables, checklists, label/value pairs. Section 4 (the SOW itself) uses short paragraphs — it's a document the prospect reads.
• One prospect per SOW. Don't mix conversations from multiple prospects.
• Prospect's words first. The Opening Context section must start with the prospect's language, not the provider's service description. If the skill can't find prospect language to open with, it flags this in the Confidence Check.
• Deliverables must be verifiable. "Help with operations" is not a deliverable. "Operations process audit covering hiring, onboarding, and monthly close — delivered as a documented playbook" is a deliverable.
• Exclusions must be plausible. Only list things a reasonable person would assume might be included. Don't pad the list.
• Scope Protection Notes are never client-facing. They exist to protect the provider. Never include them in the SOW output.
• The SOW must be sendable. Copy-paste into an email or export as a PDF. No brackets to fill in (except pricing placeholder if no pricing data exists). No "[insert client name]" — use whatever names appear in the conversation. If no names appear, use the identifier the user provides.
• Messy input is fine. Misspellings, incomplete sentences, voice-to-text artifacts, mixed email threads — the skill extracts what's there and flags what's missing. Never refuse to produce a SOW because the input was messy.
• Partial input produces partial SOWs. If the conversation is thin, the SOW will have gaps — and the Confidence Check will name every one. A partial SOW with flagged gaps is still more useful than a blank page.
• Output as a markdown file. Name the file: [prospect-name]-sow-[YYYY-MM-DD].md

Output Format

# Statement of Work

| | |
|---|---|
| **Prospect** | [Name or identifier] |
| **Date** | [Today's date] |
| **Based on** | [Conversation type — "Discovery call notes, March 28" or "Email thread, 4 messages, March 20-27"] |
| **Your practice** | [Summary from setup question] |

---

## Conversation Extract

| | |
|---|---|
| **Problem stated** | [Prospect's words] |
| **Outcome desired** | [Prospect's words] |
| **Urgency level** | [Crisis / Active Problem / Growth / Vision] — [one-line evidence] |
| **Budget signals** | [What was said or "None detected — pricing will need manual input"] |

---

## Service Recommendation

| | |
|---|---|
| **Service type** | [DFY / Advisory / DWY / Retainer] |
| **Tier** | [Diagnostic / Project / Continuity] |
| **Why** | [1-2 sentences connecting to conversation] |

---

## Scope Definition

**Included:**
1. **[Deliverable]** — [contents]. Done when: [completion criteria].
2. **[Deliverable]** — [contents]. Done when: [completion criteria].
3. **[Deliverable]** — [contents]. Done when: [completion criteria].

**Not included:**
- [Exclusion] — [one sentence framing]
- [Exclusion] — [one sentence framing]
- [Exclusion] — [one sentence framing]

---

## The SOW

[Full proposal document — ready to send. See Section 4 structure above.]

---

## Scope Protection Notes (Internal)

| # | Creep Risk | What It Looks Like | Boundary Language | Re-scope or Absorb? |
|---|-----------|-------------------|-------------------|---------------------|
| 1 | [Risk] | [Pattern] | [Language] | [Decision + test] |
| 2 | [Risk] | [Pattern] | [Language] | [Decision + test] |
| 3 | [Risk] | [Pattern] | [Language] | [Decision + test] |

---

## Confidence Check

| Element | Confidence | Note |
|---------|-----------|------|
| Problem statement | [H/M/L] | [Why] |
| Scope | [H/M/L] | [Why] |
| Pricing | [H/M/L] | [Why] |
| Timeline | [H/M/L] | [Why] |
| Deliverables | [H/M/L] | [Why] |

**[Ready to send / Needs verification — list what to check]**

What Makes This Different

Most proposal tools give you a template to fill in. This skill reads an actual conversation and writes the proposal from what the prospect said.

The difference: a template starts with your services and asks you to match a prospect to them. This skill starts with the prospect's words and builds a scope around their problem. The Opening Context uses their language. The deliverables match what they described. The investment ties to their situation, not your rate card.

Practice owners with 10-30 active prospects lose deals to delay, not to competitors. The conversation was good — the proposal just took too long. This skill closes the gap: paste the conversation, review the SOW, send it today.

Pair this with Skill #1 (Client Intelligence Brief) and Skill #2 (Hidden Revenue Scan): the CIB shows you what clients are saying between the lines. The Revenue Scan finds the money hiding in existing relationships. When those signals surface a conversation — this skill converts that conversation into a proposal before the momentum dies.