Nobody buys "AI consulting." They buy a problem solved by a date they can plan around. This lesson turns vague expertise into a service promise a buyer can understand, compare, and say yes to — and that you can deliver without renegotiating the scope every week. (Product/expertise track from the 80.0 fork: community-track readers, this is the delivery discipline behind paid extensions in Lesson 83.4 — note how scoping protects trust built in Parts XIII–XIV.)

The vocabulary first

Service work fails most often at the language level. Learn these as working definitions, not jargon:

• Service — expert work performed for a specific client to produce a specific result.
• Consulting — advice and diagnosis: what to do and why.
• Implementation — doing the build or setup, not just recommending it.
• Advisory — recurring judgment over time, usually lighter than consulting but longer-lived.
• Training — transferring capability so the client can operate without you.
• Scope — the exact work included. Deliverable — the tangible thing the client receives. Engagement — the whole bounded relationship: scope, timeline, price, support.
• Client outcome — the change in the client's world when the work succeeds, stated from their side.

The test is simple. If two reasonable people can read your offer and picture different work, your scope is not defined yet.

The expertise offer formula

Every sellable service answers five questions in one breath:

buyer problem → defined result + method + timeline + boundary + support

Take a buyer problem: "Our five-person research team drowns in unverified AI summaries and cannot trust anything enough to send to clients." The vague version sells "AI consulting to improve your research workflow." Nobody can picture what arrives, when, or what it costs to be wrong.

The scoped version sells this: "In three weeks, your team gets a source-linked research workflow — templates, source-checking rules, and one live project run through it — plus a 90-minute owner training so you can run it without me. Includes two revision rounds; excludes custom software development; email support for 30 days after handoff."

Notice what changed. The result is concrete (a working workflow plus a trained owner). The method is named (templates, rules, one live run). The timeline is bounded (three weeks). The boundary says what you will not do (no custom software). The support names what happens after delivery (30 days of email). A buyer can compare that against hiring, doing nothing, or buying software. A vague offer cannot be compared to anything, so it loses to doing nothing.

"AI consulting" versus scoped work

"AI consulting" fails for three structural reasons. First, the buyer cannot tell whether they need diagnosis, a build, or training — and prices those very differently. Second, the seller cannot estimate the work, so every engagement becomes custom and exhausting. Third, there is no finish line, so satisfaction is a mood rather than a checkable state.

Contrast three scoped alternatives for the same Research Desk skill set:

Each scoped version names the starting state, the finish state, and the evidence. Each can be priced, scheduled, and referred. "Let me pick your brain" cannot.

The local package: audit, setup, training

Use the local business running example. A neighborhood services shop does not sell "business tech help." It sells a fixed audit–setup–training package: a half-day audit of bookings and no-shows, a one-day setup of online booking with deposits and reminders, and a one-hour staff training with a printed checklist. Price it fixed. Name the exclusions (no website redesign, no hardware). Name the support (two weeks of message support, one fix visit).

Fixed packages do three jobs at once. They make the sale easier because the buyer sees the whole box. They make delivery easier because you run the same steps each time. And they make referrals easier because the past client can describe exactly what they bought. Vague hourly availability does none of these.

Exercise: write SERVICE-OUTCOME.md

Create a file called SERVICE-OUTCOME.md with these sections, each one to three sentences:

1. Client — who exactly, and what they do now instead. 2. Starting state — the painful present, with one observable fact. 3. Finish state — the world after delivery, observable and dated. 4. Included work — numbered deliverables plus method. 5. Excluded work — at least two explicit "this is not included" lines. 6. Timeline — start, milestones, handoff date. 7. Evidence of completion — how both sides know it is done (file delivered, training completed, checklist signed).

Worked miniature: "Client: owner of a six-person advisory firm. Start: analysts paste AI summaries into client briefs with no source trail. Finish: by week three, every brief ships with linked sources and a checker pass. Included: workflow template, source rules, one live brief run, owner training. Excluded: custom software, historical brief rewrites. Evidence: delivered template + one reviewed brief + completed training session."

Finish line: a service promise specific enough that a stranger could repeat it and you could deliver it twice without improvising the scope.

Verify quickly: cover the price and ask a friend what they think arrives and when. If they guess wrong, the scope — not the friend — needs rewriting.

Common failure mode: writing exclusions as an afterthought. Exclusions are the scope. Every missing "not included" becomes a free extra request later.

Check your understanding

1. What five elements turn a buyer problem into a sellable expertise offer? 2. Why does "AI consulting" lose to a scoped workflow-build-and-train offer? 3. What belongs in the evidence section of SERVICE-OUTCOME.md, and why?

Next

You have a promise you can sell. Lesson 82.2 helps you choose how to deliver it — one-to-one, implementation, workshop, retainer, cohort, or self-paced — without locking yourself into the hardest shape first.