Cum să transformați reclamațiile din social media în tichete de suport

De ce reclamațiile de pe rețelele sociale trec neobservate

Majoritatea echipelor de asistență monitorizează rețelele sociale, dar doar părțile care vin direct spre ele. Sistemele de helpdesk cu integrare X preiau mențiunile directe ale contului dvs. oficial. Asta funcționează atunci când oamenii vă etichetează. Mulți dintre ei nu o fac.

Oamenii scriu „acme” în loc de „@acme”. Întreabă pe r/sysadmin dacă mai are cineva probleme cu sincronizarea. Vă menționează la mijlocul unui comentariu pe Hacker News despre un cu totul alt subiect. Nimic din toate acestea nu ajunge într-un flux de mențiuni și nimic nu ajunge la persoana de gardă.

Cealaltă problemă este responsabilitatea. Când reclamațiile de pe rețelele sociale sunt interceptate de marketing, ele tind să rămână într-un canal Slack de marketing până când cineva le redirecționează. Un tichet are un responsabil, un termen limită și o stare. Un mesaj pe Slack nu are niciunul dintre aceste elemente, așa că soluția este să transformați reclamația într-un tichet cât mai devreme posibil.

Scrierea de alerte care detectează reclamațiile

Înainte de a conecta orice la helpdesk-ul dvs., aveți nevoie de alerte care să găsească probleme de asistență, nu orice mențiune a mărcii dvs. O alertă KWatch necesită ca fiecare cuvânt cheie din lista sa să apară, astfel că virgulele funcționează ca un AND. Acest lucru vă permite să asociați numele produsului dvs. cu cuvintele pe care le folosesc oamenii atunci când ceva nu funcționează.

Având „acme” ca exemplu pentru produsul dvs., un set de pornire arată astfel:

1. acme, not working și acme, broken pentru defecțiuni totale

2. acme, can't login și acme, logged out pentru probleme de cont

3. acme, refund și acme, charged pentru reclamații legate de facturare

4. acme, help pentru persoane care întreabă cum se face ceva

Fiecare linie este o alertă individuală. Dacă ați pune toate aceste cuvinte într-o singură alertă, o postare ar trebui să le conțină pe fiecare dintre ele pentru a se potrivi. După o săptămână, analizați ce alerte s-au declanșat și cum își formulează utilizatorii mesajele, apoi ajustați. Încercați și handle-ul oficial ca un cuvânt cheie, deoarece unii oameni vă etichetează în loc să tasteze numele mărcii.

Filtrele păstrează coada curată și contează aici mai mult decât oriunde altundeva, deoarece fiecare potrivire falsă devine un tichet pe care cineva trebuie să îl închidă. Adăugați conturile dvs. de asistență și de brand ca Utilizatori excluși, astfel încât răspunsurile dvs. să nu deschidă tichete noi. Pe Reddit și Hacker News, activați Doar cuvinte întregi dacă numele dvs. este scurt, astfel încât „acme” să nu se potrivească cu „acmeplex”. Câteva cuvinte cheie excluse pot elimina zgomotul evident, cum ar fi postările cu oferte de muncă care vă menționează. Păstrați această listă scurtă, deoarece o postare este eliminată de îndată ce apare oricare dintre cuvintele cheie excluse. Am analizat fiecare filtru în postarea noastră despre reducerea zgomotului în alertele de cuvinte cheie.

Cât de repede va ajunge o reclamație la dvs.?

Viteza depinde de platformă și merită să o știți înainte de a promite cuiva un timp de răspuns. Acestea sunt intervalele de reîmprospătare din documentația noastră:

Astfel, o reclamație pe X poate dura până la o oră pentru a ajunge în coada dvs. Pentru majoritatea echipelor de asistență, acest lucru este totuși mult mai rapid decât să o găsească manual miercuri. Dar dacă aveți un SLA strict pentru @mențiunile directe, păstrați canalul nativ de X al helpdesk-ului dvs. pentru acestea și folosiți alertele de cuvinte cheie pentru tot ceea ce acesta nu poate vedea, cum ar fi postările fără etichetare, firele de discuție de pe Reddit și comentariile de pe Hacker News. De asemenea, KWatch nu poate citi mesajele private (DMs), așa că mesajele directe rămân gestionate de instrumentele dvs. existente.

