Conversational AI Consulting: How to Scope a Chatbot Before You Build One

Most chatbot projects that fail did not fail in the build. They failed two months earlier, when someone decided what the bot would do without measuring what it needed to do. Conversational AI consulting is the short, unglamorous engagement that prevents that, and it is worth understanding what it should produce before you pay for it or skip it.

What a scoping engagement should produce

A deflection baseline. Pull your last three to six months of support conversations and classify them by topic. Some topics are fully resolvable by a grounded bot: order status, password resets, policy questions, booking changes. Some need a human every time. The share in the first group is your deflection ceiling, and it is the number the whole project will be judged on. Measure it before you build, or you will be arguing about it after.

A channel decision. Where do your customers actually contact you? Across the Gulf the answer is WhatsApp before anything else; in the US and Europe it is more often web chat and email. A bot built for the wrong channel deflects nothing. The channel also determines length limits, formatting and latency expectations, so it shapes the build rather than decorating it.

A data and systems audit. Does your help centre content actually answer the questions customers ask, or is it written for a different audience? Can your order system, booking platform or CRM be read from, and written to, by an external service? These two questions decide whether a bot can be grounded and whether it can act, and the answers are frequently no in ways nobody expected. Fixing them is often the real first project.

A written scope with a fixed price. Channels, question scope, integrations, the human handoff boundary, the evaluation set, and a number. That document is what makes vendor quotes comparable, and it is what you hold the build to.

Why this is cheaper than skipping it

A two-to-three-week scoping engagement typically costs a fraction of the build and changes the build materially. The most common outcome is that the scope narrows: the bot should handle four topics well rather than twelve badly, or it should start on one channel rather than three. The second most common outcome is discovering that the content or the integrations are not ready, and that the honest first project is fixing those.

Both outcomes are far cheaper to reach in week two than in month four.

What we look at, specifically

Conversation volume and topic distribution from your real history. Resolution rates and handle times per topic, so the deflection value has a dollar figure. Content coverage, which questions your existing material answers, and which it does not. System access: which platforms expose an API, which need an integration layer, and which are effectively closed. Language mix, which across our Gulf clients means Arabic and English switching within a single message, and across our Pakistani clients means Urdu, Roman Urdu and English. And the regulatory constraints on where conversation data can be stored, which decides hosting before architecture.

When you do not need it

If you have one channel, a small and repetitive question set, content that already answers those questions, and no need for the bot to act in any system. You can probably scope it yourself in an afternoon. That describes fewer businesses than assume it does.

A scoping engagement, week by week

The first week is listening. We read a sample of real conversations, support tickets or call transcripts, several hundred if they exist, and sort them by what the customer actually wanted. We talk to the people who handle them now, because they know which questions are easy and which are traps. We look at the systems the answers come from and check whether they have APIs. The second week is writing. The output is a document of perhaps fifteen pages: the ranked list of intents with volumes, the ones the bot should handle and the ones it should not, the systems it must connect to and how, the handoff rules, the evaluation set, a rough architecture, and a phased plan with a price for each phase. The client can take that document to us or to anyone else. Some do.

The intent list, and why volumes matter

The single most useful artefact from scoping is the intent list with counts. It usually shows that five to ten intents make up seventy percent of volume, and that a long tail of dozens makes up the rest. The bot should handle the head of that distribution well and hand off the tail gracefully. Teams that skip scoping tend to build for the interesting cases and neglect the boring high-volume ones, so the bot is impressive in a demo and useless on a Monday morning. The counts also set the business case: if order status is thirty percent of contacts and the bot can resolve it, the value is calculable before a line of code exists.

What we find that clients did not expect

In most scoping engagements, something in the first week changes the plan. Commonly: the knowledge base the bot was going to be trained on is out of date, and the support team has been answering from memory and a shared document nobody mentioned. The order system has no API, only a screen, so the most valuable intent needs an integration project first. A third of contacts are in a language the client had not planned to support. Or, best of all, the top intent turns out to be a question the website could answer with one change, and no bot is needed for it. Each of these is a week's discovery that saves a quarter's build.

Scoping for the Gulf and for regulated industries

Two situations make scoping more important, not less. For clients in Saudi Arabia, the UAE and Qatar, the scoping has to settle Arabic and English handling, dialect versus formal Arabic, data residency, and which channels matter, which for most Gulf consumers means WhatsApp before web chat. For banks, clinics and insurers anywhere, it has to settle what the bot may say and what it must never say, what is logged and for how long, and who reviews the conversations. These decisions are cheap in a document and expensive in a rebuild, and they are the ones a vendor eager to start building is most likely to skip.

What it costs and what it removes

A scoping engagement with us runs $1,600 to $3,200 and takes two to three weeks. It removes the two most expensive risks in a chatbot project: building for the wrong intents, and discovering the missing integration after the build has started. It also produces a document you can put out to tender. If we go on to build, the scoping fee comes off the build price. If you go elsewhere, the document is yours. That arrangement is only possible because scoping is genuinely separate from building, and a vendor who will not separate the two is telling you which one they are selling.

What comes next

The scope is yours. Take it to any vendor, or to us. We build AI chatbots at a fixed price against exactly this kind of document, and our broader AI consulting practice runs the same discipline across larger AI programmes. If the scoping shows that what you need is a system that takes actions rather than one that answers questions, our AI agent vs chatbot comparison explains the difference, and our note on custom chatbot development services covers what the build itself should include.