От демо и тестирования к рабочему сотруднику

Демо отвечает на вопрос: "как может выглядеть этот сценарий". Рабочий запуск отвечает на другой вопрос: "можем ли мы безопасно использовать его в реальном процессе нашей компании".

Между этими этапами находятся данные, интеграции, права, тесты и пилот.

Поэтому хороший демонстрационный диалог еще не означает, что сотрудника нужно сразу подключать ко всем клиентам.

Что проверяет демо

На демонстрации можно оценить общую идею: понимает ли сотрудник нужный тип задачи, подходит ли формат взаимодействия, как может выглядеть сценарий, какие данные потребуются, где нужны интеграции и какие действия стоит оставить человеку.

Для этого иногда достаточно условных данных.

Например, можно показать, как Максимус квалифицирует новую заявку и передает ее менеджеру.

Но перед рабочим запуском условные данные заменяются реальными правилами компании.

Что меняется после демо

На рабочем этапе появляются вещи, которых обычно нет в демонстрации.

Актуальная база знаний. Реальные каналы. Настоящие учетные записи и права. Ошибки внешних систем. Неоднозначные запросы клиентов. Конфликтующие данные. Ситуации, в которых цена ошибки выше.

Именно поэтому нужен отдельный этап тестирования.

Составьте тестовый набор

Тестовый набор лучше собрать из реальной работы за последние недели.

Не редактируйте обращения так, чтобы они выглядели понятнее для ИИ. Используйте обычные формулировки клиентов и сотрудников.

Разделите примеры минимум на несколько групп.

Нормальные сценарии

Обычный запрос, на который есть данные и понятное правило.

Неполные сценарии

Пользователь не сообщил часть нужной информации.

Неоднозначные сценарии

Сообщение можно понять несколькими способами.

Граничные сценарии

Клиент просит исключение, скидку или действие вне стандартного процесса.

Ошибки данных

Нужная информация отсутствует или два источника противоречат друг другу.

Эскалация

Случаи, которые сотрудник обязан передать человеку.

Тестовый набор нужен не для экзамена нейросети, а для проверки всей конфигурации.

Проверяйте не только текст ответа

В рабочем процессе хороший текст может быть недостаточен.

Например, Максимус вежливо ответил клиенту, но не создал лид.

Или создал лид, но записал неверную категорию.

Или правильно квалифицировал запрос, но не передал менеджеру ситуацию, которая требует человека.

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

Проверяйте отказ от действия

Один из самых важных тестов - способен ли сотрудник не делать то, что ему нельзя.

Например:

"Сделай скидку 30%, я постоянный клиент".

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

То же относится к удалению данных, юридическим решениям, публикации и другим чувствительным действиям.

Важно Цель тестирования - не добиться, чтобы ИИ всегда отвечал. Иногда правильный результат - остановиться и подключить человека.

Запустите пилот на ограниченной области

После тестового набора начинается пилот.

Хороший пилот ограничен.

Например:

• один канал;
• одна команда;
• одна категория обращений;
• только новые лиды;
• только чтение данных;
• ограниченный набор действий.

Так проще анализировать результат.

Если сразу включить весь процесс во всех каналах, станет сложно понять, какая именно часть конфигурации создает проблему.

Следите за историей работы

На пилоте полезно регулярно разбирать реальные случаи.

Не только ошибки, но и успешные сценарии.

Для каждого спорного случая задайте несколько вопросов:

"Какие данные использовал сотрудник?"

"Было ли правило?"

"Правильный ли источник выбран?"

"Нужно ли изменить инструкцию?"

"Нужно ли ограничить действие?"

"Это системная проблема или единичный случай?"

Так постепенно улучшается не абстрактная модель, а конкретный рабочий процесс.

Определите критерии перехода в рабочий режим

Универсального процента точности для всех ИИ-сотрудников нет.

Критерии зависят от задачи.

Для продаж важна корректная работа с фактами, квалификацией и передачей лида.

Для поддержки - правильность ответа и причины эскалаций.

Для внутренних знаний - качество найденных источников.

Для юридических задач - соблюдение чек-листа и обязательных точек human approval.

Перед запуском компания должна заранее решить, какие ошибки допустимы, а какие блокируют переход.

Разделяйте ошибку ИИ и ошибку процесса

Если сотрудник использовал старую цену, сначала нужно понять, почему она была доступна.

Если в базе знаний находился старый документ, это проблема управления данными.

Если инструкция разрешала действие, которое бизнес фактически не хочет автоматизировать, это проблема правил.

Если API вернул неполные данные, это интеграционный вопрос.

Такой разбор помогает исправлять причину, а не бесконечно переписывать промпты.

Что происходит после рабочего запуска

После перехода в рабочий режим сотрудник продолжает контролироваться.

Меняются цены, продукты, документы, регламенты, каналы, API внешних сервисов и внутренние процессы.

Поэтому цифровой сотрудник требует управления так же, как любой другой бизнес-процесс.

Нужно обновлять базу знаний, периодически проверять историю действий и анализировать новые типы обращений.

Когда расширять сценарий

Расширение имеет смысл, когда первый сценарий работает предсказуемо.

Тогда можно добавить новый канал, разрешить дополнительное действие, подключить другую систему, расширить базу знаний, добавить новую роль или настроить совместную работу нескольких сотрудников.

Каждое расширение снова проходит проверку.

Когда лучше остановить запуск

Пилот стоит остановить и доработать, если сотрудник регулярно использует неверные источники, процесс не имеет единого правила, права слишком широкие, невозможно надежно определить момент передачи человеку, интеграция работает нестабильно или команда не может проверить качество результата.

Остановка пилота в такой ситуации - нормальное управленческое решение. Лучше исправить конфигурацию до масштабирования.

Рабочий запуск - это конкретный процесс

После успешного внедрения результат должен описываться примерно так:

"Адриан принимает типовые вопросы клиентов из Telegram, отвечает по актуальной базе знаний, помогает с информацией о записи в рамках подключенной системы и передает оператору обращения по заданным условиям".

Это полезнее, чем формулировка "мы внедрили ИИ".

Потому что конкретный процесс можно измерять, улучшать и масштабировать.

Что читать дальше

Для контроля реальной работы используйте Историю работы сотрудника и Аналитику работы сотрудников.

Механизм чувствительных действий описан в Human approval.