На консультацию по автоматизации полезно принести описание процесса, обычный и сложный примеры, а также желаемое изменение. Это помогает сравнить настройку процесса, готовый сервис, интеграцию и собственную разработку, а затем выбрать следующую проверку.
На разговор о внедрении AI лучше приходить с работой, которая не устраивает, а не с готовым названием технологии. «Заявки теряются между почтой и CRM» даёт больше материала для решения, чем «хотим мультиагентную систему».
Разберите один недавний случай
Покажите, как задача появляется и где заканчивается. Кто получает сообщение, какие сведения уточняет, что переносит в программу и кто принимает результат? Если в процессе участвуют три отдела, не нужно рисовать всю компанию: достаточно проследить один типичный случай через границы между ними.
Рядом положите трудный случай. Он выявит ограничения: отсутствующее поле, нестандартный договор, клиента без истории, недоступную интеграцию. Иногда типичная работа автоматизируется легко, а исключения требуют внимательного участия человека. Это нормально, если они известны и для них предусмотрен путь.
Часть материалов можно обезличить. На первом разговоре редко требуется полная клиентская база или доступ к рабочему серверу. Достаточно увидеть структуру, решения и место потери времени. Не передавайте пароли в брифе: наличие доступа обсуждают отдельно от описания задачи.
- 01Вход. Откуда приходит задача и чего в ней не хватает.
- 02Действия. Что переносит сотрудник и какие решения принимает.
- 03Результат. Где видно качество: запись, дубль, потерянное поле.
Условный процесс из статьи. Подсвечены вопросы для разговора, а не обнаруженные дефекты конкретной компании.
Сформулируйте, что хочется изменить
Проблема может быть в скорости, качестве, нагрузке, доступности вне рабочего времени или неудобстве клиента. Эти цели требуют разных решений. Автоматический ответ за несколько секунд не поможет, если сотруднику затем приходится заново собирать сведения.
Попробуйте закончить фразу: «После изменения человек сможет…». Например, увидеть все заявки с ответственными, получить ответ по действующему регламенту или оформить заказ без повторного звонка. Затем спросите, по какому наблюдаемому признаку станет ясно, что это произошло.
Если цели конфликтуют, расположите их по важности. Самая короткая обработка может ухудшить точность; максимальная автономность — усложнить контроль. Открытый разговор о компромиссах полезнее обещания одновременно улучшить все показатели.
- АИзменить процесс. Убрать лишний шаг или уточнить ответственность.
- БВзять готовое. Подобрать продукт с нужной интеграцией.
- ВСобрать своё. Ограниченная автоматизация или полноценная разработка — по задаче.
Дерево альтернатив, не автоматический алгоритм принятия решения.
Четыре решения, которые стоит сравнить
Первое — изменить сам процесс: убрать лишний этап, назначить владельца, исправить форму. Второе — использовать готовый продукт с подходящей интеграцией. Третье — собрать ограниченную автоматизацию из известных действий. Четвёртое — разрабатывать собственный сервис, если задача и ограничения этого требуют.
AI может быть частью любого из последних трёх решений. Его наличие не определяет ценность проекта. Если ответ полностью задаётся правилом и таблицей, обычная программа будет проще проверяться. Если входящие формулировки разнообразны и нуждаются в интерпретации, модель может закрыть полезный участок работы.
Сравнивать нужно полный путь пользователя, а не отдельный экран. Готовый сервис без нужных прав доступа или экспорта данных может оказаться неудобнее небольшой собственной интеграции. Собственная разработка, в свою очередь, создаёт обязательства по сопровождению и не должна выбираться ради самого владения кодом.
Какие вопросы нельзя оставлять «на потом»
- Кто принимает результат и вправе менять процесс?
- Какие данные доступны, где они находятся и кто отвечает за их качество?
- Что система может делать сама, а что только предлагать?
- Как обрабатывается ошибка, повтор запроса и отказ внешней системы?
- Кто будет поддерживать решение и оплачивать регулярные расходы?
Необязательно знать все ответы заранее. Полезно отличать известный факт от предположения: «у CRM есть API» и «у нас есть разрешение использовать нужные методы» — разные утверждения. Проверка одного такого предположения иногда меняет объём проекта сильнее, чем выбор модели.
Что считать результатом разбора
Хороший разбор оставляет понятную следующую проверку. Это может быть изучение интеграции, очистка документов, прототип интерфейса или ограниченный AI-пилот. Иногда правильное решение — пока не разрабатывать: сначала измерить объём задач или исправить правила внутри команды.
Следующий шаг должен иметь вопрос, входные данные и признак завершения. «Сделать AI» — не шаг. «Проверить, можно ли из обезличенных обращений правильно собрать обязательные поля без выдуманных значений» — шаг, который можно оценить и принять.
После разговора должно стать понятнее, что проверить первым, кто это делает и какой ответ нужен. У сложного процесса останутся открытые вопросы; полезный итог — превратить хотя бы главные из них в конкретную работу с понятным результатом.
Пример следующего шага после разговора
В компании заявки приходят по почте, а менеджер вручную переносит их в CRM. На консультации выясняется, что часть писем не содержит контакта, а по одному клиенту встречаются дубли. Следующим шагом может быть проверка трёх операций: извлечь известные поля, найти возможное совпадение, подготовить черновик карточки.
Для проверки нужны примеры писем и доступ к тестовой интеграции. Ответственный сотрудник оценивает поля и совпадения. Решение о разработке принимается после этого, а не на основании обещания автоматизировать переписку целиком. Такой результат обсуждения можно объяснить команде и заложить в план работ.