Perspectives
Your branches do not need a bigger helpdesk
They need the first five minutes answered.
By Ehsan Gazar, 6 October 2026
A till stops printing receipts at a branch on a Saturday morning. The manager calls the helpdesk and waits.
The fix is in a guide somebody wrote last year. Turn the printer off, clear the paper path, turn it on again. It takes two minutes once you know.
Nobody at the branch knows, and the helpdesk is answering the same question from another site.
That is the shape of IT support for anyone with branches, stores or depots. A small number of problems come back again and again. Each one waits in the same queue as the outage that really needs a person.
Most of a helpdesk call is not the fix. It is working out what the problem is, where it is, and whether it is already written down.
A person is good at that and slow at it, because they answer one call at a time.
An agent can do the first five minutes for every site at once. Staff message it on Telegram or WhatsApp, which they already have on their phones. They describe the problem in their own words, and it starts from your guides.
Answering from your own guides
The agent searches the IT guides your team has already written: the printer fix, the Wi-Fi reset, the steps for a locked account.
It is told to answer only from what it found, one step per line. When the guides do not cover the problem, it says so rather than inventing a procedure.
After a fix, it asks the member of staff to rate the answer from one to five. Those ratings tell your team which guides work and which ones need rewriting.
Your guides become the thing the agent is good at. Improving a guide improves every answer that uses it, at every site.
A ticket for the rest
Some problems need IT to act. A new starter needs access. A laptop will not boot. A fault is not in any guide.
For those, the agent writes the ticket. It asks for what is missing, such as the site and who is affected, then records the ticket in your helpdesk system.
The write is kept and retried if the helpdesk does not answer, so a ticket is not lost because the system was busy. The member of staff is told it is open.
Some requests are sensitive even when they are routine. Access to a shared drive, a password reset for somebody else, a new admin account for a branch.
For those, the ticket is not written straight away. A second model reads the request against a policy your IT team writes in plain words. For example: a reset for your own account is fine, a reset for anyone else needs a manager, and admin access always goes to a person.
The check answers approve, refuse or needs a person, and says why. Anything short of a clear approve reaches your team instead of the helpdesk system.
The model that talked to the member of staff never makes that call. It is the one a polite message could talk round.
Each conversation is tagged with how it ended: fixed from a guide, ticket opened, or handed over. Over a month that is a clear picture of what your sites actually need from IT.
The outage goes straight through
Some messages should not wait for anything.
A whole site offline, every till down, a network fault affecting many people. The agent recognises these from the message and does not try a guide.
It hands the conversation to your IT team at once. The member of staff is told somebody from IT will reply, and the person who picks it up sees everything already said.
Sorting messages into these paths is a small decisions model with options you name and describe. Fixable from the guides, needs a ticket, urgent. You can read exactly what puts a message on each path.
What staff send is not always words
A member of staff at a depot rarely types a clean description. They send a photo of the error on the screen, or a voice note recorded while they hold the cable.
The agent can read both. A voice note is turned into text before the agent decides anything, so it is answered exactly as the same words typed would be. A photo of an error message is read for the message itself.
That matters more than it sounds. The people at a site are busy, and the quickest way to describe a fault is to point a phone at it.
Built so IT can change it
The agent is drawn as a workflow: search the guides, decide the path, answer, ticket or hand over. Your IT team can read it block by block.
When the helpdesk system changes, the ticket block changes. When a new kind of urgent fault appears, it becomes a line in the decision, not a project.
Before any of it reaches a branch, it runs in test mode. Every step that would write a ticket or reach a person answers with a fake reply, and nothing is sent. You can try the Saturday printer message and the Monday outage and watch each go down its path.
The branches do not need more people answering the phone; they need the first five minutes answered every time.