ServiceNow Case Management for Customers Best Practices

Good Case Management for Customers starts with clear case types, then builds SLAs, routing and escalation on them. Case types should follow customer intent rather than internal teams, and SLAs should match what the team can realistically meet. Routing should match each case to an agent with the right skill, and escalation should run on defined criteria.

Establish Clear Case Types Before Going Live

Case types shape everything downstream: routing rules, SLAs, knowledge associations and reporting. Without clear types, cases scatter across the system with inconsistent handling. A case type defines what the case represents, who can create it, what information is mandatory, and what the resolution path looks like.

Good practice is to define case types by customer intent, not by internal team. “Billing question”, “Password reset”, “Feature request” are customer-facing types. Each type carries a default SLA, escalation policy and knowledge association. When a customer creates a case of a known type, the system knows immediately how to treat it. When types are vague (“miscellaneous problem”), no two cases are handled the same way.

Start with 5 to 10 types covering real volume. Resist the urge to create a type for every scenario; oversegmentation defeats the purpose. Review types after launch and consolidate rare cases into broader categories. Changing types retrospectively is difficult, so get this right at the start.

Design SLAs Around Customer Expectations, Not Workload

SLAs set the commitment to customers: response time, resolution time, and consequences of breach. An SLA of one hour response time means agents must acknowledge the case within one hour, every time. Breaches are visible to customers and affect satisfaction.

Common mistake: setting SLAs too tight because leadership wants quick turnaround. Overly aggressive SLAs that are routinely missed demoralise teams and disappoint customers. The better approach is honest SLAs based on realistic staffing and the type of work. A complex technical issue may need longer; a password reset should be quick. Different case types get different SLAs.

SLAs must account for time zones and business hours. If support is Monday–Friday 9–5, the SLA clock should run only during those hours. Round-the-clock support requires 24/7 staffing and different SLAs. Do not promise 24/7 response if the team works office hours.

Use Routing to Distribute Work Based on Real Skill

Routing is the assignment engine. When a case arrives, routing rules decide who works it. Poor routing creates bottlenecks: high-skill agents are overloaded while junior staff are underused, or cases go to whoever is available regardless of fit.

Good practice is to tag agents with skills, availability and language capability. Then write routing rules that match case requirements to agent capability. For example, a billing case routes to billing agents; a technical issue routes to engineers. If no one with the needed skill is available, the case waits or escalates to a supervisor. This is far better than random assignment.

Avoid routing rules that are too complex. The system should decide in seconds, not minutes. Keep rules to fewer than 10 conditions; prioritise by skill, then by workload. Test routing with realistic case volumes before going live. Poor routing becomes visible very quickly and erodes trust in the system.

Escalate Systematically Before Customers Complain

Escalation moves cases to someone with more authority or skill when the current agent cannot resolve. Escalation should be automatic for high-risk situations: SLA at risk, customer is dissatisfied, issue is complex. Manual escalation (“I will pass this to my manager”) creates delays and lost context.

Define escalation triggers in configuration: if resolution has not happened before a point you set within the SLA time, escalate automatically to a supervisor. If a customer indicates frustration in a comment, escalate. These rules run constantly and take emotion out of the decision.

Ensure that escalation paths are real: the supervisor exists, has the authority and skill, and can see the case queue. Escalating to a role that does not exist on your team wastes time. Test escalation with live cases before declaring it working.

Keep Knowledge Aligned With Case Reality

A knowledge base that does not match the system or cases creates confusion. Articles describe how cases are supposed to be handled; if reality differs, agents ignore the articles. Misalignment happens when processes change but knowledge is not updated.

Good practice is to designate a knowledge owner who reviews case trends monthly. If many cases are being resolved with a workaround that is not in the knowledge base, that is a signal to write an article or update the process. If cases are failing because an article is wrong, fix it immediately. Knowledge should be the single source of truth, not a historical record of how things used to work.

