How to scope an AI system before you build it

AI demos are easy to love. You type a question, a sensible answer appears, and it feels as if the hard part is done. It rarely is. The model is the part you can see. Most of the work, and most of the risk, sits around it.

Scoping is how you bring that hidden part into view before anyone writes code. A good scope fits on one page and answers five questions. If you cannot answer them yet, that is useful to know too.

Start with the job, not the tool

Write down the decision or the piece of work the system should improve. "Answer customer questions about delivery" is a job. "Use AI in customer service" is not.

Then say what good looks like for the people who will use it every day. Faster replies? Fewer mistakes? Less time reading documents? If nobody can describe good, it is too early to choose tools.

The one-page brief

These five fields are enough to compare suppliers, estimate honestly and spot trouble early. We fill one in at the start of every AI project.

• The job: the decision or task it improves, in one sentence.
• The data it may touch: which sources, and how long anything is kept.
• When it must not guess: the topics where only a checked answer will do.
• When it fails: what the person sees if the model is wrong, slow or offline.
• Who runs it: the named person who watches quality, cost and incidents.

Plan for the moment it is wrong

Every model is sometimes wrong, and every service is sometimes down. The question is not whether, but what happens next. A system that knows its limits protects your reputation far better than one that is right slightly more often.

Decide which questions it may answer on its own, which go to a person, and what it says when it cannot help. Write those rules into the brief, then test them with real examples before launch.

Integration is where timelines slip

Name the systems the AI has to work with: sign-in, storage, your CRM, your phone system, your ticketing tool. Each one is a door that has to open the right way, for the right people, every time.

Connecting to them is usually more work than the AI itself. A scope that says "connects to our systems" without naming them is a scope that will grow.

Someone has to run it

After launch, somebody has to watch the answers, the costs and the complaints, and decide what to change. A pilot nobody watches becomes a liability the week real people start using it.

Where we have done this

We engineered AnswerBug for EVS7: an AI receptionist that answers calls in production, every day. The model was the smallest part of the work. The job, the boundaries and the running of it were the rest.