Common ServiceNow Proactive Customer Service Operations Mistakes and How to Avoid Them

Mistake: Ignoring Correlation Between Events

Symptom: The alert feed behind Proactive Customer Service Operations (CSO) produces thousands of alerts, most of which are false positives. Engineers get alert fatigue and stop reading them. Critical issues go unnoticed because they are buried in noise.

Root cause: CSO is configured to trigger on raw metrics without correlation. A single CPU spike triggers an alert; five spikes from the same server within an hour should trigger one escalation, not five. Or a network timeout and a slow transaction are correlated events pointing to the same upstream issue, but are treated as separate alerts.

Fix: Use event correlation and grouping. Configure CSO to aggregate alerts by customer, by service, or by component. If the same server generates five alerts within an hour, group them into one incident with five linked alerts. Correlate events: if network latency and transaction time both spike, check if they share a root cause before escalating.

Prevention: Start with a small set of high-signal alerts (customer complaints, business impact metrics) and tune them to match your environment’s baseline. As the baseline stabilizes, gradually add alerts for secondary metrics. Measure alert accuracy monthly: what fraction of alerts led to actual incidents?

Mistake: Opening a Proactive Case for Every Alert

Symptom: the alert feed that Event Management hands to CSO turns almost every alert into a proactive case. Agents open the queue each morning to find cases for internal infrastructure that no customer uses, cases for services that recovered before anyone looked, and several cases for the same underlying fault. The queue grows faster than it can be worked, and agents start closing cases unread.

Root cause: the rule that creates proactive cases is not restricted. It fires on any alert rather than on alerts whose affected configuration items are tied to install base items that customers actually hold, or to services customers subscribe to. The application is doing what it was told; the mistake is in the scope of the instruction.

Fix: narrow the case-creation rule to alerts with at least one affected install base item or a customer-facing service, and to severities that a customer would notice. Where several alerts describe the same fault across many customers, let the application propose a major case and attach the individual customer cases to it, rather than working each one in isolation.

Prevention: review the created cases monthly and sort them into three groups: a customer was affected, a customer could have been affected, no customer was affected. If the third group is large, the rule is too wide. Tighten the scope before adding any new alert source.

Mistake: Install Base Records That No Longer Match Reality

Symptom: a proactive case names a customer who stopped using the affected product last year, while the customer who does use it is never contacted. Agents learn not to trust the affected-customer list and check it by hand before every contact, which removes most of the value of having it generated.

Root cause: the relationships between configuration items, install base items and accounts were loaded once and never maintained. Renewals, cancellations, migrations and product swaps happen in the commercial systems and do not reach the install base, so the application identifies affected customers from a picture of the estate that is out of date.

Fix: treat the install base as the record that decides who is contacted, and give it an owner. Feed changes from the order and contract processes into install base items, and link each item to the configuration items that deliver it. Retire items when a customer leaves, so alerts on that infrastructure stop producing cases for them.

Prevention: reconcile a sample of install base items against the commercial record each quarter, starting with the customers who receive the most proactive contact. Treat a case raised for the wrong customer as a data defect to be traced, not as an agent error.

Mistake: Routing the Case to a Queue That Does Not Own the Customer

Symptom: a proactive case lands in a technical queue because the alert came from infrastructure. Engineers work the fault, fix it and close the case. The customer is never told that anything happened, or hears about it only when they call to report the problem themselves, by which time the proactive case has already been closed.

Root cause: the assignment rules were copied from incident routing, which sends work to whoever can fix the technology. A proactive case has two jobs, the technical fault and the customer contact, and the second one has no owner.

Fix: give the proactive case a customer-facing owner from the account or service team, and link it to the incident or alert that engineers are working. The engineers resolve the technical record; the case owner decides what the customer is told and when, and closes the case only after the contact has been made or deliberately withheld.

Prevention: define the assignment rule by customer segment and service, not by technology, and test it with a sample of past alerts before enabling it. Review cases closed without any customer contact each month and ask why.

Mistake: Creating Cases With No Assignment and No Notification Plan

Symptom: proactive cases are created correctly but sit unassigned. Nobody is notified, so nobody knows the case exists until a report is run. Meanwhile the fault is fixed through a separate channel, and the case is eventually closed days later with no record of what the customer was told.

Root cause: case creation was switched on before the handling design was finished. There is no assignment rule for proactive cases, no notification to the owner, and no agreed template for what a customer should receive and when.

Fix: assign automatically on creation using the ownership rules above, notify the owner through the channel the team actually reads, and attach a customer-facing update template that states what the customer may see, what is being done and whether they need to act. Agree the consent and notification preferences per account before the first message goes out.

