At a glance
Continuously in production
Data centres at initial deployment
End-customer users
Working directly in governed workflows
Operational technicians
Service tickets processed
Cumulative; the accumulation period is not defined
Footprint
Deployment and operating facts only. The two reported financial and labour figures are not shown here; they sit in the evidence section with their status, because neither has an established methodology in the project record.
01
The operating context
A large enterprise owner-operator runs a distributed mission-critical estate — more than thirty data centres at the point of initial deployment, across North America to begin with and later into additional international regions. Around four hundred technicians work the estate.
The unusual feature is that this operator has end customers of its own. More than a thousand people outside the organisation need to raise work against its facilities: hands-and-eyes tasks, rack and stack, cabling, installations. So the estate carries both an internal operating burden and an external service obligation.
02
The challenge
A human helpdesk sat in the middle. A customer raised a request, the helpdesk received it, the helpdesk worked out which site it belonged to, the site worked out which technician should do it.
Every step of that chain was a person making a routing decision. Requests were re-keyed between systems. The same information was recorded more than once in different places. Visibility was weak, because knowing the state of any given request meant asking someone. And because the work was brokered by people rather than captured as structured records, very little of the resulting operational data could be reused afterwards.
The intermediary was competent. That is what made the cost of having one invisible.
03
Why the existing model was not enough
The helpdesk was not failing. It was doing the job it had been set up to do, and doing it with people who understood the estate. That is the difficulty with this class of problem: because the intermediary performs well, the cost of the arrangement never appears in the operational reporting.
A helpdesk resolves; it does not accumulate. It closes the request in front of it. It does not leave behind a structured record of request type, site, skill level, time of day and duration that anyone can reason over a year later. Each request was handled and then, in evidentiary terms, largely lost.
Visibility depended on people being available. The state of a request was knowable by asking, which does not scale across thirty sites and a thousand external users, and does not work at all outside working hours.
Scale made it worse rather than better. More sites and more end customers meant more routing decisions, more duplication and more dependence on human coordination — while the operational data that might have justified a different operating model was the one thing the model did not produce.
04
What changed
The Service Management System of Work was deployed, covering service requests and ticketing, hands-and-eyes services, rack and stack, cabling, WHIP installation, and incident, change and problem management as governed workflows rather than as generic tickets.
The routing chain was replaced rather than automated. End customers now interact directly with a curated customer-facing environment. Operator and technician teams work in the operational environment. Both read and write the same record, with different governed views of it — so there is no reconciliation step between what the customer sees and what the estate is doing.
01
Service Delivery
Operational services from request to sign-off — service requests and ticketing, hands-and-eyes work, rack and stack, cabling and installation — handled as governed workflows with the right approvals and routing attached, rather than as generic tickets.
02
Incident & Problem
Response, resolution and root-cause prevention, against the same assets and the same operational history as the service work that surfaces them.
03
Change Management
Operational change governed where the work happens, so approvals sit inside the workflow rather than alongside it.
Solution attribution here is inferred from the scope of activity described in the source, which names activities rather than a solution list. The mapping follows canonical Systems-of-Work doctrine and is recorded internally as an inference.
05
The connected operating model
A request now enters a governed workflow with the right approvals, the right routing and the right visibility attached to it, and a customer can see its state without asking anyone. Incidents and changes arising from that work sit against the same assets and the same history.
Customer-facing view
A curated environment for end customers
More than a thousand external users raise and track work directly, rather than through email and human intermediaries.
Operational view
The working environment for operator and technician teams
Around four hundred technicians execute, escalate and close the same work items.
One governed record
Service requests, incidents, problems and change against the same assets and the same operational history. Two governed views, not two systems — so there is nothing to reconcile between what the customer sees and what the estate is doing.
06
The second effect took four and a half years.
Removing the intermediary changed the operation immediately. The more consequential change was slower, and could not have been designed for: every request added a structured row, and enough structured rows stopped being a service history and became a description of how demand behaves.
At deployment
Routing replaced. Requests enter governed workflows. Customers see state without asking. The immediate operating gain.
Through production
The record accumulates. Volumes, time-of-day patterns, request types and skill levels build up as structured operational data — more than a hundred thousand tickets' worth.
After several years
The record becomes evidence. Strong enough to support a workforce redesign across approximately four hundred staff.
07
Outcomes and evidence
Four tiers, in descending evidential strength. This deployment's strongest evidence is longevity and adoption; its quantitative figures are the weakest part of its evidence base, and are presented that way rather than promoted to the front.
Deployment and operating facts supported by the source record.
- More than four and a half years continuously in production. This is the longest-running of Clarisync's published deployments, and the reason the accrual argument above can be made at all.
- More than thirty data centres at initial deployment, subsequently expanded beyond the original footprint into additional international regions.
- More than a thousand end-customer users interact directly with governed service workflows rather than relying on email and human intermediaries. Adoption removed the need for the legacy helpdesk model.
- Approximately four hundred operational technicians work in the operational environment.
- More than a hundred thousand service tickets processed. Verify The period over which that total accumulated, and the definition of what counts as a ticket, are not recorded.
Figures reported in the source record without an established measurement basis.
- Approximately five times initial return on investment. Verify This reflects the helpdesk saving alone, relative to platform cost — not the full benefit over the life of the deployment. That scoping is the source's own and is carried here deliberately.
- Approximately six per cent labour-cost reduction in the measured optimisation programme. Verify
Why these two are not in the At A Glance strip. Neither figure has a recorded baseline, measurement period, calculation method or accountable owner in the project's evidence records. The Case Study Production Standard requires source, period, method, scope, status and owner for every published outcome; these have scope only. They are reported here as reported, in the tier that says so, and they are not presented as validated proof or drawn as a graphic.
Qualitative observation about the operating model.
- The operational record became decision-grade. After several years in production, several years of accumulated service data — volumes, time-of-day patterns, request types and skill levels — supported a workforce redesign across approximately four hundred staff: combining lower-skill activity with other site functions, and moving some technical coverage from 24×7 to 16×7 where the observed demand supported it. Permission required This is a customer operational decision about shift patterns and staffing. Publishing it needs the customer's specific agreement, separate from any general case-study permission.
- Service handled as operations rather than as tickets. The deployment did not simply digitise ticketing; the same record carries service, incident, problem and change against the same assets.
Where evidence does not exist, nothing is asserted in its place.
- No service-level, incident-volume or resolution-time outcome. None is recorded in the source, so none appears here — notwithstanding that this is the deployment a reader would most expect them from.
- No implementation duration. How long the deployment took to mobilise is not recorded.
- No causal claim about the workforce decision. The system produced the evidence the decision was taken on. It is not claimed to have made, or caused, the decision.
- No applied-AI outcome. The source records no AI or MIRI capability in this deployment, and none is implied.
08
What comes next
The source records no further planned scope for this deployment, and nothing is claimed about future expansion. The footprint has already grown beyond its original region; whether it grows further is not something this case study asserts.
A helpdesk answers the request. A record answers the question.
09
Customer perspective
Attribution status
No approved customer statement exists for this deployment. The customer operates under confidentiality and has not been asked for, or granted, permission to be quoted or identified.
The workforce redesign described in the evidence section is a customer operational decision. It requires the customer's specific agreement before publication, independently of any general case-study permission — a shift-pattern and staffing change is commercially and industrially sensitive for the organisation that made it.
A reference call with a peer operator can be arranged on request through the Proof Centre.
10
Evidence, method and governance
Anonymity
This customer is anonymised. No name, brand, site name or location appears anywhere in this asset, and none will be added without written permission. The regions of international expansion are deliberately unspecified.
The identities of the end customers using the customer-facing environment are also withheld; they are third parties to this case study and have given no permission of any kind.
Evidence basis
Deployment and operating facts — production duration, site count, end-customer and technician numbers, footprint expansion — are supported directly by the internal source record for this deployment.
Three items carry verification flags. The hundred-thousand-ticket total has no defined accumulation period or ticket definition. The approximate five-times initial return and the approximate six per cent labour-cost reduction have no recorded baseline, measurement period, calculation method or accountable owner; the source's own scoping caveat on the first is carried verbatim, which is necessary but not sufficient for publication.
Neither reported figure is drawn as a graphic anywhere on this page. A number without a method acquires false authority when it is charted, so both remain as text inside the tier that states their status.
Solution attribution is an inference. The source names a scope of service activity rather than a list of solutions; the mapping to Service Delivery, Incident & Problem and Change Management follows canonical Systems-of-Work doctrine and is recorded internally as inferred rather than stated.
The term WHIP appears unexpanded in the source record. First-use acronym expansion is required by the Clarisync Constitution, and the expansion is not held anywhere in the project. It is flagged for confirmation rather than guessed at.
Product and taxonomy notes
Service Management comprises Incident & Problem, Change Management and Service Delivery. Customer Command is the Command Layer that exposes curated customer-facing views; it is not part of the Service Management System of Work, and it is not a portal, dashboard or separate system of record. This case study uses the source's own description of a curated customer-facing environment and does not assert which Command capability delivers it, because the source does not say.
Incident Management is intentionally referenced in both Risk & Reliability and Service Management source material. That overlap is preserved rather than flattened.