Kwaliteitscontrole in Salesforce Service Cloud betekent dat je de antwoorden scoort die een medewerker schreef, het kanaal en de staat waarin de case is achtergelaten. Bepaal eerst wat als het gesprek telt, want een case omvat veel gekoppelde records.
In het kort
- De eigenaar van de case schreef het antwoord vaak niet zelf.
- Koppel elk criterium aan een veld dat in jouw org bestaat.
- Leg de populatie voor je steekproef vast met een rapport.
- Bepaal vóór de uitrol hoe je cases met meerdere kanalen scoort.
Wat kwaliteitscontrole in Salesforce Service Cloud echt betekent
De meeste QA-adviezen gaan uit van een ticket: één klant, één thread, één behandelaar, van boven naar beneden gelezen. Service Cloud werkt niet zo, en dat ene structurele verschil is de reden dat algemene QA-adviezen vaak al in de eerste week uit elkaar vallen.
Een case is een record. Er horen velden bij zoals status, herkomst, reden, prioriteit en eigenaar, al worden de waarden in die keuzelijsten door je eigen beheerder ingesteld en niet door het platform vastgelegd. Rond dat record staat wat de klant en de medewerker echt hebben gedaan: e-mails, chat- of berichttranscripties, interne posts, taken en, als de org telefonie heeft ingericht, gespreksrecords. De casefeed toont een chronologie van die activiteit, maar een chronologie is niet hetzelfde als een gesprek. Ze mengt antwoorden van medewerkers met systeemmeldingen, veldwijzigingen en posts van mensen die de klant nooit hebben gesproken.
De eerste vraag bij QA in Service Cloud is dus niet “wat moeten we scoren”. Het is wat noemen we het gesprek. Er zijn drie verdedigbare antwoorden, en je moet er bewust één kiezen:
- Alleen de uitwisseling met de klant. Elk bericht dat de klant kon zien, op volgorde, zonder interne posts en veldgeschiedenis. Dit lijkt het meest op een ticketthread en is het makkelijkst uit te leggen aan een medewerker.
- De uitwisseling plus de staat van het record. Dezelfde berichten, beoordeeld samen met hoe de case is gecategoriseerd en afgesloten. Geschikt voor teams waarvan de datakwaliteit de rapportage voedt.
- De hele case inclusief intern werk. Berichten, interne notities, overdrachten en taken. Het meest volledige beeld en het moeilijkst consistent te scoren, omdat reviewers het oneens zijn over hoeveel intern werk genoeg is.
Schrijf het antwoord op voordat je criteria schrijft. Doe je dat niet, dan kiest elke reviewer stilletjes zijn eigen antwoord en krijg je het patroon van onenigheid dat elke QA-lead herkent: twee mensen scoren dezelfde case met 60 en 85, en geen van beiden kan zeggen waarom. De scorecardmechaniek die daarop voortbouwt is dezelfde als in elk QA-programma voor support. Heb je er nog geen gebouwd, begin dan met hoe je een QA-scorecard bouwt en kom daarna terug.
Wat je op een case kunt beoordelen, en wat niet
Neem voordat je criteria schrijft een recent afgesloten case en inventariseer wat er echt op staat. Doe dat in je eigen org en niet op basis van een template, want wat aanwezig is verschilt enorm per configuratie van de org.
Meestal beschikbaar
- Berichten die medewerkers hebben geschreven. De e-mailantwoorden, chat- of berichtbeurten en eventuele openbare posts. Dit is het kernbewijs voor alles wat met communicatie te maken heeft.
- Tijdstempels. Wanneer de klant schreef, wanneer de medewerker antwoordde, wanneer de eigenaar wisselde, wanneer de case werd afgesloten. Genoeg om iets te zeggen over reactiesnelheid, met de kanttekeningen hieronder.
- Veldwaarden bij afsluiting. Status, reden, product- of categorievelden en alle aangepaste velden die je org verplicht stelt. Dit maakt een case rapporteerbaar en hoort dus terecht bij kwaliteit.
- Interne notities en posts. De kwaliteit van de overdracht, het onderzoek, de redenering achter een escalatie.
- Eigenaarsgeschiedenis. Wie de case had, en wanneer die werd doorgezet.
Vaak afwezig, en het controleren waard voordat je een criterium belooft
- Telefonie. Of er überhaupt een telefoongesprek aan de case hangt, en of er een transcriptie is in plaats van alleen een opname of een notitie, hangt af van hoe telefonie in je org is ingericht. Controleer dat voordat je een criterium schrijft dat afhangt van de inhoud van het gesprek.
- Wat de medewerker kon zien. Beveiliging op veldniveau en deelregels zorgen ervoor dat een reviewer een case niet per se zo ziet als de medewerker hem zag. Gaat een criterium ervan uit dat de medewerker bepaalde informatie had, controleer dan of dat zo was.
- De stand van de kennisbank op dat moment. Als een artikel veranderde nadat de case was afgesloten, had de medewerker misschien gelijk volgens de versie die hij toen had.
- Alles wat buiten het record gebeurde. Een telefonische terugbelactie vastgelegd als notitie van één regel, een gesprek in een chattool, een persoonlijke overdracht aan een ander team. Dat is echt werk, en voor QA is het onzichtbaar.
De regel die hieruit volgt is kort. Als een criterium niet kan worden onderbouwd met iets op de case, is het geen QA-criterium maar een mening. Vind het veld of het bericht dat het onderbouwt, of haal het uit de scorecard en verplaats het naar coaching. Een algemene QA-checklist voor klantenservice is een handige eerste inventaris, maar elke regel ervan moet deze test doorstaan tegen de lay-out van je eigen cases.
Hoe casedata aansluiten op scorecardcriteria
Dit is de koppeloefening die het programma maakt of breekt. Benoem voor elk criterium het bewijs, de controle en de faalwijze die je verwacht. De laatste kolom slaan teams over, en juist die voorspelt elke discussie die je gaat krijgen.
| Type criterium | Bewijs op de case | Hoe een reviewer het controleert | Waar het misgaat |
|---|---|---|---|
| Juistheid van de oplossing | Het laatste bericht van de medewerker, gelezen naast de velden waarmee de case is afgesloten | Komt het gegeven antwoord overeen met de vastgelegde uitkomst, en was het op dat moment juist | De status wordt gezet door een automatisering of een macro, zodat het record “opgelost” zegt zonder enig bewijs dat dat zo was |
| Naleving van processen | Verplichte velden, interne notities en eventuele entitlement- of serviceniveaurecords die de org heeft ingericht | Vergelijk wat de case vastlegt met je gedocumenteerde proces voor dat type case | De eis staat in een wiki in plaats van in een veld, zodat twee reviewers er twee verschillende versies van toepassen |
| Communicatiekwaliteit | Alleen berichten die medewerkers hebben geschreven, nooit de hele feed | Scoor de tekst die de klant echt kon lezen | Reviewers nemen de toon van interne posts en systeemmeldingen over en rekenen die de medewerker aan |
| Reactiesnelheid en moeite | Tijdstempels op berichten en op eigenaarswissels | Meet de tijd tussen een klantbericht en het volgende antwoord van een medewerker | Wachttijd in de queue, kantooruren en wachten op een ander team worden allemaal aangerekend aan wie de case toevallig heeft |
| Categorisering en datakwaliteit | Herkomst, reden, recordtype en je eigen rapportagevelden | Beschrijven de waarden wat er echt in het gesprek gebeurde | Medewerkers kiezen de waarde die het snelst door de validatieregel komt, en tot nu toe scoorde niemand dat |
| Routering | Eigenaarsgeschiedenis, lidmaatschap van queues, recordtype | Kwam de case meteen bij het juiste team, en zo niet, waarom niet | Een verkeerde routering door een routeringsregel wordt gescoord als fout van de medewerker |
Hoe het scoren van een case verschilt van het scoren van een Zendesk-ticket
Veel support-ops-leads hebben QA gedaan in Zendesk en moeten het nu in Service Cloud doen, of in beide tegelijk. De filosofie van de scorecard is overdraagbaar. De mechaniek niet, en dit zijn de zes verschillen die de meeste tijd kosten. Doe je ook de Zendesk-kant, dan staat de platformspecifieke mechaniek daarvoor apart beschreven in kwaliteitscontrole voor Zendesk.
| Dimensie | Zendesk-ticket | Case in Salesforce Service Cloud |
|---|---|---|
| De eenheid van review | Een ticket is een thread. Aanvrager, behandelaar en opmerkingen lezen als één lineair gesprek | Een case is een record. Het gesprek wordt samengesteld uit gekoppelde berichten, transcripties en feeditems |
| Wie het werk deed | Behandelaar plus de zichtbare auteurs van opmerkingen | Het eigenaarsveld zegt wie de case nu heeft. Het auteurschap moet je per bericht aflezen |
| Kanaal | Meestal een eigenschap van het ticket zelf | Kanalen komen binnen als verschillende gekoppelde records, en één case kan er meer dan één bevatten |
| De steekproefpopulatie bepalen | Weergaven en zoekfilters | Een rapport of lijstweergave gebaseerd op de eigen casevelden van je org |
| Hoeveel standaard is | De veldenset is tussen accounts grotendeels gelijk | Recordtypen, aangepaste velden en keuzelijstwaarden worden per org ingesteld, dus geen enkele scorecard gaat ongewijzigd over |
| Afsluitstatus | Een korte, bekende reeks statussen | Statuswaarden, en wat elke waarde operationeel betekent, worden bepaald door je beheerder |
Hoe je een steekproef trekt die je kunt verdedigen
Het verwijt dat een QA-programma het vaakst krijgt, is dat de reviewer de slechtste cases heeft uitgekozen. In Service Cloud is dat verwijt makkelijk te maken, omdat er geen natuurlijke reviewqueue is en het echt verleidelijk is om te werken vanuit de lijstweergave die al openstaat.
Bepaal eerst de populatie, in een rapport, en sla dat rapport op. Een werkbaar filter: afsluitdatum binnen de reviewperiode, recordtype of queue die het werk aanduidt dat je scoort, kanaal als je kanalen apart scoort, en een uitsluiting voor cases zonder enig bericht van een medewerker. Duplicaten, automatisch afgesloten cases en cases die nooit een mens hebben bereikt zijn ruis, en als je ze in de populatie laat, blazen ze elk gemiddelde dat je daarna publiceert stilletjes op of drukken ze het omlaag.
Trek de steekproef daarna uit die populatie en niet uit de lijst. Twee regels zijn belangrijker dan de omvang van de steekproef:
- Randomiseer binnen lagen, niet over de hele set. Stratificeer per medewerker en per type case en trek daarna willekeurig binnen elke laag. Een puur willekeurige steekproef over een hele maand geeft je drukste medewerkers twintig cases en je nieuwste medewerker één, waardoor individuele scores onvergelijkbaar worden.
- Leg de steekproef vast voordat iemand een case leest. Trek de lijst, sla hem op en review wat je hebt getrokken. Een steekproef die wordt gekozen nadat de reviewer de populatie heeft doorgebladerd, is geen steekproef.
Wees eerlijk tegen jezelf over wat een handmatige steekproef je oplevert. Dertig cases per medewerker per maand reviewen is veel werk, en het vertelt je nog steeds weinig over de specifieke typen cases die zelden voorkomen en de meeste schade doen. Die beperking is rekenkunde, geen kwestie van inzet, en het is dezelfde beperking die het engineering-handboek van NIST beschrijft bij de vraag of een in een steekproef gemeten aandeel defecten aan een eis voldoet: de steekproef moet groot genoeg zijn om de test geldig te maken voordat het antwoord iets betekent. Daarom moeten een score uit een steekproef en een interne kwaliteitsscore die je aan het management rapporteert hun betrouwbaarheidsinterval naast het getal tonen, en daarom is het de moeite waard om te weten waar een QA-steekproef de vraag niet meer kan beantwoorden.
Wie schreef het antwoord: toewijzing bij een case die van eigenaar wisselde
Dit is het probleem waar geen template je op voorbereidt, en het probleem dat het vertrouwen van medewerkers in een QA-programma in Service Cloud het meest beschadigt.
Cases bewegen. Ze worden gerouteerd, geëscaleerd, opnieuw toegewezen, uit een queue gepakt, aan een specialistisch team overgedragen en weer teruggegeven. Het eigenaarsveld legt vast wie de case heeft op het moment dat jij kijkt. Het legt niet vast wie het antwoord schreef dat de klant ergerde, of wie het onderzoek deed dat het probleem oploste. Als je QA-proces een case scoort en het resultaat bij de eigenaar boekt, heb je bij elke overgedragen case het werk van de ene persoon aan de andere toegeschreven.
Het praktische gevolg is voorspelbaar en concreet. De medewerkers die escalaties afhandelen, erven cases die al slecht lopen en krijgen de scores die daaruit volgen. Dat zijn meestal je sterkste mensen. Binnen een kwartaal leren ze dat het ze iets kost om een moeilijke case op te pakken, en het gedrag dat je het meest wilde stimuleren, wordt het gedrag dat je scorebord bestraft.
Vier regels die het oplossen
- Scoor het bericht, niet het record. Elke aftrek hoort bij een specifiek bericht van een medewerker, met tijdstempel en auteur, niet bij de case als geheel.
- Wijs toe op basis van auteur. Lees het auteurschap af van elk bericht in plaats van van het eigenaarsveld. Kan je rapportage dat niet, dan is dat het eerste wat je oplost, nog voordat je ook maar één weging aanpast.
- Behandel cases met meerdere medewerkers expliciet. Scoor de eigen bijdrage van elke medewerker apart, of haal de case uit de individuele scoring en gebruik hem voor procesreview. Beide zijn verdedigbaar. Stilletjes de laatste eigenaar scoren is dat niet.
- Houd de eigenaarsgeschiedenis naast de score. Wordt een score betwist, dan is de eerste vraag altijd wie wat deed. Als het twintig minuten kost om dat te reconstrueren, is de discussie al verloren.
Overgedragen cases zijn bovendien je rijkste bron voor proceswerk in plaats van individuele coaching. Een case die vier keer van eigenaar wisselde voordat hij werd opgelost, vertelt je iets over routering, entitlements of teamgrenzen, en dat hoort thuis in grondoorzaakanalyse en niet op iemands scorecard.
Elke case scoren in plaats van een steekproef
Zodra de handmatige methode staat, ligt de vraag voor de hand of je kunt stoppen met steekproeven. Dat kan, en het argument ervoor is in Service Cloud sterker dan bij een eenvoudiger ticketmodel, omdat de typen cases die er het meest toe doen vaak de zeldzame zijn die een steekproef nooit bereikt. Er is een echt verschil tussen 100% dekking die trends zichtbaar maakt die een steekproef van 3% nooit kan laten zien, en een maandelijkse review van dertig cases per medewerker.
Dekking op zich is echter niet het interessante deel, en is ook geen onderscheidende factor meer. Elke leverancier in deze categorie scoort inmiddels alles. De vraag die bepaalt of een geautomatiseerde score het contact met je team overleeft, is of je kunt laten zien dat de beoordeling klopte. In Service Cloud betekent dat concreet vier dingen:
- Herleidbaarheid tot in de case. Een aftrek moet het criterium noemen en verwijzen naar het precieze bericht in de case dat hem veroorzaakte. “Communicatie: min tien” bij een case met veertig feeditems is onbruikbaar.
- Hetzelfde bewijs dat de beoordeling gebruikte. Een reviewer die een score controleert, moet de set berichten zien waaruit de score is berekend, niet een samenvatting ervan.
- Een route om bezwaar te maken. Een medewerker moet een score kunnen betwisten en iemand de redenering laten bekijken. Kan dat niet, dan is de score een vonnis.
- Gemeten overeenstemming voordat hij meetelt. Laat de geautomatiseerde score een paar weken naast je eigen reviewers op dezelfde cases draaien en valideer de scoring voordat het getal ergens aan wordt gekoppeld dat gevolgen heeft.
Auto QA van Kaizo past je eigen scorecardcriteria toe op cases en houdt de redenering aan het gesprek gekoppeld, zodat een betwiste aftrek terug te voeren is op de uitwisseling die hem veroorzaakte in plaats van uit het geheugen te worden bediscussieerd. Het draait op Service Cloud via de Salesforce-integratie, uitgebreider beschreven in Kaizo op Salesforce, naast dezelfde integratie voor Zendesk. Dat is belangrijk als je QA op beide doet terwijl een migratie loopt. Demo boeken.
Een uitrol die het eerste bezwaar overleeft
QA-programma’s in Service Cloud mislukken op hetzelfde punt: de eerste keer dat een medewerker een score serieus betwist en het programma geen antwoord heeft. Richt de uitrol zo in dat het antwoord er is voordat het bezwaar komt.
| Fase | Wat je doet | Klaar als |
|---|---|---|
| 1. De eenheid bepalen | Kies een van de drie definities van het gesprek en schrijf die op. Inventariseer wat er echt op een afgesloten case in je org staat | Een reviewer zonder omwegen kan zeggen welke records erbij horen |
| 2. Criteria aan velden koppelen | Benoem voor elk criterium het bewijs, de controle en de verwachte faalwijze. Schrap alles wat je niet kunt onderbouwen | Elk criterium verwijst naar een veld of berichttype dat bestaat |
| 3. Het populatierapport bouwen | Eén opgeslagen rapport dat de reviewbare set bepaalt, met uitsluitingen voor automatisch afgesloten cases en cases zonder medewerker | Twee mensen die het rapport draaien, krijgen hetzelfde aantal cases |
| 4. Schaduwscoren en kalibreren | Drie reviewers scoren onafhankelijk dezelfde vijftien cases, waarvan minstens drie van eigenaar wisselden. Vergelijk en discussieer | Je kent de mate van onenigheid tussen je reviewers, en die daalt |
| 5. Publiceren met een bezwaarroute | Kondig de scorecard, de steekproefmethode en de bezwaarprocedure samen aan. Een bezwaar zonder route is een klacht | Medewerkers kunnen de procedure noemen zonder die op te zoeken |
| 6. Rapporteren, dan de koppeling opnieuw controleren | Rapporteer scores naast operationele uitkomsten zoals heropeningen en escalaties. Herzie de koppeling elk kwartaal | De beweging van de score verklaart iets wat een manager al vermoedde |
Een casescore zo rapporteren dat iemand er iets mee doet
Een QA-score die alleen in een QA-tool leeft, wordt gelezen door het QA-team. Om de moeite waard te zijn, moet de score naast de operationele cijfers staan waar de supportleiding al naar kijkt, en zo zijn uitgesplitst dat hij een actie benoemt.
Drie uitsplitsingen doen het meeste werk met Service Cloud-data:
- Per type case of recordtype, niet alleen per medewerker. Kwaliteit varieert veel meer met het soort werk dan met de persoon die het doet. Een laag gemiddelde bij één recordtype is een proces-, kennis- of routeringsprobleem, en dat los je centraal op.
- Per criterium, over het hele team. Een criterium dat breed faalt, is bijna nooit een coachingsprobleem. Het is onduidelijk beleid, een ontbrekend kennisartikel of een slecht geschreven criterium.
- Score tegenover heropenings- en escalatiepercentage. Dit is de controle op de scorecard zelf. Als cases met een hoge score even vaak heropend worden als cases met een lage score, meet de scorecard iets anders dan kwaliteit en moet hij opnieuw worden gewogen.
Vooral die derde uitsplitsing is het beschermen waard. Hij voorkomt dat een QA-programma afglijdt naar een compliance-ritueel dat iedereen uitvoert en niemand gebruikt. Kwaliteitsscores koppelen aan het operationele beeld is precies waar een analyseweergave voor support voor dient, en het is ook de snelste manier om een sceptisch management te laten zien dat het QA-programma iets echts meet.
Veelgestelde vragen
Heeft Salesforce Service Cloud standaard QA-scoring?
Service Cloud geeft je het ruwe materiaal: het caserecord, de berichten en transcripties die eraan gekoppeld zijn, de veldgeschiedenis en een rapportagelaag over dat alles. Een gewogen scorecard, een reviewqueue, kalibratie tussen reviewers en een controleerbaar spoor van bezwaren horen niet bij het standaard case-object. Teams bouwen óf een lichte versie met aangepaste velden en rapporten, die werkt tot de onenigheid tussen reviewers de bottleneck wordt, óf ze voegen een QA-tool toe die cases leest. Controleer wat je eigen org al heeft ingericht voordat je iets aanneemt, want de aanpassingen verschillen enorm.
Wat moet je beoordelen op een Salesforce-case?
Alleen wat de case aantoont. In de praktijk zijn dat de berichten die medewerkers hebben geschreven, de tijdstempels op die berichten en op eigenaarswissels, de veldwaarden waarmee de case is afgesloten, en de interne notities als je definitie van het gesprek die omvat. Alles waar je in het record niet naar kunt wijzen, zoals wat de medewerker op dat moment wist of een terugbelactie vastgelegd als notitie van één regel, hoort bij coaching en niet in een score.
Hoe verschilt QA in Service Cloud van QA in Zendesk?
De filosofie van de scorecard is dezelfde, de mechaniek niet. Een Zendesk-ticket is een lineaire thread met een duidelijke behandelaar, dus de eenheid van review ligt voor de hand. Een Salesforce-case is een record met gekoppelde berichten, transcripties en feeditems, dus de eenheid moet je zelf bepalen. Het auteurschap moet je bovendien per bericht aflezen in plaats van uit het eigenaarsveld, en omdat recordtypen en aangepaste velden per org worden ingesteld, gaat geen enkele scorecard ongewijzigd over tussen twee Salesforce-orgs.
Hoe trek je een steekproef van Salesforce-cases voor QA-review?
Bouw een opgeslagen rapport dat de populatie bepaalt, met filters op afsluitdatum, recordtype of queue, kanaal waar relevant, en een uitsluiting voor cases zonder bericht van een medewerker. Trek daarna willekeurig binnen lagen, per medewerker en per type case, in plaats van willekeurig over de hele maand, zodat elke medewerker een vergelijkbaar aantal cases bijdraagt. Leg de steekproef vast voordat iemand een case opent. Een lijst reviewen die je al hebt doorgebladerd, is geen steekproef.
Wie krijgt de QA-score als een case van eigenaar wisselt?
Niet automatisch de huidige eigenaar. Dat is de standaard waar de meeste programma’s in vervallen, en de standaard die de meeste schade doet. Wijs elk gescoord bericht toe aan degene die het schreef. Bij een case die door meerdere mensen is behandeld, scoor je de eigen bijdrage van elke medewerker apart, of haal je de case uit de individuele scoring en gebruik je hem voor procesreview. Wie de laatste eigenaar scoort op werk dat die heeft geërfd, leert je sterkste medewerkers om escalaties te vermijden.
Kun je e-mail, chat en telefonie op dezelfde case scoren?
Ja, maar bepaal de aanpak vóór de uitrol en niet tijdens het eerste bezwaar. Eén gemengde score over een case met een e-mailthread en een chattranscriptie is moeilijk om op te coachen, omdat de standaarden voor die twee echt verschillen. Elk kanaalsegment apart scoren en apart rapporteren is meestal duidelijker. Speelt telefonie mee, controleer dan eerst of je org echt transcripties gekoppeld heeft en niet alleen opnames, want een criterium dat afhangt van de inhoud van een telefoongesprek is zonder transcripties niet te handhaven.
