Как превратить жалобы в социальных сетях в тикеты поддержки

Почему жалобы в соцсетях теряются

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

Люди пишут «acme» вместо «@acme». Они спрашивают в r/sysadmin, не сломалась ли у кого-то еще синхронизация. Они упоминают вас в середине комментария на Hacker News, посвященного совсем другой теме. Ничто из этого не попадает в ленту упоминаний и не доходит до дежурного сотрудника.

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

Создание оповещений, которые выявляют жалобы

Перед тем как подключать что-либо к службе поддержки, вам понадобятся оповещения, которые находят проблемы с поддержкой, а не просто каждое упоминание вашего бренда. Оповещение в KWatch требует наличия каждого ключевого слова из своего списка, то есть запятые работают как оператор «И» (AND). Это позволяет объединить название вашего продукта со словами, которые люди используют, когда что-то сломалось.

Если принять «acme» за название вашего продукта, базовый набор выглядит следующим образом:

1. acme, not working и acme, broken для явных сбоев

2. acme, can't login и acme, logged out для проблем с аккаунтом

3. acme, refund и acme, charged для жалоб на оплату и счета

4. acme, help для тех, кто спрашивает, как что-то сделать

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

Фильтры поддерживают чистоту очереди, и здесь они важнее, чем где-либо еще, ведь каждое ложное срабатывание превращается в тикет, который кому-то придется закрывать. Добавьте аккаунты вашей службы поддержки и бренда в Excluded Users, чтобы ваши ответы не открывали новые тикеты. На Reddit и Hacker News включите Whole Words Only, если у вас короткое название, чтобы «acme» не совпадало с «acmeplex». Несколько исключенных ключевых слов помогут отсечь очевидный шум, например вакансии с вашим упоминанием. Держите этот список коротким, поскольку публикация отбрасывается при появлении хотя бы одного исключенного ключевого слова. Мы подробно разобрали каждый фильтр в нашей статье о снижении шума в оповещениях по ключевым словам.

Как быстро жалоба дойдет до вас?

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

Таким образом, жалоба в X может добираться до вашей очереди до одного часа. Для большинства команд поддержки это все равно намного быстрее, чем обнаружить ее вручную в среду. Но если у вас строгий SLA по прямым @mentions, оставьте для них встроенный канал X в вашей службе поддержки, а оповещения по ключевым словам используйте для всего, чего он не видит: постов без тегов, тредов на Reddit и комментариев на Hacker News. KWatch также не имеет доступа к DMs, поэтому личные сообщения продолжат обрабатываться в ваших текущих инструментах.

Отправка каждой жалобы в вашу службу поддержки

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

Вот пример полезной нагрузки из нашей документации:

{
  "platform": "reddit",
  "query": "Keywords: vllm",
  "datetime": "19 Jan 24 05:52 UTC",
  "link": "https://www.reddit.com/r/LocalLLaMA/comments/19934kd/sglang_new/kijvtk5/",
  "author": "lmzoo",
  "content": "sglang runtime has a different architecture on the higher-level part with vllm.",
  "sentiment": "neutral"
}

В нем есть все поля, необходимые для тикета. Поле content становится описанием, поле link помещается вверху, чтобы оператор мог открыть тред, а поле query указывает, какое именно оповещение сработало. Для X поле автора также включает полное имя пользователя и количество подписчиков, что помогает оператору решить, на что отвечать в первую очередь.

В Zapier

1. Создайте Zap с помощью Webhooks by Zapier и триггера Catch Hook, затем вставьте полученный URL вебхука в поле API Webhook URL ваших оповещений о жалобах.

2. Добавьте шаг Filter, если хотите превращать в тикеты только часть совпадений. Распространенное правило — пропускать все, где поле sentiment не является положительным (positive), что исключает сообщения вроде «acme решили мою проблему за пять минут».

3. Добавьте действие создания тикета вашей службы поддержки. В Zendesk это Create Ticket. Сопоставьте поле content с описанием, сформируйте тему на основе platform и author, и добавьте тег вроде social чтобы по этим тикетам было удобно формировать отчеты.

В n8n

Такой же сценарий работает с узлом Webhook, узлом IF для поля sentiment, а также узлом Zendesk или Freshdesk, настроенным на создание тикета. Если вы ранее не подключали KWatch ни к одному из этих инструментов, наше руководство по Zapier и n8n пошагово описывает настройку вебхуков.

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

Публичный ответ на жалобу

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

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

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

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