Hoe je klachten op sociale media omzet in supporttickets

Waarom klachten op sociale media tussen wal en schip vallen

De meeste supportteams houden sociale media wel in de gaten, maar alleen wat direct bij hen binnenkomt. Helpdesks met een X-integratie vangen directe vermeldingen van je officiële account op. Dat werkt prima als mensen je taggen. Veel mensen doen dat echter niet.

Mensen schrijven "acme" in plaats van "@acme". Ze vragen in r/sysadmin of bij iemand anders de synchronisatie ook stuk is. Ze noemen je halverwege een reactie op Hacker News die over iets heel anders gaat. Niets daarvan bereikt een vermeldingenoverzicht, en niets daarvan bereikt de medewerker van dienst.

Het andere probleem is eigenaarschap. Wanneer klachten op sociale media door marketing worden opgepikt, blijven ze vaak in een Slack-kanaal van marketing hangen totdat iemand ze doorstuurt. Een ticket heeft een eigenaar, een deadline en een status. Een Slack-bericht heeft dat allemaal niet, dus de oplossing is om van de klacht zo vroeg mogelijk een ticket te maken.

Alerts instellen die klachten opvangen

Voordat je iets aan je helpdesk koppelt, heb je alerts nodig die gericht supportproblemen opsporen en niet elke vermelding van je merk. Een KWatch-alert vereist dat elk zoekwoord in de lijst aanwezig is, dus komma's werken als EN (AND). Zo kun je je productnaam combineren met de woorden die mensen gebruiken wanneer er iets stuk is.

Als we "acme" als voorbeeld voor je product nemen, ziet een startset er als volgt uit:

1. acme, not working en acme, broken voor duidelijke storingen

2. acme, can't login en acme, logged out voor accountproblemen

3. acme, refund en acme, charged voor facturatieklachten

4. acme, help voor mensen die vragen hoe ze iets moeten doen

Elke regel is een aparte alert. Als je al die woorden in één alert zou zetten, moet een bericht ze allemaal bevatten om te matchen. Kijk na een week welke alerts zijn afgegaan en hoe je gebruikers dingen verwoorden, en pas het daarop aan. Probeer ook je officiële handle als zoekwoord, want sommige mensen taggen je in plaats van de merknaam te typen.

Filters houden de wachtrij schoon, en dat is hier belangrijker dan waar dan ook, want elke valse match wordt een ticket dat iemand moet sluiten. Voeg je eigen support- en merkaccounts toe als Uitgesloten gebruikers, zodat je eigen reacties geen nieuwe tickets openen. Schakel op Reddit en Hacker News "Alleen hele woorden" in als je naam kort is, zodat "acme" niet matcht met "acmeplex". Een paar uitgesloten zoekwoorden kunnen duidelijke ruis wegfilteren, zoals vacatures waarin je wordt genoemd. Houd die lijst kort, want een bericht wordt genegeerd zodra er ook maar één uitgesloten zoekwoord in voorkomt. We hebben elk filter behandeld in ons artikel over het verminderen van ruis in keyword-alerts.

Hoe snel bereikt een klacht jou?

De snelheid hangt af van het platform, en het is goed om dat te weten voordat je iemand een reactietijd belooft. Dit zijn de verversingsintervallen uit onze documentatie:

Een klacht op X kan er dus tot een uur over doen om je wachtrij te bereiken. Voor de meeste supportteams is dat nog altijd veel sneller dan er op woensdag handmatig op stuiten. Maar als je een strakke SLA hanteert voor directe @mentions, behoud dan het native X-kanaal van je helpdesk daarvoor en gebruik keyword-alerts voor alles wat dat kanaal niet ziet, zoals niet-getagde berichten, Reddit-threads en Hacker News-reacties. KWatch kan bovendien geen DMs lezen, dus privéberichten blijven binnen je bestaande tools.

Elke klacht doorsturen naar je helpdesk

Zodra de alerts binnenkomen, is de volgende stap om ze vanuit KWatch om te zetten in tickets. De handigste manier is een API-webhook. Elke match arriveert als een JSON-payload en je kunt per alert een webhook instellen, zodat je klachtenalerts naar de helpdesk gaan terwijl je andere alerts elders terechtkomen. Een webhook per alert heeft voorrang op de webhook op accountniveau.

Hier is de voorbeeld-payload uit onze documentatie:

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

Alle velden die je nodig hebt voor een ticket zitten erin. Het veld content wordt de beschrijving, het veld link komt bovenaan zodat de agent de thread kan openen, en het veld query laat zien welk alert is afgegaan. Voor X bevat het auteursveld ook de volledige naam en het aantal volgers van de persoon, wat een agent helpt te bepalen wat als eerste beantwoord moet worden.

In Zapier

1. Maak een Zap aan met Webhooks by Zapier en de trigger Catch Hook, en plak de hook-URL vervolgens in het veld API Webhook URL van je klachtenalerts.

2. Voeg een Filter-stap toe als je wilt dat slechts een deel van de matches een ticket wordt. Een veelgebruikte regel is om alles door te laten waarbij sentiment niet positief is, waardoor berichten zoals "acme heeft mijn probleem in vijf minuten opgelost" worden overgeslagen.

3. Voeg de actie voor het aanmaken van tickets van je helpdesk toe. In Zendesk is dat Create Ticket. Koppel content aan de beschrijving, stel het onderwerp samen op basis van platform en author, en voeg een tag toe zoals social zodat je eenvoudig rapportages over deze tickets kunt maken.

In n8n

Dezelfde flow werkt met een Webhook-node, een IF-node op sentiment, en de Zendesk- of Freshdesk-node ingesteld om een ticket aan te maken. Als je KWatch nog niet eerder aan een van beide tools hebt gekoppeld: onze Zapier- en n8n-gids behandelt het webhook-gedeelte stap voor stap.

Nog een opmerking over het sentimentsfilter: dit wordt gemeten ten opzichte van je zoekwoord en sarcasme kan het af en toe nog voor de gek houden. Daarom zou ik het de eerste weken als een zacht filter gebruiken. Stuur alles door, kijk naar wat als positief is gelabeld en laat het filter pas daarna tickets uitsluiten.

In het openbaar reageren op een klacht

Een ticket vanuit Reddit is een bijzonder ticket, omdat de klant het niet rechtstreeks naar jou heeft gestuurd. De manier waarop je reageert, bepaalt of het helpt.

Ik zou de eerste reactie kort, openbaar en specifiek houden. Zeg wie je bent, laat weten dat je het probleem hebt gezien en geef een tijdelijke oplossing of de volgende stap. Vraag om een privébericht als je accountgegevens nodig hebt, en vraag nooit naar persoonlijke gegevens in de openbare thread. Is het probleem opgelost, plaats dan een update. Juist die laatste reactie is wat de volgende persoon met hetzelfde probleem op Google zal vinden.

Sommige threads gaan over zaken die je niet direct kunt oplossen, zoals een prijswijziging waar mensen niet blij mee zijn. Ook die verdienen een verantwoordelijke, maar kunnen meestal beter worden getagd en doorgestuurd naar het productteam dan beantwoord door support. En als één klacht binnen een uur verandert in twintig, is het geen supportticket meer. Onze gids over het detecteren van een PR-crisis op sociale media behandelt wat je moet doen wanneer dat gebeurt.

Als je supportteam ook een selecte lijst van belangrijke accounts beheert, waarschuwt ons zusterproduct MultiFollow je wanneer specifieke personen op Linkedin en X een bericht plaatsen. Zo zie je het bericht van een gefrustreerde ambassadeur zelfs als je productnaam niet wordt genoemd.