A case’s lifecycle looks trivial on a whiteboard: it opens, someone works it, it closes. In production it is where most of the friction in a ServiceNow Customer Service Management implementation accumulates — because the lifecycle is the one part of the platform that both agents and customers touch every single day, and small design mistakes get paid for thousands of times.
This is the second part of a series on CSM practices, following account hierarchy and foundation data. Here: the taxonomy, the escalation path, and the ending.
Case types: fewer than you think
CSM gives you several dimensions to classify a case — case type, category and subcategory, contact type, and the distinct record types like order and return cases. Teams tend to use all of them, enthusiastically, and end up with a taxonomy that agents work around rather than with.
Two questions separate a useful classification field from decoration.
Does it change what happens? A case type that drives a different form, a different queue, a different SLA, or a different set of required fields is doing work. A case type that only exists so someone can filter a report is a tag, and tags belong in a tag field where getting them wrong is cheap.
Can an agent pick it correctly in three seconds, at case creation, without asking anyone? Classification happens at the worst possible moment — the start, when the least is known. If picking between “Issue” and “Problem” requires reading a wiki page, agents will pick whichever is first in the list and your data is now noise dressed as signal.
In practice a healthy model looks like a short type list that genuinely branches the process (question, issue, request, complaint, return), a category tree that is at most two levels deep, and a hard rule that resolution-time classification is separate from intake classification. What a case turned out to be is knowable at the end; what it looked like at the start is knowable at the start. Trying to make one field carry both meanings is why category data is unusable in most instances I have reviewed.
Major cases deserve special mention because they are a genuinely different animal. When one underlying fault generates fifty customer cases, the platform’s major case model — a parent major case with child cases attached — lets you communicate once, resolve once, and cascade. Set this up before you need it. Nobody designs a good major case process during an outage.
Escalation is a commercial signal, not a priority bump
The most common escalation anti-pattern is that “escalate” means “set priority to 1.” The result is an instance where a third of open cases are P1, priority means nothing, and the customers who genuinely need attention are indistinguishable from the customers who complained loudest.
Escalation, done properly, answers a different question than priority. Priority says how bad is this. Escalation says this needs attention beyond the normal path, and here is who owns that. CSM models this with dedicated escalation records rather than a field on the case, and that separation is worth keeping.
A workable escalation design has four properties:
- A reason from a controlled list. “Customer unhappy,” “SLA at risk,” “commercially sensitive,” “needs specialist” are different situations with different responses. Free text here means you can never analyse it.
- A named owner. Not a group — a person, who is accountable for the escalation until it is resolved or withdrawn. An escalation with no owner is a complaint.
- An expiry or review point. Escalations that never end are how you get back to the everything-is-P1 state by a slower route.
- A distinction from reassignment. Moving a case from tier 1 to tier 2 is normal work, not an escalation. If your process makes agents raise an escalation to get specialist help, they will stop asking for specialist help.
The last one matters more than it sounds. Escalation paths that carry a stigma get avoided, and cases sit with the wrong person for days because nobody wants to be the agent who escalated. Make the tier path frictionless and reserve escalation for genuine exceptions, and the escalation count becomes a number a service manager can actually act on.
Closure: resolve, then close
CSM separates resolved from closed and the separation exists for a good reason: resolved means the agent believes they are done, closed means the customer has stopped disagreeing. Collapsing them into one state throws away the only structured signal you have about whether your resolutions actually resolve anything.
The standard pattern is a resolution followed by an auto-close window — the customer has a fixed number of days to come back, and silence closes the case. Getting the window right is a judgement call, not a default: too short and customers find their case closed before they had a chance to test the fix, too long and your open case count is permanently inflated by cases nobody is working. Somewhere between five and ten business days suits most B2B support; consumer support can usually be shorter.
Three habits keep closure honest.
Resolution codes should be a short, mutually exclusive list. “Fixed,” “workaround provided,” “no fault found,” “duplicate,” “customer withdrew,” “out of scope.” When a list grows past about eight options, agents stop choosing and start defaulting.
Resolution notes are written for the customer, not for the ticket. They get read in the portal and in the closure email. An agent who writes “per convo, rb updated, see INC0012345” has closed the case and taught the customer nothing.
Reopens need a policy and a limit. A reopen window that matches the auto-close window is sensible. Unlimited reopens on a case from eight months ago are not — at that point the right move is a new case with a related-record link back, which keeps both the history and the metrics intelligible.
The metric distortion to watch for
Every closure design creates an incentive, and people respond to incentives. If your team is measured on time-to-close, expect cases resolved optimistically and reopened later. If measured on first-contact resolution, expect problems split across multiple cases so each one closes fast. If measured on open case count, expect a Friday afternoon closure sweep.
None of this is dishonesty; it is a rational response to what you chose to count. The mitigation is not more rules — it is measuring the pairs that pull against each other. Time-to-close alongside reopen rate. First-contact resolution alongside cases-per-customer-per-month. Backlog alongside customer satisfaction on closed cases. A team can game one number easily and two opposing numbers almost never.
This is the part of a CSM engagement where the work stops being configuration and becomes service design — deciding what your organisation is actually promising, and what it will measure itself against. It is the kind of question our technology and product advisory work exists for, and it is worth resolving before anyone builds the state model, because routing, SLAs, and escalation all read from these decisions.
Before you build the state model
Answer these first:
- What does an agent do when a case is genuinely blocked on the customer? (There should be a state for it, and it should stop the SLA clock.)
- What happens to a case whose customer never responds, ever?
- Who is allowed to close a case without resolving it, and what does that mean?
- When fifty cases share one root cause, what does the fifty-first agent do?
Each one has a clean answer in the platform’s model and an ugly answer in custom scripting. Choosing the clean answer early is most of what separates a CSM implementation that stays maintainable from one that needs a rebuild in three years.
Next in this series: what happens underneath a case — case tasks, incidents, and the downstream records that do the actual work. If your escalation process currently consists of a priority field and a Slack channel, we can help you fix that.