Who experiences the problem? Customer, agent, operator, or manager?
loading…
By delivery model, I mean the chain from the business outcome to the work, risks, rollout, and operating plan.
A customer may say, “We want an AI support agent.” Do not design from that sentence. First learn what support work is failing today, who feels the pain, and what result would justify changing the workflow.
Who experiences the problem? Customer, agent, operator, or manager?
What is slow, expensive, risky, or frustrating today?
What measurable change would make the project worthwhile?
Too vague to estimate Build an AI assistant for support.
Specific enough to scope Reduce average ticket resolution time from 12 minutes to under 5 minutes, without increasing escalation rate or customer complaints.
Now the engineering questions have a purpose. Which ticket types count? Is the system read-only, or can it change an account? What errors are tolerable? Where must a person approve the result? The answers determine both architecture and rollout.
A demo, a 20-user pilot, and a production service are three different projects. Name the delivery level before anyone quotes a date.
| Level | Purpose | Typical standard |
|---|---|---|
| Prototype | Prove that the idea may work | Manual setup, narrow data, happy path only |
| MVP | Deliver value to a small real user group | Auth, core workflow, basic error handling, simple operations |
| Production | Run reliably for real customers | Security, monitoring, support, rollback, scale, compliance, recovery |
Ask this before discussing dates “When you say done, do you mean a demo, a pilot for 20 users, or a production release?”
Before you estimate Delivery starts with a measurable outcome and a shared definition of done.