Facility Service Request

This record is one step in a larger programme. Using it for work that belongs to a neighbouring template, or to the maintenance workspace outright, produces records that are hard to report on later.

The FSR is built against ISO 45001 cl.7.1, but its fields draw on several Support, Operation, and Improvement clauses, each mapped to a specific section of the form rather than the record as a whole.

The FSR sits under welfare provisions that carry direct statutory force in most jurisdictions, not just an internal service standard, which is why an unresolved welfare-flagged request is more consequential than it looks in the queue.

Filling in the FSR's fields is mechanical. What decides whether the record actually defends the site is how consistently four judgement calls are made above those fields.

These failure modes turn up repeatedly in FSR registers running more than a year, once the singleton has been exercised across enough winters and contractors to show its seams.

A cold changing room off the despatch yard was logged as an FSR one October, marked Affects Welfare Facilities Yes and acknowledged within the week. It was never assigned a named owner, sat at Planned through winter, and closed unresolved in spring with no Requester Informed entry. The same complaint reappeared the next October under a new Request ID, unlinked to the first, Reported Before And Not Fixed answered No, because nobody checked.

By the fourth winter the fault had generated four separate FSRs, none linked, none escalated to a work order, no CAPA raised, because each record looked like a first-time, low-severity complaint rather than what it was: a four-year-old resourcing gap under cl.7.1 the scoring never caught, because the recurrence was never recorded as recurrence.

The form itself is the easy part. Keeping requests moving past acknowledgement, catching recurrence before the fourth winter, and holding the contractor links together is the work that actually slips.

KnowOps

Holds the FSR register against the site's Area and Site ID list, flags requests past their stated timescale, and checks a Yes on Affects Welfare Facilities has somewhere to escalate to.

KnowMaintain

Watches for Contractor Required or a fabric fault answered Yes with no Work Order ID, keeping the FSR and its downstream work order pointed at the same fault rather than drifting apart.

KnowContractor

Tracks the contractor's timescale once Contractor Required is Yes, so Requester Told The Timescale reflects the contractor's real commitment, not facilities' best guess.

Ella

Rolls open, overdue, and recurring requests into one view across every site, and holds every write back to the record for your approval first.

Facility service request (FSR)

A building or welfare fault that is neither an equipment failure nor a housekeeping task, raised by anybody and owned by facilities.

Work order

The maintenance record (MNT-002) opened against plant or equipment. An FSR converts into one once facilities decides physical repair is needed.

CAPA

Corrective and preventive action record (FDN-014), raised from the FSR's Outcome section when a fault is systemic or recurring rather than one-off.

Welfare facilities

Sanitary, washing, drinking water, and rest provisions a workplace must provide: a specific, statutory subset of the building faults an FSR can cover.

Singleton record

A record type set up once per workspace and maintained, rather than raised once per event; the FSR register is a singleton even though requests within it recur.