Ваш бот хорош ровно настолько, насколько хорош его промпт: руководство по AI в клиентском сервисе

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

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

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

Введение

Есть особый вид боли: вы демонстрируете бота поддержки стейкхолдерам, он работает идеально, вы деплоите — и наблюдаете, как он один за другим вскрывает все edge cases, о которых вы не подумали.

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

Ни один из этих провалов не является провалом LLM. Это провалы промпта. И все они полностью предотвратимы.

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

Чем промптинг для клиентской поддержки отличается

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

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

1. Выдуманные политики — Бот уверенно сообщает несуществующую политику, потому что промпт не определил, что делать, когда бот чего-то не знает.
2. Нестабильный тон — Личность бота плывёт от диалога к диалогу, потому что персона была определена слишком расплывчато.
3. Сломанная передача диалога — Бот пытается решить задачи, которые не в его компетенции, или не понимает, когда передать диалог человеку.

Каждый раздел этого руководства адресует хотя бы один из этих режимов.

Дизайн персоны бота

Самое важное решение при создании бота поддержки — не какую модель использовать и не как обрабатывать возвраты. Это кем является бот.

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

Четыре решения персоны

1. Имя и роль

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

❌

Ты полезный помощник нашего магазина.

✅

Ты — Миа, специалист поддержки клиентов Lumino Home. Ты помогаешь клиентам с заказами, возвратами и вопросами о товарах.

2. Тон

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

❌

Будь дружелюбным и профессиональным.

✅

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

3. Область знаний

Явно определите, что бот знает, и — критически важно — чего не знает. Здесь происходит предотвращение галлюцинаций.

✅

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

4. Жёсткие ограничения

Скажите боту, чего он никогда не делает. Конкретно.

✅

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

Пример полного блока персоны

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

Ты — Миа, специалист поддержки клиентов Lumino Home — бренда товаров для дома и мебели.

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

Ты помогаешь клиентам с:
- Статусом и отслеживанием заказа
- Возвратами и обменами (политика: 30 дней, неиспользованный товар, оригинальная упаковка)
- Наличием и характеристиками товаров
- Сроками и способами доставки

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

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

Всегда отвечай на том языке, на котором пишет клиент.
Сообщения должны быть лаконичными. Для WhatsApp — 1–3 предложения, если только длинный ответ не является действительно необходимым.

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

Обработка нестандартных ситуаций и передача диалога

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

Правило передачи диалога

Явное всегда лучше неявного.

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

Определите триггеры эскалации явно:

Немедленно передавай диалог (не пытайся решить самостоятельно), когда:
- Клиент запрашивает возврат или компенсацию на сумму свыше 5000 ₽
- Клиент упоминает юридический спор, официальную жалобу или использует слово «суд»
- Клиент выразил злость в 2 или более подряд идущих сообщениях
- Запрос касается заказа, сделанного более 90 дней назад
- У тебя нет информации, необходимой для точного ответа

Паттерн сообщения при передаче диалога

При эскалации бот должен:

1. Признать ситуацию без ложных обещаний
2. Чётко сообщить, что поможет человек
3. Установить ожидание (время ожидания, следующий шаг)
4. Не пытаться предварительно решить проблему

Шаблон сообщения при передаче:
«Хочу убедиться, что это решится как следует — соединяю тебя со специалистом прямо сейчас.
[Время ожидания / следующий шаг]. Есть что-то, что мне стоит отметить для них заранее?»

Что НЕ нужно делать

❌

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

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

❌

«Сейчас проверю для тебя.»

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

Паттерн «Я не знаю + вот что я сделаю» всегда лучше уверенного неправильного ответа.

Few-shot примеры для WhatsApp и Instagram

Инструкции говорят модели, что делать. Примеры показывают модели, как выглядит «правильно» в вашем конкретном контексте. Для channel-specific тона — где сообщения в WhatsApp короткие, неформальные и mobile-first — few-shot примеры зачастую эффективнее инструкций.

Анатомия хорошего few-shot примера

Каждый пример должен быть реалистичным сообщением клиента (не учебниковым запросом), за которым следует ответ, демонстрирующий именно тот тон, длину и обработку, которые вы хотите:

Клиент: привет когда придёт мой заказ
Миа: Привет! Твой заказ №4821 отправлен вчера — ожидаемая доставка завтра до 20:00. 📦 Отправлю тебе ссылку на отслеживание — хочешь?

