Disposition codes: 'no answer', 'not now' and 'not a buyer' differ
In short
A lead disposition code records what happens next, not what happened. It works when every value maps to exactly one next action and one accountable owner, which is why 8 well-chosen codes beat a 20-item status list: free text cannot be branched on, and values nobody acts on get applied at random.
Key takeaways
- A disposition answers "what happens next", not "what happened". Notes record the second; the code drives the first.
- Every code needs one next action and one named owner, or automation has nothing to branch on.
- 8 codes a store acts on beat 20 that exist for reporting. Unused values get applied inconsistently.
- "No answer" is an attempt outcome, not a disposition — the lead is still working until a rule says otherwise.
- Retire codes with a mapping from old to new, as a parts catalogue handles supersession, or history becomes unreadable.
A disposition code is the controlled value a salesperson or BDC agent sets on a lead to say what should happen next. It is not a summary of the conversation — the note field is for that. The test is mechanical: read any value in isolation and you should be able to name the next action and the person responsible, without opening the record.
Most stores fail that in one of two directions. Either the outcome lives in free text, so nothing downstream can branch on it, or the list has grown to 20 values mixing outcomes, reasons, reporting buckets and a manager's pet category.
What happens next, not what happened
"Left voicemail" describes an attempt. So does "no answer". Neither is a disposition, because neither changes what the system should do — the lead is still being worked and the cadence continues. Recording attempts as statuses is why CRM reports show hundreds of leads in a state that triggers nothing.
A disposition changes the branch: it moves the lead into a different loop, hands it to a different owner, or ends the sequence. If a value does none of those three, it is a note.
The minimum set an automated follow-up can branch on
| Code | What it asserts | The one next action | Owner |
|---|---|---|---|
| working | Attempted, no reply yet, still in sequence | Continue the cadence unchanged | Assigned responder |
| engaged | Two-way conversation is live | Schedule the next dated touch | Assigned responder |
| appointment_set | A date and time exist for a visit | Run the confirmation sequence | BDC or appointment owner |
| appointment_missed | The confirmed visit did not happen | Re-engage same day, then re-book or downgrade | BDC |
| revisit_dated | Real interest, wrong timing, date stated | Sleep the lead, wake it on that date | Nurture owner |
| not_qualified | Cannot proceed: finance, geography, no stock | Close with the reason; alert the manager if stock-driven | Manager |
| lost | Bought elsewhere or withdrew | Close and add to the monthly loss review | Manager |
| stop_contact | Contact must cease | Terminate all sequences immediately | Whoever owns consent |
Two rows carry most of the value. revisit_dated is useless without the date, so make the date mandatory when the code is chosen — a timing objection with no date is indistinguishable from a polite refusal. not_qualified needs its reason in a separate structured field, because "no suitable stock" is a merchandising signal and "finance declined" is not.
Why 8 codes beat 20
Every extra value splits the same volume into smaller buckets, and a bucket with no rule attached gets applied by intuition. Once two salespeople disagree about which code fits, the field stops being data. 20 statuses do not give a more detailed picture; they give the same picture with more noise and a longer dropdown people resolve by picking the first plausible option.
- Reporting statuses nobody acts on. A code added so a report shows a category, with no rule attached, gets under-applied by people working leads and over-interpreted by whoever reads it.
- Private meanings for shared codes. One salesperson uses "working" for anything they mean to call again, another for anything not yet closed. Same value, different populations.
- Codes that encode a reason. Reasons belong in their own field. Mixed into the status they multiply the list: 3 outcomes and 4 reasons become 12 values meaning the same 4 things.
- Codes that duplicate lead source. Where an enquiry came from is a separate taxonomy and never belongs in the disposition.
Retiring a code without breaking history
Deleting a value orphans every record that used it; renaming one silently rewrites the past. Retire codes the way the parts side handles a replaced number: mark the old value inactive, record what it maps to, keep the chain readable — the discipline in what a supersession chain is. Reports then roll old records into new categories defensibly, and nobody has to remember what a code meant in 2024.
Two adjacent things stay out of the disposition field. Floor traffic has its own outcomes, recorded against the visit rather than the lead — the reason an up log loses information when digitised. And a lead that never arrived has no disposition at all, so a store must separate an unworked lead from an undelivered one: the marketplace says it sent 40 leads and the CRM has 31.
If you cannot write the automation rule for a status in one sentence, that status is not ready to exist.
A disposition set is the smallest piece of schema deciding whether the rest of lead response and follow-up can be automated at all. Rebuilding one, with its routing rules and reason fields, is typical internal tools and operations work inside the systems we build for dealerships.
Frequently asked questions
Short answers to the follow-ups this page tends to raise.
Is "no answer" a disposition?
No — it is the outcome of one attempt, and the lead stays in whatever state it was already in. Log attempts separately with channel, timestamp and result, and let the cadence decide when a run of failures changes the disposition. Mixing attempt outcomes into the status field is why CRM reports show large populations that trigger nothing.
How many disposition codes should a dealership have?
Around 8 active values for a sales pipeline, with reasons stored separately. The count matters less than the rule: every code has exactly one next action and one owner, written down. If two codes share an action and owner, merge them; if one code needs two actions depending on circumstances, it hides a missing field.
Who should be allowed to change a disposition?
Whoever is doing the work, with terminal states restricted. Closing a lead as lost or not qualified should require the assigned person or a manager; stop_contact should be settable by anyone who hears it and reversible by nobody without an explicit process. Open states can change freely — a mistake there costs one extra follow-up.
Can an AI agent set dispositions automatically?
It can set the unambiguous ones and should escalate the rest. A reply containing a specific date is a reliable revisit_dated; an explicit request to stop is a reliable stop_contact. Anything needing a judgement about intent — whether "I'll think about it" is a timing objection or a refusal — goes to a person with the evidence attached.
- disposition codes
- CRM taxonomy
- follow-up
- sales process
The work behind this page
Builds from our portfolio that this page draws on.
Read next
- The ADF lead: every field a CRM receives, and the three that decide routingADF is the XML format most third-party enquiries arrive in. The spec is old and loosely honoured, so a parser has to treat almost every element as optional — except three.definition
- Lead source codes: why 3 systems give 3 answers on where a lead came fromSource in the CRM, in analytics and on the vendor invoice answer 3 different questions. Nominate one as the operational answer and stop reconciling the other two.definition
- The marketplace says it sent 40 leads and your CRM has 31A vendor's lead count and your CRM's lead count disagree for four different reasons, and from inside the CRM all four look identical. Here is the reconciliation that tells them apart.diagnostic
- What an up log is, and why the software version never matches the floorThe up log is a dealership's floor-traffic record, not a CRM record — and because the person who fills it in has usually just lost the sale, the number it produces is a floor, not a total.definition
Related across the site
Working on something in this space?
Tell us where you are in a sentence or two. We'll tell you honestly whether we're the right team, and what a sensible first slice of the work looks like.
Start the conversation