Как протестировать сценарий звонка перед изменением

Короткий ответ

Любое изменение сценария звонка — новый пункт меню, рабочие часы, текст сценария, ответ в базе знаний — может сломать что-то в другом месте. Поэтому до изменения нужно проверить шесть групп сценариев: обычный звонок, ошибочный ввод, тишина, просьба о человеке, рабочие часы и исключения, перегрузка. Для каждой группы ожидаемый результат записывается заранее и сравнивается с тестовым звонком.

Самое важное в тестировании — не само изменение, а то, чего оно не касается, — «регрессионный тест». Добавляя новое праздничное правило, нужно проверить, что VIP-правило всё ещё работает. В статье — таблица тестов, регрессионный набор и кто отвечает за процесс тестирования.

Почему «маленькое изменение» опасно

Сценарий звонка состоит из связанных правил. Если правила проверяются по приоритету, новое правило, добавленное наверх, может «скрыть» несколько правил ниже. Изменение одной фразы в приветствии может повлиять на дальнейшее поведение агента. Обновление одного ответа в базе знаний может изменить ответ на похожий вопрос. Поэтому «мы поменяли всего одну строку» — не повод отказаться от теста.

Шесть групп тестов

1. 11. ОбычныйТипичный вопрос типичного клиента: часы, цена, запись. Завершается ли сценарий как ожидалось?
2. 22. Ошибочный вводНе та клавиша, невнятный ответ, смена мысли посреди вопроса, два вопроса в одной фразе.
3. 33. ТишинаКлиент молчит или делает долгую паузу. Сколько раз агент переспрашивает и что делает потом?
4. 44. Просьба о человеке«Оператор», «человек», «0» — на каждом шаге. В рабочее и нерабочее время.
5. 55. Часы и исключенияНачало и конец рабочего дня, выходные, праздники, часовой пояс.
6. 66. ПерегрузкаНесколько звонков одновременно, операторы заняты — работает ли резервный путь.

Таблица тестов

Каждая строка теста состоит из пяти столбцов: сценарий, ввод (что говорится или нажимается), время и номер, ожидаемый результат, фактический результат. Ожидаемый результат пишется до теста — если писать после, легко сказать «так тоже нормально».

• Сценарий: праздничный день, звонок в обычное рабочее время
• Ввод: «Вы завтра работаете?»
• Время и номер: 1 января, 11:00, линия продаж
• Ожидаемо: агент называет праздничный режим и не передаёт оператору
• Фактически: записывается во время теста

Тестирование правил маршрутизации

Правила маршрутизации — самая частая зона ошибок, потому что это комбинации: время, набранный номер, номер звонящего. Пишите минимум три теста на правило: звонок, подходящий под правило, неподходящий и пограничный (например, за минуту до конца рабочего дня). Если есть симулятор, самый быстрый путь — проверить «куда попал бы этот звонок?» для всех комбинаций без реальных звонков.

Регрессионный набор

Регрессионный набор — фиксированные тесты, которые повторяются после каждого изменения. Это может быть 15–25 тестов, покрывающих важнейшие пути сценария: три самых частых типа звонков, просьбу о человеке, нерабочее время, VIP-правило, фразу экстренной ситуации. Каждый прошлый инцидент тоже добавляется в набор как тест — чтобы та же ошибка не вернулась.

Тишина и качество связи

Делайте тестовые звонки в реальных условиях, а не из тихой переговорной: с улицы, из машины, при слабом мобильном сигнале. Качество звука влияет на то, что слышит агент, и тест, пройденный в офисе, может провалиться с реальным клиентом. Особенно важен тест тишины: телефон клиента в кармане, звонок не сброшен — когда и как агент его завершает?

Процесс тестирования: кто и когда

1. 1До измененияТот, кто вносит изменение, записывает ожидаемый результат.
2. 2После измененияТесты выполняет другой человек — автор изменения может не заметить свою ошибку.
3. 3РезультатЕсли все тесты пройдены, изменение публикуется; если нет — откатывается или исправляется.
4. 4ЗаписьИзменение, результат теста и дата публикации остаются в журнале.

Иллюстративный пример: новое ночное правило

Это не реальный кейс клиента. Компания добавляет новое правило для ночных часов: после 20:00 звонки идут в ночной сценарий. Правило ставят в начало списка. Регрессионный тест показывает, что VIP-клиенты теперь тоже попадают в ночной сценарий — раньше они всегда шли дежурному менеджеру. Причина: новое правило стоит выше VIP-правила.

Исправление: VIP-правило снова поднимают наверх, тест повторяют, оба правила работают как ожидалось. Случай добавляют в регрессионный набор как тест «20:30, VIP-номер → дежурный менеджер».

План отката

Перед каждым изменением спросите: если это не сработает, как и как быстро мы вернёмся к прежнему состоянию? Предыдущая версия правила, сценария или ответа в базе знаний должна сохраняться. Публикуйте изменения в час с малым числом звонков — например, рано утром — и первый час следите за живыми звонками. Если возникла проблема, сначала откатите изменение, а не пытайтесь чинить на ходу, затем спокойно разберите причину.

Типичные ошибки

• Пропускать тест, потому что «изменение маленькое»
• Писать ожидаемый результат после теста
• Тестировать только изменённую часть и не проверять остальное
• Тестировать только из офиса, с хорошим звуком
• Забывать тесты праздников и часовых поясов

Ограничения

Набор тестов не может покрыть все реальные случаи; клиенты всегда скажут что-то неожиданное. Поэтому тесты должны работать вместе с регулярной проверкой живых звонков. Ответы разговорного агента на один и тот же вопрос могут каждый раз не совпадать дословно — в тестах смотрите на поведение (верная информация, верная передача), а не на слова.

Проверка правила в Vexvon

В Vexvon AI Call Center правила маршрутизации читаются сверху вниз по приоритету, и до публикации правило можно проверить в симуляторе: «куда попал бы звонок с этого номера в это время?» Это позволяет выполнить тесты маршрутизации без реальных звонков. Для изменений сценария и базы знаний нужны тестовые звонки; транскрипт и запись каждого звонка остаются в панели, поэтому фактический результат легко сравнить с ожидаемым.

Специальный набор тестов на галлюцинации — в статье галлюцинации голосового AI, процесс при обнаружении ошибки — в разбор инцидентов.

Первый шаг

На этой неделе напишите регрессионный набор из 15 тестов: по два-три теста из каждой из шести групп. Выполните его впервые перед следующим изменением. Другие статьи — в разделе надёжность и пилот; чтобы подготовить набор тестов вместе, свяжитесь с нами.