Integrating Grace: A Collaborative Deployment Experience

Deploying an AI agent into a utility contact centre is not a self-service exercise, and we do not pretend otherwise. It is a joint project between your team and ours, and the parts that decide whether it goes well are decided early.

Here is the shape of it.

Step 1: Scoping the call mix

Before anything is built we work out which calls Grace should take, which she should route, and which she should never touch.

That means going through your actual volume rather than a generic list. A water utility’s month is dominated by billing questions and service starts; an electric utility’s worst weeks are outage-driven. The right first scope is usually narrower than people expect — a small number of high-volume call types, done properly, with everything else routed to staff untouched.

We also agree the hard limits here: emergencies, and anything else that must always reach a person.

Step 2: Connecting to your systems

Grace works against your systems of record, so this step is about API access, not data movement.

Your CIS and billing platform stay where they are. Nothing is migrated, and we do not take a copy of your customer database — Grace queries your systems live, during the call, the same way a CSR’s screen does. Where a platform is one we already integrate with, much of this is already built.

Authentication, network access, and which operations Grace is permitted to perform get agreed and documented at this stage, and the permitted set is enforced by the platform rather than by the conversation.

Step 3: Configuring the conversation

This is where your policies get written down, often for the first time.

Grace is configured rather than coded — how she introduces herself, what she is allowed to say, when she must verify a caller, what the rules are for payment arrangements and deposits and final bills. She is not trained on your historical call recordings; the behaviour comes from explicit configuration, which is what makes it reviewable and changeable later.

The useful side effect is that the process surfaces the rules that currently live only in experienced staff members’ heads.

Step 4: Testing and UAT

We build a test suite of real situations — the awkward ones as much as the common ones — and your team runs them.

Your staff are the right testers here, because they know what a correct answer sounds like and they know which callers are difficult. UAT is where scope gets tightened: almost every deployment finds at least one call type that should be routed to a person instead.

Step 5: Going live, gradually

Go-live is usually a percentage rather than a switch. Off-hours first, or a share of overflow, with the proportion rising as the numbers hold up.

Every conversation is reviewable from day one, and staff can take a conversation back at any point.

Step 6: After go-live

The first weeks produce the most useful information you will get, because real callers do things test scripts do not.

Conversations are reviewed, flagged where they went wrong, and the configuration is adjusted — usually weekly at first, then less often. Scope widens from there: the second and third call types are much faster than the first, because the integration work is already done.

Why it works this way

We could ship a console and let you configure it yourself. We do not, because the decisions that matter — what Grace is allowed to do, when she must stop, what the correct answer is to a question about a deposit — are decisions that need your people and ours in the same conversation.

That is the part utilities tell us they value, and it is why deployments tend to land where they were supposed to.