Callback Requests in Chat: Capturing the Whole Matter

When a callback beats a chat reply, what the assistant asks first, how the request reaches your team and where the emergency number comes first.

In plain language

Sometimes a callback is better than a reply in the chat. This is the case when it is urgent, when it needs a talk or when someone wants to speak. First the assistant asks for the matter, the phone number, a time, any order or customer number and how urgent it is. The number is used for the callback, not for adverts. The request reaches your team as one case with the chat history. It is created exactly once. An emergency does not belong on the callback list. When there is danger, the assistant is meant to name the emergency number first.

September 19, 2026 14 min read By XICBOT

Key points

A callback is the better answer when a matter is pressing, can only be clarified in conversation or someone explicitly wants to talk. For information from the knowledge base the chat remains the faster route.
Before the handover the assistant asks for five details: the matter in one sentence, the callback number, a time window, any order or customer numbers and the urgency.
The phone number serves the requested callback, not advertising. Anyone who wants to call consumers for advertising later needs a separate prior express consent, which has to be documented.
The request reaches the team as one complete case including the conversation history – via a shared inbox or, in the Custom package, via a ticket system or a notification to your own system – and it is created exactly once.
An emergency does not belong on the callback list. When there is danger, the assistant is meant to name the emergency number or the firm’s emergency line first instead of collecting details.
The process becomes measurable through a few figures taken from the cases themselves: callback rate, time to callback and open requests at the end of the working day.

When a callback is the better answer

An assistant is strong at questions whose answer is written down somewhere: opening hours, delivery terms, how a service works. It is not strong when the answer only emerges while two people talk to each other. That leaves three situations in which a callback serves better than any further chat message. First, the urgent matter that is not an emergency: the heating only half works, delivery is tomorrow and the delivery address is wrong. Second, the matter that needs explaining: a situation involving several parties, an invoice with a history, a project that only gets its scope in conversation. Third, the plain wish to talk – it needs no justification, and the assistant should not ask for one. Which calls the chat can take over in the other direction is covered in the article on relieving the phone.

Situation	How the assistant recognises it	What it offers
Urgent, but not an emergency	A time reference in the description: today, tomorrow, right away, no longer works	Callback marked “today” with the next staffed time window
Needs explaining	Several follow-up questions without progress, a history, several parties	Callback with a summary of what has been clarified so far
Explicit wish to talk	Sentences such as “Can someone call me?” or “I would like to speak to someone”	Callback without further attempts at persuasion
Writing is difficult	Very short messages, switching language, references to assistive tools	Callback or the phone number, whichever is preferred
A decision is needed	Goodwill, a quote, an exception to a stored rule	Callback by the person who is allowed to decide

A callback is not, however, an escape route for questions the assistant could answer itself. If it is offered too early, it pushes work back to the phone that the chat was meant to take over. How large the share of questions is that get by without a person can only be measured: in our own measurement series, 43 of 48 questions stayed without a handover to a person; this was measured on a single assistant on our own knowledge base, not on customer projects, and a figure from live operation is not yet available. The method is described under measurements. For the remaining cases the callback is one of several routes, alongside direct handover and the ticket.

Five details before anyone calls back

A callback request is worth exactly what it contains. If it only contains a number, the callback starts with the same questions that were already answered in the chat, and the customer experiences the handover as a fresh start. If it contains the matter, the person on the phone can begin with the answer or at least with the right follow-up question. In most cases five details are enough for that. They are asked for in the course of the conversation, one after another, not as a block of form fields at the end.

The matter in one sentence

What is it about, in the customer’s words and summarised by the assistant? The summary is played back and confirmed before it is passed on. It is the field the person calling back reads first.
Callback number

The number at which the customer can be reached in the stated time window – not necessarily the one in the customer account. The assistant repeats it for checking, because two transposed digits make the whole case worthless.
Time window

