Several Requests in One Conversation: Separate and Hand Over

A message to customer service often holds more than one question: the delivery status, a query about the invoice and, almost in passing, a complaint. An assistant that answers only the first question leaves the rest lying; one that hands the whole conversation to two teams has two people working on the same question. This article describes how an assistant recognises and names several requests, in which order it works through them, what it answers itself from your sources, why a withdrawal or an access request in a side remark needs particular attention and how the rest reaches the right team with each request named on its own, with a summary the customer confirms at the end.

Enlarge graphic

Labels in the illustration

• Message
• Recognised request
• Outcome in the chat
• Close-out
• 1
• Where has my order
• got to?
• Information
• delivery status
• Open, with a reason
• no system connected
• 2
• Why is shipping
• on the invoice?
• Query
• shipping on invoice
• Answered
• source: delivery terms
• 3
• The kettle from last
• week is leaking.
• Complaint
• defective appliance
• Handed over
• to customer service
• Summary
• 1 · open, with reason
• 2 · done
• 3 · handed over
• Customer confirms
• or corrects
• Chat closes
• One responsible person passes on internally
• The handover reason lists each open request separately; the history travels along, fewer repeat questions.

One message, three requests, three separate outcomes

Three requests in one message

A typical message to a shop reads something like this: “Where has my order got to? And why is there shipping on the invoice when I was over the threshold? Oh, and the kettle from last week is leaking at the bottom.” For the customer this is one thought: they buy from you, and three things are not right. For your business they are three matters with three owners: a piece of information that comes from the shipment data, a query about billing and a complaint where someone has to examine the defect. How an assistant answers the first of these questions on its own is covered in the article Where is my order?; here the subject is the message as a whole.

At this point requests get lost in two ways. The first is overlooking: the assistant answers the first question thoroughly, the reply grows long, and the second and third questions no longer appear in it. The customer has to repeat them or gives up. The second is the double handover: the whole conversation goes to accounts and to customer service, both read all three questions, both answer the delivery status, and nobody feels responsible for the kettle because each assumes the other is. Both can be avoided if every request is treated on its own and gets an outcome of its own.

Recognising and naming requests

A language model reads a message as a whole and can distinguish several intentions within it. Whether it does so reliably depends less on the model than on whether the instruction requires it and whether the reply makes it visible. The following signals help to break a message down into requests. None is conclusive on its own; together they usually give a clear picture.

Naming matters more than recognising. Before the assistant answers in detail, it plays the list back: “I have understood three requests: the status of your order, the shipping costs on the invoice and the leaking kettle. I will start with the shipping costs.” That costs one sentence and has two effects. The customer sees that nothing was overlooked and can correct it at once if the assistant has assigned something wrongly. And from that moment the conversation has a structure every further answer can refer to. If a message is ambiguous, the assistant asks a single follow-up question instead of answering three guesses.

Setting the order

The order in which a customer writes is rarely the order in which their requests should be handled. The most important point often comes last because it only comes back to mind while writing. A fixed ranking ensures that something urgent does not wait behind a routine question. It belongs in the assistant’s instruction and is tested with real messages before go-live.

• Danger first: a mention of fire, injury or ongoing damage is meant to come before any other answer, with the number that helps right now. What that looks like is covered in the article on callback requests in chat.
• Declarations with a deadline: a withdrawal, a cancellation or an access request is named and recorded early, even if it came in the last sentence.
• Information from the sources: whatever the assistant can answer with backing, it answers straight away; that settles requests before attention fades.
• Matters for people: complaints, individual cases and discretionary questions are taken down and handed over, with everything the responsible owner needs.
• The rest: remarks and wishes that need no answer are acknowledged and mentioned in the summary.

What the reply looks like depends on the scope. If the requests are short, one reply with numbered parts following the order of the list is enough. If they are extensive, the assistant works through them one after another and announces the transition: “That settles the shipping costs. Next, your order.” A wall of text in which three answers run into each other is the form in which requests are most easily missed, by the customer as much as later by the person reading the history.

What the assistant answers itself

Each request goes through the same check as a single question: is the answer in the sources? In XICBOT, answers are built from the retrieved context of your content and not from the model’s general knowledge; an answer points to where it was found, and if it ends without a single source reference, that is recorded as a gap. In the example, the shipping cost rule can be answered from your delivery terms. An assistant only knows the status of a specific shipment if an inventory system is connected. In the example none is connected: the assistant says so openly and keeps that request as an open point with a reason. Why source references help especially with several requests is shown in the article on citing sources in chat: the customer sees, for each partial answer, what it rests on.

It is precisely the mix of answerable and unanswerable that makes conversations with several requests demanding. An assistant that gives up the whole conversation at the first request without backing throws away the answers it could have given. 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. Only single questions were measured, not messages with several requests; the method is described under measurements. For a conversation with three requests this means: answering in part and handing over selectively has to be provided for in the process.

Declarations with a deadline in a side remark

Some requests are not questions but declarations to which the law attaches consequences. The sentence “and I am sending the second item back, I don’t want it any more” can be a withdrawal under a contract with a right of withdrawal. Under Section 355(1) BGB, withdrawal is effected by a declaration made to the trader; it does not have to give reasons, and dispatching it in good time is sufficient to meet the deadline. The withdrawal period is 14 days (Section 355(2) BGB) and, unless otherwise provided, begins when the contract is concluded; for a purchase of goods at a distance it usually only begins once the consumer has received the goods (Section 356(2) no. 1 BGB). If such a sentence comes at the end of a message about delivery status and invoice, the risk is not that the assistant answers it wrongly but that nobody recognises it for what it might be.

