To avoid this, a shared case model needs to be designed. The bot cannot just store the content of the last message. It should record who the customer is, what the ticket concerns, what stage the service has reached, what has been verified, what action has been taken and what should happen next. Only on this basis can an agent join the conversation without asking: “Could you please explain from the beginning?”

Chatbot and voicebot in customer service: two channels, one customer case

Each channel has its own strengths. Chat makes it easy to send a link, a photo, an order number or step-by-step instructions. The phone makes it quicker to clarify an unusual problem, guide the customer through diagnosis or respond in an urgent situation. A customer service chatbot and voicebot should therefore not carry out exactly the same dialogues word for word. Instead, they should use the same case data and lead to the same outcome.

In practice, it is worth treating each case as a working record visible regardless of channel. The minimum set of information on such a record includes the contact identifier, the method of identifying the customer, the subject and detected intent, the related order or ticket, the current status, the actions taken, the result of any tools used, the preferred response channel, and the reason for any handover to a human. Not every conversation requires all fields, but their structure must be common to both text and voice.

A simple scenario makes a good test for the design. The customer starts a chat: “Where is my delivery? Order 5421”. The bot finds the order, shows the status and informs about the delay. The customer replies that the parcel is needed the next day, so they choose the phone call option. When the agent answers the call, they should immediately see the number 5421, the current status, information about the deadline required by the customer, and the fact that the standard response did not resolve the case. They can then immediately check an alternative delivery method, instead of asking again for the order number.

Why do phone and chat in customer service often lose context?

The most common cause is technical, but its effects are procedural: the phone and text channels store data in separate systems, under different identifiers and according to different case categories. The phone number is not linked to the customer account, the chat account is not associated with the order number, and the agent's note does not return to the bot. As a result, each channel only sees its own fragment of the history.

The problem also arises when automation treats a conversation as a series of loose questions and answers. The bot may correctly answer a question about delivery cost, but it does not know whether the customer is asking before the purchase or reporting a missing delivery after the purchase. These two situations require different data, different routing and a different next action.

A second common mistake is attaching context to the channel rather than to the case. When a customer starts a conversation on the website, later calls from a work phone, or uses a different email address, automatic identification alone may not be sufficient. The system should be able to ask for an element that links the contact to the case - for example, an order number, a ticket number or a one-time code - and connect it to the history without collecting the entire set of data again from scratch.

In a well-designed process, phone and chat in customer service are simply different interfaces to one and the same service journey. This is what distinguishes a well-implemented multichannel customer service from a company simply being present in several places.

What should a good first contact with a customer look like?

A good first contact with a customer should resolve three specific issues: establish the purpose of the conversation, decide whether the bot can safely help, and indicate the next step. It should not begin with a long survey. In the first message or utterance, it is enough to ask in plain language: “How can I help: order, payment, complaint, technical support, or something else?”. If the customer describes the problem in their own words, the bot should confirm its understanding: “I understand this is about a delayed delivery for order 5421. I’ll check its status”.

The order of the questions matters. Purpose first, then only the data that is necessary to carry out the next action. If the customer wants to know opening hours, identification is not needed. If they ask to change the delivery address, it is first necessary to confirm which order is to be changed, and then verify authorisation. A first contact with the customer structured this way shortens the conversation and reduces the number of drop-offs at the data-collection stage.

What determines whether customer service automation can be considered successful?  

Customer service automation is valuable when it does not just respond, but also carries out a specific stage of the process: checks status, creates a case/ticket, suggests a date, sends a document, or hands over the case together with the data. This requires a clear division: which information the bot can retrieve from the knowledge base, which it should check in the operational system, and which must be left to the agent. Mixing up these layers incorrectly leads to answers that sound confident but are not based on current data.

At the end, the automated stage can be logged: a short summary along the lines of “I’ve checked order 5421, you requested delivery by tomorrow, and I’ve passed the case to the logistics team”. Such a message closes this stage of contact and prepares the next person to take action. Here, customer service automation does not replace the relationship with a human being, but removes the activities that do not require the case to be explained again.

