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

Команда, которой пока нет

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

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

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

Публикация была почти готова — не хватало только заголовка.

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

В 9:04 написала Марина:

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

Анна увидела сообщение, но не стала отвечать сразу. Вопрос требовал уточнений. Нужно было понять, о каком виде работы идёт речь, какие документы уже оформлены и что именно Марина называет «отдельно». Быстрый ответ оказался бы слишком общим. Точный потребовал бы времени на разбор.

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

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

В 10:18 Илья написал:

«Анна, что отвечать на вопрос про формат? Клиент спрашивает, будут ли записи и сколько длится доступ».

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

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

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

В 11:40 Илья переслал ещё один вопрос:

«А можно просто отправить человеку прошлый ответ?»

«Можно, если у него такой же случай и информация не изменилась», — написала Анна.

«А как понять, такой же или нет?»

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

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

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

«Пять минут», — сказала она вслух.

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

Они обсуждали ситуацию двадцать две минуты.

В 21:40 Анна снова увидела сообщение Марины. Резюме после консультации она так и не отправила. Днём ей помешали публикация, оплаты, повторяющиеся вопросы и разговор о возврате. Теперь нужно было не только восстановить содержание разговора, но и заново войти в рабочий контекст.

На кухне остывал чай. Анна написала Марине, извинилась за задержку и ещё раз проверила формулировки.

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

Пять минут, которые съедают неделю

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

Восемь одинаковых или почти одинаковых ответов в день по пять минут — это сорок минут в день и три часа двадцать минут в неделю.

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

Перенос данных об оплатах и участниках отнимал ещё сорок минут.

На напоминания и проверку статусов уходило примерно пятнадцать минут.

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

Анна посмотрела на цифры:

«Но я ведь не сижу пять часов и не отвечаю на одни и те же вопросы».

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

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

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

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

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

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

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

Три разных действия, которые часто путают

После расчёта Илья задал Анне неудобный вопрос:

«Что ты хочешь получить от ИИ? Чтобы эта работа исчезла, чтобы её делал кто-то другой или чтобы ты сама выполняла её быстрее?»

Анна сначала ответила:

«Разве это не одно и то же?»

Нет. За этими вариантами стоят три разные модели.

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

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

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

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

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

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

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

Чтобы не путать эти модели, задавайте себе три вопроса.

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

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

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

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

Три зоны ответственности

На листе Илья написал три колонки:

ИИ готовит.

Человек проверяет.

Человек решает.

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

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

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

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

Для Анны эта схема выглядела так.

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

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

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

Просроченная оплата. ИИ готовит нейтральный текст напоминания. Человек проверяет имя, сумму, срок и статус оплаты. Человек решает, отправлять ли напоминание, продлевать ли срок или передавать вопрос Анне.

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

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

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

Для Ильи Анна сформулировала правило:

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

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

Как говорить с клиентом, когда ответа пока нет

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

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

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

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

Для организационных вопросов можно использовать другой вариант:

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

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

Для сложного случая ИИ можно дать такой запрос:

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

Если в переписке есть персональные данные, перед передачей текста в инструмент нужно убрать фамилию, телефон, адрес, реквизиты документов и другие сведения, которые не нужны для подготовки черновика. Работайте по правилам, принятым в вашей организации, и учитывайте требования российского законодательства о персональных данных, включая Федеральный закон № 152-ФЗ. Для первого эксперимента достаточно обезличенного фрагмента: «клиент», «компания», «дата», «сумма», «вид деятельности».

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

Короткий слепок рабочего дня

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

Для этого достаточно одного рабочего дня.

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

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

После этого разделите записи на три типа.

Подготовка — это поиск, сортировка, черновик, перенос данных, варианты формулировок и краткое резюме.

Проверка — сверка фактов, условий, дат, сумм, источников и соответствия конкретному клиенту.

Решение — выбор действия, обещания, исключения, приоритета или ответа в спорной ситуации.

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

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

Как выбрать первую задачу

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

Первую задачу выбирают не по принципу «ИИ умеет это делать», а по трём признакам.

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

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

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

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

