Как выбрать бизнес-процесс для автоматизации с помощью ИИ: критерии и проверка результата

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

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

Опишите работу до выбора инструмента

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

Границу пилота лучше сформулировать узко: «извлечь из письма тему, контакт и суть запроса, затем подготовить карточку для проверки менеджером». Формулировка «автоматизировать продажи» не подсказывает, какой результат принимать и кто за него отвечает.

Разделите операции по способу выполнения. Перенос уже заполненных полей формы в CRM сначала стоит проверить обычной интеграцией. Языковую модель имеет смысл рассматривать там, где нужно разобрать свободный текст или подготовить черновик. Расчёты и проверку обязательных полей можно оставить коду, а спорные случаи передавать человеку.

Сравните кандидатов по четырём критериям

Повторяемость. Соберите данные о числе операций за выбранный период. Частая задача с похожими входными данными удобна для сравнения. Если каждое обращение требует отдельного расследования, сначала уточните правила работы.

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

Цена ошибки. Подготовку внутреннего черновика проще ограничить проверкой перед сохранением. Отправка ответа клиенту или изменение данных в учётной системе требуют отдельных правил подтверждения. Для первого пилота выбирайте участок, где ошибку можно обнаружить и исправить до того, как она повлияет на дальнейшую работу.

Способ приёмки. Заранее определите, что считать правильным результатом. Для карточки обращения это могут быть верно извлечённый контакт, корректная тема и отсутствие сведений, которых не было в письме. Если поле пропущено, система должна показать пропуск, а не дописать правдоподобный ответ.

Эти критерии помогают обсудить задачу и с внутренней командой, и с подрядчиком. На странице AI Landmark автоматизация бизнес-процессов с помощью ИИ описана через отдельные процессы, согласование данных и проверку результата на пилоте. Такой подход удобно использовать как основу для списка вопросов перед внедрением.

Зафиксируйте исходный результат

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

Для пилота заранее запишите:

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

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

Проверьте весь путь заявки

Рассмотрим условный пример. Помощник читает письмо, выделяет контакт и тему, готовит краткое описание для CRM. Менеджер сверяет черновик с источником и подтверждает сохранение. Если контакта нет или тему нельзя определить однозначно, обращение попадает в очередь ручного разбора.

Здесь нужно проверить несколько разных результатов. Верно ли помощник прочитал письмо? Сохранилась ли карточка? Не создалась ли она повторно? Видит ли её ответственный сотрудник? Успешный ответ модели подтверждает только подготовку текста. Для записи в CRM нужно отдельное подтверждение, например идентификатор созданной карточки.

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

Считайте время с учётом проверки

Условный расчёт: ручная обработка одного обращения занимает восемь минут. С помощником сотрудник тратит три минуты на проверку и ещё две на исправления. В этом примере высвобождаются три минуты, а не пять. Числа иллюстрируют способ расчёта и не являются результатом внедрения в компании.

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

Расширять пилот стоит после того, как команда проверила результат по заранее согласованным условиям. Если карточки создаются быстрее, но сотрудники долго ищут ошибки, сначала разберите причины. Иногда полезным итогом пилота становится более узкая задача: помощник готовит краткое описание, а выбор ответственного и сохранение остаются за менеджером.

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