AI в customer support полезен не как автопилот, а как быстрый редактор, классификатор и помощник для базы знаний. Ниже — 10 промптов, которые можно адаптировать под Zendesk, Intercom, Help Scout, Jira Service Management, Notion, Confluence или внутренний чат. Важно: ответы модели требуют проверки человеком, особенно там, где есть деньги, персональные данные, юридические обещания и нестандартные кейсы.
Как выбирать промпт под задачу
| Ситуация | Лучший промпт | Что проверять |
|---|---|---|
| Много входящих тикетов | 1, 2 | Категорию, срочность, признаки эскалации |
| Нужен быстрый ответ клиенту | 3, 4, 5 | Факты, тон, наличие решения |
| Сложный или конфликтный кейс | 6, 7 | Риски, SLA, корректность передачи |
| Повторяются одинаковые вопросы | 8, 9, 10 | Полноту FAQ, актуальность инструкции |
Топ-10 промптов для поддержки
Промпт 1
Когда использовать: для первичной классификации нового тикета.
Ты — ассистент первой линии поддержки. Классифицируй тикет по теме, продукту, срочности и типу запроса. Не придумывай факты. Если данных не хватает, укажи, что нужно уточнить. Тикет: {ticket_text}. Категории: {categories}. Продукты: {products}. SLA: {sla_rules}.
- Переменные: {ticket_text}, {categories}, {products}, {sla_rules}.
- Ожидаемый вывод: категория, подкатегория, приоритет, краткое резюме, недостающие данные.
- Проверка качества: совпадает ли классификация с правилами очередей и SLA.
- Частый сбой: модель повышает приоритет из-за эмоционального тона клиента, а не из-за реального влияния.
Промпт 2
Когда использовать: чтобы понять, кому назначить обращение.
Определи маршрут тикета: первая линия, биллинг, техническая поддержка, продуктовая команда, безопасность или менеджер аккаунта. Используй только текст обращения и правила маршрутизации. Обращение: {ticket_text}. Правила: {routing_rules}. Верни причину выбора и альтернативный маршрут, если уверенность ниже 80%.
- Переменные: {ticket_text}, {routing_rules}.
- Ожидаемый вывод: команда, уровень уверенности, причина, альтернативный маршрут.
- Проверка качества: есть ли у выбранной команды право и компетенция решать кейс.
- Частый сбой: смешение технической ошибки и вопроса по оплате в одном маршруте.
Промпт 3
Когда использовать: для черновика ответа на типовой тикет.
Составь черновик ответа клиенту на русском языке. Тон: {tone}. Цель: помочь решить проблему, не обещая того, чего нет в политике. Факты: {known_facts}. Инструкция: {support_article}. Вопрос клиента: {customer_message}. Если решения нет, предложи следующий безопасный шаг.
- Переменные: {tone}, {known_facts}, {support_article}, {customer_message}.
- Ожидаемый вывод: приветствие, ответ, шаги, вопрос на уточнение или закрывающая фраза.
- Проверка качества: все рекомендации есть в базе знаний или внутренней политике.
- Частый сбой: модель добавляет несуществующие сроки, скидки или функции.
Промпт 4
Когда использовать: когда оператор написал ответ, но нужно улучшить тон.
Отредактируй ответ оператора так, чтобы он был ясным, спокойным и эмпатичным. Сохрани смысл, не добавляй новых обещаний и не убирай важные ограничения. Исходный ответ: {agent_reply}. Контекст клиента: {customer_context}. Стиль бренда: {brand_voice}.
- Переменные: {agent_reply}, {customer_context}, {brand_voice}.
- Ожидаемый вывод: улучшенная версия и список измененных формулировок.
- Проверка качества: ответ звучит по-человечески и не обвиняет клиента.
- Частый сбой: чрезмерно сладкий тон, который не подходит B2B или критическому инциденту.
Промпт 5
Когда использовать: для коротких ответов в чате, где важна скорость.
Подготовь короткий ответ для live chat. Максимум {max_sentences} предложения. Сначала признай проблему, затем дай один следующий шаг. Не используй канцелярит. Вопрос клиента: {customer_message}. Доступные действия оператора: {allowed_actions}.
- Переменные: {max_sentences}, {customer_message}, {allowed_actions}.
- Ожидаемый вывод: лаконичная реплика без длинной инструкции.
- Проверка качества: клиент понимает, что делать прямо сейчас.
- Частый сбой: ответ слишком общий: «попробуйте позже» без полезного шага.
Промпт 6
Когда использовать: для выявления кейсов, которые нельзя оставлять на первой линии.
Проверь тикет на признаки обязательной эскалации. Сигналы: персональные данные, безопасность, платежный спор, массовый сбой, юридическая претензия, VIP-клиент, нарушение SLA, негатив в публичном канале. Тикет: {ticket_text}. Правила эскалации: {escalation_policy}. Верни решение: эскалировать или нет, причину и срочность.
- Переменные: {ticket_text}, {escalation_policy}.
- Ожидаемый вывод: флаг эскалации, риск, кому передать, что приложить.
- Проверка качества: не пропущены безопасность, платежи и юридические формулировки.
- Частый сбой: модель не замечает скрытую угрозу репутации в эмоциональном тексте.
Промпт 7
Когда использовать: при передаче сложного тикета другой команде.
Сделай внутреннее резюме тикета для эскалации. Не пиши клиенту. Укажи: кто клиент, что случилось, что уже проверено, какие действия выполнены, что требуется от следующей команды, дедлайн по SLA. Данные: {case_notes}. История переписки: {conversation_history}.
- Переменные: {case_notes}, {conversation_history}.
- Ожидаемый вывод: структурированная заметка без лишних эмоций.
- Проверка качества: следующей команде не нужно перечитывать всю переписку.
- Частый сбой: в резюме попадает субъективная оценка клиента вместо фактов.
Промпт 8
Когда использовать: чтобы найти пробелы в базе знаний по повторяющимся тикетам.
Проанализируй список обращений и найди вопросы, которые повторяются, но плохо покрыты базой знаний. Обращения: {tickets_sample}. Существующие статьи: {kb_index}. Верни темы для новых статей, частотность, пример формулировки клиента и приоритет.
- Переменные: {tickets_sample}, {kb_index}.
- Ожидаемый вывод: список тем, частые формулировки, приоритет обновления.
- Проверка качества: темы действительно повторяются, а не являются единичными исключениями.
- Частый сбой: модель предлагает статьи, которые уже есть, но называются иначе.
Промпт 9
Когда использовать: для черновика FAQ по продукту или функции.
Создай FAQ на основе материалов ниже. Пиши простыми вопросами клиентов и короткими ответами. Не добавляй информацию, которой нет в источниках. Материалы: {source_docs}. Аудитория: {audience}. Ограничения продукта: {limitations}. Верни 8–12 вопросов и ответы до 700 знаков каждый.
- Переменные: {source_docs}, {audience}, {limitations}.
- Ожидаемый вывод: список вопросов и ответов, готовый к редактуре.
- Проверка качества: каждый ответ можно подтвердить ссылкой на источник.
- Частый сбой: FAQ становится рекламным текстом вместо справки.
Промпт 10
Когда использовать: для обновления устаревшей статьи базы знаний.
Сравни старую статью и новые правила. Предложи обновленную версию, отметь спорные места и вопросы к владельцу продукта. Старая статья: {old_article}. Новые правила: {new_policy}. Стиль базы знаний: {kb_style}. Не удаляй предупреждения и ограничения без явной причины.
- Переменные: {old_article}, {new_policy}, {kb_style}.
- Ожидаемый вывод: новая статья, список изменений, вопросы на согласование.
- Проверка качества: инструкция актуальна, последовательна и не ломает существующие процессы.
- Частый сбой: модель сглаживает важные ограничения, чтобы текст выглядел проще.
Как внедрять без хаоса
Начните с черновиков и внутренней классификации, а не с автоматической отправки клиентам. Для каждого промпта заведите владельца, набор тестовых тикетов и правило: модель предлагает, оператор утверждает. Полезно хранить удачные ответы как шаблоны, но регулярно пересматривать их после изменений продукта.
Запуск: чеклист
- Определите, какие данные можно передавать в AI-инструмент, а какие нужно маскировать.
- Опишите категории, маршруты, SLA, тон бренда и запреты на обещания.
- Протестируйте промпты на реальных обезличенных тикетах.
- Добавьте обязательную проверку человеком перед ответом клиенту.
- Отслеживайте ошибки: неверная категория, лишнее обещание, пропущенная эскалация, устаревшая статья.
FAQ
Можно ли отправлять клиенту ответ модели без оператора? В большинстве процессов лучше не начинать с этого. Безопаснее использовать AI для черновика, а финальное решение оставлять сотруднику.
Что важнее: длинный промпт или хорошие данные? Хорошие данные. Даже сильный промпт плохо работает, если в нем нет актуальных правил, контекста тикета и ограничений.
Как понять, что промпт пора менять? Если операторы часто переписывают один и тот же блок, модель путает маршруты или база знаний изменилась, промпт нужно обновить.
Источники и ограничения
При подготовке структуры учитывались общие рекомендации по prompt engineering и автоматизации поддержки: OpenAI: best practices for prompts, Zapier: AI prompt templates, Zapier: how to prompt AI. Это не универсальные гарантии качества: результат зависит от модели, настроек, входных данных, языка, полноты базы знаний и внутренних правил компании. Любой AI-вывод требует человеческой проверки перед использованием в customer support.