The engagement lifecycle
Every customer engagement moves through a recognisable set of stages. Naming them, and agreeing explicit exit criteria for each with the customer, is the single best way to avoid the most common failure in enterprise AI: the pilot that never ends.
The stages at a glance
| Stage | Goal | Key artefacts | Exit criteria |
|---|---|---|---|
| Qualification | Decide whether to engage | Problem hypothesis, stakeholder list | A real problem, a sponsor, and data you can access |
| Discovery | Understand the problem deeply | Discovery summary, current-state workflow | Agreed problem statement and success metric with a baseline |
| Scoping | Agree what will be built and how success is judged | Scope document, acceptance criteria, plan | Signed-off scope, timeline and access dates |
| Proof of concept | Prove the approach works on real data | Working slice, evaluation results | Hits the agreed quality bar on the customer's data |
| Pilot | Prove value with real users | Pilot plan, usage and outcome metrics | Measured improvement for a real user cohort |
| Production | Run reliably at scale | Runbooks, monitoring, security sign-off | Live, supported, with an owner on the customer side |
| Adoption & expansion | Grow usage and the next use case | Success review, roadmap | Value documented; next problem identified |
Why exit criteria matter
Without exit criteria, each stage quietly stretches. A POC becomes "let's try one more thing," and six months later the sponsor has moved on. With exit criteria, every stage ends with a decision: proceed, change course, or stop. Stopping early is a legitimate, valuable outcome — it saves both sides money and preserves trust.
Agree the exit criteria for the next stage before starting the current one. "If the POC reaches 90% extraction accuracy on the 200-document test set, we start a four-week pilot with the claims team."
What changes from stage to stage
Your audience shifts. Discovery is mostly end users and process owners. Scoping adds the budget holder. Production adds IT, security and support. Plan who needs to be in the room before each transition.
The quality bar rises. A POC can run on a laptop with a sample export. A pilot needs real authentication and real data refreshes. Production needs monitoring, on-call and a rollback plan. Build each stage so the next one is a step, not a rewrite.
The risk profile changes. Early stages carry technical risk ("can this work?"). Later stages carry adoption and operational risk ("will people use it, and will it stay up?"). Your attention should move with it.
Typical timelines
Timelines vary enormously with customer size and regulation, but a rough shape for a mid-sized engagement is a few weeks of discovery and scoping, a POC measured in weeks rather than months, a pilot of one to three months, and then a production rollout. If a POC is taking longer than the pilot that should follow it, something is wrong with the scope.
The biggest schedule risk is almost never the code. It is access: data extracts, network rules, accounts and security reviews. Start those requests on day one, before you think you need them.
Running the lifecycle in practice
- Keep a one-page engagement tracker: current stage, exit criteria, open risks, next decision date.
- Hold a short stage-gate review with the sponsor at each transition. Present results against the criteria you agreed — not a feature list.
- Record decisions in a decision log so later stakeholders understand why things are the way they are.
Case interviews often start mid-lifecycle: "The pilot has been running for three months and usage is low — what do you do?" Locate the stage, check the exit criteria, and diagnose adoption before touching the technology.
Senior Full-Stack Engineer · AI & AWS. I turn ambiguous customer problems into production systems — cloud, data and AI.