Hogyan alakítsuk át a közösségi médiás panaszokat támogatási jegyekké

Miért sikkadnak el a közösségi médiás panaszok

A legtöbb ügyfélszolgálati csapat figyeli a közösségi médiát, de csak azokat a megkereséseket, amelyek közvetlenül hozzájuk érkeznek. Az X-integrációval rendelkező helpdeskek észlelik a hivatalos fiókod közvetlen említéseit. Ez működik, ha az emberek megjelölnek téged. Sokan azonban nem teszik meg.

Az emberek az „@acme” helyett csak azt írják, hogy „acme”. Megkérdezik az r/sysadmin csoportban, hogy másnál is leállt-e a szinkronizálás. Megemlítenek egy Hacker News-komment kellős közepén, ami egy teljesen más témáról szól. Mindebből semmi sem jut el az említések hírfolyamába, és semmi sem éri el az ügyeletes munkatársat.

A másik probléma a felelősségi kör. Amikor a közösségi panaszokat a marketingesek veszik észre, azok hajlamosak a marketinges Slack-csatornában ragadni, amíg valaki tovább nem küldi őket. Egy hibajegynek van felelőse, határideje és állapota. Egy Slack-üzenetnek ezek közül egyik sincs meg, így a megoldás az, hogy a panaszt a lehető leghamarabb jeggyé alakítjuk.

Panaszokat elcsípő riasztások létrehozása

Mielőtt bármit összekötnél a helpdeskeddel, olyan riasztásokra van szükséged, amelyek a terméktámogatási problémákat találják meg, nem pedig a márkád minden egyes említését. A KWatch-riasztás megköveteli a listában szereplő összes kulcsszó megjelenését, így a vesszők ÉS (AND) kapcsolatként működnek. Ez lehetővé teszi, hogy a terméked nevét párosítsd azokkal a szavakkal, amelyeket az emberek akkor használnak, ha valami elromlott.

Az „acme” kifejezést használva a terméked helyettesítésére, a kiindulási készlet így néz ki:

1. acme, not working és acme, broken teljes leállások és működési hibák esetén

2. acme, can't login és acme, logged out fiókproblémák esetén

3. acme, refund és acme, charged számlázási panaszok esetén

4. acme, help azok számára, akik azt kérdezik, hogyan kell csinálni valamit

Minden sor egy külön riasztás. Ha az összes szót egyetlen riasztásba tennéd, a bejegyzésnek mindegyiket tartalmaznia kellene az egyezéshez. Egy hét elteltével nézd meg, mely riasztások léptek működésbe, és hogyan fogalmaznak a felhasználóid, majd finomíts a beállításokon. Érdemes a hivatalos profilnevedet is kipróbálni kulcsszóként, mivel egyesek megjelölnek a márkanév begépelése helyett.

A szűrők tisztán tartják a várólistát, és itt fontosabbak, mint bárhol máshol, hiszen minden téves egyezés egy olyan hibajeggyé válik, amelyet valakinek le kell zárnia. Add hozzá a saját ügyfélszolgálati és márkához kapcsolódó fiókjaidat a Kizárt felhasználók (Excluded Users) listájához, hogy a válaszaid ne nyissanak új jegyeket. A Redditen és a Hacker News felületén kapcsold be a Csak teljes szavak (Whole Words Only) funkciót, ha a neved rövid, így az „acme” nem fog egyezni az „acmeplex” kifejezéssel. Néhány kizárt kulcsszó kiszűrheti a nyilvánvaló zajt, például az álláshirdetéseket, amelyek megemlítenek téged. Tartsd ezt a listát röviden, mivel a bejegyzés azonnal kiesik, amint megjelenik benne bármelyik kizárt kulcsszó. Minden szűrőt részletesen bemutat a cikkünk a kulcsszavas riasztások zajának csökkentéséről.

Milyen gyorsan jut el hozzád egy panasz?

A sebesség a platformtól függ, és érdemes tisztában lenni vele, mielőtt válaszidőt ígérnél bárkinek. Íme a frissítési gyakoriságok a dokumentációnkból:

Így egy panasz az X-en akár egy órát is igénybe vehet, mire eléri a várólistádat. A legtöbb támogatási csapat számára ez még mindig sokkal gyorsabb, mintha szerdán kézzel találnák meg. Ha azonban szigorú SLA-t követsz a közvetlen említésekre (@mentions), tartsd meg a helpdesked natív X-csatornáját ezekre, és használd a kulcsszavas riasztásokat minden másra, amit az nem lát: a megjelölés nélküli posztokra, a Reddit-szálakra és a Hacker News-kommentekre. A KWatch a privát üzeneteket (DMs) sem tudja olvasni, így a közvetlen üzenetek a meglévő eszközeidben maradnak.

