Why did the customer have to reach out?

I was running the chatbot at a financial services company. I thought customers would use it more if they could do more with it. I looked for common support requests and proposed adding new scenarios.

The team responsible for the service declined. The app and automated phone system already offered those services. Adding them to the chatbot would give the team another channel to maintain.

That made me wonder what higher monthly chatbot usage would mean for the company as a whole. If customers could already do the same thing in the app, would the new scenario help them get something done or just move them to a different channel?

Then a more basic question occurred to me. With both an app and an automated phone system, why were customers still calling?

I started following what happened before the call. Under “view transaction history,” some customers could not see a recent payment, while others could not find the information they needed. In one case, customers needed records for a specific period and in a format they could use for tax filing. Giving them a way to get those records themselves changed what they had to call for.

I began judging the chatbot by what it helped people finish. That left me wondering how many other problems I was missing when I read only a handful of inquiries.

While planning an AI system for support agents, I tried structuring conversations around the customer’s situation, request, and the action taken. I hoped we could see patterns across more conversations and bring concrete cases to the teams that could make changes.

Before looking abroad, I had only my own experience to go on. I wanted to see whether support teams elsewhere could take what they found to the people who could change the service, and whether those people would act.

I initially wondered whether the difficulty of getting other teams involved was particular to the companies or market I knew. Looking at Cresta, United Airlines, CVS Health, and NiCE, I saw accounts that went beyond supplying software and described changes to how work was done. I also found accounts where discovering a problem did not lead to action.

I wanted to bring a team both the number of customers affected and examples showing where they got stuck. The count would help the team judge the scale. The conversations could show which part of the service might need to change.

Conversation intelligence could help me show where customers were getting stuck. I still needed to understand how anyone could take responsibility for what it revealed. That question sent me back to the period before AI.

The more specialized a company becomes, the less likely it is that one team can change every step a customer goes through. I wanted to find out how companies had assigned responsibility for the whole problem when each team was responsible for only part of it.

As a company grows, one customer’s problem can cross product, policy, and operations. I wondered whether specialization helped explain why action stalled. I followed voice-of-customer and CRM records back through the 1990s to the 1980s and 1960s. Companies were already trying to use complaints in decisions well before AI.

When I read accounts of companies investing in VOC and CRM, I began looking for a second piece of evidence. After the problem reached management, was anyone assigned to make a change, and did the company check whether the change helped?

Reading about Amazon and DBS shifted my attention to how responsibility moved across teams. A reported result tells me what the company says happened at one point in time. To understand whether the practice survived a reorganization or could work elsewhere, I would need to look for different evidence.

I could ask a team for help and explain why the change mattered. To make that work repeatable, I would need to know who could decide, whose capacity the work would use, and who would follow up after it was done.

That made me take the case for ROI seriously. Teams need a way to choose where limited resources go. I also wanted to know what we were counting as value. If customers can finally get the outcome they signed up for, what does that change for them, and what might it change for the business beyond handling costs?

I began asking two questions in that order: what outcome should the customer be able to get, and what would let a company keep delivering it? Answering the second meant identifying who could authorize the work, commit resources, and check what changed.

Once, when I asked another team to help fix a customer problem, I was told they had no capacity because they were working on acquiring new customers. I wondered if the two kinds of work had ever been weighed against each other. A proposal can be set aside before anyone gets to estimate its impact.

The tax document case gave me a concrete way to think about value. A customer could get a usable document and finish filing. I wanted to ask what completing that task meant for the customer and the business, alongside any savings in handling time.

Seeing AI check information and take action in work systems made me revisit the original call. If a company can recognize that a customer is in a situation it has handled before, could it offer to help before the customer has to explain it?

I now distinguish two kinds of work. When a product or process creates an avoidable inquiry, change the cause. When the need depends on a customer’s situation, test whether the company can recognize the conditions, propose a specific action, get consent, and follow up if the issue persists. A case may need both.

I began separating three decisions I had been treating as one. Teams need a place to review a problem together, a reason to commit time to it, and a clear action someone can take. A meeting can help with the first decision while leaving the other two open.

If people regularly call because the document they need is unavailable, I would look for a way to make it available. If the need only arises when an individual customer’s situation changes, I would test whether we can recognize that situation and offer the right next step.

These are designs I want to test. I want to see what evidence is enough to act, who can make the decision, and whether the customer actually gets the expected result. What I’m working toward is a way to keep delivering that result as a company grows and its teams specialize.