By Alexey Spas
Between January and April 2026, Gartner surveyed 1,303 senior executives and found that in 2025 businesses put 12% of their AI budgets into service and support processes. That is more than into any other business function studied. Yet only 24% of respondents confirmed positive financial returns.
What does the absence of returns in 76% of cases tell us? The answer is the definition of what counts as the result of the work. The share of requests closed without reaching an operator, response time, and the number of closed tickets show us the speed of the department’s work, but they don’t answer the question of what the company gains from that work.
And it can gain quite a lot, because of the very nature of the process. Let’s have a look. Previously an operators answered the user’s question, and the knowledge of that request stayed in their head, leaving nothing behind. An agent, on the other hand, has to break the request down into steps (category detection, priority, routing to the right team, drafting a reply, checking that reply against company policy) and record every one of them: what was asked, in what words, how many times a month, where it got stuck, where the knowledge base contradicts itself. This is how data about different aspects of the product, customers and their problems, and the company itself appears. It is a valuable information artifact that can be put to further use.
In systems built this way, the support department turns into a diagnostic instrument that shows plainly what the company knows about itself and what it does not. And it helps to fill the gaps.
AI customer service has become the richest source of data for various departments
AI customer support agents collect much more information than the user’s question itself: they record customers’ wording, how often issues repeat, the point at which it couldn’t provide an answer, and gaps in the knowledge sources. The most informative part of this log is where the agent could not provide an answer. This occurs in three situations: when the available knowledge, policies and documentation contain no answer; when they contradict each other; or when the question lacks the necessary context. In all three cases, the agent has found an issue that was never classified and for which no decision was ever made. This is the gap that already exists within the company, which the customer has now encountered. From there, the data can be interpreted and used differently depending on who is reading it.
- Product teams can find the weak spots in the product’s logic or interface that force customers to contact support. What is valuable here is precisely the number of requests for the same problem: if there are many of them, the product has a problem.
- Marketing teams can catch the language the product’s audience speaks, the wording it uses, what it expects and where those expectations different from reality. The customer’s view of the product and the marketing department’s view do not always coincide.
- The sales department can find readiness signals and objections that used to get lost between channels. The same data feeds AI agents in sales.
- The support team can assess the quality of the knowledge base: where the agent found no answer, where it found an outdated one, and so on.
- Legal can identify the edge cases that existing policies or contracts do not yet cover. That is excellent food for thought and could save the company from potential trouble in the future.
In turn, management receives a set of open questions about the product and company that are important to customers. This provides a wealth of ideas and insights for future development.
However, the mere presence of data does not guarantee success on its own. Very often, problems arise from improper collection, storage, or use of data.
What usually gets in the way of AI customer support adoption?
Having different departments analyze and assess the information coming from AI customer support agents genuinely makes practical sense. Otherwise, the company risks encountering issues similar to those experienced by the Cursor vibe-coding service. In April 2025, users began being thrown out of the system when they moved between devices. A support agent named Sam explained this as a subscription limitation that supposedly allowed use on a single device only. In reality, however, the company had no such policy – the AI agent had made it up. As a result, users started cancelling their subscriptions.
Another case is the reverse one, where AI agents ignore instructions: In February 2024, the court ruled in favour of Moffatt v. Air Canada, holding the airline liable for its chatbot contradicting its own published policy. Air Canada had the answer in the database, but for some reason the agent did not use it, and Cursor did not have one, but the agent made it up. In a ticket queue both cases look identical: like a missing article in the knowledge base, although a closer look would show the difference. The cause lies in the data.
Almost all the difficulties encountered in AI support projects are related to the data.
- fragmented CRMs, where the history of a single customer is spread across several systems;
- a knowledge base updated on a leftover basis, with several versions of the same policy;
- inconsistent categorisation of tickets, whereby identical requests have been placed in different categories for years.
- product documentation that lives separately from the knowledge base and is written for engineers;
- isolated systems with no common access layer, because of which the agent physically does not see half of the context.
Sinch’s report The AI Production Paradox for 2026 states: 74% of organisations that launched an AI agent for customer communications rolled it back or shut it down because of a governance failure. Among those who consider their processes fully mature, this figure is higher — 81%. The explanation is that companies with well-established processes see data problems more often and sooner, where the rest of them miss them.
This is a practical conclusion that should be accepted before the project starts. An effective AI support agent is the result of a well-built data ecosystem. As long as the data is fragmented, accelerating automation merely accelerates the appearance of errors.
How to build AI support that scales with your business
The decision to scale up is typically made before any agent logic has been written. As data preparation can account for 60–75% of the effort required for a project, it is better to start with an inventory of the knowledge ecosystem and a taxonomy of requests than with model selection. This is the stage at which most companies first discover things that they have never previously categorised. In an Instinctools project for an online store, this inventory produced 14 broad request categories and 75 subcategories that no one had spelled out before, and introduced a compliance agent that checks the refund policy.
The next step is a pilot in a specific, high-volume domain (a section of live traffic or a replayed historical dataset), in which the agent’s responses can be verified against a recognised standard. From day one, guardrails must be in place: confidence thresholds will determine when the agent acts alone and when it hands over to a human. Every action will be logged in an audit trail. Without this record, any rollback would result in lost experience.
The most often forgotten element is a process for questions that cannot be answered using the company’s systems. Such questions should be taken outside the support queue and directed to the people authorised to set policy. They should result in a decision rather than the agent improvising. Regulated industries have long worked this way. In finance, for example, anyone can submit a question to the IFRS Interpretations Committee for which the standard provides no clear answer, and receive a reasoned response within a set timeframe.
Scaling up then becomes a matter of repetition. Each new domain or channel follows the same process: prepare the data, run an observed pilot, measure and then expand.
Conclusion
AI in support gives two things at once. The first is the speed and volume of request handling, which is usually why the project is launched. The second is continuous measurement of what the company knows about its own product, customers and rules, with the gaps sorted by how often customers run into them.
The second part takes longer to pay off and costs more, but it is precisely what turns support from a cost centre into a source of management decisions. The difference between companies will be not in whose agent answers faster, but in who reads this diagnostic instrument and takes open questions through to a decision.
