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

ИИ не заменит хозяина: где появляется маржа

В 8:47 утра в мастерской «Ладья» одновременно происходят четыре вещи.

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

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

В 9:12 Марина произносит фразу, которую владельцы малого бизнеса в такие дни повторяют почти автоматически:

«Нам просто нужно больше клиентов».

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

Сначала кажется, что клиентов мало

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

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

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

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

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

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

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

Наталья покачала головой.

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

«Мне не нужны роботы, — ответила Марина. — Мне нужны заказы».

Илья, до этого молча смотревший в телефон, поднял глаза.

«А мне нужны полные заявки. Иногда заказ уже есть, деньги внесены, а о важных деталях я узнаю только в цехе».

Марина записала в блокноте: «Заявок мало. Ответы медленные. Брифы неполные. Переделки».

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

Скрытая цена обычного рабочего дня

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

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

Марина посмотрела на часы и ответила: «Да, завтра утром всё уточню».

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

Чтобы увидеть эту стоимость, не нужно сразу покупать ИИ. Нужны четыре недели фактов.

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

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

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

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

За последние четыре недели у «Ладьи» получилось 160 новых заявок, 58 коммерческих предложений и 14 оплаченных заказов. Средний чек составлял 82 000 рублей, средние прямые затраты на заказ — 54 000, а средняя маржа — 28 000 рублей. Конверсия заявки в оплаченный заказ равнялась 8,75 процента. Медианное время до первого содержательного ответа составляло 2 часа 20 минут. В шести случаях потребовалась переделка или повторная работа из-за неполного либо неверно переданного задания.

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

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

Самый частый участок — повторяющиеся ответы и сбор исходных данных. За четыре недели таких эпизодов набралось 120, каждый занимал в среднем семь минут. При стоимости часа 600 рублей это давало около 8 400 рублей рабочего времени. В четырнадцати заявках не хватало обязательных данных, поэтому расчёт откладывался, а клиенту приходилось ждать следующего контакта. Возможная роль ИИ здесь — подготовить черновик ответа и список недостающей информации.

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

Поиск старых цен и характеристик материалов занимал в среднем одиннадцать минут и повторялся 28 раз. При стоимости часа 850 рублей это около 4 360 рублей. Четыре раза использовались устаревшие данные, из-за чего возникал риск занизить цену или задержать расчёт. В этом процессе ИИ мог искать сведения в утверждённом справочнике и каждый раз указывать источник.

Уточнение неполного брифа с производством встречалось 38 раз и отнимало примерно по четырнадцать минут. Стоимость такого времени составляла около 7 540 рублей. Девять заказов потребовали дополнительных вопросов, из-за чего сдвигалось планирование и росло число переписок. Здесь ИИ мог превращать согласованную переписку в структурированный бриф и отмечать пропуски.

Переделка из-за ошибки в передаче заказа случалась шесть раз. Каждый такой случай занимал в среднем 138 минут, а стоимость времени составляла около 11 730 рублей. В трёх случаях пришлось закупать дополнительные материалы. Мастерская теряла срок и часть маржи, а клиент получал неприятный сюрприз. Возможный вклад ИИ — проверять заполненность брифа до передачи в производство.

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

В сумме набралось около 53 часов и примерно 39 150 рублей рабочего времени за четыре недели.

Это не означало, что «Ладья» гарантированно теряла ровно 39 150 рублей наличными. Часть этих часов всё равно была бы оплачена, а каждую свободную минуту невозможно автоматически превратить в новый заказ. Но 53 часа — это почти шесть с половиной рабочих дней. Их можно было потратить на расчёты, контроль качества, возвращение к клиентам или подготовку производства.

Марина сначала отнеслась к цифре настороженно.

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

Илья ответил:

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

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

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

Ни один из этих результатов не был обещанием. Это были проверяемые гипотезы.

Три роли, которые не заменяют владельца

