CP.01
A named operational owner
One person on the client side who owns deployment decisions across sites, not a committee.
›DDEPLOYMENT
We do not install software.
We deploy an operational layer.
Deployment is not a software install. It is the disciplined translation of an existing field operation — its sites, shifts, protocols, signals and accountability — into a controlled system of record. It runs as a five-stage protocol, applied to the operation you already have, not to a greenfield that does not exist.
5-STAGE DEPLOYMENTDISCOVER · MAP · PILOT · ROLLOUT · STEWARD
Discovery
Mapping
Pilot
Rollout
Stewardship
›D.00WHY DEPLOYMENT FAILS IN THIS CATEGORY
Five failure patterns we refuse
to repeat on any deployment.
Most field-operations deployments fail long before the pilot. They fail at the moment the operator decides to deploy software before understanding the operation.
F.01
Software installed before workflows are understood
Configuration precedes operational mapping. The system ends up describing what someone hoped the operation looked like, not how it actually runs.
F.02
Supervisors expected to translate the system informally
Rollout skips protocol design and relies on supervisors to glue the software to the operation shift by shift. Variance returns within weeks.
F.03
SOP variance between sites ignored
One protocol is configured and pushed everywhere. Sites quietly diverge. Management reports converge — on paper.
F.04
Rollout scales before pilot evidence exists
Adoption is measured in signed contracts rather than reconciled handovers. By the time the drift is visible, the rollout is already contractual.
F.05
Adoption mistaken for deployment
Users log in. Reports are filed. Dashboards load. Nothing in the operation has changed. The software has been adopted. The operation has not been deployed.
›D.01–›D.05FIVE-STAGE DEPLOYMENT PROTOCOL
One protocol, five stages,
each with inputs, outputs and guardrails.
No stage begins until the previous one produces evidence that it worked. Nothing scales until it has survived an ordinary week under load.
D.01 · Discovery
Operational mapping
Typical duration · 2–4 weeks
We map the operation as it actually runs — not as it is written on the contract. Site walkthroughs, signal audits, interviews with dispatch, supervisors and guards. The output is a written picture of the operation precise enough to deploy against.
Inputs
- Site topology, access geometry, patrol and coverage areas
- Shift structure, coverage floor and handover practice
- Existing SOPs, protocol variants and sector-specific rules
- Inbound signal sources — alarms, CCTV, radio, calls, client portal
- Current reporting paths, tools, formats and informal channels
- Contract and SLA surfaces visible to the client
Outputs
- Operational map of sites, shifts, roles, signals and protocols
- Inventory of fragmentation points — where the operation leaves the record
- List of SOP variants and sector-specific exceptions
- Named operational owner on the client side
- Scoping document agreed in writing before design begins
Guardrails
- No configuration begins during discovery
- No protocol is invented — only documented as it runs
- Discovery closes only when the written picture is confirmed by supervisors on site
D.02 · Design
Workflow and protocol specification
Typical duration · 2–3 weeks
The operational map is translated into enforceable protocol. Roles, escalation paths, SLA timers, evidence requirements and sector-specific variants are documented and agreed — in writing, before anything is configured.
Inputs
- Discovery output — operational map and variant inventory
- Contractual SLAs and client-visibility scope
- Sector-specific compliance requirements
- Evidence retention and audit-export expectations
- Communication channels already used on site
- Calendar dependencies that carry operational cadence
- Shared inboxes and monitored mail flows
- Third-party systems that carry operational signal
Outputs
- Versioned protocol set with named owners per variant
- Role model — Guard, Supervisor, Dispatcher, Manager, Client — scoped to sites
- Escalation paths and SLA timers mapped to signal types
- Evidence and audit-pack structure agreed with the client
- Client access layer scope — what they see, what they do not
Guardrails
- No protocol is approved without a named operational owner
- Every deviation path is explicit — no invisible exceptions
- Design is signed off on paper before configuration begins
D.03 · Pilot
Controlled pilot
Typical duration · 4–8 weeks
One site. One shift pattern. Success metrics defined before the pilot begins. Full supervisor coverage. The pilot is not a demo — it is the operation running on the record under load, observed and reconciled against discovery and design.
Inputs
- Configured protocols for pilot scope
- Field app provisioned on real shift devices
- Supervisor and dispatch consoles bound to pilot site
- Named pilot owners on both sides
- Baseline metrics captured pre-pilot
Outputs
- Reconciled shift, patrol, incident and task records for the pilot period
- Evidence chain captured for a full operational cycle
- Measured delta against baseline — coverage, time-to-action, protocol variance
- Documented failures, misreads and protocol gaps
- Sign-off or explicit stop-decision on pilot evidence
Guardrails
- Success metrics are fixed before the pilot starts, not after
- Rollout may not begin until pilot evidence is reconciled in writing
- Pilot may be extended or cancelled — never quietly scaled
D.04 · Rollout
Sequenced deployment
Typical duration · 8–24 weeks, site-dependent
Site by site, protocol by protocol. Rollout follows a sequenced plan with explicit success gates. Nothing scales until it works under load on the previous site. Protocol variance is absorbed through versions, not by divergence.
Inputs
- Pilot sign-off and reconciled evidence
- Rollout sequence with per-site entry criteria
- Role and access assignments per site
- Site-specific protocol variants from design
- Training plan for supervisors and dispatch per wave
Outputs
- Each site runs on the record within its own entry gate
- Per-site reconciled baseline captured before client release
- Client access layer activated per site as it clears the gate
- Rollout log with per-wave findings and protocol adjustments
Guardrails
- Sites advance through the gate individually — never by contract date
- Protocol variants are versioned, not improvised
- Client visibility opens only after the site is reconciled
- Integrations are activated only after core protocol logic is stable
- Connected systems are brought in as controlled extensions, not as first-layer dependencies
D.05 · Stewardship
Operational stewardship
Continuous · quarterly reviews
Deployment does not end at rollout. Operations drift — shifts change, clients change, sites are added, contracts evolve. Stewardship keeps the system of record aligned with the operation as it actually runs.
Inputs
- Live operational telemetry from across sites
- Quarterly operational reviews with the client's operational owner
- Cross-site drift reports and protocol variance data
- Contract changes, new sites, new sectors
Outputs
- Updated protocol versions and role-scope adjustments
- Drift-correction tasks assigned to named operational owners
- Expansion plan for new sites or sectors, reconciled to the existing deployment
- Annual operational review pack — audit-grade, client-shareable
Guardrails
- Protocol changes are versioned, never silent
- New sites re-enter the deployment protocol, not the rollout queue
- Stewardship reports name the operational owner on both sides
CONNECTED SYSTEMS
· AFTER THE CORE HOLDS
· AFTER THE CORE HOLDS
Integrations are deployed after the core holds.
Teams, Outlook, Google Calendar, shared inboxes, parcel providers or voice workflows can be connected as part of the deployment.
They come online only after the command layer, ownership model and protocol logic are stable. Connected systems extend the record; they do not define it.
Discipline is not a habit.
It is a structure the system holds.
People drift; protocol does not. Once the operation is translated into FieldOps, the standard is carried by the system — not by who happens to be on shift tonight.
›D.06WHAT THE CLIENT MUST PROVIDE
Deployment is a two-sided
operational contract.
The operation we deploy against is yours — not ours. Six commitments from the client side make the protocol runnable.
CP.02
Supervisor availability
Access to working supervisors and dispatch during discovery and pilot — not only to management.
CP.03
SOP access
Current SOPs, including the unofficial ones and the ones that exist only in supervisor memory.
CP.04
Sample reports and incidents
Real historical reports — good and bad — so protocols are designed against actual variance.
CP.05
Contract and SLA context
Client-facing contracts, SLA surfaces and evidence obligations that the deployment must honour.
CP.06
Site walkthrough access
Physical access to the sites being deployed — including night shifts, handover moments and peripheral areas.
›D.07WHAT SUCCESS LOOKS LIKE AFTER PILOT
Deployment is judged by the
operation, not the rollout plan.
Five observable changes inside an ordinary operational week — measured against the baseline captured before pilot.
S.01
Shift runs on the record
Sign-on, handover, patrol, incident and task close happen inside the same system, per shift, per site.
S.02
Signal-to-action loop is measurable
Time between an inbound signal and a named owner acting on protocol is a number, not an anecdote.
S.03
Protocol variance is visible
Deviations between shifts and sites show up against the versioned protocol — not at month-end review.
S.04
Evidence chain holds under scrutiny
Any incident in the pilot period can be reconstructed end-to-end, with attribution and access audit.
S.05
Client sees the same record
Scoped client access runs against the same operational truth — no reconciled extracts, no monthly PDF.
NEXT STEP
Deployment begins with the operation,
not the software.
Twenty minutes is enough to establish whether your operation is ready for this protocol — or which stage it needs to start at.