Марк Тьюрин
Работа с ИИ без хаоса: Как ставить задачи нейросети и получать полезный результат

Почему нейросеть отвечает не на тот вопрос

10:18. Мария вставила в окно нейросети сообщение клиента и добавила:

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

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

«Здравствуйте! Приносим извинения за проблему с доступом. Доступ восстановим сегодня до 18:00. В качестве компенсации продлим подписку на месяц. Благодарим за терпение».

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

«Это какая-то случайная ошибка», — сказала она Илье, когда тот заглянул в кабинет.

«Может быть, — ответил он. — А что именно ты попросила модель сделать?»

«Подготовить ответ клиенту».

«А где в переписке сказано, что мы уже проверили доступ?»

Мария открыла переписку. Там этого не было.

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

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

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

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

Разрыв между тем, что нужно, и тем, что сказано

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

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

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

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

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

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

Три причины переделок

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

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

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

Илья спросил Марию:

«Если бы я получил ровно этот запрос, смог бы понять, когда восстановят доступ?»

«Нет».

«А модель откуда должна была бы это узнать?»

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

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

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

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

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

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

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

Неопределённость расползается по ответу

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

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

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

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

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

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

Где заканчивается ошибка запроса

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

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

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

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

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

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

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

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

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

Когда ответ не тот: короткий разбор

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

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

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

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

Возвращаясь к запросу Марии

Восстановив недостающие условия, Мария отправила новую версию:

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

На этот раз появился другой текст:

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

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

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

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

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

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

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

От раздражения к диагностике

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

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

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

Сначала работа, потом запрос

Глава 2. Сначала работа, потом запрос

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

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

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

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

— Что именно мы будем считать готовым ответом? Красивый текст или сообщение, в котором клиенту сообщили проверенный статус и не пообещали невозможного?

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

Сначала — результат работы

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

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

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

Мария записала рабочую карточку:

Результат для клиента — понять, где находится заказ и что будет дальше.

Результат в системе обращений — зафиксировать проверенный статус, выполненное действие, ответственного и дату следующего контакта.

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

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

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

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

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

Маршрут одного обращения

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

Первый шаг. Понять, что пришло

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

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

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

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

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

Второй шаг. Отделить сказанное от известного

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

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

Клиент утверждает: доставка не состоялась в ожидаемый день.

Клиент просит: доставить заказ сегодня, а если это невозможно — отменить его и вернуть деньги.

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

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

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

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

Третий шаг. Сверить сведения

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

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

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

— Из какой именно системы она возьмет статус? Что будет, если запись обновится после того, как модель ее прочитает? И кто проверит, что в черновик попали сведения по нужному заказу?

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

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

Четвертый шаг. Выбрать действие

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

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

Ольга обозначила главный риск:

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

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

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

Пятый шаг. Составить ответ и проверить его

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

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

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

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

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

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

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

Шестой шаг. Отправить письмо и закрыть цикл

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

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

Карта маршрута

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

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

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

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

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

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

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

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

Не «дать нейросеть», а выбрать участок

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

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

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

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

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

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

Три вопроса для выбора участка

Прежде чем подключать модель к операции, Мария предложила задать три вопроса.

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

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

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

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

Как понять, что процесс стал лучше

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

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

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

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

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

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

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

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

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

— Если убрать имена и телефоны, этого хватит? — спросила Мария.

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

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

В одном файле — разные типы информации

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

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

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

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

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

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

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

Цель сужает набор данных

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

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

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

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

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

Перед передачей нужно проверить и материал, и инструмент

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

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

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

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

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

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

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

Как принять решение

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

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

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

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

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

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

Когда уместно обезличивание

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

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

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

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

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

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

Синтетический пример — не пересказ реального обращения

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

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

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

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

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

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

Когда правильный ответ — не использовать ИИ

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

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

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

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

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

Где заканчивается роль модели

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

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

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

Как поступила команда Марии

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

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

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

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

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

Контекст без лишней биографии

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

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

«Ответь клиенту на жалобу вежливо и по-человечески».

Илья читает ее дважды.

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

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

— Это объясняет, почему хочется ответить, но не то, что мы вправе сообщить.

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

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

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

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

