From Austin Kelly, VP of Service Delivery at INOC & Xerox IT Solutions

I’ve spent years running operations and advanced technical services across enterprise network environments. Before that, I worked on the service provider side doing NOC operations, quality programs, performance management, and network project delivery.

The work has given me a pretty clear picture of what separates the networks that run well from the ones that fight their operators every day.

If you run or support enterprise networks, I want to give you eight things that I’ve seen make a measurable difference. Some of these are operational practices while some are technology decisions. A few are just organizational habits that save more time than anyone gives them credit for.

1. Design for the network you're going to have

Most enterprise networks were built to solve a problem that existed three or four years ago. The business has grown, the workforce went hybrid, the application stack moved to the cloud (partially), and the network design hasn’t caught up.

Too often, we encounter networks built to meet a set of immediate needs with little consideration for what comes next.

Then when the company needs to scale, add locations, support remote workers at volume, or integrate an acquisition, the network can’t absorb the change without a significant rearchitecture project.

A few things to keep in mind at the design stage:

Segment early. Use VLANs to group devices by function or department. A finance team’s traffic doesn’t need to share a path with guest Wi-Fi. Segmentation prevents bottlenecks and limits blast radius when something goes wrong.
Build in fault tolerance from the start. Redundant paths, failover systems, and RAID configurations for storage are standard practice, but I still see environments where a single power supply failure takes out a core switch. Redundancy costs money upfront and saves money every time it prevents an outage.
Consider services over infrastructure (when you can). Running a VPN concentrator out of AWS can be more flexible than a physical appliance in your data center, even if it costs more per unit. The ability to scale up or down based on demand is worth paying for, especially when hardware availability is unpredictable.
Design around how people actually work now. Enterprise networking used to be about connecting sites and managing what lived inside them. Now you’re supporting corporate devices, personal devices, home offices, and people working from hotels and coffee shops. The VPN and remote access infrastructure needs to handle that reality reliably and securely. If your design still assumes most users are on-site most of the time, it’s out of date.

If adding a new office location or onboarding 200 remote workers would require a major redesign, your network probably isn't ready for how the business is growing. Design with expansion and ease of upgrade built in from the start when you can.

2. Rethink what monitoring means now

“Network monitoring” has sort of outgrown its title. In 2026, a monitoring strategy that only covers network devices is incomplete. Cloud compute, applications, infrastructure, databases, and security all have to be part of the picture now.

The challenge we see teams struggle with is understanding exactly where their infrastructure lives and how to build a monitoring program around it. Until recently, the trend was to move compute to someone else’s data center. That made management easier but made monitoring harder.

What exactly do you need to monitor when half your infrastructure is in AWS, a quarter is SaaS, and the rest is on-prem?

Jim Martin, our VP of Technology, puts it well: monitoring is more than just the raw alerts off of devices, because that’s only giving you a piece of the puzzle. Understanding the business impact of a malfunctioning device or port is what actually lets you prioritize resolution. It’s about understanding why you should care and how much you should care, not just that something is red.

Before building out or revisiting a monitoring strategy, I urge teams to ask these questions:

Where does our infrastructure actually live? Map it! Cloud, on-prem, hybrid, SaaS. Each category may require different monitoring approaches.
What is each monitoring data point telling us? When we bring a new device or technology into our monitoring environment, we spend time understanding exactly what data we’re getting and what it means. Not all data is equally useful, and not all alerts are equally urgent.
What actions should each category of data trigger? Some data should drive incident workflows. Some should feed problem management. Some should route to change management. If you haven’t mapped data categories to action categories, your monitoring program is generating information nobody knows what to do with.

3. Master your protocols

This is a more technical point, but it matters operationally, too. Monitoring is not just SNMP anymore, especially at the enterprise and service provider level.

Depending on what you’re monitoring, you may need to work with APIs for cloud services, gNMI (gRPC Network Management Interface) for modern network telemetry, WMI for Windows infrastructure, synthetic transactions to validate end-user experience on web applications, and database queries to confirm things like SQL transactions are completing correctly.

