Omnichannel klantenservice: wat het betekent en hoe het werkt

Beide modellen bieden meerdere kanalen. Het verschil is of die kanalen context delen. Freshworks definieert multichannel support als het aanbieden van meerdere onafhankelijke kanalen die elk zelfstandig werken, en merkt op dat er doorgaans per kanaal een eigen team voor nodig is. Omnichannelsystemen zorgen er daarentegen voor dat alle kanalen met elkaar verbonden zijn. Zendesk trekt dezelfde grens: bij multichannel support gaan gesprekken niet mee van het ene kanaal naar het volgende, terwijl omnichannel support interacties verbindt tot één doorlopend gesprek en agents een volledig beeld geeft van de geschiedenis van de klant.

Een kanaal toevoegen maakt je nog niet omnichannel. Als WhatsApp-berichten in een aparte app terechtkomen die je e-mailagents niet kunnen zien, heb je er gewoon een silo bij. En klanten wisselen echt van kanaal: een Gartner-enquête onder 5.801 klanten, gepubliceerd in juli 2025, liet zien dat slechts 22% in de eigen kanalen van een bedrijf begint, daar blijft en er het probleem volledig oplost, en dat 51% van de serviceklantreizen nu begint op platforms van derden zoals Google, YouTube en ChatGPT.

De kern van omnichannel support is één plek waar agents elk gesprek zien en beantwoorden. In de Zendesk Agent Workspace kunnen ticketgesprekken e-mail, chat en spraak bevatten, en agents kunnen ook social- en webberichten ontvangen en beantwoorden. Het eigen voorbeeld van Zendesk is een ticket dat begon als livechat en per e-mail verderging, vastgelegd als één doorlopend gesprek. Klantcontext, inclusief de interactiegeschiedenis, staat naast het gesprek, en agents kunnen vanuit hetzelfde scherm helpcenterartikelen zoeken en citeren.

Welke helpdesk je ook gebruikt, een werkende omnichannelopzet heeft dezelfde mogelijkheden nodig:

• Eén klantrecord dat e-mailadressen, telefoonnummers en messaging-ID's koppelt, zodat een WhatsApp-bericht en een e-mail van dezelfde persoon in dezelfde geschiedenis terechtkomen.
• Gespreksgeschiedenis uit elk kanaal op het ticket, inclusief het botgesprek dat vóór een overdracht plaatsvond.
• De mogelijkheid om via een ander kanaal te antwoorden wanneer het oorspronkelijke kanaal geen antwoord meer toestaat.
• Gedeelde tags, velden en macro's, zodat rapportage op elk kanaal op dezelfde manier werkt.

Routing bepaalt welke agent welk gesprek krijgt. De omnichannel routing van Zendesk stuurt nieuwe en open tickets uit e-mail, telefoongesprekken en messaging naar agents op basis van hun beschikbaarheid en capaciteit. In plaats van per kanaal een status in te stellen, stellen agents één centrale status in voor e-mail, voice en messaging. Voor messaging en telefoongesprekken moet de agent online zijn, en elke agent heeft vrije capaciteit nodig, wat betekent dat er minder open tickets aan hem zijn toegewezen dan zijn maximum voor dat kanaal.

Standaard gaat een ticket naar de agent met de meeste vrije capaciteit voor dat kanaal, en bij een gelijke stand naar de agent die het langst geen ticket uit dat kanaal heeft gehad. Je kunt in plaats daarvan overschakelen op round robin, en focus mode inschakelen zodat een agent niet tegelijk messaginggesprekken en telefoongesprekken krijgt. Afhankelijk van je Zendesk-abonnement kan routing ook rekening houden met de tijd tot een SLA-overschrijding, de ticketprioriteit en de skills van agents.

Het nut van routing over kanalen heen in plaats van per kanaal is gedeelde capaciteit: een agent die aan de telefoon zit, moet geen nieuwe chat aangeboden krijgen, en een agent met weinig open e-mails kan meer werk aannemen.

Omnichannel maakt kanalen niet identiek. Messagingplatforms stellen regels over wanneer een bedrijf mag antwoorden, en je workflows moeten die respecteren.

Deze regels bepalen je workflow. Als een agent een WhatsApp-gesprek oppakt meer dan 24 uur na het laatste bericht van de klant, is een vrij antwoord niet mogelijk: je hebt een goedgekeurde template nodig, of je stapt over op een ander kanaal zoals e-mail. Ook bots hebben ermee te maken, omdat de Human Agent-tag van Messenger alleen voor menselijke antwoorden is. Raadpleeg de actuele documentatie van Meta voordat je een opzet rond deze limieten ontwerpt, want Meta werkt zijn messagingbeleid en prijzen bij.

1. Maak een lijst van elk kanaal dat klanten nu gebruiken en waar elk kanaal terechtkomt: welke tool, welk team, welke inbox.
2. Breng de kanalen samen in één helpdesk, via native integraties waar die bestaan en via API's of webhooks waar dat niet zo is.
3. Bepaal hoe je identiteiten over kanalen heen koppelt, bijvoorbeeld op e-mailadres en telefoonnummer, en hoe je dubbele records samenvoegt.
4. Richt één routingconfiguratie in met capaciteit per kanaal, in plaats van aparte wachtrijen per team.
5. Zorg dat overdrachten van bot naar mens het volledige gesprek en de klantgegevens in het ticket meenemen.
6. Voeg kanaalspecifieke regels toe, zoals templateantwoorden op WhatsApp na 24 uur en verschillende SLA-doelen voor live- en asynchrone kanalen.
7. Rapporteer per klant en per probleem over alle kanalen heen, niet alleen per kanaal.

TascaLab koppelt kanalen aan de helpdesk die je al gebruikt, zoals Zendesk of Freshdesk, met API's, webhooks en Make of n8n. Een Standard Chat Bot (€ 510, eenmalig) dekt 3–5 kanalen, zoals je website, WhatsApp, Telegram, Facebook Messenger en Instagram, en Ticket Routing & Categorization (€ 690) sorteert binnenkomende gesprekken in de juiste wachtrij. Elk project omvat basisdocumentatie, 30 dagen ondersteuning na livegang en geen verborgen kosten, en de meeste implementaties duren 1–3 weken. In een gratis Health Check-gesprek van 30 minuten worden je huidige kanalen in kaart gebracht voordat er iets wordt gebouwd.