A calls table written by the voice webhook, idempotent per provider call id, plus a call_events table that stores every raw webhook payload. It is what the Recents tab, number health, the callback queue and per-line usage all read. Write-back state records whether the thread row, the callback episode and the task each landed.
Also called: call reporting · call data · why was the call missed · call audit
- 1Idempotent on (provider, provider_call_id) so webhook retries update rather than duplicate
- 2MONOTONIC on outcome — a known miss is never walked back to answered
- 3Never throws: a logging failure must not change what the caller hears
- 4Every write also lands a raw event in call_events, with a synthesised event id because the provider sends none
- 5markWriteback records per-target success and rolls it up to done / partial / failed
A call left behind one sentence of prose in a conversation and nothing else — so "how many calls did we miss last week", "how long was that call" and "why did this one not connect" had no answer anywhere in the product. Reporting on the phone meant reading threads. Every call is now a queryable fact — direction, duration, who answered, why it was missed, recording and transcript — with the raw carrier events kept behind it for when something looks wrong.
- Call history as unstructured prose
- Webhook retries duplicating call records
- No basis for number health, callback metrics or per-line usage
See it on your own jobs
Twenty minutes, your numbers, no slide deck. We’ll build one of your real buildings in front of you and send you the estimate link at the end — yours to keep either way.
or keep browsing features →