When I see a lead marked Contacted, I do not treat the label as the end of the review. I treat it as a question: what customer-facing event supports that label? A person may have sent an email, left a voicemail, connected by phone, or simply checked a task after preparing a draft. Those states need different next steps.
I start with the last verified event. I look for the original source, the date, the owner, and any note that describes what the customer actually said or requested. Then I compare that with the current next action. If the next action is still “follow up,” I ask what fact is supposed to change and when the owner should check it.
The distinction between internal work and customer contact is the part I protect most carefully. Assigning a task is internal work. Writing a draft is internal work. Summarizing a form is internal work. None of those proves that a customer received or answered a message. When the event cannot be verified, I keep the row on Hold or Missing Context instead of polishing the wording.
I also look for the stop condition. Is the request outside the service area? Is this a possible duplicate? Did the customer ask not to be contacted? Is the phone number unclear? A record can be old and still be inappropriate for another message. Do Not Contact and Duplicate are useful outcomes, not failures of the cleanup.
For a first-person lead cleanup workflow, I prefer a small redacted sample. Ten to 25 rows are enough to expose whether the status, owner, source event, next action, and permission signal tell the same story. I remove passwords, payment data, full transcripts, recordings, and unrelated customer history. If the sample cannot be redacted safely, I stop before using it.
The Missed Lead Recovery review can sort that sample into Ready, Hold, Duplicate, Do Not Contact, and Missing Context. I use it as an evidence organizer, not as a decision-maker. It does not send messages, change a CRM, or infer permission. The owner checks the record and decides what may happen next.
The habit is simple: before I trust a status, I look for the event; before I approve a next action, I look for the owner; before I allow another message, I look for the stop reason. That sequence does not guarantee a customer response. It makes the work explainable to the next person, which is the part a clean-looking pipeline often fails to provide.
I also write down what I did not verify. If the source event is only an internal note, I say that. If a call log has no connected-call outcome, I leave the outcome unknown. That small admission helps the next reviewer avoid treating an incomplete timeline as a fact. It keeps the review useful even when the right answer is to pause, ask the owner, or request a safer source record.