Define qualified outcomes before counting campaign successcampaign success

Keep transport status separate from business state

Twilio distinguishes a call resource status from its status-callback event. In that system, a completed resource means an answered call ended normally; a completed progress event can accompany other terminal outcomes. Neither establishes that the intended person was reached or that the business task succeeded.

Keep provider status unchanged in its own field. Add reviewed business outcomes separately. Check the documentation of the carrier or platform actually used; do not translate all provider event names into success.

Build an outcome dictionary with evidence

• Attempted: one identified call attempt exists. Preserve the contact and attempt identifiers so retries do not inflate unique people reached.
• Reached intended person: the conversation supports that classification under your verification process. An email match or answered number alone may be insufficient.
• Valid enquiry: the required fields are present and accurate enough for the receiving team. Unknown fields remain explicitly unknown.
• Qualified for this workflow: the enquiry meets criteria agreed by the business owner, such as supported service area and a requested next step. This is not a credit, employment or medical eligibility decision.
• Handoff accepted: the destination record exists and the responsible team has accepted the work under its process.
• Paid customer: the account has a verified qualifying payment under the finance definition. A positive call outcome or demo request is insufficient.

Create a record a reviewer can trace

For each business state, store the definition version, relevant evidence reference, reviewer decision and decision time in your authorised reporting system. Use a stable account or contact reference rather than copying personal details into a public worksheet.

Keep call-level outcomes and contact-level progression in separate views. One person may have three attempts, one useful conversation and one accepted callback. The report should show that relationship instead of calling it three leads.

1. 1Write the required fields and allowed unknowns for the task.
2. 2Choose the record that confirms each next step and name its owner.
3. 3Record pass, fail or unverified for the evidence check.
4. 4Deduplicate contacts and accounts before reporting lead or customer totals.
5. 5Preserve later corrections with their reason instead of silently rewriting past results.

Worked example: report the denominator

Illustrative example: 100 attempts cover 80 distinct contacts. Review establishes 30 useful conversations, 18 enquiries meeting the agreed qualification rules and 12 accepted handoffs. Report these as separate counts. The attempt-based qualified rate is 18/100 only if those 18 are distinct qualifying attempt outcomes; a contact-based rate needs 18 distinct contacts before using 18/80.

If payment records are unavailable, paid accounts and revenue are unknown. Do not multiply the 18 enquiries by an assumed conversion rate and present the result as acquired customers. These numbers are a hypothetical reporting example.

Resolve disputes using the record

When the BPO and client disagree, identify which field or criterion caused the disagreement. “Interested” may mean willingness to hear an offer to one reviewer and a requested appointment to another. Replace the label with an observable condition, then re-evaluate the affected calls.

Use the same definition version for both sides of a comparison. If qualification rules change during the pilot, show the change date and avoid presenting unlike cohorts as an improvement.

A little more before you begin.