Common ServiceNow Service Level Management Mistakes and How to Avoid Them

This guide covers the service level management mistakes that lead to missed targets or SLAs that people ignore. Each mistake is set out with its symptom, root cause and prevention, from targets set without a baseline to clocks that restart when records are reopened.

Mistake: Unrealistic SLA Targets

Symptom: Your SLAs sound good but are missed so frequently that no one pays attention. SLA targets are acknowledged as unachievable but are not updated. Teams are demoralized because they are measured against impossible standards.

Root cause: SLA targets were set without understanding current performance. Someone decided SLA targets should be aggressive as a motivator, without baseline data to support those targets. Or targets were copied from another organization without adjusting for your actual environment and constraints.

Prevention: Establish a baseline. Before setting targets, measure current performance without formal SLAs over a period long enough to show normal variation. Look at incident resolution times by priority and by category. Look at change approval times. Look at request fulfillment times. Use this data as the basis for setting realistic initial SLA targets. Set targets that are achievable with your current resources, then gradually improve them as your processes mature.

Mistake: SLA Definitions That Do Not Align with Business Reality

Symptom: SLAs are defined but do not match how the business actually works. A business unit works a standard business day, nine to five, but the SLA response clock includes nights and weekends. Holiday periods cause SLA breaches because the system counts those days as working days.

Root cause: SLA definitions were not reviewed with business stakeholders. The technical definition of SLA does not account for how the business actually operates. Business calendars that exclude holidays and non-working hours were not configured properly.

Prevention: Define SLAs in consultation with business leaders and service managers. Understand when your business is working and when it is not. Some organizations work twenty-four hours; others work business hours. Some operations have scheduled downtime; others are always on. Configure your business calendars accurately and use them in SLA definitions. Test SLAs against real incidents to ensure they work as intended.

Mistake: Too Many SLA Conditions and Rules

Symptom: The SLA configuration is so complex that nobody understands it. Teams do not know which SLA applies to their incidents. SLAs are calculated incorrectly or not calculated at all. Support staff spend more time troubleshooting SLA calculations than working on actual incidents.

Root cause: SLA definitions grew over time as new conditions were added. Different business units wanted different SLAs and conditions were added to account for each one. No one cleaned up old or unused conditions.

Prevention: Start simple. Define SLAs on one or two criteria: priority and service category. Use a matrix that shows the response and resolution times for each combination. Test thoroughly to ensure the SLAs work correctly. Only add complexity when simple SLAs are not sufficient. Regularly review SLA definitions and remove conditions that are not being used or that cause confusion.

Mistake: Measuring SLAs Without Acting on Results

Symptom: Your dashboard shows that SLAs are being missed regularly, but nothing changes. The same targets are missed month after month. There is no analysis of why and no action to improve.

Root cause: SLAs are measured for reporting but not used for management. No one investigates why targets are missed. No one holds teams accountable or provides support to help them meet targets. SLAs become a compliance checkbox rather than a management tool.

Prevention: Use SLMs to drive improvement. When an SLA is missed, investigate why. Was it because of insufficient staffing, a particularly complex incident, or a systematic problem? Track patterns: if a particular category of incidents always misses SLA, that is a sign that the target is wrong or that the process needs improvement. Use SLA data to make resource decisions and process improvements.

Mistake: Stopping the Clock Incorrectly

Symptom: Your SLA calculations show zero elapsed time for incidents even though they took days to resolve. Staff report that they are not working on incidents but the clock keeps running, inflating response time metrics.

Root cause: Stop-clock logic is not configured correctly. The system does not pause the SLA clock when waiting for customer feedback, vendor response, or external work. Or the clock stops but is not restarted correctly.

Prevention: Define clearly when the SLA clock should run. Usually, the clock runs when the incident is active and being worked. It stops when the incident is waiting for external action: customer feedback, vendor response, or availability of resources. Configure stop-clock conditions in your SLA definition. Test with real incidents to ensure the clock behavior is correct.

