Zendesk- en Intercom-audit: wat we scoren vóór AI-retrofit

Dinsdag, 10:00. Screen-share met de operations lead van een Nederlands e-commerce-merk, ergens tussen €8M en €15M omzet. Zendesk Professional, 22 agents, Intercom op de website-widget, Klaviyo gekoppeld voor de post-purchase loop. Ze willen er een AI-agent overheen retrofitten om 60% van de inbound te triageren. In het deck van de partner staat “binnen twee weken live.” Wij zeggen: eerst de audit.

We draaien dezelfde checklist op elke Zendesk- plus Intercom-tenant onder de €20M voor we offreren. Niet omdat we allergisch zijn voor korte trajecten — korte trajecten zijn prima — maar omdat de prijs van een support-agent-retrofit bepaald wordt door de rommel in de tenant, niet door het volume op het dashboard. Twee magazijnen identiek op papier: het ene levert in drie weken, het andere doet er vijf maanden over. Het verschil zit in wat de audit vindt.

Hier is de checklist, in de volgorde waarin we 'm draaien.

Triggervolgorde op de top 35 macro's

Zendesk draait triggers in een vaste volgorde op elk ticket-event. Macro's zijn templates die agents toepassen, maar het echte werk gebeurt in de trigger-keten die ze afvuren door tags, velden en groups te zetten. Op een typische mkb-tenant vinden we tussen de 80 en 150 actieve triggers en tussen de 200 en 400 macro's. We scoren alleen de top 35 macro's — de macro's die per agent meer dan vijf keer per week gebruikt worden — want dat is wat de AI-agent in productie gaat repliceren. De rest is inventaris.

Per macro lopen we de trigger-keten af die hij activeert en checken we drie dingen: reset een latere trigger een veld dat de macro net heeft gezet; vuurt een tag-lezende trigger af vóór de tag-zettende trigger; gaat een notificatie-trigger naar een Slack-kanaal dat afgelopen augustus is gearchiveerd. We scoren als clean, out-of-order of stilletjes kapot.

Macro                       | Triggers fired         | Order | Verdict
----------------------------|------------------------|-------|---------------
Refund request - eligible   | set_refund_tag,        | OK    | clean
                            | route_to_finance       |       |
Track-and-trace             | set_tnt_tag,           | BAD   | out-of-order
                            | enrich_from_PostNL     |       | (read before set)
Wrong size - return label   | set_return_tag,        | OK    | clean, but
                            | notify_warehouse_slack |       | slack room dead

Waarom dit telt voor een AI-retrofit: een trigger die vandaag stilletjes faalt, werkt nog steeds voor menselijke agents, want de mens compenseert. Die plakt het track-and-trace-nummer met de hand in de reply. De AI-agent erft de trigger als het contract en zet de kapotte staat in productie. We hebben een “klaar voor live”-agent op een zaterdagochtend 412 klanten een leeg track-and-trace-veld zien sturen voor iemand het door had.

Tag-drift op conversaties over de laatste 90 dagen

Trek de CSV van elke tag die in de laatste 90 dagen op een ticket is gezet. Groepeer op frequentie, sorteer aflopend. Een gezonde tenant heeft een korte staart: 80% van de tickets raakt 20 tot 30 tags, en de rest is begrensd categorisch — land, kanaal, productlijn. Een gedrifte tenant heeft 600+ unieke tags, waarvan 80% een of twee keer gebruikt is, meestal typo's (refund_requestd), dode campagnecodes (q4_2023_blackweek_DE) en verlaten experimenten (test_agent_routing_v2_FINAL_NEW).

Drift sloopt retrofits, want de trainingsset voor “hoe ziet dit ticket eruit” wordt ruis. De agent leert de lange staart voorspellen, en die is per definitie niet voorspelbaar. We meten drie getallen per tenant:

• Tag-entropie — Shannon-entropie over de tag-verdeling. Onder 4,5 bits is gezond. Boven 6 betekent dat er op elk ticket alles kan gebeuren.
• Orphan rate — percentage tags dat minder dan drie keer in 90 dagen is gebruikt. Onder 30% is gezond. We hebben 78% gezien.
• Overlap — handmatig gescoord, door ons. Drie verschillende tags die “retourzending uit België” betekenen, gaan terug naar één. Dit doen we met de hand, want regex pakt de synoniemen niet.

Een kleine jq-snippet op de tag-export, als je 'm zelf wil scoren voor de meeting:

cat tags_90d.json \
  | jq -r '.[] | .tag' \
  | sort | uniq -c | sort -nr \
  > tag_counts.txt

# orphan rate
awk '{ if ($1 < 3) o++; t++ } END { print o/t }' tag_counts.txt

Als de orphan rate boven 0,5 uitkomt, begint het gesprek over de AI-retrofit met een tag-merge-sprint, niet met een modelkeuze.

Side-conversation-API-rotatie en het AVG-spoor

