OBLYTECH Logo
Enquire Now
OBLYTECH Logo

ServiceNow customer service practice

ServiceNow customer service case routing with clear ownership

ServiceNow customer service case routing should move a customer question to the group that can make the next useful decision. OBLYTECH helps organisations design that path without making the customer repeat the same explanation at every stage.

Discuss ServiceNow customer-service case routing

Start with the customer question and intake channel

Capture what the customer is asking, the service or product involved, the contact channel, urgency and information already supplied. Intake should collect what the first decision-maker needs without turning the form into an obstacle. Preserve the question and its context as the case moves.

Classify the case before assigning ownership

Use categories that help determine capability, service, entitlement, priority or next action. Classification should be understandable to the people entering the case and useful to the people receiving it. If a category does not change routing or decision-making, its value should be questioned.

Route by capability, service and priority

Define the assignment rule and the exception path. A case may need a specialist, service owner, regional group, supplier or priority response. Record why the route was selected and what happens when the destination cannot accept the work. Avoid routing only by a broad queue when a more precise service relationship is available.

Make handoffs and escalation visible

Every handoff should carry the customer question, evidence, work completed, decision needed, new owner, timing expectation and communication responsibility. Escalation should be based on consequence, ageing, blocked work or a defined service condition rather than frustration alone.

Confirm resolution before closure

Closure should state what was done, what the customer received, what evidence confirms the outcome and whether further work remains. If the customer cannot confirm directly, record the verification method and the boundary of confidence. A closed case should not conceal an unresolved problem or follow-up action.

The ServiceNow employee workflows and HRSD page illustrates the same ownership and information-boundary discipline in employee service. For platform governance, see ServiceNow security, risk and governance. When routing rules need a controlled test, review ServiceNow risk assessment and control testing.

Discuss ServiceNow customer-service case routing

Bring one intake channel, assignment rule or handoff that creates repeated explanations, unclear ownership or uncertain closure. OBLYTECH can help map the case question, service context, capability, priority and evidence boundary.

Start the conversation

The routing decision that most often goes wrong

Customer service routing usually fails at the first assignment, not later. A case is placed in a broad group because the category is unclear, the group accepts it without knowing whether it can resolve it, and it bounces to a second group after two days. The customer experiences that as delay, the agents experience it as rework, and the reporting shows nothing useful because every bounce looks like an ordinary transfer. Improving the first assignment is therefore the one of the more valuable changes a customer service team can make to its routing.

This page is for customer service operations leads and platform owners who are deciding how cases should be assigned in ServiceNow. It assumes that some categories already exist and that the team is judging whether they support good decisions. It is not a guide to the intake form itself, but to the logic that turns a case into the right owner.

Choosing a routing basis that matches the decision

Routing can be based on several things: the product or service, the customer’s entitlement, the issue type, the channel, the region, the language, the urgency or the capability that resolves the question. Each basis works well in some situations and fails in others. A product-based route is precise when products have separate support teams, and misleading when one customer question spans two products. A capability-based route suits specialist work but needs the capability to be recorded accurately at intake.

Routing basisWorks well whenBreaks down whenUseful companion rule
Product or serviceEach product has an owning team with its own knowledgeA question spans two products or a bundleAllow a secondary service reference that does not change the first owner
EntitlementService levels or access depend on the customer’s agreementEntitlement data is stale or split across systemsCheck entitlement at assignment and record the check result
Issue typeIssue categories map to distinct resolutionsCategories describe symptoms, not outcomesRetire any category that does not change who acts
CapabilitySpecialist skills are scarce and recorded against people or groupsCapability records are out of dateReview capability records when staffing changes
Region or languageService obligations or contact requirements depend on locationCustomers are routed by a home address that is no longer currentConfirm the contact preference before assigning

A useful test for any basis is to ask what changes for the person who receives the case. If the answer is nothing, the basis is collecting data without improving the decision, and it should be removed or moved to reporting.

Designing the first assignment as a decision, not a default

A default assignment sends every case of a type to the same group, and it is simple to build. It is also the reason cases bounce. A decision-based assignment asks what the first owner must be able to do with the case, then routes to the group that can do it. When that group cannot accept the case, the rule should say where it goes next, and the record should explain why the first route was chosen so the reassignment is visible rather than hidden.

Good first assignment rules also distinguish between a case that needs a decision and a case that needs work. A decision case should go to someone with authority. A work case should go to someone with capacity and the right skill. Mixing the two produces an authority holder doing data entry and a skilled agent waiting for approval.

Reassignment as the signal to watch

Reassignment is the cleanest measure of routing health. Each reassignment is a case where the first decision was wrong, the first owner lacked information, or a dependency was not identified. Counting reassignments by type, origin and destination shows which rules need to change. A single high-volume route that bounces to one specific team usually means the rule sends the wrong work there, and the fix belongs in the rule, not in the agents’ training.

Reopened cases are the second signal. A case that closes and reopens within a short period often closed before the customer could confirm the outcome. The routing review should look at whether the closing owner had the information to verify the result, and whether the case should have stayed with a different owner until confirmation.

  • Count reassignments by the rule that sent the case and the group that returned it.
  • Track the time between assignment and first meaningful action, not only the time to closure.
  • Review reopened cases for missing verification steps rather than for agent error alone.

Regional, language and entitlement routing in practice

Region, language and entitlement are often treated as simple filters. In practice they interact. A French-speaking customer in one region may have an entitlement that is served by a team in another. A case about a regional contract may need the commercial owner rather than the local queue. The routing design has to decide which of these rules takes precedence, and the answer should be written down before the rules are built.

