Когда ко мне приходят с запросом "хотим внедрить ИИ", я сначала спрашиваю не про модель. Я спрашиваю, где сейчас болит процесс.
И почти всегда всплывает одно и то же: заявки висят в Telegram, CRM заполняют вечером, потому что "днем некогда", follow-up держится на памяти менеджера, а руководитель узнает о потерянном лиде уже после того, как клиент ушел к конкуренту.
Это не вопрос к искусственному интеллекту. Это обычная операционная дырка.
ИИ здесь может помочь, но только если его встроить в процесс. Пока сотрудник вручную копирует текст в ChatGPT, получает ответ и переносит его обратно в CRM, это не автоматизация. Это ручная работа с умным помощником рядом.
Автоматизация начинается там, где событие само запускает цепочку действий: пришла заявка, система ее забрала, разобрала, подтянула контекст, обновила CRM, поставила задачу и оставила человеку только то, где правда нужен человек.
Как ИИ реально попадает в бизнес-процессы
Самый простой вариант — чат. Сотрудник открывает ChatGPT, Claude, Gemini или GigaChat, вставляет текст, просит написать ответ, сделать сводку, проверить письмо или упростить документ. Польза есть. Иногда большая. Но весь процесс все еще держится на человеке: он принес задачу, он забрал результат, он сам вставил его куда надо.
Другой режим — workflow. Здесь уже работают n8n, Make, Zapier, Pipedream, Albato и похожие платформы. Они ловят событие: заявку с сайта, письмо, сообщение в Telegram, оплату, новый файл. Потом модель анализирует данные, а сценарий делает следующий шаг: обновляет CRM, создает задачу, отправляет уведомление, готовит черновик ответа или передает случай оператору.
Есть и третий слой, который я все чаще вижу в проектах, — coding-агенты. Claude Code, Codex, Cursor, Windsurf помогают там, где готовые блоки закончились. Нужно написать обработчик webhook, поправить JavaScript в n8n, привести данные к формату CRM, разобраться с API, накидать тесты или собрать маленький внутренний сервис. Раньше такие задачи часто зависали в очереди к разработчику. Сейчас их можно быстрее доводить до рабочего прототипа.
По сути, чат помогает отдельному сотруднику. Workflow двигает заявку по системе. Coding-агент выручает, когда автоматизация почти собрана, но ей не хватает неприятного маленького куска кода.
Что изменилось с появлением n8n и AI-workflow
До workflow-платформ нейросеть чаще жила рядом с бизнесом, а не внутри него.
Менеджер получал сообщение клиента, копировал его в ChatGPT, просил ответ, переносил текст обратно, открывал CRM, ставил задачу, потом еще пытался не забыть про follow-up. Ответ стал лучше, но сам процесс не изменился: между системами по-прежнему бегал человек.
Когда в n8n появились AI-ноды, OpenAI-ноды, AI Agent, LangChain-связки, модель стало можно поставить прямо в середину сценария. Например, клиент пишет в Telegram. n8n забирает сообщение. OpenAI определяет, что это запрос на расчет стоимости. amoCRM проверяет, есть ли такой клиент. Если клиента нет, создается сделка. Если есть, сценарий добавляет комментарий в текущую карточку. Менеджеру уходит уведомление, а через сутки система проверяет, был ли follow-up.
Вот здесь меняется роль менеджера. Он уже не переносит данные между окнами. Он видит контекст и работает с клиентом.
Инструменты при этом разные. Zapier я бы брал для быстрых связок между готовыми SaaS-сервисами, когда не хочется думать об инфраструктуре. Make удобен для визуальных сценариев и быстрых прототипов, особенно если нужно показать логику не разработчику. n8n чаще выигрывает там, где сценарий начинает ветвиться, появляются свои HTTP-запросы, кодовые вставки, self-hosted и нормальный контроль над данными.
Где модель действительно нужна
Модель не стоит подключать к каждому переносу данных.
Форма на сайте может создать сделку в CRM через обычную интеграцию. Новая строка в Google Sheets спокойно уедет в Bitrix24 без всякого GPT. Письмо после оплаты тоже не требует интеллекта, если текст всегда одинаковый.
Модель нужна там, где правило уже не справляется.
Клиент пишет свободным текстом, и надо понять, чего он хочет. В договоре нужно вытащить реквизиты и проверить, не поехали ли сумма или дата. Оператору нужен черновик ответа с учетом истории клиента, а не шаблон на все случаи. Руководителю не нужна еще одна таблица: ему нужно коротко понять, почему просели заявки и где застряли сделки.
Обычная автоматизация просто передает данные. Модель помогает разобраться, что в этих данных происходит.
Что обычно автоматизируют первым
В нормальных проектах первым автоматизируют не что-то эффектное, а скучную операционку. Входящие заявки, вопросы клиентов, заполнение CRM, сводки после звонков, письма, документы, отчеты. Все то, что повторяется каждый день и незаметно съедает часы.
Типовая история: заявка приходит из WhatsApp. Модель видит, что клиент хочет расчет стоимости. Сценарий проверяет клиента в amoCRM или Bitrix24, создает сделку, отправляет менеджеру уведомление в Telegram и готовит черновик ответа.
А потом начинается реальный проект.
Телефон пришел без кода страны. В CRM похожий клиент уже есть под другим номером. Менеджер просит не создавать дубль, а добавлять комментарий в существующую сделку. Отдел продаж хочет отдельную логику для корпоративных клиентов.
На этих мелочах и видно, собрана у вас автоматизация или просто нарисована красивая схема.
В поддержке модель хорошо закрывает первичный разбор обращений. "Не пришел чек" можно обработать почти автоматически: найти заказ, проверить статус, подготовить ответ. А вот "хочу вернуть деньги, потому что услуга не оказана" лучше сразу отдать человеку. Там уже не вопрос скорости, там вопрос риска.
В маркетинге ИИ полезен не только для текстов. Например, можно собирать отзывы за неделю в Airtable, а модель будет вытаскивать повторяющиеся темы: доставка, цена, качество, интерфейс, поддержка. Маркетолог не тратит вечер на ручную сортировку, а сразу видит, где накопилось раздражение.
С документами похожая история. Письмо с PDF приходит на почту, сценарий забирает вложение, модель извлекает ИНН, сумму, дату и номер договора, сверяет с таблицей и отправляет бухгалтеру только спорные случаи. Не весь документооборот "на ИИ", а один неприятный ручной участок.
В аналитике польза появляется, когда модель не просто пересказывает цифры, а помогает увидеть сбой: заявки из WhatsApp стали хуже конвертироваться, у двух менеджеров нет следующего шага по сделкам, а время первого ответа выросло после запуска новой рекламы.
Где помогают coding-агенты
На демо no-code выглядит безобидно: блок, стрелка, блок, зеленая галочка.
В реальном проекте быстро начинается инженерная грязь.
CRM ждет один формат данных, сайт присылает другой. Webhook отдает телефон то с плюсом, то без плюса. API возвращает поле с другим названием. Интеграция падает, если email пустой. Для разных филиалов нужны разные правила, а ошибки надо куда-то логировать, иначе через неделю никто не поймет, почему половина заявок не дошла.
Раньше это часто заканчивалось фразой: "Тут нужен разработчик, но задача маленькая". И маленькая задача лежала две недели, потому что у разработки есть более срочные пожары.
Сейчас часть таких разрывов можно закрывать через Claude Code, Codex или Cursor. Я не говорю, что они заменяют разработчика. Не заменяют. Но если нужно написать функцию на 20 строк, привести JSON к нормальному виду, обработать пустые поля и не уронить сценарий, агент может сэкономить много времени.
Я бы не давал ему абстрактную задачу вроде "сделай интеграцию". Я бы давал грязный кусок реальности:
Вот что прилетает из webhook. CRM ругается. Телефон может быть пустым, email тоже. Сделай так, чтобы сценарий не падал, нормализуй телефон и верни понятную ошибку, если данных не хватает.
Такой подход не снимает ревью. Если участок касается платежей, персональных данных, прав доступа или чего-то, что может ударить по клиентам, код должен смотреть человек.
Готовый сервис, workflow или разработка
Инструмент выбирается не по модности, а по тому, насколько процесс типовой.
Если поддержка уже живет в тикетах, логично посмотреть Intercom или Zendesk AI. Если основной канал — мессенджеры и воронки, ближе Manychat, Botpress или Voiceflow. Для встреч часто проще взять Fireflies или Fathom, чем самостоятельно собирать транскрибацию, саммари и отправку в CRM.
Готовый сервис хорош скоростью запуска. Но он плохо переносит странности конкретного бизнеса: особые статусы клиентов, ручные согласования, нестандартные поля в CRM, внутренние правила, которые никто не записал, но все почему-то "должны знать".
Когда нужно связать несколько систем в один процесс, я обычно смотрю в сторону workflow-платформ. Например: сайт, CRM, Telegram, Google Sheets и модель. На первом пилоте этого часто достаточно.
Потом сценарий начинает обрастать условиями. Для новых клиентов одна логика, для текущих другая. Для корпоративных заявок отдельное уведомление. Для ошибок отдельный канал. В этот момент либо добавляются кодовые вставки и coding-агенты, либо проект уходит в нормальную разработку.
Кастомная разработка нужна, когда много внутренних данных, сложные права доступа, интеграция с 1C или ERP, поиск по документам, логи, роли, контроль качества и высокая цена ошибки. Там уже появляются LangChain или LlamaIndex, векторные базы вроде Qdrant, Pinecone, Weaviate, собственный backend и нормальная инженерная поддержка. Не потому что это "красивый стек", а потому что иначе систему потом невозможно сопровождать.
Как понять, что бизнес готов
Внедрение редко ломается на модели. Чаще оно ломается на скучных вещах.
База знаний не обновлялась полгода. CRM заполнена как попало. Никто не решил, какие ответы можно отправлять без человека. Владелец процесса появляется только тогда, когда все уже упало.
Перед автоматизацией я смотрю не на презентацию, а на реальность: есть ли повторяемый участок работы, где лежат данные, кто отвечает за правила и кто будет смотреть логи после запуска.
Например, если заявки идут из Telegram, WhatsApp и сайта, но в CRM попадает только часть, сначала надо разобраться с маршрутом заявки. Если база знаний лежит в личных сообщениях старшего менеджера, модель будет угадывать. Если никто не может объяснить, что считать горячим лидом, ИИ тоже не сможет принимать это решение нормально.
Инструкции в личных чатах, грязная CRM и устаревшая база знаний — плохой фундамент. ИИ не спасет такую систему. Он просто начнет уверенно опираться на мусор.
С чего начать
Я бы начинал с места, где процесс уже регулярно ломается.
Не надо сразу "автоматизировать продажи". Возьмите один кусок: заявка из Telegram должна попадать в CRM, получать правильный тип, менеджер должен видеть уведомление, а follow-up не должен зависеть от памяти.
Не надо сразу "внедрять ИИ в поддержку". Возьмите первичную классификацию обращений и черновик ответа по базе знаний.
Не надо сразу "делать AI-аналитику". Начните с утренней сводки по зависшим сделкам: где нет следующего шага, где клиент ждет ответ, где менеджер не двигает карточку.
Первый рабочий сценарий может быть простым: Telegram, n8n, OpenAI, amoCRM, уведомление менеджеру и проверка follow-up через сутки. Если формат данных ломается, добавляется короткая функция или coding-агент. Если ошибка может стоить денег или клиента, ставится ручная проверка. Если сценарий работает стабильно, его можно расширять.
Как считать эффект
Эффект считается не по факту "мы внедрили ИИ". Считается то, что изменилось в операции.
Оператор раньше вручную разбирал обращения по темам, а теперь проверяет только спорные случаи. Менеджер не пишет заметку после каждого звонка с нуля: транскрибация и модель создают сводку в CRM. Руководитель не собирает утренний отчет из трех систем, а получает короткое сообщение: где просели заявки, какие сделки зависли, у кого нет следующего шага.
С coding-агентами эффект другой. Они экономят время на создании и поддержке автоматизации. Мелкая API-доработка раньше могла неделю ждать разработчика. Теперь, если задача хорошо описана и контекст понятен, агент может быстро подготовить черновик функции, а человек потратит время на проверку, тесты и внедрение.
Пилот должен показать простую вещь: стало ли меньше ручной работы, меньше ошибок, быстрее реакция, понятнее контроль. И еще важнее — можно ли это поддерживать без одного героя, который помнит, куда вставил кусок JavaScript.
Если автоматизация работает только пока один энтузиаст помнит промпт для Claude Code, это не система. Это удачный эксперимент.
Риски
ИИ ошибается. Coding-агенты тоже ошибаются. Иногда убедительно.
Модель может красиво ответить клиенту и упустить важное условие. Агент может написать код, который проходит на одном примере и ломается на втором. CRM может получить неправильный статус. Сценарий может отправить сообщение не туда. База знаний может оказаться старой.
Поэтому критичные действия нельзя отпускать без контроля. Деньги, персональные данные, юридические вопросы, возвраты, скидки, блокировки, важные письма — все это должно проходить через понятные ограничения и ревью.
Нормальная схема скучная: ИИ готовит черновик, человек проверяет спорные места, сценарий пишет логи, код проходит ревью, ошибки разбираются после запуска. Зато потом есть шанс понять, что именно пошло не так, а не гадать по скриншотам из чата.
Самая опасная ошибка — ускорить плохой процесс. Компания годами делала лишние действия, потом подключила ИИ, и лишняя работа стала выполняться быстрее. А coding-агент еще аккуратно дописал для нее код.
Попробуйте собрать свою первую автоматизацию
Если после всего этого хочется не просто читать про ИИ-автоматизацию, а попробовать ее руками, начните с малого сценария: заявка, сообщение, таблица, CRM, уведомление менеджеру. Не с большой системы. С одного процесса, который уже бесит.
Для этого я сделал бот-конструктор автоматизаций. Он помогает разложить ваш процесс на шаги, понять, где нужен обычный workflow, где подключать ИИ, а где потребуется кодовая вставка или coding-агент.
Доступ к боту я даю через свой Telegram-канал. Переходите в канал, забирайте доступ и попробуйте собрать первую автоматизацию на своем реальном процессе: https://t.me/lebedew_pro