Escalatiemanagement: zo voorkom je vastgelopen klanten

Chayenne Garcia • 23 juli 2026

Een escalatie is geen afronding, maar een overdracht. Zo voorkom je dat klanten wachten op een team dat niet weet dat het aan zet is.

Een klant meldt een probleem. De eerste lijn kan het niet oplossen en zet het door naar techniek. Techniek heeft extra informatie nodig, maar stelt die vraag intern. Drie dagen later belt de klant zelf, geïrriteerd, en niemand kan vertellen waar het ticket staat. Herkenbaar?

Dit is zelden een kwestie van luie medewerkers of slechte software. Het is een ontwerpprobleem. In de meeste organisaties is escalatiemanagement nooit bewust ingericht, maar organisch ontstaan. Er zijn geen criteria, geen eigenaar en geen afspraak over wie de klant op de hoogte houdt. In dit artikel lees je waar klanten precies vastlopen tussen teams, hoe je een escalatieproces opzet dat wel houdbaar is, en welke inrichting in je ticketsysteem het verschil maakt tussen een gecontroleerde overdracht en een zwart gat.

Wat escalatiemanagement eigenlijk is

Escalatiemanagement is het geheel van afspraken dat drie dingen vastlegt:

Wanneer een vraag doorgaat naar een ander team of een hoger niveau
Wie er vanaf dat moment verantwoordelijk is voor de oplossing
Hoe de klant tussentijds op de hoogte blijft, en met welke frequentie

Die drie horen bij elkaar. Ontbreekt er één, dan valt het proces om. In de praktijk hebben veel organisaties alleen het eerste punt geregeld, en dan nog impliciet. "Als je er niet uitkomt, gooi je hem naar tweede lijn." Dat klinkt werkbaar, tot je gaat meten. Dan blijkt dat een flink deel van je tickets minstens één keer van eigenaar wisselt, en dat juist die tickets veel langer openstaan dan de rest.

Het probleem is dat een escalatie in de beleving van de eerste lijn een afronding is. Het ticket is weg, de wachtrij is korter, het gevoel is dat het werk gedaan is. Voor de klant begint op dat moment juist het lange wachten. Zolang je escalatiemanagement die twee perspectieven niet aan elkaar knoopt, blijft er een gat waar klanten in verdwijnen.

De vier plekken waar klanten vastlopen tussen teams

Als je meerdere escalatiestromen naast elkaar legt, komen steeds dezelfde vier knelpunten terug.

De koude overdracht. Het ticket gaat door met de originele klantvraag en verder niets. Geen samenvatting, geen uitgevoerde stappen, geen hypothese. Het ontvangende team begint van voren af aan en stelt de klant vragen die al beantwoord zijn.
Het niemandsland. Na de overdracht is er formeel geen eigenaar meer. Het ticket ligt in een groepswachtrij waar iedereen langsloopt en niemand zich verantwoordelijk voelt.
De stille periode. Tweede lijn werkt aan het probleem, maar communiceert intern. De klant hoort weken niets en concludeert terecht dat er niets gebeurt.
De boemerang. Het ticket komt terug naar de eerste lijn met de opmerking "geen technisch probleem", zonder toelichting. De eerste lijn weet niet wat ze de klant moet vertellen en zet het ticket opnieuw door.

Wat deze vier gemeen hebben: het zijn geen incidenten. Het zijn structurele gevolgen van een proces waarin overdracht wel is toegestaan, maar nergens is beschreven.

Zo richt je een escalatieproces in dat wel werkt

1. Begin bij de criteria, niet bij de techniek. Een escalatie hoort te starten op basis van een objectief kenmerk, niet op basis van hoe druk of hoe zeker een agent zich voelt. Werkbare criteria zijn bijvoorbeeld:

De vraag vereist rechten, systeemtoegang of kennis die de eerste lijn niet heeft
Het probleem raakt meerdere klanten tegelijk of duidt op een storing
De klant heeft na twee contactmomenten nog steeds geen oplossing
Er ligt een contractuele of juridische component onder de vraag

Wie hier vastloopt omdat het proces over meerdere afdelingen heen ligt, heeft baat bij een externe blik. Dat is precies wat wij doen binnen onze klantenservice consultancy.

2. Leg vast wat er meegaat. Een warme overdracht bevat altijd vier elementen:

