Ken je klant, kies dan je kanalen

In het kort. Een kanaal toevoegen is makkelijk, het bemensen niet. Neem je top tien contactredenen, geef elke reden een kanaal en een reden, en schrijf op wat je nooit automatiseert. Eén pagina, één middag, geen journey-mapping-programma nodig.

Je kunt dat vermijden zonder een onderzoeksproject. En weersta de neiging om alles in één keer op te lossen, want daar lopen deze projecten meestal stuk. Probeer geen tien jaar in één keer te repareren. Verhuis wat je hebt, laat mensen eraan wennen, en begin dan met optimaliseren.

Voor veel teams is de eerste echte winst kleiner dan ze verwachten. Voice, e-mail en chat op één plek krijgen is al de grote verandering, en dat is genoeg voor maand één.

Waar dit artikel in de serie past

Dit is het tweede van vier samenhangende artikelen over de stap van wachtrijbeheer naar het eigenaarschap van de klantreis.

Deel één eindigde met een week aan gelogde contactoorzaken en een benoemde eigenaar die iets buiten het contactcenter kan veranderen. Dit deel maakt van dat log een kanaalontwerp: elke contactreden krijgt een kanaal en een reden om daar te zijn, en alles wat nooit geautomatiseerd zou moeten worden, komt op een aparte lijst voordat iemand een flow bouwt.

Wat uit dit deel komt, is een kanaalkaart van één pagina. Deel drie test of je data de geautomatiseerde delen van die kaart echt kan ondersteunen, en deel vier meet of het ontwerp werkt zodra echte klanten het gebruiken. Als je het oorzakenlog uit deel één nog niet hebt gedraaid, doe dat dan eerst, want een kanaalbeslissing zonder dat log is giswerk met een projectplan eraan vast.

Tien redenen, één pagina, één middag

Haal de contactredenen van vorige maand uit je telefoonsysteem en je inbox. Neem de top tien. Als je rapportage te grof is, vraag dan drie agents een uur. Ze noemen er acht van de tien uit hun hoofd.

Schrijf voor elke reden vier dingen op: hoeveel volume hij vertegenwoordigt, op welk kanaal hij vandaag binnenkomt, wie hem oplost, en op welk kanaal hij zou moeten binnenkomen. Dat is de hele oefening. Het past op één pagina en het houdt stand in de praktijk, wat uitgebreidere frameworks vaak niet doen.

Match daarna redenen aan kanalen. Complex of emotioneel gaat naar voice. Statusvragen en simpele verzoeken gaan naar self-service of messaging. Alles wat een papieren spoor nodig heeft, gaat naar e-mail. Drie kanalen die goed werken verslaan er zeven die half worden bijgehouden.

Segmenteer je klanten op gedrag in plaats van demografie. Een inkoper, een consument met een eenmalige vraag en een key-account hebben een verschillende tolerantie voor moeite, en dat verschil bepaalt je kanaalmix. Leeftijd en postcode niet.

Eén randvoorwaarde geldt voor allemaal. Onderzoek van Zendesk zet het aandeel consumenten dat verwacht dat een medewerker direct toegang heeft tot eerdere interacties, ongeacht het kanaal, op 87%. Welke mix je ook kiest, context moet met de klant meereizen, anders heb je een reeks losse wachtrijen gebouwd en die omnichannel genoemd.

Vraag het je agents, maar stop daar niet

Betrek de mensen die het systeem gebruiken. Weet alleen wat je terugkrijgt. Hun referentiekader is de tool van vandaag, dus requirements komen eruit als een kopie ervan.

Daarom zijn demo- en inspiratiesessies met leveranciers de tijd waard. Niemand kan om iets vragen dat hij nooit heeft gezien. Gebruik die sessies om het kader te verbreden, en laat daarna het oorzakenlog uit deel één bepalen wat er echt gebouwd wordt.

"Vraag mensen wat ze nodig hebben en ze beschrijven het systeem dat ze al hebben, met één knop op een andere plek."

Daarom leveren intern verzamelde requirementslijsten meestal een iets mooiere versie van het verleden op. Gebruik de agents om te ontdekken wat er stukgaat. Gebruik blootstelling van buiten om te ontdekken wat mogelijk is. Vraag niet één groep om allebei te doen.

Test wat er gebeurt met de gesprekken waar niemand op rekende

Eén voorbeeld uit een project waar we bij werden gehaald. De organisatie draaide al twaalf jaar dezelfde opzet: een IVR met zes opties en een keten van fallbacks daarachter. Elk gesprek dat het menu niet kon plaatsen, belandde uiteindelijk bij de receptie.

In het nieuwe ontwerp was de receptie verdwenen. Dus elk gesprek dat daar vroeger eindigde, viel nu door naar een afdeling. Die organisatie had er drie aparte bedrijven onder zitten, en de afdeling die die gesprekken nu kreeg, bediende er maar één van. Gevolg: een stroom gesprekken die niets met hen te maken hadden, en het oordeel dat het nieuwe platform het bedrijf niet aankon.

