How customers feel about AI bots and what makes conversations easier

To assess a customer’s experience with an AI bot, check whether the bot solved their task and whether it is easy to reach a person when the bot cannot help. It also matters to introduce the assistant honestly: who is responding, what it can and cannot do, and how to reach an employee. Evidence exists that disclosing a bot’s identity reduced sales, but it came from very specific conditions and is no basis for hiding AI. In the EU, transparency requirements under the AI Act for systems that interact with people have also applied since August 2, 2026.

After reading this article, you will be able to write an honest bot greeting, define rules for handing conversations to an employee, and choose metrics that reveal customer frustration without guesswork.

What actually frustrates a customer

When a customer writes “let me talk to a real person,” check whether they encountered one of these situations.

The bot does not understand the request. The customer asks in their own words, but the bot answers a different question or offers an irrelevant menu. After two or three such replies, patience runs out.

They have to repeat themselves. The customer has already given the order number and explained the problem, but after handover the agent asks them to do it all again. Repetition feels like the company does not value their time.

The bot cannot solve the task but does not admit it. The reply sounds polite and confident, but nothing changes: the refund is not filed, the status is not found, and the conversation is formally “closed.”

There is no path to a person. There is no “contact an agent” button, it is hidden, or the bot repeatedly tries to “help on its own” before allowing a handover.

These problems can stem from a weak flow, lack of access to the required data, or a poorly designed handover. The practical takeaway: before discussing how to “present” the bot, check whether it actually helps with the scenarios for which it was launched.

What a field experiment can—and cannot—tell us

In one field experiment, more than 6,200 customers of a financial company were randomly assigned structured outbound sales calls from either a bot or a person. When the bot did not disclose what it was before the conversation, its sales were about on par with experienced employees and about four times those of inexperienced employees. Disclosing before the call that the caller was a bot was associated with a purchase-rate decline of more than 79.7%. The effect was smaller when disclosure came later and among customers with prior AI experience. Customers who knew they were speaking to a bot talked less and rated it as less knowledgeable and empathetic.

Why this result cannot be transferred to modern customer support:

• these were outbound sales calls, not inbound requests from a customer seeking help;
• it was a structured voice sales flow, not a resolution for an order problem;
• the data were collected before generative models became widespread, and people’s attitudes toward AI conversation partners may have changed since then—this is a separate question that requires new data;
• the measured outcome was a purchase, not task resolution or satisfaction.

Most importantly, the study describes how people reacted; it does not authorize misleading them. A “disclose later” strategy drawn from this experiment conflicts with Article 50 of the AI Act where it applies: the information must be provided no later than the first interaction.

What Article 50 requires: providers of AI systems intended to interact directly with people must design them so people know they are interacting with AI, unless this is obvious to an informed, attentive, and reasonable person. Those transparency obligations have applied since August 2, 2026. Whether the AI Act applies to your business, who in your chain is the system provider, and what form disclosure should take are questions for legal review. Even where the law does not directly require disclosure, hiding AI risks loss of trust when a customer discovers it.

Introducing the assistant: role, limits, and access to a person

A good bot introduction answers three customer questions before they need to ask: “Who am I talking to?”, “What can you help me with here?” and “What happens if you cannot help?”

A training example: a greeting and two conversation paths

The copy and flow below are editorial examples, not ready-to-use legal wording or a description of a real project.

Greeting:

> “I’m the service’s AI assistant. I can help find information about your order, delivery, and returns. If your question needs an employee to make a decision, I’ll pass them this conversation along with everything you’ve already told me.”

Path 1: a simple order-status question. The customer writes: “Where is my order 4512?” The bot checks that the customer is signed in and the order belongs to them, reads the status from the system of record, and replies: “The order was handed to the delivery service yesterday. It is expected on Thursday. Would you like the tracking number?” The conversation ends when the customer has an answer, not when the bot decides that “everything is clear.”

Path 2: a dispute about a return. The customer writes: “My return was denied, but the item arrived damaged.” The bot does not argue or promise a decision it has no authority to make. It asks for a few facts—the order number, what was damaged, and whether there is a photo—and explains: “An employee makes the decision about returns. I’ll pass them this conversation, the order number, and the photo, so you won’t have to repeat anything.” The agent receives a card with the information already collected and continues where the bot stopped.