Een korte samenvatting van het probleem in eigen woorden
Wat er al is geprobeerd, inclusief wat niet werkte
Wat de klant tot nu toe is beloofd
De urgentie, met de reden daarachter

Dit kost de eerste lijn twee minuten en bespaart de tweede lijn er twintig.

3. Bepaal wie de klant houdt. Dit is het lastigste punt en het belangrijkste. Mijn advies is om dat eigenaarschap bij de eerste lijn te laten, ook na de escalatie. De specialist lost het probleem op, de eerste lijn blijft het gezicht naar de klant. Zo houd je één aanspreekpunt en voorkom je dat een klant met drie afdelingen tegelijk in gesprek raakt. Spreek daarbij een vast terugkoppelritme af, bijvoorbeeld elke twee werkdagen een update, ook als er niets nieuws te melden is. Juist die lege update voorkomt de meeste boze telefoontjes.

4. Koppel je escalatieniveaus aan realistische doorlooptijden. Een tweede lijn die structureel overvraagd is, haalt geen enkele afspraak. Botst je escalatiebelofte met je bezetting, dan ligt de oplossing in slimmere planning via Workforce Management, niet in strengere targets.

Escalatiemanagement in Zendesk: welke inrichting het verschil maakt

De techniek lost het proces niet op, maar maakt het wel afdwingbaar. In Zendesk leg je escalatiemanagement vast met een handvol instellingen die je eenmalig inricht:

Een apart veld voor escalatieniveau, in plaats van tickets alleen verplaatsen tussen groepen. Zo blijft zichtbaar dat een ticket geëscaleerd is en houd je de volledige historie in één ticket.
Triggers die de toewijzing en notificatie automatisch regelen zodra dat veld verandert.
Automations die aan de bel trekken wanneer een geëscaleerd ticket te lang stilstaat, zonder dat iemand daarop hoeft te letten.
Side conversations voor het interne overleg. Je collega bij techniek of logistiek beantwoordt de vraag binnen hetzelfde ticket, terwijl de klant alleen jouw communicatie ziet. Het ticket blijft van jou, de kennis komt bij jou binnen.
Skills-based routing, als je daarover beschikt, om escalaties toe te wijzen op vaardigheid in plaats van afdeling.

Zit die logica er nu niet in, dan is dat zelden een gebrek aan functionaliteit. Het is een inrichtingskwestie die je oplost bij de Zendesk implementatie of bij een herziening daarvan. Loopt de klant via meerdere kanalen binnen, dan is het samenbrengen daarvan in één omnichannel klantenservice-omgeving een voorwaarde. Anders escaleer je per kanaal en raak je alsnog het overzicht kwijt.

Meet daarna wat er gebeurt. Drie cijfers vertellen je binnen een kwartaal waar je proces lekt:

Het aantal escalaties per maand, afgezet tegen je totale ticketvolume
De gemiddelde doorlooptijd ná het moment van escalatie
Het aantal keren dat een ticket heen en weer gaat tussen teams

Zet die cijfers in een customer service dashboard zodat je bijstuurt voordat een klant klaagt.

Wat een gecontroleerd escalatiepad je oplevert

Escalaties zullen er altijd zijn. Een deel van de vragen is nu eenmaal te specialistisch, te gevoelig of te complex voor de eerste lijn, en dat is geen falen. Het wordt pas een probleem als de escalatie zelf ongestructureerd verloopt, want dan verliest de klant niet alleen tijd, maar ook vertrouwen. En dat vertrouwen herstel je niet met een snelle oplossing achteraf.

Organisaties die hun escalatiemanagement wel bewust inrichten, zien meestal binnen enkele maanden hetzelfde patroon. De doorlooptijd van complexe tickets daalt, het aantal heropende tickets neemt af, en de klachten over "ik moest mijn verhaal drie keer vertellen" verdwijnen grotendeels. Intern gebeurt er iets vergelijkbaars: de wrijving tussen eerste en tweede lijn neemt af, omdat de verwachtingen over en weer eindelijk expliciet zijn.

Het mooie is dat je hiervoor zelden nieuwe software nodig hebt. De meeste knelpunten los je op met afspraken, een paar velden en een handvol automatiseringen in het systeem dat je al gebruikt. De vraag is vooral of iemand in je organisatie het escalatiepad ooit heeft uitgetekend. Als het antwoord nee is, weet je waar je begint.

Wil je weten waar klanten in jouw proces vastlopen tussen teams? Plan een vrijblijvend gesprek met een van onze consultants.