From Jim Martin, VP of Technology, Managed Services at INOC & Xerox IT Solutions

Most NOCs we’ve walked into over the past 20 years share the same basic problem. It’s not the tooling or the talent. It’s the structure.

The typical NOC is a room full of engineers who all do roughly the same thing. An alarm fires, whoever is available picks it up, works it until they either solve it or get stuck, and then escalates it to someone more senior. The senior person drops what they were doing, takes over, and works it from there.

Rinse, repeat, all shift, every shift.

This works when you’re monitoring a few hundred devices. It stops working when you’re monitoring thousands, across multiple clients, with different SLAs, different severity tiers, and different escalation requirements. At that scale, the “everyone does everything” model means your most experienced engineers spend most of their time on routine issues that a less senior person could have handled. Your P1 response is inconsistent because whoever happens to be free gets the critical incident. And your Tier 1 engineers never develop because they escalate anything that doesn’t match a pattern they’ve seen before.

The fix isn’t better tools. It’s a better operating structure.

What a well-structured NOC actually looks like

At INOC and Xerox IT Solutions, we've spent years developing what we call the Structured NOC. It's the operational framework we use to deliver 24x7 support across enterprise, service provider, and OEM environments.

The diagram below shows how it's organized.

The 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.

Here’s how each layer works, and more importantly, what the client gets from each one.

The front door: alarm analysis and auto-correlation

Everything starts here. Alarms and events from client infrastructure flow into the platform through secure connectivity. Before a human touches anything, the AIOps engine processes the incoming data.

At this stage, three things happen:

This layer manages time-to-ticket SLOs. The time between an alarm firing and a ticket being created in ServiceNow, enriched with CMDB data and ready for an engineer, is measured in seconds. In our environment, the target is under 30 seconds from alarm to a fully contextualized ticket.

The outcome of this is engineers not being buried in noise. The correlation engine has already done the work of separating signal from noise, grouping related events, and attaching the context an engineer needs to act. The ticket volume the NOC team actually works reflects the real incident volume, not the raw alert volume. That distinction is the difference between a NOC that’s drowning and one that’s focused on the incidents that are of the highest priority.

The triage layer: Advanced Incident Management

This is where the Structured NOC model differs most from traditional operations, and where I'd argue the biggest value lives.

In a traditional NOC, incidents enter at the bottom of the org chart. Tier 1 picks up the ticket, tries to resolve it, and escalates when they can’t. The senior engineers sit at the top and wait for escalations. By the time a complex incident reaches someone with deep diagnostic experience, it may have been misdiagnosed once or twice, bounced between tiers, and accumulated hours of elapsed time.

We inverted that. Our Advanced Incident Management (AIM) team sits at the beginning of the workflow, not at the end. These are senior troubleshooting personnel whose job is to look at every incoming incident (particularly P1s and P2s) and do four things:

The AIM team also handles problem management and capacity management. They’re the people who look across incidents over time and identify patterns: recurring failures on the same circuit, capacity trends that predict future problems, chronic issues that need root cause analysis rather than repeated break-fix.

Our NOC clients get their incidents correctly diagnosed and routed from the start. The most common failure mode in NOC operations is misdiagnosis at initial triage, which causes the incident to bounce between teams, accumulate elapsed time, and frustrate everyone involved. The AIM model eliminates that by putting experienced analysts at the front.

Time to Impact Assessment (TTIA) drops because the person doing the assessment actually knows what they’re looking at.

We track TTIA as a formal metric here. It measures how quickly we can tell the client: here’s what’s happening, here’s what’s affected, and here’s what we’re doing about it. In a P1 situation, that communication is often more valuable to the client than the resolution itself, because it eliminates the uncertainty that causes organizational anxiety during an outage.

Service Desk and Tier 1: the workhorse

The bottom of the structure diagram is where most of the daily volume lives. The Service Desk and Tier 1 team handles the incoming support requests from client engineering and sysadmin teams (phone, email, chat), as well as the incidents that flow down from the alarm analysis layer after the AIM team has assessed and prioritized them.

Tier 1 work includes:

• Executing runbook procedures

• Searching known error and knowledge databases

• Providing call and email support to end users and client engineers

• Incident updates and follow-up

• Access control management

• Coordinating RMA and dispatch when hardware needs to be replaced or a technician needs to go on-site

