ИИ-промпты для профессии: Поддержка

Составьте ответ для первого контакта по заявке на тему [[TICKET_TOPIC]]. 1. Подтвердите конкретную проблему пользователя: `[[USER_ISSUE_SUMMARY]]`. 2. Подтвердите получение их заявки и укажите ID заявки: `[[TICKET_ID]]`. 3. Укажите наше стандартное время ответа для этого типа проблемы: `[[RESPONSE_TIME_SLA]]`. 4. Если известно, упомяните специалиста или команду, которой она была передана: `[[ROUTED_TEAM]]`. 5. Сохраняйте эмпатичный и профессиональный тон. Не обещайте решения, только последующее уведомление.

В запросе пользователя по поводу `[[TICKET_TOPIC]]` отсутствует ключевая информация. Составьте вежливый ответ, который: 1. Поблагодарит их за сообщение. 2. Четко укажет конкретную информацию, необходимую для продолжения. Перечислите ее в виде маркированного списка: * `[[REQUIRED_INFO_1]]` * `[[REQUIRED_INFO_2]]` * `[[REQUIRED_INFO_3]]` 3. Кратко объяснит, *почему* нам нужна эта информация (например, "чтобы найти ваш аккаунт", "чтобы воспроизвести ошибку"). 4. Заверит их, что их заявка будет обработана в приоритетном порядке после получения информации.

Сгенерируйте пошаговое руководство, отвечающее на вопрос пользователя: `[[USER_QUESTION]]`. Пользователь использует тарифный план `[[USER_PLAN_LEVEL]]`. 1. Начните с прямого подтверждения: "Да, вы можете это сделать. Вот шаги:" 2. Используйте нумерованный список для шагов. 3. Ссылайтесь на конкретные элементы пользовательского интерфейса по названию (например, "Нажмите 'Настройки' на главной панели"). 4. Если доступно, дайте ссылку на соответствующую статью базы знаний: `[[KB_ARTICLE_URL]]`. 5. Завершите приглашением задавать дополнительные вопросы.

Мы только что решили общесистемную проблему: `[[ISSUE_DESCRIPTION]]`. Составьте проактивное сообщение пользователю, которого затронула эта проблема. 1. Укажите исходный ID заявки: `[[TICKET_ID]]`. 2. Кратко сообщите, что проблема, о которой они сообщали, теперь должна быть решена. 3. Попросите их подтвердить, работает ли все, как ожидалось, с их стороны. 4. Предоставьте прямую ссылку, где они могут проверить исправление: `[[TESTING_URL]]`. 5. Поблагодарите их за терпение.

Сгенерируйте соответствующее требованиям сообщение для первого контакта, включающее раскрытие информации об ИИ. Пользователь спрашивает о `[[TICKET_TOPIC]]`. 1. Начните с четкого раскрытия информации, например: "Вы взаимодействуете с ИИ-помощником от [[COMPANY_NAME]]". 2. Предоставьте немедленную возможность эскалации к живому агенту (например, "Вы можете запросить живого оператора в любое время."). 3. Затем перейдите к ответу на первоначальный запрос пользователя на основе предоставленного контекста. 4. Сохраняйте все сообщение кратким и ясным.

Пользователь выражает значительное разочарование по поводу `[[USER_ISSUE]]`. Он уже обращался к нам `[[NUMBER_OF_CONTACTS]]` раз. Составьте эмпатичный ответ, который: 1. Использует фразы, подтверждающие их чувства (например, "Я понимаю, насколько это должно быть неприятно", "Вы правы, что расстроены."). 2. Явно извиняется за негативный опыт, не признавая вины за основную проблему. Пример: "Мне жаль, что это доставило вам неудобства." 3. Суммирует проблему своими словами, чтобы показать, что я ее понял: `[[PROBLEM_SUMMARY]]`. 4. Указывает немедленное следующее действие, которое я лично предпринимаю: `[[AGENT_ACTION]]`.

Проанализируйте следующий ответ агента и перепишите его, чтобы он был более эмпатичным и менее роботизированным. Исходный ответ: `[[ORIGINAL_RESPONSE]]` Ситуация пользователя: `[[USER_SITUATION]]` Сосредоточьтесь на: 1. Замене корпоративного жаргона на простой язык. 2. Добавлении предложения, которое признает эмоциональное состояние пользователя (например, разочарование, замешательство). 3. Обеспечении точности основного сообщения и любых инструкций.

Составьте ответ, информирующий пользователя о том, что запрашиваемая им функция `[[REQUESTED_FEATURE]]` в настоящее время недоступна. 1. Начните с эмпатии и подтверждения ("Это отличная идея" или "Я понимаю, насколько это было бы полезно"). 2. Четко, но мягко укажите, что функция на данный момент не существует. 3. Предложите жизнеспособное обходное решение, если оно есть: `[[WORKAROUND_STEPS]]`. Если обходного решения нет, четко укажите это. 4. Объясните, что вы официально регистрируете их запрос в команде продукта. Упомяните, что их обратная связь ценна. 5. Не указывайте сроки и не обещайте, что это будет реализовано.

