Как да превърнете оплакванията в социалните мрежи в тикети за поддръжка

Защо оплакванията в социалните мрежи остават незабелязани

Повечето екипи за поддръжка следят социалните мрежи, но само това, което идва директно при тях. Helpdesk системите с интеграция за X улавят директни споменавания на официалния ви акаунт. Това работи, когато хората ви тагнат. Много от тях обаче не го правят.

Хората пишат „acme“ вместо „@acme“. Питат в r/sysadmin дали синхронизацията на някой друг не работи. Споменават ви по средата на коментар в Hacker News по съвсем друга тема. Нищо от това не стига до фийда с меншъни и нищо от това не стига до дежурния служител.

Другият проблем е отговорността. Когато оплакванията в социалните мрежи бъдат уловени от маркетинга, те обикновено седят в маркетингов Slack канал, докато някой не ги препрати. Един тикет има отговорник, краен срок и статус. Едно съобщение в Slack няма нищо от това, така че решението е оплакването да стане тикет възможно най-рано.

Създаване на известия, които улавят оплаквания

Преди да свържете каквото и да било към вашата helpdesk система, имате нужда от известия, които намират проблеми за поддръжка, а не всяко споменаване на вашия бранд. Известие в 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 за хора, които питат как се прави нещо

Всеки ред е отделно известие. Ако сложите всички тези думи в едно известие, публикацията ще трябва да съдържа всяка една от тях, за да съвпадне. След една седмица проверете кои известия са се задействали и как потребителите ви се изразяват, след което коригирайте. Пробвайте и официалния си псевдоним (handle) като ключова дума, тъй като някои хора ви тагват, вместо да пишат името на бранда.

Филтрите поддържат опашката чиста и тук имат по-голямо значение от всякога, защото всяко фалшиво съвпадение се превръща в тикет, който някой трябва да затвори. Добавете акаунтите на вашата поддръжка и бранд като Изключени потребители, така че вашите отговори да не отварят нови тикети. В Reddit и Hacker News включете Само цели думи, ако името ви е кратко, така че „acme“ да не съвпада с „acmeplex“. Няколко изключени ключови думи могат да отстранят очевидния шум, като например обяви за работа, които ви споменават. Дръжте този списък кратък, тъй като публикацията се отхвърля веднага щом се появи дори една изключена ключова дума. Разгледахме всеки филтър в нашата статия за намаляване на шума в известията за ключови думи.

Колко бързо ще стигне едно оплакване до вас?

Скоростта зависи от платформата и е добре да я знаете, преди да обещаете време за отговор на когото и да било. Това са интервалите на опресняване от нашата документация:

Така че едно оплакване в X може да отнеме до един час, за да стигне до вашата опашка. За повечето екипи за поддръжка това все пак е много по-бързо, отколкото да го открият ръчно в сряда. Но ако поддържате строг SLA за директни @споменавания, запазете вградения канал за X на вашата helpdesk система за тях и използвайте известия за ключови думи за всичко, което тя не може да види, като публикации без таг, теми в Reddit и коментари в Hacker News. KWatch също така не може да чете DMs, така че личните съобщения остават в досегашните ви инструменти.

Изпращане на всяко оплакване към вашата helpdesk система

След като известията започнат да се задействат, следващата стъпка е да ги изведете от KWatch и да ги превърнете в тикети. Най-чистият начин е чрез API уебхук. Всяко съвпадение пристига като JSON полезен товар (payload) и можете да зададете уебхук за всяко известие, така че известията ви за оплаквания да отиват в helpdesk системата, докато другите ви известия отиват другаде. Уебхукът за отделно известие има предимство пред този за целия акаунт.

Ето примерния полезен товар (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 не е позитивно, което прескача публикации от типа „acme реши проблема ми за пет минути“.

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

В n8n

Същият работен процес работи с Webhook възел, IF възел за полето sentiment, и възел за Zendesk или Freshdesk, настроен да създава тикет. Ако не сте свързвали KWatch с нито един от двата инструмента преди, нашето ръководство за Zapier и n8n покрива частта с уебхука стъпка по стъпка.

Няколко думи за филтъра за настроения (sentiment). Той се измерва спрямо вашата ключова дума, а сарказмът все още го подвежда от време на време, така че бих го използвал като предварителен филтър през първите няколко седмици. Изпращайте всичко, прегледайте какво е маркирано като положително и едва тогава оставете филтъра да отхвърля тикети.

Отговаряне на оплакване публично

Тикет от Reddit е странен тикет, защото клиентът не го е изпратил директно до вас. Начинът, по който отговаряте, определя дали това ще помогне.

Бих запазил първия отговор кратък, публичен и конкретен. Кажете кой сте, кажете, че сте забелязали проблема, и посочете заобиколно решение или следващата стъпка. Ако имате нужда от данни за акаунта, помолете ги да ви пишат на лично съобщение и никога не искайте лична информация в публичната тема. Когато проблемът е решен, върнете се и го напишете. Този последен отговор е този, който следващият човек със същия проблем ще намери в Google.

Някои теми ще бъдат за нещо, което не можете да поправите, като например промяна в цените, която хората не харесват. Те все пак заслужават отговорник, но обикновено е по-добре да бъдат маркирани и изпратени на продуктовия екип, отколкото да получат отговор от поддръжката. А ако едно оплакване се превърне в двадесет за един час, това вече не е просто тикет за поддръжка. Нашето ръководство за улавянето на PR криза в социалните медии обяснява какво да правите, когато това се случи.

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