The key operational metric at this tier is first-level resolution rate: what percentage of incidents get resolved without escalation. In our environment, that number is 85% or higher. Most teams we talk to who run their own NOCs see 40 to 60%, sometimes even less.

The difference comes from two things: the enriched ticket (which gives the Tier 1 engineer full context from the moment they open it) and the runbook library (which gives them a defined procedure instead of requiring them to improvise).

Our clients get fast, consistent resolution for the majority of incidents. When 85% of tickets resolve at Tier 1, the client’s experience is that most problems get fixed quickly by the first person who touches them. They’re not being bounced between teams or repeating the same information to three different engineers. The structure ensures that Tier 1 has the tools and context to resolve what they can, and a clean handoff path for what they can’t.

Tier 2 and Tier 3: the specialists

When Tier 1 can’t resolve an issue (the remaining ~15%), it escalates to Tier 2 or Tier 3. These are advanced technical specialists with deep domain expertise in specific technology areas like routing and switching, optical, wireless, cloud infrastructure, security, and voice.

The critical thing about this tier is utilization. In an unstructured NOC, your most skilled engineers spend 60 to 80% of their time on work that a Tier 1 engineer could handle. That’s expensive, and it means they’re unavailable when a genuinely complex problem comes in.

In the Structured NOC model, Tier 2/3 engineers spend their time on the incidents that actually require their expertise. Our framework typically reduces high-tier support activities by 60% or more, sometimes as much as 90%. We measure this by tracking how activities migrate between tiers over the first few months of a new client engagement.

When our clients have a complex problem that requires deep expertise, that expertise is available. The specialists aren’t buried in password resets and routine maintenance tickets. They’re actually working on the problems that need them.

The external connections

The right side of the diagram shows the operational integrations that extend beyond the core NOC team.

To run through them quickly:

It’s one point of contact for everything. When a circuit goes down and the carrier needs to dispatch a technician, the NOC handles that coordination.

When a switch fails under warranty and the OEM needs to ship a replacement, the NOC handles the RMA. The client’s internal team isn’t spending time on vendor management and ticket tracking across multiple providers. That work is absorbed into the NOC operation.

The migration effect

One of the things that validates this model is what happens during the first few months of a new client engagement. When we onboard a team, their incident distribution usually reflects the unstructured model they came from.

Too many incidents are escalating to high tiers. The Tier 1 resolution rate is low. Senior engineers are handling routine work. Time to resolution is inconsistent.

Over the first 90 to 180 days on the Structured NOC, activities steadily migrate to their appropriate tiers.

• Tier 1 starts resolving more because the runbooks are built, the CMDB is populated, and the enriched tickets give them what they need.

• AIM starts catching misdiagnoses earlier.

• The auto-resolution rate climbs as the platform learns the client’s environment and more patterns qualify for automated remediation.

By the six-month mark, the distribution looks fundamentally different. High-tier activities have dropped by 60 to 90%. Tier 1 resolution is at or above 85%. Auto-resolution is handling nearly half of all incidents without human intervention. And the metrics (TTN, TTA, TTIA, MTTR) are tracking at levels the client has never seen from an internal operation.

At more or less full maturity, the numbers usually look like:

• 85%+ Tier 1 resolution rate.

• 48% auto-closed without engineer intervention.

• 45% reduction in time-to-action year over year.

• Year-over-year cost reduction commitments of 5% in years 2 and 3 through AIOps maturation.

Why structure (in some ways) matters more than tools

We’ve been in this industry long enough to have watched multiple generations of NOC tooling come and go. SNMP managers, NMS platforms, ITSM systems, AIOps engines. The tools keep improving, but the NOCs that perform well have one thing in common: the operational structure is right.

A well-structured NOC with average tooling will outperform a poorly structured NOC with best-in-class tooling every time. The structure determines who handles what, how incidents flow, where decisions get made, and whether your most experienced people spend their time on the problems that need them or on the problems that just happen to land in their queue first.

The Structured NOC model we run is the result of two decades of building, measuring, and refining this structure across hundreds of client environments. It’s not the only way to organize a NOC. But the principles behind it, senior triage at the front, tiered resolution with clear escalation paths, automated correlation and enrichment feeding the human workflow, dedicated critical incident response, and continuous measurement driving improvement, are the principles that produce consistent, measurable results.

