Home›
Customer Service

AI in customer service: why inbox gains plateau

3 September 2026
VerifiedVerified & Reviewed
AI in customer service spans automated replies, agent copilots, intent routing, sentiment analysis and QA scoring. Deployed inside the inbox it cuts cost per conversation. Applied to operations it cuts the number of conversations, which is where the gains stop plateauing.

How AI is actually used in customer service

AI in customer service covers a spread of applications: automated replies and conversational agents, agent copilots that draft and summarize, intent classification and routing, sentiment analysis, quality assurance scoring, and knowledge-base generation. Most e-commerce brands now run at least one of these, usually reply automation or a copilot.

The adoption pattern is consistent. Teams start where the tooling is easiest to deploy, which is inside the helpdesk, and get a genuine but bounded result.

We did not start Keeyu because we wanted to build AI. We started because e-commerce operations is broken: stockouts not flagged until it is too late, delivery delays discovered after customers complain.

Every order is a promise. Keeyu keeps it. Most AI deployments improve how you talk about a broken promise.

Why the gains plateau

AI applied inside the inbox reduces the cost per conversation. It does not reduce the number of conversations, because ticket volume is created by events that happen outside the helpdesk entirely.

Helpdesks and AI chatbots wait for the customer's query and then triage the problem. They do not fix operational issues. That is why we built an AI agent that spots and fixes the operations issue before the customer notices, instead of a smarter way to answer the complaint about it.

At Papinelle complaint tickets ran at 110% of order volume, and essentially all of them were about orders. Deploy the best available reply automation across that queue and you have a cheaper way to service a business where more things go wrong than go right.

The plateau is structural. You can optimize handling indefinitely and never touch demand.

The applications that change demand

The uses of AI that reduce ticket volume operate on the operation rather than the conversation:

  • Detecting orders that have stopped progressing across store, warehouse and carrier
  • Classifying what kind of break occurred and what the remedy is
  • Executing the remedy: cancel, reship, refund, redirect, file a claim
  • Notifying the customer before they notice, with the fix already moving

At EHP Labs an out-of-stock workflow that took the team 45 minutes now runs in five. Reactive tickets fell 55%, resolution time went from 45 minutes to 5, and the CX function went from 18 people to 8.

The out-of-stock workflow shows what that looks like end to end: triggered when the warehouse types 'out of stock' into NetSuite, it searches other stores for inventory, finds product alternatives, checks the ERP for next shipments, and if no replacement stock exists, cancels the order and processes the refund.

The applications that change demand are the ones that start with detection. Phase 1 of Keeyu made it easy to detect operations issues in real time, and fixing them was still manual. Visibility just moves the pressure onto the team, and retailers who had been happy sweeping unhappy customers under the rug now had a list to fix. It only worked once we automated the fix. Deployments that begin at the reply are optimizing the last step of a process they never instrumented.

Where the hard part actually is

The language model is not the difficult component. Reading a situation and drafting a sensible response is largely solved. The difficulty is access and judgment: getting reliable data out of systems that were never designed to be automated, and deciding what to do without being confidently wrong at scale.

Most ops tools fail here because they assume stability, and e-commerce is chaos. I have seen phase 2s stretch 12 months, sometimes forever, and by then the business had bolted three new systems on top. I signed a couple of customers and then we discovered we could not build the integration, as I said on Give it a Nudge. So our CTO Tahir built a browser operator that reads data from systems with no usable API. That is unglamorous work and it is what determines whether an AI deployment covers your real stack or only the modern parts of it.

The browser operator opens the browser the way an agent would, reviews the information, takes photographs, and converts them into usable data. It constantly scans carrier portals like Royal Mail for tracking data when an API connection cannot be built.

On judgment: building the agent, our immediate customer learning was that the user needs enough friction to feel like the pilot, not the passenger. Routine cases execute automatically, unusual and expensive ones go to a person with the diagnosis already done.

We learned this the expensive way. We tried to build our automations on off-the-shelf agent tooling, LangChain and LangGraph, and it failed, so we went back and built our own deterministic engine, and we are on the third attempt at that layer. I said so on The Breakout CEO. We are running financial transactions and inventory, and a language model can easily hallucinate. Imagine a shopper who should get a $1 refund getting $1,000.

How to evaluate a deployment

Ask what metric it moves. If the answer is deflection rate or handling time, it is an inbox tool and it will plateau. If the answer is exception rate or customer-detected rate, it is operating on the cause. I watch teams measure first response time, resolution time and customer satisfaction score, and if those three are good they think they are crushing it. They are fixing a problem no customer wanted, and doing it well. I call that backwards thinking.

Both are legitimate purchases. Just be clear which problem you are solving, and do not expect an inbox tool to change how many customers have a bad experience.

Evaluate it against the size of the category it should be shrinking. Customer service exists because things go wrong, so the bigger prize is the discipline that stops them going wrong, which is what I argued on The Growth Concept. A deployment that answers faster is competing inside the old category rather than reducing it.

Where this sits

This is proactive e-commerce operations. Detect. Decide. Act. The customer gets what they want, on time, as promised.

See how the workflows run or book a demo.

For the tooling category, read AI customer service. For agents specifically, see AI customer service agent. For the helpdesk layer, read helpdesk automation.

Frequently Asked Questions

How is AI being used in customer service?

Today, mostly four ways: answering common questions, assisting human agents with drafts and summaries, classifying and routing tickets, and, most recently, detecting and fixing the operational problems that cause tickets in the first place. The first three live in the inbox. The fourth lives in operations, and it is the only one that reduces ticket volume.

Is AI replacing customer service?

It is replacing the repetitive parts: status questions, routine refunds, standard notifications. It is not replacing the conversations that need a human. The practical shift is that support teams stop answering 'where is my order' and start handling the interactions that actually build loyalty.

What are real examples of AI in customer service?

Inbox examples: auto-drafted replies, intent routing, sentiment scoring. Operational examples: detecting an order that never synced to the warehouse, canceling and refunding an oversold item automatically, and rebooking a lost parcel before the customer notices. At EHP Labs an out-of-stock workflow that took 45 minutes now runs in five.

References

Keep the promise.

See how Keeyu catches and fixes post-purchase issues before customers notice.

In one call, we’ll map your operations and show how Keeyu detects issues, decides what needs to happen, and takes action across your existing systems.

We’ll confirm your integration requirements and rollout plan during the demo.