Een contactvoorkeur doorgeven aan je onderaannemer

Een contactvoorkeur is een keuze van de bezoeker: via welk kanaal, op welk moment, met welke taal. Je formulier kan die keuze goed vastleggen, en toch verdwijnt ze onderweg. Dat gebeurt meestal op drie plaatsen: in het formulier zelf (de voorkeur is een vrij tekstveld dat niemand structureel leest), in de export of automatisering (het veld wordt niet meegenomen) en in de opvolging (de onderaannemer gebruikt zijn eigen standaardmethode).

Het doel van deze gids is dus niet meer data delen, maar de juiste data delen. Hoe minder velden je doorstuurt, hoe kleiner het risico en hoe makkelijker de controle. Een verwant uitgangspunt staat in de W3C-tutorial over toegankelijke formulieren (dat gaat over het formulier zelf; de toepassing op doorgeven aan derden is een redactionele keuze) op W3C: toegankelijke formulieren: vraag alleen wat nodig is om het proces af te ronden, want bij overbodige of irrelevante vragen haken gebruikers sneller af. Wat je niet vraagt, hoef je ook niet door te geven.

Maak van de voorkeur een gestructureerd veld in plaats van een vrij tekstvak. Een keuze tussen enkele opties (bijvoorbeeld e-mail, telefoon, beide) is makkelijker door te geven en te controleren dan een zin als 'liefst na de middag bellen, behalve woensdag'. Houd een optioneel opmerkingenveld voor uitzonderingen.

Let op deze punten:

• Geef elk veld een zichtbaar label dat aan het veld gekoppeld is, zodat de keuze ook met een schermlezer of spraakbesturing duidelijk is. De W3C-tutorial noemt het label-element als basismechanisme.
• Groepeer samenhorende keuzes, zoals kanaalopties, met fieldset en legend.
• Leg uit waarvoor de voorkeur dient, met een korte instructie bij het veld.
• Valideer de invoer: als de klant 'telefoon' kiest, moet er een telefoonnummer zijn. Client-side validatie vangt fouten meteen op, maar de MDN-pagina over formuliervalidatie (MDN: formuliervalidatie aan clientzijde) waarschuwt dat die validatie niet volstaat en dat je de data ook aan serverzijde moet controleren.

Een voorkeur die logisch niet kan kloppen met de ingevulde gegevens, bereikt je onderaannemer nooit in bruikbare vorm.

Gebruik dit beslisblad per veld voordat je een overdracht automatiseert. Het is een werkmodel, geen juridisch kader; laat je verwerkingsafspraken zo nodig toetsen door iemand met die expertise.

Twijfel je bij een veld, dan geldt: niet doorgeven tot je kunt uitleggen welke taak van de onderaannemer er zonder stukloopt.

Een voorkeur doorgeven zonder afspraken is een open einde. Leg schriftelijk vast, in een korte overdrachtsnota of in je bestaande overeenkomst, wie wat doet. Controleer minstens:

1. Wie neemt contact op en via welk kanaal? De onderaannemer volgt de gekozen voorkeur en wijkt er niet vanaf.
2. Waarvoor mag hij de gegevens gebruiken? Alleen voor de aanvraag waarvoor de klant ze gaf.
3. Wat gebeurt er als de klant een voorkeur wijzigt of intrekt? Wie krijgt die melding en binnen welke afgesproken termijn?
4. Hoe lang bewaart de onderaannemer de gegevens en wie verwijdert ze na afloop?
5. Wie is aanspreekpunt bij een fout, bijvoorbeeld als iemand ten onrechte gebeld is?

Spreek zelf een termijn af die voor jullie samenwerking werkt; er bestaat geen universele termijn. Het W3C-materiaal over formulieren adviseert gebruikers te informeren over succes en fouten. Als eigen suggestie kun je dat doortrekken naar de overdracht: laat de klant weten dat zijn voorkeur is genoteerd.

Een fictief voorbeeld om de procedure te oefenen. Markeer testaanvragen duidelijk als test en stem vooraf met de installateur af dat hij er niet op reageert, zodat er geen echte afspraak of contact volgt. Een kmo met een offerteformulier werkt samen met een externe installateur. De testaanvraag bevat deze invoer:

• Naam: Test Jansen
• Voorkeurskanaal: e-mail
• E-mailadres: test@example.com
• Telefoonnummer: ingevuld, maar niet als kanaal gekozen
• Voorkeursmoment: voormiddag
• Omschrijving: offerte voor een nieuwe installatie

Verwachte technische controles bij de overdrachtsmail of export naar de installateur:

1. Het veld voorkeurskanaal bevat 'e-mail' en het e-mailadres is aanwezig.
2. Het telefoonnummer wordt niet meegestuurd, omdat het kanaal e-mail is.
3. Het voorkeursmoment staat in de overdracht.
4. Er staat geen klantgeschiedenis of ander veld in dat niet in het beslisblad staat.
5. De klant ziet een bevestiging waarin de voorkeur herhaald wordt.

Doe daarna een tweede test met kanaal 'telefoon' en een leeg nummer. Verwacht dat het formulier de verzending tegenhoudt en een duidelijke foutmelding toont. Er zijn hier bewust geen resultaten of aantallen genoemd: het gaat om invoer en verwachte controles.

Herhaal de testaanvragen telkens je iets wijzigt: een nieuw veld, een andere plug-in, een aangepaste automatisering of een nieuwe onderaannemer. Een korte vaste procedure:

1. Dien testaanvragen in met elke kanaalkeuze, ook met een bewust fout of leeg veld.
2. Vergelijk wat de onderaannemer ontvangt met het beslisblad.
3. Test het formulier met alleen toetsenbord en controleer of labels en foutmeldingen bruikbaar zijn.
4. Laat de onderaannemer bevestigen dat hij de voorkeur gezien heeft, en controleer bij echte opvolging steekproefsgewijs of ze ook gevolgd wordt; een bevestigingsmail aan de klant bewijst dat niet.
5. Noteer datum en wijziging in een eenvoudig logboek.

Beperk je niet tot één browser of toestel; het formuliercursusmateriaal op web.dev: formulieren leren noemt testen op verschillende apparaten, browsers en contexten als onderdeel van een goed formulier. Wil je weten welke zichtbare signalen jouw website rond contactmogelijkheden en formulieren toont, bekijk dan de publieke signalen via Marketing Scan. Een publieke scan meet wat van buitenaf zichtbaar is en bewijst niet hoe jouw overdracht intern werkt, dus je eigen testaanvragen blijven nodig.