После таблицы разговор об ИИ стал конкретнее. Марина больше не спрашивала: «Что искусственный интеллект может сделать для бизнеса?» Теперь её интересовало другое: «Какую строку мы можем проверить без риска для клиента и денег?»

Для малого бизнеса полезно различать три роли ИИ.

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

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

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

В «Ладье» для каждой роли выбрали по одному ограниченному примеру.

Помощник: из переписки в бриф

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

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

Для такого разбора использовали запрос:

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

Результат мог выглядеть так:

Изделие: тумба под раковину.

Подтверждено: напольная, две дверцы, светлый цвет, нужна влагостойкая поверхность.

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

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

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

Аналитик: из журнала заявок в картину воронки

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

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

После этого аналитическая роль ИИ могла выглядеть так:

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

В результате «Ладья» увидела не только 160 заявок и 14 заказов. Выяснилось, что после первого обмена сообщениями у 37 заявок не было назначенного следующего шага. В 13 случаях предложение отправили, но никто не вернулся к клиенту в течение двух дней. Это не доказывало, что все 13 заказов были потеряны. Зато показывало участок, который можно проверить.

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

Ускоритель коммуникаций: из шаблона в черновик

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

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

Базовый черновик первого ответа мог выглядеть так:

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

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

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

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

Такое сообщение не давило на клиента. Оно возвращало диалог и давало простой способ ответить. ИИ мог подготовить список тех, кому пора написать, и черновики сообщений. Но решение о контакте, тон и отправка оставались у Натальи.

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

Почему нельзя автоматизировать всё сразу

На том же совещании Марина, уже увлечённая найденными возможностями, предложила:

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

Идея казалась логичной — до первой нестандартной ситуации.

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

Илья сказал:

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

Наталья добавила:

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

Попытка автоматизировать всё сразу обычно ломается по четырём причинам.

Во-первых, непонятно, что считать успехом. Если одновременно менять ответы, расчёты, напоминания и передачу в производство, невозможно понять, что именно дало результат.

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

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

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

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

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

Это уже не обещание революции. Это эксперимент.

Проверка реальности: выбрать три процесса

Теперь можно выполнить упражнение, которое Марина сделала вместе с командой. Оно занимает около двадцати минут, если под рукой есть переписка, календарь и журнал заказов.

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

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

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

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

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

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

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

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

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

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

Работает простое дерево решений.

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

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

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

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

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

Три строки, которые Марина оставила в конце упражнения, выглядели так.

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

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

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

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

Что оставалось у человека

К концу недели Марина сформулировала для команды несколько правил.

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

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

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

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

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

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

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

Карта работы: увидеть задачи, которые съедают день

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

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

Пять заблуждений, которые мешают увидеть работу

Первое заблуждение: день съедает одна большая задача

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

Второе заблуждение: первой нужно брать самую частую задачу

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

Третье заблуждение: всё повторяющееся можно без опасений отдать ИИ

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

Четвёртое заблуждение: карта работы должна описывать идеальный процесс

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

Пятое заблуждение: если информация хранится в голове владельца, она уже доступна бизнесу

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

Правильная единица наблюдения

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

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

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

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

Клиентский путь под увеличительным стеклом

Начните не с вопроса «где применить ИИ?», а с вопроса «что происходит с одним заказом после первого обращения?».

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

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

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

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

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

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

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

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

Упражнение «снимок одного заказа»

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

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

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

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

Пример записи: «10:12 — администратор — извлёк из обращения количество и желаемую дату — сообщение клиента — черновик заказа — владельцу на проверку — 35 минут до ответа». Следующая строка может показать, что владелец не получил сам текст обращения, а увидел только сокращённое описание. Тогда передача становится видимой.

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

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

Инвентаризация скрытой работы

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

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

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

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

Разделите задачи на четыре типа

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

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

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

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

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

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

Следите за местами потери информации

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

Есть пять устойчивых признаков разрыва.

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

Второй — сотрудник регулярно просит переслать «последнюю версию». Значит, нет единого источника актуальной информации.

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

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

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