У Анны картина выглядела так.

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

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

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

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

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

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

Проверка границ за три дня

Первое внедрение не обязано начинаться с автоматической отправки. Для Анны безопаснее было провести диагностический эксперимент.

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

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

Илья отмечал один из трёх результатов:

«Можно отправлять после быстрой сверки».

«Нужна существенная правка».

«Не подходит, вопрос выходит за пределы базы».

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

Здесь пригодится простое дерево решений.

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

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

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

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

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

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

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

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

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

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

Это уже не желание и не обещание. Это начало процесса.

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

Карта работы вместо списка желаний

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

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

Пять мифов, которые мешают начать

Миф первый: автоматизировать нужно самую долгую задачу

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

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

Миф второй: контент сам по себе является процессом

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

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

Миф третий: если ИИ выдал текст, процесс уже автоматизирован

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

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

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

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

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

Миф пятый: человеческая проверка уничтожает выгоду

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

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

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

Цепочка от внимания до повторного обращения

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

Внимание

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

Доверие

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

Покупка

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

Результат

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

Повторное обращение

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

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

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

Семь полей для одной операции

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

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

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

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

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

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

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

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

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

Стоимость одной операции рассчитывается так: количество минут делится на 60 и умножается на стоимость часа владельца или исполнителя. Если обработка одного обращения занимает 18 минут, а ориентировочная стоимость часа равна 1200 рублям, ручная стоимость составляет 360 рублей за обращение. При 24 обращениях в месяц это 8640 рублей. Такой расчёт не является бухгалтерской себестоимостью: он показывает, сколько ресурса поглощает процесс и с чем сравнивать затраты на улучшение.

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

Как построить карту за один рабочий сеанс

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

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

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

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

Видимый вход

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

Проверяемый выход

Можно ли показать готовый результат? Если его нельзя положить в таблицу, сообщение, файл или другой понятный объект, его трудно проверять.

Место решения

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

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

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

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

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

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

Что чаще всего ломает карту

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

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

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

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

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

Разбор рабочего маршрута

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

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

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

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

Внимание

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

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

Промежуточное решение: связана ли тема с реальной проблемой клиента и предложением практики.

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

Владелец: основатель; помощник готовит черновик.

Риск ошибки: средний. Неверный акцент снижает качество обращений.

Доверие

Вход: вопрос или заявка из канала связи.

Действие: извлечь задачу, срок, контекст и недостающие сведения; подготовить ответ.

Промежуточное решение: подходит ли обращение под аудит, достаточно ли данных и нужен ли дополнительный вопрос.

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

Владелец: помощник; решение о соответствии принимает основатель.

Риск ошибки: средний или высокий. Можно потерять подходящего клиента или пообещать лишнее.

Покупка

Вход: квалифицированная заявка и заметки по задаче.

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

Промежуточное решение: соответствуют ли объём, цена и сроки задаче; нет ли ограничений.

Выход: подтверждённый заказ, оплата и согласованный объём.

Владелец: основатель.

Риск ошибки: высокий. Ошибка влияет на деньги, обязательства и ожидания.

Результат

Вход: оплата, бриф, доступы и материалы клиента.

Действие: провести аудит, подготовить отчёт и обсудить его на встрече.

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

Выход: отчёт с приоритетами и согласованный план действий.

Владелец: основатель.

Риск ошибки: высокий. Неверный вывод снижает ценность услуги.

Повторное обращение

Вход: переданный результат и обратная связь.

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

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

Выход: повторный проект, сопровождение или рекомендация.

Владелец: помощник готовит контакт, основатель утверждает предложение.

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

Под картой добавили рабочие измерения.

Подготовка материала для этапа внимания: 8 раз в месяц, 45 минут на операцию, ориентир стоимости часа — 1800 рублей, стоимость ручного времени за месяц — 10 800 рублей.

Квалификация первичного обращения: 24 раза в месяц, 18 минут на операцию, ориентир стоимости часа — 1200 рублей, стоимость ручного времени за месяц — 8640 рублей.

Подготовка предложения: 8 раз в месяц, 35 минут на операцию, ориентир стоимости часа — 1800 рублей, стоимость ручного времени за месяц — 8400 рублей.

