How to Build a Call Disposition List You Can Trust

A rep hangs up, clicks one item in a dropdown, and moves to the next number. That click is the whole record of what just happened. It decides when the number gets dialed again, whether it ever gets dialed again, and what your Monday report says about the week. Most outbound teams have never audited that dropdown, and most of them are running a call disposition list that quietly lies to them.

What is a call disposition, and why is outbound different?

A call disposition is the short label attached to a call the second it ends. Answered. No answer. Voicemail. Bad number. Callback booked. One field, one value, on every call your team makes.

Inbound support teams use dispositions to explain why the customer called. Billing question, cancellation, complaint. The data feeds staffing and process fixes, and a well known contact centre industry guide lays out that version well.

Outbound sales asks the same field to do a second job. Here the call disposition is a label and an instruction at once. "No answer" means try again in four hours. "Bad number" means stop and fix the record. "Do not call" means stop forever and write it down. Your dialer reads that instruction and acts on it with nobody in the middle.

So a lazy click does more damage in outbound than a messy report. It hands the wrong order to a machine that will dial thousands of numbers this week. That is the difference worth holding on to: an inbound call disposition explains history, and an outbound one writes the future.

What breaks when the call disposition list is wrong?

More things read this field than most managers realize. In a typical outbound setup, the call disposition drives:

• The retry rule. How soon, how many times, at what hour of the day.
• Suppression. Which numbers stop being dialed, permanently, and why.
• Campaign completion. When a list is finished instead of half worked.
• Your connect rate and every talk time number above it.
• Coaching. Which calls a manager pulls up and listens to on Friday.

Two coding errors cost real money, and both are common.

Collapsing "not interested" into "do not call"

These are different events with different consequences. A brush off on a Tuesday is a lead you can work again next quarter. A do-not-call request is a promise you made, and the caller has a right to expect you to keep it. Teams that offer one code for both outcomes either burn good leads or park a real request in a bucket nobody suppresses. Federal telemarketing rules require an internal do-not-call list of your own, separate from the national registry, and the code your rep clicks is how a name gets on it. Treat that as a data design question first and ask your own compliance people about the rest, because this is general education and not legal advice.

Hand coding what the dialer already knows

Plenty of teams let reps pick "left voicemail" by hand while the dialer is also labeling calls with its own answering machine detection. Now you have two sources for one fact and no way to tell them apart later. When you go to check whether detection is actually working, your evidence is a mix of machine judgments and human clicks, including test calls a rep coded as voicemail after listening to their own greeting. One bad row does not sound like much until you look at how few labeled examples you have.

How many call disposition codes should a sales team have?

Ten or fewer. That ceiling shows up again and again in contact centre practice, and the reason is behavioral rather than technical.

Reps are choosing under time pressure, between calls, while a dialer waits. Every extra option is another half second of reading and another chance to guess. A call disposition list that takes real thought to use will be used badly, no matter how well designed it looks in a spreadsheet.

Long lists get gamed. Reps default to whatever sits at the top, or to the one code they always pick, especially when they feel watched on call volume. Alphabetize a twenty item list and watch an odd share of your calls land on something starting with A.

Ten is not a hard law. It is a budget. Every code you add has to earn its place by changing what happens next. If two codes produce the same retry rule, the same suppression, and the same follow up, they are one code wearing two names.

Make the click mandatory once the list is short. If coding is optional, your reps will skip it on the busiest afternoons, which is exactly when the data matters most. Short list plus a keyboard shortcut turns a call disposition into one keystroke that nobody resents.

Which outcomes should the dialer set, and which should the rep?

Split the list by who actually knows the answer.

The machine knows the mechanical result. Ring with no pickup, busy signal, invalid or disconnected number, carrier rejection, answering machine, a call dropped before an agent arrived. A dialer should write those itself, every time, with no rep involvement. Human hands on machine facts is where your data goes soft.

The rep knows only what a person said. Interested. Not now, call me in the spring. Wrong person, the buyer left the company. Booked. Asked to be removed. That is a short list, and it should be, because those are the only outcomes a human is the authority on.

This split also protects the numbers you have to report. Abandon rate is calculated from calls where a person answered and no rep arrived, so if reps can hand code that state, your abandon rate reporting becomes an opinion poll. Same for voicemail. If you use voicemail drops, the system knows exactly when it dropped one and your rep does not need to confirm it.

How do you catch dispositions that are being coded wrong?

You do not need a project for this. Three checks catch most of it.

Check duration against outcome. A call coded "no answer" that lasted two minutes did not happen. Sort by disposition, look at the length distribution inside each one, and the impossible combinations jump out. Industry practitioners use exactly this as a sense check, and it works on day one with no new tooling.

Check the shape of the distribution. Pull the share of calls in each code by rep, for the same campaign and the same week. Reps working the same list should look roughly alike. The one whose calls are sixty percent "not interested" while the team runs at twenty is either getting different data or clicking to get past the screen.

Read the free text. Notes should be free text. Outcomes never should. But give reps somewhere to type when nothing fits, then read that box once a month. Repeated phrases are your list telling you what it is missing.

To run any of these you need a call disposition report that carries more than a count. At minimum it should show the rep, the campaign, the code, the timestamp, and the call length, with a link to the recording where one exists. A count by code tells you what people clicked. Those extra columns tell you whether the click was true.

What a short outbound call disposition list looks like

Here is a starting point. Every entry answers one question: when do we dial this number again?

1. No answer. Set by the system. Retry on the campaign cadence.
2. Busy. Set by the system. Retry sooner than a no answer.
3. Answering machine. Set by the system. Retry per cadence, drop a message if the campaign allows one.
4. Bad number. Invalid, disconnected, or rejected by the carrier. Stop dialing, flag the record for data cleanup.
5. Wrong person. Right number, wrong human. Stop, route to research.
6. Not interested. Live refusal. Long cooldown, then eligible again.
7. Callback scheduled. A date exists. Dial at that date and not before.
8. Qualified. Moves to the next stage of your pipeline and out of the dialing list.
9. Do not call. Permanent suppression across every campaign you run, plus your internal do-not-call list.

Nine codes. If your team needs a tenth, take one out first. Notice that every call disposition here ends in an action a system can carry out on its own, which is the test any candidate code has to pass.

How do you change the list without losing your history?

Never rename a code in place. Renaming rewrites the past, and last quarter's report silently becomes something you cannot reproduce.

Retire and add instead. Turn off the old code so nobody can pick it, leave the historical records pointing at it, and publish a mapping of old to new for anyone reading the archive. If you must merge two codes, do it in the report rather than the data.

Then leave it alone. Quarterly review is plenty. A list that changes every few weeks trains reps to stop reading the options, which is the behavior you were trying to fix.

One last thing worth checking. If your dialer, your CRM, and your reporting each keep their own idea of what happened on a call, you will spend your Mondays reconciling three versions of the same week. Running them on one record is part of why we built SellifyGPT the way we did, at one published price rather than a stack of tools that each hold a piece of the truth.