Call outcome and lead stage are different things

Here is a bug that survives in most sales stacks for years, because it never throws an error: one field is being asked to describe three different things.

Someone calls a lead. It goes to voicemail. What do you write down?

Three questions that look like one

The honest answer is that there are three separate facts, with three different lifetimes:

• Call outcome. What happened on this attempt. Reached and spoke, no answer, busy, voicemail, callback requested, wrong number, not interested, do not call. It describes ninety seconds and never changes again.
• Lead stage. Where this person stands with you. New, contacted, qualified, won, lost, DND, wrong number. It describes a relationship and changes over months.
• Queue state. Whether they should be called today. It is a consequence of the other two plus the calendar — and it is nobody's job to type.

Collapse those into one "status" dropdown and you get a field that means "no answer" on Tuesday and "qualified" on Thursday, and a pipeline report that can never be reconciled with the call log, because the two are counting different things under the same name.

The symptom you will recognise

Someone asks how many qualified leads you have. Two people run it two ways and get two numbers. The argument that follows is not about the query — it is about whether "no answer" three times means the lead has gone cold. That is a modelling question being litigated as a reporting question.

If two honest people can produce different counts from the same data, you have conflated two fields.

Derived fields must be read-only

The queue is the one people get wrong most often, because making it editable feels helpful. It is not. The moment someone can hand-set "in queue", the queue stops being a fact about your data and becomes an opinion someone had in March.

In Convarza AI the calling list is a definition, not a stored value: every contact assigned to you, whose lead stage is still open, that you have not called today. Open means everything except qualified, won, lost, not interested, DND and wrong number. There is no delayed group, no queue-reason vocabulary, and nothing to maintain — because reaching a closed stage takes someone out of the list automatically.

Every outcome should state its consequence

Once the three are separate, one more thing becomes possible: telling the agent what will happen before they commit.

"Reached — spoke" moves the stage to Contacted. "No answer", "Busy" and "Voicemail" log the call and leave the stage alone, so the contact stays in the list. "Callback requested" creates a task at the time you set. "Wrong number", "Not interested" and "Do not call" move the stage and take the person out of the list.

Write that as one table and let the dropdown labels, the confirmation line and the save behaviour all read from it. Then they cannot drift apart — which is what usually happens when the label says one thing and the code does another.

What to do if you already have the mess

1. Write down every value your status field currently holds and mark each one as outcome, stage, or queue. The mixed ones are your bug.
2. Add the missing field rather than renaming values. Renaming loses history.
3. Backfill stage from the last meaningful outcome, not the most recent one — three voicemails do not change where a lead stands.
4. Make the queue derived and delete the ability to set it.

It is a boring migration. It is also the one that makes every report afterwards agree with itself. See how it works on contacts and lead stages.