Бизнес на автопилоте: ИИ для контента, продаж и клиентского сервиса

Понятно ли, где работа заканчивается?

Назван ли актуальный источник данных?

Есть ли человек, который проверяет результат?

Отделены ли обычные случаи от исключений?

Зафиксированы ли цена и последствия ошибки?

Есть ли значения времени, конверсии, стоимости и числа сбоев до запуска?

Понятно ли, при каком сигнале система должна остановиться?

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

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

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

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

Карта бизнеса без тумана

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

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

Мифы, которые мешают увидеть маршрут

Миф первый: если в компании есть CRM, путь клиента уже описан.

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

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

Миф второй: путь клиента начинается с лида и заканчивается оплатой.

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

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

Миф третий: сначала нужно описать весь бизнес, а уже потом автоматизировать.

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

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

Миф четвёртый: узкое место находится там, где больше всего работы.

Самая загруженная роль не обязательно задерживает маршрут. Проблема часто возникает на стыке двух ролей. Маркетинг передал заявку в продажи, продажи передали неполный бриф аналитику, аналитик вернул запрос на уточнение в продажи, а клиент тем временем ждёт. Каждое подразделение чем-то занято, но сам маршрут стоит.

Похожая ситуация возникает между каналами. В мессенджере вопрос уже задан, но в таблице нет записи. В таблице запись есть, но без ссылки на исходную переписку. В CRM создана карточка, а ответ клиенту остался в личном телефоне. Каждая система содержит часть истории, а ответственность оказывается распределена между всеми — и никем.

Миф пятый: искусственный интеллект сам восстановит недостающие правила.

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

Неописанный процесс превращается в сценарий для ИИ, который никто заранее не проверил. Модель заполнит пробел правдоподобным текстом, но правдоподобный текст не равен корректному решению.

Правильная единица анализа — переход

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

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

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

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

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

Статус — текущее состояние маршрута. Хороший статус позволяет понять, что уже сделано и чего ждут дальше. «Ожидаем данные от клиента» полезнее, чем «в работе». «Предложение отправлено» полезнее, чем «думаем».

Решение — развилка, которая меняет маршрут. Клиент подходит или не подходит. Данных достаточно или нужно уточнение. Запрос стандартный или требует технической оценки. Предложение принято, отклонено или осталось без ответа. Такие решения нельзя оставлять внутри головы конкретного сотрудника.

Роль — не обязательно должность. Это тот, кто отвечает за результат перехода. Маркетинг отвечает за источник и соответствие обещания реальному продукту. Продажи — за первичный контакт и квалификацию. Аналитик или инженер — за оценку нестандартной задачи. Сервис — за запуск и результат. Владелец задаёт правила исключений и получает эскалации, а не забирает себе каждую операцию.

Система фиксации — место, где сохраняется актуальное состояние маршрута. Это может быть CRM, структурированная таблица или другой рабочий реестр. Переписка в мессенджере может оставаться каналом общения, но не должна быть единственным хранилищем статуса.

Срок отсчитывается от конкретного триггера. Не «быстро ответить», а «в течение 30 минут в рабочее время после появления нового обращения». Не «передать в сервис», а «в день подтверждения оплаты создать задачу запуска и прикрепить согласованный объём работ».

Возможная потеря показывает, где маршрут может оборваться. Это не обязательно уже доказанная проблема. Если подтверждения пока нет, формулировка должна описывать наблюдаемый сигнал: «в пяти карточках нет даты первого ответа», а не звучать как обвинение: «продажи не отвечают».

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

Минимальная карта одного этапа выглядит так.

Вход: новое обращение из публикации или рекомендации.

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

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

Статус: «новое», «контакт установлен», «ожидаем данные», «квалифицировано», «не подходит».

Решение: можно ли передавать задачу на подготовку предложения.

Роль: администратор или менеджер продаж.

Система фиксации: единый реестр обращений.

Срок: первый ответ в рабочее время в течение 30 минут, квалификация — до конца следующего рабочего дня.

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

Эскалация: если ответ не отправлен в установленный срок, уведомление получает руководитель продаж; если клиент прислал данные, а статус не изменён, задача возвращается владельцу этапа.

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

Упражнение: восстановить десять последних маршрутов

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

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

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

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

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

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

Карту задержек и повторной работы составьте отдельно. Разделяйте факт, сигнал и гипотезу.

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

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

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

Потеря маршрута. Если обращение есть, а следующего статуса или результата нет, сверьте канал входа с реестром. В карту добавьте контроль отсутствующих статусов.

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

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

Разбор маршрута: как заявка исчезает между ролями

Рассмотрим учебный кейс без привязки к конкретной компании. Компания оказывает услуги по настройке управленческой отчётности и сопровождению отдела продаж. Лиды приходят из экспертных публикаций и по рекомендациям. В маршруте участвуют маркетинг, продажи, аналитик, сервис и владелец бизнеса.

За рабочий месяц для разбора взяли 24 обращения: 15 пришли после публикаций, 9 — по рекомендациям. В пяти случаях источник не внесли в рабочий реестр. В двух обращение сохранилось только в переписке. Ещё три записи оказались дублями: клиент написал в мессенджере, а затем заполнил форму, но связь между обращениями никто не установил.

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