Проведение аудита и подготовка результата: 3 раза в месяц, 180 минут на операцию, ориентир стоимости часа — 1800 рублей, стоимость ручного времени за месяц — 16 200 рублей.

Контакт после результата: 3 раза в месяц, 15 минут на операцию, ориентир стоимости часа — 900 рублей, стоимость ручного времени за месяц — 675 рублей.

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

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

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

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

Правило пилота на две недели

На ближайшие две недели выберите только один процесс. У него должен быть один владелец и один основной измеримый результат. Не «улучшить маркетинг», а, например, «сократить медианное время подготовки первого ответа с 18 до 8 минут». Ограничение по сроку нужно не для отчётности, а чтобы эксперимент не превратился в бесконечную перестройку бизнеса.

Для выбранной операции достаточно пройти четыре шага.

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

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

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

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

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

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

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

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

Правила для цифрового напарника

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

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

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

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

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

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

Особенно слабым результат оказывается в трёх ситуациях.

Во-первых, проект молодой, и основные правила хранятся в голове владельца. На сайте одна формулировка, в заметках — другая, в переписке с подрядчиком — третья. Модель получает только ту версию, которая случайно оказалась в переданных ей материалах.

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

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

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

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

Задача: подготовить текст для страницы услуги.

Продукт: название, состав, результат для клиента.

Аудитория: кто принимает решение и в какой ситуации.

Используй: утверждённые факты из указанных источников.

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

Если данных не хватает: перечисли пробелы и задай вопросы.

Формат результата: объём, структура, призыв к действию.

Критерии проверки: фактическая точность, ясность, соответствие голосу проекта.

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

Контекст проекта: что именно должен знать напарник

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

Начните с одного предложения о продукте. В нём должны быть понятны сам продукт, адресат и результат. Формула может выглядеть так: «Мы помогаем [кому] получить [результат] с помощью [продукта или метода]». Если результат зависит от действий клиента, это тоже нужно указать.

Например:

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

Сразу после этого обозначьте границу обещания:

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

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

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

Рабочее описание аудитории может выглядеть так:

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

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

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

Зафиксируйте:

1) базовую цену и валюту расчёта;

2) что входит в стоимость;

3) что оплачивается отдельно;

4) допустимые способы оплаты;

5) сроки оказания услуги;

6) срок действия цены, если он ограничен;

7) правила переноса, отмены и возврата;

8) условия скидок и тех, кто вправе их утверждать;

9) контакт или роль, отвечающие за исключения.

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

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

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

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

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

Отдельно запишите обещания проекта. Удобно разделить их на три уровня.

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

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

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

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

Единый набор источников вместо папки с противоречиями

Сигнал: в разных ответах помощник использует разные цены, сроки или характеристики

Такой сбой почти всегда говорит не о «плохой памяти» модели, а об отсутствии иерархии источников. Сведения в проекте есть, но никто не определил, какой документ главнее и что делать при конфликте.

Для каждого факта заведите карточку источника. Достаточно семи полей:

Название источника.

Какие факты он подтверждает.

Кто отвечает за актуальность.

Дата последней проверки.

Срок действия или условие устаревания.

Приоритет по отношению к другим документам.

Какие формулировки разрешено использовать публично.

Пример:

Источник: актуальный прайс-лист.

Подтверждает: цены, состав пакетов, доступные способы оплаты.

Владелец: руководитель продаж.

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

Приоритет: выше старых презентаций и переписки.

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

Приоритет источников удобно выстроить так:

1) действующие условия продукта, утверждённые ответственным владельцем;

2) прайс-лист и правила оплаты;

3) договор, публичная оферта и утверждённые условия возврата;

4) база часто задаваемых вопросов;

5) согласованные примеры и кейсы;

6) тексты сайта и презентации;

7) отдельные сообщения, черновики и старые файлы.

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

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

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

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

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

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

Голос бренда задаётся не прилагательными

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

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

Разделите его на четыре слоя.

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

Полезен список замен. Например:

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

