Choosing an AI partner for the contact centre is no longer just a technology decision. It is an operational, commercial, and customer experience decision that can quickly fail when outcomes, ownership, and human escalation are not clearly defined.
In this live CCCS London 2026 panel, three senior customer service leaders share the buyer-side realities of AI adoption, including what should be non-negotiable, when to stop a weak pilot, how to compare pricing models, and why the strongest AI deployments are built around partnership rather than software procurement.
Opening Remarks and Introductions
Good morning again.
Just to give you a quick introduction to myself, my name is AB, and I head Product and Operations at Cobotics.
The topic for today’s panel discussion is this: if you are looking to partner with an AI vendor, what exactly should you be looking for?
As leaders, all of us are speaking about AI almost every day. It comes up in nearly all our conversations. The important part, therefore, is figuring out the practical playbook. When we are having these conversations and trying to find the right AI partner, what should we evaluate?
Today, we have an amazing panel. All three speakers come from different domains, and they will help us understand what enterprises should actually be looking for.
I will pass it over to them for a quick introduction and perhaps a brief perspective on where they are in their AI journey today.
Hi, everyone. My name is Alex, and I am from Thrive Homes. I am the Customer Service Manager.
I have a mid-sized team, which is growing at the moment because of a merger that has just taken place with another company. We are effectively doubling in size.
The future is still somewhat uncertain, and we are very much at the beginning of our AI journey.
Good morning, everyone.
My name is Chris Brown, and I am Head of Customer and Communications at Capper Brown Utilities Limited.
The clue is in the title. We are a construction company focused predominantly on the utilities industry.
We have a slightly unusual dynamic because I effectively have two sets of customers. One is my client, which currently happens to be a large water company. The other is the millions of customers served by that water company.
That means anyone can become a customer if they pass through the area, so it creates an interesting dynamic.
My background is with BT. I used to run contact centres, both outsourced across Europe, the Middle East, and Africa, and internally within BT Retail and BT Global.
That is me.
Hi. Good morning, everyone.
My name is Rachel. I currently live in Dubai, which is why I am dressed for summer and freezing here.
I have spent the last 30 years working across a wide range of industries in customer service, contact centres, customer experience, and sales.
I currently work for a digital bank in Dubai. It is only three years old, so it is a startup, somewhat similar to the Revolut model.
Before that, I worked across many industries. I worked in telecommunications in the UK for T-Mobile and Orange, around the time EE was being created. I was part of the design and launch team for the EE brand.
I have also worked for Virgin Trains, Expedia, Intel, Weight Watchers, Qatar Airways, and several other companies.
The core principles of customer experience management, understanding how to manage customer expectations, and balancing AI, technology, and human support have always been central to everything I have worked on.
I am happy to be here and share some experiences with everyone.
Thank you so much for being part of the panel.
To give you some context on why this topic is relevant to me, I have actually been on both sides.
I spent more than 15 years heading contact centre operations. We scaled those operations from zero to what is now an organisation of more than 20,000 people, running contact centres across the US and UK.
For the last two years, I have been on the product-building side. I am now involved in building conversational AI and conducting demonstrations for enterprises and contact centre leaders.
So, I have seen both sides. It is very interesting for me to understand what happens on the enterprise side and what happens on the vendor or product side.
Today, we are trying to answer a central question: when you are on the enterprise side, what exactly should you look for?
On that note, the first question I would like us to discuss is this:
If you were choosing an AI partner today, perhaps for a current project or an upcoming initiative, what would your non-negotiables be?
AI is an interesting topic because many people are afraid of it, or they imagine it to be something that it may not actually be.
An AI tool can be many different things. It does not necessarily need to be a large language model. It could be a process agent or another form of support tool.
For me, at the moment, I am looking for something that works with the people I already have.
I work with a relatively small team, especially compared with some of the organisations discussed here. I want something that complements their humanity and acts as a tool, rather than something that takes over their work.
In social housing, it is very important for us to retain the human element.
What I am looking for is essentially a helper or a servant. That is perhaps an awkward way of describing something that feels almost human, but I want something that works with us and for us.
That would be my non-negotiable.
That is a very good point.
Chris, what are your thoughts?
For me, a non-negotiable in any pilot would be outcomes.
I have been in situations where you see the technology, listen to the pitch, understand what it could offer, and immediately begin thinking of all the ways it could improve your contact centre or service team.
Then other teams become involved. Sometimes it is a PMO or another internal function. Very quickly, the pilot or trial can begin moving away from the original concept.
That is why outcomes are non-negotiable for me.
I want to know whether it does what it says on the tin. Am I going to get value from it?
The technology may be brilliant. We may all admire how technically impressive it is. But is it actually doing anything for my customers? Is it improving the experience?
That is what matters.
Over the years, the best approach for me has been to stay out of the technology and focus on what I am good at, which is customers and people.
I am not a technical person. I do not know JavaScript or any of those things.
I keep it very simple. I say, “I want this to do these specific things for my people. Does it do them or not?”
That is what I want to see during the trial.
How close can it get to the desired outcome? Is there a clear roadmap for getting there?
Ultimately, I just want it to get me where I need to go.
That is a very interesting point about separating the technology from the customer experience, while making sure neither one is forgotten.
In the project I worked on, the AI vendor had already been selected before I joined.
What made the project successful was the relationship we built with the vendor. Both sides were easy to work with, and we eventually became one team.
We were a remote team because we were based in different locations, but everyone had a clear role. We had the CTO, the CCO, and the other relevant stakeholders.
At the same time, everyone understood the ultimate goal, which was to improve the customer experience.
It was also a lot of fun. Both sides learned a great deal along the way.
It became a strong partnership.
As I mentioned, I was not part of the original selection criteria because the vendor had already been chosen before I joined. I think we were fortunate that the vendor we partnered with was capable of delivering a very good outcome.
That makes a great deal of sense.
It is also why I tend to use the word “partner” rather than “vendor.”
Even when I was on the operations side and evaluating different suppliers and vendors, we would often refer to them as partners.
The most important question is whether they can become part of your operations, understand the operation properly, and work hand in hand with you.
It should not be a transactional relationship where the supplier simply says, “Here is the product. My job is done.”
That leads us to the next part of the conversation.
We have discussed what a good partner should look like. Let us now flip the question.
Chris, you mentioned that many vendors give excellent demonstrations and present very strong initial outcomes before the pilot begins.
What would be the two or three signs that make you pull the plug within the first two or three weeks?
You should not have to wait six months or a year to discover that something is not working.
When the demonstration was great and the pilot has started, what tells you that the solution is not going to work in production?
For us, it would come back to the output.
If our customers suddenly began saying, “What are you talking about? I do not understand this,” it would become very obvious very quickly that something was wrong.
Customers would be confused almost immediately. CSAT scores would begin to fall.
I think we would see that within a week, and that would probably lead us to pull the plug.
It is a difficult question because it depends on the solution, the commercial structure, and what you are trying to achieve.
I remember one particular pilot where it became clear quite early that it was not going to deliver what had been intended.
There were several reasons for that.
To a certain extent, you have to trust your instincts. You know what you are trying to achieve.
It also depends on whether you are the decision-maker or the end user. Even if you are not the decision-maker, but you are the person who will actually use the software or service, you are heavily invested and will quickly understand whether it is working.
One important factor for me was user acceptance testing during the pilot.
You need the people who are going to use the solution to be involved.
In the case I am referring to, the product was a new graphical user interface. It included several widgets and buttons designed to make the CRM functionality of a well-known software platform work more smoothly and intuitively during customer interactions.
That was the idea.
However, two problems became evident very early.
First, the feedback from my team was poor. The interface was confusing, and the team did not understand what they were testing or why they were being given certain scripts.
Second, the standard IT test scripts were evaluating the solution from the perspective of technical reliability, robustness, and sign-off.
They were not testing what I needed as an end user, or what the customer needed in terms of actual improvements.
That takes us back to deliverables and outputs. What is the solution really going to deliver?
It became obvious in the first week.
By the second week, we needed to recover quickly, which becomes a programme governance issue.
We had some very direct conversations with the development team and realised the solution was not going to do what we needed it to do.
However, we were already invested by that point. The PMO was involved, the IT department was involved, and the budget had been approved.
Sometimes these projects begin to snowball and move beyond your control.
We needed it to deliver, so we continued with it.
Ultimately, it did not deliver what we wanted.
From personal experience, poor user feedback and a failure to test against customer and operational outcomes are strong early indicators that a pilot is in trouble.
That makes sense.
Rachel, what was your experience?
There is a great deal of commonality.
The project I worked on was quite unusual because of the customer base.
We launched four AI bots for customer service on a trading platform.
The four languages were English, Russian, Chinese, and Farsi, which were relatively unusual languages for this type of deployment.
For the proof of concept, we launched all four at almost the same time.
The initial business case was mainly focused on deflection rate and cost per contact. That was how success was originally going to be measured.
However, I strongly argued that CSAT also needed to be one of the core metrics.
We established a daily comparison between CSAT for the bots and CSAT for the human agents.
While the bots were live, the contact centre agents were still operating, so we were constantly comparing deflection rates and satisfaction scores across both channels.
That became one of our most important measures of success.
We quickly discovered that the Chinese-language bot was deflecting fewer contacts and receiving lower CSAT scores than the human agents.
There was a cultural issue.
The Chinese-speaking customers simply did not like speaking with the AI, even though it could answer their questions accurately and quickly.
The customers did not enjoy the experience.
At that point, the question became: cost per contact may be good and deflection may be high, but are we at risk of losing a significant proportion of our customer base?
In trading platforms, Chinese customers often invest substantial amounts in gold, and some of the transaction values are extremely high.
The risk of losing those customers was too great.
We adjusted the programme accordingly. It was working well in Russian, Farsi, and English, but not as well in Mandarin.
It became a test-and-learn process.
We had completed user acceptance testing with our own employees before launch, but it was only when we rolled the bots out to a larger group of real customers that we began to see these issues.
We did not switch off any of the bots, but we made it very easy for customers to speak with a live agent.
At no point did we prevent a customer from reaching a human.
Now that I work in banking, I understand that many organisations take the opposite approach and make it extremely difficult to speak with a live agent.
The digital bank I currently work for has taken a completely different approach.
Customers can reach a human at any point.
We use AI to support them and improve the experience if they choose to use it, but we do not force them.
That is a very important and interesting point.
We are seeing the same thing repeatedly.
It is no longer a choice between humans and AI. In most cases, it is a combination of both.
You cannot simply tell customers to speak with AI and accept whatever response they receive.
At the same time, you cannot say that humans must continue to do everything.
More and more discussions are focused on finding the best of both worlds.
Alex and Chris, are you seeing the same thing?
Yes.
I previously worked for a large online retailer during the early days of chatbots.
We were experimenting with things such as Facebook bots, before they were supported by modern AI models.
What we saw was customers typing “MANAGER” repeatedly, often in capital letters, until they managed to get past the bot.
It is about identifying the point where the customer clashes with the bot and trying to avoid that.
AI systems are more sophisticated now, and you can allow customers to leave the AI interaction and speak with an agent or adviser at any point.
That makes the experience much better.
It is very interesting because you can often tell which businesses are using AI primarily to drive efficiency and savings, and which are using it to improve customer experience.
In Rachel’s example, the project was clearly being driven by customer experience.
The question was not simply, “Can we switch this off?” It became, “How can we make it easier for the customer to reach an agent?”
By contrast, in some parts of the banking sector, it is extremely difficult to reach a human.
It becomes obvious that the business case has been built around preventing agents from taking calls.
In those cases, the primary goals are call reduction and channel shift.
That distinction is important.
We did not reduce the size of our customer service team during that project.
We launched the four bots but kept the same number of agents.
The roles of the agents changed slightly.
The bots handled many of the FAQs and simpler scenarios.
The human agents then handled more complex trading questions, especially situations where customers were losing significant amounts of money.
Trading is a highly emotional environment, and the bots were not able to handle every situation appropriately.
The humans focused more on customer retention, and potentially on upselling and cross-selling.
We also created new roles within the contact centre.
One of our agents became what we informally called the “bot manager.”
Her role was to manage the bot flows and review performance data, including deflection rates and the topics being handled by the bots.
The QA and training teams also became involved in different ways.
The QA team was evaluating the bots as well as the human agents.
It created an entirely new dynamic within the team.
The work became more interesting, and people became less afraid that AI was going to replace them or leave them without a job.
That was not what happened.
In fact, it created several new roles that had not existed before.
That makes sense.
Let us now discuss the commercial side.
There are many commercial models available when selecting an AI partner.
These may include pricing per minute, per outcome, per resolution, per licence, a platform fee, or many other creative structures.
What do you think makes the most sense for an enterprise?
I do not control all the budgets where I work, so perhaps I can say whatever I want.
We use many different external companies for different services.
For example, we have an out-of-hours team that we pay by the minute.
I sometimes find that type of model restrictive, especially if budgets are low or there is a broader budget issue.
As I mentioned earlier, we have recently gone through a merger.
Budget has therefore become a major topic of discussion across our teams, and the purse strings have been tightened.
I would prefer something more accessible, perhaps a platform fee or a similar arrangement.
I am not sure whether the others have more financial oversight than I do.
Please do not tell Thrive anything I have said today.
My answer is broadly similar.
It depends on the platform or solution being developed, the size of the contact centre or operation, and the wider commercial setup.
Whether a flat fee, transactional fee, or per-minute model is best depends on the situation.
I would probably distinguish between a managed-service fee and a pay-per-use model.
Again, it depends on what you are doing.
There is one solution I am currently exploring that uses AI to engage with communities.
We are trying to move beyond what I call transactional customer service.
Transactional customer service is when somebody buys something, has a problem, needs a password reset, or has another relatively simple, one-and-done interaction. These contacts often produce a high level of satisfaction because the issue is straightforward.
In utilities, however, anyone who passes through the client’s operating area can be considered a customer by the regulator, particularly if they contact the company.
That contact may be unwanted. They may have seen roadworks, a company vehicle may have driven over their garden, or there may have been an accident.
That contact may become a complaint and may negatively affect CSAT.
So, I need to move beyond reacting to customers who contact us.
I need to reach entire communities before they contact us.
That creates some unique challenges.
For that journey, a managed approach makes more sense.
I want to partner with a company, brand, and solution that will remain with me throughout the entire process, rather than simply providing off-the-shelf software.
This solution will need to be built from the ground up, so the relationship is much more of a partnership.
I also do not know what the volume will be. I do not know how many interactions it will generate or how many components we will need.
That is why managed services make sense in this case.
However, if you are running a traditional contact centre and have reliable forecasts for calls, web chats, and other contacts, then you can be more precise about the transactional cost.
There is another important commercial issue.
How many people in this room have full budget control over contact-centre technology?
It appears only a few do.
In our industry, contact centres are often viewed as cost centres.
That is how the finance team tends to see us.
It can be difficult to build a business case with a strong return on investment, and the decision may not always be ours.
We often regret not being involved early enough in the discussion or in vendor selection.
My advice would be to get involved in the decision-making process as early as possible.
Build relationships with the finance director, commercial director, or whoever controls the budget.
Help them understand the journey, because they are not necessarily experts in customer experience.
We need to guide them.
That makes sense.
Rachel, how did the commercial model work in your project?
In our case, the commercial terms were initially based on usage tiers.
The tiers were linked to the number of conversations deflected or retained each month.
Nobody knew how successful the project would be, so we had several thresholds, such as up to 30,000 conversations, up to 50,000, and up to 70,000 per month.
That was how we started.
However, we became more successful than expected and reached the top of the tiers very quickly.
Within the first three months, we were already deflecting approximately 40,000 chats per month through the bots.
We had exceeded the original tier and needed to move to the next one.
That led to some back-and-forth discussion with the commercial team about moving towards something more like an unlimited broadband package or an all-you-can-consume model.
Eventually, that is what we agreed.
It was in both our interest and the vendor’s interest to move to that model.
Cost per contact had been one of the initial measures.
The goal was not necessarily to reduce cost, but to optimise it.
We were very successful.
At the last calculation I completed, the average cost was approximately 50 cents per chat handled by the bot, compared with around $2.50 for a conversation handled by an agent.
That cost varied across languages because different language teams had different salary structures.
Russian- and Mandarin-speaking agents, for example, received higher salary packages than English-speaking agents.
Therefore, cost per contact varied between teams.
We learned a lot about commercial structures throughout the process.
As I said, the primary goal was never simply to cut costs.
It was to manage the customer experience effectively.
We also paid an ongoing monthly platform fee in addition to the usage tiers.
That is very interesting.
We have three leaders and three different models: a platform model, a usage-based model, and a managed-service model.
The answer is clearly not one-size-fits-all.
It may be a combination of different approaches, depending on the organisation, its operating model, and its workflows.
Every organisation is structured differently.
That brings us back to the importance of partnership.
The AI partner needs to understand the organisation, understand its preferences, and adapt accordingly.
On that note, I would like to open the discussion to the audience.
If anyone has a question, an experience to share, or a point they would like the panel to address, please feel free.
Peter?
Thank you.
Several of the points you made really resonated with me.
I have approximately 25 years of experience in telecommunications, specifically with BT.
For the last six months, I have been working in the water industry for a well-known company in the southwest.
I have seen how advanced AI had become in my previous environment, and that contrasts strongly with my current organisation, which is only taking its first tentative steps into AI.
It is clear that we need to accelerate our AI journey quickly.
However, we are already partnered with one vendor.
Do you have any experience working with multiple vendors?
How well do they work together?
Would you recommend using multiple vendors or staying with one?
I compare it with my wedding. I had a photographer and a videographer from two different companies, and they kept getting in each other’s way.
I would be interested in your thoughts.
I do not have much direct experience with that scenario.
In the project I have been discussing, we only had one vendor, and we were fortunate to work very well with them.
At the company I am currently with, we are building much of our AI capability internally.
We have recently hired a large team of AI specialists, many of whom are recent graduates and know far more about the technology than some of us with longer careers.
I am interested to see how that develops.
However, I have not personally managed a situation where multiple AI vendors were working on the same customer-service solution.
We are not far enough along in our journey to have direct experience either.
However, many of the vendors we currently use for other services have suddenly added AI functionality.
A service they provided previously now has an “amazing AI capability” that we can add if we choose.
AI is moving very quickly, and many organisations are trying to enter the space.
Your photographer-and-videographer example makes sense because those two roles were very similar and could easily interfere with one another.
AI is much broader.
It depends on which tools you need and what you are trying to achieve.
If the vendors are solving different problems, they may not interfere with each other.
The important thing is finding vendors that can build connectors and APIs for your existing software.
You also need to stay close to the process.
It is still a relatively mysterious industry, with many technical teams appearing quickly, building solutions, and moving on.
You need to stay involved throughout the journey.
That makes me think about separating the problem into different areas.
What are the pain points, and what are you trying to solve?
When I think about it, we did have different vendors, but they worked in completely different areas.
One handled client onboarding, KYC, and document verification.
Another worked on servicing.
Another supported sales.
The vendor I have been discussing was primarily focused on customer service.
So, multiple vendors can work in parallel if they are solving clearly separated problems.
Is your situation specifically within the contact centre, or does it extend across the organisation?
It is within the contact centre.
Is the contact centre in-house or outsourced?
Both.
The point about what we are trying to achieve is important.
Unfortunately, I want to have my cake and eat it too.
I want to deflect contacts, but I do not want to compromise customer service.
There are different parts of the contact centre.
Billing is relatively predictable and can be forecast.
Operational incidents, such as burst pipes, are much less predictable.
So, the challenge is finding out whether one solution can fit everything.
It is an interesting and difficult time.
Are you considering another vendor because your current provider is not delivering the results you expected?
Or is the second vendor intended for a completely different project?
I think it is both.
As Chris said, the solution needs to do what it says on the tin.
What we are seeing is that the current provider delivers part of what it promised, but access to additional capabilities requires separate add-ons.
Those add-ons create unplanned costs.
That is what is prompting the question about whether we should bring in another vendor.
I can give you an example from a previous role.
I had 26 contact centres across Europe, the Middle East, and Africa.
They operated in different languages and countries, serving different customer groups, but all supporting the same products for the same client.
There was a similar challenge.
We needed continuity while also managing multiple stakeholders and different vendors.
What worked for us was retaining ownership of the customer, the customer journey, and the customer experience.
If you stay true to that, all the vendors have to work around that central principle.
Rather than trying to dictate exactly what happens in the technology space, you say:
“This is my customer. This is the customer journey. I own it from end to end. You will not interfere with it unless I am satisfied that the change supports the outcome we have agreed.”
That allows you to bring all the vendors together and say, “This is what we are collectively trying to achieve.”
You can also include requirements in the contracts.
I remember clauses covering information sharing, access to platforms, and technology interoperability.
Those clauses prevented us from becoming ring-fenced or overly dependent on one vendor.
That worked well because some vendors did not operate in every country.
A vendor might provide excellent technology in one market, but the same technology would not be available elsewhere because they lacked the local footprint or operating capability.
There needed to be a mechanism for sharing and integration.
That creates intellectual-property issues, which is where the commercial and legal teams need to support you.
Those are excellent answers.
Are there any other questions?
You mentioned contact centres operating in different countries and chatbots interpreting different languages.
How do you manage the balance between automation and human judgement?
With NLP and sentiment analysis, how do you correctly classify the customer’s sentiment?
For example, a customer may use language that sounds insulting or negative, but they may not actually be directing it at the agent.
How do you ensure the system does not classify a satisfied interaction as DSAT simply because the AI misinterpreted the language?
How does the dataset work in that situation?
Do you have experience managing this?
That is a very good question.
We had some amusing experiences, even with our English-language virtual assistant.
We were not supposed to call them bots. We called them virtual assistants.
Many of the English-speaking customers at the trading company were based in Nigeria.
The way they spoke English was different from the form of English the virtual assistant had originally been trained to understand.
That made the project very interesting.
The vendor came to visit us and spent time with our teams.
They listened to customer calls and reviewed chat transcripts.
Together, we built a much deeper understanding of how non-native English speakers communicate compared with native English speakers.
It helped us shape the persona of the virtual agent.
The system needed to understand the customer’s persona, the way they spoke, their intention, what they were trying to achieve, and how they phrased their questions.
Older bots worked in a very structured way.
They might ask, “Do you want to deposit? Do you want to withdraw?”
But customers do not always speak in that structured manner.
We had some very funny scenarios while learning how customers actually communicated.
Using native speakers was essential.
Our QA team included native speakers for the different languages.
I do not think you can do this properly without that level of linguistic expertise.
In my 26-country example, sentiment analysis was not as advanced at the time, so it was not as significant an issue.
However, your question raises an important point.
How often do we analyse the analysis?
That is probably the core issue.
You may need a native language expert to review the results.
In the outsourcing environments where I have worked, teams spent significant time validating the sentiment analysis.
They updated the algorithms, involved the technical teams, and continuously adjusted the system to improve accuracy.
Otherwise, the data becomes useless.
What has your experience been so far?
My experience was not particularly good.
I ended up listening to many of the calls again manually.
There were different pronunciations and interpretations.
We tried to adjust the algorithms so the system could recognise bad language and classify whether the customer was rude, aggressive, or frustrated.
However, the classification was often inaccurate.
The overall sentiment might be marked as DSAT because the customer used strong language at the beginning of the call.
By the end of the interaction, the agent may have resolved the situation completely, but the system still gave the call an amber or negative score.
That change in sentiment is what I wanted to understand.
The NLP did not work well enough for me to recommend it.
However, I am still very interested in the technology, not only from a cost-reduction perspective.
It could potentially automate or re-engineer many aspects of quality control across calls, chats, and other channels.
I wanted to know whether the technology is working well for anyone else or whether everyone is still manually reviewing the results.
I think we are still in an experimental period.
My fiancée was, until recently, a localisation manager for a food-related company.
Her work increasingly involved reviewing how AI systems translated content and handled transcreation.
Transcreation is not simply translating one phrase directly into another language. It is understanding what that phrase means to a customer in a particular country or culture.
For example, in Arabic-speaking countries, a direct translation might begin with “dear” because of the way expressions such as “habibi” are used.
You still need a human being with genuine language expertise to say, “That expression means something different in this country,” or, “That is slang with a particular cultural meaning.”
I do not think AI will fully replace that for a long time.
During a live chat or phone call, the customer’s sentiment may change several times.
They may begin the conversation swearing and end it by saying, “Thank you so much. I am not angry with you. I am angry with the company or the situation.”
At that point, you want to retain the customer.
But the AI may focus on the profanity at the beginning and classify the interaction as negative.
That is why you still need human oversight.
We are not replacing QA yet.
We also need to be careful that we do not become data trawlers instead of customer-service experts.
How many people here spend time analysing sentiment data or other forms of customer feedback?
It appears quite a few do.
That is one of the risks.
We can create so much data, feedback, and verbatim content that we become data-rich but information-poor.
We may spend all day going through data without actually getting the job done.
I completely recognise the issue you are describing.
The answer to your question summarises much of this discussion.
It needs to be a combination of AI and human oversight.
From our experience deploying solutions for larger enterprises, the first requirement is a QA layer.
You cannot have an isolated AI agent claiming to be 100% accurate and then allow it to handle every conversation without supervision.
You need an AI quality layer that continuously monitors the AI agent.
For example, we use 100% automated QA and then provide a dashboard based on the QA results.
That allows teams to monitor outcomes daily and in real time.
It highlights the main areas of opportunity and creates a feedback mechanism for the developers to improve the AI agent.
The system cannot be perfect on day one.
Sentiment should also be tracked in real time.
As you said, the customer’s sentiment at the beginning of the call may be very different from their sentiment at the end.
From a customer-experience perspective, what matters is how the call ended.
If the AI can move the customer from irritated or frustrated to satisfied, that is a major success.
The challenge is making sure the change is measured.
Real-time sentiment tracking can show that the interaction began negatively and ended positively.
Those calls then become valuable training examples because they demonstrate the type of conversation the AI should learn to replicate.
Is your AI conversational across all omnichannel interactions?
Can it support genuine two-way communication, including some informal conversation or light banter?
Or is it primarily transactional, where it asks for an ID, completes verification, and moves directly through the process?
How does it work?
I will give a quick answer because we are almost out of time.
We are omnichannel.
The technology has reached a stage where the experience can be designed according to the customer’s requirements.
For B2B conversations, many customers want the experience to remain transactional.
They do not want longer AHTs or unnecessary discussion.
In those cases, a short and direct interaction makes sense.
For inbound customer-support calls, however, the organisation may want the experience to be more conversational.
They may want customers to feel good about the interaction.
The system can support both approaches.
We have successfully implemented multilingual solutions across markets including Australia, Egypt, the US, and the UK.
The technology is now capable of delivering these outcomes, although it still requires extensive testing.
There must also be a human layer.
Even when you have 100% automated QA, someone still needs to review the QA results, interpret the findings, and return that feedback to the developers so they can improve the system.
To summarise, thank you all for being so candid and detailed in this conversation.
It has been very helpful for me, and I am sure it has been valuable for everyone here.
The main takeaway is that successful AI implementation requires a combination of several things.
There are different commercial models.
It is not only about the AI agent. You also need the QA layer.
You need a strong human handoff, ideally with context, because customers should not feel as though they are being blocked by a wall.
It is a combination of technology, people, processes, governance, and commercial alignment.
Most importantly, organisations need to find the right AI partner.
“Partner” is the key word.
The provider must understand the organisation, understand the business workflows, and shape the outcome around those requirements.
On that note, thank you again to all our panellists.
Thank you to everyone who joined us and contributed such interesting questions.
This was a great session.
