Your pilot team
One operations or facilities lead who owns the outcome, plus the 3–8 people who actually receive and action requests day to day. If the people doing the work are not in the pilot, the pilot proves nothing.
Pilot plan
Prove it on your operation in four weeks.
A JFS OPS pilot is a fixed-scope, fixed-duration engagement with one team and one site. You will know by week 4 whether it earns a wider rollout — because we agree what “working” means before we start. The system under test is a control layer for unresolved work between your existing systems — nothing gets ripped out or replaced.
Timeline
Four working weeks, three phases
01
Week 0 · Set up
- · Connect to your Microsoft 365 tenant
- · Configure categories, teams, and routing
- · Invite the pilot team
02
Weeks 1–3 · Run live
- · Requests flow through the desk
- · Ownership, SLA warnings, and escalations in use
- · Weekly check-in on what is working
03
Week 4 · Review
- · Measure against the agreed success criteria
- · Export the pilot evidence pack
- · Decide: expand, adjust, or stop
Who is involved
A small group, clearly defined
Your IT contact
One person with Microsoft 365 admin rights in your tenant who can register an app and confirm permissions. Needed for about an hour in week 0 — not a six-month IT project. The week-0 checklist below is the complete ask; there is nothing hiding behind it.
JFS OPS
We configure the desk, connect intake, set up routing and SLA targets with you, train the pilot team in one session, and join a weekly 30-minute check-in.
Week 0
The complete IT checklist — nothing else
The pilot runs on SharePoint lists in your Microsoft 365 tenant — provisioned there, and your data stays there. This is the entire technical ask of your IT contact. We do not ask for tenant-wide admin rights, and we document exactly what is granted.
01
A Microsoft 365 administrator in your tenant
Someone who can register an application in Entra ID and grant admin consent. That is the only elevated access the setup needs.
02
A SharePoint site for the requests list
One site where the requests list lives. Your team owns the site; we configure the list columns the desk needs.
03
One app registration, scoped to that site
Your IT contact registers an app (“JFS OPS”), grants the SharePoint Sites.Selected application permission with admin consent, then grants the app read/write on the one approved site. The app can touch nothing else in the tenant.
04
Five values pasted into the setup form
Tenant ID, client ID, client secret, site ID, and list ID — pasted into the JFS OPS setup wizard, which tests the connection on save. About an hour, end to end.
Responsibilities
What you provide, what we handle
No ambiguity about who does what. If it is not on one of these lists, we agree it in writing before the pilot starts.
You provide
- · Access to the tools your team already works in (the standard pilot connects Microsoft 365)
- · The categories and teams requests should route to
- · One hour of your IT contact's time for the connection
- · Honest feedback in the weekly check-in
We handle
- · Desk configuration: categories, routing, SLA targets, escalation paths
- · Email intake wiring and request capture
- · Team onboarding: one training session, written guides
- · Weekly check-ins and the end-of-pilot evidence pack
Success criteria
Agreed before we start
In week 0 we agree what the pilot must prove. Week 4 measures against that list — not against vibes.
- Every request submitted during the pilot has an owner — measured, not asserted
- Submission-to-acknowledgement time against the targets we agree in week 0
- Zero safety-flagged requests left unacknowledged
- The pilot team can answer “what is open, who owns it, and what is next?” without a meeting
- A go / no-go decision the whole team understands, based on the evidence pack
Out of scope
What the pilot is not
- No custom software development during the pilot — configuration only
- No migration of historical data (we can discuss it after, with a separate plan)
- No integrations beyond your existing tools and email in the standard pilot
- No organization-wide rollout — one team, one site or building, proved first
How it is measured
A sample criteria menu
Targets are set with you in week 0 against your current baseline. The week-4 report counts every measure below — including the ones that missed.
01
SLA attainment %
The share of requests acknowledged and resolved inside the response and resolution targets agreed in week 0 — reported per urgency level, not as one blended number.
02
Median response and resolution time
How long it typically takes for someone to take responsibility, and for the work to be done. Medians, because one disaster should not hide a good month — and the week-4 report shows the misses too.
03
Vendor-commitment capture %
The share of vendor jobs with a recorded promised date. A commitment you did not record is a commitment you cannot hold.
04
Safety escalation handling
Zero unacknowledged safety flags, measured continuously. Safety escalations get an explicit acknowledgement target agreed in week 0 — this one is not negotiable.
Commercial terms
Agreed in writing, before anything starts
No surprise fees mid-pilot. The commercial shape of a standard pilot:
The pilot
- · Fixed duration: four working weeks, plus a week-0 setup
- · Fixed scope: one team, one site or building
- · Includes configuration, onboarding, weekly check-ins, and the evidence pack
- · Terms — including any pilot fee — are agreed in writing before week 0
After the pilot
- · Post-pilot pricing is driven by: number of sites, number of operators, request volume, and integrations needed
- · You receive a written proposal based on your actual pilot usage — not a tier you have to guess into
- · If you stop: your data stays in your tenant, audit records are exported to you, access is revoked
After the pilot
Expand, adjust, or stop — with evidence.
Week 4 ends with a decision the whole team understands. If it worked, we plan the rollout together. If it didn't, you keep the evidence pack and the lessons.