On this page8 sections+
- 01One approval number cannot explain the backend
- 02Preserve the identifiers that make feedback usable
- 03Define the events before comparing rates
- 04What a usable source-to-status record looks like
- 05Corrections and reconciliation need a path
- 06Confirm who can authorize the project
- 07Build the brief around the data disagreement
- 08Frequently asked questions
One approval number cannot explain the backend
A low approval rate can reflect different conditions: the customer could not be reached, the number was invalid, the customer did not recognize the order, the offer did not match the expectation, the address fell outside the permitted delivery area, or the call ended in a clear decline.
Those are not interchangeable outcomes. A network needs event definitions and reasons before it can have a useful conversation about traffic quality or call handling.
Preserve the identifiers that make feedback usable
The configured intake can retain the project lead ID and relevant dimensions such as offer, publisher, traffic source or subID. The return path can attach the call status, reason, order change and permitted downstream event to the same identifier.
Only fields required for the project should move between systems. The exact data contract, access, correction path and retention belong in technical discovery and the project agreement.
Define the events before comparing rates
Accepted lead
A record admitted to the calling queue after the contract-defined technical and eligibility exclusions. The rule should say how duplicates, tests, wrong-market records and missing or invalid fields are treated.
Reached lead
A unique lead meeting the project’s qualifying human-connection threshold. Voicemail, a third-party answer, a silent call and a very brief answer need explicit treatment. Repeated attempts must not become repeated reached leads.
Confirmed order
A customer who has agreed the project-required product, quantity, price, address and
other required details. If a tracker calls this event approved, the mapping should
be written down.
Delivered and paid order
An order reported by the responsible downstream source as both delivered and paid.
COD teams may call this buyout. It is not a call-center event, even when later
feedback is used to review the confirmed-order cohort.
What a usable source-to-status record looks like
Sample network return
| Project lead ID | Source context | Lifecycle status | Reason or outcome | Returned change |
|---|---|---|---|---|
LD-EXAMPLE-201 |
offer_A / pub_17 / sub_4 |
confirmed |
customer_confirmed_details |
Quantity 1 → 2 |
LD-EXAMPLE-202 |
offer_A / pub_17 / sub_9 |
closed_no_order |
customer_says_did_not_order |
none |
LD-EXAMPLE-203 |
offer_A / pub_22 / sub_3 |
excluded |
invalid_contact_data |
none |
LD-EXAMPLE-204 |
offer_A / pub_22 / sub_3 |
callback_due |
callback_requested |
callback window |
This table demonstrates a possible mapping. It is not a client report or universal production taxonomy.
Corrections and reconciliation need a path
A customer decision may change, an order can be corrected, or a downstream status may arrive later. The project should define:
- which event source is authoritative;
- which statuses are provisional or final;
- who may correct a record and why;
- how the correction is transmitted;
- which time window closes a commercial event;
- how disputes are reconciled without changing the original source context.
A performance-linked fee or network postback is only as clear as those definitions.
Confirm who can authorize the project
TheCall needs an authorized route to the offer, customer data, script and backend operation. A network that controls or is authorized by the advertiser can be the project counterparty. A pure publisher without that authority is more likely to refer the advertiser or backend owner.
TheCall does not operate as an affiliate network, offer marketplace, traffic source or media buyer.
Build the brief around the data disagreement
Tell us which markets and offers are involved, who authorizes the lead use, which
identifiers must survive the call operation, how accepted, reached, approved
and delivered and paid are currently defined, and where the existing data becomes
unclear.
Frequently asked questions
Can you return postback events?
Project-defined events and fields can move through a configured real-time API. The exact postback or integration path is confirmed during technical discovery; TheCall does not offer a universal public connector.
Can we pass publisher and subID data?
Those fields can be included when they are required and approved in the project data contract. Data should be limited to what the operation needs.
What is your definition of approval rate?
There is no universal definition. A possible project definition is contract-defined confirmed orders divided by the stated accepted-lead cohort. The event, denominator, exclusions, window and correction rules must be explicit.
Can affiliates send leads directly?
Only through an authorized offer and customer-data flow. The client must be entitled to collect, share and use the lead for the agreed call. TheCall does not accept cold, bought or scraped lists.
Can you guarantee that one source will approve better than another?
No. Source comparison requires a sufficiently defined cohort and still does not prove sole causation. Traffic, contactability, the offer, call handling and downstream delivery can all affect the observed result.
Do you hide declined or unreachable reasons?
The project is designed to return agreed statuses and reasons. The exact taxonomy, correction process and access are configured with the contracting client.
Next step
Describe the launch or operating need.
Share who owns the offer, where the customers are, approximate daily volume and what the phone-sales operation needs to produce.