Here is a pair of numbers worth sitting with. Around 88% of contact centers now have some form of AI in place. Only about 25% have it running in daily operations. Almost everyone has bought it. Three quarters are not really using it.
That gap is usually explained as a training problem or a change management problem. The 2026 research points somewhere else, and it is a much more boring answer: the AI cannot see enough of the business to be useful.
The number that explains the other numbers
Bought is not the same as running, and the distance between them has a cause.
Puzzel’s State of Contact Centres 2026 research found that the average team runs 3.9 separate contact center technologies, and only 3% operate on a single unified platform. Three percent. That is the number that makes the adoption gap make sense.
Think about what four disconnected systems does to an AI feature. The dial outcome lives in the dialer. The customer history lives in the CRM. The recording lives in a third system, and the ticket lives in a fourth. Any task that needs two of those at the same time either fails or gets handed back to a person.
So the AI ends up confined to the things one system can do alone. Transcribe this recording. Summarise this ticket. Those are real conveniences and nobody minds them, but they are not what anyone approved the budget for, and they are not enough to change how a day runs.
Meanwhile the pressure to show something keeps building. Gartner found 91% of customer service leaders under executive pressure to implement AI. Pressure plus a fragmented data path produces exactly what the numbers show: fast purchasing, slow adoption.
Why a tool that is usually right gets ignored
There is a second failure mode that follows straight from the first, and it is the one that quietly kills pilots.
When a model can only see part of the picture, it guesses at the rest. It is right most of the time, because most cases are ordinary. Being right most of the time sounds fine until you look at what it does to the person using it.
A tool that is right most of the time gets checked every time. The agent reads the suggestion, then opens the CRM to confirm it, then acts. That is slower than just opening the CRM. So after a few weeks they stop reading the suggestion, and the feature is technically live and functionally dead. It is in the 88% and not in the 25%.
Trust here is not a soft factor. It is a straightforward calculation the agent is making about whether verification costs less than doing it manually. Fix the data path and the calculation flips.
The research keeps landing on agent workflow, not self-service
The order most teams buy in, and the order the returns actually show up in.
Verint’s 2026 research found the highest returns in agent workflow rather than customer self-service. That finding keeps recurring across different studies, and it keeps getting ignored, for a reason that is easy to understand.
Self-service is the part that looks like a headcount saving. It has a clean business case you can put on one slide. Agent workflow improvements look like helping people do their existing jobs slightly better, which is a much harder thing to write a number next to before you have done it.
But the self-service case has a measurement trap in it. Deflection is easy to count and easy to misread. A call the bot handled without a transfer counts as deflected, whether or not the customer called back an hour later, gave up, or emailed instead. Teams declare a win on the deflection number, then find total contact volume did not move, then blame the model and start shopping for a better one. That is how you end up with a fifth system to integrate.
The agent workflow route starts smaller. The AI drafts the summary, suggests the next action, and pulls the relevant history in before the agent asks. It needs less autonomy to be useful, and crucially it fails safely, because a person is reading everything it produces. But it needs the joined-up data that self-service also needs, which is why doing it first is the right order rather than a compromise.
Get the order right
Three steps, in this sequence.
First, put the call outcome and the customer record somewhere a tool can read them together. That is not a platform migration and it does not mean ripping out four systems. It means one place where a query can join what happened on the call to who the person is. If that place does not exist, nothing you buy next will work properly, no matter how good the model is.
Second, point AI at the agent’s work. Summaries, next-action suggestions, quality scoring across the whole call volume instead of the two calls a supervisor had time to listen to. These pay quickly and they generate the labelled outcome data you need for anything more ambitious.
Third, automate the calls that never needed a person, once you can prove from your own data which ones those are. By then you are automating a category you have measured, not a category a vendor deck told you exists.
Done in that order you finish with fewer moving parts than you started with. Done in the usual order you finish with more.
Three questions before the next purchase
These are worth asking any vendor, and worth asking about tools you already own.
Can it read the outcome? If the tool cannot see how the last call ended, it is guessing at the next one. Ask specifically how it gets the disposition, not whether it integrates.
Can it write back? A tool that only reads produces a report. A tool that writes back changes what happens on the next contact. This is the difference between an analytics product and an operational one, and the demo rarely makes it obvious.
Who owns the join? If the only place your call data and customer data come together is inside the vendor’s platform, you have rented your data path along with the model. Switching costs then grow every month, and the thing you would be switching away from is not the AI, it is the integration.
That last question is where self-hosting earns its keep. When the dialer runs on your own infrastructure, the call records, dispositions and recordings sit in a database you control, and you decide what reads them. Our write-up on open source cloud call center software covers what that looks like in practice.
Where ICTBroadcast fits
Worth being precise here, because vague AI claims are part of the problem this article is about.
ICTBroadcast integrates with Google Dialogflow. That means you build the conversational agent in Dialogflow, with its intents and flows, and ICTBroadcast handles the telephony side: placing the calls, managing the campaign, and recording what happened. The integration is the connection between the two, not a separate AI engine bundled into the dialer.
Why that matters for everything above: the campaign data, call outcomes and recordings stay in your ICTBroadcast installation on your own server. The conversational layer is a component you chose and can replace. Nobody else owns the join between what the agent said and what your business knows about the customer.
ICTBroadcast also ships a REST API by default, which is the practical mechanism for step one. If the outcome data needs to reach your CRM, or your CRM needs to feed the dial list, that is an API call rather than a support ticket. We covered the API in more detail in the SP Edition REST API post.
What to do this week
Count your systems. Just count them. Dialer, CRM, ticketing, recording, quality, reporting. If the number is around four, you are average, and the average is where the adoption gap lives.
Then pick one question your team asks often that needs two of those systems to answer, and time how long it takes to answer today. That number is your integration debt, expressed in a unit anyone can understand. It is also the thing your next AI purchase will run into.
Frequently asked questions
Why do most contact centers have AI but not use it daily?
Because the data the AI needs is split across separate systems. Research puts the average team on 3.9 different contact center technologies with only 3% on a unified platform, so anything requiring two systems at once either fails or gets escalated to a person. The tool then gets used only for single-system tasks like transcription.
Is agent-facing AI really a better first step than self-service?
Verint’s 2026 research found the highest returns in agent workflow rather than customer self-service, and that finding shows up repeatedly. Agent-facing tools need less autonomy to be useful, fail safely because a person reviews the output, and produce the outcome data that later automation depends on.
What is wrong with measuring call deflection?
Deflection counts calls the bot finished without a transfer. It does not count the customer who called back later, gave up, or switched to email. Check total contact volume over the same period instead, because that is the number that reflects whether work actually went away.
Does ICTBroadcast include an AI voice agent?
ICTBroadcast integrates with Google Dialogflow, so you build the conversational agent there and ICTBroadcast handles call placement, campaign management and recording. The AI capability comes from the Dialogflow side, and the integration connects it to your telephony.
What does it mean to own the join between call data and customer data?
It means the place where a call outcome gets matched to a customer record is infrastructure you control, rather than a vendor’s platform. If only the vendor can perform that join, replacing them means rebuilding the integration, which is usually a larger job than replacing the AI model itself.
Do we need one unified platform to get value from AI?
No, but you do need one place where the call outcome and the customer record can be read together. That can be achieved with an API and a shared datastore. The point is a readable join, not a single vendor.
Related resources
- Gartner’s $80 Billion Call Center AI Forecast: The Fine Print
- Open Source Cloud Call Center Software
- Self-Hosted Auto Dialer Software
- ICTBroadcast SP Edition: REST API Included by Default
Where to go next
If counting your systems produced an uncomfortable number, the first move is a readable join between call outcomes and customer records, not another platform. ICTBroadcast runs on your own infrastructure with a REST API included, so the campaign data stays somewhere you can query and connect. Tell us which systems you are trying to join and we will help you work out the shortest path. Open a ticket at service.ictinnovations.com.