WhatsApp-agent voor leadkwalificatie: 11 dagen, 12 vestigingen

Twaalf vestigingen, één inbox, één weekend

Het is maandagochtend bij een regionale rijschool in Nederland. Twaalf vestigingen verspreid over drie provincies, twaalf managers en één operations lead die de WhatsApp-inbox probeert bij te benen. Op dinsdagmiddag zijn de leads van het weekend al koud. Een ouder vroeg op zaterdag naar rijlessen voor zijn zeventienjarige zoon, kreeg geen reactie en boekte zondagavond bij een concurrent.

De eigenaar verwoordde het anders: "We verliezen de mensen die ons in het weekend appen. Tegen de tijd dat iemand het bericht maandag leest, hebben ze elders al een aanbetaling gedaan."

De opdracht: leads kwalificeren op WhatsApp voordat een mens ze aanraakt, de gekwalificeerde leads doorsturen naar de juiste vestiging, en het binnen twee weken doen omdat de zomerdrukte over elf dagen begon. We waren op dag elf klaar.

Eén nummer per vestiging, niet één nummer in totaal

De eerste ontwerpverleiding is de verkeerde: één WhatsApp-nummer dat vooraf vraagt "welke vestiging?". We hebben die flow een middag op papier getest en weer weggegooid. Drie redenen.

Ten eerste adverteren de vestigingen hun eigen lokale nummers al op flyers, Google Bedrijfsprofielen en de deuren. Ze vervangen door één landelijk nummer betekent twaalf sets marketingmateriaal opnieuw drukken en herregistreren. Daar zit niemand op te wachten.

Ten tweede converteren lokale nummers beter. Een ouder in Zwolle die een Zwols nummer appt, vertrouwt het antwoord meer dan dezelfde ouder die een 088-servicenummer appt. We hadden geen harde data voor de rijschoolsector, maar de operations lead geloofde er sterk genoeg in om er een randvoorwaarde van te maken.

Ten derde wilden de vestigingsmanagers zicht houden op hun eigen pipeline. Eén inbox per vestiging, één wachtrij per vestiging, één set cijfers per vestiging. Een centrale pool had een kleine burgeroorlog veroorzaakt.

Dus: twaalf Twilio-WhatsApp-senders, één per vestiging. Dezelfde agentcode achter alle nummers, vestigingsidentiteit als context meegegeven bij elke webhook.

Twaalf senders provisionen zonder elf dagen te verliezen

Het trage stuk van elke WhatsApp Business-bouw is niet de code. Het is de sender-goedkeuring. Elk WhatsApp Business-nummer heeft een door Meta goedgekeurde display name nodig, door Meta goedgekeurde message templates en een Twilio-sender-registratie die alles aan elkaar koppelt. De WhatsApp-documentatie van Twilio is eerlijk over de doorlooptijd: ga uit van twee tot vijf werkdagen per sender, soms langer als je display name niet overeenkomt met je geverifieerde bedrijfsnaam in Facebook Business Manager.

We gingen geen vijftig dagen wachten op twaalf senders achter elkaar. We hebben drie dingen gedaan om dat venster in te korten:

• Op dag één alle twaalf display-name-aanvragen ingediend, voordat er één regel code bestond. Het product kan wachten. Meta laat zich niet opjagen.
• Eén overkoepelende business vooraf geregistreerd in Facebook Business Manager die alle twaalf vestigingsprofielen bezat. Goedkeuringen liepen daardoor parallel in plaats van als twaalf losse verificatieketens.
• De vier message templates waarvan we wisten dat we ze nodig hadden (eerste contact, herinnering bij gemist venster, overdracht naar vestiging, lesbevestiging) op dag twee opgesteld en ingediend. Templates hebben hun eigen goedkeuringscyclus. Ze parallel laten lopen met het codewerk scheelde ons een week.

Op dag zes waren tien van de twaalf senders live. De laatste twee kwamen op dag negen door. Twee vestigingen draaiden op dag negen en tien proef, de rest ging op dag elf live.

De kwalificatieflow die we hebben opgeleverd

Een rijlesboeking heeft meer variabelen dan mensen denken. Alleen al de Nederlandse rijbewijscategorieën zijn er ruim tien. De meeste leads voor een rijschool zitten in drie: B (personenauto), AM (brommer) en A (motor, met subcategorieën A1 en A2). De kwalificatieflow moest de categorie, de leeftijd van de leerling, de gewenste vestiging, het gewenste startmoment en of de lead de leerling zelf was of een betalende ouder, allemaal vaststellen.

