Een klant wil teruggebeld worden op een specifiek uur

Een terugbelverzoek mislukt zelden door onwil. Het gaat mis op overdrachtsmomenten: het uur staat in een vrij tekstveld dat niemand leest, het verzoek belandt in een algemene mailbox, of twee collega's denken allebei dat de ander belt. Een tijdvak zonder eigenaar is geen afspraak maar een wens.

Maak daarom onderscheid tussen drie zaken: wat de klant vraagt (een uur), wat jij kunt waarmaken (een haalbaar tijdvak) en wie dat uitvoert (een naam). Pas als die drie samenvallen en de klant dat weet, bestaat er een belofte. Alles daarvoor is een verzoek in behandeling.

Beperking: dit artikel beschrijft een werkproces, geen wettelijke regels over bereikbaarheid of gegevensverwerking. Vraag je telefoonnummer en voorkeursuur alleen uit als je ze echt gebruikt, en raadpleeg bij twijfel over privacy een deskundige.

Een goed formulier maakt het gewenste uur duidelijk en controleerbaar. De cursus Forms van web.dev behandelt onder meer hoe je gebruikers helpt de juiste gegevens in te voeren en hoe je formulieren test. Gebruik die basis als startpunt voor je eigen controle. De keuze voor tijdvakken of een tijdveld is een redactioneel voorstel van dit artikel, geen eis uit die bron.

1. Vraag het voorkeursuur in een apart, duidelijk benoemd veld, niet in een vrij opmerkingenveld. Gebruik een keuzelijst met tijdvakken of een tijdveld, zodat de waarde eenduidig is.
2. Laat bij het veld zien binnen welke uren je daadwerkelijk kunt bellen, zodat de klant geen onmogelijk uur kiest.
3. Vraag een telefoonnummer in een veld dat als telefoonnummer is bedoeld, en controleer of het in een bruikbaar formaat binnenkomt.

Toon bij het verzenden een bevestiging die het gekozen uur herhaalt. Zo ziet de klant meteen wat is genoteerd en kan hij een vergissing corrigeren voordat de belofte ontstaat.

Een terugbelformulier moet ook bruikbaar zijn voor wie een schermlezer of spraakbesturing gebruikt. De toegankelijkheidstutorial voor formulieren van het W3C noemt onder meer het labelen van velden, het groeperen van samenhangende velden, formulierinstructies, het valideren van invoer en meldingen over gelukte taken en fouten. Het volgen ervan bewijst geen volledige WCAG-conformiteit. Pas dat toe: elk veld krijgt een zichtbaar label, en het uur en het nummer zijn als aparte velden benoemd.

Voor controle van de invoer kun je de browser een eerste check laten doen. De uitleg over formuliervalidatie aan de clientzijde van MDN beschrijft dat dit een eerste controle is die de gebruiker meteen laat corrigeren, maar niet volstaat als beveiliging. Valideer daarom ook aan de serverzijde en vertrouw niet blind op wat de browser doorstuurt.

Controleer verder dat een foutmelding zegt wat er mis is en hoe het te herstellen valt, bijvoorbeeld 'Kies een uur tussen 9 en 17 uur'. Een melding als 'ongeldige invoer' helpt niemand.

Gebruik deze checklist per terugbelverzoek. Pas ze aan je team en tools aan; de volgorde is een voorstel.

• Ontvangen: verzoek heeft naam, telefoonnummer, voorkeursuur en onderwerp.
• Haalbaar: het gevraagde uur valt binnen je bereikbare tijden, of er is een alternatief voorgesteld.
• Eigenaar: één persoon is benoemd om te bellen, met naam in het dossier.
• Bevestigd: de klant kreeg een bericht met het afgesproken uur en wie belt.
• Afwijking: kan de eigenaar het uur niet halen, dan staat vast wie overneemt of wanneer opnieuw gebeld wordt, en de klant is vooraf verwittigd.
• Afgerond: de poging staat genoteerd, ook als de klant niet opnam, met het volgende contactmoment.

Het belangrijkste is het verschil tussen een belofte die je kunt waarmaken en een die je gewoon aanvaardt omdat de klant ze vroeg. Bevestig alleen wat haalbaar is, en meld een afwijking vóór het uur verstrijkt, niet erna.

Na aanpassing van formulier of werkwijze test je het hele pad, van invoer tot belmoment. Vooraf kun je niets beloven over conversie of antwoordpercentages; je kunt wel nagaan of de overdracht technisch en organisatorisch klopt.

Fictief voorbeeld. Invoer: een testverzoek met voorkeursuur 14 uur, een telefoonnummer en het onderwerp 'offerte'. Verwachte controles: het uur komt als aparte waarde binnen in het bericht aan het team; er is een bevestiging naar de klant met het uur; één persoon is als eigenaar benoemd; en een tweede testverzoek met een uur buiten de bereikbare tijden toont een duidelijke melding met een alternatief. Er worden hier bewust geen aantallen of resultaten verzonnen.

1. Verzend in een veilige testomgeving een testverzoek binnen de bereikbare tijden, met fictieve gegevens en een unieke herkenbare testtekst (bijvoorbeeld een verzonnen referentie), en volg het naar de eigenaar. Gebruik geen echte persoonsgegevens.
2. Verzend hetzelfde testverzoek twee keer, of herlaad na een foutmelding of timeout, en controleer of er één of twee verzoeken in het systeem staan. Een fout kan optreden nadat het verzoek al is opgeslagen, dus een bevestigingsscherm of foutmelding bewijst het niet; kijk in het ontvangende systeem.
3. Verzend een testverzoek buiten die tijden en controleer de foutmelding en het voorgestelde alternatief.
4. Test het formulier met alleen toetsenbord en met een schermlezer.
5. Controleer dat een serverzijdige fout (leeg uur, ongeldig nummer) ook wordt opgevangen.

Wil je de publiek zichtbare signalen van je eigen website bekijken, dan kan dat via Marketing Scan. Een publieke scan meet wat zichtbaar is en bewijst geen volledige technische implementatie, en onze scan voert niet alle controles uit dit artikel uit.