Skip to main content
Customer service training

Customer service role play with AI: building scenarios

"Unhappy customer, late order" is a topic, not a scenario — and with an instruction like that the AI customer behaves differently every time. This guide builds simulation scenarios for support agents: an eight-part card, the hidden detail, choosing by frequency and risk, three difficulty levels, authority limits, scenarios from real enquiries, testing and keeping the library current.

October 6, 20266 min read

Short answer

AI customer simulation for support agents starts with a well-written scenario card. The card holds eight things: who the customer is, what the problem is, the facts the agent must uncover, a hidden detail revealed only when asked, the emotional level, what the agent may and may not offer, the success criterion and the source of the correct answer. Scenarios are chosen by frequency and risk, written at three difficulty levels and tested before use. The more concrete the scenario, the more realistically the AI customer behaves and the fairer the evaluation.

What a weak scenario looks like

"Unhappy customer, late order" is a topic, not a scenario. With an instruction like that, the AI customer behaves differently every time: once it calms down after two messages, once it is never satisfied. The agent does not know what they are practising, and the evaluation swings randomly between "good" and "bad".

A good scenario gives the AI a clear role and the agent a clear task. Both sides know what counts as success.

The eight parts of a scenario card

  1. Customer"Leyla, 34, writing for the second time, at work, in a hurry."
  2. Problem"Ordered three days ago, delivery was due today, the courier has not come."
  3. Facts to uncoverOrder number, address, when the customer is at home.
  4. Hidden detail"She typed the wrong address" — revealed only when the agent checks the address.
  5. EmotionIrritated at first, calms down after a proper acknowledgement, sharpens after "please wait".
  6. AuthorityThe agent may offer a new delivery time; may not promise a refund.
  7. Success criterionThe cause is found, a new time is agreed, the customer knows what will happen.
  8. Answer sourceThe "delivery delay" rule in the knowledge base.

Which scenarios to write: frequency and risk

Build the library on two dimensions. Frequency — how often the enquiry arrives. Risk — how serious the consequence of a wrong answer is. That gives four groups:

  • Frequent and high-risk: the first scenarios to write (a payment problem, for example).
  • Frequent and low-risk: for a new agent's first day (opening hours, address).
  • Rare and high-risk: regular practice for experienced agents (a legal request, a suspected data leak).
  • Rare and low-risk: no scenario needed.

Three difficulty levels

  1. BasicThe customer states the problem clearly, is calm, gives information as soon as asked.
  2. IntermediateThe customer is vague, gets irritated once, and there is a hidden detail.
  3. HardThe customer demands something beyond authority, complains about a previous agent, changes the subject.

Writing the same problem at three levels shows a new agent's progress: strong at basic but weak at intermediate means the problem is not knowledge but clarifying skill.

Write the authority limit into the scenario

The most common mistake in a support scenario is a promise the agent has no right to make: "we'll refund you", "it will definitely arrive tomorrow". The scenario should state plainly what the agent may offer and what must go to a manager. The AI customer should test that limit — by insisting on compensation, for example. How price and promise data are protected in scenarios is covered in price and promises in training scenarios.

Writing scenarios from real enquiries

The best scenarios come from real enquiries — without personal data. Take a real conversation, replace the name, number, address and order details with invented values, and keep the structure of the problem. The customer's real phrasing — short, mixed-language, misspelt — helps the AI customer sound more convincing.

Testing before use

Each new scenario is run by two people: an experienced agent (for whom it should be easy) and the lead (who checks how the AI customer reacts to a wrong answer). Three questions: does the AI stay in role, does the hidden detail come out at the right time, does the evaluation give the expected result? Testing simulations is covered in detail in testing training simulations.

Keeping the library current

When a rule changes, the scenario must change too. If the return period went from 14 to 30 days, the old scenario will "praise" the agent for a wrong answer. Each scenario should carry a link to its answer source and the date it was last checked. Once a quarter the library is checked against the knowledge base and outdated scenarios are archived.

An illustrative example

This is an illustrative example. A bank-card support team builds a library of 12 scenarios. The frequent, high-risk group holds "card blocked", "a transaction I don't recognise" and "transfer not received". Each is written at three levels. The hidden detail in "a transaction I don't recognise": the customer lent the card to a family member but says so only when the agent asks.

In the first month most new agents miss the hidden detail at the intermediate level. The lead adds a short drill on clarifying questions, and results improve in the next cycle.

Common mistakes

  • Treating a topic as a scenario.
  • Not writing a success criterion.
  • Leaving the authority limit out of the scenario.
  • Keeping real customer data in a scenario.
  • Not updating scenarios when rules change.

Limitations

Even the best scenario does not cover every way a real customer behaves. The AI customer may step out of role or calm down sooner than it should — so scenario results must be checked on samples. A good result in simulation does not automatically become a good result in real work.

Customer profiles in Vexvon

In Vexvon AI Training, the company creates customer profiles itself: name, description, customer type, language, behaviour, a list of objections (up to 50), notes and a sample conversation standard. AI can also draft a profile from the company's own instructions and knowledge base; for a company without these, no invented profile is created. A practice session ends when the AI customer ends it, when the reply limit is reached, when the agent stops it or after 30 minutes of silence. More on AI Training.

Next step

Pick your most frequent support problem and fill in the eight-part card for it — including a hidden detail. Then have an experienced agent run it and discuss the result. For the overall concept, see AI customer service training. More articles are in the customer service training section, and we can start your scenario library together during a demo.

Live demo

Ready? Let's start

See Vexvon live in a 10-minute demo.

  • A scenario built for your business
  • A live sample call
  • A tour of the platform
Get a demoorBook a meeting

Your details are used only for the demo and to get in touch.