Operating model
How we think about operational work.
JFS OPS is built on six principles — not features. They explain why the product works the way it does, and why we say no to the things that would make it just another system of record.
The loop
From scattered work to an operating loop.
Operational work follows a cycle. Most teams are stuck at 'capture' — requests arrive, but nothing structures them. JFS OPS closes the loop.
1
Capture
2
Structure
3
Assign
4
Coordinate
5
Review
6
Improve
Human review and accountability sits at the centre of the loop — not as a step, but as the control that governs every transition.
Illustrative workflow using sample data. No customer data shown.
01
Start with one workflow
Not a platform replacement. We begin with a single operational workflow — the one causing the most friction — and make it work. Platform migrations fail; focused workflow improvements compound.
02
Capture work in a structured, visible record
Every request becomes a record with owner, status, next action, and history. Not a ticket in a black box — a working document that the team actually uses to coordinate.
03
Keep a human accountable
For decisions, approvals, and escalations, a named person is responsible. The system suggests, surfaces, and reminds — but it never acts autonomously on operational work. Human judgment is the control.
04
Connect where information already lives
Before forcing migration, we connect to email, SharePoint, and the tools teams already use. The goal is visibility, not rip-and-replace. Meet the operation where it is.
05
Make activity measurable over time
From day one, the system records what happened: response times, ageing, exceptions, recurring issues. Not to surveil the team — to give them evidence for improvement.
06
Expand only after the first workflow is useful
We do not expand scope until the initial workflow is demonstrably better. Then, and only then, we apply the same discipline to the next workflow. Deliberate expansion beats big-bang.
The path
Start narrow, expand deliberately.
A possible implementation path — not a guaranteed transformation. Each stage builds on the previous, and we do not advance until the current stage is working.
Stage 1
One workflow, structured
- Single team, single site or building
- Structured intake: every request captured
- Clear ownership and next actions
- Human-confirmed triage and routing
Advance only when this stage is demonstrably useful.
Stage 2
Reporting and exception signals
- Weekly brief generated from the record
- Exception panel: overdue, unowned, stale
- Vendor commitment tracking
- Recurring-issue detection
Advance only when this stage is demonstrably useful.
Stage 3
A connected operating picture
- Multiple workflows, consistent structure
- Cross-site and cross-team visibility
- Pattern analysis over time
- Evidence-based improvement
Illustrative workflow using sample data. No customer data shown.
Human in the loop
Automation suggests. Humans decide.
The boundary between system and operator is explicit. The system handles structure, routing suggestions, reminders, and record-keeping. Humans handle judgment, approvals, and accountability.
The system does
- Captures requests from email, forms, manual entry
- Suggests category, urgency, owner with reasons
- Routes to teams based on rules you define
- Tracks SLAs and surfaces pre-breach warnings
- Flags exceptions: unowned, overdue, stale
- Maintains the immutable activity record
Humans do
- Confirm or override triage suggestions
- Approve vendor quotes and expenditures
- Review and close safety escalations
- Decide when to open problem records
- Own the relationship with requesters
- Are accountable for outcomes
Operating model
See it in a pilot.
One team, one workflow, four weeks. We agree what 'working' means before we start — then measure it.