Стоимость потерянного часа

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

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

Есть и отложенная стоимость: клиент может не сделать повторную покупку, снизить объём заказа или реже рекомендовать компанию. Не нужно пытаться с точностью до рубля оценить доверие. Достаточно зафиксировать диапазон — низкая, средняя или высокая цена ошибки — и указать основание.

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

Стоимость исправления — это дополнительные часы работы, умноженные на внутреннюю стоимость часа, плюс прямые расходы.

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

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

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

Разбор учебного кейса: мастерская корпоративных наборов

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

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

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

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

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

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

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

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

Матрица выбора первой задачи

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

В учебном примере оценки выглядят так.

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

Черновик стандартного предложения по утверждённому прайсу: большинство типовых заказов, от администратора к клиенту; эффект — 4, сложность запуска — 3, риск для клиента — 3, цена ошибки — 3. Решение — после проверки правил.

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

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

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

Напоминание о сборе обратной связи: после доставки, от администратора к клиенту; эффект — 3, сложность запуска — 2, риск для клиента — 2, цена ошибки — 2. Решение — альтернативный первый пилот.

Разбор претензий и предложение компенсации: по мере возникновения, от владельца к клиенту; эффект — 4, сложность запуска — 4, риск для клиента — 5, цена ошибки — 5. Решение — не отдавать ИИ решение.

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

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

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

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

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

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

Первый опыт без дорогой перестройки

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

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

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

Пилот начинается не с модели

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

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

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

Поэтому первым объектом проверки становится не то, «насколько умно отвечает сервис», а граница самого сценария:

что именно получает ИИ;

что он должен вернуть;

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

кто проверяет результат;

сколько времени занимает вся операция;

при каком результате эксперимент прекращается.

Если на эти вопросы нет коротких ответов, запускать пилот рано. Сначала задачу нужно уменьшить.

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

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

Заполните паспорт до того, как начнёте сравнивать модели.

Задача

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

Вход

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

Ожидаемый выход

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

Срок

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

Проверяющий

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

Метрики

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

Условие остановки

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

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

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

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

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

Срок: 90 минут на подготовку, 72 часа на пилот, не менее 15 обращений.

Проверяющий: сотрудник, который утверждает ответы клиентам.

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

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

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

Девяносто минут до первого решения

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

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

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

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

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

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

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

Контрольная выборка важнее красивой демонстрации

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

Для первого прогона достаточно 10–20 случаев. Включите четыре-пять обычных примеров, составляющих основной поток, два-три коротких и простых обращения, два случая с неполными данными, два примера с противоречиями или необычной формулировкой и один-два случая, в которых ошибка будет критичной.

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

Обезличивание не сводится к простой замене имени словом «клиент». Проверьте телефоны, электронные адреса, номера заказов, адреса доставки, паспортные данные, реквизиты, ссылки, фотографии и сочетания сведений, по которым человека можно узнать. Если содержание всё равно позволяет восстановить личность, считайте его чувствительным. Для первого теста заменяйте такие фрагменты единообразными обозначениями: «ИМЯ_КЛИЕНТА», «НОМЕР_ЗАКАЗА», «АДРЕС_ДОСТАВКИ». При этом сохраняйте свойства задачи: длину текста, наличие ошибок, последовательность сообщений и противоречия.

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

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

Если первый слой дал хороший результат, это ещё не разрешает переходить к третьему.

GigaChat и YandexGPT: сравнивать нужно не названия, а пригодность

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

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

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

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

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

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

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

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

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

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

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

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

Задача: подготовить черновик ответа на входящее обращение.

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

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

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

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

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

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

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

Демонстрационный ответ против рабочего материала

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

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

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

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

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

Как измерять время и качество

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

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

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

В журнале достаточно следующих полей.

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

Вариант — ручной способ, GigaChat, YandexGPT или другая версия.

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

Качество — балл по заранее установленным критериям.

Исправления — количество и тип изменений.

