Turn every phone call into structured data

The problem with call recordings

A recording is not data. Neither is a transcript. Both still require a person to open them, read to the end, decide what happened, and type the answer into another system. At ten calls a day that is an annoyance. At a thousand it is a team — and one that quietly stops doing the job properly somewhere around the fourth hour.

What operations teams actually need from a finished call is a small number of specific answers. Did this lead have budget. What objection was raised. When did they say to call back. Should this account be escalated. Those answers are already in the conversation. Extraction is the step that gets them out in a form software can act on.

How it works

You define a template — a list of fields, each with a name, a type, and a plain-English description of what to look for. When a call ends, the transcript and that template go to an LLM, and what comes back is validated JSON keyed by your field names.

A lending team's template might be four fields: payment_intent as an enum of will_pay / needs_time / refuses / disputed, promise_to_pay_date as a date, escalation_required as a boolean, and call_summary as free text. Every call in that campaign then produces those four values, with the same shape every time, whether the borrower spoke Hindi or Tamil.

Templates belong to a workspace and can be pinned to a specific agent, so a collections campaign and an inbound support line extract completely different things without interfering with each other. They are versioned, so changing a field description does not silently rewrite the meaning of data you already collected.

Dates that resolve correctly

This sounds like a detail and is not. Borrowers and customers almost never state a full date. They say "next Tuesday", "after the 15th", "end of the month". An extractor with no sense of when the call happened will confidently return a date in the wrong year, and you will not notice until a follow-up campaign fires three months late.

Every extraction is given a grounding block built from the calling agent's configured timezone before the transcript is read. Relative dates resolve against the day the call actually happened, in the timezone it happened in — not against the server's clock or the model's training cutoff.

Two ways to capture, one place to read

Some fields are better captured live. If the agent needs to confirm a spelling or read back an account number, it collects that during the call as a tool call. Other fields — sentiment, summary, whether an objection was really an objection — can only be judged once the whole conversation exists.

Both paths write to the same field bag on the conversation. Your CRM sync, your dashboard and your export do not need to know which mechanism produced a given value, and you can move a field from one to the other without changing anything downstream.

Model choice, and what it costs you

Extraction defaults to Gemini 2.5 Flash at low temperature, which is the right trade for this job — the task is reading comprehension against a fixed schema, not creative writing. OpenAI and Anthropic models are selectable per template if you have a reason to prefer them.

If you would rather run extraction on your own LLM account, you can supply your own key at the workspace level. When your key serves the request, the extraction is not billed by us.

Every extraction records what it consumed: input tokens, output tokens, processing time and cost. That is visible per call rather than rolled into an opaque platform fee, so you can see exactly what a schema change did to your unit economics before rolling it across a campaign.

When a model is unavailable

A single-provider extraction pipeline fails whenever that provider does. Ours falls through a chain — your own key first if you supplied one, then the platform Gemini path, then a second Gemini backend, then an OpenAI model as a last resort. A stale customer key or a rate-limited region degrades the run instead of losing the data.

Extractions can also be re-run against calls that already happened. If you add a field next month, you can apply the new template to last month's conversations rather than accepting a hole in the data.