A maintenance request is not a ticket

A maintenance request is a message; a ticket is a record. The message arrives by phone, on WhatsApp or at a reception desk, and disappears when the call ends. The ticket keeps what the call loses: who reported the fault, who approved the work, who was sent, what was done and when.

What is lost between the phone call and the ticket?

Everything said and not written, and the loss stays invisible until the same fault returns. The caller knows the building, the room and something of its history; whoever writes the ticket afterwards knows a fraction of it. A record that starts after that conversation starts incomplete: no site, no department, no fault category, no name to call back.

In the maintenance system we built for a healthcare facility, requests arrived by phone, in person and on paper. Nobody could say which had been approved, which team was on one, or what had been repaired the week before, and completion was a verbal report.

Which states must a ticket pass through?

One current state per ticket, named in advance, and no ticket allowed to sit in two. The system we built works through these:

State	Who moves it there	What it must carry
New	whoever took the report	site, department, fault category
Approved	the approving role	approver, time, named team
In progress	the assigned team member	start time
Awaiting parts	the supervisor	the reason it stopped
Completed	the person who did the work	before-and-after photos
Pending approval	the person who did the work	what needs checking
Closed	the reviewer	the closure note

The table is the easy half. What matters is that every move carries a reason and an actor, so a stalled ticket shows where it stalled, not only that it is late.

Who is allowed to move a ticket?

Fewer people than the software permits, and whoever approves the work must not be the only one who signs it off. Approval and assignment belong in one action: the approving role approves the ticket and names the supervisor and the team member. Split that across two screens and you get approved tickets nobody owns.

Scope matters as much as permission. A supervisor who sees every site cannot be held to one, so they see only the locations assigned to them. Whoever reports a fault can add to the ticket and cannot close it. Completed to closed needs a second pair of eyes — that is what pending approval is for.

What is the SLA clock actually measuring?

Elapsed time from the moment the request became a ticket, against a target that belongs to the priority rather than to the person who complained. That is the only definition that measures what the requester experiences: the wait.

Two decisions must be written down, or the clock measures nothing. The priority scale, with a real failure at each level — not "urgent" as a feeling, but the faults that stop the building that day. And whether a ticket waiting for parts pauses: defensible only if the pause is a state, with a reason and an actor, so a stalled ticket cannot pass for a working one.

In the system we built, each priority carries a target and a breach is detected automatically, so a high-priority ticket that waited too long is flagged rather than discovered at month end.

Why is the closure note the only part that teaches anything?

Because it is the only field written by someone who knows what the fault was. Every other field is metadata: a site, a category, a name, a time. The note holds the cause, the part replaced, and the workaround that will hold until the part arrives.

Photos and the note do different jobs. Photos prove a repair happened — required before completion, so the repair is documented rather than reported — but a photo cannot say why. A note reading "fixed" closes a ticket and teaches nothing, and a year of those is a list of events with no causes. It is also the field that decays first, which is why making it part of closure, and having a supervisor read it, is the whole discipline.

What is the log worth at the end of the year?

Exactly the questions it answers without anyone's memory: what is open, what breached its target, which team carries the load, what a location has cost in attention over the year.

Reconstruction is the real test: why the same fault keeps returning to one building, whether a team is overloaded or understaffed. Without a log that is a meeting where the loudest recollection wins; with one it is a filter.

Which requires an immutable log: every change with its actor, timestamp and value before and after, so the record survives a dispute about what was done and when.

How do you set this up?

1. Write the states down, one current per ticket, and refuse a system that lets a ticket carry two.
2. Attach an actor and a reason to every transition before you attach a colour.
3. Name the approving role, and make approval and assignment one action.
4. Define the priority scale with a real failure from your own history at each level.
5. Fix the target per priority, write down when the clock starts, and make any pause a state rather than a silence.
6. Require photos and a closure note before closing, reviewed by a second person.
7. Read the log on a schedule — open tickets, breaches, load per team — not once a year.

Where this goes wrong

• The ticket is written after the work is done, from memory, by the person being measured: the record becomes a summary, not evidence.
• The queue is a chat group. The request lives in a thread, is worked, and never becomes a record.
• Approval and assignment live in different places, producing approved tickets that sit unowned.
• The clock starts when the technician arrives. Waiting in the queue is invisible, and that is the hour the requester noticed.
• Every closure says "done". The log fills with events and stays empty of causes.
• The timeline is editable, so whoever touched the ticket last controls the history.
• The log is opened once a year, in a budget meeting, by people looking for a justification.

What this does not cover

It says nothing about planned preventive maintenance, spare-parts inventory or cost accounting. It quotes no prices and no response times, because both depend on the market and on the building. And it does not claim a ticket system fixes a team that is too small: the record makes a shortage visible and arguable, not solved.

We build maintenance systems where the ticket, not the phone call, is the record — approval, assignment, the clock and an immutable timeline in one place, Arabic-first from the interface outward.