Dit is het stuk dat de meeste offertes sloopt, en het stuk dat niemand in de discovery call benoemt.

Zendesk side conversations zijn de manier waarop een agent een magazijn, leverancier of 3PL erbij betrekt — zonder de klantthread bloot te leggen. Ze draaien over externe transports: e-mail, Microsoft Teams, Slack. Elk transport authentiseert met credentials in de integratielaag van Zendesk. Onder elk redelijk security-beleid roteren die credentials elke 90 dagen. Bij die rotatie mogen drie dingen niet breken.

1. Webhook-delivery voor nieuwe replies op bestaande side conversations.
2. Attributie-metadata op elk bericht — wie zei wat, wanneer, op welk kanaal.
3. Het export-endpoint dat een AVG / GDPR Artikel 15-inzageverzoek bedient, dat juridisch ook side-conversation-inhoud moet bevatten waar klantgegevens in voorkomen.

We testen dit door de credential in een staging-tenant te roteren, daarna direct een ticket met een actieve side conversation te exporteren en de JSON op volledigheid te checken. Van de laatste tien Nederlandse mkb-tenants die we volgens dit protocol hebben geaudit, overleefden er drie de rotatie schoon. Zes behielden de berichten, maar verloren de attributie — de side-conversation-berichten kwamen terug als “external participant,” datumstempels intact, maar de afzendernaam weg. Eén tenant verloor de berichten volledig uit de export, omdat de integratie-token alleen scope had op die ene conversation-thread; roteren trok de toegang met terugwerkende kracht in.

Het retrofit-risico: een AI-agent die namens de klant uitwaaiert naar side conversations erft deze breekbaarheid. Als het redeneerspoor van de agent afhankelijk is van side-conversation-context — “ik heb het magazijn gevraagd, die zei ja, dus bevestigde ik aan de klant” — en dat spoor bij de volgende key-rotatie verdwijnt, heb je een black-box-beslissing in productie die je niet kunt reconstrueren. Dat is geen theoretisch AVG-probleem. Het is een AVG-probleem zodra de eerste klant vraagt waarom.

Het scoreformulier

We persen de audit in één pagina, vijf categorieën, elk gescoord van 0 tot 3. We offreren geen retrofit op een tenant die onder de 7 van de 15 scoort. Onder 7 offreren we eerst een opschoning en kijken we daarna opnieuw naar de retrofit.

Categorie                        | Score 0-3 | Notities
---------------------------------|-----------|---------------------------
Trigger-health (top 35 macro's)  |           | clean / out-of-order / kapot
Macro-dekking vs ticket-redenen  |           | matcht de library wat er
                                 |           | daadwerkelijk binnenkomt
Tag-entropie en orphan rate      |           | entropie < 4,5, orphan < 30%
Side-conversation-rotatie        |           | overleeft de staging-test
AVG-spoor-integriteit            |           | export reproduceert de thread
---------------------------------|-----------|---------------------------
Totaal                           |    /15    | <7 = eerst opschonen

Het getal dat het zwaarst weegt, is het laatste. We hebben retrofits opgeleverd op tenants met rommelige macro's — mensen hebben die macro's geschreven, mensen kunnen ze in een sprint opschonen. We zijn weggelopen van tenants waarvan het AVG-spoor een credential-rotatie niet kon overleven, want dat is een structureel probleem met de integratie-topologie en het is niet aan de AI-agent om dat op te lossen. Dat is aan het platformteam, vóór iemand er een agent bovenop zet.

Wat de drie overlevers gemeen hadden

Van de drie tenants uit onze laatste batch van tien die de side-conversation-rotatie schoon doorkwamen, had er geen het duurste Zendesk-abonnement, geen had een toegewijde platform engineer, en geen was recent overgestapt naar een ander platform. Wat ze wél hadden, was saai: één eigenaar met naam en toenaam van de integratie-credentials, een 90-daagse rotatie die echt in een runbook stond, en side conversations beperkt tot twee transports in plaats van vijf. Minder oppervlakte, minder secrets, één persoon die weet waar de keys liggen. Dat is het hele patroon.

Wat je vandaag kunt doen

Open Zendesk, exporteer de tag-activiteit over de laatste 90 dagen, draai de jq-snippet hierboven en lees de orphan rate hardop voor. Zit je boven de 50%, dan begint het gesprek over de AI-retrofit met een tag-opschoning, niet met een modelkeuze. Toen we afgelopen winter de support-agent bouwden voor een Nederlands woonmerk, was dit precies het ding dat het project bijna deed ontsporen — 612 unieke tags in 90 dagen, geen taxonomie, geen eigenaar. We hebben het opgelost met een tag-merge-sprint van één week voor er ook maar een begin werd gemaakt met het AI-agent-werk, en de retrofit werd opgeleverd binnen het oorspronkelijke window van drie weken.

Exporteer de tags. Lees de orphan rate. Daar begint de audit.