Aanvraag komt bij de verkeerde vestiging terecht

Routeringsfouten hebben meestal één van vier oorzaken. Zoek eerst uit welke bij jou speelt, want de oplossing verschilt.

1. Regel klopt niet: de postcode staat in de verkeerde vestigingslijst.
2. Gegeven klopt niet: de klant typte een foute of onvolledige postcode, of koos de verkeerde locatie in een keuzelijst.
3. Regel ontbreekt: de postcode valt buiten alle lijsten en komt in een standaardbak terecht.
4. Overdracht klopt niet: het formulier stuurt correct door, maar de mailbox, het CRM of de agenda van een vestiging ontvangt het niet of leest het verkeerd.

Haal uit je inbox of CRM tien recente aanvragen die verkeerd uitkwamen. Noteer per aanvraag wat de klant invulde, waar het terechtkwam en waar het hoorde. Je zoekt een patroon, bijvoorbeeld steeds dezelfde postcode of steeds dezelfde keuzeoptie. Zonder dit patroon test je blind.

Vraag aan wie het formulier beheert een export of overzicht van de huidige regels: welke postcodes of gemeenten horen bij welke vestiging, en wat gebeurt er bij geen match. Bestaat dat overzicht niet, dan ontdek je meteen het eerste probleem: de regels leven alleen in iemands hoofd of in de formuliertool.

Maak daarna een tabel met vier kolommen: invoer, verwachte vestiging, werkelijke vestiging, tijdstip van de test. Neem minstens deze rijen op:

• één postcode per vestiging, midden in het werkgebied;
• de randpostcodes van elk werkgebied;
• een postcode die in geen enkele lijst staat;
• een postcode met een typfout of een spatie;
• een leeg veld, als het veld niet verplicht is.

Verstuur elke rij bij voorkeur via een testomgeving of testmodus van het formulier. Bestaat die niet, spreek dan vooraf met alle vestigingen een tijdslot af en gebruik een herkenbare testnaam en een uniek testnummer, zodat je team de aanvraag kan negeren of verwijderen en er geen automatische opvolging naar echte klanten vertrekt. Een test op papier bewijst de regel, niet de keten tot in de mailbox.

Een Belgische postcode volgt niet altijd netjes één werkgebied. Eén gemeente kan meerdere postcodes hebben, en binnen één postcode kunnen deelgemeenten verschillen in welke vestiging dichterbij ligt. Controleer in jouw regels of dit bij jou voorkomt. Leg dan per grensgeval vooraf een beslissing vast, anders beslist elke medewerker anders.

Bruikbare beslisregels:

• Postcode in twee werkgebieden: vraag in het formulier ook de gemeente of straat, of kies één vaste vestiging en documenteer waarom.
• Postcode onbekend: stuur naar een benoemde eigenaar, niet naar een algemene bak die niemand leest.
• Klant kiest zelf een locatie die niet past bij de postcode: volg de keuze van de klant, tenzij je dienst echt aan het adres gebonden is. Dan toon je een melding.
• Aanvraag buiten alle werkgebieden: geef een duidelijk antwoord aan de klant in plaats van stilte.

Schrijf deze regels op één pagina en geef aan wie de uitzonderingen mag wijzigen.

Een deel van de verkeerde routering begint bij de invoer. Controleer drie punten, met de volgende bronnen als achtergrond.

Eerst de validatie. Volgens de uitleg over validatie van MDN vangt validatie in de browser fouten snel op, maar is ze niet voldoende als beveiliging, en moet de server de gegevens ook controleren. Voor jou betekent dit: test of een foute postcode al in het formulier wordt gemeld, en of de server een ongeldige waarde niet stilzwijgend naar een standaardvestiging stuurt.

Dan de begeleiding. De formuliertutorial van W3C raadt aan om elk veld te labelen, instructies te geven en bij fouten duidelijk te melden wat te corrigeren. Staat bij het postcodeveld wat je verwacht, bijvoorbeeld vier cijfers, dan daalt de kans op foute invoer. Of het bij jou veel verschil maakt, controleer je in je eigen testtabel.

Tot slot de omgeving. De cursus over formulieren van web.dev bevat onderdelen over testen op verschillende toestellen en browsers. Test dus minstens één keer op mobiel en in een tweede browser. Of een keuzelijst of automatisch invullen daar anders werkt, is een eigen controle: kijk of automatisch invullen een oude postcode in het veld zet.

Een fictief voorbeeld, enkel om de werkwijze te tonen. Een bedrijf heeft twee vestigingen, A en B. De regel zegt dat postcode X naar A hoort en postcode Y naar B. Een derde postcode Z ligt tussen beide en staat in geen lijst.

Voor de overdracht zelf: laat in elke doorgestuurde aanvraag zichtbaar staan welke postcode of locatie de klant invulde en welke regel is toegepast. Dan kan een vestiging een foutieve routering doorgeven in plaats van ze zelf te herroepen of te negeren.

Herhaal de volledige testtabel telkens als je iets wijzigt aan het formulier, de regels, de tool of de ontvangende mailboxen. Een kleine aanpassing in één veldnaam kan de routering breken zonder dat je het ziet.

1. Voer de tabel opnieuw uit in de testomgeving of met duidelijk gemarkeerde testverzendingen.
2. Vergelijk verwachte en werkelijke vestiging en noteer elk verschil.
3. Vraag elke vestiging te bevestigen dat de testaanvragen aankwamen, met volledige velden.
4. Kijk na enkele weken opnieuw naar echte aanvragen die verkeerd uitkwamen en pas je tabel aan op nieuwe patronen.

Belangrijk: deze procedure toont of jouw regels doen wat je bedoelde. Ze garandeert geen foutloze routering voor elke toekomstige invoer.

Wil je ook weten welke publieke signalen je website uitstuurt, zoals hoe contact- en vestigingsinformatie zichtbaar is? Bekijk ze via Marketing Scan. Een publieke scan meet zichtbare signalen en bewijst niet hoe je routering intern werkt.