Challenge
An independent company services sterilisation and clinical equipment for surgery centres and hospitals, as a more personal alternative to the manufacturers' own service contracts. The work is growing, and the operation behind it had not kept up.
Almost everything ran through people rather than systems. Customers called or texted a technician directly, and most requests were never logged. Nobody could see at a glance where the technicians were or who should take the next job. The equipment management system held the record of every device, but it could not connect to anything else, so each step around it meant typing the same information again. Renewals and scheduled maintenance depended on someone remembering them, and hours were pieced together at the end of the month, which meant some work was never billed.
Solution
We designed one system that orchestrates the whole operation around a single record per job. Every call lands on a shared work line and becomes a drafted work order. The job is assigned to the right technician with a planned route, the van's movements and the visit itself provide the hours, and billing runs from that same record. Renewals and repairs are created automatically from each device's service dates, so the company reaches out before the customer has to call.
The result is an operation where every request is captured, every hour is counted, and the people in it can spend their time on the equipment and the customers instead of on the admin around them.
Execution
Mapping the operation end to end
We followed the work from start to finish: how a new client is taken on and their equipment entered into the equipment management system, how requests arrive, how technicians are chosen and sent out, what happens on site, how reports are written, and how hours turn into invoices. Every step was walked through with the people who do it, so the map describes how the work really runs, not how it is supposed to.
Finding the bottlenecks
The map made five of them plain:
- Requests arrived on personal phones. Nothing was logged unless someone wrote it down.
- Dispatch lived in one person's head. There was no shared view of where the vans were or who was free.
- The equipment record was a dead end. The system that held every device had no way to connect to other tools, so everything around it was typed twice.
- Renewals relied on memory. Scheduled maintenance and replacements were only as reliable as someone's calendar.
- Billing was rebuilt every month. Hours were collected after the fact, and some work slipped through.
Choosing the tools
We compared phone systems and van trackers against three tests: an open connection other software can use, a price that makes sense for a small team, and something the technicians would actually use in the field.
The equipment management system was the harder decision. It had no way for other software to connect to it, and it was held in place by one piece of test equipment that only talked to that system. Replacing that equipment removes the lock, and opens the way to an equipment management system built to connect.
Designing the system
Four principles shaped the design:
- One record per job. From the first call to the invoice, every job has one record. Every other tool reads from it or writes to it.
- Events, not data entry. A call ending, a van arriving on site, a test being completed: each one updates the record on its own, so nobody types the same thing twice.
- The equipment register drives the calendar. Service dates on each device create the next job ahead of time, so renewals and repairs are planned, not remembered.
- Quick wins first. The work line and van tracking come first because they are cheap and useful on day one. The equipment system switch follows, and the orchestration layer is built on top once the data flows.