Что делает этот пример хорошим:

• Неформальное приветствие соответствует регистру клиента
• Использует номер заказа (показывает, что проверил)
• Конкретная дата доставки (не «через несколько дней»)
• Проактивное предложение (ссылка на отслеживание)
• Заканчивается вопросом, чтобы держать диалог открытым
• Один короткий абзац

Пять проработанных примеров

Статус заказа:

Клиент: где мой заказ
Миа: Привет! Дай мне проверить — можешь поделиться номером заказа или email, который использовал при оформлении?

Запрос на возврат:

Клиент: хочу вернуть лампу которую купил на прошлой неделе
Миа: Конечно! Возврат в течение 30 дней оформляется быстро. Можешь назвать номер заказа, чтобы я нашла детали?

Наличие товара:

Клиент: полка дуб есть в белом цвете
Миа: Да! Полка Nomad доступна в цвете дуб и матовом белом — оба варианта сейчас в наличии. Отправить ссылку?

Расстроенный клиент:

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

(Не пытается решить проблему, признаёт эмоцию, корректно эскалирует)

Не по теме / вне компетенции:

Клиент: есть сейчас промокоды
Миа: У меня нет доступа к актуальным акциям, но на сайте обычно отображаются активные скидки при оформлении! За свежими предложениями можно также заглянуть в наш Instagram. Могу ещё чем-то помочь?

(Честно о том, чего не знает, предлагает альтернативу, сохраняет тёплый тон)

Антипримеры: как плохой промпт обрабатывает те же сообщения

То же сообщение «расстроенного клиента» с обобщённым промптом:

❌

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

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

Как формировать библиотеку few-shot примеров

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

Начните с 5–8 примеров, охватывающих самые частые типы запросов плюс 2–3 нестандартных ситуации. Расширяйте библиотеку по мере появления новых паттернов в продакшн-трафике.

Управление контекстом в многоходовых диалогах

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

Что происходит при заполнении контекстного окна

У каждой LLM есть ограничение контекстного окна. Для WhatsApp-диалога, который растягивается на часы или дни, вы можете его исчерпать. Тогда модель теряет доступ к ранней истории разговора — и клиенту приходится повторяться.

Стратегии

Инъекция резюме разговора: Через регулярные промежутки (или при превышении порога использования контекста) генерируйте резюме диалога и инжектируйте его в начало контекста:

[Резюме разговора]
Клиент: Алексей. Проблема: Заказ №4821 опоздал второй раз подряд.
Предоставленный контекст: детали заказа подтверждены, принесены извинения, поставлен в очередь к специалисту.
Текущий статус: ожидает доступности специалиста.

Явное отслеживание состояния: Для транзакционных потоков (возвраты, обмены) поддерживайте состояние в структурированном JSON-блоке, который сохраняется между ходами:

{
  "customer_name": "Алексей",
  "order_id": "4821",
  "issue_type": "late_delivery",
  "escalated": true,
  "specialist_queue": "senior_support"
}

Сброс сессии по таймауту: Определите чёткие границы сессии. Если клиент не писал 2+ часа — начинайте свежее контекстное окно. Не предполагайте, что тот же разговор продолжается.

Удержание контекста на практике

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

Ход 1 — Клиент: хочу вернуть заказ 4821
Ход 1 — Миа: [Инициирует процесс возврата, фиксирует номер заказа]

Ход 6 — Клиент: а до какого числа можно вернуть?
Ход 6 — Миа: Твой заказ был оформлен 3 марта, так что у тебя время до 2 апреля — в пределах 30 дней. Оформляем возврат?

В ходе 6 бот знает дату заказа из хода 1. Это ожидаемое поведение. Без явного управления контекстом он может снова спросить «какой заказ?»

Структурированный вывод для автоматизированных пайплайнов

Если бот клиентской поддержки передаёт данные в downstream-систему — CRM, тикетинг, движок маршрутизации или аналитику — натурального текста ответа недостаточно. Нужен структурированный вывод.

Паттерн двойного вывода

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

После каждого сообщения клиента отвечай двумя чётко разделёнными частями:

ОТВЕТ:
[Сообщение для клиента — короткое, разговорное, в рамках бренда]

МЕТАДАННЫЕ:
{
  "intent": "<order_status|return_request|product_question|complaint|escalate|other>",
  "order_id": "<номер заказа, если упоминался, null иначе>",
  "customer_sentiment": "<positive|neutral|negative|angry>",
  "escalate": <true|false>,
  "escalation_reason": "<причина, если escalate = true, null иначе>"
}

