Maintenance issue predictor

A maintenance issue predictor ranks guest rooms by the chance that something will need attention soon. It uses occupancy and usage history, room or building vintage, and prior tickets. The only acceptable product is a flag that names the room and cites those facts. When history is thin, the field stays empty. The model does not invent a work order, and engineering still inspects.

If a dashboard writes a job into the CMMS from the score alone, you have already left the quality outcome. A flag is a hypothesis with sources. A work order is a decision after someone has looked at the room or the plant.

Property platforms in this class, including Oracle Hospitality, Mews, Cloudbeds, and Agilysys, hold stay records, room status, and often a task or ticket trail. Read those as evidence, not as a diagnosis. Occupancy pressure also appears in adjacent planning such as a housekeeping schedule optimizer. That overlap is useful for usage intensity. It is not a substitute for ticket cites.

Refuse this failure first: treating the flag as a closed work order. A high rank does not mean the asset was already handled, the guest complaint was already filed, or the technician can skip the room. Until an engineer inspects, the item belongs on a watch list only.

Scoring starts after you can reconstruct a room's life, not after you pick a model.

Load, per room: occupied-night or stay counts over a window you actually keep; turnovers and out-of-order days if they exist; construction year or last major renovation; make and age of in-room plant if you track it; open and closed tickets with dates, room identifiers, and the category or description as written. Do not rewrite "AC loud" or "drain slow" into a clean failure code before you cite it. Keep the original line. That line is what the engineer will check against the room.

Join keys matter. Room 412 in the PMS, 412 in the work-order system, and 412 after a wing rename are not the same object until you prove they are. If the join is fuzzy, drop the room from scoring rather than blending two histories.

Do not treat guest preference notes or live routing queues as past maintenance evidence. A guest preference-based room setup record tells you how the room was prepared, not whether the fan coil is failing. An in-room service request router may carry today's guest requests. Those belong in current dispatch. They are not invented historical tickets.

When history is missing, stop. A new-build floor with two months of stays and no tickets is not a low-risk floor. It is an unscored floor.

Re-score on a cadence that matches how you close tickets, not on every night audit. A daily refresh is enough if occupancy and tickets land overnight. Scoring more often than your CMMS updates will reprint the same flag with a new timestamp and look like new work.

A usable flag has three parts on one card or row: the room identity, the ticket history that supports the rank, and the vintage (build year, last rehab, or equipment age, whichever you actually have).

Cite tickets by identifier and date, and quote the category or description as stored. Cite usage as occupied nights, turnovers, or the same counts you loaded, over a named window. Cite vintage as a year or a rehab event, not as "old wing." If you cannot point to those fields, do not emit the flag.

Illustrative walkthrough, not a measured result: Room 412 ranks high. The card lists PMS room 412, occupied most nights across the last two seasons, three closed tickets in eighteen months tagged to cooling ("AC loud," "room won't cool," "fan noise"), and a 2009 guest-room rehab with the original fan-coil still in place. The engineer walks 412 when it is vacant, checks airflow and the condensate line, and then decides whether to open a work order. The model never wrote "replace compressor" and never closed anything.

A flag with no ticket cite is a failure even when occupancy and age look dramatic. High use plus an old floor is a reason to inspect on a schedule you already own. It is not a maintenance-issue prediction unless prior tickets, or an equally explicit plant record, sit on the card. Suppress those rows or mark them "insufficient ticket history." Do not dress them as predictions.

Do not invent an HVAC failure because cooling tickets are common in the set. The cite is "three cooling tickets as written." The diagnosis is the engineer's. If an energy anomaly monitor later shows odd consumption on that stack, treat it as a separate signal with its own cites. Do not merge the two into a story the files do not support.

Show occupied versus vacant in the same row as the cites. A vacant room can be walked on the current shift. An occupied room needs access coordination. The rank does not change that constraint.

Thin history is normal in parts of the building: recently renovated keys, rooms that changed numbers, tickets that lived only in email, plant that was never tagged to a room.

Keep these rules:

No tickets and no plant record means no flag. Occupancy alone is not enough.

Tickets that cannot be joined to the current room id mean no flag.

Unknown vintage plus tickets that lack a location mean no flag.

Open tickets already in dispatch for the same symptom must not emit a second prediction that looks like new work. Point the engineer at the open job.

Empty is a valid system state. Dashboards that force a score onto every key train people to ignore the list. A short list with cites beats a full tower painted in risk colors.

If you later collect a season of clean tickets and a verified join, the room can enter the ranked set. Until then it stays blank. Do not backfill invented tickets to "complete" the model.

Front office and housekeeping should not see a risk color without the cites. If they only see a red room, they will block the key or promise the guest a repair you have not verified. Engineering owns the list.

The operating loop is load room history, flag with cites, leave blanks, inspect.

The chief engineer, or the shift engineer they designate, owns inspection priority. Use the ranked list to decide which vacant rooms to walk during a slow arrival period, which occupied rooms to request access for, and which plant rooms to open when the cite is on a shared riser rather than the guest key. After the walk, three honest outcomes exist: no work, open a work order with what was found, or keep watching with a dated note. None of those outcomes is "the model scored it, so we are done."

Do not auto-create work orders from the rank. Auto-create is how invented HVAC failures and ghost jobs enter the CMMS. If a technician sees a job that says "predicted failure" with no ticket numbers, they will ignore it or replace parts that did not need replacing.

Do not close a flag because the calendar moved. Close it because someone inspected, or because you withdrew it for thin history. A stale flag that still shows a cite remains a watch item until the walk happens.

Handover should copy the same three fields the card already has: room, tickets, vintage. Adding a narrative that names a failed component, without an inspection, recreates the HVAC-invention failure in the log book.

Keep guest-facing and housekeeping systems in their lanes. Housekeeping pressure can explain usage. Live in-room requests belong in routing. Neither should silently become a completed engineering ticket.