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