Почему внедрение ассистента проваливается, когда долг процесса остаётся скрытым

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

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

Вот почему многие AI-проекты ранo разочаровывают. Люди ждут чистого вывода от процесса, который всё ещё работает по неясным правилам, с устаревшими заметками и невысказанными допущениями. Ассистент сам по себе этого не исправит. Он повторяет путаницу, часто более гладко выражая её.

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

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

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

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

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

Где прячется долговая нагрузка процесса

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

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

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

Чат создаёт свои проблемы. Кто‑то публикует новое исключение в Slack, другой делится лучшим шаблоном в приватной ветке, и ни одно обновление не попадает в главный документ. Ассистент работает со старой документацией, а команда почему‑то думает, что он знает последнюю версию.

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

Язык вносит путаницу тихо. Одна группа говорит «lead», другая — «trial user», третья — «account». Все могут иметь в виду одного и того же человека, но ассистент будет трактовать эти слова по‑разному, если рабочий процесс их явно не определяет.

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

Как заметить проблему процесса

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

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

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

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

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

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

Проследите один плохой ответ до источника

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

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

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

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

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

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

Простой пример из растущего стартапа

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

Но команда растёт, и трещины проявляются.

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

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

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

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

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

Исправьте устаревшие документы перед настройкой промптов

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

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

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

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

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

Oleg Sotnikov часто рассматривает это как системную проблему, а не трюк с промптами. Эта идея проявляется и в его работе на oleg.is: чистые документы, ясные термины и меньше дубликатов дают ассистенту шанс ответить правильно.

Назначьте реального владельца для каждого рабочего процесса

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

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

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

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

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

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

Если у рабочего процесса три владельца — значит, у него нет владельца.

Уберите лишние согласования

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

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

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

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

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

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

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

Ошибки, которые сохраняют слабый вывод

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

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

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

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

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

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

Исправьте правило, передачу и владельца сначала. Отредактируйте промпт после этого.

Короткая проверка и следующий шаг

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

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

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

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

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

Если аудит выявит более серьёзные проблемы, этим занимается Oleg Sotnikov через его Fractional CTO и консалтинг для стартапов на oleg.is. Полезная часть — не ещё один шаблон промпта, а порядок в процессе, владении и исходных материалах, чтобы ассистенту было на чём опираться.

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