AI and Customer Service: Unify Channels, Automate Triage

This article is part of our guide to AI by industry. It tackles a very concrete problem: customer service scattered across too many channels for one person to keep a full picture.

Why do customer requests slip through the cracks?

Today's customer writes by email, fills in a form on the site, opens a chat, leaves a review on a marketplace, or calls directly. Each channel has its own tool: an inbox, a CRM, a marketplace back office, a review module. Nothing connects them.

The result: the same person can send an order-tracking email, a marketplace message and a phone call about the same request, handled by three different people with no shared history. First-response time stretches out, not because teams are working badly, but because volume outgrows what a channel-by-channel setup can absorb.

This isn't specific to one sector. We see it as much in e-commerce as in more traditional trades, for example in customer service as seen from a hospitality floor, where booking requests and online reviews pile up in exactly the same way.

How do you centralise channels without rebuilding everything?

The right approach isn't to replace your tools, it's to connect them to a shared analysis layer. Each channel (inbox, form, chat, marketplace, reviews, transcribed calls) stays in place, with a connector feeding every new request into a single hub.

Technically, this kind of connection increasingly relies on open standards like the Model Context Protocol, which lets an AI agent read and write across several systems without a custom integration for each one. That reduces the cost of getting started and makes it easier to add a new channel later.

For a business that sells online, this work often overlaps with product and order data. On the storefront side, syncing product and order data is the same logic applied upstream: without clean, accessible data, AI has nothing reliable to analyse on the customer-service side.

What does AI actually do once channels are centralised?

Once messages are pooled into a single flow, AI analyses them one by one, before a human ever opens the first one. Three things get extracted systematically.

Intent: order tracking, after-sales, a carrier dispute, a pre-sale question. This classification automatically routes the request to the right queue, without an agent having to read it first to work out what it's about.

Urgency: a blocked delivery doesn't wait as long as a general product question. AI prioritises based on keywords, mentioned deadlines and the type of request, not raw order of arrival.

Sentiment: a neutral message and one that expresses real frustration don't follow the same path, even when the underlying intent is similar. This is the signal that triggers, or doesn't trigger, a priority escalation.

Which requests can be handled automatically?

Repetitive, low-risk requests are the first candidates: order status, an estimated delivery date, an answer to a standard return question. These are factual answers, with no room for negotiation or judgement, where the agent can send a prepared reply built directly from the customer's real data.

Which requests go out as a draft for human approval?

Once a request touches an open-ended after-sales issue or a situation that calls for context (customer history, tone to adjust, a possible goodwill gesture), AI prepares a full reply with the context gathered, but an adviser reviews it, adjusts if needed, and sends it. The time saved is real: the adviser isn't starting from a blank page, they're validating work already done.

How does escalation to a human work?

Escalation shouldn't leave anything to the AI's judgement at the point of decision. It runs on rules set in advance, applied the same way to every request.

Three triggers come up systematically: an explicitly mentioned dispute (a carrier issue, a contested faulty product), negative sentiment past a defined threshold, or a refund request that falls outside the standard scope. In all three cases, the AI doesn't attempt a reply, it hands the case to an adviser with the history and context already gathered, so the customer doesn't have to explain everything again.

This split between automatic handling, a validated draft and human escalation follows the same principle detailed in what a customer service AI agent can actually do: the AI's scope is defined before deployment, not decided case by case once it's live.

What has this looked like in practice?

At Babykare, a childcare e-commerce brand we co-run, a customer-service agent of this type is in production today: it centralises inbound requests from every channel, analyses each message (order tracking, after-sales, carrier disputes), prepares a reply and either submits it for approval or sends it, depending on the risk level.

The principle that makes this viable day to day is simple to state and harder to hold to: every type of request has a clear rule, known in advance, about what goes out directly and what goes back through a human. Nothing is left to the AI's judgement in the moment. That discipline, more than the technology itself, is what prevents bad surprises.

Which safeguards are non-negotiable?

The first safeguard concerns personal data. A customer request contains information about an order, sometimes an address or partial payment details. The CNIL, France's data protection authority, is a useful reference here: it stresses that any AI processing of personal data must stay proportionate, documented and limited to what's necessary to handle the request. That means a professional tool, not a consumer product that might reuse that data for other purposes.

The second safeguard is brand tone. A generated reply should sound like the business sending it, not a generic assistant. That gets set up in advance, with example replies, and checked regularly, not just at launch.

The third safeguard is a hard ban on automatic replies for sensitive topics: a contested refund, an already unhappy customer, anything touching product safety. These always go through a human, with no exception configured to save time.

The last point is continuous quality measurement: the rate of automated replies validated without correction, average response time by channel, and the escalation rate. Tracked over time, these numbers tell you when to widen the automated scope, and when to tighten the rules instead.

Where should you start?

The safest sequence starts small: one channel, one low-risk request type, escalation rules written down before the first automated reply goes out. You measure, adjust, then extend to other channels.

For a small business operating in France, this work can start with a funded diagnostic: Bpifrance's Diag Data IA scheme (the French public investment bank's AI diagnostic programme) covers 40% of the cost, leaving a net cost of around €6,000 excl. VAT, open to SMEs and mid-sized companies with 10 to 2,000 employees. This diagnostic identifies which channels and which requests to tackle first before investing in integration.

Once the scope is defined, the question becomes technical: connecting AI to your CRM, your inbox and your sales channels without weakening your existing systems. That's exactly what integrating AI into your business systems covers: the architecture, access and security of this type of project.