Work Requests

A work request is what your floor submits when something looks wrong: “Press won’t start”, “Forklift makes a noise”, “Air conditioning is leaking water”. It’s the inbox that feeds the maintenance work-order pipeline. A request is not yet maintenance work — it’s a candidate for maintenance work, awaiting a planner’s review.

Submitting a request

The mobile-friendly submit form captures:

• The asset (if known) — the QR scan flow on the asset’s sticker pre-fills it.
• The functional location (if no specific asset) — useful when the user can’t identify the exact unit.
• A problem code from the catalog — filtered to codes relevant to the asset class.
• An optional severity override — H / M / L. Use when your intuition disagrees with the catalog default.
• A free-text description.
• Optional attachments — photo, short video.

Submitting computes:

• An auto-generated request number (e.g., WR-2026-0042).
• An SLA tier — IMMEDIATE / URGENT / STANDARD / LOW — computed from asset criticality × problem severity.
• An SLA due-at timestamp — the operating-calendar deadline by which a planner must accept or reject the request.

The new request lands in the planner’s inbox as NEW.

SLA tiers

The tier sets the response-time target:

• IMMEDIATE — A-critical asset with H severity. First response measured in minutes.
• URGENT — A-critical with M severity, or B-critical with H severity. First response within roughly 4 operating hours.
• STANDARD — B-critical with M severity, or C-critical with H or M severity. First response within about a day of operating time.
• LOW — C-critical with L severity. Re-reviewed periodically.

Your tier matrix is configurable — different orgs have different tolerance for delay.

Triage states

A planner reviews each request and moves it through one of these states:

• NEW — Just submitted; awaiting review.
• ACCEPTED — Planner has seen it and committed to acting. Not yet a WO — the parts/team/schedule still need sorting.
• DEFERRED — Will deal with later; reason and re-review date required. The system auto-promotes deferred requests back to NEW on their re-review date.
• CONVERTED — Turned into a maintenance work order. Terminal — once converted, the request is read-only and all edits move to the MWO.
• REJECTED — Won’t be done; reason required. Terminal.

A planner can bulk-triage several requests together (the same asset reported by three operators in the same shift) — accepting, deferring, or rejecting them in one pass.

Conversion to a work order

The “Convert to MWO” action opens a drawer that inherits the request’s asset, functional location, problem code, severity, and team default, and lets the planner adjust the WO’s flavour (usually CORRECTIVE or BREAKDOWN), assign a team, set the scheduled window, and either release immediately or save as PLANNED for later review.

The generated MWO carries source = WORK_REQUEST and source_reference_id pointing at the request, so the audit trail is preserved.

Duplicate suppression

When you start a new request for an asset that already has an open request (NEW/ACCEPTED/DEFERRED) for the same problem code, the UI warns you and links to the existing request rather than blocking — sometimes the second submitter has useful new context to add, sometimes they didn’t see the first request and would happily defer to it.