Each protocol gives you a different type of visibility.

SNMP tells you device-level health.
API polling tells you application-level status.
Synthetic transactions tell you whether the actual user experience matches what the device metrics say it should be.
gNMI gives you streaming telemetry at a granularity that SNMP can’t match.

If your team is monitoring a complex environment with SNMP alone, you’re seeing one layer of a multi-layer system.

The question to ask: For each critical service in your environment, do you have monitoring at the device layer, the application layer, and the user-experience layer? If any layer is missing, that's where your blind spot is.

4. Start correlating events to stop drowning in noise

This one makes the list because it’s the single most impactful operational change we’ve made in our own NOC, and I’ve seen it change outcomes for every client we’ve deployed it for.

Here’s the problem anyone in network operations knows well:

A typical enterprise environment generates hundreds of events during peak hours.
When one thing goes wrong, ten or twenty related devices might fire alerts in the same two-minute window. In a traditional monitoring setup, each of those alerts becomes its own ticket. Now you’ve got an engineer looking at 20 tickets when there’s actually one problem.
Some platforms cut a separate ticket for each event instead of correlating events into one ticket, and it becomes a self-inflicted operational problem.
You end up spending your time on a ticketing platform trying to combine and make sense of it instead of being able to clearly see the real incident flow.

Our AIOps engine solves this by analyzing events against topology data and historical patterns, grouping related events into a single incident, and generating one enriched ticket with context from the CMDB attached. The engineer opens one ticket, sees the full picture, and starts resolving.

The operational impact comes out in the numbers: 48% of incidents in our environment auto-close without an engineer touching them. 85% of the rest resolve at Tier 1. Those numbers are directly downstream of correlation. If you’re running a NOC or evaluating one, ask whether their platform correlates events or just forwards alerts. The difference in engineer productivity is dramatic.

5. Fix your default thresholds

This is so common that it deserves its own section, even though it’s technically a subset of monitoring tuning.

Out-of-the-box thresholds in monitoring tools almost never match the actual needs of the environment they’re monitoring. We regularly find environments where CPU and memory thresholds are set at 80% because that’s the default. The result is a torrent of alerts and tickets that consume engineering time without corresponding to actual problems.

Subscribe now

When you question those thresholds, you often realize they can be set to 90% or 95% for most devices without losing any real visibility into genuine issues. The ticket volume drops just about immediately.

The fix is almost always a good alarm analysis. Take a week or two of alarm data and ask the hard questions. What does this alarm data actually mean? What do you want people to do with it? Which alarms drive actions and which are noise?

The answers should drive your filtering strategy. Data that doesn’t lead to action shouldn’t be generating tickets. It can still be collected and analyzed for trend purposes, but it shouldn’t be waking up your on-call engineer at 2am.

We've seen environments where adjusting CPU alert thresholds from 80% to 95% cut ticket volume by more than half, with zero impact on actual incident detection. The 80% threshold was generating alerts for normal operating conditions. Nobody had questioned it because it was the default!

6. Turn monitoring data into actual business intelligence

Once you’ve got the right monitoring in place and the noise is under control, the data itself becomes valuable for more than just incident response.

I’ve always believed that the more data you have, the more apt you are to identify where issues are and where they’re occurring. That sounds obvious, but in practice most teams stop at “detect the alert, resolve the ticket.” They never circle back to ask what the data is telling them about longer-term patterns.

Two examples from our own operations:

We had a client where we were analyzing performance data across their network links and spotted that certain links through a specific carrier were consistently under strain during specific time windows. By pulling together monthly average totals and presenting them to the client, they were able to go to their carrier with data and negotiate a resolution. In some cases, clients have used this kind of analysis to get financial compensation for chronic underperformance.
Another case: we traced a recurring service interruption pattern on a fiber run to a train that crossed the route at the same time every day. The vibrations from the train were enough to cause brief disruptions on the fiber. We only identified it because we had enough granular data (down to errored seconds and severely errored seconds) to see the pattern over time. That’s the kind of root cause that no amount of reactive troubleshooting would surface. It took data analysis and patience.

