Return the status and the reason behind it.

Why one status field fails

Affiliate platforms commonly use commercial conversion states such as pending, approved and declined. Those values are useful for attribution and payout logic, but they do not tell an operator:

• whether the number rang;
• whether the intended customer was reached;
• whether another attempt is due;
• whether the customer denied submitting the order;
• whether an order was confirmed and then changed;
• whether fulfillment or a courier later reported a different event.

Keep the operating truth first. Map it to each receiving platform second.

1. Separate four layers

An attempt outcome is not automatically the current lead status. No answer at 10:00 can be followed by customer reached at 15:00. Preserve both events and derive the current state.

Order updated and upsell accepted are events attached to the order. They should not replace the lead's confirmed status.

2. Use a small lifecycle vocabulary

The exact labels may change by project. Their meanings must not.

Do not use approved as the internal definition unless the project explicitly maps it to confirmed and records the definition version.

3. Keep attempt outcomes observable

These events describe a specific call, not a final judgment about the lead:

Define the qualifying human-connection threshold. A silent connection, a one-word third-party answer or voicemail must not become three different interpretations of reached across reports.

4. Use one primary reason for a terminal state

Intake exclusion reasons

Closed no-order reasons

Customer says they did not order is an observation, not automatic proof of publisher fraud. Outside delivery area describes the current downstream coverage, not call quality.

Closed unreachable reasons

The attempt-plan version is part of the evidence. A lead called once and a lead called under the complete agreed plan must not share the same terminal reason without that context.

5. Keep downstream events in a separate namespace

When the client or responsible downstream system supplies them, events may include:

TheCall may receive those events to review later outcomes or perform an agreed customer call. It does not create, own or guarantee physical delivery or payment.

6. Preserve source context without putting customer data in an affiliate report

Keep stable non-customer identifiers:

• external lead ID;
• internal lead ID;
• offer ID;
• market;
• source ID;
• publisher/affiliate ID where applicable;
• subID or equivalent campaign slot;
• order ID after creation;
• event ID;
• definition/schema version.

Platform names vary. The Awin glossary (opens in a new tab) uses advertiser, publisher, transaction and server-to-server tracking language. Everflow's identifier guidance (opens in a new tab) distinguishes click/transaction and conversion event identifiers, while its postback documentation (opens in a new tab) shows source/sub parameters in platform-specific mappings. Affise's postback documentation (opens in a new tab) requires its own click identifier and supports commercial statuses such as approved, pending, declined and hold. Map the project's fields to the platform actually in use; do not assume sub1 means the same business dimension in every system.

Affiliate reporting normally does not need the customer's name, phone, address, call audio or free-text health information. Use pseudonymous IDs and a controlled evidence route for a permitted dispute review.

7. Working CSV event template

This template is intentionally an event ledger, not a single mutable lead row.

event_id,lead_id,external_lead_id,order_id,offer_id,market,source_id,publisher_id,sub_id,event_type,lifecycle_status,attempt_outcome,reason_code,order_revision,occurred_at,recorded_at,source_system,schema_version,correction_of_event_id,detail_code

Field rules

Synthetic status-exchange example

event_id,lead_id,external_lead_id,order_id,offer_id,market,source_id,publisher_id,sub_id,event_type,lifecycle_status,attempt_outcome,reason_code,order_revision,occurred_at,recorded_at,source_system,schema_version,correction_of_event_id,detail_code
evt_demo_001,lead_demo_001,ext_demo_001,,offer_demo,NG,paid_social,pub_demo,creative_a,lead_accepted,accepted,,,0,2026-07-31T08:00:00Z,2026-07-31T08:00:01Z,calling_crm,1.0,,
evt_demo_002,lead_demo_001,ext_demo_001,,offer_demo,NG,paid_social,pub_demo,creative_a,call_attempted,calling,no_answer,,0,2026-07-31T08:04:00Z,2026-07-31T08:04:02Z,dialer,1.0,,
evt_demo_003,lead_demo_001,ext_demo_001,,offer_demo,NG,paid_social,pub_demo,creative_a,call_attempted,calling,customer_reached,,0,2026-07-31T11:20:00Z,2026-07-31T11:20:02Z,dialer,1.0,,
evt_demo_004,lead_demo_001,ext_demo_001,,offer_demo,NG,paid_social,pub_demo,creative_a,callback_requested,callback_due,,,0,2026-07-31T11:20:03Z,2026-07-31T11:20:04Z,calling_crm,1.0,,callback_same_day
evt_demo_005,lead_demo_001,ext_demo_001,order_demo_001,offer_demo,NG,paid_social,pub_demo,creative_a,order_confirmed,confirmed,,,1,2026-07-31T15:10:00Z,2026-07-31T15:10:04Z,calling_crm,1.0,,

Synthetic IDs and values are used only to demonstrate the schema. They are not client records, TheCall performance data or a universal production taxonomy.

8. Map operations to a network without losing detail

Write a mapping table for the actual network:

Do not send repeated attempts as repeated conversions. Do not reuse an event ID after changing its meaning. A retried webhook must be idempotent: the receiver recognizes the same event rather than creating a second commercial action.

9. Govern corrections and finalization

Before the first report or invoice, agree:

1. which system owns each event;
2. which timestamp creates the reporting cohort;
3. how long interim states remain open;
4. the downstream maturity window;
5. the challenge/correction window;
6. which evidence each role may inspect;
7. who may correct an event;
8. whether a correction reverses, replaces or supplements the commercial event;
9. when the period becomes final;
10. how later courier or payment updates are shown.

Never delete a disputed event and insert a cleaner row. Append a correction with a new event ID, actor/source, time, reason and correction_of_event_id.

10. Build the report from counts and denominators

For each market, offer, source/publisher and subID slice, show:

• accepted leads;
• reached leads under the stated threshold;
• confirmed orders;
• closed no-order records by primary reason;
• closed unreachable records by terminal reason;
• excluded records by intake reason;
• provisional and mature downstream counts where supplied;
• correction count;
• definition/schema version.

Then calculate only named rates:

Contact rate = reached leads ÷ accepted leads
Confirmation rate = confirmed orders ÷ accepted leads
Contact-to-confirm rate = confirmed orders ÷ reached leads
Reason share = records with one reason ÷ records in that reason's parent state

Customer says they did not order should be divided by the relevant reached, no-order cohort, rather than automatically by all submitted leads. No answer attempt counts should not be compared with unique lead counts as if they were the same unit.

Read the complete denominator guide.

11. Use codes to choose the next review