adsoraPreserve a stable source lead ID, define each stage and return timestamped outcomes. Separate technical rejection, qualification mismatch and sales follow-up results so every problem reaches the right team.
Give each event one meaning
These are suggested definitions, not a required universal vocabulary. If your team uses issued, sat or demo, document exactly what each means. A report cannot be compared across branches when the same label represents different events.
| Stage | Suggested meaning |
|---|---|
| Accepted | The buyer accepted the delivery under the agreed specification |
| Assigned | The record reached the responsible branch or sales queue |
| Contact attempted | The team made a logged attempt to reach the homeowner |
| Contacted | A two-way conversation occurred |
| Appointment set | A visit or consultation was scheduled |
| Appointment held | The appointment actually took place |
| Sold | A sale was recorded under the buyer’s definition |
| Closed without sale | The opportunity ended with a recorded reason |
Keep the source ID beside your internal record
Store the source lead ID when the lead enters the CRM and preserve the relationship if records are merged or reassigned. The source should not have to match a disputed inquiry by a homeowner’s name in an email thread.
A useful feedback record includes the source ID, buyer record ID, event, timestamp and a controlled reason where applicable. Agree on timezones and whether later updates replace or append to earlier events.
Do not mix delivery rejects with sales outcomes
A malformed payload is a technical issue. An out-of-area lead is a specification issue. A homeowner who does not answer the first call is a contact outcome. Each needs a different response, and combining them under “bad lead” makes the source review less useful.
The credit agreement determines which events qualify for a credit. A CRM disposition should report what happened without silently rewriting commercial terms. Keep a credit-request status separate from the sales status.
Agree how feedback moves between systems
Feedback can use an agreed export, a webhook or a platform feature. LeadConduit, for example, documents feedback as a separate mechanism from the original lead delivery. Choose the method both teams can operate consistently.
Send only the agreed fields and avoid placing homeowner details into URLs or unsecured logs. Define how to handle repeated updates, unknown IDs and a temporary destination failure. Keep an audit trail of the original event and any correction.
Review source performance at the right level
Compare the same stages for the same delivery cohorts. A recently delivered lead has had less time to become an appointment than an older one. Segment by trade and market when those groups have different follow-up processes.
Start each review with specific exceptions: accepted but not assigned, missing IDs, duplicate records or a high share of wrong-service inquiries. The next action should name a rule, a field or an owner, rather than asking the source to “improve quality” without evidence.
Before we get started.
Is a postback the same thing as a ping?
No. A ping is part of a pre-delivery decision. A disposition postback reports a later event, such as an appointment or sale. The receiving system and field specification may differ.
Should a no-answer outcome trigger an automatic credit?
Only if the agreed commercial terms say so. Contact outcomes and credit eligibility should be defined and tracked separately.
Can I begin with a disposition export?
Yes, if both sides agree on the identifiers, fields, cadence and secure transfer method. The important part is a reliable match back to the original lead.
Source documentation
Implementation details can vary by account and change over time. Use your current posting specification alongside these provider documents.