A practical approach is to order the rules explicitly: entitlement and legal obligations first, then the capability that resolves the issue, then language and region as a tie-breaker. The order should be visible to the people who manage the queues, so an unexpected route can be explained without reverse engineering the rule set.

When a case should skip the normal queue

Some cases should leave the normal route at once. The contact center case escalation page covers giving agents a clear next step when a case needs another team, a decision or a different level of attention. A service condition may affect many customers, a commitment may be due within the hour, or a customer may have a risk condition that the service owner has defined. These cases need a defined priority path, not a general instruction to agents to use their judgement.

Priority routes are safe only when they are narrow. If every case is marked urgent, the urgent route stops meaning anything, and the people on it burn out. A short list of priority conditions, each with a named owner, keeps the route meaningful.

Keeping the customer’s question intact across assignments

Each assignment is an opportunity to lose information. The customer’s own words, the evidence they provided and the steps already tried can be dropped if the case record only carries a category and a short description. The handoff should keep the original question visible, the work completed so far, the decision now needed and the communication owner who will speak to the customer. The receiving owner should not need to reconstruct the case from the agent’s notes.

This matters for consistency. A customer who has explained a problem three times and is asked to explain it again will assume the process is broken, whether or not it is. Keeping the question intact is one of the few routing improvements that customers notice directly.

Common questions about customer service case routing

Should routing be automated or handled by a person?

Automate the decisions that are repeatable and well defined, such as entitlement checks and clear category routes. Keep a person in the loop where the first decision needs judgement, such as a case that crosses product lines. Automation that cannot be explained to the team that runs it will be overridden quickly, so the rules should be simple enough to read.

How many categories should a customer service catalog use?

Use only the categories that change who acts or what decision is made. A category that exists only for reporting belongs in reporting. Review categories against reassignment data, and retire any category that never changes a routing decision.

What happens when a case touches two services?

Record one owner for the customer outcome and a secondary service reference for the other service. The owner coordinates, asks the other team for the decision they need and keeps the customer informed. Splitting the case into two unrelated tickets is often what creates the duplicate explanations customers dislike most.

Does the employee workflow route work the same way?

The logic is similar. The employee workflows and HRSD page describes making employee requests easier to complete while giving the service team enough context to act, and the same questions about the first owner and the handoff apply to customer cases.

If a customer case is bouncing between groups, or customers are repeating their explanation at each stage, bring one intake channel and its last assignments as the starting example. Discuss your case routing with OBLYTECH.

How to improve case routing in ServiceNow: a four-step sequence

To improve customer case routing, find where cases are being reassigned, fix the single rule behind the most bounces, then choose the ServiceNow mechanism that fits that decision. Changing the platform feature before understanding the bounce usually moves the problem somewhere else.

  1. Sample the reassigned cases. Take a recent set of cases that changed owner at least once and label each with one cause: unclear category, missing information at intake, wrong capability, or entitlement not checked. Fifty cases read carefully teach more than a dashboard of thousands.
  2. Fix the largest cause first. Change one rule, write down what it was before, and leave everything else alone for a full cycle. Changing five rules at once makes the result impossible to read.
  3. Choose the mechanism that matches the decision. The table below sets out the usual fit.
  4. Measure again. Compare the reassignment rate and the time to first meaningful action with the sample you started from.
MechanismFits whenWatch for
Assignment rules and data lookup rulesThe answer is the same every time, such as product, region or entitlementRule count grows, so the order of evaluation needs to be written down
Skill and capacity based assignment (Advanced Work Assignment, usually for queue-based work)Specialist skills are scarce and agents work from queuesSkill records go stale when staffing changes
Predictive classificationMany past cases were categorised consistentlyPoor historical categories teach the model the same mistakes

Whichever mechanism you pick, record the reason for the route on the case so a reassignment can be explained rather than guessed at. The case management guide explains how customer cases are structured, and the service level and experience management page covers the response targets routing has to support. Teams that route by product alone should also read the customer service management hub to see how product, entitlement and contact data relate.

Testing a Routing Change Against Past Cases Before It Goes Live

Test a routing change against closed cases before it goes live. Pull the cases from the period where bounces happened, run each one through the proposed rule, and count how many would have reached the group that finally resolved them. A rule that matches the resolving team for most of the sample is ready to try. A rule that sends a large share of cases to a group that handed them on is not, however sensible its logic looks on paper.

The check needs no new data. A typical case record already holds the category, the assignment history and the closing group. For each case, ask two questions: would the proposed rule have picked the group that resolved it, and would that group have had the information to act? The second question matters. A rule can pick the right team and still fail if the case arrives with only a category and a one-line description, because the receiving agent will bounce it for more detail.

Each tested case falls into one of three groups, and each group needs a different fix:

  • Routed to the team that resolved it: keep the rule as written.
  • Routed to a team that handed it on: the basis is wrong or too broad, so narrow it or change the basis.
  • Not placed by the rule at all: these usually trace back to a field missing at intake, so fix intake before adding rules.

Run the test on the whole rule set, not on one rule at a time. Rules that depend on each other, such as an entitlement check that runs before a capability route, can look correct alone and still produce bounces together. Record the result beside the rule, with the sample it was tested on, so the team that owns the queue can see why the rule was accepted. A later review can then be measured against that record, not against what people remember.

Intake quality limits what any test can show, so check the data design before tuning rules. The workflow data and context design guide covers which fields the first owner needs to decide. If the cases come from customers rather than staff, the ServiceNow case management for customers guide sets out the customer-facing side. For the reassignment counts themselves, the ServiceNow reporting and dashboards guide is the place to build them.

ServiceNow guides on this topic

Guides from the Oblytech ServiceNow library that explain the practice behind this page.

More in this section