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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Владелец — не обязательно автор документа. Это роль, отвечающая за правильность сведений. За карточки услуг может отвечать руководитель сервиса, за цены — руководитель или специалист, утверждающий расчёты, за стиль — автор контента или руководитель, за 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 рабочих дней после согласования. Доставка и монтаж рассчитываются отдельно, а итоговая стоимость зависит от размеров и выбранного материала.

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

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

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

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