Scoping your first system.

This is lesson 05 of the ColabContent AI-Ready Course, a free seven-lesson primer for mid-market operators considering a custom AI commission. Each lesson takes five to ten minutes and ends with a concrete action. By the end of the seven days the operator has a written scoping document for a potential commission.

Day five. The four elements of a tight scope. The difference between a system that ships in 6 weeks and one that ships never.

Lesson5 of 7
Read time~20 minutes
FormatMemo-style
CostFree

Most AI projects fail at scope.

Most AI projects do not fail at the technology layer. The technology layer has gotten boringly reliable, fast. Most AI projects fail at the scoping layer. The owner had a problem; the scope did not name the problem precisely; the build wandered for two quarters; the deliverable solved a different problem than the one the owner cared about.

A tight scope has four elements. Each one has to be answered before any architecture is drawn. We will walk through each.

Element I: outcome.

The outcome is what changes about the business when the system is live. Not what the system does (that's the architecture). Not what the system uses (that's data). The outcome is the line item on the P&L that moves, or the operational metric that improves, or the named bottleneck that is removed.

The discipline is to write the outcome as a sentence with a number. "Quote turnaround drops from 6 hours to 30 minutes for the first 80% of inbound RFQs." "Annual unbilled-time leakage at the operation reduces by $1.2M, validated against last quarter's actuals." "COI turnaround drops from 18 hours to 30 minutes, and the agency's COI-related retention loss reduces by 50% over the next 12 months."

If the outcome cannot be written as a sentence with a number, the scope is not ready. About 30% of the diagnosis calls we run end here, with us telling the prospect to come back when the outcome is named.

Element II: interface.

The interface is where the human meets the system. This is the element most builds get wrong, because the interface is treated as an afterthought. It is not. A system that does brilliant work behind the scenes, surfaced through an interface the operator hates, is a system the operator works around.

For most workflows in mid-market operators, the right interface is not a new tool the team logs into. It is the existing tool the team is already in: ServiceTitan, CCH Axcess, iManage, Applied Epic. The AI runs in the background and writes its output into the existing tool. The operator does not see "the AI"; they see a better-prepared queue in the system they already use.

The discipline is to ask: where does the operator currently make this decision, and how does the AI's output get into that exact spot? If the answer is "we'll build a separate dashboard," the answer is wrong. Build the AI to write into the spot the operator is already in.

Element III: data.

The data element answers two questions: what data does the system need to read, and what data does it need to write?

The reads are usually obvious once the outcome is named. Quote turnaround needs RFQ documents, the part library, the customer history, current material costs. COI generation needs client policy, additional-insured request specifics, carrier templates. Billable-hour reconstruction needs partner activity in iManage, calendar, Teams call history.

The writes are where scopes get into trouble. The system needs to write back to the system of record, not to a parallel universe. ServiceTitan AI writes Jobs into ServiceTitan. CCH Axcess AI writes binder entries into CCH Axcess Document. The AI is a layer, not a parallel system.

The discipline is to inventory both reads and writes before the build, with the source of truth named for each. "Customer master is in ServiceTitan, period." "Time entries write to iManage Time, period." Vagueness here causes scope drift later.

Element IV: guardrails.

The guardrails are what the system is not allowed to do. The discipline is to name them in advance, in writing, and review them with the operator.

Examples of well-named guardrails: "The system never sends an email to a client without a CSR's one-click approval." "The system never modifies a tax return; it only surfaces flags to the reviewer." "The system never bypasses iManage permissions; queries run with the user's actual access." "The system never auto-quotes above $50K without a senior estimator's sign-off."

Operators who feel comfortable with guardrails get comfortable with the system. Operators who don't, don't. Skipping this element is the most common reason a technically correct system fails to gain adoption.

The one-page scope.

A tight scope fits on one page. Outcome (one paragraph with a number). Interface (one paragraph naming the exact existing tool the AI writes into). Data (one paragraph listing reads and writes with sources of truth). Guardrails (a numbered list of 5-8 lines).

If the scope does not fit on one page, the scope is not tight. If it fits on one page but the elements are vague ("we'll figure out the interface in week 3"), the scope is not tight. The build that follows a tight scope is a 4-7 week engagement that ships. The build that follows a loose scope is the project that becomes a slide in the post-mortem deck two quarters from now.

Tomorrow.

Lesson 6: change management. The system works. Your team hates it. Now what?

Where this lesson fits

How the AI-Ready course is structured.

Where lesson 05 fits in the AI-Ready course.

The AI-Ready course is a seven-lesson primer for operators considering whether to commission a custom AI build for their business. The course is free. It is structured as one short lesson per day for seven days, delivered by email. Each lesson can be read in five to ten minutes and ends with a single concrete action the operator can take that day.

The lessons in order: the two questions every operator should answer before any AI buying motion, the build-versus-buy framework, the diagnosis structure, the prototype-before-pay engagement model, the integration boundary, the handoff and ownership posture, and the twelve-month-after-handoff stewardship pattern. This lesson is one of those seven.

