Hoe maak je een supportticket-rapport: stap voor stap

Een supportticketrapport is vooral een definitievraagstuk. Gemaakte tickets, opgeloste tickets, eerste reactietijd en oplossingstijd klinken allemaal vanzelfsprekend. Maar elk van deze statistieken heeft binnen dezelfde helpdesk meer dan één officiële betekenis.

Zodra de telregels eenmaal zijn vastgelegd, schrijft het rapport zichzelf. Sla die stap over en twee eerlijke mensen zullen dezelfde export maken en er uren naast zitten ten opzichte van elkaar.

Deze gids behandelt wat er in het rapport thuishoort, de vier punten waarop definities uiteenlopen en hoe u het rapport opbouwt op basis van een ticketexport.

Wat hoort er thuis in een supportticketrapport

Alleen het volume zegt bijna niets. De indeling is wat de cijfers betrouwbaar maakt om te interpreteren.

Element	Waarom het er staat
Gemaakte tickets in de periode	De vraagzijde
Opgeloste tickets in de periode	De aanbodzijde, op basis van een vastgestelde statusregel
Backlog aan het einde van de periode	Alles wat niet is opgelost of gesloten
Eerste reactietijd	Op basis van een vastgestelde klok en definitie
Oplossingstijd	Eerste of volledige, expliciet benoemd
Heropende tickets	Het kwaliteitssignaal dat de andere cijfers verbergen
Onbeantwoorde tickets	Waar het proces volledig is mislukt
Een vastgestelde datumbasis en scope	Welke kanalen, merken en wachtrijen zijn inbegrepen

Twee rijen wegen zwaarder dan hun omvang doet vermoeden. Heropende en onbeantwoorde tickets zijn de punten waarop een rapport niet langer een scorebord is, maar echt nuttig wordt.

Zendesk publiceert de onderliggende formules, waardoor de definities controleerbaar zijn in plaats van een kwestie van mening. De referentie voor statistieken en attributen vermeldt ze allemaal.

Begin met de eenvoudigste. Opgeloste tickets is "het aantal opgeloste of gesloten tickets", dus de statistiek omvat twee statussen in plaats van één.

"Eerste reactietijd" heeft twee officiële definities

Dit is het kruispunt dat voor de meeste onenigheid zorgt, en de leverancier waarschuwt hier direct voor.

De SLA-documentatie van Zendesk zegt het in één regel: "Verwar de SLA-reactietijd niet met de systeemeigen reactietijdstatistiek van Zendesk."

De systeemeigen statistiek is streng over wie er antwoordt. Zendesk stelt dat "de eerste reactietijd uitsluitend wordt berekend op basis van antwoorden van agenten". Geautomatiseerde acties en acties van bots "worden niet meegewogen bij het berekenen van de eerste reactietijd".

De SLA-statistiek is dat niet. Daar is de eerste reactietijd "de tijd tussen het aanmaken van het ticket en de eerste openbare reactie van een agent (of automatische reactie)". Zendesk voegt hieraan toe dat "aan reactietijdstatistieken wordt voldaan als u een trigger instelt om automatisch te reageren met een openbare reactie".

Als u die twee combineert, is de consequentie overduidelijk. Een automatische beantwoorder kan aan uw SLA-doelstelling voldoen, terwijl de systeemeigen eerste reactietijd blijft doorlopen.

Een rapport dat 98% SLA-behaald percentage en een mediaan van vier uur voor de eerste reactie laat zien, is dus niet in tegenspraak met zichzelf. Het rapporteert twee verschillende dingen, beide correct.

Er zijn nog twee kleinere uitzonderingen die het waard zijn om te weten. Neem het geval waarin een agent het ticket aanmaakt en de eerste reactie openbaar is. De referentie voor tijdsduurstatistieken stelt dat de tweede tijdstempel "verschuift naar de tweede openbare reactie van de agent".

En gedeelde tickets tellen niet mee. Zendesk merkt op dat wanneer een agent openbaar reageert vanuit een ander account via het delen van tickets, "dit niet meetelt voor de eerste reactietijd van uw account".

