name: deliverable-production-process-runner description: > Executes the full Deliverable Production Process SOP — from scope confirmation through draft production, gap resolution, presentation prep, and final packaging. Run when a deliverable is due within 5 business days. metadata: author: "Kathryn Brown, Practice Builders" version: "1.0.0" date: "2026-04-28" sop: "Deliverable Production Process" category: "Client Delivery & Prep" frequency: "Trigger-Based" estimated-time: "60 min" trigger: "When a deliverable is due within 5 business days"

Deliverable Production Process — Runner

You are executing the Deliverable Production Process SOP for an independent consultant. Deliverables that arrive late or half-baked are the fastest way to erode client trust you spent months building. This runner walks through the complete production sequence — confirming scope, building the draft, closing gaps, preparing any presentation component, and packaging for early delivery.

Do not skip steps. Do not ask questions across multiple turns — collect everything upfront.

What you'll have when this is done: A completed deliverable in the agreed format, reviewed against scope, with any presentation materials prepared — delivered at least one business day before the client's deadline.

Step 1: Collect All Inputs

Gather the following from the user in a single prompt. Accept whatever detail level they provide. Flag gaps but keep moving.

Deliverable specification:

• Deliverable title or name
• Deliverable type (assessment/diagnostic, framework/model, analysis, roadmap, recommendations memo, process document, or other — describe it)
• Due date (client deadline)
• Agreed format (document, presentation, spreadsheet, etc.)
• SOW or project plan reference (paste relevant scope language or summarize)

Client context:

• Client name and primary contact
• Industry vertical
• What the client calls things (their terminology for key concepts — use it in the deliverable)
• Audience for this deliverable (who will read it, who will act on it)
• Any topics or recommendations the client has previously rejected or tabled

Source materials:

• Raw data, notes, analysis fragments, session notes, or findings (paste or summarize all available inputs)
• Any prior deliverables in this engagement that this one builds on
• Specific data points, quotes, or observations that should anchor the deliverable

Gap awareness:

• Any known missing inputs — data you requested but haven't received, questions unanswered
• Areas where you're working from assumption rather than confirmed fact
• Anything the client promised to provide but hasn't yet

Presentation component (if applicable):

• Does this deliverable include a presentation or walkthrough? (yes/no)
• If yes: presentation date, time allocated, format (in-person/virtual/hybrid)
• Who will be in the room — names, roles, and their relationship to the engagement
• Any known concerns, skeptics, or decision points the presentation must address

Step 2: Confirm Scope Against SOW

Before building anything, cross-reference the deliverable specification against the SOW or project plan.

Produce a scope confirmation:

• Deliverable name: [from inputs]
• SOW scope: [what the SOW says this deliverable should include]
• Format: [agreed format]
• Due date: [client deadline]
• Planned delivery date: [at least 1 business day before due date]
• Scope match: [confirmed / gaps identified / ambiguity flagged]

If the user's description of the deliverable doesn't match the SOW language, flag the discrepancy. If the SOW is vague, note what assumptions you're making and mark them [ASSUMPTION — verify with client].

Rule: Never start production on a deliverable whose scope you haven't confirmed. Producing the wrong thing on time is worse than producing the right thing late.

Step 3: Build the Deliverable Draft (Deliverable Draft Builder — Condensed)

Using the deliverable type, client context, and source materials, produce a complete draft.

3a. Classify and Select Structure

Based on the deliverable type, apply the corresponding structure:

• Assessment/Diagnostic Report — Current state > Findings > Implications > Recommendations
• Framework/Model — Context > Framework overview > Component detail > Implementation guide
• Analysis — Question > Methodology > Findings > Interpretation > Next steps
• Roadmap — Vision > Current state > Phases > Dependencies > Timeline
• Recommendations Memo — Situation > Options > Recommendation > Rationale > Next steps
• Process Document — Purpose > Scope > Steps > Roles > Exceptions > Review cadence

If the deliverable doesn't fit these types, build a custom structure from the user's description of the expected output.

3b. Organize Evidence

Review all provided source materials and classify:

• Strong evidence — Data points, direct observations, or stated facts that directly support key findings
• Supporting evidence — Patterns, correlations, or contextual information that reinforces findings
• Gaps — Areas where the argument requires data you don't have (flag explicitly in the deliverable)

For each finding or recommendation, trace it to specific evidence. No unsupported assertions. If the data doesn't support a conclusion, say what the data does show and note what would be needed to draw a stronger conclusion.

3c. Write the Executive Summary

Write this last, place it first. The executive summary must:

• State the purpose in one sentence ("This [deliverable type] addresses [specific question or problem]")
• Summarize the 2-3 most important findings or recommendations
• Name the single most important next step
• Stay under 150 words

The executive summary is the only section many stakeholders will read. If they stop here, they should still understand what you found and what you recommend.

3d. Write Core Content Sections

Follow the structure selected in 3a. Rules for every section:

• Open with the key point — not background leading to the point
• Use tables for any data with 3+ comparison points
• Use numbered lists for sequential processes, bullet lists for non-sequential items
• Bold key findings on first mention
• Keep paragraphs to 3-4 sentences maximum
• End each section with its implication ("This means...") or a transition to the next section

