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

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

Анна хотела переписать всю инструкцию. Илья остановил её:

— Сценарий не должен уметь отвечать на этот вопрос. Он должен уметь его распознавать и передавать.

Развилка стала такой.

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

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

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

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

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

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

В 16:30 три обращения всё ещё стояли без движения.

— Где она ошиблась? — спросила Анна, имея в виду систему.

— В этот раз система не ошиблась, — ответил Илья. — Ошиблась передача. У черновика не было владельца.

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

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

День шестой. Проверить не только качество, но и передачу

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

Факт взят из актуального источника.

Ответ закрывает именно заданный вопрос.

В нём нет выдуманных дат, цен и обещаний.

Рискованный запрос правильно передан человеку.

В конце есть понятное следующее действие.

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

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

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

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

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

День седьмой. Зафиксировать рабочую версию, а не объявлять победу

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

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

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

Илья оформил первый контур как короткий паспорт.

Название сценария: первый ответ на входящий вопрос о практикуме.

Вход: обезличенный текст сообщения и доступный контекст.

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

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

Владелец очереди: Илья.

Владелец налоговых и спорных вопросов: Анна.

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

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

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

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

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

Три провала, которые нужно сохранить в системе

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

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

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

При разборе любого сбоя Илья возвращал разговор к трём вопросам.

Контекста не хватило?

Задача оказалась шире, чем нужно?

Не был назначен человек, который принимает результат?

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

План, который можно повторить

В первый день найдите реальные повторяющиеся операции и выберите одну.

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

В третий опишите один маршрут: вход, обработка, выход, границы, критерии и владелец.

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

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

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

В седьмой проведите смешанный тест, разберите провалы и оформите паспорт рабочей версии.

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

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

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

Голос бренда из головы основателя

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

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

Когда правильный текст звучит неправильно

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

Черновик начинался так:

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

Анна прочитала текст на телефоне, поставила три красные пометки и написала Илье: «Правильно, но я так не говорю».

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

Илья позвонил Анне.

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

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

— В одном я говорю на ходу, в другом отвечаю клиенту, в третьем разбираю чужую ошибку. Они же разные.

— Разные ситуации, но человек один. Если признаки повторяются, мы их увидим.

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

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

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

Не архив, а выборка

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

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

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

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

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

К голосовой заметке Илья добавлял короткую карточку:

Ситуация: после консультации с начинающим специалистом.

Вопрос клиента: «Мне нужно что-то делать с каждым переводом или только с оплатой за работу?»

Что объясняет Анна: сначала различить назначение операции, затем проверить применимые правила и только после этого выбирать действие.

Граница: нельзя делать вывод по одному слову в назначении платежа.

Результат: клиент прислал описание ситуации без лишних деталей и получил список вопросов для проверки.

Эта карточка была нужна не для красоты. Расшифровка показывает, что сказала Анна. Карточка объясняет, зачем она это сказала и в каком контексте. ИИ без контекста легко превратит частное объяснение в универсальный совет.

Голосовые заметки

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

«Ну, здесь человек опять пытается решить всю задачу одним прыжком. Он спрашивает: “Мне теперь каждый перевод проверять?” А у него на самом деле три разных вопроса. Первый — за что пришли деньги. Второй — когда именно они пришли. Третий — что он уже оформил, если вообще что-то оформил. Я бы не начинала с длинного объяснения. Сначала попросила бы его описать одну операцию. Одну, не всю историю за год. Тогда становится понятно, где действительно нужна проверка, а где человек просто испугался незнакомого слова».

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

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

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

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

Переписки

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

Несколько фраз Илья вынес отдельно:

«Я не понимаю, я уже должна что-то делать или пока просто ждать?»

«Мне страшно нажать не туда, потому что потом я не найду, как исправить».

«Я запуталась, где у меня доход, а где просто перевод от знакомого».

«Если клиентов мало, мне вообще нужен весь этот практикум?»

«Я хочу один раз разложить всё по полочкам и не открывать каждый вечер разные статьи».

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

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

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

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

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

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

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

Консультации и разборы

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

В одном из разборов она сказала:

«Я бы не называла это ошибкой, пока мы не посмотрели, что именно произошло. Пока у нас есть только ваше ощущение, что “что-то не так”. Оно может быть полезным сигналом, но это ещё не факт. Давайте отделим событие от вывода».

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

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

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

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

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

Факты, оценки и гипотезы

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

Они ввели три статуса.

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

Профессиональная оценка — вывод Анны, основанный на опыте и практике, но не универсальное правило.

Гипотеза — предположение, которое пока требует проверки.

Например, к фактам относились такие записи:

«В практикуме четыре занятия и один групповой разбор вопросов».

«Условия участия опубликованы на странице продукта и действуют с указанной даты».

«При подготовке материалов по налогам сведения, зависящие от даты, проверяются по актуальным официальным источникам, в том числе по материалам ФНС».

К профессиональным оценкам относились следующие:

«Начинающему специалисту проще разобрать одну типовую операцию, чем сразу изучать всю систему».

«Если человек говорит: “Я боюсь нажать не туда”, длинное объяснение терминов обычно увеличивает тревогу».

К гипотезам:

«Большинство отказов от практикума связано с высокой ценой».

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

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

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

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

Археологический алгоритм

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

1. Выбрать один сценарий, а не всю тему. Например: «Клиент получил оплату и не знает, с чего начать проверку».

2. Найти три–пять реальных материалов об этом сценарии: голосовое объяснение, переписку, фрагмент консультации, разбор ошибки или готовый ответ.