Фразу «поможем увеличить эффективность» заменять описанием действия и результата.

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

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

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

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

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

Так помощник получает не абстрактное «пиши как мы», а набор наблюдаемых образцов.

Сравните две формулировки:

«Наше комплексное решение позволит существенно повысить эффективность бизнес-процессов и вывести компанию на новый уровень».

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

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

Что напарнику запрещено придумывать

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

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

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

Помощник не придумывает:

1) цены, скидки, рассрочки, комиссии и условия оплаты;

2) сроки изготовления, доставки, запуска, ответа или возврата;

3) характеристики продукта, наличие функций и состав пакета;

4) отзывы, названия клиентов, должности и результаты кейсов;

5) сертификаты, лицензии, партнёрства и награды;

6) статистику, проценты, исследования и ссылки на источники;

7) юридические выводы и гарантии правового результата;

8) обещания дохода, роста продаж, экономии или иного результата, зависящего от обстоятельств клиента;

9) сведения о наличии свободных мест, товаров или специалистов;

10) персональные данные и внутреннюю информацию о других клиентах.

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

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

Рабочая инструкция:

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

Безопасный шаблон ответа при нехватке данных:

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

Такой ответ не выглядит бесполезным. Он показывает границу знания и сохраняет следующий шаг.

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

1) источники противоречат друг другу;

2) клиент просит исключение из стандартных условий;

3) требуется изменить цену, срок, состав услуги или порядок возврата;

4) есть жалоба, угроза претензии или риск репутационного конфликта;

5) запрос касается персональных данных;

6) требуется юридическая, финансовая или иная специализированная оценка;

7) клиент не подходит под стандартный сценарий;

8) помощник не может подтвердить ключевой факт;

9) ответ может создать обязательство для компании;

10) ошибка будет стоить дороже, чем ручная проверка.

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

Критерии хорошего результата: не «нравится», а можно ли принять

Сигнал: ответ оценивают фразами «что-то не то», «сделай лучше» или «слишком сухо»

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

Для текста проверьте девять пунктов.

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

2) Понятен адресат и его ситуация.

3) Каждое существенное утверждение подтверждено источником либо явно обозначено как предположение.

4) В тексте нет придуманных цен, сроков, цифр, отзывов и гарантий.

5) Есть одна основная мысль, а не набор разрозненных преимуществ.

6) Конкретики достаточно: читатель понимает, что получит и что делать дальше.

7) Лексика, ритм и эмоциональность соответствуют голосу проекта.

8) Призыв к действию соответствует реальному следующему шагу.

9) Текст можно проверить и утвердить, не расследуя заново всю историю продукта.

Для ответа клиенту критерии будут другими.

1) Вопрос точно определён: цена, срок, состав, доступ, возврат, статус или что-то ещё.

2) Использован актуальный источник.

3) Сначала дан прямой ответ, затем пояснение.

4) Если вопрос не решён, обозначено, что именно проверяется.

5) Назван следующий шаг и ответственный канал.

6) Не обещан срок, который никто не подтвердил.

7) Не раскрыты чужие данные и внутренняя информация.

8) Тон уважительный, но без неискренних извинений и давления.

9) При наличии риска ответ передан человеку, а не отправлен автоматически.

Коммерческое предложение требует ещё более жёсткой проверки.

1) Описана задача клиента, а не только услуги исполнителя.

2) Понятно, что входит в работу и что в неё не входит.

3) Результаты сформулированы как проверяемые поставки: отчёт, настройка, консультации, материалы, план или доступ.

4) Сроки основаны на актуальных данных и указаны вместе с условиями, от которых зависят.

5) Цена совпадает с действующим источником.

6) Дополнительные расходы и ограничения не спрятаны за общими словами.

7) Кейсы и цифры имеют источник и не выданы за гарантию.

8) Предусмотрен порядок согласования и внесения изменений.

9) Указан срок действия предложения, если он нужен.

10) Есть понятный следующий шаг: подтвердить объём, назначить встречу, передать данные или запросить расчёт.

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

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

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

Роль: кем выступает помощник в этой операции.

Задача: какой результат нужно подготовить.