Mornings, afternoons, later today: only times in which someone can actually call are offered. A window is a preferred time, not a confirmed appointment, and the assistant says so.
Prior information

Order, customer or case number, if there is one. It saves the search before the callback and prevents two cases from being mixed up. If it is missing, a name and one feature such as the order date are enough.
Urgency

Today, in the next few days or no rush. The level sorts the list for the team. If the description reveals an emergency, the callback process ends at this point and the assistant names the appropriate emergency number.

The order of the questions follows the conversation, not a list. Someone who has already written that delivery is tomorrow is not asked about urgency again; someone who gave the order number in the first message is not asked for the order number. The assistant collects from the history what is already there and only asks for the rest. If the description becomes noticeably impatient along the way, that is a reason to get to the request faster and ask fewer follow-up questions. How an assistant recognises annoyance and when it hands over is covered in the article on frustration in chat.

Capturing the matter in one sentence

Of the five details, the matter has the greatest influence on whether the callback succeeds. A line such as “Question about invoice” forces the person calling back to start the conversation from scratch. A line such as “September invoice debited twice, wants a refund to the same account” lets them call prepared, with the case open and the answer in mind. The difference does not arise with the customer, who said the same thing in both cases. It arises in the summary, and that is why the summary deserves rules of its own.

Subject, problem, timing: the matter states what it is about, what is wrong and, if known, since when.
One goal: what does the customer expect from the callback – information, a decision, an appointment?
The customer’s own words stay: their terms are not translated into internal labels, because they should recognise them on the phone.
No judgement: the summary describes, it does not rule on fault, entitlement or goodwill.
Confirmed: the customer sees the sentence before it is passed on and can correct it.

Whoever calls back should be able to start with the answer

A callback request has worked when the first sentence on the phone is not “What is this about?”. Everything needed for that has already been said by the customer in the chat. The assistant’s job is to record it in a way that nobody has to ask for it a second time.

Phone number, consent and purpose limitation

A phone number is personal data, and processing it requires a legal basis. For a callback request that basis does not, as a rule, lie in a separate consent but in the request itself: the customer wants to clarify something – an order, a job, a quote – and provides the number so that exactly that can happen. Article 6(1)(b) GDPR covers processing that is necessary for the performance of a contract with the data subject or in order to take steps at their request prior to entering into a contract. Independently of that, Article 13(1) GDPR requires the information about the processing to be provided at the time the data are collected. In the chat this means a short notice next to the question about the number, linking to the full privacy policy.

processing is necessary for the performance of a contract to which the data subject is party or in order to take steps at the request of the data subject prior to entering into a contract

Regulation (EU) 2016/679 (GDPR), Article 6(1)(b)

The purpose is fixed by the request, and everything else depends on it. The number was given for this callback about this matter. Adding it to a mailing list, using it for a satisfaction survey or handing it to sales for a later campaign is a different purpose. The General Data Protection Regulation sets out this principle in Article 5(1)(b).

collected for specified, explicit and legitimate purposes and not further processed in a manner that is incompatible with those purposes

Regulation (EU) 2016/679 (GDPR), Article 5(1)(b)

For the phone, competition law comes on top. A callback about the requested matter is covered by the customer’s request. A later call to make a consumer an offer they did not ask for is telephone advertising, and for that Section 7(2) no. 1 UWG requires prior express consent; the callback request from back then does not replace it. Anyone who then advertises by phone must, under Section 7a UWG, document the consent in an appropriate form at the time it is given and keep the proof for five years (Section 7a(2) UWG), counted from when it was given and again after each use. What a clean consent flow in a chat looks like is covered in the article on consent for contact data.

What the number is used for: the callback about this matter.
Who calls back: the company itself, where applicable the responsible department.
A link to the full privacy policy, reachable with one click from the chat window.
How long the request is stored, or where that can be read.
If wanted, a separate question about advertising calls that is not pre-selected – not bundled with the callback request.

How the request reaches the team

