How to scope a fixed-price AI pilot.

Why fixed scope beats vague retainers

Open-ended “AI exploration” burns budget without a finish line. A pilot forces clarity: what changes in the business when we are done? Fixed price is not a trick — it is a forcing function for shared reality.

What good scope includes

• Workflow name — e.g. “Inbound lead enrichment + CRM update”
• In-scope steps — explicit list
• Out-of-scope — equally explicit
• Success metric — hours, cycle time, error rate, response SLA
• Baseline — how work performs today and how you measured it
• Systems & access — accounts, APIs, sample data
• Human control points — where approval is required
• Timeline & price — single number, single end date
• Exit criteria — what “shipped” means
• Owner — who lives with the system after pilot

Pick one primary metric

Secondary metrics are fine; one primary metric prevents moving goalposts. Example: reduce average handling time for inbound research from 40 minutes to under 10, with human review on external sends.

Sample charter outline

1. Problem statement (two sentences)
2. Workflow steps in / out of scope
3. Primary metric + baseline method
4. Tools, data, access list
5. Human checkpoints
6. Timeline and fixed price
7. Acceptance criteria
8. What happens after success / after miss

Common scoping failures

• Boiling the ocean (“automate the whole company”)
• No baseline measurement
• No owner on the client side
• Zero discussion of exceptions
• Success defined as “feels magical”
• “Can it also…” mid-pilot without change control

Change control

When someone asks “can it also…”, the answer is either a new scope document or a polite no until Pilot ends. Protect the metric. Protect the end date. That is how trust is built.

Hand-off into Run

A pilot that hits the number should produce: runbook, permission matrix, evaluation sample set, and a named owner. Without those, “success” is a screenshot. Run is where compounding happens.

Next steps

Use the audit checklist, then email [email protected]. We will tell you if the pilot is coherent — or what to narrow. Firm direction: Vision.

Field notes from delivery

Across real scoping conversations, the same failure modes show up: no baseline, no owner, no written metric, and a desire to automate everything before anything is proven. Guides like this exist to slow that impulse without killing momentum. Clarity is speed.

When you brief Kokasync Labs, bring the messy truth — screenshots, exception examples, “this is how it actually works on Tuesdays.” Polished process docs that nobody follows will produce systems nobody uses.

A 30-day action plan

1. Days 1–3: Inventory the three workflows that burn the most hours.
2. Days 4–7: Score them with the checklist dimensions (frequency, time, risk, clarity, access).
3. Days 8–10: Choose one pattern per workflow (chatbot / automation / agent / hybrid).
4. Days 11–14: Write a one-page pilot charter with a single primary metric.
5. Days 15–30: Run Map with a builder (internal or Kokasync) and decide go / no-go on Pilot.

How this connects to the rest of the site

The Library goes deeper on individual concepts. Vision explains the firm we are building. How we work is the engagement contract. AI agents and Automations are the service doors. These Guides are the shared language between them.

Glossary (quick)

• Baseline — measured performance before the pilot.
• Human checkpoint — a required person on a material action.
• Kill-switch — how you stop the system quickly when quality or cost drifts.
• Run layer — ongoing operation after pilot proof.
• Fixed scope — one deliverable, one number, one timeline.

Closing

If this guide changed how you would brief the next AI conversation, it worked. If you want help turning it into a live pilot, write to [email protected] with the workflow, the tools, and what better looks like in 30–60 days.

Detailed walkthrough: from pain to pilot

Start with a pain that has a clock attached — something that burns hours every week. Write the current steps as if training a new hire. Circle every handoff and every tool. That map is more valuable than a feature wishlist.

Next, invent the metric before you invent the architecture. “Make us more efficient” is not a metric. “Cut average handle time from 18 minutes to under 8 on tier-1 requests, with human review on external sends” is a metric. If you cannot write it, you are not ready to buy models, tools, or agency time.

Then decide the pattern per step — not for the whole company. Rules-based steps become automations. Language-heavy multi-step work becomes agent work with gates. Questions become chat with escalation. Hybrid systems are adult systems.

Finally, pilot small and instrument everything. Keep a weekly sample of successes and failures. Name an owner. Write a kill-switch. Only then expand. This is how Kokasync Labs compounds craft without becoming a factory of demos.

Quality bar we hold ourselves to

• Written metric before build
• Human control on material risk
• Logs that reconstruct a bad run
• Owner after launch
• Honest no-go when economics do not work

Continue