If you’re running a NOC internally and your Tier 1 resolution rate is below 60%, your senior engineers are spending more than half their time on routine work, or your P1 response quality depends on who’s on shift, the structure is the thing to fix. Not the dashboard and not the alerting rules. The structure.

If you want to see how this model would apply to your environment, get in touch. We’ll walk you through the operational framework and show you what the tier migration looks like for organizations similar to yours.

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.

From Gregg DePratt, Former Solutions Architect II at Xerox IT Solutions

The term “managed workstation” has always undersold what’s actually happening around helping end-users. That term conjures an image of someone keeping laptops patched and answering the phone when Outlook stops working. And ten years ago, that was basically it.

Today though, the scope of what it means to support a workforce is different. Employees are in offices, at home, in hotel rooms, at client sites, and just about everywhere else. Their devices are laptops, tablets, phones and conference room hardware. The software stack is mostly cloud-based now (but not entirely).

Some companies still have servers sitting next to the water heater while others are fully on Azure. Most are somewhere in between, running a hybrid setup they didn’t entirely plan, with tools they’ve accumulated over time rather than chosen.

I’m responsible for service delivery across Xerox IT Solutions, including everything from our NOC operations through our managed services and support functions. My teams handle onboarding, tools configuration, and getting clients plugged into our platforms and services.

I want to quickly walk through what modern workforce support actually involves, because most of the descriptions I see out there, including our own in some cases, don’t go deep enough to be useful.

What the job of workforce support actually is now

We call it Modern Workforce Solutions, and that name is better because it captures the real scope:

That’s a big surface area, and most MSPs cover a slice of it. Some cover a few slices. What we’re building is a model where one partner handles all of it, from procurement to retirement, with one platform underneath.

If you’re running IT for a growing business, the practical question isn’t “who manages my laptops.” It’s “who manages the environment my people work in.” Those are different questions with different answers.

The tower model for endpoint security

At Xerox, we’ve restructured how our support teams are organized. We’re moving to a tower model where support is divided into three verticals: end-user compute (laptops, desktops, mobile devices), data center and server infrastructure (DCO tower), and networking.

Each tower has tiered support within it. When a user calls in with a laptop issue, the help/service desk handles the initial assessment. If the problem goes deeper than a 15-minute resolution, it routes to the end-user compute tower. If the problem turns out to be a broader system issue, it routes to the DCO or networking tower as an incident.

The reason this matters from the client’s perspective is routing accuracy.

• In a traditional help desk, every call goes to the same queue. The person answering doesn’t always have the context to distinguish between a user’s laptop problem and a system-wide application failure.

• In our new model, the system will classify and route, so the right specialist gets the right problem.

Pete Prosen, who runs our enterprise service desk operations, put it well: when a user calls in and says “I can’t use this application,” and it turns out nobody on the site can use it, that’s not a help desk ticket. That’s an incident. The tower model handles the reclassification without the user having to know the difference.

What “proactive” actually means for workforce support

The word “proactive” gets used a lot in managed services and really deserves to be defined and challenged. Here’s what it means in ours:

We just finished migrating to Datto RMM as our remote monitoring and management platform. What we’re doing with it draws on the same operational thinking behind our Xerox INOC Platform 3.0 on the NOC side: use the data the tooling generates to identify and resolve problems before the user has to call in.

That same approach applies to CPU utilization, memory, backup status, software update failures, certificate expirations. The RMM gives us the data points. The question we’re working through is which of those data points can trigger an automated remediation versus which ones need a person.

This is the same logic that drives our NOC’s high auto-resolution rate on infrastructure incidents. We’re applying it to the endpoint layer.

End-user onboarding never stops!

On the NOC side, onboarding is an actual event. A new client comes in, we integrate their environment, and the concept of onboarding fades into the background. On the managed services side, onboarding is continuous.

A small business with 50 users adds 10 new hires over the course of a year. Each one needs a laptop, configured to spec, with the RMM agent deployed, the EDR solution installed, Microsoft 365 provisioned, security baselines applied, and everything enrolled in monitoring. If that process is painful for the client (calling us, filling out forms, waiting days), they’ll leave. The friction alone isn’t worth the headache.

What we’re building is automatic detection of new machines entering the environment. A device shows up on the network, we detect it, deploy the RMM agent, install the EDR, apply the security baseline, and enroll it in monitoring. The client told us they have a new user. We take care of the rest behind the scenes. Nobody had to touch anything.