In this example, the bot does not pretend to be human, states the limits of its authority honestly, and makes the handover useful rather than merely formal.

What not to put in the greeting

Some phrases sound friendly but create false expectations that later cause frustration:

• “I can help with anything.” A bot that cannot process a return is more disappointing after this promise than one that states its limits upfront.
• “I’ll connect you to a manager now,” when no agents are available. Be honest instead: “Our staff are available from 9:00 to 18:00. I’ll save your question, and they’ll reply during business hours.”
• “I understand everything” or other claims about emotions and understanding that a customer may interpret as pretending to be human.
• A long list of capabilities. Three or four common tasks are enough; the bot can offer more once it understands the request.

The bot’s name is a separate question. A bot can have a name if it does not create the impression that it is an employee. “Assistant Alice,” with the explanation “I’m an AI assistant,” is acceptable. A real person’s name and avatar without an explanation are not.

How to keep the customer in control

Customers feel comfortable when they understand what is happening and can change it. For an AI bot, that means several concrete mechanisms.

Clarify instead of guessing. If a request is ambiguous, the bot asks: “Do you mean a refund or a replacement?” rather than choosing at random.

Confirm before taking action. Before cancelling an order, changing an address, or submitting a request, the bot shows what it is about to do and asks for confirmation.

Correct information. If the bot misunderstood a number, date, or amount, the customer can correct it in one message, and the corrected value is used going forward.

Clear escalation. A path to a person is available at any time and does not require the customer to go through several bot steps. The customer knows what happens next: a live agent chat now, a reply during business hours, or a callback. If agents are unavailable, the bot says so directly instead of pretending the customer is waiting.

Honesty about uncertainty. When the bot lacks the data, it says “I couldn’t find that information” rather than making up a plausible-sounding answer.

How to measure the experience without guessing

A common trap is assuming that if the customer did not ask for a person or complain, they are satisfied. Some support platforms count a conversation as resolved not only when the customer explicitly confirms it, but also when they did not ask for an agent or respond negatively within a short period. For example, one support platform automatically marks a conversation as “assumed resolved” after three minutes if the customer has not asked for a person or responded negatively. This is useful for workload tracking, but it does not replace a satisfaction measure: the customer may simply have left.

Track several metrics together:

Compare like-for-like scenarios: order-status requests handled with and without the bot, not “the bot” overall against “agents” overall. Agents often receive more complex requests, so directly comparing their ratings with the bot’s is invalid.

How to improve the flow

Improving an AI bot means fixing specific problems in specific conversations, not generally “adjusting the tone.”

Use this sequence:

1. Collect failed conversations. Include those that ended with an agent request, abandonment, repeat contact, or complaint. Review a sample regularly across different scenarios.
2. Identify the problem type. The bot did not understand the request; lacked the required data; gave a wrong answer; lacked authority but did not hand over; or handed over without giving the agent the context.
3. Change one thing. Add a data source, change an escalation rule, or rewrite an answer for a particular request type—and record exactly what changed and when.
4. Check the effect on the same scenario. Compare before and after for the same request type and a comparable period. If the volume is small, collect data longer than you would like so a random fluctuation is not mistaken for improvement.
5. Check that nothing else got worse. A new escalation rule may reduce complaints but increase agent workload. Track that too.

A training illustration of one cycle (a fictional situation): a review finds that customers often ask for an agent after asking “when will I get my money back?” The bot cannot access return status, so it gives a generic answer about timing. The team connects the return status from the system of record and changes only this answer. A few weeks later, it compares agent requests, repeat contacts, and confirmed resolutions for this request type with the same period before the change. If agent requests fall but complaints rise, the change is reviewed rather than declared successful based on one metric.

What to change in your process

1. Rewrite the bot greeting so it states the bot’s role, limits, and how to reach a person.
2. Make agent handover available at any time and explain to the customer what happens next.
3. Pass the collected context along with the conversation so the customer does not have to repeat the story.
4. Separate confirmed and assumed resolutions in reports, and add repeat contacts and agent requests.
5. Review a sample of failed conversations every week and classify the causes.
6. Change one element at a time and check the effect in the same scenarios.
7. Ask a lawyer to assess whether Article 50 of the AI Act or other disclosure requirements apply to you and in what form.

Frequently asked questions