A Bad Number Returns to the Call Queue: Repair the Record Before Another Attempt

When a confirmed incorrect number returns to a call queue, hold the affected number–person association and trace how it re-entered. Inspect the original call evidence, the current contact record, the refreshed list, and any enrichment or sync that changed the value. Correct the source and verify the resulting queue before another attempt.

A saved outcome is evidence of an action at one point in the workflow. It does not prove that every upstream source, duplicate record, later import, and calling surface now carries the same correction. The repair procedure below is a proposed method for inspecting your own records, not a promise of universal automatic suppression.

What exactly was established as wrong?

Start with the number actually dialed and the person the rep intended to reach. Record the observed reason the association was rejected. A number that belongs to someone else, an incorrect company route, and an unanswered attempt are different findings. Preserve that distinction rather than reducing every unsuccessful call to bad data.

Keep the evidence attached to the specific number and person. A contact can have several phone values, and an account can have shared routes used by many people. Do not invalidate unrelated numbers or label the account uninterested when the evidence concerns only one association.

Review direct dial, mobile, and switchboard distinctions when the route is unclear. A shared company number may be valid for the organization while being incorrectly presented as a personal line. That requires an accurate association and description, not an invented claim that the person rejected the offer.

What does the documented Bad number outcome change?

The current Unify call dispositions guide says Bad number marks the dialed number invalid after a call made in Unify. Logging an external call with that disposition does not change the number's validity. Do not call is separate: it opts the person out of future calls.

Determine which path produced the original activity. Was it an actual Unify call, an externally logged call, or a note imported from another system? Keep the saved outcome alongside the observed validity state. If the state did not change, investigate the documented behavior before assuming the correction failed.

Do not use a person-level stop request as a substitute for a number correction, or a number correction as a substitute for an actual stop request. Preserve each fact at the scope it concerns. Where the caller explicitly asked for no further calls, the outreach boundary remains relevant even if another phone value becomes available.

The Making calls workflow also lets a rep select among available numbers. Confirm which value the attempt used before editing the current primary field. The number now shown first may not be the one that generated the evidence.

Where should you trace the returning value?

Build a short chronology from the original attempt to the queue entry now under review. Use record IDs, source names, and timestamps rather than names alone. Keep the original stored value as evidence and compare normalized values when identifying the same number across formatting changes. Formatting is a matching aid, not proof of ownership.

Inspect the contact's current phone attributes and the related activity. The record inspection documentation describes viewing attribute values, record IDs, and last-updated timestamps. A record-level update time does not by itself identify which phone field changed or prove that its ownership was verified.

Then inspect the list or task that produced the queue entry. Establish whether the queue contains a newly imported person, an existing person with changed data, or an older task that still points to the same record. These are investigation branches, not diagnoses you can assign without inspecting the actual history.

If the chronology is incomplete, record what you cannot inspect. A missing audit event does not prove there was no write. Ask the data owner to resolve the gap before declaring an enrichment provider or integration responsible.

Could the list refresh have restored the number?

Compare the refresh input with the current record and the earlier correction. Look for a stale phone column, a different person identifier, a duplicate contact, or a mapping that writes the old value into an active field. Check what the import was configured to update instead of assuming it only changed list membership.

Unify's import documentation explains that CSV matching uses company domains and person emails, and that mapped values can update an existing record. Review the actual file and mapping when testing whether a refresh restored the phone value.

A change in the person's email or a duplicate source record may require identity review. Do not merge records solely because their names or phone numbers match. Keep verified identity, account association, and phone evidence separate until the responsible operator establishes the correct record.

When preparing a clean input, use calling-list readiness checks for the broader review. Preserve the rejected association in your correction history so that removing a field does not also remove the reason it should stay out of the queue.

Could enrichment have supplied the same value again?

Inspect where enrichment was requested and what information identified the person. Compare the returned number with the rejected value, then inspect the current validity and eligibility states. A newly returned value is not automatically new evidence that the same person now owns it.

The power dialer documentation describes optional enrichment for missing numbers when preparing a session. The task settings guide describes another path: enabled phone lookup when a call task becomes ready and the person has no numbers or all are invalid. An existing unverified number can prevent that lookup. Check the route actually used.