The practical application is building reports that do more than confirm you met your SLAs last month. Good reporting should answer questions like:

Which circuits experience the most outages?
Which hardware categories fail most frequently?
Are there time-based patterns to recurring incidents?
What should we address through problem management versus change management?

7. Sharpen your focus on change management and communication

This one isn’t glamorous. Nobody writes conference talks about change control procedures. But it saves more time than almost any technology investment you can make!

The amount of time wasted chasing false alarms because a customer moved equipment without telling anyone is staggering. I’ve seen it happen where a client relocates a rack and doesn’t notify the NOC. That triggers a cascade of false alarms. An engineer spends an hour and a half investigating. A senior resource on the client side spends another hour and a half. All of it could have been prevented by a single email.

The financial cost of this kind of thing is hard to measure directly, but the opportunity cost is real. Every hour an engineer spends chasing a ghost is an hour they’re not spending on actual problems or improvement work.

The sectors that we see get this right the most are instructive.

Federal agencies tend to have strong change control: changes get reviewed, notifications go to all relevant parties, and documentation is maintained throughout.
Financial institutions, especially high-frequency trading firms and large banks, have similarly strict procedures. In both cases, everyone knows what’s happening and when, and changes are handled in a structured, predictable way.

Most enterprises can’t replicate federal-grade change control overnight. But a few basics go a long way:

Require notification before any physical infrastructure changes. A standard form, an email alias, a Slack channel. The format doesn’t matter as long as the notification happens before the work starts.
Automate your maintenance window suppression. When a change is scheduled and documented, the monitoring system should suppress alerts on the affected devices during the window. This is standard in our platform and it eliminates an entire category of false alarms.
Tie change records to incidents. If an incident fires shortly after a documented change, the system should automatically associate them. That context alone can cut diagnostic time dramatically.

8. Know when to build vs. partner

This is the decision that sits underneath all the others. Some organizations can build and run an effective NOC internally. Most can’t, or at least can’t do it at the maturity level their environment requires.

The honest calculus: maintaining 24x7 coverage requires a minimum of 10 to 12 staff. Finding people with NOC expertise is its own challenge because the skill set is specialized. Building the operational framework (runbooks, escalation procedures, SLA management, quality programs, reporting) is a multi-year project that requires experience most companies don’t have in-house. And the tooling investment, a proper AIOps-enabled monitoring platform with CMDB integration and automated workflows, is substantial.

When a company partners with a provider that already has all of this running, they get “instant operational maturity.” Years of process development, tooling refinement, and staffing optimization are available from day one. The internal team can focus on strategic work instead of break-fix.

The decision factors I’d consider:

Can you actually staff 24x7 coverage reliably? Not just bodies in seats but skilled engineers at every shift, with backup and escalation paths that work at 3am on a Saturday.
Do you have the tooling? Event correlation, automated ticketing, CMDB integration, runbook automation, and reporting that drives improvement. Building this from scratch is a multi-year, multi-million-dollar project.
Can you commit to continuous improvement? A NOC that isn’t getting better is getting worse. Quality programs, alarm analysis, process refinement, and data-driven improvement cycles are what separate a good NOC from one that just answers the phone.

If the answer to any of those is “not really,” the partnership model is probably the better path.

Getting started

If you’ve read this far and some of these points hit close to home, the first step is usually an honest assessment of where your monitoring and operations actually stand. Not where you think they are. Where the data says they are.

We do this regularly with clients through alarm analysis, operational assessments, and monitoring program reviews. The output is specific: here’s what your alarm data is telling you, here’s where the gaps are, here’s what to prioritize. No commitments required. Just a clear-eyed look at the current state and a practical path forward.

Get in touch if that’s useful.

📄 Also, be sure to read our free white paper that digs into the NOC and ITOps side of this a little deeper: The NOC Improvement Playbook — 10 Common Problems We See and Solve in Our Consulting Engagements

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.

The Operations Desk

8 Tips for Managing an Enterprise Network in…