Head office answered in four hours. The clinic had already decided.
That sentence is most of what I have learned about franchise support. The gap between a question and its answer is not dead time. It is time in which somebody is deciding without you, and the decision they reach is the one your network actually runs on.
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.
01
What actually happens while a clinic waits
Nothing dramatic. 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.
She does the sensible thing. She looks at what the clinic did last time something similar came up, and she does that. It is a good decision, made by a capable person, and it is completely invisible to you. When the answer arrives at three, it is no longer a decision. It is a review.
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.
02
Measure it where support really happens
Most networks I have seen run support in two places: a ticket system that leadership looks at, and a set of chat groups where the actual work happens. The dashboard reports on the first one. The drift comes from the second.
So read the messages. Take a month of the busiest group, and go through it by hand. For each message, ask three things. Was this a question. Did an answer arrive. How long did it take, and did the answer come with a name attached or did it evaporate into agreement.
That last part matters more than the clock. An answer nobody owns is not an answer, and I have watched a question get four sympathetic replies and no decision, then disappear. In the transcript it looks like the query was handled. In the clinic, nothing changed.
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.
03
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.
The second clock is for anything that changes what a clinic does this week. Scheduling, a supply substitution, a query about eligibility. Target in hours, inside the working day.
The third is everything else, 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.
04
What the number is really telling you
A slow first clock is rarely a staffing problem. When I have traced it, it has usually been one of two things.
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. That is not a support problem either. That is a concentration of knowledge that 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.
05
Where this leaves you
You do not control how many questions your clinics have. 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.
What you control is narrower and more useful. Whether the first clock has a name against it for every open hour. Whether you have read a month of real messages recently, rather than a report about them. Whether an answer carries an owner. And whether a question you have now answered five times gets written 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.