Запишите ожидаемый результат до теста
Выберите один процесс из задания и согласуйте тестовые данные. Запишите, какие материалы, каналы, подключения и права будут использоваться. Со стороны заказчика нужен сотрудник, который знает реальные обращения и может оценить результат.
Проверяйте отдельно ответ клиенту, допустимость обещаний, действие в сервисе и сведения для сотрудника. Например, хорошая консультация ещё не подтверждает, что визит появился в расписании.
Записывайте результаты в одну таблицу
Таблицу можно прокрутить по горизонтали.
| Поле | Что зафиксировать |
|---|---|
| Условие | Исходное обращение, известные данные и состояние сервиса. |
| Ожидание | Ответ, разрешённое действие и следующий шаг. |
| Доказательство | ID записи, состояние поля, задача сотруднику или подтверждённый отказ. |
| Результат | Пройден / не пройден; наблюдение и причина. |
| Исправление | Что изменено, кто проверил повторно, редакция системы. |
Не используйте реальную переписку без необходимого основания и ограничения доступа. В большинстве приёмочных примеров достаточно обезличенных ситуаций, сохраняющих логику задачи. Не записывайте пароли и токены в отчёт и не оставляйте их на снимках экрана.
Какие проверки нужны вашей задаче
Таблицу можно прокрутить по горизонтали.
| Направление | Сценарий | Доказательство |
|---|---|---|
| Продажи | Клиент меняет задачу и не сообщает бюджет | Заявка отражает последние вводные и неизвестные значения без догадок. |
| Поддержка | В источниках нет правила для исключения | Нет выдуманного ответа; сотруднику передан вопрос и контекст. |
| Запись | Два клиента выбирают одно окно | Сервис допускает только разрешённую занятость; второму предложен честный выход. |
| Интеграция | Операция выполнена, но ответ потерян | Повтор узнаёт исходный результат и не создаёт лишнюю запись. |
Сюда же входят отказ клиента продолжать, просьба о человеке и работа вне смены. Для каждого состояния найдите, кто отвечает за продолжение. Автоматическое сообщение «передал» без принятой передачи оставляет процесс незавершённым.
При каких ошибках запуск откладывают
До тестов выберите ошибки, при которых рабочий запуск запрещён: неверные обязательства, недопустимое действие, утечка данных, двойная запись или потерянная передача. Конкретный перечень зависит от процесса и фиксируется с заказчиком. Менее критичные замечания тоже получают владельца и решение, а не исчезают из отчёта.
Проверьте недоступность знаний, отказ API, истёкшие права и ответ, по которому непонятно, выполнилась ли операция. Сверяйтесь с документацией выбранного сервиса, например с рекомендациями amoCRM. Успешный тест одного подключения не проверяет остальные.
Что передать команде перед запуском
- Сотрудник умеет принять диалог, увидеть контекст и остановить автоматические ответы.
- Назначен владелец знаний и понятен порядок обновления.
- Есть журнал ошибок и способ вернуть предыдущую проверенную редакцию.
- Согласованы наблюдаемые метрики и исходный период.
- Результаты проверки и оставшиеся ограничения записаны и согласованы.
После изменения знаний или интеграции повторяйте связанные тесты и важные прежние сценарии. Это не повод бесконечно прогонять весь набор без изменений, а способ убедиться, что конкретная правка не сломала соседнюю задачу. Расширять самостоятельность агента следует по подтверждённой готовности процесса.
Примеры ошибок и повторных проверок
- Продажи: повторите отправку после ошибки. В CRM должна остаться одна заявка с прежним подтверждением.
- Поддержка: задайте вопрос по устаревшей инструкции. Агент должен передать его сотруднику, пока правило не проверено.
- Запись: отправьте две заявки на одно время. Должна сохраниться допустимая занятость, а второй клиент должен получить другой вариант.
После исправления повторите исходную ситуацию и соседние сценарии. Оценивайте подключение, которое будет работать в проекте: учебная демонстрация не заменяет его проверку.