Callbacks

When someone on a call says "can you ring me back tomorrow at three?", Sysevo doesn't just write it in a transcript and hope somebody reads it. The Callbacks page turns that sentence into a real, scheduled dial — or, when the request is too vague to act on safely, into a job on a review list with the caller's exact words attached.

In this guide

• How a callback is captured
• Getting to the page
• The three tabs: Scheduled, Needs review, History
• How the time is worked out
• Which number gets dialled
• Why a callback lands in Needs review
• The answering-machine guard
• Working the review list
• Editing, rescheduling and cancelling
• Notifications
• Troubleshooting

---

1. How a callback is captured

Every completed call is analysed. Part of that analysis asks a single question: did this person ask to be called back, and when?

The model's job stops at describing what was said — it never computes a timestamp itself. It returns a structured description:

• Did they ask? (yes / no)
• The raw phrase they used, verbatim.
• A time spec — either a duration ("in two hours", "in fifteen minutes") or a calendar reference ("tomorrow", "Friday", "August 15th"), optionally with a clock time or a daypart ("later this afternoon", "tonight").
• A confidence — how precisely the time was stated.
• A number, if they gave one.

Sysevo then does the arithmetic itself and decides one of three things: schedule it, send it for review, or ignore it.

Why the split matters. Letting a language model do date maths is how a callback booked for "in two hours" ends up three weeks out. Keeping the arithmetic in one deterministic place means a prompt change can degrade extraction quality but can never silently break the timing.

---

2. Getting to the page

1. Open the Voice AI hub.
2. Click Callbacks in the left navigation (the calendar-clock icon).
3. The page opens at …/voice/callbacks.

The header reads Callbacks — "People who asked to be rung back, and when they asked for." A Refresh button sits on the right.

Callbacks share the Campaigns feature gate.

---

3. The three tabs

Each scheduled row carries a state:

---

4. How the time is worked out

Two kinds of request resolve differently.

Durations — "in two hours", "in twenty minutes". These resolve immediately from the moment of the call and never need a timezone. They are bounded deliberately: at most 12 hours or 720 minutes, at least 1. A misread like "in 500 hours" is rejected rather than booked three weeks out, and a zero that would resolve to now is rejected too.

Calendar references — "tomorrow", "Friday", "the 15th". These need the caller's timezone to become a real instant, because 3pm is not a moment in time until you know where the person is.

A few rules make the results sensible:

• Weekends roll to Monday — unless the caller explicitly named Saturday or Sunday. "Tomorrow" on a Friday means Monday; "call me Saturday" means Saturday.
• A daypart fills in for a missing clock time — morning becomes 9am, afternoon 3pm, evening 6pm.
• No time and no daypart defaults to 11am.
• The caller's own words overrule the model's reading of them. If the transcript plainly says "in two hours" but the extraction came back as a calendar time, the spoken duration wins.

---

5. Which number gets dialled

Four possible numbers are considered, in this order:

The order is what did they ask for → what do we know, not what is the cleanest data. A direct line someone hands over beats the switchboard we called, even though ours is tidier.

Every candidate is validated before it is used: it must be 8–15 digits and must not contain letters. Transcript debris like "this one" (lifted from a caller answering "this one's fine") is rejected — and a rejected candidate falls through to the next source rather than ending the search.

On outbound calls, the number we called from is deliberately never used as the number to ring back. That is our own caller ID, and dialling it would ring ourselves.

---

6. Why a callback lands in Needs review

A callback goes to review rather than the dialler when it cannot be turned into a defensible time. The reason is always stated verbatim on the row:

Each review row shows the raw phrase the caller actually used. That is usually enough to resolve it in one glance without opening the call.

---

7. The answering-machine guard

An answering machine says "please leave your name and number and I'll get back to you." Read literally, that is somebody asking to be rung back — and the extracted callback object is indistinguishable from a genuine request. The words are identical; only the speaker differs.

Sysevo already knows the difference from the disposition assigned earlier in the same analysis. So a callback extracted from a call whose disposition sits in the machine answered bucket — voicemail, call screening, IVR — is filed for review with the reason "machine answered (voicemail_business) — greeting, not a request" rather than dialled.

Two deliberate exclusions:

• needs_review dispositions do not suppress. A genuine request the classifier simply could not code must never be dropped — a real person never getting their call back is a worse failure than a junk row a human closes in two seconds.
• An unknown or missing disposition fails open. A missed suppression costs someone thirty seconds; a wrong one costs a prospect.

---

8. Working the review list

For each review row you can:

• Read the phrase — what the caller actually said.
• Open the call — jump straight to the conversation and its recording.
• Set a time and schedule it — supply the time the extraction could not resolve, and it joins the Scheduled tab.
• Add or correct the number — where the reason was a missing or unusable number.
• Dismiss it — for machine greetings and anything that was never a real request.

Read before dismissing in bulk. Several review reasons — a vague time, a missing timezone — sit on top of a perfectly real request from a real person.

---

9. Editing, rescheduling and cancelling

A scheduled callback that has not yet run can be rescheduled or cancelled from its row. Cancelling removes it from the queue; it stays visible in History so the record of the request is never lost.

A cancelled callback is not resurrected by a later analysis run.

---

10. Notifications

Callbacks becoming due raise a notification so a person is prompted before the moment passes, rather than discovering the request afterwards in a transcript. Notification routing is configured per user under Settings → Notifications.

---

11. Troubleshooting

---

Related guides

• Call Analysis — what gets extracted from each call
• Call Actions — the other things that happen automatically after a call
• Dispositions — how the answering-machine guard knows
• Campaigns — the outbound calling callbacks come from