Что меняет результат

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

— Что именно мы поручаем модели?

— Подготовить первый ответ клиенту, — говорит Мария.

— Не решить вопрос с доставкой, не оценить работу перевозчика и не определить компенсацию?

— Нет. Только подготовить черновик ответа.

— Кому он адресован?

— Клиенту, который ждет заказ и уже обратился в поддержку.

— На каком этапе мы находимся?

Мария открывает карточку обращения, не копируя ее в запрос.

— Согласованное окно доставки прошло. Служба доставки подтвердила задержку. Новый срок пока неизвестен. Команда уже запросила обновление.

Ольга уточняет:

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

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

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

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

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

Проверка на редакторском столе

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

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

Цель: что должен сделать черновик?

Адресат: кто прочтет текст и что ему нужно понять?

Этап: что уже произошло, а что еще проверяется?

Факты: какие сведения подтверждены и влияют на ответ?

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

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

Мария пробует составить первый расширенный вариант:

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

Илья обводит фразу «последние недели у нас выросло число обращений».

— Что модель сделает иначе, если узнает это?

— Наверное, ничего, — признает Мария.

— Тогда убираем. А «в регионе стало больше заказов»?

— Тоже не объясняет задержку именно этого заказа.

Ольга указывает на слова «мы выясняем ситуацию».

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

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

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

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

Когда длиннее — не значит лучше

— Я хотела объяснить модели всю ситуацию, чтобы она не ответила шаблоном, — говорит Мария. — Поэтому дописала, как у нас устроена работа.

Она показывает вторую версию:

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

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

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

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

— Нужна ли здесь история о загруженности команды? — спрашивает Илья.

— Нет, — отвечает Мария. — Клиенту она ничего не объясняет и звучит как оправдание.

— Нужна ли причина задержки?

— Только если она подтверждена.

— А скидка?

— Убираем. Ее нельзя обещать по этому обращению.

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

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

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

Компактная версия

После нескольких правок на экране остается запрос, который Мария может быстро сверить с карточкой обращения:

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

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

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

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

Нейросеть предлагает:

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

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

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

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

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

Один случай, разные адресаты

На следующий день служба доставки подтверждает новое окно: заказ планируют привезти завтра с 10 до 14 часов. Клиент пишет еще раз и просит назвать срок. Факты почти те же, но ситуация изменилась: неизвестный срок стал известен, а задача теперь — не рассказать о проверке, а передать подтвержденное окно.

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

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

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

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

Мария составляет отдельный запрос:

«Сделай краткую внутреннюю сводку для специалиста, который проверяет задержки доставки. Факты: согласованное окно прошло; задержка подтверждена; сначала новый срок отсутствовал, позднее служба доставки сообщила плановое окно на завтра с 10 до 14 часов. Клиент обращался повторно. Выдели хронологию и вопрос, который нужно проверить. Не предполагай причину задержки».

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

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

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

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

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

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

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

Удобный формат короткого брифа

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

Цель — что подготовить или сделать.

Адресат — кто будет читать или использовать результат.

Текущий этап — что уже произошло и что происходит сейчас.

Подтвержденные факты — на что можно опираться.

Неизвестное — какие важные сведения пока не установлены.

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

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

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

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

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

Редакторская проверка на достаточность

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

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

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

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

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

Хороший результат можно узнать заранее

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

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

Первый вариант начинался вежливо и занимал почти весь экран:

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

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

Второй вариант был коротким:

«Здравствуйте. Обращение получено. Информация будет предоставлена после проверки».

«Холодно», — сказала Мария. «Зато всё верно», — ответил Илья. Ольга согласилась насчёт точности, но заметила: клиент спрашивал о субботе, а текст не объясняет, что именно будут проверять и когда ждать ответа. Третье сообщение отвечало на вопрос прямо:

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

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

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

У слова «хорошо» нет готового контрольного списка. Его приходится составлять для конкретной задачи.

От впечатления к приёмке

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

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

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

«Значит, сначала решаем, что ответ должен сделать, — сказала Мария. — Не как он должен ощущаться, а какую задачу выполнить».

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

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