Критическая ошибка — да или нет, с кратким описанием.

Решение — принять, доработать или отклонить.

Оценку качества можно проводить по шкале от 0 до 2 для каждого критерия: 0 означает, что критерий нарушен; 1 — что требуется заметная правка; 2 — что результат соответствует требованиям.

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

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

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

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

Три дня полевого теста

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

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

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

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

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

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

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

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

Сигналы в поле: что они означают и что делать

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

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

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

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

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

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

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

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

Условия остановки, доработки и продолжения

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

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

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

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

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

Скрипт проверки перед каждым результатом

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

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

В инструкции для модели можно закрепить такой порядок:

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

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

Решение по итогам 72 часов можно зафиксировать в четырёх правилах.

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

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

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

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

Что должно остаться после пилота

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

Если после теста остаётся только ощущение, что «модель вроде бы помогает», эксперимент не завершён. Верните его к измеримому решению. Сколько минут сэкономлено? Как изменилась доля правок? Какие ошибки встречаются? Кто и сколько времени проверяет? Что произойдёт, если объём вырастет в пять раз? На эти вопросы не нужно отвечать теоретически: часть ответов уже должна быть в журнале.

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

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

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

Из хаоса в контекст: собрать рабочую базу

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

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

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

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

Результат может выглядеть так:

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

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

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

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

Что именно продаёт или делает компания?

Для кого и в какой ситуации это нужно?

Что разрешено обещать и при каких условиях?

Как оформить ответ на языке компании?

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

Контекст начинается не с архива

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

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

Рабочая база обычно держится на пяти блоках.

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

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

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

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

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

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

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

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

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

Каждое сведение проверьте тремя вопросами.

Если убрать этот факт, изменится ли правильный ответ?

Есть ли источник, который его подтверждает?

Кто может сказать, что факт по-прежнему действует?

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

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

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

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

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

Карточка продукта должна запрещать догадки

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

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

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

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

Пример учебной карточки:

Название: выездная диагностика кофемашины.

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

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

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

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

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

Срок: продолжительность зависит от модели и характера неисправности; время визита подтверждает администратор.

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

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

Владелец: администратор сервиса.

Дата проверки: указывается при каждом обновлении.

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

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

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

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

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

Упражнение второе. Собрать одну карточку, на которую можно опереться

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

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

После заполнения проверьте карточку на трёх типах вопросов.

Может ли модель назвать точную цену, если она известна?

Может ли она отказаться от точного ответа, если данных для расчёта недостаточно?

Может ли она объяснить, что клиенту нужно сделать дальше?

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

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

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

FAQ приносит пользу тогда, когда отражает реальное решение клиента. Запись «вопросы о доставке» слишком расплывчата. Рабочая формулировка выглядит так: «Можно ли получить товар в день заказа, если нужной позиции нет в наличии?»

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

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

Слабый ответ на такое возражение выглядит так: «Мы работаем только с качественными материалами и всегда заботимся о клиентах». Он ничего не объясняет.

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

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

Вопрос: «Можно ли выполнить работу за один визит?»

Слабая формулировка: «Да, наши специалисты работают быстро и стараются решить вопрос сразу».

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

Рабочий вариант звучит не так эффектно, зато управляет ожиданиями. Он не обещает того, что зависит от диагностики и наличия детали.

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

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

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

Упражнение третье. Превратить пять обращений в пять рабочих правил

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

Затем проверьте каждый вариант на трёх уровнях.

Первый уровень — точность. Есть ли подтверждающий источник?

Второй — применимость. Понятно ли, для какого товара, услуги или сегмента действует правило?

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

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

Правила стиля должны быть наблюдаемыми

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

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

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

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

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

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

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

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

Обезличивание: оставить ситуацию, убрать человека

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

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

Перед использованием клиентской истории последовательно выполните несколько шагов.

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

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

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

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

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

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

Для разбора качества ответа достаточно следующего:

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

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

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

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

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

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