These documented entry points explain where to investigate; they do not establish that enrichment caused this particular recurrence. Preserve the lookup result and its available source context before assigning a cause.

Use the contact discovery and enrichment use case to frame a reviewed search for the right person. Treat returned contact data as evidence to assess against the correction history. The existence of a fresh response should not erase a confirmed contradiction without a reason that the reviewer can explain.

Which record should remain outside the queue?

Hold the affected calling candidate while its identity or number association is unresolved. Define the hold at the level supported by your tools and evidence: the rejected number–person pair, the ambiguous contact, or a broader scope when a genuine stop request requires it. Make the reason visible to whoever prepares the next session.

Review both existing tasks and new list-based sessions. A corrected source field does not prove that every already-created task or queued selection now points to the intended state. Inspect the pending work and the current record together before releasing the hold.

Assign the repair to the person who can change the relevant source and mapping. The team call-task guide covers ownership of work; here the assignment should specifically identify the data defect, affected record, and evidence needed to close it. Completing a generic call task is not evidence that the source was repaired.

Coordinate overlapping queues and systems through your established controls. Duplicate-outreach prevention addresses that broader coordination problem. Use the mechanisms verified in your environment rather than assuming that a local change automatically propagates everywhere.

How should the correction be recorded?

Retain a compact correction record with a stable reference to the person, the dialed value, the evidence, and the affected source. Record the proposed correction and the observed result separately. An intended write and a successful persisted write are different states.

Choose the source of truth for the affected field before making changes. If another system regularly overwrites it, correcting only the destination may be temporary. Review the responsible mapping or source process with its owner, without changing unrelated fields to force the record out of a list.

If the call is shared with the CRM, inspect call sync rules and the sync log. A synced call activity can carry outcome context, but it is not proof that the phone field or queue eligibility changed. Verify those states separately at their actual destinations.

How do you verify that the repair persists?

Use a reviewed, permitted record to test the path that actually reintroduced the number. This is a proposed acceptance procedure, not a report of a completed test. Preserve the before state, apply the authorized correction, and inspect the resulting source and destination records before any calling action.

Run the relevant refresh or review its next normal execution under controlled conditions. Check whether the rejected value reappears, whether its invalid state remains associated with the intended number, and whether a duplicate person was created. Keep live dialing outside the test; inspecting a queue does not require another call to the rejected destination.

Verify the queue used by the rep, not only the data-management screen. Inspect which number is selected and whether the record's hold or restriction is effective on that path. The calling-session workflow is the final context to review before resuming the affected work.

The repair passes this proposed check only when the relevant data state and queue decision match the documented correction across the inspected path. If the result is blocked, incomplete, or inconsistent, keep the case unresolved and preserve the evidence for the responsible administrator or support team.

Close the case with a concise explanation of what changed and what was checked. Keep the original call evidence, using the factual-note approach in cold call follow-up records. Future operators should be able to distinguish a new legitimate number from an old rejected association returning under a fresh timestamp.

Frequently asked questions

Why can a bad number appear again after a list refresh?

A refresh may write mapped values, reference a duplicate person, or introduce data from another source. These are possible paths to inspect, not conclusions. Trace the actual input, record identity, and queue entry to establish what happened.

Should I remove every number from the contact?

No. Limit the correction to the number and association supported by the evidence. Review other values independently, and preserve any separate person-level stop request without confusing it with a phone-data correction.

Does a new enrichment timestamp prove the number is correct?

No. A recent response or record update does not establish current ownership of that number. Compare the returned value with the correction history and inspect the evidence supporting its association with the person.

Is a synced call outcome enough to close the repair?

No. Verify the relevant phone value, validity state, source process, and actual queue eligibility. Activity history and current contact data answer different questions, even when both are visible in the CRM.

When can the affected candidate return to the queue?

After the responsible reviewer resolves the identity and number evidence, confirms the applicable outreach boundaries, and verifies the resulting queue state. If those checks remain incomplete, retain the hold and its reason.