We hebben geen reuzeprompt geschreven en gehoopt op het beste. De flow is een state machine met vijf expliciete states, en de agent mag pas door naar de volgende state als de slot die hij nodig heeft, ingevuld is.

// Simplified excerpt from the per-branch handler
type QualState =
  | "greet"
  | "category"      // B, AM, A, A1, A2
  | "age_window"    // 16, 16.5, 17, 17.5, 18+
  | "start_window"  // "this month", "summer", "after exam X"
  | "handoff"

type Lead = {
  branchId: string
  whatsappFrom: string
  state: QualState
  category?: "B" | "AM" | "A" | "A1" | "A2"
  ageMonths?: number
  startWindow?: string
  isParent?: boolean
  notes: string[]
}

async function step(lead: Lead, incoming: string): Promise<Reply> {
  switch (lead.state) {
    case "greet":
      return ask(lead, "category",
        "Hi! Welk rijbewijs wil je halen? B (auto), AM (brommer), of A (motor)?")
    case "category": {
      const cat = parseCategory(incoming)
      if (!cat) return clarify(lead, "Bedoel je B, AM, of A?")
      lead.category = cat
      return ask(lead, "age_window", ageQuestion(cat))
    }
    // ... etc
  }
}

Het taalmodel schrijft de vrije stukken: de toon van de begroeting, de verduidelijkingen bij ambigue input, de samenvatting aan het einde van het gesprek. De slot-filling-logica is gewone code. Die splitsing is de belangrijkste architectuurkeuze in de bouw, en het is de reden dat de agent geen lesprijzen verzint en geen vestigingsadressen uit zijn duim zuigt.

Wat de agent mag zeggen

Containment is het stuk dat mensen overslaan en waar ze later spijt van krijgen. Anthropic publiceerde dit jaar een nuttig stuk over de manieren waarop ze Claude inkaderen in hun producten, en het onderliggende punt geldt voor iedereen die een agent in een klantgericht kanaal zet: het model is de motor, niet het beleid. Het beleid leeft buiten het model.

Voor deze bouw betekende containment vier dingen:

• Geen prijzen noemen. De agent noemt nooit een prijs per les. Prijzen verschillen per vestiging en per pakket, en een verkeerd bedrag op WhatsApp wordt een klacht aan de balie. De agent zegt "je vestiging bevestigt de exacte prijs als ze je terugbellen" en gaat door.
• Niet inplannen. De agent belooft geen tijdslot. Hij belooft een terugbelvenster. De bestaande planner van de vestiging regelt de echte slots, en we wilden niet in twee systemen tegelijk schrijven.
• Geen medisch of juridisch advies. Rijscholen krijgen verrassend veel vragen van leerlingen met ADHD, dyslexie of angststoornissen of ze nog wel een rijbewijs kunnen halen. De instructie van de agent is: erken de vraag, leg hem vast als notitie en stuur door naar een mens. Daar is een echt juridisch kader voor in Nederland (de Eigen Verklaring van het CBR) en we willen niet dat een taalmodel dat parafraseert.
• Niet off-topic. De agent beantwoordt vragen over rijles. Als het gesprek afdwaalt (en dat doet het regelmatig, richting "kun je mijn zoon ook bijles geven voor zijn theorie?"), legt de agent de vraag vast en draagt over.

Alle vier worden afgedwongen in code rondom de modelcall, niet in de prompt. Een promptinstructie als "noem nooit prijzen" is een suggestie. Een post-processing-check die elk euroteken in het conceptantwoord markeert en herschrijft naar "[je vestiging bevestigt dit]" is een garantie.

De tijdlijn van elf dagen

Zo zag de kalender er werkelijk uit. Klanten vragen altijd hoe we een bouw als deze in twee weken proppen, en het antwoord is: door eerlijk te zijn over wat op mensen wacht en wat op code wacht.