Het was nooit het platform. Niemand had onder druk getest wat er gebeurt met gesprekken die het menu niet kan plaatsen zodra het menselijke vangnet weg is. Neem dus je flows, haal in gedachten de fallback weg, en volg het gesprek. Waar landt het, en wil dat team het hebben?

De lijst met dingen die je nooit automatiseert

Schrijf hem op voordat iemand iets bouwt. Overlijden. Klachten met emotioneel gewicht. Kwetsbare klanten. Veiligheidskwesties. Alles waarbij efficiënt door software afgehandeld worden zou voelen als onzorgvuldig behandeld worden.

Een uitvaart hoort niet in een telefoonmenu. Voor een consumentenbedrijf is een sterfgeval in de familie het duidelijkste voorbeeld. Iemand belt om een account op te zeggen voor een overleden familielid. Elke seconde door opties navigeren is een seconde te horen krijgen dat het bedrijf wel wat beters te doen heeft. Hier valt geen automatiseringswinst te halen, alleen schade te voorkomen.

Zorg er daarna voor dat elke geautomatiseerde flow een uitweg heeft. Een route naar een mens die de klant kan vinden zonder de truc te kennen, zonder zichzelf te herhalen, en zonder terug te gaan naar het begin van het menu.

Transparantie is nu wet, geen fatsoen

In Europa is dit op 2 augustus 2026 opgehouden een ontwerpvoorkeur te zijn. Vanaf die datum gelden de transparantieverplichtingen in artikel 50 van de AI Act, en die dekken elk systeem dat direct met mensen omgaat, inclusief chatbots en spraakassistenten. Mensen moeten te horen krijgen dat ze met AI te maken hebben, tenzij het uit de omstandigheden duidelijk is. De Europese Commissie publiceerde haar definitieve richtsnoeren op 20 juli 2026, en boetes voor niet-naleving lopen op tot 15 miljoen euro of 3% van de wereldwijde jaaromzet, afhankelijk van welke hoger is.

Twee praktische gevolgen voor een organisatie die in meer dan één land actief is. De verplichting volgt je gebruikers, dus een contactcenter buiten de EU dat EU-klanten bedient, valt eronder. En de verplichting landt op de gebruiker net zo goed als op de leverancier, dus het platform kopen draagt de plicht niet over. Goedkoper om het nu in te bouwen dan later achteraf.

Er zit hier een breder punt in. Het 2026-onderzoek van DMG Consulting laat medewerkersbeleving zakken naar 9,1% van de strategische prioriteiten, terwijl DMG zelf een hybride model van menselijke en AI-agents beschrijft als het realistische operating model voor de komende jaren. Die twee passen niet bij elkaar. Plan voor de mensen die je nog steeds nodig zult hebben.

Doe dit deze week

• Haal de top tien contactredenen van vorige maand op, of boek een uur met drie agents
• Vul de vier kolommen in voor elke reden
• Schrijf je nooit-automatiseren-lijst en laat de sponsor die tekenen
• Controleer elke live geautomatiseerde flow op een AI-melding en een route naar een mens

Checklist, deel 2

• Top tien contactredenen met volume, op één pagina
• Klantsegmenten op basis van gedrag, niet demografie
• Een kanaalkeuze per contactreden, met een reden eraan vast
• Alleen kanalen die je echt kunt bemensen
• Elk fallback-pad getest, inclusief de paden zonder mens aan het eind
• Geschreven lijst met redenen die nooit worden geautomatiseerd
• Een vindbare route naar een mens in elke geautomatiseerde flow
• Klanten krijgen te horen wanneer ze met AI te maken hebben, in lijn met AI Act artikel 50

Volgende in deze serie

Je kanaalkaart zegt nu welke contactredenen zonder mens afgehandeld zouden moeten worden. Deel drie, Begin bij je data, niet bij je bot, controleert of je data dat echt kan ondersteunen, en geeft je vijf criteria voor het kiezen van een eerste geautomatiseerde use case die je niet voor schut kan zetten.

Lees de hele serie

Deze vier artikelen zijn geschreven om in volgorde te lezen. Elk deel levert iets op dat het volgende gebruikt.

• Deel 1. Los eerst het mandaat op, dan de wachtrij. Wie is eigenaar van het probleem, en hoe ver reikt hun mandaat.
• Deel 2. Ken je klant, kies dan je kanalen (dit lees je nu). Welke contactreden op welk kanaal thuishoort, en wat je nooit automatiseert.
• Deel 3. Begin bij je data, niet bij je bot. Of je data ondersteunt wat je wilt automatiseren, en waar je begint.
• Deel 4. Zet het aan, meet het, en durf het uit te zetten. De cyclus die de eerste drie delen levend houdt na go-live.

Bron: DMG Consulting LLC, 2026 CX AI Playbook: Strategic Outlook and Investment Priorities, februari 2026, gesponsord door Five9. Aanvullende marktdata van Gartner, Zendesk en openbare analistencommentaren, opgehaald in augustus 2026.