Twenty thousand voter-outreach calls produce little operational value if connected, failed, and early-ended calls cannot be separated reliably. Before anyone reports reach, engagement, or cost, the system needs a defensible record of what happened to every call.
In 1999, NASA’s Mars Climate Orbiter was expected to reappear from behind Mars and establish contact. It did not. At the Jet Propulsion Laboratory in Pasadena, the team had telemetry and calculations from a spacecraft that had traveled for months, but the mission’s most important outcome was suddenly uncertain.
The investigation, chaired by Arthur Stephenson, found that one engineering team had supplied impulse data in English units while another processed it as metric. NASA’s Mars Climate Orbiter Mishap Investigation Board Phase I Report documented how that mismatch contributed to the spacecraft entering the atmosphere at a dangerously low altitude. The orbiter was lost.
The lesson was larger than unit conversion. A system can process a large amount of technically valid activity while carrying a hidden disagreement about what the records mean.
Call volume cannot substitute for call truth
Now return to the outreach supervisor opening a dashboard the morning after 20,000 calls.
The top-line number looks impressive. Underneath it are harder questions. Which calls reached a person? Which reached voicemail? Which failed before connection? Which callers heard the disclosure? Which conversations ended after a few seconds? Which people opted out? Which calls were billed despite producing no usable interaction?
If the system records all of those outcomes as a broad “completed” state, the dashboard cannot answer them. A completed telephony event may mean the provider finished processing the call. It does not necessarily mean a voter answered, understood the agent, or completed the intended conversation.
This distinction affects more than reporting. Campaign staff may contact the same person again because an early-ended call appears successful. A finance operator may accept a cost report built from attempts rather than connected minutes. A compliance reviewer may see a finished call without evidence of consent, disclosure, or opt-out handling.
The data exists, but its meaning has drifted.
Define the lifecycle before launching the list
A reliable calling operation needs an explicit lifecycle shared by the telephony provider, assistant runtime, billing system, and dashboard.
At minimum, each call should retain its provider identifier, timestamps, connection state, final disposition, duration, billing status, consent record, opt-out state, and relevant webhook history. Those events should be preserved well enough to reconstruct the call later.
That reconstruction matters when systems disagree. A provider may report that a call ended normally while the assistant runtime shows that no meaningful exchange occurred. A webhook may arrive late, twice, or out of order. The dashboard should resolve those conditions through documented rules instead of treating the latest event as unquestioned truth.
Asenda Talk has a telephony lifecycle webhook pipeline with call-truth tracking, metered per-minute billing, consent and opt-out records, and an audit trail for every call. These controls are part of the platform being built and evaluated in early access. They still require testing against the selected live provider’s event model.
That provider decision has not yet been made live for outbound calling. The gate matters because each provider can describe ringing, connection, voicemail, failure, and termination differently. Launching before those mappings are tested would turn the first large campaign into an expensive classification exercise. The related question is examined directly in Can a Twi-English Voter Agent Launch Before Its Outbound Provider Is Approved?.
Test the disagreement cases
A pilot should test more than successful conversations. The useful cases are the awkward ones:
- The recipient answers and hangs up during the first message.
- The call reaches voicemail.
- The provider connects, but the assistant runtime never starts.
- The same webhook arrives more than once.
- A termination event arrives before an earlier lifecycle event.
- The recipient opts out in Twi or English.
- The call begins near a billing threshold and ends before a meaningful exchange.
For each case, the team should agree in advance on the dashboard status, billing treatment, retry policy, and audit evidence. Then the observed record can be compared with the expected one.
Spend controls belong in the same exercise. A real-money gate placed before billed calling limits the cost of incorrect assumptions while lifecycle mappings are still being verified. AI Calling Pilot Spend Controls explains why that stop should exist before the first paid minute.
Make the next morning boring
The Mars Climate Orbiter team did not lack calculations. Two parts of the operation assigned different meanings to the same data, and the disagreement was not caught in time.
A voter-outreach operation faces smaller stakes, but the mechanism is similar. If the provider, runtime, billing ledger, and dashboard disagree about what “connected” or “completed” means, 20,000 records can create confidence without clarity.
Before scaling, run a controlled call set with known outcomes. Include failures, brief connections, opt-outs, duplicate events, and delayed events. Reconcile every record across the provider logs, assistant runtime, billing ledger, and audit trail.
The goal for the next morning is specific: the supervisor should be able to explain every total, open any disputed call, and show how the system reached its status.
Comments
No comments yet.