Scope and boundaries

“We can't put it live until it's connected to the back-office system”

The sentence turns up early in almost every project, and it sounds responsible. It is also why a fair number of voice agents never make it out of a meeting room.

IngridIngrid,
Two colleagues sit at a desk in a small back-of-house warehouse office at blue hour, talking over a printed sheet, while a third woman stands blurred behind them with a telephone handset to her ear in front of the window onto the racking

The sentence usually arrives in the third meeting, from someone who owns the systems:

“We can't put it live until it's connected to the back-office system.”

Nobody argues. It sounds like the opposite of rushing. The integration becomes a scoping exercise, the scoping exercise joins a queue in a department that doesn't own the phone number, and the phone rings exactly as before for another six months.

The objection isn't nonsense. It is just true in a much narrower way than it gets used.

Why it sounds sensible

Three reasons, and all three are honest.

The demo showed a lookup. Almost every voice agent demo contains the same moment: the agent looks up an order and reads back the status. That is the part people remember afterwards, and it puts the integration in the middle of the product.

It is the part that can be assessed. An IT function asked about a voice agent has few footholds for judging conversation design or voice quality. Interfaces, access control and data processing are familiar ground. The question moves to where somebody can answer it.

The alternative sounds bad. “An agent that can't look anything up” sounds like an answering machine with better grammar. Nobody wants to defend that in a meeting.

The assumption underneath

The claim smuggles in something it doesn't say out loud: that a voice agent's value is proportional to how much of your data it can reach.

That is worth testing against the calls you actually get.

What the caller wants What the agent needs access to
What does it cost? Are you open on Saturday? Where are you based? Nothing beyond what is already on your website
I'd like to book an appointment, or ask for a site visit Write access to one calendar
I need to speak to Sarah An extension, and a rule for what happens when she doesn't pick up
Where is my parcel? What is this line on my invoice? A read lookup in the back-office system, with caller identification
I want to change the address on my contract Write access to the customer record

The top three rows need no back-office connection at all. How much of your volume sits there is something you won't know until you look – and finding out needs no integration either. Listening through a week of calls and sorting them into the rows above is enough. Some of them turn out to be questions that were only asked out loud because the answer wasn't published anywhere.

The order that costs least

Each step below costs roughly an order of magnitude more than the one before it – in contracts, in testing, and in what can go wrong once something does. That is the argument for the order. Not caution.

No integration. The agent answers, informs, takes a message and transfers. The only thing that has to be properly settled here is what triggers the handover and what the human is told.

One write: the calendar. This is usually the integration that changes most for the money. A booked appointment is a finished call, and it is easy to count.

One read lookup. This is where the hard part starts, and it isn't about the interface. To read anything back about a customer, the agent first has to know who it is talking to, and identifying someone over the phone is its own problem with its own failure modes. That is the work that takes time, not the connection.

Write access to the customer record. Last. For many, never.

Where the objection is right

Three cases where waiting is the right call.

Where the call is the transaction. If the customer is ringing to block a card, report a claim or check whether a prescription is ready, there is no useful answer outside the system. An agent without access is just one more step on the way to someone who has it.

Where a wrong answer is expensive. If the agent says something about price, cover or a deadline that doesn't match the system, you haven't saved a call. You have created two.

Where everything ends with a human anyway. If the agent transfers nine calls in ten because it can't answer anything, you have built a slower switchboard. Better to settle that in advance than discover it after three months – and it is exactly the kind of question a pilot should be set up to be able to answer no to.

And a fourth case, which is less comfortable: if you already know the integration will never be prioritised, the question isn't whether to wait. The question is whether an agent that answers a third of the questions is worth anything. It often is. But then it should be a choice somebody made, rather than something that simply happened.

What waiting actually defers

It is worth being precise about what happens in the meantime.

Integrations rarely take a long time because they are technical. They take a long time because they sit in a queue held by people with different priorities from whoever owns the phone number. In the weeks the agent waits for an interface, the phone rings as it did before – and none of the calls that went unanswered in the meantime come back later.

Threll.ai builds voice agents in Norwegian, Swedish and Danish. We are happy to connect the back-office system. We just tend to suggest the phone gets answered first.

Related Articles

Continue reading more articles