Chat agent voor hostingsupport: 62% van tier-1 in 4 minuten

Het is 21:14 op een zaterdag in Haarlem. De dienstdoende engineer bij een managed-hosting reseller van 24 man is twee biertjes diep op een barbecue als zijn pieper afgaat. Een WordPress-site die order-bevestigingen verstuurt, weigert elke uitgaande mail met een 550 reject. Het ticket staat al negen minuten open.

De chat agent in hun supportpaneel heeft de eerste vier stappen die hij zelf had gedaan al uitgevoerd. Het systeem haalde het betreffende domein op, controleerde SPF en DKIM, vond het kapotte record en stelde de fix op. Het wacht op zijn akkoord voor de DNS-wijziging. Hij knikt via zijn telefoon. Het ticket sluit op minuut elf.

Drie maanden eerder had datzelfde ticket tot maandagochtend in de wachtrij gestaan.

Deze post is de architectuur en de eerlijke cijfers van de chat agent die nu tier-1 draait bij deze reseller. Ze willen liever niet bij naam genoemd worden, dus noemen we ze de Haarlemmer. Het headlinegetal klopt: 62% van hun tier-1 hostingtickets sluit binnen vier minuten zonder dat een engineer eraan komt. Het interessante deel is wat de agent weigert te doen.

Hoe het was

De Haarlemmer draait ongeveer 9.000 sites voor Nederlandse mkb-bedrijven en een lange staart van eenmansbureaus. Hun stack is DirectAdmin op bare metal in twee Nederlandse datacenters, gefactureerd via WHMCS. Klanten noemen het hostingpaneel "cPanel" omdat ze dat altijd zo deden. De meesten zijn twee jaar geleden van cPanel afgestapt, toen de licentieprijzen omhoog gingen.

Hun tier-1 ticketmix, gemeten over een normale week voordat we iets aanraakten:

• Ongeveer een derde was e-mailbezorging: DNS, SPF, DKIM, blacklist-hits.
• Een vijfde was "site is down" wat neerkwam op PHP-versie mismatches of stil gefaalde SSL-vernieuwingen.
• Ongeveer een op zes was mailbox-quota of wachtwoord-resets.
• Een op zeven was database connection limits.
• De rest was alles wat overbleef, inclusief de echt lastige.

De gemiddelde first-response was 47 minuten tijdens kantooruren en zes uur plus in het weekend. Hun support lead, die dit al negen jaar doet, sloot de meeste tier-1 tickets binnen vijf minuten zodra ze eraan toekwam. De bottleneck was nooit vaardigheid. Het was queue-diepte.

Wat we gebouwd hebben

Drie stukken, aan elkaar genaaid met zorg over welk stuk wat mag.

WHMCS als ruggengraat

Elk ticket leeft in WHMCS. Elke klant heeft daar een client_id. We hebben de ticketwachtrij niet verplaatst naar een nieuwe tool. We hebben de agent via de publieke API aan WHMCS gehangen, zodat de bron van waarheid voor "is dit ticket gesloten" blijft waar de support lead al kijkt. Alles wat de agent doet verschijnt als een reply in het ticket met een duidelijke robot-handtekening.

Een read-only DirectAdmin mirror

De agent logt nooit in op de live DirectAdmin API. Hij leest uit een mirror die we elke 90 seconden synchroniseren: domeinlijst, mailbox-status, huidige PHP-handler, laatste backup-timestamp, huidige zonefile, quotagebruik. Alles wat de agent nodig heeft om te diagnosticeren, niets waarmee hij kapot kan maken.

Dit klinkt paranoïde. Dat is het ook. Het punt is dat de agent "wat is het SPF-record op dit domein op dit moment" kan beantwoorden in 40 milliseconden zonder ooit een credential vast te houden waarmee hij naar productie zou kunnen schrijven.

Een Claude-aangestuurde escalation gate

Als de agent besluit dat hij iets wil wijzigen (een zonefile herschrijven, een proces herstarten, een mailbox-wachtwoord resetten), doet hij dat niet zomaar. Hij belt een gate aan. De gate heeft één regel: elke actie die state muteert, moet eerst een snapshot opleveren, precies afgebakend tot wat er gaat veranderen, met een TTL van één uur. Als de snapshot faalt, gebeurt de actie niet. Het ticket escaleert naar een mens met de diagnose erbij.

