On this page7 sections+
- 01Before dispatch: establish what the customer agreed
- 02During delivery: act on an event the operation can supply
- 03White-label calls use the approved brand identity
- 04Responsibility and data map
- 05Map each call event to the delivery workflow
- 06A service your merchants can understand
- 07Map the real event flow
Before dispatch: establish what the customer agreed
When an order or lead reaches the approved calling queue, an agent can contact the customer under the client-approved store identity and confirm the product, quantity, price, address and other required details.
The call can also include permitted quantity changes, upsells or cross-sells when the merchant has approved the options. The returned record tells the fulfillment operation whether the customer confirmed, declined, requested a callback or could not be reached under the agreed attempt logic.
During delivery: act on an event the operation can supply
A fulfillment partner or courier may need a customer response after an unsuccessful attempt, address question or availability issue. TheCall can call on that defined trigger, present the permitted options and return the customer response.
The downstream operator must still decide and perform the next physical action. A calling team cannot guarantee a reattempt, route, delivery window, successful handover or cash collection.
White-label calls use the approved brand identity
Agents can call under the store or brand identity approved for the project. The opening, script, customer promise and escalation path are agreed before work begins.
White-label calling does not make TheCall the merchant, fulfillment provider or courier. The project agreement and customer-facing process must preserve the appropriate legal and operational responsibilities.
Responsibility and data map
Responsibility map
Responsibility template:
| Moment | Data owner | TheCall action | Returned event | Next owner |
|---|---|---|---|---|
| New order before dispatch | Merchant or fulfillment partner | Run approved confirmation call | Confirmed, declined, callback or unreachable with reason | Fulfillment partner applies dispatch rule |
| Address exception | Fulfillment or courier source | Clarify permitted address detail | Corrected detail or unresolved reason | Downstream source validates and acts |
| Failed delivery event | Courier or fulfillment source | Ask about availability or approved reattempt option | Customer response and requested option | Courier or fulfillment partner decides the next attempt |
| Later outcome | Downstream source | No physical action by TheCall | Delivered-and-paid or other agreed feedback can return for review | Project owners analyze the cohort |
The table illustrates one possible division of responsibility. Actual event names, fields and permitted calls are configured per project.
Map each call event to the delivery workflow
A stable project lead or order ID connects the call to the downstream record. The technical design establishes:
- which order or event enters the queue;
- the minimum customer and order fields required;
- which statuses and reasons TheCall may return;
- which order fields an agent may change;
- how corrections are handled;
- which system owns dispatch and delivery truth;
- who acts when a customer requests a callback or reattempt.
Agreed events can move through a configured real-time API. Custom work is subject to technical discovery; TheCall does not promise universal WMS, courier or store connectors.
A service your merchants can understand
The partner can explain the boundary in one sentence:
The calling team confirms the customer decision and returns the agreed order or delivery response; the fulfillment and courier operation manages the parcel.
This avoids selling a false all-in-one promise. It also gives each party a precise place to investigate when a record, call outcome or physical delivery event is wrong.
Map the real event flow
Send the markets, merchant profile, current order source, pre-dispatch rules, delivery-exception statuses, customer options and systems involved. TheCall can then assess where a separate calling function adds a useful decision rather than another handoff.
Agents remain dedicated to one client project rather than a shared queue. A multi-merchant partner therefore needs a project structure that keeps training, identity, product rules and reporting unambiguous; staffing and commercial fit are assessed from the brief.
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.