Three things. If you have all three you are ready to brief a build. If you are missing one, the deployment will stall in a way that is entirely predictable from here.
One: two specific ticket types, named
Not "customer service". Specifically: bill queries arriving by email, and tier-one router troubleshooting on WhatsApp. Or coverage checks from web chat and post-purchase order status.
If you can name two, you have a brief. If the only answer is "all of it", nobody can scope the work and the build will sprawl until it is bad at everything.
The instinct to launch across every channel and every query type at once is the single most reliable way to produce a deployment that underperforms on all of them. Start narrow, get one excellent, add the next.
Two: customer data in something queryable
A CRM, a database, a helpdesk. Anything the agent can look a customer up in by phone number or email and get back a coherent record.
Messy is fine. Disconnected is not. If a customer's history lives across three systems with no shared identifier, that needs joining first. The AI build will not fix that problem. It will make it very visible, usually in front of a customer.
Three: one person who owns it for ninety days
One. Not a committee, not "the ops team".
Not their full-time job, but their named project. They sit in the weekly review, they decide when the agent's behaviour should change, and they are the person to call when something needs a judgment.
This is the one people skip, and it is the one that decides whether the thing still works at month six. Deployments without an internal owner go stale within a month of launch, because the world keeps moving and nobody is watching the gap open.
What you do not need
A perfect knowledge base. Existing help docs, policies and past tickets are enough raw material to start from, and the tidying happens during the build.
A technical team. Integration work sits with whoever builds it. What you need from your side is someone who can grant system access without a two-week wait.
Certainty about ROI. You will not have it before you start, and anyone offering you a precise figure in advance is guessing. What you can have is a narrow first scope where the result will be unambiguous either way.
If you are missing one
Spend the few weeks fixing it rather than starting anyway.
A build that begins before the data is joinable, or before anyone owns it, does not fail fast. It fails slowly, four months in, having consumed budget and goodwill. That is a much more expensive way to learn the same thing.