Пользователь жалуется на плохой опыт взаимодействия с предыдущим агентом поддержки или на предыдущее взаимодействие. Его ссылка: `[[PREVIOUS_TICKET_ID]]`. Составьте ответ, который: 1. Извиняется за то, что предыдущий опыт не оправдал их ожиданий. 2. Не обвиняет предыдущего агента. Сосредоточьтесь на опыте пользователя. 3. Принимает ответственность за проблему сейчас. ("Я взял на себя ответственность за эту заявку, чтобы довести ее до конца.") 4. Просит краткое изложение нерешенной проблемы, чтобы убедиться, что у вас есть полный контекст, не заставляя их повторять все.

Пользователь оспаривает списание `[[CHARGE_AMOUNT]]` от `[[CHARGE_DATE]]`. Составьте четкое объяснение. 1. Укажите конкретный номер счета или заказа: `[[INVOICE_ID]]`. 2. Разбейте списание на отдельные позиции из счета (например, "Подписка на Pro Plan: $XX", "Плата за перерасход: $Y"). 3. Дайте ссылку на соответствующие условия обслуживания или страницу с ценами, объясняющую это списание: `[[POLICY_URL]]`. 4. Используйте простой, прямой язык. Избегайте бухгалтерского жаргона.

Пользователь имеет право на возврат средств за `[[PRODUCT/SERVICE]]` в соответствии с нашей политикой. Составьте сообщение, подтверждающее возврат. 1. Четко укажите, что возврат обработан. 2. Укажите сумму возвращаемых средств: `[[REFUND_AMOUNT]]`. 3. Сообщите, сколько времени потребуется для поступления средств на их счет (например, "5-10 рабочих дней"). 4. Упомяните ID исходной транзакции для их записей: `[[TRANSACTION_ID]]`. 5. Завершите на позитивной и полезной ноте.

Пользователь запрашивает возврат средств за `[[PRODUCT/SERVICE]]`, но его запрос выходит за рамки нашей политики возврата, потому что `[[REASON_FOR_DENIAL]]`. Составьте твердый, но эмпатичный отказ. 1. Признайте их запрос и покажите, что вы его рассмотрели. 2. Четко укажите, что запрос выходит за рамки политики возврата. 3. Кратко и нейтрально объясните конкретное правило политики, которое применяется (например, "Возвраты доступны только в течение 30 дней с момента покупки."). 4. Дайте ссылку на публичную страницу политики возврата: `[[POLICY_URL]]`. 5. Если возможно, предложите альтернативу, например, скидку на будущую покупку или понижение тарифного плана. `[[ALTERNATIVE_OFFER]]`. Не предлагайте это, если нет подходящей альтернативы.

Как менеджер, я одобрил одноразовое исключение из нашей политики для этого пользователя в отношении `[[POLICY_ISSUE]]`. Составьте сообщение, которое четко это доносит. 1. Укажите, что вы рассмотрели их конкретную ситуацию. 2. Четко заявите, что вы делаете *одноразовое исключение*. 3. Объясните результат исключения (например, "мы произвели полный возврат средств", "мы продлили вашу пробную версию"). 4. Мягко повторите стандартную политику, чтобы управлять будущими ожиданиями. 5. Используйте позитивный тон "рад помочь".

Проанализируйте следующую стенограмму заявки в службу поддержки и суммируйте ее в одну пару "Вопрос-Ответ" для нашего FAQ. Стенограмма: `[[TICKET_TRANSCRIPT]]` 1. **Вопрос:** Сформулируйте основную проблему пользователя как четкий, искомый вопрос. 2. **Ответ:** Напишите краткий, пошаговый ответ, который решает вопрос, основываясь на окончательном решении в заявке. 3. Удалите всю персонально идентифицируемую информацию (ПДн). 4. Конечный результат должен быть на простом языке, а не историей заявки.

Проанализируйте эти 5 заявок в службу поддержки. Выявите общую тему или вопрос, на который НЕ отвечают наши текущие статьи базы знаний. Заявка 1: `[[TICKET_1_SUMMARY]]` Заявка 2: `[[TICKET_2_SUMMARY]]` Заявка 3: `[[TICKET_3_SUMMARY]]` Заявка 4: `[[TICKET_4_SUMMARY]]` Заявка 5: `[[TICKET_5_SUMMARY]]` Текущие заголовки БЗ: `[[KB_TITLES_LIST]]` Выведите одно предложение, описывающее пробел в знаниях. Пример: "У нас нет статьи, объясняющей, как интегрироваться с новой версией X API.

Составьте новую статью базы знаний на основе следующей информации. **Тема:** `[[ARTICLE_TOPIC]]` **Целевая аудитория:** `[[AUDIENCE_DESCRIPTION]]` (например, "Новые пользователи", "Разработчики") **Ключевые шаги/информация для включения:** * `[[POINT_1]]` * `[[POINT_2]]` * `[[POINT_3]]` **Структура:** 1. **Заголовок:** Четкий, ориентированный на действие заголовок. 2. **Введение:** Одно предложение, суммирующее, что статья помогает пользователю сделать. 3. **Предварительные условия:** Маркированный список всего, что нужно пользователю перед началом. 4. **Шаги:** Нумерованный список с четкими инструкциями. 5. **Устранение неполадок/FAQ:** Небольшой раздел с 1-2 распространенными проблемами и их решениями.