For clients who want more control, we’re working on a self-service model through ServiceNow where they can log into a portal and say “monitor this device,” “push this software,” or “take this out of monitoring.” It puts them in control without requiring them to call us or wait for a ticket to be processed.

That second model works well for companies that have some internal IT capability and want to co-manage the environment. The first model (full automation) works for companies where we are their entire IT department. Both are legitimate, and the service needs to accommodate both.

Workforce security

Human factors are still the biggest risk at the workstation level. You can deploy every tool in the world, and someone will still click the wrong link in an email.

Our approach to security now is layered rather than a single tool. Here’s what that looks like:

What makes this work as a managed service is that the client doesn’t have to source, configure, and maintain five separate security tools anymore. The whole stack comes as part of the service, deployed consistently across every device, updated automatically, and monitored centrally.

For compliance-heavy clients (healthcare, financial services, education), the monitoring and reporting data feeds directly into audit documentation. That alone saves significant time during compliance cycles.

Microsoft 365 and the cloud layer

This is a bigger part of modern workforce support than most people realize. Xerox is a Tier 1 Microsoft CSP (Cloud Solution Provider) partner, which means we handle Microsoft 365 licensing, Azure management, and tenant administration directly.

In practice, that means a client’s Microsoft licensing, mailbox management, Teams configuration, SharePoint administration, OneDrive policies, Intune (mobile device management), and Azure Active Directory all get managed through us. When something breaks in their M365 environment, they call the same number they call for a laptop issue. One team, one ticket, one platform.

The alternative, which is how most companies do it today, is managing Microsoft licensing through one partner, getting help desk support from a second, and running security through a third. Then spending internal IT hours integrating the three.

Where AI fits on the endpoint side

On the NOC side, there’s commonality in workflows, but each incident has individual character. A circuit goes down, and it might be the same carrier, but it’s not the same phone number or the same root cause every time.

On the help desk side, the tickets are more repetitive. If you read 1,500 help desk tickets and 1,000 of them are the same password reset problem, AI can identify that pattern and generate the knowledge article to prevent it from being a ticket next time.

The gap right now is ticket data quality. Closing a ticket without documentation into what was done makes it hard for any system (AI or human) to learn from the resolution. We’re addressing this in the new platform by automating time tracking (you click “work ticket,” work the ticket, click save, and the system calculates your time) and by building in categorization guidance (the system suggests the correct category based on the ticket content, so engineers aren’t filing password resets under “server” because they happened to log into the AD server to do the reset).

That data quality work is boring but foundational. AI can’t learn from bad data.

What “one provider” actually gets you

I’ve been in and around managed services long enough to know that most clients aren’t looking for magic. They’re looking for less coordination.

When you buy workstation support from one vendor, security from another, cloud management from a third, procurement from a fourth, and telecom from a fifth, you end up spending a meaningful chunk of your IT budget on integrating those providers. Not in a formal sense. In the sense that your internal people become the glue between five different companies that don’t talk to each other.

I’ve started using a different label internally for what Xerox is becoming. We’re really a technology services provider. Managed services is one part of that. But when you can procure hardware across every category (traditional, non-traditional, network, server, endpoint), manage Microsoft licensing as a Tier 1 CSP, provide help desk and NOC support through one platform, do provisioning and deployment through our integration centers, and offer optimization and vCIO advisory on top of all of it, you’ve moved past the MSP model.

A small business shouldn’t need to find five vendors and Frankenstein them together with Zapier and hope it works. They should be able to start with one partner and grow into whatever they need as their business grows. That’s the model. And I realize we’re not fully there yet for every service area. But the structure is in place, and the direction is clear.

What to look for if you’re evaluating this

If you’re shopping for modern workforce support, either because your MSP isn’t keeping up or because you’re building this function for the first time, a few things are worth asking:

The companies that build IT support on a platform rather than a collection of point tools will spend less time coordinating and more time working. That's the shift we're in the middle of. I'll keep writing about it as we get further along.

Learn more about our modern workforce solutions and get in touch to start the conversation.

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.

From Jim Martin, VP of Technology, Managed Services at INOC & Xerox IT Solutions

Most service providers who monitor and manage network infrastructure say they’re “AI-enabled” one way or another now. In practice, though, that usually means they’ve bolted on a dashboard or reporting tool that uses the word “intelligence” somewhere in the interface. Maybe they’ve got a couple of correlation rules. Maybe they’ve integrated GenAI into their ticketing.

