At 8:50 on a Tuesday evening, a patient writes to a Beirut clinic's assistant. She wants to know whether her insurer covers a procedure her doctor suggested. The assistant replies: "I'm sorry, I didn't understand. Please rephrase." She rephrases. Same reply. She rephrases again. Same reply. Her fourth message is two words: "forget it." By morning she has booked at another clinic.
This scene is a composite, written to illustrate a pattern. It is not a report about a real patient or clinic.
Nothing in that exchange was broken in the technical sense. The assistant did not have the answer, which is normal, because the answer lives with an insurance desk that had gone home. What failed was the message. Nobody had written it. A default error line filled the space, and the default error line cost a booking.
Why the unknown-answer is the moment customers judge you
Most of what a support assistant says is routine: opening hours, a tracking link, a reset instruction. Customers do not remember routine. They remember the one time they asked something that mattered and the system had nothing.
That moment tells them three things at once. Whether you will be straight with them. Whether anyone is behind the assistant. Whether their time will be respected. A bluffed answer fails the first test. A dead end fails the second. An apology loop fails the third.
In my experience, businesses treat this moment as an error to minimise and so they never write it. They write the greeting, the menu and the tone guide, then leave the one message that carries the most trust to whatever the platform ships by default. I would rather treat it like any other customer message: drafted, reviewed by the person who owns the customer relationship, tested, and revised.
The four parts of an "I don't know" that keeps the customer
When I review a support assistant, I look for four parts in every reply that admits a gap:
- What it does know. Start with something true and useful, however small. "The clinic works with several insurers" is not an answer, but it shows the assistant understood the question.
- What it cannot confirm, said plainly. One sentence, no apology theatre. "I can't confirm whether your plan covers this procedure" is enough. Three apologies in a row make the customer manage your feelings.
- What happens next, with a named owner and a time. "Someone will contact you" is not a step. "Maya from the insurance desk will reply here by 10:00 tomorrow" is.
- What the customer does not need to repeat. Pass the context along and say you did. The sentence that says so matters as much as the handover itself.
Miss any one and an honest gap turns into a lost customer. Without part one, the customer feels unheard. Without part two, the reply is vague. Without part three, nothing is promised. Without part four, the customer expects to start over, and some will not bother.
Worked example: the same clinic message, before and after
Everything in this section is illustrative. The messages and numbers are invented to show the mechanism, not drawn from a real client.
Before, the patient's question about insurance cover receives this:
I'm sorry, I didn't understand. Please rephrase.
After, the same question receives this:
I can't confirm whether your insurer covers this procedure, and I would rather not guess. What I do know: the clinic works with several insurers, and cover depends on your plan and the procedure. Our insurance desk checks that. They open at 8:30 tomorrow, and Maya will reply here by 10:00 with a yes or no. I have passed her your insurer, the procedure and your phone number, so you do not need to explain again. If you send your policy number now, it will be waiting for her.
Now suppose, over 14 days, 60 patients ask a question the assistant cannot answer. Illustrative outcomes:
- Before: 39 of 60 leave without reaching anyone (65 percent). Of the 21 who reach reception, most are asked to give the details again.
- After: 12 of 60 leave (20 percent). The other 48 receive a named follow-up inside a stated window.
- Bookings from that group: 14 before, 31 after.
I am not claiming those figures are typical. They show where the loss sits. The patient who left did not want a different answer. She wanted to know that someone had her question and when it would be handled.
A five-question test before launch
You can run this in an afternoon. Pull five real questions your assistant cannot answer from your own inbox, WhatsApp history or support tickets. Real ones, not invented. Send each to the assistant and score the reply against the four parts, one point each. Anything below three out of four gets rewritten before launch.
Then write the unknown-answer in each language your customers use. In Lebanon and across the Gulf that usually means Arabic, Arabizi and English, and often a mix inside one message. A customer who writes in Arabizi and receives a stiff English fallback hears that nobody planned for them. Have a native speaker check tone, and make sure the owner and the time appear in the same form in every version.
Also test after hours. The 8:50 pm message is the one most likely to land on a team that is asleep, so part three should name the next working hour, not a vague "soon."
What not to do
- Bluff. A confident wrong answer about insurance, delivery or a refund will be acted on. The cost arrives later and lands on your team.
- Promise vaguely. "Someone will contact you" with no name and no time reads as a polite no.
- Loop on apology. "Sorry, I didn't understand" repeated is not a fallback. It is a locked door with a kind face.
- Go silent after hours. If the follow-up cannot happen until morning, say so, and say when morning is.
What I check first in a support audit
When I audit a support setup, I do not start with accuracy scores or response speed. I ask for the five questions the assistant handles worst, and I read the replies as the customer would. The first fix is nearly always the same: the unknown-answer was never written.
If you want to run the test on your own assistant and compare notes, write to me through the contact details on this site. I would like to hear which of the four parts your replies miss most often.
Related evidence: Article 50 of the EU AI Act requires providers to design AI systems that interact directly with people so that those people are informed they are interacting with an AI system, unless that is already obvious in the circumstances and context of use. (EU AI Act Article 50 transparency obligations)
NIST's AI RMF appendix on human-AI interaction notes that AI systems can autonomously make decisions, defer decision making to a human expert, or be used by a human decision maker as an additional opinion. (NIST AI RMF appendix on human-AI interaction)
