A private healthcare group. Fourteen clinics, 312 staff, and a four-person support team responsible for everything that plugs in: computers and the practice management system, biomedical equipment, printers, network links, air conditioning, medical gas alarms, and whatever else a clinic manager decided was theirs that day.
Support arrived through eleven WhatsApp groups, three personal cellphone numbers and a shared mailbox nobody owned. There was no record of anything. The same vaccine fridge had failed four times in a year, and nobody knew, because each failure had been a separate phone call to a different person.
The interesting part of this project was not the ticketing tool. It was defining what "urgent" means in a building where some faults are inconvenient and some are clinical.
Why clinical support is not office IT support
- Impact is measured in patients, not users. A failed printer at reception slows a queue. A failed vaccine fridge threatens stock worth more than the building's IT and a cold chain you have to be able to prove.
- The person reporting is with a patient. Anyone who expects a nurse to open a portal, choose a category and write a description has never watched a clinic at 08:30.
- Half the estate belongs to someone else. Contracted equipment must route to the vendor holding the service agreement, with the clock and the evidence to enforce it.
- After-hours is real. Clinics run past five, and a fault at 19:00 cannot wait for somebody to check a mailbox in the morning.
- Accreditation wants evidence. Not just that things were fixed, but that faults were logged, prioritised, escalated and closed.
Every support desk eventually gets the priorities it deserves. If urgency is decided by who phones the manager directly, then the loudest clinic gets the best service and the quietest one runs on faith.
The priority matrix, which was the real deliverable
Written with the clinical director and the operations manager, not by IT alone, and printed on a card at every reception desk.
| Priority | Meaning | Examples | Response / resolve |
|---|---|---|---|
| P1 | Patient care stopped or clinical stock at risk | Vaccine fridge alarm, practice system down at a whole site, no power to a treatment room | 15 min / 4 hours, any hour |
| P2 | Care continuing, but degraded or at risk | One consulting room's system down, X-ray printer failed, network slow enough to block claims | 1 hour / same day |
| P3 | Inconvenience with a workaround | Reception printer, one user's login, a phone extension | 4 hours / 2 working days |
| P4 | Request rather than fault | New starter setup, equipment move, report change | 1 day / 5 working days |
Two rules made it work. Anyone may raise a P1, without asking permission, and nobody is ever criticised for calling one wrongly. And the desk, not the reporter, sets the final priority, with the reason recorded. That second rule was uncomfortable for a fortnight and then became invisible.
Getting the tickets in at all
The tool was a mainstream service desk product. Configuration was straightforward. Every meaningful decision was about the channel, because a service desk that clinical staff will not use is just an inbox with reporting.
- WhatsApp became a channel, not an enemy. Messages to the support number create tickets automatically, and replies from the desk go back into the same chat. Staff kept the habit they already had; the business got the record it never had.
- A QR sticker on every asset. Scan the fridge, the printer, the ultrasound, and the ticket opens with the asset, the site and the room already filled in. Half of all tickets now start this way, and they arrive better described than anything typed.
- Phone still works, logged by the agent while talking. Removing the phone would have been an act of self-harm.
- Email as the fallback, mostly used by managers and vendors.
- Vendor routing on the equipment record. A fault on contracted equipment raises the vendor ticket automatically, with the contract reference, and the SLA clock keeps running while the vendor holds it.
Meet people on the channel they already use
The instinct is to insist on the portal because it produces the cleanest data. The result is that clinical staff phone somebody instead, and you have clean data about a fraction of reality. Take the messy channel, automate it into a ticket, and let the data quality problem be solved by the desk rather than by the nurse.
Eight weeks, in order
| Weeks | Phase | What actually happened |
|---|---|---|
| 1 | Shadow the chaos | Two days sitting with the support team, counting where requests came from and how many were never recorded. Four in ten left no trace. |
| 1–2 | Priority matrix | Written with clinical leadership. Three drafts. The vaccine fridge argument took a whole afternoon and was worth it. |
| 2–4 | Configure | Queues, routing, SLA clocks with pause-on-vendor, escalation paths, after-hours rota, reporting. |
| 3–5 | Asset and vendor data | Every supported device listed with its site, room, warranty and service contract. Nine contracts were found to have lapsed. |
| 4–5 | Knowledge base | Twenty first-line fixes written for reception staff, in plain language, with photographs. |
| 6 | Pilot at three clinics | Including the busiest and the most sceptical. QR stickers went up during the pilot, which is when the ticket volume jumped. |
| 7–8 | Roll out | Remaining eleven clinics, one visit each, WhatsApp groups closed on the day of the visit rather than "soon". |
The hardest part was managers, not nurses
Clinical staff adapted quickly, because the QR sticker was less effort than typing a message. The difficulty was senior people who had spent years getting service by phoning the IT manager directly, and who experienced the new process as a downgrade.
What resolved it was the IT manager changing his own behaviour, with the group's backing: calls were answered, and then logged while the caller waited, so the caller could see the ticket number arrive. Nobody was refused. Within a month the direct calls had mostly stopped, because the logged route was demonstrably faster.
The support team needed different training: triage, not tools. Deciding a priority quickly, asking two useful questions, and closing tickets with a resolution note specific enough to help the next person. The team also got something they had never had, which was a defensible reason to say "that is a P3", and it noticeably reduced how frayed they were by Friday.
What it cost
| Line | Once-off | Notes |
|---|---|---|
| Configuration and workflow | R163,800 | Queues, SLAs, escalation, vendor routing, reporting |
| WhatsApp channel integration | R71,500 | Business API setup and two-way ticket threading |
| Asset capture and QR labelling | R57,400 | Around 700 supported devices across fourteen sites |
| Knowledge base | R33,600 | Twenty articles written and tested on reception staff |
| Training and site rollout | R45,300 | Every clinic visited in person |
| Total once-off | R371,600 | Over eight weeks |
| Running cost | R9,760 / month | Six agent licences, WhatsApp conversation fees, support |
For scale: a single-site business with two agents and email-only intake can be running for under R30,000 once-off. Licensing is per agent, not per person supported, which is why service desks scale well.
What changed, measured
- Recorded requests went from 61% of reality to 96%. Everything after this depends on that number.
- P1 response went from an average of three hours and four minutes to 22 minutes, and after-hours P1s stopped depending on whose cellphone was on.
- Repeat-fault reporting found three devices generating 40% of the calls at their sites. Two were replaced, one was recommissioned. Ticket volume at those clinics fell by a third.
- Nine lapsed service contracts were found and renegotiated, and vendor SLA breaches became evidenced rather than remembered, which produced real credits.
- The vaccine fridge that failed four times was replaced in the first month, once its history existed in one place.
- First-line deflection reached 18%, with reception staff resolving common faults from the knowledge base rather than logging them.
What we would do differently
We would write the knowledge base before the pilot, not during it. Deflection is the cheapest capacity a support team will ever get, and it arrived a month late.
We would resist the first draft of the priority matrix, which had seven levels. Four is enough. More than that and agents guess, which makes the reporting worthless.
And we would load vendor contracts in week one. Discovering nine lapsed agreements in week five was useful but disruptive, and two of them had to be renegotiated under time pressure.
If your desk is a group chat
Start by counting how many requests leave no record. That number is the business case, and it is usually worse than anyone expects. Then write the priority matrix with the people who own the consequences, and only then choose a tool. The tool is the easy part, and it always was. Where the same estate needs planned maintenance rather than reactive fixes, the asset register approach is the natural next step.
