Jak przekształcić skargi z mediów społecznościowych w tickety wsparcia

Dlaczego skargi w mediach społecznościowych umykają uwadze

Większość zespołów wsparcia monitoruje media społecznościowe, ale tylko to, co trafia bezpośrednio do nich. Narzędzia helpdesk z integracją z X wychwytują bezpośrednie wzmianki o Twoim oficjalnym koncie. To działa, gdy użytkownicy Cię oznaczają. Wielu z nich jednak tego nie robi.

Użytkownicy piszą „acme” zamiast „@acme”. Pytają na r/sysadmin, czy u kogoś jeszcze nie działa synchronizacja. Wspominają o Tobie w połowie komentarza na Hacker News na zupełnie inny temat. Żadna z tych wiadomości nie trafia do kanału wzmianek i żadna nie dociera do dyżurującego konsultanta.

Kolejnym problemem jest odpowiedzialność. Kiedy skargi w mediach społecznościowych są wychwytywane przez marketing, często zalegają na marketingowym kanale Slack, dopóki ktoś ich nie przekaże dalej. Ticket ma osobę przypisaną, termin realizacji i status. Wiadomość na Slack nie ma żadnego z tych elementów, dlatego najlepszym rozwiązaniem jest przekształcenie skargi w ticket tak szybko, jak to możliwe.

Tworzenie alertów wychwytujących skargi

Zanim podłączysz cokolwiek do swojego helpdesku, potrzebujesz alertów, które znajdują problemy techniczne, a nie każdą wzmiankę o Twojej marce. Alert KWatch wymaga pojawienia się każdego słowa kluczowego z listy, więc przecinki działają jak operator ORAZ (AND). Pozwala to połączyć nazwę produktu ze słowami, których ludzie używają, gdy coś nie działa.

Przyjmując „acme” jako nazwę Twojego produktu, zestaw początkowy wygląda następująco:

1. acme, not working oraz acme, broken w przypadku całkowitych awarii

2. acme, can't login oraz acme, logged out w przypadku problemów z kontem

3. acme, refund oraz acme, charged w przypadku skarg dotyczących rozliczeń

4. acme, help dla osób pytających, jak coś zrobić

Każda linia to osobny alert. Gdyby wszystkie te słowa znalazły się w jednym alercie, post musiałby zawierać każde z nich, aby dopasowanie było trafione. Po tygodniu sprawdź, które alerty się uruchomiły i jakich sformułowań używają Twoi użytkownicy, a następnie wprowadź korekty. Jako słowo kluczowe wypróbuj także swój oficjalny identyfikator, ponieważ niektórzy oznaczają Cię tagiem, zamiast wpisywać nazwę marki.

Filtry pomagają utrzymać porządek w kolejce i mają tutaj większe znaczenie niż gdziekolwiek indziej, ponieważ każde fałszywe dopasowanie staje się ticketem, który ktoś musi zamknąć. Dodaj konta swojego wsparcia i marki jako Wykluczeni użytkownicy (Excluded Users), aby Twoje odpowiedzi nie otwierały nowych ticketów. Na Reddit i Hacker News włącz opcję Tylko całe słowa (Whole Words Only), jeśli Twoja nazwa jest krótka, aby „acme” nie dopasowywało „acmeplex”. Kilka wykluczonych słów kluczowych pozwala odrzucić oczywisty szum, na przykład oferty pracy wspominające o Tobie. Utrzymuj tę listę krótką, ponieważ post jest odrzucany, gdy tylko pojawi się w nim którekolwiek z wykluczonych słów kluczowych. Wszystkie filtry szczegółowo omówiliśmy w naszym artykule na temat redukcji szumu w alertach słów kluczowych.

Jak szybko dotrze do Ciebie skarga?

Szybkość zależy od platformy i warto ją znać, zanim obiecasz komukolwiek określony czas reakcji. Oto częstotliwości odświeżania z naszej dokumentacji:

Zatem skarga na X może potrzebować do godziny, aby trafić do Twojej kolejki. Dla większości zespołów wsparcia to wciąż znacznie szybciej niż ręczne natrafienie na nią w środę. Jeśli jednak masz rygorystyczne SLA dotyczące bezpośrednich wzmianek (@mentions), zachowaj dla nich natywny kanał X w swoim helpdesku, a alertów słów kluczowych używaj do wszystkiego, czego on nie widzi: nieotagowanych postów, wątków na Reddit i komentarzy na Hacker News. KWatch nie potrafi również czytać wiadomości prywatnych (DMs), więc prywatne wiadomości pozostają w Twoich dotychczasowych narzędziach.

