Intake
Requests are captured the same way every time — from a form, from email, from a QR code, from a 30-second call log, from the team — so nothing disappears into a chat thread or a hallway conversation.
How it works
From scattered requests to a working system.
JFS OPS is a control layer for unresolved work between your existing systems — it sits alongside the tools you already run, not instead of them. It is built around five capabilities that turn operational friction into owned, tracked, resolved work. Here is what each one does, shown with a real walkthrough — not a slide deck.
The five capabilities
What the system actually does
Each capability is deliberately narrow. Together they cover the full life of an operational request.
Triage
Every new request gets a suggested owner with the reason shown, and a person confirms it. Ownership is a decision, never a guess — and never automatic.
Verified safety escalation
Safety-flagged requests route to Management review immediately and bypass the normal queue. Every action is recorded in an append-only evidence trail.
Requester communication
The requester is told who owns their request and what happens next — and kept updated as it moves. No more “any update?” emails.
Operational memory
Recurring issues surface at the moment they matter (“this has happened three times”), and history accumulates into better procedures instead of fading with staff turnover.
The judgment contract
AI advises. You decide.
Nobody else in this space will write this sentence: every recommendation shows its evidence and what it's missing. The system never decides for you — on safety, spend, compliance, or anything else.
Every recommendation shows its evidence
What was seen, where it came from, and what it doesn't show. If the evidence isn't there, the system says so instead of guessing.
No silent automation
Nothing happens on safety, spend, or compliance without a person confirming it. The system records; people decide.
No black-box scores
No single health scores, no sentiment scores, no 'AI confidence 87%'. If it can't show its working, it doesn't get a say.
The record is append-only
What was decided, by whom, and on what evidence — always retrievable, never rewritten.
Walkthrough
One request, end to end
The most honest way to show how it works: follow a single fictional request from submission to resolution, with each system action labelled.
One request, end to end
“Meeting Room 3 is too warm” — from submission to resolution.
Request submitted
09:12
A team member reports that Meeting Room 3 is uncomfortably warm during meetings. The request is captured with category (Facilities), location (Meeting Room 3, Floor 2), and urgency (High — the room is booked all afternoon).
What the system did: Intake validates the submission and creates the request with a unique reference.
Triage suggestion appears
09:12
The desk suggests A. Okafor as owner, with the reason shown: Facilities category match, and this owner resolved 6 similar temperature requests in the last 90 days.
What the system did: Rules-based suggestion with reason codes. Nothing is assigned automatically — a person confirms.
Owner confirmed
09:20
The facilities coordinator accepts the suggestion in one click. The request moves from New to Assigned. The requester is told who owns it and what happens next.
What the system did: Assignment, status change, and the requester update are recorded as events.
SLA warning fires
11:40
The High-urgency first-response target is approaching. The desk flags the request: response due within the hour. The owner is already on site, so no escalation is needed.
What the system did: Deterministic pre-breach warning at 75% of the approved SLA target.
Vendor booked, commitment recorded
13:05
The on-site check finds a faulty thermostat. A vendor is booked for the next morning and the promised completion date is recorded against the request.
What the system did: The promised date becomes a commitment the ledger can track.
Resolved and confirmed
Next day, 10:30
The thermostat is replaced and the room temperature verified. The request is marked Resolved, the requester is notified, and the fix is linked to the two similar temperature reports from earlier in the quarter.
What the system did: Resolution, requester notification, and the recurring-issue link are recorded as events.
Illustrative workflow using sample data. No customer data shown.
Lifecycle
Where a request can go
A small, fixed set of statuses. Every move is recorded, so the history of a request reads like a story.
New
Captured, awaiting triage
Assigned
Owner confirmed
In progress
Work under way
Needs review
Checkpoint before closing
Resolved
Fixed and confirmed
Closed
Archived with history
Escalated
Any stage can escalate — safety-flagged requests route to Management review immediately and bypass the normal path.
See the operating model
What the desk looks like in practice
The Operations Desk itself is invite-only, so these are faithful illustrative recreations with fictional records — the same views, the same information, sample data.
The triage queue
Every open request in one place, with urgency, status, owner, and age visible at a glance. Warnings surface before targets are missed.
Triage queue
5 open
JFS-2408Emergency light flickering, stairwell B
CriticalEscalatedOwner: M. LindqvistAge: 4 h⚠ Safety reviewJFS-2411Meeting Room 3 temperature too high
HighIn progressOwner: A. OkaforAge: 2 d⚠ Breaches in 6 hJFS-2404Recycling collection missed twice
LowNewOwner: UnassignedAge: 9 d⚠ No ownerJFS-2398Car park barrier stuck open
HighIn progressOwner: S. AdeyemiAge: 3 dJFS-2402Projector bulb replacement, boardroom
MediumNeeds reviewOwner: D. ByrneAge: 4 d
Request detail
Owner, next action, and due date on every request — plus the full activity history, so nothing depends on memory.
JFS-2411
Meeting Room 3 temperature too high
HighIn progress
- Owner
- A. Okafor
- Next action
- Vendor attending tomorrow 09:00
- Due
- Tomorrow, 17:00
- Location
- Meeting Room 3, Floor 2
Activity
- 09:12Request created from the intake form
- 09:12Triage suggested A. Okafor — Facilities category match
- 09:20Coordinator accepted the suggestion; request Assigned
- 09:20Requester notified: owner confirmed, next step shared
- 11:40SLA warning: response target approaching
- 13:05Vendor booked; promised completion recorded
Safety escalation
Safety-flagged requests route to Management review immediately, with an append-only evidence trail of every action taken.
JFS-2420 · SAFETY
Exposed wiring, ground-floor corridor
Escalated
Evidence trail — append-only
- 14:02Safety risk flagged by D. Byrne — exposed wiring near a public corridor
- 14:02Routed to Management review immediately (bypasses normal queue)
- 14:20Acknowledged by M. Lindqvist
- 15:45Area cordoned off; electrician booked for 08:00 tomorrow
- —Closing requires an operator and a written resolution note
Operations reporting
The measures that matter — ownership, acknowledgement speed, safety response — in one weekly view.
Weekly operations view
Requests with an owner94%
Acknowledged within target88%
Safety escalations acknowledged12 / 12
Past response target (open)6
Illustrative workflow using sample data. No customer data shown.
Next step
See it against your own operation.
A short conversation about the workflows that keep your buildings running — and whether a four-week pilot makes sense.