Twi Call Evidence Fades Fast. Write the Incident Report Before Complaints.

A Twi call-failure incident report should begin as soon as call-truth data shows a meaningful failure pattern, before a customer complaint turns investigation into a scramble. Capture the call evidence, the customer impact, the current hypothesis, and the containment decision while the records and context are still available.

In 1970, Apollo 13’s crew faced a damaged spacecraft after an oxygen tank exploded en route to the Moon. Jim Lovell, Jack Swigert, and Fred Haise had limited supplies and an uncertain path home. Mission Control in Houston had to work from telemetry, test possible fixes, and communicate decisions before the situation became fatal. Jim Lovell and Jeffrey Kluger document the response in Lost Moon: the team worked from the evidence available, including the urgent carbon-dioxide problem, rather than waiting for a complete explanation.

A failed Twi call has lower stakes, but the operating discipline is the same. Write down what the system can show now. Do not wait for a campaign manager to send a recording with a frustrated note attached.

Start with the call record, not the suspected cause

The first draft should separate observed facts from interpretation. That distinction keeps an incident report useful when the initial theory proves wrong.

Open with the smallest reliable statement: which agent, which call window, which campaign or queue, and what call-truth records show. A useful first sentence might read: “Between the recorded call start and end events, this Twi outbound call ended before the intended handoff, with no completed outcome recorded.”

Then add the evidence available at the time:

• The telephony lifecycle events, including whether the call connected, ended early, failed to reach the assistant runtime, or reached a handoff state.
• The configured persona, first message, and selected voice for the affected agent.
• The Twi and English transcript segments, where they exist, clearly marked as recognition output rather than a perfect record of what the caller meant.
• Consent, opt-out, and audit-trail events associated with the call.
• The call identifier, timestamps, and any repeat pattern across similar calls.

Do not write “the agent misunderstood the caller” unless the evidence supports it. Write what happened first: “The caller switched into Twi after the opening message; the next recorded turn did not produce a completed response.” That gives the next reviewer something concrete to test.

For a related example of why end labels can obscure the real customer outcome, see The “Ended Early” Label That Hid Twi Callers’ Unresolved Cases.

State the customer impact before the engineering detail

An incident report earns trust when it describes the customer-facing consequence plainly. The issue may be a failed recognition turn, a telephony event gap, or a handoff that never completed. The customer experiences a call that stopped making sense.

Name the likely impact with an appropriate confidence level:

“Callers who reached this point may have been left without the requested account action.”

“Callers may have heard an incomplete Twi response before the call ended.”

“Because opt-out confirmation was not recorded after the request, this call requires review before any further campaign contact.”

That last example matters. In voice calling, an unresolved consent or opt-out event is not a minor logging defect. It should change what happens next. The report should record whether the affected agent, campaign, or contact segment was paused, restricted, or left running, and who made that decision.

Use a fixed four-part report while evidence is fresh

A short report written immediately is more valuable than a polished explanation written after everyone has moved on. Use four parts.

First, record the observed failure. Include the call-truth timeline and the specific point where expected behavior diverged.

Second, describe customer impact and scope. One call may be isolated. A cluster of calls with the same persona, opening message, or Twi utterance needs a wider review. Do not claim a campaign-wide problem from a single record.

Third, list the working hypothesis and what would confirm or rule it out. For example: “Possible recognition failure following a Twi code-switch. Review comparable recordings and transcript confidence signals before changing the agent prompt or voice configuration.”

Fourth, document containment and next owner. That may mean pausing a campaign, reviewing a small sample, changing the first message, or escalating a consent concern. Include the decision time and the person responsible for the next update.

This structure also makes it easier to tell the difference between a call that ended because the caller chose to leave and a call that ended while the system still owed them a useful response.

Preserve uncertainty, then close the loop with evidence

Apollo 13’s team did not begin with a clean root cause report. They had incomplete telemetry, constraints they could not ignore, and a need to act before every unknown was resolved. The value of their process was disciplined evidence and clear decisions under uncertainty.

Apply that discipline to Twi calling. Keep the first report factual, mark assumptions as assumptions, and update it when playback, call-truth events, and audit records show more. If a caller requested a human and the handoff did not complete, say so. If a phrase was recognized inconsistently, preserve the exact segment for review. If consent status is uncertain, prevent the next call until it is resolved.

The report becomes the handoff between the person who sees the flag and the person who can fix the system. Write it while the evidence is still intact, then use the next call review to prove or disprove the first explanation.