Контекст: продукт, аудитория, стадия общения и особые условия.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

— А контент?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

— Почему?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Переписки

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

К гипотезам:

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

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

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

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

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

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

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

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

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

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

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

5. Разнести содержание по статусам: факт, профессиональная оценка, гипотеза.

6. Добавить словарь клиента: его точные слова, страх, возражение и желаемый результат.

7. Сформулировать одно правило звучания и один запрет. Например: «Начинать с описания ситуации, а не с термина» и «Не обещать, что после одного занятия человек никогда не ошибётся».

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

Этот алгоритм не заменяет редактуру. Он сокращает путь от «всё у меня в голове» до материала, которым могут пользоваться Илья и цифровой напарник.

Что было бы, если бы Анна просто выгрузила весь архив

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

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

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

Что было бы, если бы Анна ограничилась словами «пиши тепло и по-человечески»

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

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

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

Паспорт голоса

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

— Здесь написано так, будто меня разобрали на детали.

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

— А если я завтра скажу иначе?

— Тогда обновим паспорт. Он не приговор, а текущая карта.

В итоговой версии паспорт выглядел примерно так.

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

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

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

Уровень строгости — спокойный и собранный. Анна может сказать «так делать не стоит», но не говорит «как можно было этого не знать». Ошибку нужно называть без унижения.

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

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

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

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

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

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

Как отличить узнаваемость от копирования

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

Для поста получилось:

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

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

Ответ в переписке звучал иначе:

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

Здесь больше прямого обращения и меньше объяснения. Это нормально: задача поддержки — помочь человеку продолжить разговор, а не опубликовать мини-лекцию.

Фрагмент описания продукта:

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

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

Неудачный вариант выглядел так:

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

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

Проверка на удачных и неудачных примерах

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

1. Узнаваем ли способ рассуждения? Текст начинается с ситуации клиента или сразу с общего лозунга?

2. Есть ли в нём реальное слово аудитории, а не придуманный маркетинговый термин?

3. Разделены ли событие, проверяемый факт и вывод автора?

4. Есть ли действие, которое читатель может выполнить дальше?

5. Не обещает ли текст больше, чем продукт и эксперт могут выполнить?

6. Не использует ли он старую цену, закрытый формат или прежние условия?

7. Можно ли убрать имя Анны, а текст всё ещё будет соответствовать её правилам?

8. Если в тексте есть утверждение о налоговых требованиях, понятно ли, откуда оно взято и когда проверено?

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

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

Для теста Илья подготовил три задания без названия бренда:

«Ответьте клиенту, который спрашивает, нужен ли ему весь практикум, если клиентов пока два».

«Напишите короткое объяснение, с чего начать, если человек получил оплату и не понимает, какие сведения собрать».

«Обновите описание продукта после изменения формата участия».

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

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

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

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

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

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

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

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

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

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

Анна сначала возразила, что без этих слов текст станет слишком стерильным. Тогда они сравнили два варианта.

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

«Сначала разберитесь с самой операцией. Потом проверяйте, какие действия к ней относятся».

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

Обновление, когда меняется продукт

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

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

Илья заметил старый текст в ответе клиенту только после публикации. Человек спросил, можно ли прислать Анне все свои операции, чтобы получить личную проверку. Ответ из старой базы обещал именно это.

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

После этого Анна и Илья ввели порядок обновления.

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

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

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

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

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

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

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

Паспорт голоса как рабочая карта

Через несколько недель Анна заметила странный эффект. Илья стал приносить ей не десять текстов «на правку», а два варианта с короткими вопросами:

«Здесь мы используем факт или твою оценку?»

«Эта формулировка относится к текущему формату?»

«В словаре есть слово клиента для этой ситуации или мы его придумали?»

«Нужно обещать результат или описать ближайшее действие?»

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

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

что считать началом разговора;

какой страх признавать, а какой не усиливать;

как говорить о неопределённости;

какие слова использует аудитория;

где заканчивается общий совет;

какие обещания продукт действительно выполняет;

что следует проверить перед публикацией.

Проверочный список для первой версии

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

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