ИИ вместо большой команды: Как создавать контент, продавать и поддерживать клиентов
ИИ вместо большой команды: Как создавать контент, продавать и поддерживать клиентов

Полная версия

ИИ вместо большой команды: Как создавать контент, продавать и поддерживать клиентов

Язык: Русский
Год издания: 2026
Добавлена:
Настройки чтения
Размер шрифта
Высота строк
Поля
На страницу:
4 из 6

Факты: что обязательно включить.

Ограничения: что запрещено утверждать, обещать или менять.

Формат: длина, структура, канал, количество вариантов.

Если данных не хватает: что нужно перечислить и кому передать.

Критерии приёмки: по какому чек-листу проверить результат.

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

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

Как обратная связь превращается в новое правило

Сигнал: одна и та же ошибка повторяется после нескольких исправлений

Разовое исправление не меняет систему. Если в каждом новом тексте приходится снова удалять слово «гарантированно», проблема не в конкретной публикации. В паспорте отсутствует правило о гарантиях.

Сначала классифицируйте ошибку. Удобно использовать пять категорий.

Фактическая ошибка — неверная цена, срок, характеристика или цифра.

Ошибка источника — использован старый документ или источник с меньшим приоритетом.

Ошибка задачи — помощник не понял аудиторию, цель, формат или режим работы.

Ошибка голоса — нарушены лексика, ритм, уровень конкретики или эмоциональный диапазон.

Ошибка риска — появились обещание, юридический вывод, раскрытие данных или самостоятельное решение, которое должен принимать человек.

После классификации исправление записывается по формуле:

Фрагмент: что именно было выдано.

Тип ошибки: к какой категории она относится.

Причина: какого контекста, источника или правила не хватило.

Правило: что теперь нужно делать в подобных случаях.

Исправленный вариант: как должен выглядеть результат.

Источник или владелец: кто подтверждает правило.

Область действия: только эта задача, конкретная роль или весь проект.

Пример слабой обратной связи:

«Сделай менее рекламно и не выдумывай».

Пример рабочей обратной связи:

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

Второй вариант можно превратить в правило, проверить на новых примерах и включить в паспорт.

Не каждое замечание должно становиться постоянной нормой. Разделите изменения на три типа.

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

Обновление источника меняет факт: например, цену, срок или состав пакета.

Общее правило применяется к будущим задачам: например, запрет на слово «гарантированно» или обязательное указание условий возврата.

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

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

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

Сборка паспорта за один рабочий сеанс

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

Затем подготовьте короткую рабочую версию паспорта. Она может состоять из следующих разделов.

Название проекта и роль помощника.

Цель роли и список задач, которые она выполняет.

Описание продукта: для кого, в какой ситуации, что получает клиент и чего продукт не делает.

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

Условия: цена, состав, сроки, оплата, возврат, ограничения и источник каждого изменяемого факта.

Обещания: разрешённые результаты, осторожные утверждения и запрещённые гарантии.

Карта источников: название, владелец, приоритет, дата проверки и срок актуальности.

Голос: обращение, лексика, ритм, уровень конкретики, эмоциональный диапазон и примеры.

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

Передача человеку: перечень условий остановки и роль ответственного.

Критерии качества: отдельный чек-лист для текста, ответа и коммерческого предложения.

Обратная связь: формат замечания и место для журнала актуализации.

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

Минимальная проверка паспорта выглядит так:

1) Может ли помощник назвать текущий продукт одним предложением?

2) Понимает ли он, кому продукт не подходит?

3) Знает ли он, где брать цену и когда обязан перепроверять её?

4) Может ли отличить результат услуги от гарантии?

5) Есть ли у него примеры допустимого голоса, а не только прилагательные?

6) Понимает ли он, что делать при отсутствии факта?

7) Знает ли условия передачи задачи человеку?

8) Можно ли оценить текст по наблюдаемым критериям?

9) Понятно ли, куда заносить повторяющиеся ошибки?

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

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

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

Интерлюдия: семь дней до первого контура

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

В понедельник в 8:43 Анна открыла рабочий мессенджер и увидела тридцать одно непрочитанное сообщение. Восемь человек спрашивали о практикуме «Налоги без паники», пятеро хотели понять, подходит ли он им, двое просили прислать запись занятия, а один участник не мог войти в личный кабинет. Внизу списка ждало сообщение от Марины Сергеевой:

«Я только зарегистрировалась как самозанятая. Подскажите, мне сначала разобраться с налогами или можно сразу на практикум? И сколько он длится?»

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

Илья посмотрел на часы и сказал:

— Если сегодня начнём автоматизировать всё, завтра не поймём, что именно сломалось.

— А если выбрать только один участок, мы оставим без внимания контент и поддержку.

— На семь дней — да. Зато через семь дней получим работающий участок, а не три недоделанных.

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

День первый. Перестать принимать желания за задачи

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

— Это направления, а не операции. Покажи, что действительно происходило за последние десять рабочих дней.

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

Получился список, который выглядел не так эффектно, зато оказался гораздо полезнее.

Стоимость практикума: Илья искал последнюю цену в разных файлах и отвечал вручную.

Расписание: Анна или Илья проверяли, не изменился ли график, а затем отправляли дату и ссылку.

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

Конкретный налоговый расчёт: Илья пересылал вопрос Анне, потому что не мог проверить правовой смысл ответа.

Запись занятия: Илья проверял оплату, находил нужный материал и отправлял его.

Отзыв участника: Анна сохраняла его в отдельной заметке, но делала это нерегулярно.

Переписывание записи эфира в пост: Анна сначала сама просматривала запись, затем составляла план и снова редактировала текст.

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

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

Илья предложил зафиксировать выбор одной фразой:

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

Анна добавила:

— А контент?

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

Упражнение для первого дня

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

Для каждой операции хватит пяти строк.

Вход: что именно приходит?

Действие: что человек делает с этим входом?

Результат: какой артефакт должен остаться?

Владелец: кто проверяет и принимает результат?

Цена ошибки: что произойдёт, если ответ окажется неверным, неполным или несвоевременным?

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

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

День второй. Собирать не идеальную инструкцию, а доказательства

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

Через десять минут документ занимал две страницы. В нём были слова «экспертно», «по-человечески», «без давления» и «с заботой». Не было только одного — точного ответа на вопрос, что именно можно сообщать клиенту.

Илья попросил Анну закрыть документ и открыть рабочие материалы.

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

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

— Если дать модели всё подряд, она выберет не правду, а наиболее удобное сочетание фрагментов, — сказал Илья.

— Тогда сначала нужно собрать идеальную базу.

— Нет. Сначала нужно увидеть, где у нас самой нет единой правды.

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

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

Практикум рассчитан на самозанятых, которым нужна системная база по работе с налогами и учёту доходов.

В программе четыре недели, еженедельные занятия и записи.

Практикум не заменяет индивидуальную консультацию по конкретной ситуации и не включает представительство перед государственными органами.

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

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

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

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

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

Анна хотела включить в базу все свои посты и записи эфиров. Илья остановил её:

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

Упражнение второго дня

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

Разделяйте три типа сведений.

Факт: «В программе четыре недели».

Интерпретация: «Людям обычно удобно проходить её параллельно с работой».

Неизвестное: «Дата следующего набора ещё не подтверждена».

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

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

День третий. Настроить только один рабочий маршрут

В среду они не добавляли новых задач. Илья собрал сценарий на одном листе.

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

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

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

Илья сформулировал рабочую инструкцию без декоративных обещаний:

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

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

Анна настояла ещё на одном ограничении:

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

— Почему?

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

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

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

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

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

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

День четвёртый. Проверить систему на прошлых ошибках

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

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

Илья сразу остановил тест.

— Где она ошиблась?

Анна посмотрела на экран:

— Взяла устаревшую дату.

— Это описание ошибки. Почему она смогла её взять?

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

Они не стали писать «не доверяй старой информации». Такое правило слишком общее. Вместо этого добавили проверяемое ограничение: «Используй только документ “Условия участия — актуальная версия”. Если в нём нет ответа, не обращайся к архивным материалам и отметь необходимость уточнения».

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

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

Практика четвёртого дня

Берите для первого теста не придуманные запросы, а уже решённые и безопасные примеры. Удалите персональные сведения, оставьте только тот контекст, который действительно был нужен для ответа, и сравните черновик с отправленным вариантом.

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

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

День пятый. Устроить безопасное столкновение с живым потоком

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

Первое сообщение было простым:

«Можно ли посмотреть запись, если не получится прийти на занятие?»

Черновик получился точным. Второе сообщение звучало так:

«Я работаю с клиентами по договору. Мне точно подходит режим самозанятого? И сколько налога я буду платить?»

На страницу:
4 из 6