A System for Perfecting Maintenance Work Orders

A maintenance work order is the job that runs every time something in your building stops doing what it's supposed to: a housekeeper finds a sink that won't drain mid-turn, a guest reports a leak, a preventive schedule comes due. It runs many times a day, across at least three teams — whoever spots and reports it, the front desk that takes it in, and the maintenance techs who fix it. And like most operational processes, it is invisible right up until it isn't: until a room sits out-of-order longer than it should, the same fixture breaks for the fourth time this season, or your time-to-resolve quietly drifts and nobody can say where the hours went.

This process tends to create a particular kind of failure: a repair that gets done but never gets confirmed, on a fixture nobody remembers has broken before — so the room stays blocked, the reporter never hears back, and the same fault gets patched again and again. By the end of this post you'll have a copy-pasteable spec for the whole process — every step, every owner, every handoff — plus two portable principles you can apply to anything else that runs through your building. The problem is a fix that nobody confirms and nobody remembers. The solution is owning the handoff that goes quiet and keeping the record that shows the pattern.

The bad run

Jane is turning room 412 at 11:40 on a Tuesday, working against a noon checkout-to-arrival window. The bathroom sink won't drain — water pooling, slow gurgle, the works. She's a housekeeper, not a plumber, so she radios the front desk the way she always does: "412, the sink's messed up, it's not draining." The agent, mid-check-in, writes 412 sink — maint on a sticky note and says they'll call it in. What Jane actually saw — standing water, a smell, what looked like it was backing up rather than just slow — never makes the trip. It got compressed into four words on a radio.

The note sits until 12:10, when the agent radios maintenance between guests. The channel's busy; the call doesn't land. They try again at 12:35 and reach a tech finishing a job two floors down. "412, sink. Got it." The tech pictures a clogged trap, grabs a hand auger, and arrives at 1:15 — only to find a sink backing up from a blocked branch line, which the auger won't touch. Wrong guess, wrong tool, because the only thing that ever reached him was the word "sink." He heads back for the right equipment, clears it by 2:30, and logs nothing, because the radio handoff was never a ticket in the first place.

Here's the part that actually costs you. Nobody tells Jane, who's long since moved on with no idea whether 412 is hers to finish — so the room sits in limbo, blocking an arrival nobody reassigned. And because the report was never written down, nobody notices this is the fourth time this exact sink has been "fixed" this season. Each time it got cleared as a one-off clog; nobody ever pulled the thread that says a line backing up monthly isn't a clog, it's a failing line. So the symptom gets treated, again, and the cause keeps waiting — until 412 floods weeks later, and the GM learns the fix had been sitting in the maintenance log all along, if there'd been a log.

The good run

Jane is turning 412 at 11:40 and finds the same sink. She taps her phone, photographs the standing water, adds two words — "not draining" — and the report lands in front of a tech with the photo attached, so he sees it's a branch-line backup, not a trap clog. He moves the ticket into picked up the moment he takes it, and that status is right there on 412 for Jane and the front desk to see — so within a minute, without anyone sending her anything, she knows it's in hand and not still hers to chase. He brings the right equipment the first time, clears it, logs it on the way out. The room flips back to available on its own. Jane gets one message — 412 sink is fixed — can you confirm the room's good to finish? — which both tells her it's handled and asks her to verify before she releases it.

And quietly, the ticket gets written to that room's history — the fourth entry on this sink, finally enough for someone to notice the pattern. Then nothing else happens. A process that works is quiet — which is why the broken version is the one everyone remembers. So how does the quiet version run?

The bridge

Start with the broken run as a picture. Notice where the arrows go dotted — that's where the work falls out of the world.

The manual run:

1. Housekeeping spots the issue mid-turn and radios it to the front desk — in words ("sink's messed up"), not a picture. Detail is lost in translation.
2. Front desk relays it to maintenance by radio or sticky note — symptom compressed, the right kit guessed.
3. A tech eventually picks it up, often arrives with the wrong tool, and repairs it on a second trip.
4. The tech moves on. The PMS often isn't updated, so the room stays in limbo.
5. Housekeeping is never told it's done — the return leg has no owner.
6. Nothing is logged to the room's history, so a repeat fault never gets recognized as a pattern.

Look at the dotted arrows, because they're the whole story. The recurring pattern is a missing confirmation at every handoff — plus, here, a missing memory of the job itself:

• A report that drifts in translation. What Jane saw — standing water, a backup, a smell — became "the sink's messed up" by the time it reached the tech. Housekeeping isn't a trade; asking a housekeeper to diagnose plumbing over a radio strips out the detail that picks the right tool. A picture would have carried what words couldn't.
• No receipt confirmation. The radio relay wasn't guaranteed to land. A sticky note and a busy channel aren't a handoff — they're a hope. The ticket lived in someone's memory, so it could (and did) evaporate.
• No pickup status. Nothing showed that anyone had taken the job. Jane couldn't tell whether 412 was still hers, because there was no status on the ticket to look at — it lived in one tech's memory. A visible "picked up" the moment a tech takes it is the cheapest acknowledgment there is: early acknowledgment is the strongest single predictor of satisfaction even when the fix runs late, and here the person left hanging is your own staff, with a room stuck behind the silence.
• No completed confirmation. Nobody owned the return leg. The tech's job ended when the repair did; telling housekeeping and flipping the room's status was formally nobody's job — so it didn't happen, and the room sat in limbo.
• No record, so no pattern. Because nothing was logged, the fourth backup looked exactly like the first. Without a per-room history, every repeat reads as a fresh one-off — so you keep treating the symptom (clear the clog) instead of the cause (replace the failing line). The most expensive ticket is the one you've quietly paid for four times.

