Топ-10 промптов для customer support и базы знаний

<p>AI в customer support полезен не как автопилот, а как быстрый редактор, классификатор и помощник для базы знаний. Ниже — 10 промптов, которые можно адаптировать под Zendesk, Intercom, Help Scout, Jira Service Management, Notion, Confluence или внутренний чат. Важно: ответы модели требуют проверки человеком, особенно там, где есть деньги, персональные данные, юридические обещания и нестандартные кейсы.</p><h2>Как выбирать промпт под задачу</h2><table><thead><tr><th>Ситуация</th><th>Лучший промпт</th><th>Что проверять</th></tr></thead><tbody><tr><td>Много входящих тикетов</td><td>1, 2</td><td>Категорию, срочность, признаки эскалации</td></tr><tr><td>Нужен быстрый ответ клиенту</td><td>3, 4, 5</td><td>Факты, тон, наличие решения</td></tr><tr><td>Сложный или конфликтный кейс</td><td>6, 7</td><td>Риски, SLA, корректность передачи</td></tr><tr><td>Повторяются одинаковые вопросы</td><td>8, 9, 10</td><td>Полноту FAQ, актуальность инструкции</td></tr></tbody></table><h2>Топ-10 промптов для поддержки</h2><h3>Промпт 1</h3><p><strong>Когда использовать:</strong> для первичной классификации нового тикета.</p><blockquote>Ты — ассистент первой линии поддержки. Классифицируй тикет по теме, продукту, срочности и типу запроса. Не придумывай факты. Если данных не хватает, укажи, что нужно уточнить. Тикет: {ticket_text}. Категории: {categories}. Продукты: {products}. SLA: {sla_rules}.</blockquote><ul><li><strong>Переменные:</strong> {ticket_text}, {categories}, {products}, {sla_rules}.</li><li><strong>Ожидаемый вывод:</strong> категория, подкатегория, приоритет, краткое резюме, недостающие данные.</li><li><strong>Проверка качества:</strong> совпадает ли классификация с правилами очередей и SLA.</li><li><strong>Частый сбой:</strong> модель повышает приоритет из-за эмоционального тона клиента, а не из-за реального влияния.</li></ul><h3>Промпт 2</h3><p><strong>Когда использовать:</strong> чтобы понять, кому назначить обращение.</p><code>Определи маршрут тикета: первая линия, биллинг, техническая поддержка, продуктовая команда, безопасность или менеджер аккаунта. Используй только текст обращения и правила маршрутизации. Обращение: {ticket_text}. Правила: {routing_rules}. Верни причину выбора и альтернативный маршрут, если уверенность ниже 80%.</code><ul><li><strong>Переменные:</strong> {ticket_text}, {routing_rules}.</li><li><strong>Ожидаемый вывод:</strong> команда, уровень уверенности, причина, альтернативный маршрут.</li><li><strong>Проверка качества:</strong> есть ли у выбранной команды право и компетенция решать кейс.</li><li><strong>Частый сбой:</strong> смешение технической ошибки и вопроса по оплате в одном маршруте.</li></ul><h3>Промпт 3</h3><p><strong>Когда использовать:</strong> для черновика ответа на типовой тикет.</p><blockquote>Составь черновик ответа клиенту на русском языке. Тон: {tone}. Цель: помочь решить проблему, не обещая того, чего нет в политике. Факты: {known_facts}. Инструкция: {support_article}. Вопрос клиента: {customer_message}. Если решения нет, предложи следующий безопасный шаг.</blockquote><ul><li><strong>Переменные:</strong> {tone}, {known_facts}, {support_article}, {customer_message}.</li><li><strong>Ожидаемый вывод:</strong> приветствие, ответ, шаги, вопрос на уточнение или закрывающая фраза.</li><li><strong>Проверка качества:</strong> все рекомендации есть в базе знаний или внутренней политике.</li><li><strong>Частый сбой:</strong> модель добавляет несуществующие сроки, скидки или функции.</li></ul><h3>Промпт 4</h3><p><strong>Когда использовать:</strong> когда оператор написал ответ, но нужно улучшить тон.</p><code>Отредактируй ответ оператора так, чтобы он был ясным, спокойным и эмпатичным. Сохрани смысл, не добавляй новых обещаний и не убирай важные ограничения. Исходный ответ: {agent_reply}. Контекст клиента: {customer_context}. Стиль бренда: {brand_voice}.</code><ul><li><strong>Переменные:</strong> {agent_reply}, {customer_context}, {brand_voice}.</li><li><strong>Ожидаемый вывод:</strong> улучшенная версия и список измененных формулировок.</li><li><strong>Проверка качества:</strong> ответ звучит по-человечески и не обвиняет клиента.</li><li><strong>Частый сбой:</strong> чрезмерно сладкий тон, который не подходит B2B или критическому инциденту.</li></ul><h3>Промпт 5</h3><p><strong>Когда использовать:</strong> для коротких ответов в чате, где важна скорость.</p><blockquote>Подготовь короткий ответ для live chat. Максимум {max_sentences} предложения. Сначала признай проблему, затем дай один следующий шаг. Не используй канцелярит. Вопрос клиента: {customer_message}. Доступные действия оператора: {allowed_actions}.</blockquote><ul><li><strong>Переменные:</strong> {max_sentences}, {customer_message}, {allowed_actions}.</li><li><strong>Ожидаемый вывод:</strong> лаконичная реплика без длинной инструкции.</li><li><strong>Проверка качества:</strong> клиент понимает, что делать прямо сейчас.</li><li><strong>Частый сбой:</strong> ответ слишком общий: «попробуйте позже» без полезного шага.</li></ul><h3>Промпт 6</h3><p><strong>Когда использовать:</strong> для выявления кейсов, которые нельзя оставлять на первой линии.</p><code>Проверь тикет на признаки обязательной эскалации. Сигналы: персональные данные, безопасность, платежный спор, массовый сбой, юридическая претензия, VIP-клиент, нарушение SLA, негатив в публичном канале. Тикет: {ticket_text}. Правила эскалации: {escalation_policy}. Верни решение: эскалировать или нет, причину и срочность.</code><ul><li><strong>Переменные:</strong> {ticket_text}, {escalation_policy}.</li><li><strong>Ожидаемый вывод:</strong> флаг эскалации, риск, кому передать, что приложить.</li><li><strong>Проверка качества:</strong> не пропущены безопасность, платежи и юридические формулировки.</li><li><strong>Частый сбой:</strong> модель не замечает скрытую угрозу репутации в эмоциональном тексте.</li></ul><h3>Промпт 7</h3><p><strong>Когда использовать:</strong> при передаче сложного тикета другой команде.</p><blockquote>Сделай внутреннее резюме тикета для эскалации. Не пиши клиенту. Укажи: кто клиент, что случилось, что уже проверено, какие действия выполнены, что требуется от следующей команды, дедлайн по SLA. Данные: {case_notes}. История переписки: {conversation_history}.</blockquote><ul><li><strong>Переменные:</strong> {case_notes}, {conversation_history}.</li><li><strong>Ожидаемый вывод:</strong> структурированная заметка без лишних эмоций.</li><li><strong>Проверка качества:</strong> следующей команде не нужно перечитывать всю переписку.</li><li><strong>Частый сбой:</strong> в резюме попадает субъективная оценка клиента вместо фактов.</li></ul><h3>Промпт 8</h3><p><strong>Когда использовать:</strong> чтобы найти пробелы в базе знаний по повторяющимся тикетам.</p><code>Проанализируй список обращений и найди вопросы, которые повторяются, но плохо покрыты базой знаний. Обращения: {tickets_sample}. Существующие статьи: {kb_index}. Верни темы для новых статей, частотность, пример формулировки клиента и приоритет.</code><ul><li><strong>Переменные:</strong> {tickets_sample}, {kb_index}.</li><li><strong>Ожидаемый вывод:</strong> список тем, частые формулировки, приоритет обновления.</li><li><strong>Проверка качества:</strong> темы действительно повторяются, а не являются единичными исключениями.</li><li><strong>Частый сбой:</strong> модель предлагает статьи, которые уже есть, но называются иначе.</li></ul><h3>Промпт 9</h3><p><strong>Когда использовать:</strong> для черновика FAQ по продукту или функции.</p><blockquote>Создай FAQ на основе материалов ниже. Пиши простыми вопросами клиентов и короткими ответами. Не добавляй информацию, которой нет в источниках. Материалы: {source_docs}. Аудитория: {audience}. Ограничения продукта: {limitations}. Верни 8–12 вопросов и ответы до 700 знаков каждый.</blockquote><ul><li><strong>Переменные:</strong> {source_docs}, {audience}, {limitations}.</li><li><strong>Ожидаемый вывод:</strong> список вопросов и ответов, готовый к редактуре.</li><li><strong>Проверка качества:</strong> каждый ответ можно подтвердить ссылкой на источник.</li><li><strong>Частый сбой:</strong> FAQ становится рекламным текстом вместо справки.</li></ul><h3>Промпт 10</h3><p><strong>Когда использовать:</strong> для обновления устаревшей статьи базы знаний.</p><code>Сравни старую статью и новые правила. Предложи обновленную версию, отметь спорные места и вопросы к владельцу продукта. Старая статья: {old_article}. Новые правила: {new_policy}. Стиль базы знаний: {kb_style}. Не удаляй предупреждения и ограничения без явной причины.</code><ul><li><strong>Переменные:</strong> {old_article}, {new_policy}, {kb_style}.</li><li><strong>Ожидаемый вывод:</strong> новая статья, список изменений, вопросы на согласование.</li><li><strong>Проверка качества:</strong> инструкция актуальна, последовательна и не ломает существующие процессы.</li><li><strong>Частый сбой:</strong> модель сглаживает важные ограничения, чтобы текст выглядел проще.</li></ul><h2>Как внедрять без хаоса</h2><p>Начните с черновиков и внутренней классификации, а не с автоматической отправки клиентам. Для каждого промпта заведите владельца, набор тестовых тикетов и правило: модель предлагает, оператор утверждает. Полезно хранить удачные ответы как шаблоны, но регулярно пересматривать их после изменений продукта.</p><h2>Запуск: чеклист</h2><ul><li>Определите, какие данные можно передавать в AI-инструмент, а какие нужно маскировать.</li><li>Опишите категории, маршруты, SLA, тон бренда и запреты на обещания.</li><li>Протестируйте промпты на реальных обезличенных тикетах.</li><li>Добавьте обязательную проверку человеком перед ответом клиенту.</li><li>Отслеживайте ошибки: неверная категория, лишнее обещание, пропущенная эскалация, устаревшая статья.</li></ul><h2>FAQ</h2><p><strong>Можно ли отправлять клиенту ответ модели без оператора?</strong> В большинстве процессов лучше не начинать с этого. Безопаснее использовать AI для черновика, а финальное решение оставлять сотруднику.</p><p><strong>Что важнее: длинный промпт или хорошие данные?</strong> Хорошие данные. Даже сильный промпт плохо работает, если в нем нет актуальных правил, контекста тикета и ограничений.</p><p><strong>Как понять, что промпт пора менять?</strong> Если операторы часто переписывают один и тот же блок, модель путает маршруты или база знаний изменилась, промпт нужно обновить.</p><h2>Источники и ограничения</h2><p>При подготовке структуры учитывались общие рекомендации по prompt engineering и автоматизации поддержки: <a href="https://help.openai.com/en/articles/10032626-prompt-engineering-best-practices-for-chatgpt">OpenAI: best practices for prompts</a>, <a href="https://zapier.com/blog/ai-prompt-templates/">Zapier: AI prompt templates</a>, <a href="https://help.zapier.com/hc/en-us/articles/36532133250317-How-to-prompt-AI-in-Zapier-products">Zapier: how to prompt AI</a>. Это не универсальные гарантии качества: результат зависит от модели, настроек, входных данных, языка, полноты базы знаний и внутренних правил компании. Любой AI-вывод требует человеческой проверки перед использованием в customer support.</p>