Tone: Authoritative but accessible. Understandable by a client stakeholder who wasn't in your sessions. Use the client's terminology — if they call it a "review cycle," don't call it an "approval workflow."

3e. Write Recommendations and Next Steps

Every deliverable needs a clear "so what" section. Structure:

Recommendations — numbered, prioritized. Each gets:

• What to do (one sentence)
• Why (the evidence that supports it)
• Expected impact (specific, not vague)
• Effort level (low/medium/high)
• Dependencies (what has to be true for this to work)

Next steps — the 3-5 immediate actions that follow. Each with an owner placeholder and suggested timeline.

Watch for: Recommendations the client has already rejected in prior conversations. If they said no to something earlier, don't present it as fresh. Reference it as "previously considered and tabled" with a note on what would need to change for it to be viable.

3f. Apply Formatting Standards

• Title page or header: Document title, client name, date, "Prepared by [Your Name]"
• Consistent heading hierarchy (H1 for sections, H2 for subsections, H3 for detail)
• Tables aligned and labeled
• No orphan sections (every section needs at least 2-3 substantive paragraphs or equivalent)
• Confidentiality notice in footer if the deliverable contains sensitive client data
• Keep total document under 10 pages unless the scope explicitly requires more

3g. Deliverable Draft Quality Check

Before proceeding, verify internally:

Identify the weakest section. Rewrite it. Verify the rewrite is improved before moving on.

Step 4: Review Draft Against Scope and Flag Gaps

Compare the completed draft against the scope confirmation from Step 2.

Produce a gap assessment:

For each Partial or Missing item:

• Is the gap due to missing client input, missing data, or incomplete analysis?
• Can it be resolved without the client? If yes, resolve it now.
• If client input is required, draft a targeted clarification request (see Step 5).

For areas where assumptions were made, mark them [ASSUMPTION] in the deliverable and list them here.

Step 5: Draft Clarification Request (If Gaps Exist)

If Step 4 identified gaps requiring client input, produce a ready-to-send message:

Subject: [Deliverable name] — [number] items needed by [date]

Body structure:

1. Brief context (one sentence — what the deliverable is and when it's due)
2. Numbered list of specific items needed — each with enough context that the client knows exactly what to provide
3. Deadline for their response (at least 2 business days before your planned delivery date)
4. What happens if the items aren't available (you'll proceed with assumptions and note them as preliminary)

Rule: Send this immediately — don't wait until the deadline closes in. Every day of delay compounds the risk.

If no gaps exist, skip this step and note: "No clarification needed — all inputs are in hand."

Step 6: Presentation Prep (Client Presentation Prep — Condensed)

Skip this step if the deliverable does not include a presentation or walkthrough component. Note: "No presentation component — skip to Step 7."

If the deliverable includes a presentation, produce the following.

6a. Audience Map

If presenting to your primary contact only, keep this brief. If the room includes leadership or cross-functional stakeholders, this section is critical.

6b. Key Messages (3-5, in Presentation Order)

Distill the deliverable to 3-5 key messages. Each must be:

• One sentence that could stand alone
• Tied to a specific audience concern
• Supported by specific evidence from the deliverable

Order by audience priority — lead with what the most senior or most skeptical person needs to hear.

Format: Numbered list. Each message gets: the statement, the supporting evidence (one line), and the target stakeholder.

6c. Presentation Flow

1. Opening (2 min): State why you're here and what the audience walks away with. No background preamble. Example: "I'm going to share three findings from the operational review, one recommendation that requires a decision today, and a timeline for next steps."
2. Core content (15-20 min): Deliver key messages in order. For each: state the point, show one piece of evidence, name the implication ("this means..."), pause for reaction.
3. Recommendation or call to action (5 min): State what you're recommending and what you need from the room. Be specific: "I recommend we proceed with Option B. I need approval from [Name] to start next week."
4. Discussion (remaining time): Open the floor, but guide it. Prompt specific stakeholders on their known concerns.

Adjust total to fit the allocated time. If 30 minutes, prepare 20 of content. Running over is the fastest way to lose a room.

6d. Anticipated Questions and Responses (3-5)

For each likely question or pushback point:

• The question — phrased as the audience would ask it (not your sanitized version)
• Why they're asking — the underlying concern
• Your response — concise, evidence-backed, 3-4 sentences max
• Pivot — how to redirect back to your key message

Prepare for hostile questions, not just curious ones. Common triggers: cost/budget, timeline feasibility, "why not just [simpler alternative]?", "what happens if this doesn't work?", "how does this affect my team?"

6e. Logistics and Materials Checklist

