Twee collega's bellen dezelfde lead: voorkom overlap

Overlap heeft meestal één van vier oorzaken. Ga ze na op de laatste tien leads waar dubbel contact was:

1. De lead is zichtbaar voor meerdere mensen, maar niemand ziet wie hem al oppakte.
2. Er is wel een eigenaar, maar de status wordt pas na het gesprek aangepast.
3. Dezelfde persoon dient twee keer een formulier in en krijgt twee aparte leads.
4. Een lead wordt doorgegeven in een chat of mail, buiten het systeem.

Noteer per geval welke oorzaak speelde. Die telling is jouw eigen diagnose; ze zegt niets over andere bedrijven. Pas het proces aan op de oorzaak die het meest voorkomt, niet op alle vier tegelijk.

Een claim betekent: één persoon is verantwoordelijk, en iedereen ziet dat. Gebruik wat je al hebt, zoals een eigenaarveld in je crm, een kolom in een gedeeld blad of een label in je mailbox. Vereis minstens drie gegevens: wie claimt, wanneer, en de huidige status.

Spreek af dat claimen gebeurt vóór het eerste contact, niet erna. Houd statussen beperkt: 'nieuw', 'geclaimd', 'contact gelegd', 'vrijgegeven', 'afgesloten'. Meer statussen worden zelden consequent bijgehouden.

Spreek ook af wat een claim waard is: wie claimt, belt binnen een door jullie bepaalde termijn of geeft de lead vrij. Welke termijn dat is, hangt af van je sector en bezetting; er bestaat geen universeel getal.

Een deel van het probleem begint in het webformulier. Het W3C raadt aan enkel te vragen wat nodig is voor de transactie, omdat overbodige of excessieve gegevens de kans op afhaken vergroten (https://www.w3.org/WAI/tutorials/forms/). Voor opvolging zijn meestal nodig: naam, een betrouwbare contactvorm en de vraag zelf. Voeg een veld toe zoals 'voorkeur: bellen of mailen', zodat het team niet allebei probeert.

Valideer dat het telefoonnummer en e-mailadres een geldig formaat hebben. MDN beschrijft dat validatie in de browser de gebruiker meteen laat corrigeren, maar dat je gegevens ook server-side moet controleren, omdat clientcontrole gemakkelijk te omzeilen is (https://developer.mozilla.org/en-US/docs/Learn_web_development/Extensions/Forms/Form_validation). Een fout nummer leidt tot meerdere belpogingen door meerdere mensen.

De terugkoppeling is de tweede helft van de regel: na elk contactmoment noteert de eigenaar één zin met uitkomst en vervolgstap.

Fictief voorbeeld, enkel invoer en te controleren punten. Maandag 9u00 komen twee formulieren binnen met hetzelfde e-mailadres, het eerste met telefoonnummer, het tweede zonder. Collega A en collega B zien de lijst. Jullie afspraak: claimtermijn twee werkuren (jouw team bepaalt dit zelf).

1. A zet zich als eigenaar op de eerste lead en wijzigt de status naar 'geclaimd'.
2. B ziet het eigenaarveld en belt niet.
3. De tweede lead is een duplicaat; wie het opmerkt, voegt beide samen en behoudt A als eigenaar.
4. A belt, noteert 'contact gelegd' en één zin over de vervolgstap.
5. Lukt het niet binnen de termijn, zet A de status op 'vrijgegeven', zodat B kan claimen.

Je controleert hier alleen: is er op elk moment één zichtbare eigenaar, en is het vrijgavemoment vastgelegd in het systeem?

Geef het nieuwe proces een proefperiode die je zelf bepaalt. Haal daarna de leads op met meer dan één contact en vergelijk met je oorspronkelijke telling van tien. Controleer vier punten: heeft elke lead een eigenaar, is de claim aangemaakt vóór het eerste contactmoment, staan vrijgegeven leads daadwerkelijk opnieuw geclaimd, en zijn duplicaten samengevoegd?

Test ook je formulier zelf: dien een testlead in met een ongeldig telefoonnummer en kijk of de fout duidelijk wordt gemeld. Controleer of het formulier labels heeft bij elk veld. Het W3C beschrijft dat je het label-element gebruikt om elk formulierbesturingselement te identificeren (in specifieke gevallen kunnen andere mechanismen volstaan), en dat helpt ook voor toegankelijkheid. Deze controle bewijst geen volledige WCAG-conformiteit. Of overlap daardoor afneemt, blijkt enkel uit je eigen cijfers.

Wil je weten welke publieke signalen je site rond contactformulieren nu toont, bekijk ze dan via Marketing Scan. Onze publieke scan ziet wat zichtbaar is en kent je interne claimproces niet.