Trimiterea fiecărei reclamații către helpdesk-ul dvs.

Odată ce alertele funcționează, următorul pas este să le scoateți din KWatch și să le transformați în tichete. Cea mai curată metodă este un API webhook. Fiecare potrivire sosește ca un payload JSON și puteți seta un webhook per alertă, astfel încât alertele de reclamații să meargă la helpdesk, în timp ce celelalte alerte merg în altă parte. Un webhook per alertă are prioritate față de cel la nivel de cont.

Iată exemplul de payload din documentația noastră:

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

Fiecare câmp de care aveți nevoie pentru un tichet este prezent acolo. Câmpul content devine descrierea, câmpul link se plasează în partea de sus pentru ca agentul să poată deschide firul de discuție, iar câmpul query vă indică ce alertă s-a declanșat. Pentru X, câmpul de autor include de asemenea numele complet al persoanei și numărul de urmăritori, ceea ce ajută un agent să decidă la ce să răspundă mai întâi.

În Zapier

1. Creați un Zap cu Webhooks by Zapier și declanșatorul Catch Hook, apoi lipiți adresa URL a webhook-ului în câmpul API Webhook URL din alertele dvs. de reclamații.

2. Adăugați un pas de tip Filter dacă doriți ca doar anumite potriviri să devină tichete. O regulă comună este să permiteți trecerea a tot unde câmpul sentiment nu este pozitiv, ceea ce exclude postările de tipul „acme mi-a rezolvat problema în cinci minute”.

3. Adăugați acțiunea de creare a unui tichet din helpdesk-ul dvs. În Zendesk aceasta este Create Ticket. Asociați câmpul content cu descrierea, construiți subiectul din platform și author, și adăugați o etichetă precum social pentru ca aceste tichete să fie ușor de inclus în rapoarte.

În n8n

Același flux funcționează cu un nod Webhook, un nod IF pe câmpul sentiment, și nodul Zendesk sau Freshdesk setat pentru a crea un tichet. Dacă nu ați mai conectat KWatch la niciunul dintre aceste instrumente până acum, ghidul nostru despre ghidul pentru Zapier și n8n acoperă pas cu pas partea de webhook.

Câteva cuvinte despre filtrul de sentiment. Acesta este măsurat în raport cu cuvântul dvs. cheie, iar sarcasmul îl mai păcălește din când în când, așa că aș recomanda să îl folosiți ca pe un filtru orientativ în primele două săptămâni. Trimiteți totul, analizați ce anume a fost etichetat ca pozitiv și abia apoi lăsați filtrul să elimine tichete.

Răspunsul la o reclamație în public

Un tichet venit de pe Reddit este un tichet neobișnuit, deoarece clientul nu vi l-a trimis direct dvs. Modul în care răspundeți decide dacă acesta este de ajutor.

Aș păstra primul răspuns scurt, public și precis. Spuneți cine sunteți, confirmați că ați observat problema și oferiți soluția de moment sau pasul următor. Dacă aveți nevoie de detalii despre cont, cereți-le să vă trimită un mesaj privat și nu solicitați niciodată informații personale în firul de discuție. Când problema este rezolvată, reveniți și menționați acest lucru. Acel ultim răspuns este cel pe care următoarea persoană cu aceeași problemă îl va găsi pe Google.

Unele fire de discuție vor fi despre ceva ce nu puteți remedia, cum ar fi o schimbare de preț care nu le place oamenilor. Acestea merită în continuare un responsabil, dar de obicei este mai bine să fie etichetate și trimise echipei de produs decât să primească răspuns de la suport. Iar dacă o reclamație se transformă în douăzeci într-o oră, nu mai este vorba doar de un tichet de asistență. Ghidul nostru despre detectarea unei crize de PR pe rețelele sociale explică ce este de făcut atunci când se întâmplă acest lucru.

Dacă echipa dvs. de asistență are grijă și de o listă restrânsă de conturi cheie, produsul nostru înfrățit MultiFollow vă alertează atunci când postează anumite persoane de pe Linkedin și X, astfel încât veți vedea postarea unui susținător nemulțumit chiar dacă acesta nu menționează niciodată produsul dvs.