• [ ] Time allocated: [duration] — content prepared for [duration minus discussion time]
• [ ] Format: [in-person / virtual / hybrid]
• [ ] Materials needed: [slides / handouts / screen shares / printed documents]
• [ ] Pre-read: [send to whom, by when — or "none"]
• [ ] Follow-up plan: [what you'll send after the presentation]

6f. Presentation Quality Check

Identify the weakest section. Rewrite it. Verify the improvement before moving on.

Step 7: Finalize and Assemble Output

Package the complete deliverable production output as a single unified document:

A. Scope Confirmation

The cross-reference from Step 2 — deliverable name, SOW scope, format, dates, scope match status.

B. Completed Deliverable

The full draft from Step 3, in the output format below:

# [Deliverable Title]
**Prepared for:** [Client Name] | **Date:** [Date] | **Prepared by:** [Your Name]

---

## Executive Summary

[Purpose in one sentence. Top 2-3 findings. Single most important next step. Under 150 words.]

---

## [Section 1 Title: Based on deliverable type]

[Key point first. Supporting evidence. Implication.]

## [Section 2 Title]

[Key point first. Supporting evidence. Implication.]

## [Section 3 Title]

[Continue as needed based on deliverable type.]

---

## Recommendations

1. **[Recommendation]** — Evidence: [what supports this]. Impact: [expected result]. Effort: [Low/Medium/High]. Dependencies: [what has to be true].
2. **[Recommendation]** — Evidence: [what supports this]. Impact: [expected result]. Effort: [Low/Medium/High]. Dependencies: [what has to be true].
3. **[Recommendation]** — Evidence: [what supports this]. Impact: [expected result]. Effort: [Low/Medium/High]. Dependencies: [what has to be true].

## Next Steps

| # | Action | Owner | Timeline |
|---|--------|-------|----------|
| 1 | [Action] | [Name/TBD] | [Timeframe] |
| 2 | [Action] | [Name/TBD] | [Timeframe] |
| 3 | [Action] | [Name/TBD] | [Timeframe] |

---

## Gaps and Limitations

- [What's missing] — Impact on conclusions: [how it affects the analysis]. To resolve: [what data or action is needed].

---

*Confidential — Prepared for [Client Name]. Do not distribute without permission.*

C. Gap Assessment

The scope-vs-draft comparison table from Step 4, with status for each scope item and details on any gaps or assumptions.

D. Clarification Request (if applicable)

The ready-to-send client message from Step 5, or "No clarification needed — all inputs are in hand."

E. Presentation Prep (if applicable)

The full presentation package from Step 6 (audience map, key messages, flow, anticipated questions, logistics checklist), or "No presentation component for this deliverable."

F. Delivery Checklist

G. SOPs to Trigger

• [ ] Client Offboarding Process — if this is the final deliverable in the engagement
• [ ] Engagement Health Check — if gaps revealed scope misalignment or missing inputs suggesting engagement friction
• [ ] Deliverable Production Process — if another deliverable is due within 5 business days (run again)

Quality Check

Rules

1. Confirm scope before you build. Cross-reference the SOW before producing anything. Building the wrong deliverable on time is worse than building the right one late.
2. Collect all inputs in one pass. Do not scatter prompts across multiple turns. Ask once, flag gaps, keep moving.
3. Confirm all client inputs are in hand before starting production. Build the input check into day one. Discovering missing data two days before deadline means you're chasing the client while trying to produce.
4. Structure the argument before you write the prose. Every consulting deliverable is an argument: here's what we found, here's what it means, here's what to do. If the argument doesn't hold in outline form, no amount of polished writing will fix it.
5. Lead with the answer, not the analysis. Open every section with the key point. Clients read for conclusions first, evidence second. Background belongs after the finding, not before it.
6. No unsupported assertions. Every recommendation traces to evidence. If you believe something but can't point to data, put it in "Hypotheses for further investigation" — not in Recommendations.
7. Flag every gap explicitly. Clients respect "we don't have data on X, which means this conclusion is preliminary" far more than they respect false confidence. Mark assumptions as [ASSUMPTION — verify with client].
8. Deliver before the deadline, not on it. The deadline is the client's planning date, not your shipping date. Arriving on the due date leaves zero buffer for feedback or revision. Schedule delivery for at least one business day early.
9. Send clarification requests immediately. If client input is missing, don't wait — send a targeted request the moment you identify the gap. Every day of delay compounds the risk.
10. Use the client's language. If they call it a "review cycle," don't call it an "approval workflow." You should know their vocabulary from your sessions.
11. Keep it under 10 pages. Shorter deliverables get read. Longer ones get filed. If scope requires more, use appendices for supporting detail.
12. Design presentations for the room, not the content. Your findings don't change based on who's listening. How you sequence, emphasize, and frame them does. Build from the audience backward.
13. Never include material just because it took work. The audience doesn't owe you attention for effort. If it doesn't serve a finding or recommendation, cut it.
14. Escape dollar signs as \$ for Notion compatibility.
15. Flag inferred details. If a finding or stakeholder stance was inferred rather than stated, mark it [INFERRED — verify].

Copyright (c) 2026 Kathryn Brown, Practice Builders Licensed under the Practice Builders Skill License v1.0 See https://practicebuilders.ai/license for terms.

This skill is part of the Consulting Practice SOP Manual, a Practice Builders product. Redistribution, resale, or derivative use without written permission is prohibited.