// snapshot-gate.js
// Refuses any action the agent cannot atomically undo.

async function gateAction(action, ctx) {
  if (!action.mutates_state) {
    return { allow: true, snapshot: null }
  }

  const snap = await directadmin.snapshot({
    domain: ctx.domain,
    scope: action.scope, // 'zone' | 'mailbox' | 'site' | 'db'
  })

  if (!snap.ok) {
    return {
      allow: false,
      reason: `no_snapshot: ${snap.error}`,
      escalate_to: 'human',
    }
  }

  await audit.write({
    ticket: ctx.ticket_id,
    action: action.name,
    snapshot_id: snap.id,
    ttl_minutes: 60,
  })

  return { allow: true, snapshot: snap.id }
}

De escalatie-routing zelf is een kleine Claude-aanroep die de diagnose, de voorgestelde actie en het abonnement van de klant leest, en dan beslist of dit naar tier-1 review, tier-2 of meteen naar de dienstdoende engineer gaat. Het model is niet het ding dat tickets sluit. Het model is het ding dat beslist welke mens er níét naar hoeft te kijken.

Hoe die 62% is opgebouwd

De kop is "62% van tier-1 gesloten in onder vier minuten". Dat getal klopt, maar het is saai zonder de vorm.

• E-mailbezorging: ongeveer vier op vijf lost zichzelf op. Bijna allemaal ontbrekende SPF-includes na een nieuwe mailprovider, of een DKIM-selector mismatch. Beide zijn mechanisch te diagnosticeren vanuit de read-only mirror.
• "Site is down": iets meer dan de helft lost zichzelf op. PHP-versie bumps, SSL-vernieuwingen die stil faalden, en één specifieke WordPress-plugin die alle beschikbare PHP-FPM workers opvreet.
• Mailbox-issues: drie op vier lost zichzelf op. Quotaverhogingen binnen het abonnement, wachtwoord-resets na identiteitsverificatie via WHMCS.
• Database-limits: slechts ongeveer een op vijf lost zichzelf op. De meeste hiervan vragen om een mens, omdat de fix "je code lekt" is, en de agent mag niet degene zijn die een klant vertelt dat hun developer een fout heeft gemaakt.

De 38% die de agent niet sluit valt in twee categorieën. Tickets waar de diagnose duidelijk is maar de fix een menselijke handtekening vraagt (een primaire mailbox hernoemen, een database herstellen, alles wat facturatie raakt). En tickets waar het vertrouwen van de agent onder een bewust hoog gezette drempel zit.

De escalation gate in de praktijk

De gate is het stuk van het systeem dat het langst duurde om goed te krijgen. De eerste versie was een confidence score. Die hebben we na drie weken weggegooid, omdat confidence scores die getraind zijn op oude tickets niet voorspellen op welke manier een nieuw ticket precies breekt.

De versie die we hebben uitgerold gebruikt drie checks, in deze volgorde:

1. Kun je dit snapshotten? Zo nee, escaleren. Geen uitzonderingen.
2. Staat de actie op de allowlist voor het abonnement van deze klant? Abonnementen hebben verschillende blast radii. De agent van een klant van €9 per maand mag MariaDB niet herstarten. De agent van een klant van €290 per maand wel, na snapshot.
3. Heeft een mens deze actieklasse de afgelopen 90 dagen goedgekeurd voor deze klant? Zo ja, dan handelt de agent en plaatst hij de reply. Zo nee, dan bereidt de agent de reply en de actie voor, en vraagt hij één keer een mens om akkoord. Daarna is deze actieklasse 90 dagen lang pre-approved voor die klant.

Die derde check is degene die de support lead na week twee heeft gevraagd. Haar instinct klopte. De meeste frictie zat niet in "kan de agent dit", maar in "heeft deze klant ingestemd met dat de agent dit doet". Toestemming behandelen als iets per klant, per actieklasse, met een tijdvak, maakte de agent minder een indringer en meer een junior die de voorkeuren van elke klant leerde.

Wat er stukging

Twee dingen, allebei waard om eerlijk te vertellen.

