The AI transformation playbook
Run AI transformation one workflow at a time. Inventory and score candidate workflows, pick one, take it through Discover (1 week), Prototype (2 weeks), Build (3–6 weeks) and Ship, measure it against a baseline, then reuse the components for the next workflow.
Company-wide AI programmes stall because they try to change everything at once and measure nothing in particular. This playbook is deliberately narrow. Each cycle produces one system that people use every day, plus reusable parts (ingestion, review UI, logging, eval harness) that make the next cycle faster.
Stage 1. Inventory (1–3 days)
Output: 20–40 candidate workflows.
- Ask each team lead for the three workflows that consume the most repetitive hours.
- Write each one as trigger → steps → output → owner.
- Ignore "use AI for X" ideas that have no owner or no current workflow.
Stage 2. Score (1 day)
Output: a ranked backlog.
Score each candidate from 1 to 5 on five criteria and multiply nothing: just add.
| Criterion | 5 means |
|---|---|
| Value | Many hours a week, or a direct revenue or risk impact |
| Owner | One named person who can change how the work is done |
| Data | Hundreds of real historical inputs and outcomes, exportable |
| Stability | The process has not changed much in 6–12 months |
| Measurability | Volume, time and quality are already tracked |
Then check the top five for risk and regulatory constraints. Use the 25-point readiness checklist for the finalists.
Stage 3. Discover (1 week)
Output: a scoped build plan.
- Map the workflow, including the exceptions people handle without thinking.
- Confirm data access and permissions in writing.
- Agree one metric and take a baseline before anything is built.
- Write the definition of "in production" for this system (see what in production means).
Stage 4. Prototype (2 weeks)
Output: evidence that the approach works on real inputs.
- Build a narrow working slice on real data with a real model. Not a clickable demo.
- Assemble the first eval set of 50–200 real cases with known good outcomes.
- Decide what stays in code: arithmetic, lookups and policy checks do not belong in prompts.
Stage 5. Build (3–6 weeks)
Output: a production-ready system.
- Integrate with the real source and destination systems. This is often the largest share of the work.
- Put guardrails in code and add a human review path for low-confidence cases.
- Add logging, dashboards and alerts for volume, quality, latency and cost per task.
- Iterate against the evals, not against impressions.
Stage 6. Ship (handoff plus the first month)
Output: a system the client team can run.
- Run in shadow mode, compare against human decisions, then go live.
- Hand over the runbook, prompts, evals and dashboards, and train the owner.
- Review the metric at 30 and 90 days.
Stage 7. Scale (quarterly)
Output: compounding transformation.
- Reuse ingestion, review UI, logging and the eval harness.
- Pick the next two workflows from the backlog.
- Formalise AI governance once there are three or more systems in production.
Principles
- If a rule works, write a rule. Use models only for judgement.
- Real data from day one.
- Evals before launch.
- Human approval before any irreversible action.
- Handoff is a deliverable, not an afterthought.
How long the whole thing takes
The first workflow typically takes 6–10 weeks from kickoff to go-live. Company-wide transformation is the sum of many such cycles, usually across one to two years. The timelines page breaks this down by scope.
This is the method Sudo Sapient runs in client sprints; the services page lists what each sprint delivers.