Minden panasz elküldése az ügyfélszolgálati rendszerbe

Miután a riasztások működésbe léptek, a következő lépés az, hogy a KWatch-ból eljussanak a jegyekbe. A legtisztább megoldás az API webhook. Minden egyezés JSON-adatcsomagként érkezik, és riasztásonként külön webhookot állíthatsz be, így a panaszriasztásaid a helpdeskbe kerülnek, míg az egyéb riasztásaid máshová. A riasztásonkénti webhook elsőbbséget élvez a teljes fiókra érvényessel szemben.

Íme a példa adatcsomag a dokumentációnkból:

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

Minden mező megtalálható benne, amire egy hibajegyhez szükséged lehet. A(z) content lesz a leírás, a(z) link kerül legfelülre, hogy az ügyintéző megnyithassa a szálat, a(z) query megmutatja, melyik riasztás lépett működésbe. Az X esetében a szerző mező tartalmazza a személy teljes nevét és követőinek számát is, ami segít az ügyintézőnek eldönteni, mire válaszoljon először.

A Zapierben

1. Hozz létre egy Zap-et a Webhooks by Zapier alkalmazással és a Catch Hook triggerrel, majd illeszd be a webhook URL-címét a panaszriasztásaid API Webhook URL mezőjébe.

2. Adj hozzá egy Filter lépést, ha csak bizonyos egyezésekből szeretnél hibajegyet készíteni. Gyakori szabály, hogy átenged mindent, ahol a(z) sentiment értéke nem pozitív, ami kihagyja az olyan bejegyzéseket, mint az „az acme öt perc alatt megoldotta a problémámat”.

3. Add hozzá a helpdesk jegylétrehozási műveletét. A Zendeskben ez a Create Ticket. Rendeld a(z) content mezőt a leíráshoz, állítsd össze a tárgyat a(z) platform és authormezőkből, és adj hozzá egy olyan címkét, mint a(z) social , hogy ezekről a hibajegyekről könnyen készíthess kimutatásokat.

Az n8n-ben

Ugyanez a folyamat működik egy Webhook csomóponttal, egy IF csomóponttal a(z) sentimentmezőre, valamint a jegy létrehozására beállított Zendesk vagy Freshdesk csomóponttal. Ha korábban még nem kapcsoltad össze a KWatch-ot ezen eszközök egyikével sem, a Zapier és n8n útmutatónk lépésről lépésre bemutatja a webhookok beállítását.

Néhány szó a hangulatszűrőről. A hangulatot a kulcsszavadhoz viszonyítva méri, és a szarkazmus időnként még megtréfálhatja, ezért az első pár hétben lazább szűrőként érdemes használni. Küldj át mindent, nézd meg, mi kapott pozitív címkét, és csak ezután engedd, hogy a szűrő elvessen hibajegyeket.

Nyilvános válaszadás egy panaszra

A Redditről érkező hibajegy szokatlan jegy, mivel az ügyfél nem közvetlenül neked küldte el. Az, hogy hogyan válaszolsz, eldönti, hogy valóban segít-e a beavatkozás.

Az első választ érdemes rövidre, nyilvánosra és konkrétra fogni. Mondd el, ki vagy, jelezd, hogy láttad a problémát, és adj meg egy áthidaló megoldást vagy a következő lépést. Ha fiókadatokra van szükséged, kérd meg, hogy küldjön privát üzenetet, és soha ne kérj személyes adatokat a nyilvános szálban. Amikor a hiba elhárult, térj vissza és jelezd. Ez az utolsó válasz lesz az, amit a következő, ugyanezzel a problémával küzdő ember megtalál majd a Google-ban.

Egyes beszélgetések olyan témákról szólnak majd, amelyeket nem tudsz azonnal kijavítani, mint például egy nem tetsző árváltozás. Ezeknek is szükségük van felelősre, de általában jobb megcímkézni és elküldeni őket a termékcsapatnak, mintsem az ügyfélszolgálatnak válaszolnia rájuk. És ha egyetlen panaszból egy óra alatt húsz lesz, az már több mint egy egyszerű ügyfélszolgálati hibajegy. A következő cikkünk a PR-válságok felismeréséről a közösségi médiában részletesen bemutatja, mi a teendő ilyen esetben.

Ha a támogatási csapatod egy szűk kiemelt ügyféllistát is felügyel, testvértermékünk, a MultiFollow értesítést küld, ha bizonyos személyek közzétesznek valamit a Linkedin és az X felületén, így akkor is láthatod egy csalódott belső támogatód posztját, ha abban meg sem nevezi a termékedet.