A case model you can still report on in three years

Almost every service reporting problem we are asked to fix turns out to be a taxonomy problem, and the taxonomy was built in an afternoon.

Somebody configured the org. Case Type and Case Reason arrived as picklists carrying sample values, a decision had to be made before the first user could log anything, and it was made by whoever was in the room with whatever they knew at the time. It was never revisited, because nothing about it ever breaks loudly.

#A case taxonomy fails silently

Every other configuration error announces itself. An assignment rule that misroutes gets escalated within a day. A validation rule that fires wrongly gets a ticket raised the same morning.

A bad picklist value gets selected several hundred times a week by agents who stopped reading it in week two, and the cost appears at the point somebody tries to analyse the result. That is usually two or three years later, in a meeting where a service director asks which products generate the most contacts, or whether the change made in March reduced repeat contacts. The honest answer is that the data cannot say, and by then the data is the only record of those years.

So the taxonomy is a data model decision rather than a picklist. Service Cloud will store whatever values you give it. It will not tell you they are the wrong ones.

#Build it from what the customer said, not from what you want to report

There are two ways to write the list, and they produce different organisations.

The first starts from the report. An executive wants contact volume by product line, so the values become the product lines. Somebody wants workload by team, so the values become the teams. The list is drafted from a slide, in a room with no agents in it, and it maps neatly onto the org chart.

It fails at the point of use, and it fails in a specific way. An agent is on a call, forty seconds in, and the customer has described a problem in their own words. The agent now has to translate that description into a category drawn from an internal structure the customer knows nothing about. Sometimes the translation is obvious. Often it is not, and there is a queue. The agent picks the nearest plausible value, which is a judgement made under time pressure, and the same conversation gets categorised differently by three different people.

The second approach starts from the conversation. Take a few hundred recent cases and read only the first thing the customer said. Not the subject line the agent typed, and not the resolution notes: the opening message, the first line of the call summary, the words the customer chose. Cluster those, and the clusters are your values.

That list looks less tidy on a slide and works far better in a case feed, because every value corresponds to something a customer actually says. An agent recognises it rather than translating into it, and selection accuracy is a function of recognition.

#The General Enquiry problem

Nearly every org we survey has one value absorbing a large share of case volume. It is usually called General Enquiry, Other, or something similarly forgiving.

It is worth being precise about why it wins. It is always true, so selecting it is never wrong. It requires no judgement, which matters when average handle time is on a wallboard behind the agent. And it is the correct choice on the occasions when the real value genuinely is missing, so agents learn to trust it and then reach for it whenever they are merely unsure.

The damage is not confined to the cases it swallows. Once a catch-all holds a large share of volume, the remaining distribution cannot be interpreted, because there is no way of knowing whether the unclassified mass resembles the classified mass or differs from it systematically. The reasonable assumption is that it differs, since the cases hardest to categorise are rarely the routine ones. So a permissive value does not cost you the share of the dataset it holds. It costs you confidence in all of it.

The fix has two parts, and orgs usually do only the first. Remove the comfortable catch-all and replace it with the three or four intents hiding inside it, found by reading the descriptions on cases already filed there. Then keep exactly one escape hatch, make it require a free-text explanation, put its volume on a dashboard somebody owns, and review it monthly. Values that keep appearing in that free text get promoted into the list. Treated that way, the escape hatch stops being a leak and becomes the mechanism by which the taxonomy learns.

#Depth versus breadth: three levels is usually one too many

Type, then reason, then sub-reason feels like rigour. It is where most taxonomies go wrong.

The arithmetic is the first problem. Eight types with eight reasons each and five sub-reasons under those is several hundred terminal combinations. Dependent picklists narrow that, which helps only if the first choice was right, and the third level is chosen last, when the agent has already spent attention on the first two. It is where accuracy collapses.

The second problem is that the third level is almost never used. Watch how service reports get built and they aggregate back to level one or two, because that is the altitude at which the numbers are stable and the audience is asking about categories rather than instances. Detail captured at cost is discarded at analysis.

Two levels is the working shape. A small set of case types, in the range where an agent sees them all at once, and a handful of reasons under each. Keep the combined list to something a person could read aloud in under a minute. Where fine detail is genuinely required for one product or process, put it in a dedicated field on that record type rather than deepening the taxonomy for everybody.

The test to apply to any proposed value is whether a decision changes depending on which value is chosen. If two values lead to the same routing, the same knowledge article, the same process improvement and the same report line, they are one value wearing two names. Salesforce sets out the operational side of this in its own contact centre material, and the design principle holds regardless of platform.

#The reason and the resolution are different facts

A customer contacts you because their card was declined. The case is worked, and the cause turns out to be an address mismatch on the billing record. Two facts, both true, both worth having, and constantly recorded in one field.