Клиент видит ОТВЕТ. Ваша система автоматизации читает МЕТАДАННЫЕ.

Что дают метаданные

• Маршрутизация интентов: Высокочастотные интенты (статус заказа) идут в автоматическое разрешение; эскалационные — в очередь к человеку
• Трекинг сентимента: Агрегированный сентимент по разговорам для выявления системных проблем
• Обновления CRM: Автоматическое создание тикета при escalate = true
• Аналитика: Понимание того, о чём на самом деле спрашивают клиенты

Тестирование структурированного вывода

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

• Вернуть МЕТАДАННЫЕ как code block вместо inline JSON
• Использовать другие названия ключей
• Пропустить ключ, когда не уверена в значении

Тестируйте логику парсинга против полного вывода — не только «счастливого пути». Используйте валидацию схемы как первоклассный тест (см. статью о тестировании LLM для паттернов реализации).

Чеклист тестирования перед деплоем

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

Сценарий 1: Стандартный запрос

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

assert бот_отвечает_на_вопрос_корректно AND оценка_тона >= 0.8

Сценарий 2: Выход за рамки темы

Ввод: Что-то полностью вне определённой области компетенции
Ожидание: Корректное признание + перенаправление или эскалация (не выдуманный ответ)
Тест:

assert "escalate" in метаданные OR ответ содержит перенаправление

Сценарий 3: Агрессивный / расстроенный клиент

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

assert сентимент_ответа нейтральный или позитивный AND эскалация через N злых ходов

Сценарий 4: Неизвестный вопрос о политике

Ввод: Вопрос о политике, информации о которой нет в промпте
Ожидание: Честное «не знаю» + эскалация или перенаправление
Тест:

assert ответ не содержит выдуманной информации о политике

(метрика галлюцинаций GEval)

Сценарий 5: Смена языка

Ввод: Клиент переходит на другой язык в середине разговора
Ожидание: Бот отвечает на новом языке с этого момента
Тест:

assert язык_ответа == язык_сообщения_клиента

Сценарий 6: Многоходовая согласованность

Ввод: Разговор из 5–8 ходов, где ход 5 ссылается на информацию из хода 1
Ожидание: Бот корректно использует ранний контекст
Тест:

assert ответ в ходе 5 корректно использует данные из хода 1

Сценарий 7: Целостность структурированного вывода

Ввод: Любое стандартное сообщение клиента
Ожидание: МЕТАДАННЫЕ — валидный JSON со всеми необходимыми ключами
Тест:

assert json.loads(метаданные) валиден AND все обязательные ключи присутствуют

Автоматизация чеклиста

Используйте GEval-метрики DeepEval для автоматизации сценариев 3 и 4 — стабильность тона и обнаружение галлюцинаций требуют семантической оценки, которую простые assert-тесты не поймают. Паттерны реализации, включая установку порогов, описаны в нашей статье о тестировании LLM.

Частые ошибки и как их избежать

❌ «Будь полезным и дружелюбным»
Слишком расплывчато. Модель интерпретирует «полезный» как «всегда давай ответ» — что ведёт к выдуманным политикам. Замените явными границами области знаний и паттерном «я не знаю».

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

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

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

❌ Откладывание структурированного вывода «на потом»
Добавление структурированного вывода постфактум требует переработки downstream-систем и переписывания промпта. Если вы знаете, что понадобится маршрутизация или интеграция с CRM — стройте паттерн двойного вывода сразу.

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

Заключение

Три принципа для продакшн-промптов клиентской поддержки:

1. Явное лучше неявного — Определяйте персону, область знаний, ограничения и триггеры эскалации конкретно. Модель заполнит каждый пробел своей лучшей догадкой.
2. Тест до деплоя — Прогоните все семь сценариев до любого запуска для клиентов. Автоматизируйте тестирование тона и галлюцинаций через GEval.
3. Проектируй провал в первую очередь — Стройте путь эскалации до счастливого пути. Ваши нестандартные ситуации — это чей-то обычный день.

О техниках промптинга, стоящих за этими паттернами, читайте в «Промптинг: действительно полезное руководство». О том, как построить набор тестов для валидации бота перед запуском — в статье «Как ухватить LLM за хвост: эффективные стратегии тестирования AI-моделей».

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