Запишите ожидаемый результат до теста
Этот протокол предназначен заказчику и сотруднику, который будет работать с системой. Начните с одного процесса из ТЗ. Укажите редакцию знаний, канал, подключённые инструменты, права и ответственного за оценку. Тестовая среда и данные должны быть согласованы; испытание не должно незаметно превращаться в реальные сообщения клиентам.
Разделите четыре оценки: содержание ответа, допустимость обещания, фактическое действие и доступность контекста сотруднику. Успех по одной не компенсирует провал по другой. Например, хорошая консультация не подтверждает, что запись появилась в расписании.
Используйте один короткий шаблон протокола
Таблицу можно прокрутить по горизонтали.
| Поле | Что зафиксировать |
|---|---|
| Условие | Исходное обращение, известные данные и состояние сервиса. |
| Ожидание | Ответ, допустимое действие, граница и следующий шаг. |
| Доказательство | ID записи, состояние поля, задача сотруднику или подтверждённый отказ. |
| Результат | Пройден / не пройден; наблюдение и причина. |
| Исправление | Что изменено, кто проверил повторно, редакция системы. |
Не используйте реальную переписку без необходимого основания и ограничения доступа. В большинстве приёмочных примеров достаточно обезличенных ситуаций, сохраняющих логику задачи. Пароли и токены не включают в протокол или снимок экрана.
Добавьте проверки, специфичные для каждой услуги
Таблицу можно прокрутить по горизонтали.
| Направление | Сценарий | Доказательство |
|---|---|---|
| Продажи | Клиент меняет задачу и не сообщает бюджет | Заявка отражает последние вводные и неизвестные значения без догадок. |
| Поддержка | В источниках нет правила для исключения | Нет выдуманного ответа; сотруднику передан вопрос и контекст. |
| Запись | Два клиента выбирают одно окно | Сервис допускает только разрешённую занятость; второму предложен честный выход. |
| Интеграция | Операция выполнена, но ответ потерян | Повтор узнаёт исходный результат и не создаёт лишнюю запись. |
Сюда же входят отказ клиента продолжать, просьба о человеке и работа вне смены. Для каждого состояния найдите, кто отвечает за продолжение. Автоматическое сообщение «передал» без принятой передачи оставляет процесс незавершённым.
Согласуйте критерии блокировки запуска
До тестов выберите ошибки, при которых рабочий запуск запрещён: неверные обязательства, недопустимое действие, утечка данных, двойная запись или потерянная передача. Конкретный перечень зависит от процесса и фиксируется с заказчиком. Менее критичные замечания тоже получают владельца и решение, а не исчезают из отчёта.
Проверяйте недоступность знаний, отказ API, истёкшие права и неопределённый ответ. Ограничения конкретного сервиса нужно сверять по документации и аккаунту: пример — рекомендации amoCRM по API. Не стоит переносить успешный тест одного подключения на все будущие интеграции.
Передайте команде управление и правила остановки
- Сотрудник умеет принять диалог, увидеть контекст и остановить автоматические ответы.
- Назначен владелец знаний и понятен порядок обновления.
- Есть журнал ошибок и способ вернуть предыдущую проверенную редакцию.
- Согласованы наблюдаемые метрики и исходный период.
- Запуск, границы и оставшиеся ограничения зафиксированы в приёмке.
После изменения знаний или интеграции повторяйте связанные тесты и важные прежние сценарии. Это не повод бесконечно прогонять весь набор без изменений, а способ убедиться, что конкретная правка не сломала соседнюю задачу. Расширять самостоятельность агента следует по подтверждённой готовности процесса.
Заполненный протокол трёх направлений
Таблицу можно прокрутить по горизонтали.
| ID | Провал до исправления | Изменение | Повтор |
|---|---|---|---|
| S-01 · продажи | Повтор операции создаёт две строки | Ключ операции и возврат прежнего результата | Одна запись, прежний ID |
| K-01 · поддержка | Ответ по просроченной карточке | Проверка срока и статуса источника | handoff вместо устаревшего ответа |
| B-01 · запись | Два запроса выбирают один слот | Атомарная запись с ограничением | accepted + conflict, одна бронь |
Это результаты локальных моделей правил в скачиваемом стенде. Без LLM, реального календаря и клиентских данных; до промышленного запуска нужен отдельный протокол выбранных интеграций, качества ответов и действий сотрудников.
Как повторить локальный стенд
Скачайте самодостаточный Python-стенд и выполните python3 service-demos.py. Нужен Python 3, только стандартная библиотека; сеть, CRM, LLM и внешние сообщения не используются. Скрипт проверяет продажи, знания и конкуренцию за слот, выводит JSON с before/after и проверяет результат через assert. Временная база удаляется после запуска.
Ожидается: sales — 2 строки в наивном варианте и 1 после повтора по ключу; support — answer до проверки актуальности и handoff после; booking — два успешных предварительных чтения против одной атомарной записи и конфликта. Эти узкие модели не заменяют испытания реальной системы.
Основания и источники
Примеры и расчёты — иллюстрации, а не результаты клиентов. Ссылки ниже подтверждают названные технические возможности; матрицы и критерии проверки — редакционные рекомендации ЛидПотока. Проверено 27 октября 2026.
- amoCRM: ограничения и рекомендации API
Ограничения и обработка запросов API amoCRM; критерии нашего протокола являются редакционной методикой.
- Microsoft Copilot Studio: передача диалога и контекста человеку
Передача истории и переменных в Copilot Studio при настроенном engagement hub; общий регламент передачи в статье — проектное правило.
- Локальный воспроизводимый стенд: правила повторов, знания и слоты. Не интеграция платформы.
Самодостаточная локальная модель правил: повтор операции, просроченное знание, конкурентная запись. Без LLM и внешних интеграций.