Перепишите следующую статью базы знаний, чтобы она была более обнаруживаемой поисковыми системами и легче сканировалась пользователями. **Исходный текст статьи:** `[[ARTICLE_TEXT]]` **Основное ключевое слово:** `[[KEYWORD]]` **Инструкции:** 1. Убедитесь, что основное ключевое слово находится в заголовке (H1) и хотя бы в одном подзаголовке (H2). 2. Разбейте длинные абзацы на более короткие. 3. Используйте маркированные или нумерованные списки, где это уместно. 4. Добавьте "TL;DR" или "В этой статье" сводку вверху. 5. Выделите ключевые термины жирным шрифтом для лучшей читаемости.

Оцените производительность агента в следующей стенограмме заявки по нашей рубрике контроля качества. Присвойте оценку от 1 до 5 для каждой категории и краткое обоснование. **Стенограмма:** `[[TICKET_TRANSCRIPT]]` **Рубрика контроля качества:** 1. **Начало:** Было ли оно персонализированным и оперативным? 2. **Идентификация проблемы:** Правильно ли агент определил истинную проблему пользователя? 3. **Тон и эмпатия:** Был ли тон уместным и эмпатичным? 4. **Качество решения:** Было ли решение точным и хорошо объясненным? 5. **Завершение:** Было ли завершение четким и подтверждало ли оно решение? Выведите в формате таблицы Markdown.

Просмотрите следующее взаимодействие агента. Выявите самую большую возможность для коучинга агента. **Стенограмма:** `[[TICKET_TRANSCRIPT]]` Сосредоточьтесь на поведении, а не на личности. Сформулируйте возможность конструктивно. Пример вывода: "Агент мог бы более эффективно деэскалировать ситуацию, заранее подтвердив разочарование клиента, прежде чем переходить к решению.

На основе сложной заявки ниже создайте сценарий ролевой игры для тренировочной сессии. **Краткое описание сложной заявки:** `[[TICKET_SUMMARY]]` **Вывод сценария:** 1. **Персонаж клиента:** Краткое описание клиента (например, "Расстроенный, нетехнический, уже дважды пытался исправить"). 2. **Начальная фраза:** Точная фраза, которую должен использовать "клиент" для начала ролевой игры. 3. **"Поворот":** Скрытая информация или недопонимание, которое агент должен раскрыть. 4. **Желаемый результат:** Как выглядит успешное разрешение.

Создайте вопрос с множественным выбором для викторины на основе этой неоднозначной заявки в службу поддержки. **Краткое описание заявки:** `[[TICKET_SUMMARY]]` **Инструкции:** 1. Задайте вопрос "Какой следующий шаг будет лучшим?". 2. Предоставьте четыре варианта: * A - Идеальный, по всем правилам ответ. * B - Правдоподобный, но неверный ответ. * C - Распространенный, но неэффективный ответ. * D - Ответ, нарушающий политику. 3. Укажите правильный ответ и дайте краткое объяснение, почему он лучший выбор, а остальные неверны.

Подготовьте краткое резюме этой беседы для эскалации к живому агенту. Агент занят и должен понять ситуацию менее чем за 15 секунд. **Стенограмма разговора:** `[[CONVERSATION_TRANSCRIPT]]` **Резюме должно включать:** 1. **Пользователь:** `[[USER_NAME_OR_ID]]` 2. **Проблема:** Одно предложение, суммирующее проблему. 3. **История:** Что было предпринято до сих пор (например, "ИИ предложил очистить кэш, пользователь говорит, что это не помогло"). 4. **Эмоциональное состояние пользователя:** (например, "Спокойный", "Расстроенный", "Запутавшийся"). 5. **Конкретный вопрос для решения:** Точный вопрос, на который должен ответить человек.

Проанализируйте следующий черновик ответа на предмет любого языка, который может быть расценен как обещание, гарантия, признание вины или юридически обязывающее заявление. **Черновик ответа:** `[[DRAFT_RESPONSE]]` Если обнаружен чувствительный язык, идентифицируйте конкретную фразу и предложите более безопасную альтернативу. Пример вывода: - **Фраза:** "Я гарантирую, что это решит вашу проблему." - **Риск:** Создает обещание, которое мы, возможно, не сможем выполнить. - **Предложение:** "Это рекомендуемый следующий шаг, и он решает проблему для большинства пользователей.

Просмотрите следующую беседу с клиентом и отредактируйте всю персонально идентифицируемую информацию (ПДн) перед отправкой ее в отдел разработки в рамках отчета об ошибке. **Исходная стенограмма:** `[[ORIGINAL_TRANSCRIPT]]` **ПДн для редактирования:** - Имена - Адреса электронной почты - Номера телефонов - Физические адреса - IP-адреса - Номера счетов или ID пользователей Замените каждую часть ПДн на заполнитель, например `[[REDACTED_EMAIL]]` или `[[REDACTED_NAME]]`. Сохраните остальное содержание и структуру беседы.