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

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

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

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

В таких случаях продавец не должен «сохранять лицо» за счёт уверенного ответа. Надёжнее зафиксировать неизвестное, назвать следующий шаг и назначить владельца.

Сервисный помощник: отвечать по базе и вовремя останавливать автоматизацию

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

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

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

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

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

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

Что изменилось после разделения

После создания четырёх контуров тот же кейс стал выглядеть иначе.

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

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

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

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

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

Три развилки, которые проверяют архитектуру

Если в команде нет четырёх отдельных сотрудников

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

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

Если источники противоречат друг другу

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

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

Если обращение выглядит срочным и эмоциональным

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

Чем выше цена ошибки, тем короче должна быть автономная часть маршрута.

Матрица ответственности

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

Аналитик. ИИ группирует данные, ищет повторения, показывает пропуски и формулирует гипотезы. Сотрудник проверяет выборку, подтверждает применимость вывода и выбирает способ проверки. Руководитель утверждает эксперименты и изменения процесса.

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

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

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

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

Служебные скрипты для передачи

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

Для аналитика:

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

Для редактора:

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

Для продавца:

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

Для сервиса:

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

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

Ошибки, которые разрушают разделение

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

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

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

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

Пятая ошибка — не назначать владельца окончательного решения. Фраза «передать ответственному» бесполезна, если не указано, кто это, в каком статусе передача считается выполненной и через какое время проверяется результат.

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

Практическая проверка для команды

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

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

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

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

Промпт как рабочее задание

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

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

Одна строка, три разных результата

В рабочем чате появляется просьба:

«Сделайте хороший текст о новом тарифе. Коротко, понятно и продающе».

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

Если ту же просьбу получают три исполнителя, появляются три несовместимых результата.

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

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

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

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

Хороший промпт в бизнес-процессе — не удачная фраза для получения красивого ответа. Это воспроизводимое задание: кто действует, зачем, на каких данных, в каких границах, в каком формате и по каким признакам результат принимается или передается человеку на доработку.

Если результат нельзя проверить без устного объяснения автора, задание еще не готово к автоматизации.

Просьба, задача и операционная роль

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

Задача описывает одну операцию с определенным входом и выходом.

Например:

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

В таком задании уже определены объект работы, аудитория, этап воронки, источник фактов, канал, объем и правило для неизвестных данных.

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