How to apply the lesson at your operation this week.

The lesson ends with a concrete action because the course is designed to produce a written artifact, not a feeling. By the end of the seven days the operator has a one-page document that names their leading constraint, names the workflow that addresses it, names the integration boundary, names the buying motion, and names the ownership posture. The document is the operator's to keep regardless of whether the operator commissions a build.

The action this lesson asks for is small. Five to fifteen minutes of work, written down, kept in a single document that the operator returns to as the course progresses. Most operators do the work on a Sunday evening over coffee. By Friday of the second week the document is done.

What the next lesson covers.

Each lesson builds on the previous one. The next lesson takes the artifact the operator built this week and applies the next decision in the sequence. The operator who reads the lessons in order, does the action each one asks for, and lets the artifact accumulate ends the course with a complete written scoping document for a potential commission. The operator who reads the lessons out of order or skips the actions gets less value from the sequence.

Why ColabContent runs the course.

The course exists because most of the operators we end up commissioning for came in already having done some version of this work on their own. The structured course shortens that path. Operators who finish the course and decide their constraint is right for a custom commission book the forty-five-minute diagnosis call. Operators who finish the course and decide the right answer is no AI right now, or off-the-shelf, or an internal hire, are better positioned for whichever motion they chose.

The course generates no obligation to commission. Operators who finish the course and choose any of the alternatives are fine; we will refer them to whichever path they decided on if we know who does that path well.

All seven lessons.

The course hub indexes the seven lessons. Each lesson is also available as a standalone read for operators who arrive at it through search or a referral. The hub also explains how the daily email delivery works for operators who would rather have the course paced for them than read it in one sitting.

Extended questions

The questions buyers ask after the first one.

How much of the buy decision should the operator make versus delegate.

The right shape of the buying motion has the operator-owner or operating partner in the room for the diagnosis call. The constraint identification is too consequential to delegate to a department head. The implementation work that follows can and should be delegated; the decision on which constraint a commission addresses cannot.

How to evaluate references the consulting house presents.

Three questions per reference. First, what was the named constraint the commission addressed at this operator. Second, what was the measured result twelve months post-handoff, in dollars or hours. Third, does the reference operator still run the system. Vague references on any of those three are flags. ColabContent provides direct introductions to past commission operators for any prospect that asks; a fifteen-minute call to the operator is the most honest signal a prospect can get.

How a fixed-fee commission scopes overage risk.

The fixed fee is set after the diagnosis call, after the integration depth is named, and after both sides have written the constraint in a sentence. Overages occur when the operator changes the scope mid-build (a different workflow, a different integration, an additional system). Either side can pause the build to renegotiate; neither side absorbs hidden overages without explicit agreement. The default is to ship the original scope and address scope expansion in a separate engagement.

What happens to the system one year after handoff.

The system continues to run inside the operator's cloud tenant. Models, prompts, and integration code are versioned and the operator has the source. When the underlying foundation model improves (a new release from the model vendor, a new open-weight option), the operator can swap the component without renegotiating the engagement. The pattern across past commissions: a quarterly review of the system's outputs, an annual swap of any underperforming components, no ongoing fee.

When the right call is not a commission.

The right call is sometimes a product (when the workflow matches a product's calibration target), sometimes an internal hire (when the operator has a five-year horizon and a $5M AI runway), sometimes a Big Four engagement (when the operator is large enough that the strategy-then-build separation makes sense), sometimes no AI right now (when the operator's leading constraint is not actually addressable with AI). We tell prospects when their constraint falls into one of those buckets and route them to whichever path fits. The four-commissions-per-quarter cap is real; the firms that get one of those four slots are the firms where the commission is the right buying motion.

The five-minute fit-check worksheet.

Operators who want to test the fit before booking a diagnosis call can run a five-minute self-check on six questions. First, is the operator's annual revenue in the $8M to $50M band. Second, is there a named workflow where time or money is leaking measurably. Third, has the operator tried an off-the-shelf product and either rejected it or hit a misfit ceiling. Fourth, is the operator comfortable running the system inside their own cloud tenant under NDA. Fifth, can the senior operator commit to forty-five minutes for a diagnosis call. Sixth, is the budget runway for a $45K to $180K fixed fee real this quarter.

Six yes answers means a diagnosis call is worth the forty-five minutes. Three or fewer yes answers means the right next step is probably one of the alternatives. Four or five yes answers means the call surfaces whether the missing one is addressable.

What to bring to the diagnosis call.

Two artifacts make the call substantially more productive. First, a one-page description of the leading constraint, written in the operator's words, naming the workflow and the rough dollar or hour leakage. Second, a list of the systems the operator uses for the workflow (the system of record, the related tools, the integration boundaries). Neither artifact has to be polished. The point is to surface the constraint quickly so the call's forty-five minutes are spent on diagnosis, not exposition.

Get the one-page scope written for you.

Every diagnosis call ends with the one-page scope, written and yours to keep, regardless of whether you commission.