Een installatiebedrijf met vestigingen in Utrecht, Amersfoort, Eindhoven, Tilburg en Zwolle. Op de website staat één adres: info@. Daar komt alles binnen.
Een aanvraag voor onderhoud in Veenendaal. Een vraag over een offerte voor een pand in Best. Een klant uit Kampen die wil weten wanneer de monteur komt. Elke ochtend leest iemand op het hoofdkantoor die mails, bedenkt welke vestiging erover gaat en stuurt ze door. Hoort Veenendaal bij Utrecht of bij Amersfoort? Dat weet de collega die het al jaren doet. Is die er niet, dan gaat de mail naar de verkeerde vestiging, of hij blijft liggen.
Waarom één adres voor alle vestigingen vastloopt
Eén algemeen adres is voor de klant makkelijk. Hij hoeft niet te weten hoe u georganiseerd bent. Maar daardoor komt het uitzoeken bij u te liggen, mail voor mail.
Dat uitzoeken is geen moeilijk werk, wel werk dat nooit ophoudt. En het hangt af van kennis die nergens is opgeschreven: welke plaatsen bij welke vestiging horen, welke uitzonderingen er zijn, en wat er gebeurt met een plaats precies op de grens. Waarom een gedeelde mailbox zonder eigenaar vanzelf dichtslibt, leest u in Waarom info@ altijd dichtslibt.
Dit stuk gaat over verdelen naar plaats: welke vestiging gaat over het adres waar de mail over gaat. Wilt u de mail van een vaste klant bij zijn eigen accountmanager laten uitkomen, dan leest u dat in Nieuwe of bestaande klant?. Beide kunnen samen, en verderop leest u hoe.
Wat de verwerking met elke mail doet
De mailbox wordt elke minuut gecontroleerd. Voor elke nieuwe mail zoekt de verwerking uit waar hij heen moet, voordat iemand hem opent.
Ze leest waar de mail over gaat. Een AI-model haalt vaste velden uit de mail: de postcode en de plaats van het adres waar het om gaat, een vestiging als de klant die zelf noemt, en wat voor soort vraag het is. Het model krijgt de opdracht het adres van het werk of de levering te nemen, niet het adres onder in de handtekening. U bepaalt zelf welke velden het model teruggeeft. Hoe dat werkt, leest u in AI die bruikbare antwoorden geeft, niet alleen mooie.
Ze zoekt de vestiging op in een tabel. Welke vestiging welk gebied doet, staat in een tabel die u zelf bijhoudt. Per regel een postcodereeks, de vestiging, het mailadres van die vestiging en de map in de mailbox. Bijvoorbeeld:
| Postcode van | Postcode tot | Vestiging |
|---|---|---|
| 3400 | 3999 | Utrecht |
| 3800 | 3899 | Amersfoort |
| 5500 | 5699 | Eindhoven |
Overlappen twee reeksen, zoals hierboven, dan bepaalt u welke voorgaat. Daarvoor krijgt elke regel een voorrang, zodat de fijnere reeks voor Amersfoort wint van de brede reeks voor Utrecht. De verwerking zoekt de postcode uit de mail op in die tabel. Dat is een vaste regel, geen inschatting van een taalmodel. Dezelfde postcode geeft altijd dezelfde vestiging.
Ze kiest de route. Noemt de klant zelf een vestiging, dan gaat de mail daarheen. Staat er een postcode in, dan beslist de tabel. Staat er alleen een plaatsnaam, dan kan de tabel ook per plaats een vestiging hebben. Lukt geen van drieën, dan beslist een mens, waarover zo meer.
De mail bij de vestiging
Is de vestiging bekend, dan doet de verwerking drie dingen.
De mail gaat naar de map van de vestiging. In de gedeelde mailbox heeft elke vestiging een eigen map, of bij Gmail een eigen label. De oorspronkelijke mail staat daar, met bijlagen en al. Wie in Amersfoort werkt, opent de map van Amersfoort en ziet alleen wat voor Amersfoort is.
De vestiging krijgt een bericht. Naar het mailadres uit de tabel gaat een kort bericht met wat het model uit de mail haalde: de afzender, de plaats, het soort vraag en de tekst van de klant. Dan weet de vestiging dat er iets ligt, ook als niemand de hele dag in de gedeelde mailbox kijkt.
De klant hoort wie het oppakt. Wilt u dat, dan krijgt de klant in hetzelfde gesprek een korte bevestiging, in een tekst die u zelf schrijft:
Goedemorgen,
Dank voor uw bericht. Uw aanvraag voor onderhoud in Veenendaal ligt bij onze vestiging in Amersfoort. Een collega daar neemt vandaag of morgen contact met u op.
Antwoordt de vestiging vanuit de gedeelde mailbox, op de mail in haar eigen map, dan blijft het antwoord in hetzelfde gesprek met de klant. Mailt de klant daarna terug, dan herkent de verwerking het gesprek en kan ze de nieuwe mail in dezelfde map zetten. Hoe dat herkennen werkt, leest u in "Ja, doe maar": waarom een losse mail niets zegt.
Als niet duidelijk is welke vestiging
Niet elke mail noemt een plaats. "Kunnen jullie een offerte maken voor ons nieuwe pand?" zegt niet waar dat pand staat.
Dan zijn er twee wegen, en u kiest welke u wilt:
- De verwerking vraagt het na. In hetzelfde gesprek vraagt ze de klant om het adres of de postcode. Komt het antwoord, dan loopt de mail alsnog de gewone route. Zo werkt navragen ook bij onvolledige bestellingen; zie Bestelling zonder artikelnummer.
- Een collega kiest met één klik. De mail gaat naar een collega op het hoofdkantoor, met een knop per vestiging. Die klikt "Eindhoven", en de verwerking doet de rest: map, bericht aan de vestiging en eventueel de bevestiging aan de klant. Hoe die stap werkt, leest u in Mail automatiseren zonder de controle kwijt te raken.
Reageert de collega niet binnen de termijn die u instelt, dan blijft de mail in de algemene map staan en kan iemand anders hem oppakken. Hoe u zo'n termijn laat doorschuiven naar een achtervang, leest u in Spoedmail die niemand oppakt.
Samen met uw CRM
Plaats en klant kunnen elkaar tegenspreken. Een vaste klant uit Zwolle vraagt een offerte voor een nieuw filiaal in Tilburg. Welke vestiging gaat dan voor?
Dat bepaalt u, en u legt het één keer vast. Een veelgebruikte keuze: werk op locatie gaat naar de vestiging van die locatie, al het andere naar de vestiging die de klant al kent. Staat in uw CRM bij de klant een vaste vestiging, dan zoekt de verwerking die op via de API, op dezelfde manier als bij Nieuwe of bestaande klant?. Daarna past ze uw regel toe.
Wat er nodig is aan uw kant
Een indeling in gebieden. Welke postcodes of plaatsen bij welke vestiging horen. Vaak bestaat die al in een planning of een spreadsheet. Wij zetten hem in de tabel, en u past hem daar aan als een gebied van vestiging wisselt.
Een map per vestiging. In de gedeelde mailbox, of een label in Gmail. Hebben vestigingen een eigen mailbox, dan kan de verwerking die ook lezen. Komt daar mail binnen voor een andere vestiging, dan krijgt de juiste vestiging een bericht met de tekst van de klant. De mail zelf blijft dan in de mailbox waar hij binnenkwam, want tussen twee losse mailboxen verplaatst de verwerking niets.
Een paar vaste teksten. Voor het bericht aan de vestiging, voor de bevestiging aan de klant en voor het navragen van een adres.
Waar het ophoudt
Bijlagen lezen we niet mee. Staat het adres alleen in een bijgevoegde tekening of pdf, dan ziet de verwerking het niet. De mail gaat dan de route voor een onduidelijke vestiging. De bijlagen zelf blijven bij de oorspronkelijke mail in de map van de vestiging; in het bericht aan de vestiging zitten ze niet.
De tabel weet wat u erin zet. Een nieuwe vestiging of een verschoven gebied moet in de tabel staan voordat de verwerking het kan gebruiken.
Het model kan zich vergissen in het adres. Noemt een klant twee adressen, bijvoorbeeld zijn kantoor en de bouwplaats, dan kan het model de verkeerde kiezen. Geef het daarom een duidelijke opdracht, en laat mail met meer dan één adres langs een collega gaan.
Kortom
Eén info@ is makkelijk voor uw klanten, maar het verdelen over vestigingen kost u elke dag tijd en leunt op kennis in één hoofd. Leg die kennis vast in een tabel. Laat de verwerking de plaats uit de mail halen, de vestiging opzoeken en de mail in de juiste map zetten. Alleen wat niet duidelijk is, komt bij een collega, en die kiest met één klik.