A callback request that sits in the chat log and is seen by nobody is worse than none: the customer waits for a call that does not come. The handover therefore needs a route on which the team reliably sees the request, and a status from which you can tell whether it has been dealt with. Which route fits depends on where your team works today. In principle, what the article on handover to staff describes for every handover applies: the full context travels along so that nobody has to ask again.

Route	Fits when	What to watch out for
Message to a team inbox	callbacks are already distributed by email today	A shared inbox, not the address of a single person who happens to be on holiday
Entry in the CRM or ticket system	cases are kept there anyway	The entry is created exactly once, even if the customer confirms twice
Notification to your own system	a tool of your own keeps the callback list	Signed message, delivery log and retry on failure
List in the conversation overview	the team works in that interface anyway	A visible status: open, in progress, done

In XICBOT, “record callback” is one of the write actions the assistant carries out in connected systems in the Custom package, and like every write action it is bound to an approval; this is described on the tool control page. Regardless of the tool, two places deserve attention where callbacks get lost in practice. The first is the duplicate entry: if the customer confirms twice, the same callback must not appear twice for the team – otherwise two people call, or nobody does because each assumes the other will. The second is silent delivery: if the transfer fails, someone has to see it before the customer notices.

An emergency is not a callback

There are descriptions for which a callback list is the wrong answer, however well it is kept. If someone has fallen and cannot get up, if something is on fire, if water is standing in the flat and still rising, then every question about a time window is lost time. In this case the assistant is meant to name first the number that helps now: for danger to life and limb, fire or an accident, 112 (fire brigade and ambulance service); for a crime, 110 (police); for damage in progress, the firm’s emergency line. Only after that, and only if it still helps, does it take down details. That emergency connections via 112 and 110 must be possible free of charge for end users is laid down in Section 164 of the German Telecommunications Act.

so that end users can make free-of-charge connections initiated either by dialling the single European emergency number 112 or the additional national emergency number 110 or by sending corresponding signals

German Telecommunications Act (TKG), Section 164(1), first sentence (translated)

Danger to life and limb: an immediate reference to 112 (fire brigade and ambulance service), or to 110 (police) for a crime, without prior questions.
Damage in progress: the firm’s emergency line to call directly, with the times when it is staffed.
Urgent, but no damage in progress: callback request marked “today” with the next staffed time window.
No rush: callback request with a preferred time, or a pointer to a fixed appointment.

For trades businesses this is not an edge case but everyday life: burst pipe, heating failure, power cut. The assistant for trades businesses is meant to recognise the urgency in such descriptions and point to your emergency service: with the stored number or with a callback request that already contains the captured matter. What matters is the order: the number comes first, the details afterwards. Someone who is mopping up water does not answer five questions.

Time windows the team can keep

The preferred time is where a callback most easily turns into a promise nobody can keep. “We will call you back in ten minutes” sounds friendly and is a promise that breaks on the first busy Monday. It is better to offer only windows in which someone is actually available, and outside those times to say openly when someone will call at the earliest. If the matter needs a fixed appointment rather than a callback – a consultation, a viewing, an on-site measurement – the callback is a detour. Then the customer belongs in an appointment request, as taken by the booking assistant with free times from your appointment types; it becomes binding once your business confirms it.

Windows instead of exact times: mornings, afternoons, later today – depending on staffing.
Outside staffed hours the assistant states the earliest realistic time and no preferred time that nobody covers.
The customer receives a confirmation with the matter, number and window, so that they can spot mistakes themselves.
If the team cannot reach the customer, there is a fixed number of attempts followed by a message via the agreed channel.
A callback that does not succeed within the window is not quietly postponed but communicated to the customer.

Making callbacks measurable

Whether the callback process works is not shown by the impression that things have become quieter, but by a few figures that come from the cases themselves. They require every request to have a status and that status to be maintained. Without the “done” tick, none of the following metrics can be formed.

