Chatbot and agent: how to hand over requests without losing context

A customer asks in chat why an order is marked as delivered even though the parcel has not arrived. The bot offers tracking instructions, then repeats them in different words. The customer asks for an agent, but the conversation returns to the menu again. When an employee finally joins, they have to ask for the order number once more.

In this situation, the problem is not just the quality of the automated response. The company has not defined when the bot should stop, who will accept the request and what context the agent will see. These are the arrangements worth checking before launching automated support.

Handing a chat over from a bot to a person without losing context requires a clear handoff condition, a saved conversation history, a brief description of the unresolved issue, an accountable person and an honest message about the wait. Below is a practical procedure you can adapt to your team. These are process recommendations, not claims that all the actions described are already automated in a particular product.

Chatbots and live chat: what exactly are you combining?

Website chat is a communication channel. A person, a rule-based bot or an AI assistant can respond in it. So the presence of a widget alone does not tell you who is helping the customer or what decisions they are authorized to make.

A rule-based bot follows predefined paths: for example, it offers a choice of topics and asks for contact details. An AI bot can generate responses based on connected sources, but the quality of those sources and its operating rules need to be checked. An agent adds investigation, assessment of unusual situations and decisions within their authority. People can also make mistakes, however, and no format on its own guarantees good service.

Assign work according to the nature of the request, rather than the principle that “the bot answers everything first.” Public information about opening hours can remain automated. A disputed charge, suspected unauthorized access or an exception to the returns policy requires a separate route to an authorized employee.

If request volumes are low and one person can handle them, ordinary chat with a message about working hours may be enough. A bot is not necessary just because it comes with the platform. First, determine what repetitive work it actually needs to do.

When a bot should hand a request over to an agent

Draw up a short list of conditions the team can explain and test. Do not rely solely on a general rule such as “if the bot cannot handle it”: that will mean different things to different employees.

• The customer explicitly asks for a person. Make this route accessible without requiring them to go through the entire menu again. If contact details are needed for a reply, explain why rather than disguising data collection as another attempt to provide advice.
• There is no verified answer. Missing instructions, conflicting terms or a request outside the permitted scenario are reasons to hand the issue over, not invent a solution.
• The previous advice did not help. Once the customer reports an unsuccessful attempt, do not start the same loop again. Record exactly what has already been checked.
• A decision or access is required. Individual compensation, payment verification, account data changes or technical investigation should go to the appropriate role.
• There is a risk or a sensitive issue. Prepare a separate procedure for suspected fraud, access to data and other cases defined by the company.

This does not mean that every mention of a “return” always requires manual work. A general link to the policy can be provided automatically. But checking whether a particular customer qualifies for an exception should not be replaced with generic instructions. The boundary is determined by the risk of error, the available data and approved authority.

Similar handoff principles are described in current practical guidance from Gleap on combining chatbots and agents. Use them as a reference for your own procedure, not as a promise about any system’s capabilities. The source was checked on November 11, 2026.

What context to pass along with the chat

A full history and a short summary serve different purposes. The history makes it possible to check the details. The summary helps the agent quickly understand what to do next. If you pass on only the history, the agent will spend time piecing it together. If you pass on only the summary, they risk missing an important condition or an error in the automated response.

A minimum handoff record

• What the customer wants: an explanation, a check, a change or a specific action.
• What information has already been provided: for example, an order number and a way to contact the customer.
• What the bot suggested and what outcome the customer reported.
• What remains unresolved and why a person is needed.
• Who the issue is being routed to, who checks that it has been accepted and what next action the team expects.
• What waiting-time message the customer has already received.

Collect only the data needed for the specific issue. Do not ask for a password, one-time codes or full payment details to fill out the record. If identity verification is needed, arrange it according to an approved procedure in an appropriate secure environment.

An AI-generated summary should not be treated as verified fact. Before making a decision, the agent should check key details against the history and available records. This is especially important for payment amounts, promises made to the customer and actions that have supposedly already been completed.

A handoff is complete only after acceptance

The message “I’m transferring you to a specialist” does not prove that a specialist has seen the request. Distinguish at least three events in your procedure: the handoff has been initiated, the request has been accepted and the customer has received a human response. These can be stages in the process even if the system does not have corresponding built-in statuses.