Our NOC operations service, INOC, has been applying machine learning and automation to operations infrastructure for several years now. We call the result the Xerox INOC Platform 3.0. I’ll walk through the platform and give you a tour of how AI and automation actually show up in our operations and what they do.

This is going to be detailed! If you run a NOC or you’re evaluating one, this is the piece where you can compare claims against actual mechanics.

The Xerox INOC platform in 30 seconds

Before getting into the AI specifics, it helps to understand what the platform is. The Xerox INOC Platform 3.0 is our operating system for NOC and service desk delivery.

It has three major flows: alarm, ticketing, and notification.

I’ll unpack this:

On the left side, client infrastructure and monitoring tools (LogicMonitor, SolarWinds, New Relic, Datto, Nagios, Dynatrace, whatever the client runs) feed alarm and event data into our AIOps engine.

That engine processes, correlates, and contextualizes that data. The output feeds into ServiceNow, our ITSM platform, where incidents are created, enriched from the CMDB, and worked by engineers. On the right side, integrations push data back into the client’s ITSM (ServiceNow, Jira, Freshworks, HaloITSM, Salesforce) and communications tools (Slack, Microsoft Teams, Twilio, email).

The whole process from alarm ingestion to an engineer holding a fully contextualized ticket can take under a minute. If you want the full deep-dive, stop here and read our platform explainer first.

This gives you an idea of the “shell.” Now here’s where AI, ML, and automation actually live inside it.

1. Event correlation

This is the core of our AIOps tooling, and it’s one of the platform’s biggest differentiators. A typical mid-sized environment can generate hundreds of events during peak hours. When a fiber line gets cut, 50 different devices might fire alarms in the same two-minute window. In a traditional NOC, that’s 50 tickets, 50 triage actions, and several engineers chasing what turns out to be one problem.

Our AIOps engine takes those 50 alarms, analyzes them against topology data and historical patterns, identifies that they’re all expressions of the same underlying incident, and generates one ticket. The engine is doing alarm correlation, pattern matching, and noise reduction in real time.

Rather than querying a static set of rules, we’re using extremely carefully trained AI to improve the correlation accuracy over time as we process more data from a given client’s environment. The more it sees, the better it gets at grouping related events and separating genuinely new issues from noise.

The operational impact is direct: engineers aren’t triaging 50 tickets. They’re triaging one! The cognitive load difference is enormous.

2. Automatic ticket creation and enrichment

Once the AIOps has correlated events into an incident, the system automatically creates a ticket in ServiceNow. This is where the CMDB does its work.

The incident ticket gets created with the following context already attached:

All of that is pulled from the CMDB and linked in a few seconds.

In a traditional NOC, an engineer would spend the first 10 to 15 minutes of an incident gathering this information manually. By the time they opened the ticket, they’d be starting from nothing. In our environment, the engineer opens a ticket that already has everything they need.

This is automation and data integration, not machine learning specifically. But it’s the foundation that makes the ML-driven pieces (like correlation and self-healing) useful. Without the enriched ticket, the automation upstream doesn’t translate into faster resolution downstream.

3. Automatic ticket creation and enrichment

Not all incidents are equal, and our platform knows this. Each incoming incident gets classified by business impact and severity using the data the system already has about the affected services.

Our priority system runs Priority 1 (P1) through Priority 4.

Here’s a visual breakdown of our structured NOC operations with tiered workflows:

The prioritization also drives our notification workflows. Client stakeholders get notified through IVR (PanTerra), email, Slack, Twilio, or whatever other platform they use based on the priority tier and the client's notification preferences. Those notifications fire without anyone manually composing them.

4. Self-healing and auto-resolution

This is where things get interesting. For a growing class of routine operational issues, the platform doesn’t wait for an engineer.

It executes the remediation itself!

Memory restarts, service restorations, certain types of configuration drift, predictable backup failures: these all have automated remediation paths. The platform detects the pattern, matches it against known resolution procedures, executes, validates, and closes.

We now typically auto-close 48% of incidents without an engineer touching them.

5. Recurring event handling

This is an automation function that sometimes gets overlooked but saves a lot of time. A feature called Recurring Event Handler separates events that have already been associated with an existing ticket from events that are genuinely new.

