Maintenance 3 min read Updated October 2026
From a service request to a closed ticket
In many institutions a fault gets reported twice: once verbally, and once when someone remembers. Meanwhile the tap keeps dripping, and staff stop reporting because “nobody fixes anything anyway”. A good maintenance process cuts the report down to one sentence, makes sure the request reaches the right person, and closes with whoever reported it.
1. The reporter doesn’t need to know who fixes it
Requiring the reporter to know who to contact is what breaks maintenance processes. A counselor who sees a leak at two in the morning doesn’t need to know whether it’s the caretaker, the plumber or a contractor. They need to report what and where, and the process routes it.
2. A good request: three fields and a photo
Every extra field on the form lowers the number of reports. Three fields are enough to open a request, and one phone photo replaces three lines of description.
In every request
- What: the type of fault, from a short list. Electrical, plumbing, furniture, IT, cleaning.
- Where: building and room.
- How urgent: one of three fixed levels.
- A photo, when possible.
3. Urgency levels everyone reads the same way
When every request is marked “urgent”, none is. Define three levels in advance, with examples and an expected handling time for each.
| Level | Examples | Example handling time |
|---|
| Safety | An exposed wire, a stuck exit door, a large leak | Immediately, plus a call to the person in charge |
| Disrupts routine | No hot water on a floor, air conditioning not working in a room | By the end of the day |
| Regular | A loose handle, a burnt-out bulb, a closet that won’t close | During the week |
The times are examples. What matters is that they’re set in advance and everyone knows what to expect.
4. Routing by type and place
Routing by type and location saves the coordination step. An electrical fault in a given building goes to the same person every time. Requests with no clear owner go to one inbox, which one person is responsible for.
- Every type of fault has a default handler.
- A handler sees only their own requests, in order of urgency.
- A request not picked up within the set time is escalated to the maintenance manager.
5. Closing the loop with the reporter
A request is closed only when whoever reported it knows it’s closed. Without that, they’ll report it again or stop reporting altogether. A short update on closing is what keeps the staff’s trust in the process.
01OpenedThe reporter sees the request was received and who it went to.
02In progressThe handler took it. If a part or contractor is needed, it’s written in the request.
03ClosedWhat was done, and when. The reporter gets an update.
04ReopenedIf the fault comes back, reopen the same request rather than a new one, so repeat faults are visible.
6. What to measure
Two measures are enough: how long until a request is picked up, and how long until it’s closed. Comparing fault types and buildings shows at once where the bottleneck is, and where the same fault keeps returning and deserves a proper fix.
Common mistakes
- A long form the staff can’t be bothered to fill in.
- Every request marked “urgent”.
- Reports on WhatsApp to the caretaker that get lost among other messages.
- A request closed without the reporter knowing.
- A repeat fault opened as a new request each time, so nobody sees it keeps coming back.
Want to see a maintenance request opened from a phone in half a minute, routed to the right person and closed with the reporter? We’ll show it on your own structure.
