A customer writes "where is my order". The answer already exists in your company: it sits in the shop, in the warehouse and in the carrier system. It is just that somebody has to assemble it by hand, from three windows, every single time. An automatic answer to "where is my order" does not come from a smarter reply template. It comes from letting the model read what the operator reads.
The work nobody wants
Mornings on a small e-shop support desk look the same. Forty messages in the inbox and a good half of them ask the same thing. The operator pastes the order number into the admin, checks whether the goods were picked, opens the carrier page, reads the last scan, and types two sentences.
One reply takes two or three minutes. On its own, nothing. Fifty times a day it is half a job that nobody enjoys and that leaves nothing behind. Meanwhile the customer waits from morning to afternoon for a fact your warehouse already knew yesterday.
Twenty messages with the same question before lunch, and twenty nearly identical answers. Only the parcel number changes.
— A Monday on customer support, abridged
What connected actually means
On its own, Claude knows nothing about your order 24187. It is not a database and it does not get access to anything just because it is clever. Until you open one specific door into one specific system, all it can do is write nicely.
That door is an MCP server. A small program that sits between Claude and one of your systems and turns a question into a request that system understands. One for orders, one for the warehouse, one for parcel tracking. No copy of your database, no export uploaded into somebody else"s service. Claude asks live and gets exactly what a person would see at that moment.
Concretely: the shop, the warehouse and the carrier
Take an ordinary Czech setup. The shop on Shoptet, stock and accounting in Pohoda, parcels through Zásilkovna and Česká pošta. Today those three worlds only talk to each other through a human switching tabs. You change none of it and you migrate nothing. You add one bridge.
- Finds the order by number, by e-mail, by name, or from the sentence "I ordered those boots last week".
- Reads the stage: received, paid, picked, handed to the carrier.
- Pulls the last carrier scan and translates it into a human sentence, including the fact that "delivered" at a pickup point means the parcel is waiting to be collected.
- Checks the ticket history for what the customer was told before.
- Drafts the reply in the tone you actually write in, and leaves it for approval.
As an illustration: a two-person support desk handling fifty parcel-status questions a day spends roughly two hours on this routine. When only checking and sending is left, it is twenty minutes of work. Nobody lost a job. The two-hour hole moves to the complaints that genuinely need a person.
What this will not do, and why that is good
It will not promise a delivery date it has nowhere to get. If the carrier has not scanned for three days, the bridge says so plainly instead of inventing an estimate. It will not decide on compensation, on waiving a cancellation fee, or on sending a free replacement. Those are decisions about money and about a relationship, and they belong to a person.
That limit is the reason the pattern can be trusted. A component that may only read and propose cannot cause damage you discover a month later in a statement. A person still presses send. Instead of assembling facts, they do the part nobody else can do: they decide.
What it would take
You start with one system, usually the shop, because that is where the order number lives. The bridge runs on your infrastructure, under your sign-in, with your log of who asked what. This is not a year-long project. The first useful version is a matter of days, not quarters. Then the carrier and the warehouse follow, each separately, each with its own rights.
What is left
The model is not the bottleneck. Claude can already write a decent reply to a customer and nobody is waiting on that. The bottleneck is the distance between Claude and the data your company has had all along: the order number in the shop, the picking status in the warehouse, the last scan at the carrier. That distance is what we close.
If "where is my order" is the sentence that costs your support desk the most, write to us. A short call is enough to work out which three systems your answer is assembled from, and which one is worth bridging first.