When a device flaps, or an issue recurs while a ticket is still open, the platform auto-associates the new event with the existing ticket, acknowledges the alarm, and logs the correlation (engineers don’t get a second ticket for the same problem). This directly reduces mean time to resolution because it stops the NOC from treating a recurring symptom as a new incident. This is one of the most common issues in NOCs and other support functions that drive people crazy while really dragging down service levels.

6. Automated runbook execution

Runbooks are step-by-step troubleshooting procedures.

Here’s the basic “anatomy” of our typical NOC runbook:

Traditionally, an engineer would open a runbook, follow the steps, and document what they found. We’ve automated the first diagnostic steps for many incident types.

When an incident is created, the platform can automatically locate affected infrastructure elements, retrieve relevant event data, run initial diagnostics, and update the ticket with the findings. By the time a human engineer opens the ticket, the first phase of investigation is already done.

This is rule-based automation, not ML. But the benefit compounds with the correlation and enrichment pieces. The ticket arrives with context, the diagnostics have already started, and the engineer can skip the research phase and go straight to resolution.

7. GenAI

We’ve been working generative AI into ServiceNow, which is our platform’s platform so-to-speak.

The most production-ready application we have in our NOC service today is really tight ticket summarization.

When a complex incident spans days, involves shift changes, and accumulates dozens or hundreds of updates, the ticket history becomes a document in itself. An engineer joining mid-incident has to read through all of it to understand what’s happened, what’s been tried, and where things stand. GenAI condenses that history into a concise summary: what happened, what was done, what’s still open. The engineer reads a few paragraphs instead of scrolling through 80 ticket updates.

This is a genuine time savings. Anyone who has worked a long-running P1 knows how much context gets lost at shift boundaries.

The broader GenAI roadmap is what we’re calling 4.0. It might include things like:

• Automatic knowledge article generation from resolved incidents (so the system learns from every ticket it closes).

• On-the-fly runbook creation when no runbook exists for a given pattern.

• Automated action plan generation.

• Agentic workflow execution where the AI doesn’t just suggest remediation but executes it.

Platform 4.0 is in development. The GenAI applications beyond ticket summarization are still maturing. We're testing, validating, and refining.

8. Change management automation

Maintenance windows are common hurdles in NOC operations. Every time a client schedules maintenance on a device or circuit, the NOC needs to know about it to avoid creating false incidents from expected alarms. Unsurprisingly, the NOC isn’t notified as much as it would like to be.

The platform handles this automatically. When a maintenance event is recorded, alarm suppression activates for the affected configuration items. The system only creates tickets if something fires after the maintenance window closes, or if an unexpected alarm occurs during the window. The system also ties maintenance records back to configuration items, so future incidents can be correlated with recent changes.

This is one of those capabilities that’s invisible when it works and painful when it doesn’t. Maintenance-related false alarms are a significant source of noise in any NOC. Automating the suppression removes that category of waste.

9. Problem management and predictive analytics

AIOps can be used for much more than just attacking incidents. It also drives problem management by spotting patterns across incidents over time.

When the same type of incident recurs on the same circuit, device, or vendor, the platform surfaces that trend. Our reporting provides visibility into incident volumes, resolution times, categorization patterns, and infrastructure hot spots.

Clients can see which carrier circuits experience the most outages, which hardware components fail most frequently, and which categories of incidents consume the most engineering time.

The predictive element is still developing alongside the tooling available to us. We can identify patterns that precede failures (CPU trends, capacity curves, degradation trajectories) and flag them before they cause an outage. The accuracy depends on having enough historical data from a client’s environment. For clients who have been on the platform for a year or more, the pattern library is substantial.

10. Help desk applications

The help desk side is where GenAI has the most untapped potential. The help desk is (arguably) more ripe for AI than the NOC was, because the tickets are more repetitive and the workflows are more standardized.

The actual logistics of help desks are different than the NOC in ways that complicate integration, but here’s the direction we’re heading:

We're also working on smarter routing, where AI classifies incoming requests and sends them directly to the right tier or specialist, skipping the generic intake process. Executives get faster escalation. Engineers skip Tier 1 and go directly to Tier 2. Apple-specific issues go to a dedicated Apple support team, for example.

What the numbers look like

A few operational metrics that are downstream of these capabilities give some hard insight into how this all translates into actual value:

