Turn a Client Engagement into a Sellable Service Package

Your best sales asset is sitting in a project folder you already closed.

We just shipped Module 2.7: Service Package from a Real Engagement , and it exists because of a pattern we keep seeing. A company runs a genuinely good client engagement: SLAs hit, metrics improve month over month, a happy customer says quotable things in review meetings. Then the engagement ends, the folder gets archived, and the sales team goes back to pitching with adjectives.

The proof, the process, and the pricing already exist. They are just buried in sprint reports and meeting notes. Reading and synthesizing a messy corpus is exactly what an agent is good at, which makes packaging a service a workflow-extraction problem, not a writing problem.

The practice is four steps. Each step feeds the next:

• Mine. The agent reads the whole project corpus and writes a research file where every claim cites a source document. No invented numbers.
• Decide. You answer five questions before anything gets written: target buyer, anonymization, deliverables, language, and service name.
• Blueprint. The agent writes the internal service blueprint: the operating manual a new project manager could run a second engagement from.
• Derive. Offer sheet, case study, landing page, deck. All marketing copy quotes one source of truth, so the numbers never drift.

The counterintuitive part: the messy documents matter most. A dispute about out-of-hours work becomes a working-hours governance policy. A client complaint that led to a process fix becomes your most credible quality standard. Post-fix process beats marketing adjectives every time.

Asking an agent for “a landing page for our support service” gets you something plausible and unverifiable. The blueprint-first practice forces a citation chain: every marketing claim traces to the offer sheet, which traces to the blueprint, which traces to the research file, which cites project documents. When a prospect asks “is that number real?”, your salesperson has an answer.

We ran this practice on a real production-support engagement while building the lesson. The proof band it produced:

• Zero SLA breaches across 151 tickets in five months
• Product coverage grown from 2 to 9 apps
• Resolution rate up from 64% to 87%
• Zero negative CSAT

Every one of those numbers traces to a monthly report in the project folder.

Here is the whole practice as one prompt. Paste it into Claude Code at the root of any completed project's folder, point the first line at your export, and answer the questions when it stops to ask. It works in Claude web too if your corpus fits in the context window.

I'm turning a completed client engagement into a sellable service package.
Corpus: [POINT AT YOUR PROJECT FOLDER / EXPORT]

Work in four steps. Do not skip ahead.

STEP 1 - MINE. Read the whole corpus (including messy documents: disputes,
complaints, mid-flight fixes - those are the most valuable). Save a research
file covering: (1) service operations model - roles, cadence, tooling,
escalation, working-hours policy; (2) SLA & metrics evolution - contractual
targets vs. what the customer later demanded, and how each is measured;
(3) customer feedback - verbatim quotable praise, criticisms, what was fixed;
(4) results - concrete numbers with dates; (5) commercial model - pricing,
capacity unit, billing, contract lifecycle; (6) reusable assets - every
template, checklist, dashboard recipe worth productizing. Cite filenames.
No invented claims.

STEP 2 - DECIDE. Ask me, and wait for answers: target buyer (niche or broad)?
name the reference client or anonymize (default: anonymize)? which
deliverables first (blueprint / case study / landing page / deck / one-pager)?
language(s)? Then propose 3-5 service names with rationale and let me pick.

STEP 3 - BLUEPRINT. Write the internal service blueprint from the research
file: service definition with explicit out-of-scope; blueprint table (journey
stages Discover > Contract > Onboard > Operate > Review > Renew, crossed with
customer actions / frontstage / backstage / supporting systems); engagement
lifecycle with the de-risking spelled out as a selling point; operating model
with every LESSON from the engagement stated as a rule; onboarding playbook;
SLA and metrics catalog with measurement recipes; pricing tiers - the proven
price is fact, extrapolated tiers are marked "proposal - confirm with finance";
asset library; anonymized proof points. Written so a new PM could run a second
engagement from it alone. End with unresolved questions.

STEP 4 - DERIVE. From the blueprint produce an external offer sheet (the
single source of truth for marketing copy), then an anonymized case study
(context > challenge > solution > results table > quotes > CTA), then any
further assets I chose - all copy sourced from the offer sheet verbatim.

QUALITY GATES before showing me anything: grep every external file for
client/people/product names; verify numbers are identical across all assets;
verify generated files programmatically (page counts, slide bounds); list
every extrapolated or assumed figure under "unresolved questions".

Two habits make it work:

• Answer Step 2 in writing and make the agent wait. Regenerating everything because you changed the anonymization decision halfway is the most common failure.
• Keep the unresolved-questions list. An honest assumptions list is what separates a package you can sell from one you have to walk back.

The interactive version is live in the course: run /start-2-7 inside Claude Code and you'll package a service from the Planerio campaign work you built in Module 2's campaign brief lesson . Then run the same practice on a real engagement at your own company. That second run is where it compounds.

Browse all course modules , or jump straight to the lesson: Module 2.7: Service Package from a Real Engagement .