Modern IT organizations have mature processes for handling major incidents. When a critical application fails or becomes unavailable to hundreds of users, established frameworks immediately activate. Teams follow defined procedures for triage, escalation, communication, and recovery.
Yet another type of incident often receives far less attention despite its business impact: the complete loss of productivity experienced by an individual employee.
An employee unable to access a workstation, email, VPN, multifactor authentication, or a critical application may represent only one affected user from an IT support perspective. From a business perspective, however, that employee may be completely unable to perform their job.
I refer to these incidents as workstoppages—and most organizations are measuring them incorrectly.
Traditional incident-management processes may classify workstoppages as routine support tickets because they affect only one person. Organizations should instead treat them as a distinct operational category with dedicated identification criteria, routing rules, service objectives, and performance measures.
Most incident-management systems determine priority through a combination of impact and urgency. Impact is often associated with the number of affected users, systems, or business units, while urgency reflects how quickly action is required.
This approach works for large outages but can underestimate the cost of complete productivity loss at the individual level. A single-user incident may receive a low priority even when its effect on that employee is absolute.
Consider a salesperson unable to access CRM before a client meeting, a support agent locked out of the platform used to manage active cases, or a field technician unable to authenticate at a customer site. Each incident has a limited technical footprint, but the affected employee’s productive work has stopped.
These incidents often enter the same queue as routine requests and compete for attention according to standard service-level agreements. Consequently, a password reset for someone with an available workaround may receive the same classification as an authentication failure that has brought another employee’s work to a complete halt.
The issue is not that existing frameworks are wrong. They are generally designed to measure service impact, while the business also needs to understand productivity impact.
A workstoppage framework should distinguish among three conditions:
| Incident category | Operational condition | Primary objective |
|---|---|---|
| Major incident | A disruption affects a significant population or critical operation | Restore the service |
| Routine incident | A user experiences a problem but can continue working | Resolve within the applicable SLA |
| Workstoppage | An employee cannot perform their primary responsibilities | Restore productive capability |
Repeated workstoppages also affect the digital employee experience. Research has linked workplace interruptions with increased workload, lost concentration, and lower performance. A study of office workers examined how the frequency and duration of interruptions affect perceived workload, while a review of digital working identified technostress and overload among the consequences of poorly managed workplace technology.
Organizations do not need to replace their existing incident-management practices. They can introduce a workstoppage framework alongside their current ITSM processes.
Employees who are completely unable to work follow the same process as those experiencing routine technical problems. The service desk records the affected technology but may not determine whether the employee can still perform their primary responsibilities.
Service-desk personnel begin identifying complete losses of productive capability. A simple intake question—“Can the employee continue performing their primary job responsibilities?”—can establish whether an incident qualifies.
The service desk should also determine whether a workaround exists, whether a customer interaction or transaction is at risk, and when productive work stopped.
Workstoppages receive dedicated routing and escalation paths. Tickets move directly to the appropriate resolver group rather than waiting in a general queue.
This does not mean every workstoppage should trigger a major-incident response. The goal is proportional urgency: restoring productivity quickly without unnecessarily disrupting unrelated teams.
Organizations should also separate productivity restoration from permanent resolution. A temporary device, alternative authentication method, backup connection, or virtual desktop may allow an employee to resume work before the underlying problem is fully resolved.
Organizations begin using automation and AI to identify productivity-blocking events. Authentication failures, account lockouts, endpoint problems, VPN interruptions, and application crashes can generate signals before an employee submits a ticket.
Those signals can be correlated with information about the employee’s role, affected service, and available alternatives. The incident can then be classified and routed without relying entirely on manual triage.
This transition is already underway. Reporting on AI adoption by ITSM teams found that organizations are applying AI to incident resolution, monitoring, knowledge management, and proactive incident prevention. However, many still emphasize ticket activity rather than business outcomes.
Organizations measure productivity recovery, analyze workstoppage trends, and incorporate employee downtime into operational decisions. Leaders can identify which applications, devices, or processes cause the most workstoppages and prioritize preventive investments accordingly.
Many IT organizations track Mean Time to Resolution or Mean Time to Repair. These metrics remain useful, but they do not always capture the outcome that matters most: how quickly an employee can resume productive work.
A complementary measure is Time to Productivity Restoration, or TPR. TPR measures the time between the loss of productive capability and the point at which an employee can again perform their primary responsibilities.
Suppose IT provides a loaner device within 30 minutes, but repairing the original workstation takes two days. The technical resolution time is two days, while TPR is 30 minutes.
Tracking both measures provides a clearer picture:
MTTR measures technical resolution.
TPR measures business recovery.
The difference shows how effectively IT uses workarounds.
Organizations can establish specific service objectives, including workstoppage identification within 15 minutes, direct assignment to the correct resolver group, productivity restoration within an hour where feasible, and separate tracking of root-cause resolution.
The financial impact can be estimated using a simple calculation:
Workstoppage cost = Loaded hourly employee cost × Nonproductive hours
Organizations may also include measurable downstream costs such as missed appointments, delayed transactions, overtime, or lost revenue. Even a conservative calculation based only on employee time can reveal substantial cumulative losses across hundreds or thousands of incidents.
Implementation does not necessarily require a new platform. Most enterprise ITSM systems already provide configurable fields, routing rules, escalation workflows, automation, and reporting. Organizations can begin by adding a workstoppage flag to incident forms and measuring TPR before introducing more advanced detection and analytics.
Major incidents will always deserve immediate attention. But organizations focused exclusively on large outages may be overlooking a significant source of operational inefficiency.
By recognizing workstoppages as a distinct category and measuring success through restored productivity rather than ticket closure alone, IT teams can improve business performance and the employee experience. The future may involve predictive detection and autonomous remediation, but organizations can begin today by identifying workstoppages consistently and prioritizing the outcome that matters: getting employees back to productive work.
Jisu Dasgupta has more than 15 years of experience helping organizations make technology work for the business. He has worked across oil and gas, retail, the federal government, hospitality, and other sectors through organizations including HCL, IBM, Accenture, and Maximus. Jisu holds an MS in Information Science and Engineering, a postgraduate qualification in systems and operations, and certifications in ITIL, ServiceNow, AI, and cloud technologies.