The consultant who fails does it in the first meeting, by asking "so what would you like to automate?" and building whatever the loudest person names. Meridian's founder will say "the reporting, it's killing us," her paid-media manager will say "no, lead follow-up, we're losing deals," and both are half right and neither is a prioritization. Choosing targets is an operator's job, done with a scoring model, not a vote. This lesson gives you the model and applies it to Meridian's real inventory, and the artifact you leave with (a process spec) is the same document that becomes an agent's spec in lesson 5.5.
Meet Meridian, precisely
You cannot map processes for a business you are describing in generalities, so here is Meridian in the detail the rest of Part 5 depends on. Keep this page open; every lesson references it.
Meridian is a twelve-person B2B-leaning marketing agency in Denver, founded 2019. Retainer model: 11 active clients, average retainer $9,000/month, just under $100K MRR, about $1.9M/year with project work.
People (12):
- Dana Whitfield, Founder and Managing Director
- Marcus Lee, Head of Client Services
- Priya Nair, Account Manager
- Tom Reilly, Account Manager
- Sofia Alvarez, Content Lead
- Jaylen Brooks, Content Strategist and Writer
- Erin Kowalski, Paid Media Manager
- Raj Patel, SEO and Analytics Specialist
- Nina Torres, Designer
- Wes Coleman, Designer and Video
- Grace Kim, Operations Manager (your main contact for the Agent OS)
- Ben Okafor, Junior Coordinator and inbound-lead triage
The stack (as-is, with the mess left in):
- CRM: HubSpot (Starter). Underused. Only Ben and Grace live in it. Deals are ALSO tracked in a Google Sheet called "Pipeline_2026_MASTER", and the two disagree.
- Email: Google Workspace (Gmail). Shared inbox: hello@meridian.
- Calendar: Google Calendar. Booking via Calendly.
- Docs and knowledge: Google Drive (sprawling). Grace started moving SOPs into Notion six months ago; the migration is about half done.
- Chat: Slack. Inbound leads ping the #leads channel.
- Project management: Asana (all client work lives here).
- Analytics: GA4 and Google Ads and Meta Ads. Raj pulls all three into a Google Sheets template by hand every week.
- Meeting notes: Fathom auto-records client Zoom calls (adopted recently, not everyone trusts it yet).
- Time tracking: Harvest. Invoicing: QuickBooks.
Two clients (Brightpath Dental, Vireo Outdoors) refuse to grant ad account access and instead email PDF screenshots of their numbers.
A few clients by name: Northwind Logistics (B2B freight, $18K/mo, the biggest), Halcyon Software (B2B SaaS, $12K/mo), Brightpath Dental Group (multi-location dental, $9K/mo), Cedar & Sage (DTC wellness, $7K/mo), Vireo Outdoors (outdoor apparel DTC, $8K/mo).
That mess is not flavor, it is the work. The dual pipeline, the half-done Notion migration, the two clients who email PDFs: these are the exceptions your process specs have to name, and the reason a generic template fails on a real business. An Agent OS that pretends Meridian is clean will break the first time a Brightpath PDF shows up where the agent expected an API.
The scoring model
Score every candidate process on four axes, one to five, and let the product rank them. The axes are not interchangeable.
- Frequency. How often it runs. Weekly reporting scores high; the annual brand audit scores low. Frequency multiplies everything, because saved minutes only matter times how often you save them.
- Pain. How much the current process hurts: time, tedium, error rate, the human cost of the person stuck doing it. High pain is where the buy-in lives.
- Verifiability. Can you check the output is correct, cheaply and objectively? A report's numbers are verifiable against the source data. "Write an on-brand thought-leadership post" is barely verifiable at all. This is the axis everyone skips, and skipping it is fatal.
- Blast radius. What a wrong output costs if it escapes. A bad internal task draft costs a shrug. A wrong number in a client-facing report costs trust. A mis-sent client email costs the retainer. High blast radius does not disqualify a process, it sets where on the autonomy dial it can ever go.
Verifiability is the gate because of everything Part 3 taught: an output you cannot verify is an output you cannot eval, and an agent you cannot eval cannot move off Draft, ever. Pick a high-frequency, high-pain, low-verifiability process and you have built something that feels valuable and can never be trusted to run unattended, which is the worst place to spend a client's money. Score verifiability honestly and low-verifiability processes fall down the list where they belong, no matter how much they hurt.
Meridian's inventory, scored
Grace and you list what the team actually does and score it. An excerpt:
| Process | Freq | Pain | Verif | Blast | Notes |
|---|---|---|---|---|---|
| Weekly client reports | 5 | 5 | 5 | 3 | Numbers checkable against GA4/Ads; client-facing but reviewable |
| Lead triage + follow-up drafts | 4 | 4 | 4 | 3 | Classification checkable against a rubric; drafts, not sends |
| Meeting notes to tasks | 5 | 3 | 4 | 2 | Fathom transcript in, Asana tasks out; internal, low blast |
| Monthly retainer invoicing | 2 | 2 | 5 | 4 | Already semi-automated in QuickBooks; low frequency |
| "Write a thought-leadership post" | 3 | 4 | 1 | 3 | Barely verifiable; brand voice is subjective |
| Proposal writing for new business | 2 | 4 | 2 | 4 | Infrequent, high-stakes, hard to verify |
| Reconcile HubSpot vs the Pipeline sheet | 3 | 5 | 4 | 2 | Painful and checkable, but a symptom to fix, not automate |
The ranking picks itself, and it matches CURRICULUM's first three: weekly client reports, lead triage with follow-up drafts, and meeting notes to tasks. Each is frequent, painful, and verifiable, with blast radius low enough to start on Draft and climb. Note what the model rejects: the thought-leadership post scores high on pain and frequency but craters on verifiability, so it is a bad first target however loudly someone wants it. And the HubSpot reconciliation is a trap: it is painful and checkable, but automating it papers over the real problem, which is that Meridian runs two pipelines. Some processes should be deleted, not automated. An honest consultant says so.
The process spec
A ranked process is not yet buildable. You turn it into a process spec, five parts, and this document is the deliverable that becomes the agent's system prompt in 5.5. If you cannot write the spec, you do not understand the process well enough to automate it, and that is the spec's first job: to surface that gap now, cheaply, instead of mid-build.
# PROCESS SPEC: Weekly Client Report
## INPUTS
- Client's GA4 export (CSV) for the report week (Mon-Sun).
- Client's Google Ads + Meta Ads export (CSV) for the same week.
- The client's report SOP: which metrics matter, targets, tone.
- Last week's report (for trend language and continuity).
- Exception: Brightpath and Vireo send a PDF, not a CSV. Their
numbers are transcribed into the CSV template by Ben first;
the agent never parses the PDF.
## STEPS
1. Load this week's metrics and last week's for comparison.
2. Compute week-over-week deltas for each tracked metric.
3. Flag any metric that missed its target or moved more than 20%.
4. Draft the narrative in the client's template: what happened,
why it likely happened, what we're doing next.
5. Never invent a cause. If a spike has no known driver, say the
driver is unknown and flag it for the account manager.
## OUTPUTS
- A drafted report in the client's Google Doc template, to a review
folder. Draft only. A human sends it.
- A one-line summary of anything flagged, for the account manager.
## EXCEPTIONS
- Missing or partial data for the week: do not guess. Produce a
partial draft that names exactly which metrics are missing.
- A metric moved more than 50%: treat as likely a tracking error,
flag it loudly, do not narrate it as real performance.
## SLA
- Drafted by Monday 9am for the account manager to review and send
by Monday noon. (Currently: manually assembled Monday afternoon.)Every section maps to something the agent needs. INPUTS becomes the tool and knowledge access. STEPS becomes the prompt's task. OUTPUTS becomes the typed output contract and the review surface. EXCEPTIONS is where most of the real engineering lives, because it is the messy-business detail (the Brightpath PDF, the tracking-error spike) that a generic agent gets wrong. SLA is how you will later measure whether the thing is actually helping. This is the same specify-before-you-build discipline as the 3.1 dispatch, pointed at an operation instead of a code change.
Lablab-5-2Score Meridian's inventory and write a real process spec
Goal: Produce a scored, ranked process inventory and one complete process spec detailed enough to hand to a builder, exceptions and all.
Prereqs: a repo or folder for your Meridian work (you will grow it across Part 5). Create meridian/ now. No Claude Code run is required for this lab; it is operator work, and doing it by hand is the point.
- In
meridian/process-inventory.md, list at least eight Meridian processes (use the one-pager and the table above as a start, then add your own from how a real agency runs). Score each on frequency, pain, verifiability, and blast radius, one to five, with a one-line note per score you can defend. - Rank by a rule you write down (for example: sort by frequency + pain + verifiability, then break ties by lower blast radius). State the rule; do not eyeball it.
- Confirm your top three are buildable-first candidates and write one sentence each on why. If your ranking disagrees with CURRICULUM's three, that is allowed, but you must justify it.
- Identify one process that scores high on pain but low on verifiability, and one that should be deleted rather than automated (the HubSpot-vs-sheet reconciliation is a candidate). Name them explicitly; a consultant who only ever says "yes, automate that" is not doing the job.
- Write one full process spec in
meridian/specs/, all five sections, for your top-ranked process. The EXCEPTIONS section must name at least two real messy-business exceptions from Meridian's stack (the PDF clients, the dual pipeline, the half-done Notion migration, a metric that spikes on a tracking error).
Verify
process-inventory.mdscores at least eight processes on all four axes, each score with a defensible note.- Your ranking rule is written down, and the top three follow from it rather than from taste.
- At least one high-pain, low-verifiability process is flagged as a bad first target, and at least one process is flagged as delete-not-automate, each with a reason.
- The process spec has all five sections, and EXCEPTIONS names two or more concrete Meridian exceptions, not generic "handle errors" language.
>Troubleshooting
- Every process scores a 5 on pain: you are scoring with the client's enthusiasm, not an operator's eye. Force a spread; if nothing is a 2, your scale is broken and the ranking means nothing.
- You cannot write the EXCEPTIONS section: that is the spec working. It means you do not yet know how the process handles its edge cases, which is exactly what you must learn from Grace before a builder touches it. Go get the answer; do not invent one.
- Your spec's STEPS read like a wish ("produce a great report"): rewrite each step as an action on a named input producing a named output, the same way a 3.1 dispatch's verification must be a command, not a hope.
Knowledge check
Knowledge check
Sources
- Best practices for Claude Code (specify precisely before building; verification criteria stated in advance; the discipline the process spec applies to an operation): https://code.claude.com/docs/en/best-practices (fetched July 2026)
- Define success criteria and build evaluations (verifiability as the precondition for evaluation, and evaluation as the precondition for trusting unattended output): https://docs.claude.com/en/docs/test-and-evaluate/develop-tests (fetched July 2026)