• 85% or more of incidents resolved at Tier 1.

• 48% of incidents auto-closed without an engineer touching them.

• 45% reduction in time-to-action year over year.

• Year-over-year cost reduction contractually committed: 5% in year 2, 5% in year 3, driven by AIOps maturation.

These numbers came from the AIOps and automation investments described above. Each improvement connects to a specific capability: correlation reduces noise, enrichment reduces research time, auto-resolution reduces ticket volume, runbook automation reduces diagnostic time.

What “AI-enabled” actually means in the NOCs of today

If you’ve read this far, you have a concrete picture of where AI, ML, and automation live in a modern NOC platform.

Here’s how I’d summarize it:

AI-enabled doesn’t mean the NOC runs itself. It means the platform handles the parts of operations that don’t need a person: event correlation, ticket creation, data enrichment, routine diagnostics, known-pattern remediation, stakeholder notification, and report generation.

It means the parts that do need a person (complex troubleshooting, vendor coordination, architectural decisions, client communication during outages) get better because the person starts with full context instead of a blank screen.

The humans aren’t going away! They’re going to spend less time doing things machines are better at and more time doing things that actually require judgment and expertise. It’s operational, and it’s already running.

If you want to see what this looks like on real infrastructure, get in touch. We’ll show you the platform and walk you through the data.

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.

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:

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:

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.

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.

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:

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:

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:

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.

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.

If we’re not already working together, we’re INOC, a service off of Xerox IT Solutions. We’re an ISO 27001:2022 certified 24×7 NOC providing end-to-end monitoring and management solutions including NOC support, optimization, design, and build services for enterprises, communications service providers, and OEMs.

We improve the support provided to partners’ and clients’ customers and end users.

Since we’ve become part of Xerox IT Solutions, we’re now part of an organization supporting more than 1.2 million endpoints and 250,000 infrastructure devices. We’ve resolved over a million help desk tickets. We have 600-plus engineers and network architects spread across operations, help desk and desktop support, managed workstation, managed server, managed network, managed security, data protection, field services, cloud hosting, and much more.

That work generates a lot of knowledge:

• How incidents move through a service desk.

• Where endpoint patching breaks down.

• What actually changes when you bring AIOps into a workflow.

• How backup and failover testing catches problems that scheduled patching creates.

In most teams, that knowledge usually stays internal. It lives in runbooks, in post-incident reviews, in quarterly business reviews, in the heads of the engineers who worked the problem.

The Operations Desk is where we start sharing those insights with you.

What is The Operations Desk?

This is a publication written by the people at INOC who build and run these services.

It’s not another marketing blog, nor is it a product announcement channel. We’re writing about the actual work of managing IT operations for organizations that can’t afford downtime, from the network layer to the end user’s workstation.

Here’s some of what we’re planning to publish here:

Who should subscribe?

If you work in or around IT operations, you’ll probably want to sign up.

• Maybe you lead an infrastructure team and you’re responsible for uptime, SLAs, and keeping costs under control.

• Maybe you run a help desk or service desk and you’re trying to scale without just adding headcount.

• Maybe you manage endpoints across a distributed workforce and patching alone is a full-time job.

• Maybe you’re at an MSP and you’re thinking about what operational maturity looks like at the next stage of growth.

• Maybe you’re a CIO or IT director at a mid-sized organization trying to figure out what to keep in-house and what to hand off.

You don’t need to be an INOC/Xerox IT Solutions customer to get something out of this. We’re writing for everyone in this space.

Why a newsletter?

The way people consume IT operations content has changed. Blog posts built for search engines reward generality when a lot of what we know (incident-level detail, cross-environment pattern recognition, opinionated takes from experienced engineers) doesn’t always fit that format well.

A subscriber publication does. We can write at a depth and specificity that wouldn’t make much sense elsewhere. So we’ll write what we know, put names and experience behind it, and keep it useful.

What’s coming?

Our first few posts will cover ground we already know well: topics our teams have been working on across network operations, managed services, and the help desk. After that, we’ll build out recurring formats: incident breakdowns on a regular cadence, field pattern reports, and conversations with our engineers and architects on specific service areas.

If there’s a topic you want us to cover, anything from endpoint management to data center architecture to how we run a 24x7 service desk, reply to any email. We read them.

Welcome to The Operations Desk.

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.

Share The Operations Desk