Упражнение четвёртое. Очистить одну клиентскую историю

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

Затем проведите три проверки.

Можно ли по оставшимся сведениям узнать конкретного клиента внутри компании или сопоставить их с другими файлами?

Изменится ли правильный ответ, если убрать этот факт?

Не содержит ли текст данных, к которым у пользователя ИИ не должно быть доступа?

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

Устаревший файл опаснее отсутствия файла

Отсутствие информации заставляет модель остановиться или попросить уточнение, если такое правило задано заранее. Устаревшая информация создаёт другую ситуацию: модель уверенно использует неверную цену, старую комплектацию или отменённое ограничение.

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

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

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

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

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

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

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

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

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

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

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

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

Правило if/then для рабочего контекста

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

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

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

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

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

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

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

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

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

Сборка минимального контекстного паспорта

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

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

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

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

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

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

Запрос, который приводит к результату

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

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

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

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

Кейс: публикация для мастерской

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

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

Первый запрос выглядит так:

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

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

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

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

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

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

Пять опор рабочего запроса

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

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

1. Задача

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

К слабой исходной формулировке добавим только задачу:

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

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

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

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

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

2. Контекст

Контекст отвечает на вопрос: «На каких данных и в какой ситуации нужно работать?»

Для публикации добавим проверенную карточку:

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

Теперь у модели появился материал для текста, а вместе с ним — чёткая граница: неизвестные данные нельзя заменять догадками.

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

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

Последний пункт особенно важен. Например:

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

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

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

3. Ограничения

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

Для публикации можно добавить:

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

Здесь соединены несколько видов ограничений.

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

Ограничения по объёму не дают модели превратить короткую публикацию в рекламную статью.

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

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

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

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

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

4. Формат

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

Добавим:

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

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

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

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

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

5. Критерии качества

Критерии качества превращают «сделай хорошо» в проверку «прошло или не прошло».

Для публикации зададим такие условия:

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

Это уже не пожелание редактора, а список контрольных точек.

Итоговый рабочий запрос для кейса выглядит так:

«Работай как редактор коммерческих текстов и проверяющий факты.

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

Контекст: мастерская изготавливает фасады и стойки по размерам помещения. Расчёт выполняется по чертежу или исходным размерам. Базовый срок изготовления — от 14 рабочих дней после согласования. Доставка и монтаж рассчитываются отдельно. Итоговая стоимость зависит от размеров и выбранного материала. Эти сведения актуальны на 12 мая 2025 года.

Ограничения: объём от 700 до 900 знаков без пробелов; не указывай цену; не обещай скидку, фиксированную дату готовности, минимальную стоимость, максимальную скорость или работу “под ключ”; используй один призыв к действию; не добавляй факты, которых нет в контексте.

Формат: заголовок до 70 знаков; затем два или три коротких абзаца; затем призыв с перечнем данных от клиента; после текста отдельный блок “Проверка”, где перечислены использованные факты и возможные места для дополнительной проверки.

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

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

Финальный вариант может начинаться так:

«Обновляете зал кафе или готовите новое открытие?

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

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

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

Роль без театральной маски

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

Роль полезна, когда описывает функцию.

Слабый вариант:

«Ты — самый известный эксперт по продажам. Напиши идеальный текст».

Рабочий вариант:

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

Для анализа:

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

Для подготовки решения:

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

Такая роль задаёт не статус, а дисциплину. Она сообщает модели, через какую профессиональную оптику смотреть на задачу.

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

Примеры входа и образцы результата

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

Ответ клиенту

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

Запрос:

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

Ожидаемый результат:

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

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

Сравнительный разбор

Для сравнения двух материалов входные данные можно задать так:

«Материал А: стоимость комплекта 96 000 рублей, базовый срок 14 рабочих дней, способ ухода не указан. Материал Б: стоимость комплекта 126 000 рублей, базовый срок 18 рабочих дней, способ ухода не указан. Доставка и монтаж в обе суммы не входят. Сравни варианты для кафе, которое планирует открыть зал через месяц. Не делай вывод о долговечности, если данных нет».

