Staffing is one of the biggest factors that drives organizations to strategically outsource their network operations center. If you’re running it 24x7x365, that means three shifts a day, every day, forever.
We’re often asked how many people are actually needed to cover a NOC around the clock. That question is obviously important, but it’s also in some ways the smallest part of what’s actually being asked. The number that keeps the lights on and the number that keeps an operation working well are often different — and it’s almost always more heads and hands than people assume.
While there’s no standard handbook for this, there are some common steps that we’ve found have to go into the process of resourcing a modern support operation.
Before you hire anyone, somebody on your team has to:
Design an operational structure and then an org structure to sit on top of it.
Write specialized job descriptions that don’t exist anywhere else in the company.
Build shift schedules that survive holidays and sick days.
Stand up training.
Procure tools and licenses.
Define a dozen or more processes running from escalation to knowledge management.
Decide how quality gets measured and who measures it.
Many teams end up guessing at how those pieces fit together, and the business absorbs the cost of the guesses as outages while it gets sorted out.
Then there’s the part almost nobody plans for, which is that none of it ends. A NOC isn’t something you simply “stand up.” It’s something you manage continuously, and it can punish the business in both directions if it isn’t carefully managed.
Understaff it and a small team takes on too much until it burns out.
Overstaff it and you’ve spent money without touching whatever operational problem was generating the workload to begin with.
What’s changed more recently is mostly on the input side. The breadth of technical knowledge a NOC engineer needs keeps widening, the market for people who have it is tight, and AI is adding demands that even long-tenured engineers haven’t dealt with before. None of that has made the math of staffing any easier.
Here’s the quick rundown of what staffing a NOC takes: the coverage math, what that math leaves out, and the hiring and retention work that ends up costing more than either.
1. Basic headcount for a NOC
The staffing question we field more than any other is how many people it takes to cover a NOC 24/7.
The answer is 10 to 12 at an absolute minimum, and most NOCs need more. If you’re running five people and telling yourself you have coverage, it’s a fragile place to be. You have a rotation that will almost certainly break the first time two of them are unavailable in the same week.
But 10 to 12 is a coverage floor, not a staffing plan. Here’s what sits on top of it:
Time off is headcount. If your company gives 10 holidays and four weeks of PTO, that’s roughly six weeks per person per year when they aren’t on the floor. Multiply that across the team and you’ve got a meaningful block of coverage that somebody has to fill. Take it from us having helped many teams wade out of staffing quagmires: it has to be in the headcount from the start, not solved later with overtime.
Attrition is a permanent line item. Assume a typical engineer stays five years. That’s an 80% retention rate, which means you’re replacing ~20% of your staff annually. On a team of 12, that’s two or three hires a year, every year, for as long as you’re running the operation. That’s often enough to be a more or less standing function rather than occasional hiring pushes.
NOCs also “run hot” because they’re naturally stressful environments and turnover concentrates at entry level, where the work is heaviest and the exit ramps are most visible. Keep in mind too that when headcount shrinks, you’re burdening the remaining staff even more, which can be quietly vicious cycle.
Training can be a multi-month pipeline. Depending on the technologies/infrastructure involved, it can take up to six months of training and on-the-job work before an engineer is ready to carry high-stakes NOC responsibilities on their own. That changes the timing of everything. The person you hire in January isn’t fully productive until summer, so you’re hiring against gaps you expect rather than gaps you have.
Somebody has to watch the work. Quality control gets discovered late in almost every operation we assess. It’s simply not a part of most teams. Reviewing tickets and escalations, looking at chronic alarms, coordinating maintenance calendars, reporting on service metrics, identifying root causes and preventive actions, checking proficiency levels against what the contract assumes. You need to be doing all of it to maintain a healthy and efficient operation, but its’s real hours, and it isn’t the same hours as working the queue.
Add all of it up and the working number is meaningfully higher than the coverage number.
There’s also the measurement piece: how do you know if you’re getting staffing right? Most teams try to answer this with KPIs and SLAs, which measure how well the NOC is performing at its job, but say almost nothing about whether it’s staffed correctly. The metrics that answer the staffing question are utilization metrics, and they’re a blind spot nearly everywhere.
Here are three key utilization metrics we use to measure our own staffing efficiency and help teams measure theirs:
Labor content for each edit of a ticket
This tells you how much work a ticket’s lifecycle actually consumed. The central distinction here is that ticket duration is not the same as labor content. Teams almost always conflate them. Duration doesn’t capture how much human labor was spent each time the ticket was edited because of the time that exists between edits while the ticket sits open.
A real ticket lifecycle looks like: created, picked up, edited, assigned a status, returned for another edit, maybe another, then resolved. Our own average is roughly 4.3 edits per ticket given the environments we support. An example is four edits at 20 minutes each, which is 80 minutes of labor content on a ticket whose duration might read as days.
Once you have the average, you extrapolate. 20 minutes of average labor content across 1,000 tickets gives you a real labor requirement you can staff against.
We always tie this directly to OPEX and morale. Without it, you get stuck in a bad (but very common) cycle: leaders can’t investigate why everyone is busy, staff feel destined to burn out, low morale drives churn, churn adds hiring cost, and the understaffed NOC then asks more of whoever remains while they still have to hit their SLAs.
Staffing correctly lets you be one of the rare operations that can actually step out of that.
Number of edits processed per hour
The simplest of the three here. It measures how many edits in the ticket lifecycle one person can perform per hour.
Its value is almost entirely relational. If labor content for a given ticket type is 15 minutes, you can reasonably expect a maximum of four per hour at 100% efficiency. This metric isn’t useful examined alone, only as a component of the larger picture.
It’s also the metric that lets you benchmark individuals. It gives the data to say one engineer is doing 50% of what they should and another 150%, and making staffing and coaching decisions from there.
A heatmap of edits by time of day and day of week
This is arguably the most important metric for making staffing decisions, because it answers the question teams actually need answered: how many people do I need in the NOC at a given time?
Here’s an example of a similar report (created tickets) to give you an idea of the insights you can almost immediately glean from it:
A well-designed heat map tells you that at 8:00 a.m. on Mondays you should expect to work up to 60 tickets. Stack the other two on top and it becomes 60 tickets on Monday at 8:00 a.m., each with four edits taking 20 minutes, which converts directly into a shift level instead of a guess.
Capturing these shouldn't be particularly burdensome, since it's mostly a matter of configuring your tools. Reporting and visualizing them is the bigger lift for a team that's metrics-deficient generally. Talk to us if you want to set this up within your own operation.
More on metrics and reporting in the NOC:
2. Structure comes before headcount!
We address headcount here first because it’s what most teams think of first when they’re staffing. But the most common sequencing error we see is hiring first and building the structure around whoever end up on the team.
Operational structure comes first. It tells you how the work will move, which tells you who you need.
A tiered support structure is the usual starting point for a NOC or similar support-focused operation that is dealing with a significant volume and variety of events.
We wrote about our tired structure extensively here:
In short though, Tier 1 works the monitoring tools and sits at the center of the flow, connecting to end-user help desks, to Tier 2 and 3 engineers, and out to third parties. Working that way, we’ve seen NOCs, our own included, resolve 65 to 75% of incidents at Tier 1.
That number is the whole economic argument for the structure. It means most of your volume is handled by the tier it should be handled by, and your senior engineers aren’t spending their week on break-fix.
Our structure has distinct operational layers, each with a defined scope of responsibility, and clear routing between them.
Alarms enter from the top.
Support requests enter from the bottom left.
Everything flows through defined paths to the right people at the right tier.
Workflows come next. Issues get prioritized into queues, each one handled by the group with the right skills, with SLAs and technology and technician skill level determining how the queues are cut. Without that, you get the wall of red and a team that treats everything as equally urgent.
Then, and only then, the org chart.
Once you have roles on paper, map them properly. A RACI chart is worth the afternoon it takes: for each task, who is responsible, who is accountable, who gets consulted, and who gets informed. Build it with the other teams in the room rather than alone, since the NOC touches most of them.
And be honest about the process list you’re signing up for alongside the people:
Escalation
QA and QC
Disaster recovery and continuity
Onboarding
Training
Continuous development
Workflow management
Incident, problem, and knowledge management
Access and credential management
In many NOCs, every one of those needs an owner, and the owners are people you have to hire.
3. What skills you're actually hiring for
Technical skills are the easy part to specify and the easier part to teach.
The modern NOC engineer needs breadth across network technologies, cloud, server operating systems, virtualization, storage, and applications. That breadth is getting harder to find each year, and AI is adding demands that even experienced engineers haven’t faced. Plenty of seasoned people have never worked on a network that reasons about its own traffic.
But after hiring into hundreds of NOC and NOC-adjacent roles across more than twenty years, the pattern we’d point to is that the soft skills are the ones you can’t train your way out of like: Communication in writing and out loud, urgency, accountability, empathy, customer service instinct.
Hire for those and the technical gaps close. Hire against them and they don’t.
It also matters which tier you’re filling. Tier 1 candidates need to read and interpret documentation quickly and follow a written procedure under pressure. That’s a different aptitude from troubleshooting. As you move up the tiers, the weight shifts toward investigation and diagnosis.
While we’ve seen excellent NOC staff come from all walks of life, a few backgrounds that tend to be positive indicators of a fit for support include:
People with a genuine interest in technology outside work. They stay current on their own and they pick up service management concepts faster.
Former military. High-tempo, high-stress, multitasking environments translate directly.
Customer service backgrounds. Call center, retail, hospitality. All of it transposes to frontline NOC work with the right training, and it brings the soft skills that are hardest to build.
Former ISP staff. They understand what’s happening behind the technologies the NOC supports, and they already know you don’t talk to a carrier the way you talk to a bank.
4. The part that costs more than hiring
Getting people in the door and into the NOC is the visible cost. Keeping them is the larger one, and it’s mostly a design problem to solve.
Start from the premise that most people don’t want to be NOC engineers forever. That’s fine! The NOC is a strong first step into a lot of disciplines, and the operations that retain well are the ones that treat it that way. Lay out paths toward technical specialization and toward management. Promote people off the frontline visibly, so the rest of the team can see the path is real.
A few things that work well for career progression here include:
Development time inside the shift. We dedicate a portion of shift work to professional development, so people can work on themselves during the workday rather than on top of it.
Hybrid roles. Someone spends part of their schedule on NOC duties and the rest on scripting, automation, process improvement, or quality work. It covers operational needs and prevents the burnout that comes from an unbroken queue.
Recognition that isn’t a gift card. A kind word or a promotion carries more than a prize, in our experience. And it’s worth recognizing more than pass-fail performance, since a team that only ever hears about its shortcomings stops hearing anything.
There’s also a company culture question underneath all of it. A team working ticket to ticket, optimizing for how fast they can close, ends up in a permanently anxious environment that managers have a hard time leading their way out of. Shifting from a ticketing culture to a customer-driven one is slow and needs constant reinforcement, but it’s the difference between a NOC people stay in and one they pass through.
One last thing that catches people: When a team outgrows its management, no warning light comes on. It happens quietly, and the first symptom is usually that nobody’s growing anymore because the manager no longer has the hours. Watch the ratio deliberately, because it won’t announce itself.
5. Where staffing usually lands
Put the pieces together and you can see why so many teams end up strategically outsourcing some or all of this.
A build takes 16 to 24 weeks minimum before the parts are even in place, and months or years beyond that to reach real operational maturity. Then the recruiting, training, scheduling, and quality work continues indefinitely. Many companies that move to us cut their total cost of ownership roughly in half, mostly because an economy of scale absorbs costs that a single in-house team has to carry alone.
One caution on the middle path: outsourcing only nights and weekends solves a scheduling problem and creates a management one, since you’re now maintaining quality and consistency across two teams instead of one. It can work. But it needs to be designed rather than improvised.
The clearest way to think about it is that the question isn’t whether a 24x7 NOC is worth having. It’s whether building and continuously managing the staffing machine behind it is the best use of your team’s attention, given everything else they could be doing.
For most companies we talk to, the answer turns out to be no.
📄 Our free white paper, Top 11 Challenges to Running a Successful NOC and How to Overcome Them, goes deeper on all of this, including how to classify NOC activities into functional categories and what to weigh in setting an efficient staffing strategy.
We've also written two longer guides on this subject: Staffing a 24x7 NOC: Costs, Challenges, and Key Considerations and How to Build and Manage an Effective NOC Team.
About INOC, a service of Xerox IT Solutions
INOC is an ISO 27001:2022 certified 24×7 NOC and an award-winning global provider of NOC Lifecycle Solutions®, including NOC support, optimization, design, and build services for enterprises, communications service providers, and OEMs. INOC solutions significantly improve the support provided to partners’ and clients’ customers and end users.
INOC assesses internal NOC operations to improve efficiency and shorten response times, and provides best practices consulting to optimize, design, and build NOC operations, frameworks, and procedures. Proactive 24×7 NOC support is provided with several options, including North America, EU, or APAC only or global integrated NOCs. INOC’s 24×7 staff provides a hands-on approach to incident resolution for technology infrastructure support.
Learn more about our NOC support and NOC operations consulting services. Get in touch to start the conversation. We’d love to talk NOC.