Work Order System for Hotels: Closing Is Not Finishing

A shower valve is repaired at 14:12 on a Thursday. The engineer marks the job done, which it is. Two days later the guest checks out and writes, among nicer things, that the shower was reported on the first night and nobody ever came back to them.

Both statements are true. The work was finished and the loop was not, and the property will read that review as a maintenance failure and go looking in the wrong place. This is the most expensive thing a work order system for hotels gets wrong, and it is nearly invisible from inside the system, because from inside the system that job looks perfect: raised, assigned, completed, closed.

What follows are the beliefs that produce it. They are all reasonable, which is why they survive procurement.

”The queue is the product”

The queue is bookkeeping. It is necessary and it is not where the value is, because a queue only holds jobs that already exist and only releases them when somebody says so. The two ends are what decide whether anything improves: how work gets in, and what happens when it goes out.

The entry end is well covered — it is the gap between a guest reporting something and it becoming tracked work, and it is where the category concentrates. The exit end is the one this piece is about, and it is almost never demoed, because a demo ends when the job turns green.

”Priority is a field you fill in”

Four levels — low, normal, high, urgent — is a scale that works, and it stops working the moment everything is urgent, at which point you have a queue with a decorative column. Priority is only meaningful if something in the system is willing to assign it without a person’s optimism involved.

Two rules do most of that work. A repair created automatically from a failed check is written high, because a member of staff already made the judgment that something is broken and the system does not need to second-guess it. A repair raised from a guest conversation defaults to normal, and the person raising it moves it up if the guest is in the room with the problem. Neither is clever. Both mean the scale still means something at the end of a busy week, which is the only test that counts.

”The engineer will ask if they need more detail”

They will not. They will walk there, look at it, form a theory, and either fix it or come back. Every piece of context that did not travel with the job costs a second trip, and on a villa property a second trip costs more in walking than the repair costs in tools.

So the question to put to any system is what rides along with the job. On the board we build for villa properties: the guest’s own report, pre-filled into the job when a staff member raises it from the conversation, so the engineer reads the description of the noise instead of somebody’s three-word summary of it. The villa — never typed, so it cannot be mistyped. The reporter’s photo, when the job came from a failed check. And the note, delivered in the engineer’s own language, which on a team that speaks several is the difference between an instruction and a guess.

”Closing the job closes the loop”

This is the one that produced the review at the top.

Resolution and closure are different events, separated by a person. A guest who reported a problem has no window into your queue; from where they are sitting, the only evidence that anything happened is somebody telling them. Until that happens the problem is, as far as the review is concerned, unresolved — and a guest who thinks they were ignored will say so more strongly than a guest who had a broken shower.

When a repair that came from a guest conversation is completed, the staff member who owns that guest’s thread is notified — the villa, the fact that it is fixed, and a link straight into the conversation. The message they get says to let the guest know, because a person writes the sentence.

“Your maintenance request has been resolved” arriving from software, after a bad first night, reads as a receipt from an organization; the same fact from the host who has been talking to them all week reads as somebody taking care of it. The stay is repaired by the second one.

Somebody reads the day’s completed jobs and decides which ones a guest is waiting to hear about. It is a few minutes at the end of a shift, and it is the highest-return few minutes on the sheet.

”You will know later”

You will know what is written down, in the shape it was written down in.

Each villa carries its own history — the jobs run on it, who did what and when, the checklist results and the photos, newest first. That answers the question a duty manager puts to you at eight in the evening, which is what has been happening in this villa, in the order it happened.

What a specific unit has cost you over three years is a different question, and it is answered by a different record: an asset register, with spare-part stock and warranty dates hung off it. If the question keeping you awake is which air handler keeps failing, that is a CMMS, with everything that implies, and the trade-off is worth reading before you buy either.

The test that takes two minutes

Take the last repair your team completed. Not a difficult one — an ordinary one, from earlier this week.

Ask who told the guest, when, and how you know that happened. If the answer requires somebody to remember, you have found the leak, and it is almost certainly costing you more than anything upstream of it. Almost any property can produce the completed job. Very few can produce the second half.

If you would like to see how our side handles that half — the completion, the notification — we will walk one repair through from the guest’s message to the guest being told.