Удобный формат результата может выглядеть так.

Стоимость комплекта. Материал А — 96 000 рублей, материал Б — 126 000 рублей. Нужно проверить, входят ли в суммы дополнительные элементы.

Базовый срок. Для материала А — 14 рабочих дней, для материала Б — 18. Нужно проверить, достаточно ли этого срока до открытия.

Доставка и монтаж. В стоимость обоих вариантов не входят. Нужно уточнить итоговую стоимость работ.

Уход за поверхностью. Данные по обоим материалам отсутствуют. Нужно запросить инструкцию производителя.

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

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

Расчёт

Для расчёта экономики отдельного заказа запрос может выглядеть так:

«Рассчитай валовую прибыль заказа. Выручка — 180 000 рублей. Материалы — 96 000 рублей. Работа — 28 000 рублей. Доставка — 8 000 рублей. Не включай налоги, аренду и административные расходы, так как их нет во входных данных. Покажи формулу, сумму валовой прибыли, её долю в выручке и результат при увеличении стоимости материалов на 10 процентов. Если какого-либо значения не хватает, не подставляй ноль».

Корректный результат:

Выручка: 180 000 рублей.

Прямые затраты: 96 000 + 28 000 + 8 000 = 132 000 рублей.

Валовая прибыль: 180 000 − 132 000 = 48 000 рублей.

Доля валовой прибыли в выручке: 48 000 / 180 000 × 100 = 26,7 процента.

При увеличении стоимости материалов на 10 процентов материалы составят 105 600 рублей. Валовая прибыль снизится до 38 400 рублей, а её доля в выручке — до 21,3 процента.

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

Список вопросов и сценарий звонка

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

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

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

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

Три прохода вместо просьбы «сделай лучше»

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

Первый проход — черновик.

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

Второй проход — критика.

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

Третий проход — улучшение.

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

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

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

Если условия меняются

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

Что произойдёт, если цель публикации изменится?

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

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

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

Меняется не только заголовок. Меняются критерии качества, формат и следующий шаг.

Что делать, если данные неполные или устарели?

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

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

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

Что делать, если цена ошибки высока?

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

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

В этом случае автоматизация ограничивается этапом подготовки. Отправку выполняет человек после сверки.

Библиотека запросов для команды

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

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

Карточка шаблона должна содержать несколько полей.

Название. Оно должно описывать действие, объект и канал. Например: «Пост_расчёт_комплекта_для_кафе_ВКонтакте_v1».

Назначение. Одно предложение: «Получить первый вариант публикации для заявок на расчёт».

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

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

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

Дата обновления. Она показывает, насколько свежи условия и факты.

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

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

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

Правила пополнения библиотеки просты.

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

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

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

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

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

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

Четыре заготовки для библиотеки

Шаблон для текста

«Задача: подготовь [тип текста] для [аудитория] с целью [действие].

Контекст: используй только следующие факты, актуальные на [дата]: [факты]. Неизвестно или требует проверки: [список].

Ограничения: [объём], [тон], [запрещённые обещания], [число призывов], [правила работы с персональными данными].

Формат: [заголовок], [число абзацев], [призыв], [внутренний блок проверки].

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

Шаблон для анализа и сравнения

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

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

Критерии качества: все значения имеют единицы измерения; неизвестные поля отмечены; выводы связаны с критериями; рекомендации не выдают предположение за факт».

Шаблон для расчёта

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

Шаблон для подготовки решения

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

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

Алгоритм сборки запроса

Перед отправкой запроса пройдите семь шагов.

1. Назовите действие: написать, сравнить, посчитать, проверить или подготовить.

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

3. Отберите только нужные факты и укажите дату их актуальности.

4. Перечислите неизвестные сведения и запреты на догадки.

5. Задайте формат: блоки, объём, столбцы, порядок и единицы измерения.

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

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