The monthly average is a poor description of a support operation. Financial close, a release, a new site or a critical incident can change the work dramatically. Yet the internal staffing model often remains fixed. A capacity-based model does not simply replace employees with an hours pool. It makes service obligations, demand patterns, specialist availability and escalation responsibilities explicit.
Distinguish interruption from fulfillment and improvement
A service interruption needs restoration; a routine request needs fulfillment; a recurring cause needs investigation; an enhancement needs a delivery decision. Atlassian's service-management categories distinguish incidents, service requests, problems and changes. Keeping these distinctions avoids measuring every work item as if it had the same objective or urgency.
Sources for this section: Atlassian — ITSM work categories
Understand the shape of demand
Review a representative period, including known peak events. Look at arrivals by hour or day, complexity, applications involved, repeat contacts, time spent waiting and specialist effort. A high ticket count may come from easy repetitive requests, while a small number of complex cases consumes most expert capacity. Record both counts and effort before making a sourcing decision.
Include work that is currently invisible: release support, knowledge maintenance, vendor coordination, monitoring follow-up and recurring problem investigation. Leaving these activities out creates an apparently efficient plan that has no capacity for prevention. Also separate genuinely unpredictable events from predictable peaks such as month-end close; they need different preparations.
Define service obligations before buying hours
Specify service hours, supported systems, priority definitions, response expectations, escalation ownership and conditions for major-incident handling. An hours balance is not a service-level commitment. A customer with unused capacity still needs a credible route to the right expertise when a critical business process fails.
Decide who can authorize additional work and how that decision is communicated. The agreement should explain what happens when the available capacity is nearly exhausted without allowing a spreadsheet balance to silently determine emergency behavior. Shared specialists can provide breadth, but their availability and handover arrangements must be explicitly governed rather than assumed.
Combine stable coverage with planned flexibility
A practical model has three layers: baseline coverage for predictable demand, scheduled capacity for known peaks, and a controlled escalation arrangement for exceptional work. Allocate these by skill and service, not only by total hours. Twenty available generalist hours cannot automatically replace a specialist who understands a critical integration.
For illustration, a team with 160 planned hours might reserve 100 for expected fulfillment and incident work, 30 for recurring-problem reduction and 30 for an agreed release window. This is a planning example, not a recommended universal ratio. Reforecast as evidence changes and protect the ability to respond to critical events.
Measure flow without rewarding superficial closure
Track the age of open work, reopens, repeat incidents, time to restore the service, fulfilled-request lead time and backlog movement. Review the distribution rather than relying only on an average that hides difficult cases. Pair speed with user outcomes: an early closure followed by another call is not a meaningful improvement.
DORA's guidance on work-in-process limits is relevant to the improvement work inside support: control concurrent commitments and expose waiting states. Do not apply an improvement queue mechanically to a critical incident. The operating model needs both a disciplined planned-work flow and a distinct, clearly owned response path for disruption.
Sources for this section: DORA — Work in process limits
Make knowledge and continuity part of the service
Before transitioning support, agree a service inventory, access controls, runbooks, contacts, escalation paths and acceptance criteria. Verify that someone other than the outgoing specialist can use the documentation. Keep source code and operating knowledge accessible through controlled customer-specific repositories and records, not personal accounts or informal messages.
Review the model jointly with internal IT and business process owners. Examine which recurring issues should become improvements and whether the service is improving resilience or merely processing more contacts. Retain internal accountability even when execution is shared with a provider. Flexibility is useful only when responsibility stays clear.
Evaluate the full economic picture, including retained internal effort, coordination, transition and specialist availability. Do not assume that a more flexible contract necessarily reduces total cost. The decision should reflect the required service outcome and the demand profile, not a promised saving detached from the actual operating scope.
A governed capacity model
- 1Service scopeSystems, service hours and priorities.
- 2Demand profileVolume, effort, peaks and skills.
- 3Capacity planBaseline, scheduled peaks and escalation.
- 4Operating reviewBacklog, recurrence, outcomes and reforecasting.
The next management decision
Buy a governed service with the right capacity and expertise—not an unqualified promise that a pool of hours replaces every service obligation.
Explore the relevant Optenera serviceSources and further reading
The sources support the concepts referenced in the article. The recommendations and practical examples are an Optenera framework, not a claim of endorsement by the source organizations.