"Oplossingstijd" heeft er ook twee

Dezelfde splitsing loopt door de oplossingsstatistieken, en hier worden beide versies standaard meegeleverd.

De eerste oplossingstijd is de "duur tussen het aanmaken van het ticket en de eerste oplossing", eindigend op "de eerste keer dat de ticketstatus op opgelost wordt gezet".

De volledige oplossingstijd is de "duur tussen het aanmaken van het ticket en de meest recente oplossing". Deze eindigt op "de laatste keer dat de ticketstatus op opgelost werd gezet".

Voor een ticket dat één keer is opgelost, zijn de twee identiek. Voor een ticket dat is opgelost, heropend en opnieuw opgelost, wijken ze af met de tijd die de tweede ronde in beslag nam.

Dat is precies waarom heropende tickets in het rapport thuishoren. Zendesk definieert ze als tickets die "zijn heropend nadat ze waren opgelost", en merkt op dat de statistiek "geen tickets omvat die tijdens dezelfde update zijn opgelost en heropend".

Er is een effect van de tweede orde dat mensen over het hoofd zien. Het dagelijkse gemiddelde van opgeloste tickets telt ze "alleen als ze momenteel zijn opgelost of gesloten". Dus een ticket dat vandaag wordt heropend, verdwijnt stilletjes uit het aantal opgeloste tickets van vorige maand.

Een rapport dat u in juni hebt gedraaid, zal in augustus dus niet hetzelfde resultaat opleveren. Er is niets kapot; de onderliggende status is veranderd.

Nog twee statistieken scheiden wachten van werken. De wachttijd voor de aanvrager is de gecombineerde tijd in de statussen nieuw, open en in de wacht (on-hold), en de wachttijd voor de agent is de gecombineerde tijd in de status in behandeling (pending).

Dit paar beantwoordt de vraag die een gemiddelde oplossingstijd niet kan beantwoorden. Lange oplossingstijden veroorzaakt door het wachten op de klant zijn een heel ander probleem dan lange oplossingstijden veroorzaakt door de lengte van de wachtrij.

Kalenderuren of kantooruren

Elk reactie- en oplossingscijfer bestaat op twee klokken, en het kiezen van één ervan is niet optioneel.

Zendesk slaat beide op. Na de eerste openbare reactie "berekent het systeem de eerste reactietijd in kalenderuren en kantooruren". Beide statistieken "worden opgeslagen met de ticketgegevens".

De standaardinstelling die u ziet is niet neutraal. Zendesk merkt op dat vooraf gebouwde Explore-rapporten "informatie in kalenderuren weergeven". Statistieken in kantooruren "zijn beschikbaar en kunnen in uw eigen rapporten worden gebruikt".

Een team dat van negen tot vijf werkt, zal traag lijken in het standaardrapport. Een ticket dat op vrijdag om 18:00 uur binnenkomt, telt ongeveer 63 kalenderuren vóór maandagochtend, en bijna nul kantooruren.

Live gesprekkanalen voegen nog een extra complicatie toe. De statistiek Eerste reactietijd (sec) voor messaging en chat "negeert uw instellingen voor kantooruren voor messaging en openingstijden voor live chat".

En SLA's voor de reactietijd van chat zijn opt-in. Zendesk stelt dat reactietijd-SLA's voor live chat "standaard zijn uitgeschakeld", dus de afwezigheid ervan is een configuratiestatus in plaats van een perfecte prestatie.

Hoe u dit handmatig doet

Optie 1: Eén tabblad per statistiekfamilie

Exporteer de ticketlijst met statistiekvelden en splits vervolgens volume, reactietijd en oplossingstijd op in afzonderlijke tabbladen voordat u iets samenvat.

Houd de kolommen voor kalenderuren en kantooruren naast elkaar in plaats van er één te kiezen tijdens het exporteren. Er zal namelijk naar de andere gevraagd worden.

Bereken medianen in plaats van gemiddelden voor de tijdstatistieken. Een handvol tickets dat tijdens een feestdag open blijft staan, trekt een gemiddelde naar een niveau dat voor geen enkel reëel ticket geldt.

