Call memory

Without memory, every call starts from zero. For a support or sales line that's a bad look: a customer who rang yesterday, explained their problem, and agreed a plan has to explain the whole thing again.

Call memory gives the agent a short history of its previous conversations with the same contact, so a returning caller is treated like a returning caller.

What the agent actually gets

Not the transcripts. A compact rolling summary of what the previous calls were about — a few lines, not a document.

That's deliberate. Transcripts are long, noisy and would slow every call down; summaries carry the useful part. In practice the agent knows things like "called last Tuesday about a broken boiler, engineer visit was arranged for Friday" and can open with something that acknowledges it.

What builds it

Memory is assembled from the AI call summary written after each call. That has two consequences worth knowing:

• Memory only works on plans that include AI call analysis, and it draws on the same monthly allowance. See Plans & limits.
• Calls that weren't real conversations never enter the history. A call has to run long enough and actually involve the caller speaking before it counts — so wrong numbers, immediate hang-ups and voicemail hits don't clutter the memory.

The history is built up incrementally as calls happen rather than rebuilt each time, which keeps it cheap and stable.

Who it's matched to

• Outbound calls — unambiguous. The system knows exactly which contact it dialled.
• Inbound calls — matched on caller ID, and only when exactly one contact in your CRM owns that number.

That second rule is stricter than it looks, and it's intentional. If two contacts share a phone number — a couple, an office line, a duplicate record — the system won't guess. Guessing would mean reading one person's conversation history to whoever happens to be on the line.

The agent treats memory as facts, not orders

Memory is derived from things callers said, which makes it untrusted input. Someone could deliberately say something on one call designed to manipulate the agent's behaviour on the next.

The system handles this: the memory is passed to the agent inside a clearly marked boundary with instructions to treat it as background information only — never as instructions, never as approval for anything, and never as proof of who someone is. The boundary itself is randomised per call so it can't be predicted or imitated.

You don't need to configure any of this. It's worth knowing it exists if you're evaluating the product for a security-sensitive use case.

The post-call reconciler

A related system, and one of the more useful things in the product.

Calls end messily. A caller agrees to a Thursday appointment and the line drops before the agent writes it down. The conversation happened; the booking didn't.

After every call, a second pass re-reads the transcript, compares it against what actually got created, and completes what's missing.

The rules it works under

These constraints are what make it safe to leave switched on:

• It heals, it never invents. A booking is only created if the caller explicitly agreed to a specific date and time — and the system has to be able to point at the caller's own words agreeing to it. Anything vaguer becomes a follow-up instead of a booking.
• It never picks a slot for the customer. If the time was ambiguous, it doesn't choose one.
• It can't do anything the live agent couldn't. If booking is switched off for that agent, the reconciler can't book either.
• Times are treated as the caller said them. "Tuesday at 2" is resolved in your workspace timezone — which is why getting the timezone right matters more than it seems.
• It runs once per call, so a hiccup can't produce a double booking.
• It respects your plan quotas and re-checks availability before writing anything.

Anything it creates is marked as having come from the post-call pass, so you can tell at a glance what the agent did live versus what was healed afterwards.

Configuring it

Telephony → Numbers → open a number → Post-call actions

It's set per phone line, so a sales line and a support line can behave differently.

A master switch turns the whole thing on or off, and then two independent switches:

• Schedule a missed follow-up — if the call ended with an open item and no call-back was booked.
• Complete an agreed booking — if the caller agreed a specific time but the booking never saved.

Everything is on by default, because the gap it closes is real and common.

Each switch also takes a "when should it do this?" instruction in plain English, handed to the AI word for word. Leave it blank to use the sensible default shown in the box, or narrow it:

Only schedule a follow-up if the caller explicitly asked to be called back. Don't create one just because they sounded interested.

Turn booking-healing off if you'd rather have a missed booking than an unexpected one — for example if your slots are genuinely scarce and a wrongly-created appointment costs you more than a lost one.