A refrigeration and air-conditioning service company. Six technicians in six vans, 462 customer sites, two-thirds of them on maintenance contracts and the rest calling when something breaks. Restaurants, filling-station forecourt shops, two cold stores and a lot of small retail.
Work was allocated from a whiteboard by phone each morning. Job cards were carbon-copy books, handed in on Fridays, sometimes. Invoicing ran three weeks behind the work, and the number on the invoice was reconstructed from a technician's handwriting and an office manager's memory.
What makes service businesses distinctive is that the product is a person's time, and if you cannot see where that time went, you cannot price anything correctly.
Why refrigeration service is its own problem
- The clock starts with stock at risk. A failed cold room is not an inconvenience, it is a restaurant's inventory. Response commitments are commercially serious in a way that "we will come Tuesday" is not.
- Diagnosis lives in site history. The same unit failing the same way for the third time is a different job from a first failure, and a technician who does not know that starts from scratch.
- A site is not a unit. One customer address may hold nine pieces of equipment with different ages, warranties and contracts. Job history has to attach to the unit, not the address.
- Refrigerant has to be accounted for. Gas taken on and put into a system is both a cost and a record-keeping duty, and estimating it at month-end is a guess dressed as a figure.
- The van is a warehouse nobody counts. Six vans held tens of thousands of rand of parts that appeared in no stock system.
In a service business, the job card is the product. Everything downstream, the invoice, the margin, the maintenance history, the argument with the customer, is a copy of what a technician did or did not write down at 16:40 in a plant room.
What we put in
An off-the-shelf field service platform, configured hard, integrated with their accounting package. No custom build. The decisions that mattered:
| Workflow | Before | After |
|---|---|---|
| Allocation | Whiteboard, phone calls each morning | Scheduling board with skills and geography; the day can be re-cut when a breakdown lands |
| Job card | Carbon book, handed in weekly | Mobile app, offline-capable, closed on site with photos, readings, parts and a signature |
| Site knowledge | In the technician who usually goes there | Equipment register per site, full history on the technician's screen before he arrives |
| Planned maintenance | A spreadsheet reminder that was often missed | Contract schedules generate jobs automatically, with completion tracked per contract |
| Parts | Bought as needed, van stock invisible | Each van is a stock location; parts consumed on the job card deplete it and trigger replenishment |
| Gas | Estimated monthly | Recorded per job, in and out, by cylinder |
| Invoicing | Three weeks later, from handwriting | Job closes, office reviews, invoice out the same or next day |
The app has to be faster than the paper it replaces
A technician will not adopt a system that adds five minutes to every job, no matter what management says, and the failure shows up as job cards completed in the van park at the end of the week from memory. Design the mobile job card down to the smallest number of fields the business genuinely needs, put the common parts and fault codes one tap away, and time it against the paper version before you roll it out.
Ten weeks, in order
| Weeks | Phase | What actually happened |
|---|---|---|
| 1 | Ride along | A full day in two different vans. Nothing in the project shaped it more, including the discovery that a third of jobs need a part that is not on the van. |
| 2–3 | Configure | Job types, fault and resolution codes kept deliberately short, contract templates, van stock locations. |
| 3–5 | Customer and site data | 462 sites imported. Equipment lists were not imported, because they did not exist. See below. |
| 5–6 | Accounting integration | Customers, parts and invoices, both directions, tested against a month of real jobs. |
| 7 | Pilot with two technicians | The two who volunteered. They redesigned the job card screen, and their version is what everybody uses. |
| 8–9 | Roll out | Remaining four technicians, one at a time, each with a day of paper running alongside. |
| 10 | Contracts loaded | Maintenance schedules generated for the year, which immediately showed that 45% of planned visits had been quietly skipped. |
The equipment register, built by doing the work
The obvious plan was to capture every unit at every site before go-live: 462 sites, several units each, weeks of driving. We did not do it. Instead the job card required the technician to identify or create the unit he was working on, with a photograph of the plate. After ninety days, 81% of active equipment was in the register, captured by people who were going to be there anyway, at no additional cost.
The remaining 20% belonged to sites that had not called in three months, which is a reasonable definition of "not yet urgent". Capture as a by-product of the work beats a data-capture project almost every time.
Training six technicians and one dispatcher
The technicians took a morning, then a week of being irritated, then never mentioned it again. The things that mattered: the app works with no signal and syncs later, which it must in plant rooms and basements; the screen assumes gloves; and the first week's job cards were reviewed by the office without complaint about missing detail, coaching rather than correcting.
The bigger change was in the office. The person who had been an administrator became a dispatcher, which is a genuinely different job: watching a board, re-cutting the day when an emergency lands, protecting planned maintenance from being eaten by callouts. That role needed a fortnight of shoulder-to-shoulder support and it was the highest-leverage training in the project.
What it cost
| Line | Once-off | Notes |
|---|---|---|
| Configuration and setup | R144,200 | Job types, codes, contracts, van stock, scheduling rules |
| Accounting integration | R67,500 | Two-way, tested against a real month |
| Customer and site data | R31,800 | Equipment captured in the field afterwards, at no extra cost |
| Rugged phones and mounts | R53,640 | Six technicians, replaced the personal-phone arrangement |
| Training and pilot support | R39,700 | Including two weeks with the new dispatcher |
| Total once-off | R336,840 | Over ten weeks |
| Running cost | R8,690 / month | Eight licences, mobile data, support |
For scale: two-technician operations run on entry-level products for a few thousand rand a month with a weekend of setup. Cost scales with technicians and integration, not with customers.
What changed, measured
- Invoicing lag went from 21 days to 2, which moved a month of revenue forward in working capital terms and ended most billing disputes, because the invoice arrived while the customer still remembered the visit.
- First-time fix went from 61% to 78%, driven by site history on arrival and by van stock being visible enough to reposition parts.
- Planned maintenance completion went from 55% to 94%, which is the single biggest driver of contract renewals in this business.
- Recharges stopped leaking. Parts and hours that had been absorbed because nobody could evidence them added up to a meaningful monthly figure once they were captured at the point of work.
- Travel time fell by 15%, from geography-aware scheduling rather than allocation by who answered the phone.
- Gas usage became a real number, and the variance against what had been estimated was large enough to change how it was charged.
What we would do differently
We would load the maintenance contracts in week two rather than week ten. Discovering that 45% of planned visits had been skipped was the most commercially significant finding in the project, and it arrived at the end.
We would start with fewer fault codes. The first list had 60, drawn from an industry standard. Technicians picked the nearest one, which produced tidy nonsense. Twelve real codes, written by the technicians, produce data you can act on.
And we would put the office change first. The dispatcher role was treated as a consequence of the software rather than as a deliberate redesign of a job, and it took a month longer to settle than it needed to.
If your work leaves the building on paper
Ride along for a day before you buy anything. You will learn more about what your business needs than any requirements workshop will tell you, and you will find the two or three constraints, no signal, gloves, a customer standing over the technician, that decide whether the software gets used. Then keep the job card short, capture the asset list as a by-product of work, and connect it to invoicing on day one. The same pattern, capture where the work happens, runs through site work generally, and offline behaviour matters more here than anywhere: see software that keeps working when the signal does not.