• Dag 1. Discoverygesprek met de operations lead en twee vestigingsmanagers. Huidige intake in kaart gebracht. Twaalf display-name-aanvragen bij Meta ingediend.
• Dag 2. Vier message templates opgesteld en ingediend. State machine op papier uitgewerkt.
• Dag 3. Twilio-webhook-handler en state machine in TypeScript gebouwd op één Cloudflare Worker. Vestigingsrouting gestubd.
• Dag 4. Vestigingsmetadata (adres, naam manager, openingstijden) als statische config per vestiging bedraad. Geen CMS, geen database hiervoor. Twaalf YAML-blokken in de repo.
• Dag 5. De overdracht-e-mail en het simpele dashboard per vestiging gebouwd waarmee managers nieuwe leads zien.
• Dag 6. Tien van de twaalf senders goedgekeurd door Meta. Begonnen met end-to-end-testen op een sandboxnummer.
• Dag 7. Flow doorlopen met de operations lead. Ze herschreef drie begroetingen van de agent in helderder Nederlands. We hebben haar bewoording gehouden.
• Dag 8. Laatste twee senders goedgekeurd. Het template-bericht gebouwd voor leads die meer dan vier uur stil blijven.
• Dag 9. Proef gestart bij twee vestigingen (Zwolle en Apeldoorn). 23 gesprekken in de eerste middag. Twee bugs gevonden, allebei dezelfde dag gefikst.
• Dag 10. Proef draaide een tweede dag. Geen nieuwe bugs. Operations lead gaf groen licht voor volledige uitrol.
• Dag 11. De resterende tien vestigingen gingen live, één nummer tegelijk, met per vestiging een manager standby.

De krappe tijdlijn werkte alleen omdat we het mens-blokkerende werk (Meta-goedkeuringen) parallel lieten lopen met het codewerk, en omdat we vroeg ontwerprestricties hebben gemaakt die anders in week twee een discussie waren geworden. Eén nummer per vestiging. Geen prijzen noemen. Niet inplannen. Elk van die beslissingen scheelde ons een meeting in week twee.

Hoe de eerste twee weken eruitzagen

We hebben vier dingen gemeten in de eerste twee weken na livegang. We publiceren het absolute lead-volume niet omdat de klant dat niet wilde, maar de verhoudingen zijn nuttig.

• De mediaan tijd tot eerste reactie ging van "volgende werkdag" naar onder de dertig seconden. Dit was het headlinecijfer voor de eigenaar.
• Aandeel gekwalificeerde leads (leads waarbij categorie, leeftijdsvenster, vestiging en startmoment allemaal vastlagen voordat een mens het gesprek las) was 71% in week één en 78% in week twee. De rest had ergens in de flow een menselijk duwtje nodig, meestal omdat de leerling een off-topic-vraag stelde die de agent correct doorzette.
• Weekendconversie (leads die tussen vrijdagavond en zondagnacht appten en binnen zeven dagen een betaalde intake boekten) verdubbelde ongeveer ten opzichte van de baseline van de maand ervoor. We hebben dit nog geen volledig kwartaal gemeten, dus zie het als een richtingsignaal, geen garantie.
• Tevredenheid van managers is moeilijk schoon te meten. De notitie van de operations lead in week twee: "Ik heb mijn zaterdagochtendwekker verwijderd." Dat noemen we een sterk signaal.

Wat we anders zouden doen

Twee dingen.

Ten eerste hebben we het volume aan voice-notes onderschat. Ongeveer 14% van de inkomende WhatsApp-berichten in de eerste week was audio. Onze v1-agent kon ze niet aan en vroeg de afzender beleefd om te typen. Dat is op zich prima, maar het is frictie. v1.1 voegde voice-note-transcriptie toe voordat de state machine de tekst ziet. Dat hadden we op dag één moeten opleveren.

Ten tweede hadden we het dashboard per vestiging vanaf het begin met sorteerbare kolommen moeten bouwen in plaats van als een platte lijst. Vestigingsmanagers op de drukkere locaties vroegen er op dag twaalf om.

Geen van beide had de elf-dagen-tijdlijn veranderd. Allebei hadden ze week twee rustiger gemaakt.

Kijk je naar een vergelijkbare bouw bij je eigen bedrijf, dan is het kleinste wat je vandaag kunt doen: een sandbox-account openen op de WhatsApp-playground van Twilio en een state-machine-flow op papier schetsen. Het agentontwerp is het makkelijke deel. Provisioning en goedkeuringsflows bepalen of de kalender wel of niet haalbaar is.

Toen we deze WhatsApp-agent bouwden voor de rijschoolketen, was wat ons bijna de deadline kostte één mismatchende display name in Facebook Business Manager, die we oplosten door alle twaalf display names op dag één in te dienen met identieke schrijfwijze van de juridische entiteit, zodat een eventuele afwijzing meteen tegen alle twaalf tegelijk zou opduiken. Hetzelfde patroon (state machine in code, taal in het model, goedkeuringen parallel aan de bouw) is hoe we de meeste van onze AI-agents opleveren.