De beperking is dat een spreadsheet de statusgeschiedenis niet kan inzien. U krijgt de huidige status van elk ticket, dus het heropeningsgedrag moet voortkomen uit het aantal heropende tickets in plaats van uit reconstructie.

Optie 2: Een definitietabblad, als eerste geschreven

Leg de definitie van de reactietijd, de klok, de oplossingsstatistiek, de statusregel voor opgelost, de kanalen binnen de scope en de datumbasis vast.

Leg vervolgens vast wat het rapport niet claimt. Door op te schrijven dat het behaalde SLA-percentage en de systeemeigen eerste reactietijd verschillende dingen meten, voorkomt u dat een goedwillende collega ze als één getal citeert.

De beperking is de gebruikelijke. Het documenteren van een regel betekent niet dat deze wordt toegepast, en volgend kwartaal bouwt iemand de draaitabel weer op uit het hoofd.

Optie 3: Segmenteren voordat u het gemiddelde berekent

Splits op kanaal voordat u een tijdstatistiek berekent. E-mail-, chat- en telefonische tickets hebben een andere dynamiek, en een gecombineerde mediaan beschrijft geen van alle goed.

Sluit vervolgens de tickets uit die het beeld verkenen, of markeer ze. Tickets die al weken wachten op een reactie van de klant horen thuis op een eigen regel, in plaats van binnen het oplossingsgemiddelde.

Laat zien wat u hebt uitgesloten en hoeveel het er waren. Een lezer die het filter niet kan zien, zal ervan uitgaan dat er geen filter was.

De beperking is dat segmentatie het werk vermenigvuldigt. Drie kanalen maal twee klokken maal twee oplossingsstatistieken levert twaalf getallen op om uit elkaar te houden.

De gedeelde beperking. Alle drie gaan ze ervan uit dat de export één datumbereik op één datumbasis beslaat voor elke wachtrij. Gemengde bereiken over tabbladen heen is de meest voorkomende onopgemerkte fout in dit rapport.

Waar de handmatige route vertraagt

Het eerste supportticketrapport kost een middag. Het vierde duurt langer, omdat de helpdesk eronder is veranderd.

Er wordt een nieuw kanaal ingeschakeld, waardoor de gecombineerde mediaan verschuift om redenen die niets met prestaties te maken hebben. Kantooruren worden aangepast voor een nieuwe regio, en elk historisch cijfer voor kantooruren verschuift mee.

Vervolgens treedt het heropeningseffect op. De cijfers van het vorige kwartaal zijn niet meer te reproduceren, en het uitleggen van de reden kost meer tijd dan het opnieuw opbouwen van het rapport.

Er zijn vierde kosten die pas onder druk zichtbaar worden. Iemand vraagt of de support dit kwartaal sneller is geworden. Een eerlijk antwoord vereist dat eerst de klok, de definitie en de kanaalmix worden vastgesteld.

Voor de tevredenheidskant van hetzelfde plaatje, zie onze gids voor het maken van een NPS-rapport. Als het volume zelf het probleem is, behandelt onze handleiding over het bouwen van een AI-agent voor pre-sales klantenservice de kant van de ticketdeflectie.

Hoe u dit bouwt met Powerdrill Bloom

Stap 1: Upload uw ticketexport

Upload the ticket export, or the ticket and SLA exports together. Powerdrill Bloom profiles the columns on arrival, so blank timestamps, mixed date formats, and tickets missing a first reply surface before any median is computed.

Stap 2: Beschrijf het rapport in natuurlijke taal

Formuleer de definities in plaats van ze opnieuw op te bouwen. Noem de definitie van de reactietijd, de klok, welke oplossingsstatistiek u wilt, de statusregel voor opgelost en de kanalen binnen de scope.

Stel vervolgens de vragen die de fouten opsporen. Vraag hoeveel tickets helemaal geen reactie van een agent hebben. Vraag welke tickets zijn heropend. Vraag om medianen per kanaal in plaats van één gecombineerd cijfer.