When there is one field, the resolution wins, because the agent touches the record last at closure and the closure screen is where the required fields live. The declined card disappears, and what remains is useful to the team fixing address validation and useless to everybody trying to work out what customers contact you about.

Separate the two explicitly.

Contact reason is set when the case is created, describes the customer's stated problem in the customer's language, and should be difficult to change after first save. It answers what generates demand, which is the input to self-service content, product fixes and any deflection strategy. If automated handling is going to sit in front of this, that field is what the design depends on, as we set out in deflection that does not cost you the customer.

Resolution is set at closure, describes what turned out to be true and what was done, and is owned by the person closing the case. It answers what actually fixes things, which is the input to knowledge articles, training and agent guidance.

The cross-tabulation of the two is the most useful report in service and almost nobody has it. Reasons resolving to a single consistent outcome are candidates for automation. Reasons scattering across many resolutions are where diagnosis is happening, and those need knowledge investment rather than a bot. Where a virtual agent sits in front of the case object, that distinction governs what it can safely handle, which we work through in what actually connects to what.

#Who is allowed to add a value

Uncontrolled picklists are how taxonomies die, and the death is gradual enough that nobody files a ticket about it.

The mechanism is ordinary. A team hits a case the list does not cover, and somebody with the right permission adds a value that afternoon, because it is a two-minute change and the alternative is blocking a colleague. It is a reasonable act, repeated by different people over several years, and the result is a list holding Billing, Billing Issue, Billing Query and Invoice Question, all in active use, none documented, and no report able to tell you what billing volume is.

The governance that prevents this is light, and the lightness is the point, because heavy governance gets bypassed.

One named owner. Not a committee. One person who can approve a change in a day, so the two-minute workaround is never the faster path.

An evidence bar for additions. A new value has to be justified by cases that already exist, most easily by pointing at the escape hatch and showing a recurring pattern in its free text. Values proposed from a hypothetical are how the list grows without the data improving.

Deprecation, not deletion. Values leaving the list are made inactive so historical records keep their meaning. Deleting a value or repointing it destroys the only record of what those cases were.

A scheduled review. Quarterly, half an hour, looking at three things: the escape hatch volume, the values used almost never, and any pair of values agents appear to use interchangeably. That review is also where the automation implications surface, which connect to the wider argument in automation agents do not work around.

#The values that need replacing

Most existing taxonomies contain the same handful of failures. This table is the redesign we start from, and it is worth reading against your own picklist before designing anything new.

Every row is the same underlying error in a different costume: a value describing the organisation, the process or the outcome, sitting in a field whose job is to describe the customer.

#Migrating a live taxonomy without losing comparability

Most of this work happens on an org with years of history, and the history is the constraint. The instinct is to tidy the picklist in place, and that is the one thing that must not happen. Renaming a value rewrites the meaning of every historical record carrying it. Repointing records from an old value to a new one destroys the evidence of what was originally selected. Both look like housekeeping, both are irreversible, and the person who notices is whoever owns the service dashboard, several weeks later, unable to explain why last year moved.

The sequence that works is deliberate and slower.

Add the new field rather than editing the old one, and leave the old field in place, read-only, as the record of what was captured. Publish a mapping from old values to new before anything changes, showing which old values map cleanly, which map to more than one candidate, and which cannot honestly map at all. That third list is the important one, and it should be published rather than quietly resolved by picking the closest match.

Backfill only where the mapping is one-to-one. Leave the rest unmapped and visibly so, because an unmapped record is a known gap while a guessed record is a false certainty nobody can later distinguish from a real one.

Then set a cut-over date, tell whoever owns service reporting before rather than after, and require every trend chart crossing that date to mark it. Cross-period trends run on the mapped superset, at whatever coarse level the mapping supports honestly. The new detail is reported on from the cut-over forward, and becomes comparable a year later, which is a real cost and cheaper than the alternative.

#What to settle before you touch the picklist

Six answers, and the configuration follows from them.

What the values are, drawn from reading what customers actually said rather than from a reporting slide. How many levels, with two as the default and a specific argument required for a third. What happens when the right value is absent, meaning one escape hatch with required free text and a named owner watching its volume. Which field holds the contact reason and which holds the resolution, and what stops the second overwriting the first. Who approves a new value, on what evidence, and how quickly. And what the migration path is, where there is history to protect.

That is an afternoon with the right people in the room, which is the same afternoon the original taxonomy took. Salesforce documents the mechanics of customer service software thoroughly, and the platform will implement whatever list you hand it. The list is the part nobody else can decide for you, and it is the difference between a service function that can answer questions about itself and one that has generated data for three years without producing evidence.