De eerste ging stuk in week vier. De mail van een klant routeerde al twee jaar via een third-party filter. De agent diagnosticeerde een "ontbrekend MX-record" en stelde voor om de DirectAdmin-default toe te voegen. De snapshot heeft ons gered. De rollback was schoon. Maar de agent had vol vertrouwen ongelijk, en die ongelijkheid zag er in het ticket precies zo uit als wanneer hij wél gelijk had. We hebben dit opgelost door een check toe te voegen voor elke third-party MX, SPF-include of DKIM-selector ouder dan 30 dagen, en die standaard als "human only" te markeren. De agent schrijft nu een paragraaf met wat hij ziet en vraagt een mens om de bedoeling te bevestigen.

De tweede ging stuk in week zeven en was grappiger. De WordPress-site van een klant was gehackt. Op de vraag "waarom is mijn site traag" identificeerde de agent terecht abnormaal hoog PHP-FPM worker-gebruik, stelde voor de worker count omhoog te gooien en maakte een snapshot van de config. Hij had geen ongelijk over die worker count. Hij had ongelijk over de vraag. De site was traag omdat hij op de achtergrond cryptocurrency aan het minen was. We hebben een set patroon-checks toegevoegd (procesnamen die er niet thuishoren, uitgaande verbindingen naar bekende mining pools, file-modification spikes in wp-content/uploads) die altijd escaleren, ongeacht hoe mechanisch het oppervlaktesymptoom eruitziet.

Waarom de snapshot-regel meer telt dan het model

Er loopt deze maand een Duitse rechterlijke uitspraak door het nieuws over de vraag of Google aansprakelijk is voor verkeerde antwoorden in zijn AI Overviews. De details worden de komende jaren uitgevochten. De algemene richting is wat elk hostingbedrijf nu al zou moeten aannemen. Als jouw platform de vraag van een klant beantwoordt, is het antwoord van jou. "De AI zei het" is geen verdediging, en wordt dat ook niet.

De snapshot gate is hoe je dat overleefbaar maakt. Niet omdat de agent nooit ongelijk zal hebben (dat zal hij), maar omdat alles wat hij verkeerd doet aan een server in 60 seconden teruggedraaid kan worden door een junior in de dienst. Het model is vervangbaar. De omkeerbaarheid is de moat.

Dit is ook het stuk dat hostingteams in onze ervaring genoeg op hun gemak stelt om überhaupt een agent neer te zetten. De support lead van de Haarlemmer vertelde ons in de kickoff dat haar werkelijke bezwaar tegen chat agents niet was dat ze dom zouden zijn. Het was dat ze dom zouden zijn op manieren waar zij vervolgens drie uur mee bezig was om op te ruimen. De gate heeft dat van tafel gehaald.

Wat dit verandert, en wat niet

De Haarlemmer heeft niemand ontslagen. Dat waren ze ook niet van plan. Hun tier-1 wachtrij at vroeger ongeveer 18 engineer-uren per week. Nu eet hij er ongeveer zeven. Die elf uur zijn naar een project gegaan waar ze al twee jaar mee wilden beginnen: hun oudste klanten migreren van een PHP 7.4 cluster naar een actuele build. Dat is wat de agent ze opgeleverd heeft. Geen kleiner team. Een team dat werk doet waar ze nooit mensen voor konden vrijmaken.

De framing telt. Er loopt nu een populair argument dat CEO's die denken dat AI hun medewerkers vervangt, degenen zijn die nooit hebben begrepen wat die medewerkers eigenlijk deden. Daar zijn we het mee eens. De tier-1 engineers van de reseller waren nooit de bottleneck. De wachtrij was dat. Het weghalen van de wachtrij maakte de engineers waardevoller, niet minder.

Wil je dit zelf proberen als hostingbedrijf

Voordat je iets bouwt, doe één audit. Pak je laatste 200 tier-1 tickets erbij. Schrijf voor elk op of de diagnose mechanisch was, of de fix mechanisch was, en of er voor die fix gesnapshot had kunnen worden. De tickets waar alle drie ja is, zijn je startende allowlist. De rest is voorlopig nog mensenwerk.

Toen we de chat agent bouwden voor de Haarlemmer, liepen we steeds tegen het feit aan dat "tier-1" een wachtrij-label was geweest, geen omschrijving van het werk. We hebben het opgelost door de wachtrij op te splitsen in "mechanisch omkeerbaar" en "de rest" voordat de AI-agent ook maar één ticket te zien kreeg. Die splitsing is de audit die je vandaag kunt doen, voordat er ook maar één regel code geschreven wordt.