The right of access works in a similar way. If someone asks in the same breath “and what data do you actually hold about me?”, that can be a request under Article 15(1) GDPR, that is, a demand to learn whether and which personal data are being processed. For the response the rule is: the controller provides information on the action taken without undue delay and in any event within one month (Article 12(3) GDPR) of receipt of the request; where necessary, taking into account the complexity and number of the requests, that period may be extended by two further months (Article 12(3), second sentence, GDPR). The deadline depends on receipt, and receipt can be in the chat. What an access request covers with regard to the chat history is described in the article on the right of access.

Handing over separately, not twice

Whatever the assistant cannot settle itself goes to a person. With several requests, how that happens matters. The handover does not say “customer has questions” but lists each open request separately: what it is about, what has already been answered in the chat and from which source, what is open and which details are already available. That way the responsible person sees at a glance that the shipping costs are settled and only the delivery status and the complaint are waiting for them. The general pattern of a good handover is described in the article When the assistant should hand over to people; here the point is keeping several requests apart while doing so.

In XICBOT, the handover sets the conversation to escalated, creates an entry and notifies a person; the full history travels with it. In the inbox the handover appears with request, queue, waiting time and assignee. Which queue receives a topic is decided by your routing rules, not by the assistant: the first matching rule assigns the handover, and an existing assignment is not overwritten by a rule. A second handover in the same conversation does not trigger a second notification. A conversation thus remains one case with one responsible person: the owners from the table are named in the handover reason, and that person passes on other requests internally, instead of two queues working on the same conversation independently of each other. Connected systems such as a ticketing system additionally receive, in the Custom package, an outgoing event on handover, signed, with a delivery log and a retry on failure; there a conversation can be split into several cases if your process provides for it. More on this on the page about the support assistant.

Summary and confirmation at the end

Before the conversation ends, the assistant sums up, not the history but the status of each request. This summary has three jobs. It shows the customer that nothing has been lost. It gives them the chance to correct a misunderstanding or add a forgotten request. And it is the text the responsible person starts from later, because it says in a few lines what the long history only reveals on reading.

• Done: which requests are answered, each with a note of where the answer came from.
• Handed over: which request goes to which owner and what is already available for it.
• Open: what remains unresolved, why, and what the customer can do themselves.
• Next step: how things proceed, without promising a deadline the team cannot control.
• Follow-up question: “Have I missed anything?”, so the customer confirms or adds to it.

The summary also protects against a technical limit. An assistant does not keep the whole history in view but a window of the most recent messages; in XICBOT this history window, like the permitted length of a message, can be set per tenant. In a long conversation the first request can drop out of that window while the third is still being discussed. Naming the list of requests early and repeating it at the end keeps it present in the conversation. How assistants handle the history is described in the article on conversation memory. Only once the customer has confirmed the summary is it the shared status both sides can refer to later.

What the record holds

A conversation with several requests is often read later by several people: by accounts because of the invoice, by customer service because of the complaint, perhaps again weeks later when the customer follows up. For that the record has to be more than a text history. In XICBOT every conversation carries tenant, assistant, channel, language, status and timestamps, and every message its role, its text, the sources used and the tool calls. From this it can be traced which request was answered from what, when a declaration came in and which step triggered a handover. The same model is the basis for analytics, export and deletion.

• Recognisable for each request: the assistant’s answer with its source, or the note that none was available.
• The time of every message, so that a declaration with a deadline can be matched to a receipt.
• The handover reason verbatim, with each open request listed separately.
• The summary and the customer’s reply to it.

Many such conversations reveal which requests frequently occur together. If customers regularly ask about delivery status and shipping costs in the same breath, perhaps a note is missing at the point where the invoice is explained. Conversation analytics groups questions by topic and frequency; which of them occur together is shown by reading individual histories.

Test cases and metrics

Whether an assistant separates several requests cleanly does not show in the single-question conversations acceptance tests often start with. That needs dedicated test cases, ideally from real messages in your inbox, with names and numbers altered. How an acceptance test before go-live is structured overall is described in the article on test cases before go-live.

In operation, three measures show whether the separation holds. First, follow-ups about something already said: if a customer writes “and my second question?”, a request has been overlooked. Second, conversations whose handover reason names only one request although the history contains several open ones. Third, cases passed back and forth between queues until someone takes ownership. None of these measures needs new technology; they arise when someone regularly reads a sample of histories and keeps count.

Honest limits and a checklist

An assistant that separates requests does not replace rules on ownership; it presupposes them. It can take down a complaint but cannot decide whether there is a defect; more on this in the article on complaints and warranty. It can name a sentence as a possible withdrawal but cannot judge whether it is effective. And the splitting itself typically works well but not without error; hence the summary with confirmation. If a conversation with several requests turns heated, the task shifts: it is no longer about the order of the answers but about bringing in a person in good time, as described in the article on frustration in chat.

• The instruction requires several requests to be named before the assistant answers in detail.
• A ranking is set: danger, declarations with a deadline, information, matters for people.
• Each request is answered from the sources, with a source reference; a gap affects only that one request.
• Withdrawal, cancellation and access requests are recorded verbatim with their time and handed over flagged.
• The handover reason lists each open request separately, and each has exactly one owner.
• At the end there is a summary by done, handed over and open, which the customer confirms.
• Test cases with several requests are part of acceptance, a sample of histories is part of operation.

Frequent questions