Przesyłanie każdej skargi do Twojego helpdesku

Gdy alerty już działają, kolejnym krokiem jest przekazanie ich z KWatch do ticketów. Najczystszym sposobem jest webhook API. Każde dopasowanie dociera jako ładunek JSON i możesz skonfigurować webhook dla pojedynczego alertu, dzięki czemu alerty dotyczące skarg trafiają do helpdesku, a pozostałe alerty gdzie indziej. Webhook skonfigurowany dla konkretnego alertu ma pierwszeństwo przed webhookiem na poziomie całego konta.

Oto przykładowy ładunek z naszej dokumentacji:

{
  "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"
}

Znajdziesz tam każde pole potrzebne do utworzenia ticketu. Pole content staje się opisem, pole link trafia na samą górę, aby konsultant mógł otworzyć wątek, a pole query informuje, który alert się uruchomił. W przypadku X pole autora zawiera także pełne imię i nazwisko oraz liczbę obserwujących, co pomaga konsultantowi zdecydować, na co odpowiedzieć w pierwszej kolejności.

W Zapier

1. Utwórz Zapa za pomocą aplikacji Webhooks by Zapier i wyzwalacza Catch Hook, a następnie wklej adres URL webhooka w polu API Webhook URL swoich alertów dotyczących skarg.

2. Dodaj krok Filter, jeśli chcesz, aby tylko niektóre dopasowania stawały się ticketami. Powszechną regułą jest przepuszczanie wszystkiego, gdzie pole sentiment nie ma wartości dodatniej, co pozwala pominąć posty typu „acme rozwiązało mój problem w pięć minut”.

3. Dodaj akcję tworzenia ticketu w swoim helpdesku. W Zendesk jest to Create Ticket. Przypisz pole content do opisu, stwórz temat na podstawie pól platform oraz author, a także dodaj tag taki jak social aby łatwo generować raporty z tych ticketów.

W n8n

Ten sam schemat działa z węzłem Webhook, węzłem IF sprawdzającym pole sentimentoraz węzłem Zendesk lub Freshdesk skonfigurowanym do tworzenia ticketu. Jeśli wcześniej nie łączyłeś KWatch z żadnym z tych narzędzi, nasz przewodnik po Zapier i n8n wyjaśnia krok po kroku konfigurację webhooka.

Kilka słów o filtrze sentymentu. Jest on mierzony względem Twojego słowa kluczowego, a sarkazm wciąż może go od czasu do czasu zmylić, dlatego przez pierwsze kilka tygodni zalecam stosowanie go jako filtra orientacyjnego. Przesyłaj wszystko, sprawdzaj, co zostało oznaczone jako pozytywne, i dopiero wtedy pozwól filtrowi odrzucać tickety.

Odpowiadanie na skargę publicznie

Ticket z Reddit to nietypowy ticket, ponieważ klient nie wysłał go bezpośrednio do Ciebie. To, jak odpowiesz, zadecyduje o tym, czy odpowiedź rzeczywiście pomoże.

Zalecam, aby pierwsza odpowiedź była krótka, publiczna i konkretna. Przedstaw się, napisz, że zauważyłeś problem, i podaj obejście lub kolejny krok. Jeśli potrzebujesz danych konta, poproś o wiadomość prywatną i nigdy nie pytaj o dane osobowe w publicznym wątku. Gdy problem zostanie rozwiązany, wróć i poinformuj o tym. Ta ostatnia odpowiedź będzie tą, na którą w Google natrafi kolejna osoba z tym samym problemem.

Niektóre wątki będą dotyczyć kwestii, których nie możesz naprawić od ręki, takich jak nielubiana przez użytkowników zmiana cennika. One również zasługują na osobę odpowiedzialną, ale zazwyczaj lepiej je otagować i przekazać zespołowi produktowemu, zamiast odpowiadać przez dział wsparcia. A jeśli jedna skarga zamieni się w dwadzieścia w ciągu godziny, to już nie jest zwykły ticket wsparcia. Nasz przewodnik po wyłapywaniu kryzysu PR w mediach społecznościowych wyjaśnia, co zrobić w takiej sytuacji.

Jeśli Twój zespół wsparcia dba również o krótką listę kluczowych klientów, nasz siostrzany produkt MultiFollow powiadamia Cię, gdy określone osoby na Linkedin i X publikują posty, dzięki czemu zobaczysz wpis sfrustrowanego kluczowego użytkownika, nawet jeśli nigdy nie wymieni nazwy Twojego produktu.