Stap 3: Exporteer de grafiek, het rapport of de presentatie

Exporteer de tabel met statistieken per kanaal, of een grafiek van gemaakte versus opgeloste tickets met de backlog erachter. Slides die de definities naast de cijfers tonen, rollen uit dezelfde run.

Veelgemaakte fouten

Het behaalde SLA-percentage citeren als eerste reactietijd. De ene accepteert een automatische reactie en de andere sluit geautomatiseerde acties volledig uit.

Kalenderuren vergelijken met kantooruren. Het standaardrapport geeft u de eerste, terwijl uw doelstelling waarschijnlijk op de tweede was gebaseerd.

Het gemiddelde gebruiken voor reactie- en oplossingstijden. Een paar achtergelaten tickets verschuiven een gemiddelde naar een niveau dat geen enkel reëel ticket weerspiegelt.

Kanalen op één hoop gooien. De medianen van chat en e-mail verschillen inherent van elkaar, en door ze te combineren worden beide onzichtbaar.

Oplossingstijd rapporteren zonder te vermelden welke. Eerste en volledige oplossingstijd zijn afzonderlijk opgeslagen statistieken, geen afrondingsvarianten.

Een aantal opgeloste tickets als definitief beschouwen. Het aantal opgeloste tickets bevat alleen tickets die momenteel zijn opgelost of gesloten, dus heropeningen veranderen het verleden.

Onbeantwoorde tickets weglaten. Deze worden gedefinieerd als tickets met minder dan één reactie van een agent, en ze zijn de duidelijkste mislukking die het rapport aan het licht kan brengen.

Conclusie

Noem de reactiedefinitie, noem de klok, kies eerste of volledige oplossing, vermeld de statusregel, segmenteer per kanaal en toon heropende en onbeantwoorde tickets. Dat levert een supportticketrapport op waar iemand echt iets mee kan.

Wat het rapport wellicht niet doet, is een zuivere vergelijking maken met de cijfers van een ander bedrijf. De definities zijn configureerbaar, dus een benchmark die u ergens leest, is vrijwel zeker anders gemeten.

Vergelijk het in plaats daarvan met uw eigen geschiedenis, op basis van een vaste set regels. Dat is the versie die u vertelt of er daadwerkelijk iets is verbeterd.

Als het maandelijks opnieuw opbouwen u een dag kost, probeer dan Powerdrill Bloom op uw ticketexport. Zie ook de pagina AI-rapportgenerator en de samenvatting van de stem van de klant.

Veelgestelde vragen

Waarom komt mijn behaalde SLA-percentage niet overeen met mijn eerste reactietijd?

Ze meten verschillende gebeurtenissen. De SLA-eerste reactietijd van Zendesk kan worden behaald door een automatische reactie, terwijl de systeemeigen eerste reactietijdstatistiek geautomatiseerde acties en acties van bots volledig uitsluit.

Moet ik de eerste oplossingstijd of de volledige oplossingstijd rapporteren?

Rapporteer degene die u benoemt. De eerste oplossingstijd eindigt op het moment dat een ticket voor het eerst op opgelost wordt gezet. De volledige oplossingstijd eindigt op het laatste moment, dus heropende tickets scheiden de twee.

Worden supportstatistieken gemeten in kalenderuren of kantooruren?

Beide worden opgeslagen. De vooraf gebouwde Explore-rapporten van Zendesk tonen kalenderuren, en statistieken in kantooruren zijn beschikbaar voor rapporten die u zelf bouwt.

Waarom is het aantal opgeloste tickets van vorig kwartaal veranderd?

Het aantal opgeloste tickets bevat tickets die momenteel zijn opgelost of gesloten. Een ticket dat wordt heropend nadat de periode is afgelopen, valt buiten de telling van die periode.

Can I compare my resolution time to an industry benchmark?

Slechts in beperkte mate. De definities, de klok en de kanaalmix zijn allemaal configureerbaar, dus een gepubliceerd cijfer is waarschijnlijk volgens andere regels gemeten dan de uwe.