Here is the same process with those gaps closed:

The system-run flow:

1. The report enters — housekeeping direct (with a photo) or via the front desk — and an automated system (Lush) captures and classifies it, photo and detail intact.
2. It auto-routes the ticket — photo attached — to the right tech by skill and priority, and dispatches it.
3. That status is visible on the room to the reporter and front desk, so everyone can see it's in hand without anyone sending a message.
4. The tech executes and logs the resolution.
5. The system automatically notifies HK if a Pick Up is needed.
6. The system updates the room status in the PMS automatically.
7. The system writes the ticket to that room's history, where repeats become a visible pattern.
8. The system confirms completion back to the reporter and invites a quick accuracy check.

That's the whole difference. Put the two pictures side by side and they're nearly identical — same housekeeper, same tech, same repair. What changed: the reporter could see the job get picked up and then see it confirmed done, the report carried a picture instead of four words, and a system held the parts that get tedious and fragile under load — capturing the detail, routing to the right hands with the right tool, flipping the room status, and keeping the record that turns a fourth repeat into a flag. Nothing heroic happened. The work simply stopped having a place to fall through — and stopped being forgotten the moment it was done.

You may not always be able to wave a magic wand and implement a system — but we still want to give you something you can use Monday morning. Here is the same process as a tool-neutral spec you can overlay by hand. Read it as See / Plan / Act: see the job clearly, plan the owners and payloads, act on the one metric that matters at each step.

Step	Owner	Input	Output	Success metric	Direction
Report issue	Housekeeping / Guest / Staff	—	Issue report: room, symptom, photo, time reported	Reports captured (not lost)	↑ higher better
Create ticket	Front Desk	Issue report	Work order: room, symptom, photo, severity, time reported	Time-to-log	↓ lower better
Triage & assign	Maintenance (dispatcher)	Work order	Work order (adds assigned tech, skill, priority)	Severity-classification accuracy	↑ higher better
Dispatch	Maintenance (dispatcher)	Work order	Work order	Dispatch delay	↓ lower better
Pick up ticket	Maintenance (tech)	Work order	Work order (status: picked up — visible to reporter)	Time-to-pickup	↓ lower better
Diagnose & repair	Maintenance (tech)	Work order	Resolution: parts used, time spent, status	First-time fix rate	↑ higher better
Log resolution	Maintenance (tech)	Resolution	Resolution	Time-to-resolve (headline)	↓ lower better
Update room status	Maintenance / PMS	Resolution	Room status: available	Room-downtime after repair	↓ lower better
Log to room history	Maintenance / system	Resolution	Room-history entry: room, fixture, symptom, fix, date	Repeat-issue rate on same room	↓ lower better
Confirm with reporter	Front Desk	Resolution	Completion confirmation: work order, fix summary, accuracy check	Reporter follow-up completed	↑ higher better

Metric and direction only — no target numbers, because the right threshold depends on your property and you can add one to any row later without touching the structure. The table never needs Lush to be useful; it's yours to run by hand.

The principles — steal these

Before you go, two ideas are worth pulling out of this one process, because they hold true for every process in your hotel.

Pick one number that matters. Every process should have a single number that tells you if it worked. For work orders, that's time-to-resolve — report to close. Everything else (first-time fix rate, repeat-issue rate, parts availability) is a clue for why that number moved, not a goal of its own. And keep the clues written down: a repeat-issue count only means something if every ticket is logged — that's what tells you when you're patching the same symptom over and over instead of fixing the cause. Pick the one number, watch it, and let the rest explain it.

Watch the handoffs, not the departments. Work almost never fails inside a team. A housekeeper can spot a broken sink; a tech can clear a line. The failure in 412 happened in the gaps between them — the report that lost its detail crossing from housekeeping to maintenance, the trip back that nobody owned. So walk the seams: at each handoff, ask who owns it, what gets passed, and how you'd know if it dropped. That last question is the one that catches the silent failures.

The Full Playbook

You just got one process mapped end to end, for free. Every process on this blog is the same deal — free to read, yours to copy, no gate.

If you'd rather have them all in one place, we've assembled the full guide: every process from check-in to check-out, through checkout and post-stay, mapped the same way, in a single document. It's behind a name and email — that's the only ask, and it's just so we can send it to you.

And if running this many connected processes by hand is starting to feel like the real problem, that's the thing we actually do — we can run all of it for you.