Ferrari, a children's hospital, and two different answers for the same customer
In 2003, two doctors from Great Ormond Street Hospital in London — cardiac surgeon Martin Elliott and intensivist Allan Goldman — were coming back from a conference and caught a Grand Prix on a hotel TV. They watched a pit stop: seven people, three seconds, not a word spoken. Nobody asked anybody what to do.
They had a specific problem at the time. Not in the operating theatre — the surgery was going well. The problem was in the lift and the corridor. A child comes off heart surgery and is moved to intensive care. What has to be handed over is the patient, three infusion pumps, a ventilator, drains — and everything the surgeon knows that the intensivist doesn’t yet. Twenty people in a small room, all talking at once, each doing their own job. And something goes missing, routinely.
Instead of hunting for a better protocol in the medical literature, they wrote to Ferrari.
Ferrari wrote back. Nigel Stepney from the F1 team watched recordings of the hospital’s handovers and pointed out what was obvious to him: your problem isn’t speed, your problem is that nobody knows who’s in command. In a pit stop there is one person who watches the whole thing and doesn’t touch the car. The London team went to Maranello, and two former airline captains, Trevor Dale and Guy Hirst, joined in afterwards — that’s where the checklist came from.
The new protocol had three parts: a clearly designated coordinator, a fixed sequence (equipment first, then information, questions last), and a sheet listing what had to be handed over.
They published the results in Pediatric Anesthesia in 2007. They observed 50 handovers — 23 before the change and 27 after. Mean technical errors fell from 5.42 to 3.15. Information omissions, from 2.09 to 1.07. And the handover, against intuition, got shorter — from 10.8 to 9.4 minutes. The share of patients with several errors stacking up dropped from 39% to 11.5%.
Notice what isn’t in this story. They didn’t hire better surgeons. They didn’t buy equipment. They didn’t shorten the operation. The only thing they changed was the moment of handover — the one part of the process nobody had been treating as a process.
The same thing happens when a customer moves between your channels
A customer types into the website chat: “do you have this jacket in L?” The bot answers. They leave, because the phone rings. Three hours later they get an SMS about their order status and reply to it: “so what about the L?”
That’s your hospital lift.
Because whatever is on the other end of that SMS is not what they were talking to on the website. Different configuration, different knowledge base, a different version of the returns policy. The customer doesn’t know that and has no obligation to — to them it’s one company and one conversation.
What actually breaks
Three things, in this order.
The customer repeats themselves. The cheapest of these problems and the most annoying one. They already gave the order number. Now they give it again. Context didn’t survive the handover, because there was no handover.
Answers drift apart. This one is more serious. The widget says “returns within 30 days”, because that’s where someone uploaded the new terms. The SMS channel says “14 days”, because someone else uploaded there, back in March. Your company has now given one customer two different answers to the same question, and one of them is false. If they hold you to the more favourable one, you have a problem no discussion wins.
The team stops trusting the numbers. Your reporting holds two separate views that can’t be added up, because the same conversation shows up twice. “How many conversations did we handle” stops having a single answer — and that’s the moment people stop opening the dashboard.
Why channels always drift
This isn’t sloppiness. It’s a consequence of how most companies arrive at a second channel.
The configuration is a copy, not a source
The first channel is built as a project. The second one is built as a copy of the first — someone pastes the prompt across, uploads the same PDFs, sets the same tone. On launch day the two are identical, so there’s nothing to see.
The drift starts with the first change nobody replicated. Not a big one — a small one. December delivery hours. A new payment provider. One sentence fixed in the terms. Each is innocent on its own, but they accumulate, and nobody is positioned to see the accumulation.
A year later you have two bots that answer differently, and nobody can point to the moment it happened.
There is no coordinator
Back to Stepney’s remark: nobody knows who’s in command. In customer communication it’s exactly the same. Who owns the fact that the channels say the same thing? The usual answer is “well, marketing and support together”, which means nobody.
The hospital didn’t solve this with better communication between people. It solved it by naming one person whose job was to watch the whole thing and not touch the car. That’s a role, not goodwill.
“We’ll integrate it later” is the expensive version
Integrating after the fact means you already have two sources of truth and have to decide which one wins. And that isn’t a technology decision, it’s a business one: which terms are binding, the widget’s version or the SMS one? Someone has to read both and compare. No connector does that for you.
That’s why one configuration is cheaper up front than two you stitch together later — not because the rollout costs less, but because it doesn’t generate work that has no owner.
What one configuration won’t fix
To be straight about it: a shared prompt and a shared knowledge base don’t solve everything.
Channels have different constraints and that part doesn’t go away. RCS has character limits and carrier rules a website widget doesn’t. SMS won’t render a product carousel. What’s a convenient form on your site has to become three questions in a row in a message. Shared configuration means “the same knowledge and the same tone”, not “an identical format” — and a vendor promising the latter is promising something the channels physically can’t deliver.
It also won’t fix bad content. If your terms are written so nobody understands them, they’ll be equally incomprehensible in both channels, just consistently.
What to do about it
Three things, in the order that makes sense — and you can do the first two this week, without changing tools.
1. Establish one source of truth. One set of documents that feeds every channel. Not “the same file in two places” — one place both read from. If that’s technically impossible in your current setup, that is precisely the cost described above.
2. Name a coordinator. By name. One person who, on every change to answer content, asks “and the other channel?” That’s half an hour a month if you keep up with it, and a two-week audit if you don’t.
3. Check for drift before your customer does. Take your ten most common questions and ask them in every channel, by hand, once a month. It’s the simplest test there is, and most companies have never run it. You’ll probably find at least one discrepancy on the first pass.
How this works here
In Chatmerce the same agent — same prompt, same knowledge base — serves the website widget, RCS, and two-way SMS. It isn’t a feature bolted on the side, it’s the thesis of the product: you configure once, so there’s nothing to drift, and you don’t need a coordinator to guard something that technically can’t come apart. Change the terms in one place and they change everywhere.
If you run two channels today and suspect they’re saying different things, get in touch — we’ll show you on your own questions. More on the RCS channel itself: RCS vs SMS, what changed.
Source for the hospital figures: K.R. Catchpole et al., Patient handover from surgery to intensive care: using Formula 1 pit-stop and aviation models to improve safety and quality, Pediatric Anesthesia 17(5), 2007, pp. 470–478. Text current as of August 2026.