Define who monitors requests that have left the bot’s flow but do not yet have an assignee. For a small team, this could be the manager on duty. With several departments, you need a rule for selecting the team and a backup person responsible if the first route fails.

Once a person accepts the conversation, the bot must not continue running the same flow in parallel. Check how responses are stopped and who can restart automation. Otherwise, the agent may be arranging a payment check while the bot simultaneously says that the issue has been resolved.

The end of a shift does not remove responsibility for a conversation that has already been accepted. If the issue passes to another employee, apply separate rules for handing requests over between shifts. At that point, it is important to preserve the next action and confirm acceptance between people, rather than putting the customer through the bot again.

What to tell the customer when no agents are available

Automated chat availability does not mean the team is available around the clock. If people respond during working hours, say so before completing the handoff. Do not display “an agent is joining now” if the request is simply queued until the next day.

A useful message explains that the request has been saved, when the team will return to work and where the reply will arrive. Promise a specific deadline only when the company can realistically meet it. For critical situations, show a separate channel only if there really is an active on-call service.

You can use the following wording as a working template: “We have saved your question and previous conversation. Our team responds [working hours]. We will continue the investigation [agreed timeframe or procedure]. You will receive a reply via [channel].” Replace the values in brackets with the company’s actual terms rather than leaving them in the live flow.

Hypothetical example: a parcel is missing even though its status is “delivered”

This is a hypothetical scenario for testing the process, not a HelpDeskStar customer case study. The customer has provided an order number, received tracking instructions and reported that they did not help. They want to find out where the parcel is, not read the help information again.

Under the procedure, the bot stops repeating the instructions and passes on the history with a summary: “Order [number], status delivered, customer denies receiving it. Instructions reviewed, no result. Delivery needs to be checked.” The system or the manager on duty routes the issue to the responsible team, depending on the verified capabilities of your configuration.

The agent first reads the context, confirms acceptance and explains the next step. If help from logistics is needed, the internal task should include the question to investigate, an assignee and the expected outcome. Responsibility for the customer conversation remains clearly assigned; handing over internal work must not leave the customer without a contact.

The success criterion here is neither “the bot sent a reply” nor “the chat was transferred.” The team needs to establish the actual delivery status and communicate a confirmed result or a clear next step to the customer. Test that exact path, including the wait for another department.

How to test the route in HelpDeskStar before launch

HelpDeskStar brings customer requests and internal tasks together. This matters after a handoff to a person: the issue may require not another chat reply, but work by another department with a designated person responsible. The website also describes request history, response templates and an internal knowledge base.

However, the presence of chat, automated responses or a messaging-platform bot connection does not prove the availability of an autonomous AI adviser with a ready-made agent handoff. If you are planning that scenario, separately check the compatibility of your chosen bot, how the history is transferred, assignment rules and the required plan. Do not assume one product has another product’s capabilities because a feature has a similar name.

An acceptance test for the demo

1. Ask a typical question, then say that the suggested answer did not help. Check whether the loop repeats.
2. Ask for a person and make sure the request enters a working process rather than merely receiving a polite brush-off.
3. Open the request from the agent’s perspective: are the history, information already provided and reason for the handoff visible?
4. Accept the conversation and check that the bot no longer sends conflicting responses.
5. Repeat the scenario with no agents available and check the message, queue and backup responsibility.
6. Involve another department and follow the process through to the final response to the customer.

After launch, review unaccepted requests, lost context, repeated requests to speak to a person and cases where the bot continued responding after the handoff separately. Do not judge automation solely by the number of conversations that never reached an agent: some customers may simply have stopped trying. For low volumes, manually reviewing conversation histories is enough; add complex analytics to answer specific management questions.

Conclusion

A chatbot and an agent complement each other when there is a tested route between them. Start with clear handoff conditions, a minimum context record and a person responsible for acceptance. Then test out-of-hours handling, stopping automated responses and interaction with other departments. This approach helps you assess the actual customer support process rather than an impressive bot demonstration.

See HelpDeskStar in action — book a demo and test the system using examples of your company’s tasks.