Metric	How it is counted	What a rise can mean
Callback rate	Conversations with a callback request divided by all conversations in a period	Gaps in the knowledge base or an assistant that hands over too early
Time to callback	From the request to the first call attempt, as a weekly median	Too little staffing in the windows on offer
Open requests	Requests without the status “done” at the end of a working day	A delivery route that nobody looks at any more
Reached on first attempt	Successful first attempts divided by all first attempts	Windows that do not suit the customers
Questions asked twice	Sample: were details asked for on the phone that were already in the chat?	A summary that turns out too brief

The callback rate is the figure most easily misread. A high rate is not bad if the matters genuinely need a conversation. It is a warning sign if the same information question repeatedly ends in a callback: then the answer is missing from the knowledge base, and the right step is to add it there rather than keep the team on the phone. Which conversations lie behind the figures is shown by regular conversation analytics.

Honest limits and a checklist

An assistant takes down the callback request, it does not call back. How good the process is in the end is decided by the team: by the staffing of the windows, by keeping the statuses up to date and by whether someone looks at the open requests in the evening. Then there is retention. A completed callback request including the number does not have to be kept indefinitely; how to set retention periods for conversation logs is covered in the article on retention periods. The XICBOT lead assistant takes down callback requests with a preferred time in the course of the conversation and passes them on to your team in structured form.

The situations in which the assistant offers a callback are set down in writing, as are those in which it answers itself.
The five details are asked for in conversation, the matter is summarised and confirmed by the customer.
Next to the question about the number are the purpose and a link to the privacy policy; any advertising consent is kept separate.
The request arrives on a route the team looks at daily, exactly once and with the conversation history.
Emergency descriptions are meant to lead first to the emergency number or the firm’s emergency line, not onto the callback list.
Only staffed time windows are offered.
Callback rate, time to callback and open requests are reviewed regularly.

Frequent questions

When should an assistant offer a callback?

As a rule, when a matter is pressing without being an emergency, when it can only be clarified in conversation or when someone explicitly wants to talk to a person. Add to that cases in which a decision is needed that only an authorised person may take. For information that is in the knowledge base the callback is usually the slower route; there the assistant does better to answer itself and offer the callback if the customer wants it.

Which details belong in a callback request?

In most cases five are enough: the matter in one sentence, the callback number, a time window, any order or customer numbers and the urgency. Whatever only becomes necessary for a quote or an order, such as a postal address, is asked for by the person on the phone in the appropriate context.

Do I need consent for the callback number?

Usually not in the form of a separate consent. If a customer asks for a callback about their own matter, Article 6(1)(b) GDPR typically comes into consideration as the legal basis, because the processing serves the performance of a contract or steps taken at their request prior to entering into a contract. The information about the processing still belongs in the chat, at the time of collection. Whether this holds in a specific case, for example with sensitive matters, should be reviewed professionally.

May I use the number later for offers?

Not without further ado. The number was given for a callback about a specific matter, and a later advertising call to consumers requires prior express consent under Section 7(2) no. 1 UWG. That consent has to be documented and the proof kept for five years (Section 7a(2) UWG). Anyone planning advertising calls therefore obtains it as a separate, voluntary step, apart from the callback request and not pre-selected.

What does the assistant do if someone describes an emergency?

It is meant to name first the number that helps now: for danger to life and limb, fire or an accident, 112; for a crime, 110; for damage in progress, the firm’s emergency line. Only after that does it take down details, if that still helps. It does not place an emergency call itself and cannot assess a situation; the emergency replies should therefore be tested before go-live with typical descriptions.

How can I tell whether our callbacks are working?

From a few figures taken from the cases themselves: the callback rate, the time from the request to the first call attempt and the number of open requests at the end of a working day. A sample is also revealing: did the phone call have to ask for details that were already in the chat? These figures require every request to have a maintained status.

Ask it yourself, Assistant of this website

Automated assistant

Settings