В 16 карточках была указана дата первого ответа. В пяти случаях ответ отправили позже установленного командой срока, хотя внутри команды считали, что «среагировали в тот же день». В трёх случаях клиенту задали вопросы, но не обозначили, когда ему вернутся с дальнейшим предложением. Поэтому обращение получило статус «в работе» и не попало ни в список ожидания клиента, ни в список задач продаж.

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

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

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

Реконструкция позволила не искать виновного. Она показала пять отсутствующих правил.

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

Второе: квалификация считается завершённой не после разговора, а после заполнения обязательного брифа.

Третье: аналитик принимает задачу только при наличии заранее определённого набора данных. Если чего-то не хватает, статус меняется на «нужны уточнения», а не остаётся «в работе».

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

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

Карту этого маршрута можно записать следующим образом.

Публикация или рекомендация. Входом служат материал, ссылка или рекомендация. Маркетинг фиксирует источник и обещанный результат. Выход — обращение с меткой источника. Переход запускает поступившее сообщение или форма. Статус: «источник зафиксирован». Решение: относится ли запрос к услуге. Роль — маркетинг. Система фиксации — реестр источников и обращений. Срок — до появления обращения. Потенциальная потеря — источник не определён. Если обращение осталось без источника, его проверяют в рамках еженедельного просмотра.

Обращение. Входом могут быть сообщение, форма или звонок. Администратор или менеджер создаёт карточку, отвечает клиенту и назначает владельца. Выход — контакт с зафиксированным следующим шагом. Переход возможен, когда в карточке есть контактные данные и канал связи. Статусы: «новое» и «контакт установлен». Решение: можно ли продолжать общение. Система фиксации — CRM или единая таблица. Срок — до 30 минут в рабочее время. Потенциальная потеря — скриншот остался в чате. Через 20 минут система напоминает исполнителю, а после нарушения срока уведомление получает руководитель.

Квалификация. Входом служат контакт и описание задачи. Продажи задают обязательные вопросы и заполняют бриф. Выход — полный бриф или зафиксированная причина отказа. Переход запускается после заполнения обязательных полей. Статусы: «ожидаем данные», «квалифицировано», «не подходит». Решение: соответствует ли запрос профилю компании. Роль — продажи. Система фиксации — карточка и бриф. Срок — до конца следующего рабочего дня. Потенциальная потеря — повторный сбор данных. Если клиент ответил, а статус не изменён, задача эскалируется.

Предложение. Входом служит полный бриф. Продажи и аналитик рассчитывают решение, готовят и отправляют предложение. Выход — документ с ценой, сроком и составом работ. Переход запускается после отправки предложения. Статусы: «готовим», «отправлено», «ожидаем решение». Решение: достаточно ли стандартного решения или требуется индивидуальная оценка. Система фиксации — карточка, расчёт и предложение. Срок подготовки стандартной задачи — один рабочий день. Потенциальная потеря — задача возвращена из-за пробела в брифе. Если срок приближается, руководитель получает сигнал.

Оплата. Входом служит принятое предложение. Администратор или владелец фиксирует оплату и создаёт задачу запуска. Выход — запись об оплате, связанная с заказом. Переход запускается после подтверждения платежа. Статусы: «ожидаем оплату», «оплачено». Решение: можно ли запускать работы. Система фиксации — финансовый реестр и карточка клиента. Срок — день подтверждения оплаты. Потенциальная потеря — платёж не связан с проектом. Неопознанные платежи владелец проверяет в тот же день.

Сервис. Входом служат оплата и согласованный объём работ. Сервис или аналитик передаёт данные, проводит запуск и выдаёт первый результат. Выход — план работ и подтверждённый результат. Переход запускается после создания задачи запуска. Статусы: «запуск», «в работе», «результат принят». Решение: нужна ли корректировка или эскалация. Система фиксации — карточка проекта и журнал результата. Срок запуска — следующий рабочий день. Потенциальная потеря — клиент ждёт начала, а сервис не получил контекст. При нарушении срока подключается руководитель сервиса.

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

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

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

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

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

Сервисная карта и стандарты, которые удерживают маршрут

Карта показывает, как происходит движение. Сервисный стандарт задаёт, как оно должно происходить в пределах конкретного срока и формата.

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

Для нового обращения стандарт может выглядеть так: «Если в рабочее время появилась новая заявка с контактными данными, администратор отвечает в течение 30 минут, фиксирует источник, назначает владельца и отправляет клиенту информацию о следующем шаге. Если через 20 минут ответа нет, система напоминает владельцу; после нарушения срока уведомление получает руководитель продаж».

Для предложения: «Если квалификационный бриф заполнен полностью, продажи или аналитик готовят предложение за один рабочий день. Результат содержит состав работ, цену, срок, ограничения и способ подтверждения. Если расчёт не готов к концу дня, статус меняется на “оценка задерживается”, а клиент получает согласованный срок следующего сообщения».

Для сервиса: «Если оплата связана с карточкой заказа, в тот же день создаётся задача запуска. Она содержит объём работ, обещанный срок, контактное лицо, доступы и первый результат. Если хотя бы одного элемента нет, проект не получает статус “запущен”; задача возвращается владельцу передачи».

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