Mistake: SLAs Without Support Process Changes

Symptom: New SLAs are announced but the support process does not change. Staff continue working as they did before. The new SLAs are not met because the process cannot support the targets.

Root cause: SLAs were defined without planning how the support team will work differently to meet them. Setting targets without changing the underlying process has no effect.

Prevention: When you implement new SLAs, plan the process changes that will support them. Do you need to increase staffing? Improve prioritization? Automate routine work? These changes must happen together with the SLA rollout. Train teams on the new process. Provide tools and resources to help them meet the targets. SLAs are aspirational unless you change the process to support them.

Reporting averages that hide the requests that breach

An average response time can look healthy while a meaningful share of the most important records wait far longer than the target. A team that answers most requests in good time and a few after a week will show a respectable average, and the few late ones are usually the executive escalations and the outages that customers remember. Report the proportion of records that met each target, broken down by priority, and keep a list of the breached records that someone must read each month. A single average figure should never stand in for compliance on its own.

Reopened records that restart the clock

When a resolved record is reopened, many configurations start a new target from the moment of reopening and discard the time already consumed. The customer experiences one continuous delay, while the report shows two short, compliant episodes. The fault is usually in the definition, not in the team’s effort. Decide, before go-live, whether a reopened record continues its original clock or starts a new one, and write the decision next to the target so that it is applied the same way every time.

Reassignment that resets the target

A similar problem appears when a record moves between groups. If the target is attached to the assignment rather than to the record, every hand-off looks like a fresh start, and a request that has waited three days in one queue appears to be new when it lands in another. The symptom is a cluster of records that breach only after a transfer. Check whether the target is tied to the original raise time, and decide whether a transfer should be counted as a delay the receiving team inherits or one that the previous team owns.

Priority set by the person raising the record

Some breaches start with a priority that does not reflect impact. When the requester chooses a high priority to get attention, the record gets a demanding target that no team can realistically meet, and the true emergencies are diluted among the inflated ones. The safeguard is a priority that is calculated from impact and urgency, with the requester’s view recorded as information rather than as the value that drives the clock. Review the share of high-priority records each month. A rising share with no change in business activity is a sign that the calculation is being gamed or misunderstood.

Changing the definition in the middle of a reporting year

The pattern to avoid is a change that improves the figure on the dashboard without improving the service. Any definition change should be visible in the report it affects, with a note explaining what moved and why.

A monthly data check for these mistakes

1. Compare the share of breached records with the share of breached records in the previous month, and list any record that breached on its first pass but was reopened.
2. Sample ten records that were reassigned and confirm that each target reflects the agreed rule for transfers.
3. Count the records at each priority and compare the share of high priority with the business activity for the same period.
4. List every exclusion applied in the month, with its approver and the reason, and remove any that lack either.
5. Check the change log for definition changes and confirm that each one has a note in the report it affected.

Is it a problem if the target is breached only at month end?

It can be. Month-end breaches often come from a batch of records raised near the end of the period and assigned without the attention they need, or from reporting that cuts the period before records have had their full window. Check the raise and close dates before deciding the team has a problem.

Should breached records be removed from the report to make it readable?

No. They should be summarized, but the summary must show how many were breached and why. Removing them makes the trend look better while leaving the customer’s experience exactly where it was.

Who should review the monthly data check?

The service owner should review the outcome, and someone outside the team that produces the figures should spot-check the sample. Where the same person builds the report and checks it, errors that suit the team’s interests can survive.

How do we know our metric definitions are consistent across teams?

Keep a written dictionary that says what each measure counts, when the clock starts and stops, and who owns it. For a worked structure, see the article on a service metric dictionary.

Several of these problems are easier to prevent when automation is designed with them in mind. The automation opportunities guide covers where timers and escalations can be automated safely, and the metrics guide helps choose the measures to report alongside them.