Prevention: test the whole path with a single manual proactive case before enabling automatic creation: confirm assignment, owner notification, the customer template and the link to the technical record. Then enable one alert source at a time and repeat the test for each.

Mistake: No Integration with Change Management

Symptom: A planned maintenance window is scheduled, but CSO still fires alerts during the window because no one told CSO that changes are happening. The on-call team is woken up for expected service degradation.

Root cause: CSO and change management are disconnected. When a change is approved, CSO is not aware of it and does not suppress alerts during the change window.

Fix: Link CSO to change management. When a change is in progress, suppress related alerts. Create a mapping: if a change involves server X, suppress alerts for server X during the change window. When the change is complete, resume normal alerting.

Prevention: Create a workflow: before a change is approved, identify which alerts should be suppressed and for how long. During the change window, CSO suppresses those alerts. After the change, resume normal alerting and verify that the service is healthy before closing the change.

Counting outreach as success

The earliest sign of this mistake is a monthly report that celebrates the number of proactive contacts made. A team that measures contacts will make more of them, and the customers receiving the calls soon learn to ignore them. The fix is to change the question. For each proactive contact, record whether the customer already knew about the problem, whether the signal was confirmed as real, and whether the customer opened a case in the following period. A contact that was unnecessary is still worth counting, because it tells you where a rule is too sensitive.

A first check is to take the last month’s outreach and sort it into three piles: the customer had noticed already, the customer had not noticed and the issue was real, and the customer had not noticed and nothing was wrong. If the third pile is the largest, the rules are generating the wrong work.

Sending internal alert language to customers

Monitoring tools produce messages written for engineers: a metric name, a threshold, a host identifier. When those messages are passed through to a customer contact with little change, the customer receives something they cannot act on and cannot tell whether it matters. The customer then either ignores the message or calls support to ask what it means, which is the reactive load the program was meant to reduce.

Write a separate customer-facing version of each outreach. It should state what the customer may see, what the provider is already doing about it, and what the customer needs to do, if anything. Keep the internal detail in the case for the engineers who need it. A simple test is to read the message aloud to someone outside the operations team and ask what they would do next. If they cannot answer, the message is not ready.

Starting collection before consent is settled

Teams often connect monitoring feeds quickly because the technical work is interesting and the commercial conversation is slow. The result is data flowing from customer environments under an agreement that does not quite cover what is being collected. Usage data gets pulled in with an operational consent, or a feed includes fields that a customer did not agree to share. When this comes to light, the program often stops for months, and the trust it was built on does not come back quickly.

Put a stop on each feed until its scope is recorded against the customer account. This is slower at the start and quicker over the life of the program, because it removes the need to unwind collection later.

Leaving health scores unexplained

A health score that combines several signals is useful only if the account manager can explain why a customer moved from green to amber. When the score is a black box, the account manager either trusts it blindly or ignores it. Both outcomes waste the signal. Require that every score change can be traced to the inputs that caused it, and that the account manager can see those inputs without asking the analytics team.

When a score moves and the explanation is weak, treat it as a defect in the score. The question to ask is whether the signal is real and the weighting is wrong, or whether the signal is noise that should be removed from the score entirely.

Running the program without a feedback loop

Closed incidents and closed outreach are a rich source of tuning data. Yet many teams close the record and move on. Without a monthly review of which alerts were confirmed, which were noise and which customers responded, the rules stay as they were on launch day, and the program drifts from the customers it now has.

Running the program on the reactive queue

A proactive program that shares its people with the reactive queue has no protected time. When the queue fills, the proactive work stops, and nobody notices until a customer who should have been contacted has already raised a case. Give the proactive work a named capacity, measured in hours each week, and protect it from reassignment. If that capacity cannot be found, the honest decision is to start with a smaller customer set rather than running the program in name only.

How do we know which mistake we are making?

Start with the table above. Each row has a single check that takes an afternoon, and the results usually point clearly to one or two problems rather than all five.

Is it a mistake to send a proactive message that turns out to be unnecessary?

Not on its own. It becomes a mistake when the same unnecessary message goes out again because the rule was never reviewed.

Who should own the customer-facing wording?

The person accountable for the customer relationship, with the operations lead checking that the wording matches what has actually been confirmed. Engineers should not write the final message.

What is the quickest way to stop a noisy rule?

Disable it for the affected customers, record the reason, and schedule a review. Turning it off silently removes the evidence the team needs to fix it properly.

If the program is already running and these patterns look familiar, the rules and the outreach record are the first things to check. For teams replacing an older monitoring setup, the migration considerations page covers migration considerations for the same kind of move, and a guide to operational baselines describes what an operational baseline is meant to support.