When should a chatbot or voicebot hand over a case to an agent?

Handing over a case to an agent should result from specific rules, not from a general impression that the conversation is getting difficult.  

The first group of cases concerns competence: the bot does not have a reliable answer, the sources of information are contradictory, it does not have access to the required system, or a given action requires authorisation that the automation does not have. In such situations, the bot should not guess or promise to carry out an action it cannot actually perform.

The second group concerns the type of case. Topics deliberately excluded from automation, such as negotiations, individual decisions, high-value complaints, or sensitive matters, should go straight to a human.

The third group is priority: events that halt an important customer process, concern security, require a fast response, or exceed the standard service time should be routed to a separate, urgent path. Transfer alone is not enough. The precondition for quality is full conversation context passed to the agent in the form of a short, structured note. It should answer five questions: who the customer is, what the case is about, what the bot has already checked, why it did not resolve the case on its own, and what the recommended next action is. Example: “Customer: order 5421. Topic: delayed delivery. Status verified: the parcel has not been handed over to the courier. The customer needs delivery by tomorrow. Reason for escalation: request to change the delivery method. Recommendation: check in-store pickup or express delivery.”

Introducing a soft queue

It is worth implementing a “soft queue” mechanism. When a customer says “I want to speak to a human”, the bot can ask one neutral question: “Of course - what is this regarding, so I can connect you?”. If the topic can be resolved quickly through automation, a specific action can be suggested. If the customer chooses an agent again, the system should immediately transfer the case to an agent. Users should not be blocked with a series of questions just to keep them within the automation.

What should happen when an agent is unavailable

A scenario for an unsuccessful connection also needs to be designed. If an agent is unavailable, the bot cannot leave the customer without a solution. It should offer a callback, create a ticket, confirm the contact details, and pass the entire conversation context on to the team. This way, switching to a human, a queue, or a channel does not reset the case. Ultimately, it is the preserved conversation context, not the technical handover itself, that determines the quality of the escalation.

‍

How does X-TALK organise the first contact by phone and chat?

X-TALK - our AI Communication Centre, can be used to design the first line of service not around separate channels, but around specific customer processes. The starting point is a catalogue of the most common reasons for contact - for example, order status, invoice, payment, complaint, service, appointment booking or a quote enquiry. For each process, it’s worth defining four elements: what information the bot can provide, what data it should collect, which tool it should use, and when it should hand the conversation over to the chosen team.

In the AI Communication Centre, these decisions can be organised into a coherent architecture: the knowledge base is responsible for content, integrations for retrieving or saving data, routing for selecting the right queue, and escalation rules for the limits of automation. As a result, the bot isn’t just a layer of questions and answers. It becomes the first stage of the process, one that recognises the topic, triggers the right path and hands a human a prepared case when a decision is needed.

Putting communication quality first

This approach also makes it possible to control quality: it’s worth regularly checking whether the bot correctly recognises intentions, which cases end up in the wrong queues, at which stages customers repeat their questions, and whether agents receive complete summaries. Metrics shouldn’t measure only the number of automatically closed contacts. Equally important are cases resolved without having to re-explain the problem, the effectiveness of routing, and the number of escalations that end in further action rather than an abandoned contact.

A well-implemented AI Communication Centre makes it possible to maintain a consistent service logic while still giving customers the freedom to choose their channel. In this model, the customer service chatbot and voicebot work as a single first-contact system: they collect the necessary data, carry out safe steps automatically, and hand the case over to the right person fully prepared.

Summary

Combining phone and chat requires more than simply launching two bots. What's needed is a shared case card, a common data model, competency-based routing, clear escalation rules and a summary passed on to a human agent. Only then can a customer start a conversation on chat, then call, and afterwards receive a summary by SMS, without losing the history of contact.

A good automation design doesn't try to handle every conversation without human involvement. It recognises when an answer can be drawn from reliable knowledge, when data needs to be checked in the system, and when an agent's decision is required. This makes it possible to shorten simple cases without creating an artificial barrier for customers with more complex issues.

Want to try our AI Communication Centre – X-TALK? Go to: https://x-talk.me/