Head office answered in four hours. The clinic had already decided.
The gap between a question and its answer matters because work may continue while the issue is unresolved. I would identify which questions require an immediate clinical route and which can wait for routine operational support.
Support response time gets filed under administration. It sits on an operations dashboard next to invoice turnaround and ticket volume, and nobody in clinical governance looks at it. I think that is the wrong home for it. In a network where head office holds the standard and the clinic holds the patient, how fast the standard can be reached decides how often it gets used.
The support promise becomes more demanding when a patient has returned to another time zone. I would publish the staffed hours, the urgent clinical route and the person covering an absent owner. An Operations Head in India's aesthetic medical tourism sector should be able to demonstrate that coverage, rather than let an overseas patient discover its limits during a problem.
Key points
- I would compare the ticket queue with the authorised channels staff actually use.
- A single response target is the usual mistake.
- For a slow urgent-response route, I would first check staffing coverage and decision authority.
- How many questions your clinics have is beyond your control.
What actually happens while a clinic waits
Nothing dramatic, and that is the problem.
A coordinator has a patient in front of her with a medication history that does not match the protocol she was trained on. She asks the group. Nobody answers immediately, because it is 11am and everyone is in session. She has a room booked, a patient who took the day off work, and a surgeon who will be free in twenty minutes.
So she does the sensible thing: she looks at what the clinic did last time something similar came up, and repeats it. A capable person has made a good decision, and it is completely invisible to you. By the time the answer arrives at three, it has become a review rather than a decision.
Multiply that by a network and a year. The written standard describes what should happen. The lived standard is an accumulation of reasonable local guesses made while waiting, and the two drift apart quietly, at a rate set almost entirely by how long the wait is.
Measure it where support really happens
I would compare the ticket queue with the authorised channels staff actually use. A dashboard limited to tickets may miss an unresolved question in a chat group. The review should close that gap without making private conversation a source of casual surveillance.
So read the messages. Take a month of the busiest group, and go through it by hand. For each message, ask whether it was a question, whether an answer arrived, and how long that took. Then note whether the answer came with a name attached or evaporated into agreement.
Acknowledgement needs an owner for the next decision. Several sympathetic replies can still leave a clinic without an answer it can act on. I would track whether the issue reached the right authority and whether the action returned to the person who raised it.
The exercise takes a couple of afternoons. It will tell you more than the ticketing report has told you all year, because the ticketing report can only count the questions somebody thought were formal enough to raise formally.
Three clocks, not one
A single response target is the usual mistake. It is set at something like twenty four hours, which is far too slow for the question that has stopped a procedure and needlessly tight for the one about next quarter's stationery.
Split it by consequence.
The first clock is for anything that stops clinical work now. A protocol conflict, a consent question, an adverse event. Target in minutes, and name the person who carries the phone. If you cannot name that person for every hour your clinics are open, you do not have this clock, you have a hope.
A slower clock covers anything that changes what a clinic does this week. Scheduling, a supply substitution, a query about eligibility. Target in hours, inside the working day.
Everything else gets the last clock, and a day is fine. Most of your volume lives here, which is exactly why a blended average tells you nothing useful. The average is dominated by the questions that did not matter.
A number that mixes urgent and routine will always look acceptable and always hide the failure you care about.
When the urgent clock runs slow
For a slow urgent-response route, I would first check staffing coverage and decision authority. A queue may lack capacity, or the available person may be unable to make or obtain the required decision. Those problems need different actions.
Either the question should not have needed asking, because the standard does not cover a situation that comes up monthly, and the fix is to write that section rather than answer it faster forever. Or the person who can answer is one of two people in the whole network, and they are also doing something else. Knowledge has concentrated in too few hands, which is not a support problem, and it will hurt you the week they are on leave.
Both are worth finding. Neither shows up if you measure response time as a service level and stop there.
Where this leaves you
How many questions your clinics have is beyond your control. A growing network generates more of them, and a network doing new procedures generates harder ones. Chasing question volume down is the wrong ambition anyway; a clinic that has stopped asking has usually stopped checking.
Your share is narrower and more useful: a name against the first clock for every open hour, and a month of real messages read recently rather than a report about them. Then an owner on every answer, and the habit of writing a question you have answered five times into the standard, so the sixth clinic does not have to wait for you at all.
Do those and the response time takes care of itself. Report the average and you will have a number that looks fine, on a network that is quietly making it up while it waits.
Questions people ask
Why treat support desk response time as a clinical metric?
Because a clinic that cannot get an answer does not stop working. It guesses. The guess is usually reasonable and occasionally not, and either way it happens outside the standard you wrote. Response time therefore sets how often your network operates on local improvisation rather than agreed practice.
What is a reasonable response target for a clinical query?
Set it by consequence, not by courtesy. A question that stops a procedure needs an answer inside the session, so measure it in minutes. A question about a form can wait a day. One target across every question type will be too slow for the urgent ones and needlessly expensive for the rest.
How do you measure this if support happens in chat groups?
Read the transcript. Take a month of messages, mark every one that is a question, and record when an answer with an owner attached arrived. It is tedious and it is also the only honest source, because the ticket system only knows about the questions somebody bothered to raise in it.
Watch the film
This note as an animated film of 2 minutes. Open the film page with chapters ↗
- 0:00 The clinic had already decided
- 0:06 The wrong home for it
- 0:15 Nothing dramatic
- 0:25 The written standard and the lived standard
- 0:35 Measure it where support really happens
- 0:44 Three clocks, not one
- 0:57 You have a hope
- 1:06 Hide the failure you care about
- 1:15 Demonstrate that coverage
Watch the short series
This note is also told in 3 short videos. See all videos ↗
The support desk is a clinical quality metric: response time in a franchise network
Why treat support desk response time as a clinical metric?
What is a reasonable response target for a clinical query?
The letter
Get the next field note by email.
A short note with the title and a link, only when something new is published. No promotion. How the letter works


