Як перетворити скарги в соціальних мережах на тікети підтримки

Чому скарги в соціальних мережах залишаються непоміченими

Більшість команд підтримки стежать за соцмережами, але лише за тим, що надходить безпосередньо до них. Служби підтримки з інтеграцією 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-payload, і ви можете налаштувати вебхук для кожного сповіщення окремо: сповіщення про скарги надходитимуть до служби підтримки, а інші — в інше місце. Вебхук для конкретного сповіщення має пріоритет над загальним вебхуком акаунту.

Ось приклад корисного навантаження з нашої документації:

{
  "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, тож ви побачите публікацію розчарованого прихильника, навіть якщо він взагалі не згадує назву вашого продукту.