Fault reports: from a scanned sticker to a work order with a deadline
Before this loop the platform knew planned work and did not know the road a fault travels. Now the fault has a measured door from end to end.
Who reports, and how
- By scanning a sticker: the location sticker (
/site/{code}) or the asset sticker (/asset/{code}). No account, no password — the scanner describes the fault and attaches a photo. - From the dashboard: the facility manager logs a report manually.
An asset sticker forces its own asset: the report lands in the right asset's record even if the reporter's wording is vague. The location sticker stays necessary — «a leak in the corridor ceiling» is a fault in a place, not in a part.
A report is a claim; a work order is a commitment
The report is its own entity, not a status on a task, because it is a reporter's claim that may be rejected. Were it a task, every rejected report would become a cancelled task polluting the board and the completion rate.
Three stamps measure the road:
- Arrival — the moment of the claim.
- Response — the first time anyone turns to it, and a rejection is a response. Stamped once, never re-stamped.
- Conversion — the moment it becomes a commitment.
Deadline and destination
The deadline lives on the asset category, then the maintenance category (else the configured floor), and is stamped onto the report at birth — a commitment once made does not shift. The destination — which crew, which manager — is read live, so changing the crew today applies to today's reports.
Notification escalates: arrival and approach go to the crew, a breach goes to the manager. And the sweep runs hourly, not daily — a four-hour deadline is not guarded by a daily sweep.
Conversion
From the report page: triage · convert · reject · reopen. Conversion mints a work order that inherits location, asset and priority, and it appears in the asset's work history beside its planned maintenance.
Rejection requires a written reason: a verdict without a reason leaves no trace worth reading.