Almost every contact operation has a mandatory field at wrap-up: the reason. Disposition, category or reason code, depending on the tool. It is the cheapest data point to capture and the most wasted one in the industry. Hardly anyone designs it: it is inherited from the CRM implementation, it grows by accretion every time someone asks for a new category, and one day the report shows that a large share of contacts landed in “Other”. From that point on, any conversation about what to improve has nothing to stand on.
It is worth a close look because it is the only operational data point produced by a person. Handle times, volumes and queues are generated by the system. The disposition is chosen by an agent, in a hurry, at the end of an interaction, from a list someone else built. That condition explains most of its problems and also how they get fixed.
What it is actually for
A disposition catalogue does not exist to fill a report. It exists to answer three specific questions: why people contact us, what happened to each case, and what would have to change outside the service team so that contact stops happening.
The third one is what justifies the effort. Without a clean catalogue you cannot hold any conversation with product, billing or logistics, because there is no way to show the size of the problem. That is the lever developed in reducing contact volume: without reliable dispositions, the lever cannot be pulled.
Signs the catalogue is broken
- One category holds a huge share of volume, and it is usually called “Other”, “General enquiry” or “Information”.
- There are options nobody has used in months still sitting in the list.
- Two categories mean the same thing in different words, and each agent picks a different one.
- Nobody knows who approved the last category that was added.
- The improvement team asks for “the real detail” outside the system, in a separate file.
The last sign is the expensive one: it means the operation has stopped trusting its own data and has built a second, informal system to work from.
Reason and outcome are not the same field
The most common design mistake is mixing why the customer got in touch with how the case ended, all in one list. You end up with catalogues where “Billing issue” sits next to “Resolved on first contact”, which are not alternatives to each other.
Splitting them into two fields costs little and changes everything you can read afterwards. The reason describes the cause and is used to talk to the rest of the company. The outcome describes how it ended and is used to measure the operation. Crossed together, they show something neither gives on its own: which reasons resolve cleanly and which ones always escalate, which is exactly where the work is.
How many levels and how many options
Two levels are usually enough: a broad category and a detail. Three can be defended in large operations with genuinely different processes. Four almost never survive contact with the night shift.
There is no magic number of options, but there is a criterion: the agent has to be able to decide without reading the whole list. If the first level does not fit on one screen without scrolling, the winner will be the first visible option or the last one used. A long catalogue does not produce more precision; it produces more noise with the appearance of detail.
A list the agent cannot read in three seconds does not get filled with judgement: it gets filled with whatever option is closest to the cursor.
Design rules that survive daily use
- Mutually exclusive. If two options can apply to the same case, the data splits in two and neither half is usable.
- Written in the customer's language. “Activation failure” is a category; “Error 4021” is an internal code the agent will translate badly.
- With a definition and an example. Every option needs one sentence saying when to use it and one typical case. Without that, the criterion shifts by agent and by shift.
- Actionable. If a category helps nobody decide anything, drop it.
- With “Other” forced to justify itself. Having it is fine; being able to pick it without typing a line of free text is not.
That mandatory text field behind “Other” is, in practice, the main source of legitimate new categories. When the same theme keeps showing up there over a few weeks, the catalogue needs to grow.
Who is allowed to change it
A catalogue with no owner degrades on its own. The minimum rule is that nobody adds, renames or removes an option without going through a named person, and that every change is dated. Reports that cross a change date without flagging it produce false conclusions: a category that “dropped 30%” has often only been renamed.
A quarterly review is enough for most operations: dead options are retired, the ones holding too much volume are split, and the ones meaning the same thing are merged. Outside that window, changes should be exceptional and justified. Who decides this kind of thing belongs to contract governance, not to whoever builds the report.
How to check it is being used properly
Dispositions get audited like any other quality element: on the same sample of cases already under review, comparing what happened in the interaction against what was recorded. It is one more question on the form, not a separate process. The method is in quality control by audited sampling.
One warning is worth making: disposition accuracy should not go into the agent's incentive pay. The moment you pay for “tagging correctly”, people start tagging what looks correct. It is corrected with feedback and clear definitions, not with money.
It is the raw material for any automation
Before automating a flow you need to know what repeats, and the disposition data is what tells you. A clean catalogue shows which reasons are high volume and low judgement, which are the first candidates, and also which ones should stay with a person. With dirty categories, the exercise starts from assumptions. The criterion for telling them apart is in AI automation in BPO.
The same applies to documentation: the most frequent reasons are the natural index of the knowledge base. If the catalogue and the knowledge base do not resemble each other, one of the two is out of date.
How smartBPO works it
We start with a short catalogue and let it grow on evidence, not the other way round. We separate reason from outcome on day one, because merging them later forces a rebuild of the history. We write a definition and an example for every option, and we put them where the agent sees them at wrap-up, not in a manual. We audit dispositions inside the same quality sample and review the catalogue quarterly with the client, keeping a dated record of every change. And we take the most repeated reasons into the meeting with the teams that cause them, which is where the data stops being a report and starts being useful.