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