A call center launch checklist for one African market.

The launch is ready only when one test lead can complete every required path

A login, phone number and script do not make an operation ready. Before production traffic starts, the parties need to agree what may enter the queue, what an agent may say and change, what makes an order confirmed, which status returns, who owns the next step and what happens when a system or customer path fails.

The exact language coverage, caller ID, calling window, staffing and legal controls must be confirmed for the project. Do not copy them from another country because both projects happen to use English.

1. Name the project and its owners

Complete this table before writing a script:

Stop if no responsible party can approve the offer, customer-data use and sales rules. A media-buying team without that authority can participate, but it cannot replace the accountable offer owner.

2. Approve the offer pack

The operator should not reconstruct the offer from an ad or an old spreadsheet. Prepare one controlled pack:

• product name, variant and quantity options;
• final price matrix, currency, permitted discounts and delivery charges;
• stock and service-area rules supplied by the downstream owner;
• permitted product and advertising claims;
• statements the agent must not make;
• client-approved store or brand identity used on the call;
• order fields the agent may create or change;
• client-approved quantity upgrades and add-ons;
• customer questions the agent may answer;
• escalation route for a question outside the approved material;
• current script version and approval date.

For nutra and supplements, the client owns product legality, registration and support for every express or implied claim. The agent must not invent benefits, diagnose a condition or provide medical advice. TheCall may refuse, pause or stop work when a material legal, fraud, product or customer-safety risk appears.

3. Confirm the authorized lead path

Document where the customer entered, what they were told and which party is entitled to use and share the data for this call.

Minimum questions:

• Which landing page, store or authorized campaign produced the lead?
• Which client or authorized party collected the data?
• What calling purpose was explained to the customer?
• Which fields are necessary for that purpose?
• How are withdrawal, objection or suppression instructions passed to the calling operation?
• How are test leads, duplicates, wrong-market records and missing or invalid fields handled?
• How long may the lead remain eligible for the agreed contact path?
• Which party answers a customer privacy request or complaint?

An inbound lead is not automatically lawful to call. The client confirms the authority to collect, share and use the record. The project still requires a country-specific review of calling, privacy, notice and recording rules.

Official guidance illustrates why this check is local rather than generic. Kenya's Data Protection (General) Regulations (opens in a new tab) address commercial use of personal data and opt-out handling for direct-marketing phone calls. South Africa's Information Regulator publishes separate POPIA direct-marketing guidance (opens in a new tab). Those examples do not state the rules for the other markets or determine how a specific inbound-lead journey is classified.

4. Define the complete phone sale

Write the required customer decision as fields, not as good lead or approved.

For a confirmed order, decide which of these must be present:

Then define the non-sale paths: callback, no answer, switched off, unavailable, voicemail, call ended before a decision, invalid contact, duplicate, customer says they did not order, outside delivery area and other agreed reasons.

5. Set the attempt and callback rules

Calling schedules are set for each project from the campaign, market and permitted contact path.

Record:

• campaign-agreed calling days and local-time windows;
• priority rule for fresh and overnight leads;
• maximum permitted attempts and spacing;
• what counts as an attempt;
• when no answer remains temporary;
• when the configured attempt path becomes terminally unreachable;
• how a customer-requested callback takes priority;
• what happens when the customer asks not to be contacted again;
• public-holiday and market-specific exceptions;
• the rule for re-entering an authorized previous lead or customer.

TheCall teams operate seven days a week within campaign-agreed calling windows. This does not mean 24/7 calling, and no fixed schedule should appear until the project confirms it.

6. Confirm the in-market team

For a TheCall project, agents are citizens of and physically based in the country whose customers they call. Agents are assigned to the client project rather than a shared queue.

Before campaign launch, confirm:

• current staffing and start capacity for the offer;
• exact language coverage needed by the project;
• caller ID or local number setup, subject to telephony and project rules;
• approved client/store presentation;
• completed product, script and status training;
• project preparation completed under the current internal process;
• team-lead responsibility;
• project-specific review checklist;
• escalation route for product, data, complaint and system issues.

Do not infer an office, every local language or a universal start date from the phrase in-market team.

7. Write the lead and status data contract

Lead intake

Use a stable external lead ID and preserve the campaign fields the client needs for source-level reporting. Name the required fields, formats and validation rule.

Typical field groups:

• lead and campaign identifiers;
• market and offer;
• customer contact fields necessary for the call;
• submitted product, quantity and price;
• source, publisher or subID references where supplied and permitted;
• creation time and original timezone;
• client-supplied authority/notice reference where required;
• deduplication and test-record indicators.

Returned events

Define:

• accepted or excluded intake result;
• attempt outcome;
• reached threshold;
• callback and next action;
• confirmed order;
• order or quantity change;
• accepted upsell/add-on event;
• closed no-order status and reason;
• manual correction;
• downstream event accepted back into the calling review, if supplied.

Use the complete status and reason-code template.

TheCall can configure real-time API exchange for agreed events and fields. That is not a public plug-and-play API or a promise to connect any unnamed system.

8. Test paths beyond the happy demo

Run synthetic records through every connected system. Do not use real customer data for a basic launch test.

An HTTP success response proves only that the endpoint handled the request. The project test must also prove that the correct record, state and next action appear in each system.

9. Put quality control around the approved rules

Quality work starts with a versioned script, outcome definitions and a checklist. It does not start with a percentage labeled QA.

Before production traffic:

• identify the current script and offer-pack version;
• define any critical failure that requires immediate correction;
• define the project review method and the evidence used for correction;
• define how an agent receives feedback and a corrected rule;
• sample positive, negative and callback outcomes rather than checking only confirmed orders;
• check whether the recorded status matches the call evidence;
• log approved changes to price, claims, script, status or attempt rules;
• name the client route for questions and disagreements.

Review methods, evidence and quality commitments remain project-specific and are agreed before launch.

10. Sign the responsibility and handoff matrix

11. Use a binary go-live gate

The launch is not ready if any required answer below is no.

• The contracting and operational roles are named.
• The market and service area are explicit.
• The product and offer may lawfully be sold in the target market.
• The client approved the current claims, prices, script and product rules.
• The client confirmed authority to collect, share and use the lead for the call.
• Language coverage, caller setup and calling window are confirmed for this project.
• The accepted-lead definition and exclusions are written.
• A confirmed order is defined by required fields.
• The attempt, callback, suppression and terminal-unreachable rules are written.
• Required intake and returned status events passed full-path tests.
• The current team completed the project preparation process.
• The review checklist and correction route are ready.
• Fulfillment and courier owners accept the handoff fields and statuses.
• A synthetic record can be reconciled from source to final available downstream event.
• The responsible person can stop or pause the flow when a material risk appears.

This is a readiness gate, not a promise about conversion, delivery or revenue.

Prepare the launch brief without customer data

Send the market, offer, expected daily volume, current systems and launch need or primary phone-sales requirement. Do not attach customer lists or sensitive production records to the website form.

See how the phone-sales service works, compare the five current markets or review the integration boundary.