Link case types to knowledge topics. When a billing case arrives, relevant billing articles should appear in search. This reduces the search burden on agents and ensures consistency.

Measure Resolution, Not Just Response

It is easy to hit a response SLA: reply to a case quickly. It is much harder to resolve cases quickly. Reporting should track both response and resolution time, but weight resolution time more heavily in performance reviews. An agent who responds quickly but resolves slowly is not truly serving customers.

A good metric is first-contact resolution: cases resolved in one interaction. For simple cases, this should be high. For complex cases, multiple touches may be needed. Tracking this by case type shows where the process is working and where it is not. If billing cases resolve on the first interaction far more often than technical cases, that points to where process improvement is needed.

Communicate Status Changes Automatically

Customers dislike silence. If a case changes status or is reassigned, the customer should know immediately, not after asking. Automatic notifications reduce repeat contact and show respect for the customer’s time.

Configure case status changes to send notifications: when a case is resolved, the customer is notified with an option to reopen if needed. When it is reassigned, a note explains why. Keep the message brief and clear. Excessive notifications train customers to ignore them, so balance transparency with restraint.

Retiring and merging case types without losing history

Once a case type has been in use for a while, the question changes from how to create it to how to retire it. A redundant type still holds closed cases that reports depend on, and deleting or hiding it can break the trend lines the business relies on. To merge two types, move new work into the surviving type, keep the old type read-only for reporting, and record the mapping between old and new labels so that comparisons over time still mean something.

Checking SLA clocks against the business calendar

An SLA clock that ignores holidays, regional working hours or the pauses for customer replies will report breaches that did not happen, or hide ones that did. Before go-live, take a handful of real cases that breached and a handful that met their target, and recalculate each clock by hand against the calendar the team actually works. Any mismatch points to a missing schedule, a wrong time zone or a pause condition that was never configured. Fix those before the first monthly report, because a corrected report is harder to explain than a late one. The service level management guide describes how these clocks are defined.

A weekly backlog review that keeps the queue honest

A queue is only as accurate as the habit of looking at it. A short weekly review, led by the supervisor and limited to cases older than the team’s own threshold, finds cases with no owner, cases waiting on a customer who has not replied, and cases that belong to a different type. Keep the review to exceptions. Walking through every open case turns it into a status meeting that nobody wants to attend.

Using the reopen rate as a quality signal

Reopened cases say more about the quality of a resolution than the time taken to close. Track the reopen rate by case type and by agent group, but read it against the case mix, because a group that handles harder cases will reopen more often. A sustained rise in one type can point to a missing step in the resolution, a knowledge article that describes the wrong fix, or a customer message that was never answered. Review a few reopened cases from the same type before deciding what to change. The case closure quality article sets out what a sound closure looks like.

Closure codes that stay useful for reporting

Closure codes are easy data to corrupt. When agents choose from a long list in a hurry, the same outcome can end up under several labels, and reports split one trend into fragments. Keep the list short, make each code mean one outcome, and remove any code nobody has used for a long time. Require a free-text note only when the code is an outcome the business will need to explain later.

Questions supervisors ask about the operating model

Should agents work from one queue or from skill-based queues?

Many teams use skill-based queues for specialist work and one general queue for everything else. The general queue catches cases the rules do not recognize, and its volume is the signal that the rules need attention.

How should a case be handed over between shifts?

The outgoing agent writes the customer’s current request, what has been tried, and what the customer was promised. The incoming agent confirms ownership in the record rather than in a chat message.

Who approves a change to a case type or an SLA?

The service owner approves, after the supervisor has shown the effect on open cases. Changing an SLA without that check moves the breach line for work already in progress.

What should a new supervisor read first?

The case type definitions, the SLA schedule and the routing rules, in that order. Those three documents explain much of what the queue will do.

Next step

An audit of queue ownership, SLA calendars and closure codes is a short piece of work for many teams, and it often finds the cause of a reporting dispute.