Scoping to one metric on day one

You already know where the pain is. The onboarding team rebuilds every new account by hand. Finance closes the month in a spreadsheet because the systems do not agree. Support escalates the same billing disputes to engineering every Tuesday. What you do not have is a vendor scope that names the workflow, the metric it will move, and what ships in the first six weeks.

That gap is where discovery theater lives. A six-week assessment. A steering committee. A deck that confirms what your operators told you on day one — except now it costs $40,000 and pushes the build into next quarter.

We scope differently. Week one ends with a one-page scope: one operating metric, one workflow whose fix moves it, and the smallest system that handles the common path in production. Here is what belongs on that page — and what to cut from any engagement that cannot produce it.

#Discovery theater confirms what you already know

Discovery theater is the consulting version of asking your team where it hurts, then billing six weeks to write down the answer.

The pattern is recognizable. A discovery phase with its own SOW. Stakeholder interviews scheduled three weeks out. A workshop series before anyone watches an operator do the work. Deliverables that read like strategy — capability maps, maturity models, AI opportunity matrices — and never name the hours-per-account number leadership actually cares about.

The theater is not malicious. Large firms are structured for it. Account managers need billable phases. Junior consultants need interview hours. Procurement needs a document trail. The output is thorough. It is also late, expensive, and disconnected from the workflow that costs you money every Monday morning.

You do not need a maturity model to know that ops spends hours per new account copying fields between CRM, billing, and an onboarding tracker. You need someone in the room with the person doing that copy-paste, a stopwatch, and authority to pick one metric and one build.

That is the anti-theater position: sit with the team doing the work in week one, not week six. If a firm cannot tell you what they would ship — and what number it moves — after one week of access to your operators, they are not scoping. They are selling time.

#One metric is not a KPI dashboard

"Reduce manual work" is not a metric. Neither is "improve efficiency," "accelerate digital transformation," or "unlock AI value." Those phrases let everyone agree in the kickoff and disagree six months later about whether anything worked.

A scoping metric is specific, owned, and measurable with tools you have today:

• Hours per new account onboarding (ops team, tracked in the onboarding tracker or a simple time log)
• Days from month-end close start to leadership sign-off (finance, tracked in your close calendar)
• Escalations per week from support to engineering for billing disputes (support lead, tracked in the ticket system)
• Time-to-first-response on priority-tier tickets (support ops, tracked in the queue)

The metric does three jobs at once. It picks which workflow matters most right now. It gives the build a finish line that is not "phase two." It gives both sides a shared answer when someone asks whether the engagement worked.

If two workflows compete for attention — onboarding time versus billing dispute volume — pick the one whose fix changes customer experience or cash fastest. Document the second on the one-pager as "next after this ships." Do not scope both in v1. Fix the lowest broken layer first applies here: one workflow, one layer, one metric.

#What week one actually produces

Our week one is not a listening tour. It is a working session with the people who run the bottleneck workflow.

We watch the job get done — screen share, shadow shift, whatever gets us the real path, including the Slack messages and the spreadsheet sidecar. We count the steps, name the systems touched, and note where data gets retyped. We ask the operator: what breaks when you rush this? What do you check twice because you do not trust the handoff?

By the end of that week, you have a one-page scope. Not a hundred-slide deck. One page.

That output is the filter for every later decision. Ship the common path first. Make exceptions visible in a reviewer console, not hidden in someone's inbox. Tie the build to the number on the page. If a feature request does not move that number in the first eight weeks, it waits.

Engagements that cannot produce this page in week one are telling you they do not know what they would build yet. You are funding their learning curve.

#What we cut — and what we keep

Cutting theater does not mean cutting rigor. It means cutting everything that does not change what ships in the first sixty days.

Cut: Multi-week discovery SOWs billed separately from the build. Maturity assessments with no named workflow. Roadmaps with twelve initiatives and no forced rank. Workshops where no operator is present. Deliverables that end in "recommended next steps" instead of a repository and a runbook.

Keep: Time with operators — an hour in week one beats six weeks of executive interviews. A written scope both sides sign. A baseline measurement for the metric, even if it is rough. Explicit v1 boundaries so the team knows edge cases come in weeks five through eight, not before the common path is live. A direct line to the person building the system — no account manager relay, no ticket queue for questions that block a Tuesday deploy.

The scoping engagement on our site exists for teams that want help naming the bottleneck before committing to a full build. It is one to two weeks, not six. It produces the same one-page scope. It can roll into the build or stand alone. The point is identical: leave with a metric, a workflow, and a decision about what to ship.

If you are evaluating AI specifically, the same rule applies. AI readiness is an operations question — not a tools checklist. Readiness work that does not end in a named workflow and a weakest layer to fix is the same theater with a different logo.

#The decision you should make this week

Before you sign another discovery SOW or sit through another capabilities workshop, ask three questions:

1. After week one, will I have one metric with a baseline and a target? If the answer is no, you are buying narrative, not a build.
2. Will someone who does the work be in the room before scope is final? If the answer is no, the scope is fiction.
3. Can the firm describe the smallest end-to-end system they will put in production — not demo — in the first month? If the answer is vague, they are not ready to build.

Bring the workflow that is costing you, the team that runs it, and the number that should move. That is enough to scope. If a partner needs more than that before they can name what they would ship, they are not the right partner — or you are about to pay to learn what your operators already know.