Formulieren op je website: Meer dan een contactformulier

Wat komt er zoal kijken bij formulieren op je website?

Probeer een formulierenchaos te vermijden

Formulieren op je website: meer dan een contactformulier

Bijna iedere website heeft er wel één: een formulier.

Soms is het niet meer dan een naam, een e-mailadres, een tekstvak en een knop met Verzenden. Maar formulieren worden ook gebruikt om offertes aan te vragen, afspraken te maken, deelnemers in te schrijven, sollicitaties te ontvangen, supportvragen te stellen of complete intakes uit te voeren.

En juist daar gaat het vaak mis.

Want wanneer iemand vraagt om “een formulier op de website”, wordt er al snel gedacht aan de techniek. Welke plugin gaan we installeren? Welke velden moeten erin? En welke kleur krijgt de verzendknop?

Dat zijn natuurlijk vragen die uiteindelijk beantwoord moeten worden. Maar eigenlijk beginnen we dan aan de verkeerde kant.

De belangrijkste vraag is niet:

Welke formulierplugin heb ik nodig?

De belangrijkste vraag is:

Wat moet er gebeuren wanneer iemand het formulier heeft ingevuld?

Want een formulier is meestal niet het eindpunt. Het is het begin van iets.

Een formulier is vaak het begin van een bedrijfsproces

Neem het eenvoudigste voorbeeld: een contactformulier. Iemand vult zijn naam, e-mailadres en een bericht in en klikt op verzenden. Daarna krijg jij een e-mail. Prima.

Maar zelfs bij zo’n eenvoudig formulier zijn er al allerlei vragen te stellen.

• Krijgt de bezoeker zelf ook een bevestiging?
• Wordt de aanvraag ergens opgeslagen?
• Wie binnen het bedrijf ontvangt het bericht?
• Wat gebeurt er wanneer de e-mail niet aankomt?
• En hoe weet de bezoeker eigenlijk wanneer hij een antwoord kan verwachten?

Bij een wat uitgebreider formulier worden die vragen alleen maar belangrijker.

Stel dat iemand via je website een offerte aanvraagt: Dan wil je misschien weten om welk type dienstverlening het gaat, wat het gewenste budget is en wanneer het project zou moeten starten.

Een aanvraag voor een webshop moet misschien bij iemand anders terechtkomen dan een aanvraag voor een training.

En misschien wil je na het versturen automatisch een taak aanmaken in je CRM, de klant een bevestigingsmail sturen en de gegevens bewaren zodat je ze later kunt terugvinden.

Dan heb je eigenlijk niet meer alleen een formulier.

Je hebt een kleine workflow.

Begin daarom niet met de velden

Wanneer ik een formulier maak, wil ik eigenlijk eerst weten wat het doel van het formulier is.

Wat wil je van de bezoeker weten?

Maar minstens zo belangrijk:

Waarom wil je dat weten?

Dat klinkt misschien vanzelfsprekend, maar formulieren hebben nogal eens de neiging om in de loop der tijd steeds langer te worden.

• “Kunnen we ook even het telefoonnummer vragen?”
• “Misschien is het handig om ook de bedrijfsnaam te weten.”
• “Kunnen we vragen hoe ze ons gevonden hebben?”
• “En kunnen we meteen vragen wat hun budget is?”

Voor je het weet moet iemand die eigenlijk alleen een eenvoudige vraag wilde stellen eerst zijn halve levensverhaal invullen.

Iedere extra vraag zorgt voor extra moeite. En iedere extra verplichte vraag kan een reden zijn om af te haken. Vraag daarom alleen wat je op dat moment werkelijk nodig hebt.

Niet ieder formulier hoeft kort te zijn

Dat betekent overigens niet dat een lang formulier per definitie slecht is.

Soms is een uitgebreid formulier juist heel nuttig.

Wanneer iemand een offerte aanvraagt voor een website, wil ik bijvoorbeeld liever vooraf iets weten over het bedrijf, de doelgroep, wat de website moet doen en welke functionaliteiten belangrijk zijn.

Dat voorkomt een eerste gesprek waarin we twintig minuten bezig zijn informatie boven tafel te krijgen die ook vooraf gevraagd had kunnen worden.

Het verschil zit vooral in de verwachting.

Wie op een knop Neem contact op klikt, verwacht meestal geen formulier met vijfentwintig vragen.

Wie kiest voor Vraag een offerte aan, begrijpt waarschijnlijk dat daar wat meer informatie voor nodig is.

Een formulier moet dus niet alleen technisch kloppen. Het moet ook passen bij de stap die de bezoeker denkt te gaan zetten.

Eén lange pagina of meerdere stappen?

Wanneer een formulier wat uitgebreider wordt, kan het prettig zijn om het op te splitsen in meerdere stappen.

Bijvoorbeeld:

1. Eerst wat algemene contactgegevens.
2. Daarna vragen over het soort aanvraag.
3. Vervolgens specifieke vragen die bij die keuze horen.
4. Tenslotte een controle en verzendstap.

Zo’n formulier voelt vaak minder overweldigend dan één lange pagina met tientallen velden. Maar ook hier geldt: gebruik het alleen wanneer het iets toevoegt. Voor een naam, e-mailadres en bericht is een formulier in vier stappen natuurlijk onzin.

Multi-step formulieren worden vooral interessant bij uitgebreidere aanvragen, intakes, configurators en inschrijvingen.

Laat alleen vragen zien die relevant zijn

Een andere mogelijkheid is zogenaamde conditional logic, daarmee kun je vervolgvragen laten afhangen van een eerder gegeven antwoord. Iemand die aangeeft een webshop te willen, krijgt bijvoorbeeld vragen over producten, betaalmethoden en verzending. En iemand die een informatieve bedrijfswebsite nodig heeft, krijgt die vragen helemaal niet te zien.

Dat is vaak veel prettiger dan één enorm formulier waarin iedere bezoeker alle mogelijke vragen voorgeschoteld krijgt. Bovendien krijg jij meestal betere informatie terug, omdat de vragen beter aansluiten bij de situatie van degene die het formulier invult.

Wat gebeurt er nadat iemand op verzenden klikt?

Dit is misschien wel het meest onderschatte onderdeel van een formulier. De bezoeker heeft moeite gedaan om het formulier in te vullen en klikt op Verzenden.

En dan?

Een melding als:

Bedankt. Je bericht is verzonden.

is technisch gezien voldoende, maar vanuit communicatie is het nogal mager. Vertel liever wat er nu gaat gebeuren. Bijvoorbeeld:

Bedankt voor je aanvraag. Je ontvangt binnen enkele minuten een bevestiging per e-mail. Normaal gesproken neem ik binnen één werkdag contact met je op.

Dat geeft duidelijkheid.

Afhankelijk van het formulier kun je na verzending ook doorverwijzen naar een aparte pagina. Bijvoorbeeld naar:

• aanvullende informatie;
• een kalender waarin direct een afspraak gemaakt kan worden;
• een download;
• een pagina met veelgestelde vragen;
• of de volgende stap in het proces.

Het formulier is dan niet meer een geïsoleerd onderdeel van de website, maar onderdeel van de complete klantreis.

Ook intern moet er iets gebeuren

Aan de andere kant van het formulier gebeurt meestal ook iets. Een medewerker ontvangt een e-mail. Maar misschien is dat helemaal niet de beste oplossing.

• Een supportvraag kan bijvoorbeeld beter direct in een ticketsysteem terechtkomen.
• Een nieuwsbriefinschrijving hoort waarschijnlijk in je mailinglijst.
• Een offerteaanvraag kan automatisch een nieuwe lead in een CRM worden.
• En een intake voor een training kan misschien direct aan een bestaande klant of cursist gekoppeld worden.

Veel moderne formulieroplossingen ondersteunen daarom koppelingen met andere systemen. Dat kan rechtstreeks via een bestaande integratie, via een webhook of via een API.

En soms is maatwerk simpelweg de betere oplossing.

Een formulier hoeft zijn gegevens niet in WordPress te verwerken

Dat is ook een belangrijk onderscheid. Het feit dat een formulier op een WordPress-website staat, betekent niet automatisch dat WordPress ook alle verdere verwerking moet uitvoeren. WordPress kan prima de plek zijn waar de bezoeker zijn gegevens invoert. Daarna kunnen die gegevens doorgestuurd worden naar bijvoorbeeld een CRM, een externe applicatie of een eigen Laravel-applicatie.

Voor eenvoudige toepassingen is dat natuurlijk nergens voor nodig.

Maar zodra formulieren onderdeel worden van de bedrijfsvoering, is het verstandig om jezelf af te vragen waar die gegevens uiteindelijk thuishoren.

“Het formulier werkt niet”

Een veelgehoorde klacht. Alleen blijkt het formulier zelf regelmatig prima te werken.

Het probleem zit dan bij de e-mail. WordPress genereert keurig een bericht, maar dat bericht komt nooit aan. Of het belandt in de spamfolder.

Het versturen van e-mail vanaf een website lijkt eenvoudig, maar betrouwbare mailaflevering is inmiddels behoorlijk wat ingewikkelder geworden. Daarom is het verstandig om e-mail vanaf een WordPress-site via een goed ingestelde SMTP-server of andere transactionele mailoplossing te versturen.

Ook zaken als SPF, DKIM en DMARC spelen daarbij een rol. Dat klinkt technisch, en dat is het eerlijk gezegd ook een beetje. Maar voor de eigenaar van de website is vooral één ding belangrijk:

Test niet alleen of je op de verzendknop kunt klikken. Test ook of de e-mail daadwerkelijk aankomt.

En doe dat niet alleen op hetzelfde e-mailadres dat je tijdens het bouwen gebruikt. Test bijvoorbeeld ook eens met een Gmail- of Outlook-adres.

En dan komt de spam

Zodra een formulier enige tijd online staat, ontdekken bots het meestal vanzelf. Soms krijg je een paar vreemde berichten per week. Soms tientallen of honderden.

De klassieke oplossing hiervoor was lange tijd een CAPTCHA waarbij je verkeerslichten, zebrapaden of motorfietsen moest herkennen. Technisch effectief, maar vanuit gebruiksvriendelijkheid niet altijd geweldig.

Er bestaan gelukkig meer methoden. Een honeypot is bijvoorbeeld een veld dat voor normale bezoekers verborgen blijft, maar door eenvoudige bots wel wordt ingevuld. Daardoor kan het systeem herkennen dat het waarschijnlijk om spam gaat.

Daarnaast zijn er oplossingen zoals Cloudflare Turnstile en andere vormen van automatische botdetectie.

De kunst is om spam tegen te houden zonder echte bezoekers lastig te vallen. Een beveiliging die iedere legitieme bezoeker drie puzzels laat oplossen is uiteindelijk ook geen goede beveiliging. Dan heb je simpelweg een nieuw probleem gecreëerd.

Denk ook aan privacy

Met een formulier verzamel je persoonsgegevens.

Soms alleen een naam en e-mailadres. Maar bij een uitgebreider formulier kunnen dat veel meer gegevens zijn. Vraag daarom niet automatisch alles wat misschien ooit handig zou kunnen zijn.

• Wanneer je geen geboortedatum nodig hebt, vraag er dan ook niet naar.
• Wanneer een telefoonnummer alleen handig maar niet noodzakelijk is, maak het dan niet verplicht.

En denk ook na over wat er met ingevulde formulieren gebeurt. Veel formulierplugins kunnen inzendingen in de WordPress-database opslaan. Dat is handig wanneer een e-mail verloren gaat. Maar daardoor staat die informatie dus ook op de server.

Dat betekent dat je moet nadenken over hoe lang je die gegevens wilt bewaren en wie erbij kan.

Bestanden uploaden vraagt extra aandacht

Een formulier waarmee bezoekers bestanden kunnen uploaden verdient nog wat extra aandacht. Een afbeelding of eenvoudig document is één ding.

Maar sollicitaties, identiteitsbewijzen, medische documenten of andere gevoelige informatie zijn iets heel anders. Niet iedere upload zou zomaar als bijlage via gewone e-mail doorgestuurd moeten worden.

Bovendien moet je technisch rekening houden met het soort bestanden dat geüpload mag worden, de maximale bestandsgrootte en de beveiliging van de opslag.

‘Kunnen mensen ook even een bestand meesturen?’ klinkt als een kleine toevoeging.

Dat kan het zijn. Maar het hoeft niet.

Een formulier moet ook toegankelijk zijn

Een goed formulier moet niet alleen mooi zijn, het moet ook bruikbaar zijn.

Dat betekent bijvoorbeeld dat ieder veld een duidelijk label heeft. Een placeholder in een veld is niet altijd een goede vervanging voor zo’n label. Zodra iemand begint te typen verdwijnt die tekst immers.

Foutmeldingen moeten eveneens duidelijk zijn.

‘Er is een fout opgetreden’ helpt niemand.

‘Vul een geldig e-mailadres in’ wel.

Ook moet een formulier met het toetsenbord te bedienen zijn en moet duidelijk zichtbaar zijn welk veld op dat moment actief is. Dat zijn misschien kleine details, maar juist bij formulieren maken zulke details een groot verschil.

Welke formulierplugin moet je kiezen?

Pas nadat al die andere vragen beantwoord zijn, wordt het interessant om naar de techniek te kijken.

Voor sommige websites zijn de formulieren die al in een pagebuilder aanwezig zijn meer dan voldoende.

Gebruik je bijvoorbeeld Elementor Pro en wil je een eenvoudig contact- of inschrijfformulier, dan hoeft daar niet per definitie nog een extra plugin bij.

Wil je uitgebreidere mogelijkheden, dan zijn er gespecialiseerde formulierplugins zoals Gravity Forms, Fluent Forms en Formidable Forms. Ook daar geldt weer dat er niet één beste oplossing bestaat.

De beste keuze hangt af van wat je nodig hebt.

Elementor Forms, Gravity Forms, Fluent Forms of Formidable Forms?

Je kunt natuurlijk enorme tabellen maken waarin je per plugin tientallen functies afvinkt.

Heeft plugin A conditional logic? Kan plugin B een betaling verwerken? Ondersteunt plugin C een webhook?

Dat soort vergelijkingen zijn niet waardeloos, maar ze vertellen maar een deel van het verhaal. Bovendien veranderen functies en licenties voortdurend.

Ik vind het nuttiger om te kijken naar het soort toepassing waarvoor ik een formulier nodig heb.

Dit is bewust geen ranglijst.

Voor een eenvoudige WordPress-site die ik toch volledig met Elementor bouw, zou ik niet automatisch Gravity Forms installeren omdat die plugin meer kan. Wanneer Elementor Forms alles doet wat nodig is, is dat waarschijnlijk de eenvoudigste oplossing.

Maar stel dat het formulier steeds belangrijker wordt.

Een offerteaanvraag krijgt verschillende routes afhankelijk van de antwoorden, gegevens moeten naar een CRM, er moet misschien betaald worden en later komt de vraag of dezelfde informatie ook naar een andere applicatie gestuurd kan worden.

Dan wordt een gespecialiseerde formulierplugin al snel interessanter.

En wanneer het resultaat van het formulier zelf weer onderdeel wordt van de website – bijvoorbeeld bij een prijsberekening, een configurator of een overzicht dat op basis van inzendingen wordt opgebouwd – komt een oplossing als Formidable Forms nadrukkelijker in beeld.

De keuze voor een formulierplugin begint dus opnieuw niet bij de plugin. Hij begint bij wat je met het formulier wilt bereiken.

Niet alles hoeft in één formulierplugin

Formulierplugins zijn in de loop der jaren steeds uitgebreider geworden. Dat is handig, maar het kan ook verleidelijk zijn om ieder probleem met nóg een uitbreiding op dezelfde plugin op te lossen.

• Een add-on voor betalingen.
• Nog één voor CRM.
• Een andere voor PDF-documenten.
• Nog eentje voor afspraken.
• En vervolgens een uitbreiding om die uitbreidingen met elkaar te laten praten.

Op een bepaald moment moet je jezelf afvragen of je nog een formulier aan het bouwen bent of inmiddels een applicatie. Dat is vaak het moment waarop maatwerk interessant wordt.

Wanneer wordt een formulier maatwerk?

Daar bestaat natuurlijk geen harde grens voor, maar een paar signalen zijn wel herkenbaar.

Wanneer een formulier complexe berekeningen uitvoert, gegevens uit meerdere systemen moet ophalen of uitgebreide bedrijfslogica bevat, kom je al snel in maatwerk terecht.

Hetzelfde geldt wanneer één inzending allerlei andere processen moet starten.

Bijvoorbeeld:

• een klant aanmaken;
• een project openen;
• medewerkers toewijzen;
• een betalingsverzoek genereren;
• gegevens naar een externe applicatie sturen;
• en afhankelijk van de antwoorden verschillende vervolgacties uitvoeren.

Dat kun je soms allemaal met plugins en automatiseringsdiensten oplossen.

Maar technisch mogelijk betekent niet automatisch verstandig.

Een relatief kleine maatwerkoplossing kan uiteindelijk eenvoudiger, betrouwbaarder en beter onderhoudbaar zijn dan een verzameling plugins en tussenkoppelingen.

Test het hele proces

Wanneer een formulier klaar is, test dan niet alleen of de verzendknop werkt. Doorloop het alsof je zelf een bezoeker bent.

• Wat gebeurt er wanneer je een verplicht veld vergeet?
• Is duidelijk wat er fout is?
• Werkt het formulier op een telefoon net zo prettig als op een desktop?
• Wat gebeurt er wanneer iemand tweemaal snel achter elkaar op verzenden klikt?
• Komt de bevestigingsmail aan?
• Komt de interne melding aan?
• Worden de gegevens opgeslagen waar je ze verwacht?
• En als het formulier gegevens naar een ander systeem stuurt: komen ze daar daadwerkelijk terecht?

Test niet alleen de voorkant, test het hele proces.

Het beste formulier begint niet bij de plugin

Een contactformulier kan heel eenvoudig zijn. En als meer niet nodig is, moet je het vooral eenvoudig houden.

Maar zodra formulieren belangrijk worden voor verkoop, afspraken, support, inschrijvingen of andere bedrijfsprocessen, is het verstandig er wat langer bij stil te staan.

• Welke informatie heb je werkelijk nodig?
• Wat verwacht de bezoeker?
• Wat gebeurt er na het verzenden?
• Wie moet de informatie ontvangen?
• Waar moeten gegevens worden opgeslagen?
• En welke vervolgstappen kunnen eventueel automatisch worden uitgevoerd?

Daarna pas komt de vraag welke techniek je daarvoor gaat gebruiken, want uiteindelijk is de belangrijkste vraag niet:

Welke formulierplugin zullen we installeren?

Maar:

Wat moet er gebeuren nadat iemand op verzenden heeft geklikt?

Doe het goed!

Heb je een formulier nodig dat meer moet doen dan alleen een e-mail versturen? Dan is het verstandig om eerst goed te kijken naar het proces erachter: welke informatie heb je nodig, waar moet die terechtkomen en wat moet er daarna gebeuren? Soms is een standaardformulier meer dan voldoende, soms is een koppeling of wat maatwerk de betere oplossing. Wil je eens sparren over wat in jouw situatie logisch is, neem dan gerust contact met me op.

Dit artikel geeft een antwoord op onder meer de volgende vragen:

1. Waar moet je op letten voordat je een formulier op je website maakt?
2. Welke informatie kun je het beste wel en niet via een formulier vragen?
3. Wat moet er gebeuren nadat iemand een formulier heeft ingevuld en verzonden?
4. Welke WordPress-formulierplugin past het beste bij een eenvoudig formulier, een uitgebreide workflow of maatwerk?
5. Hoe zorg je dat formulieren betrouwbaar, gebruiksvriendelijk, veilig en zo goed mogelijk beschermd tegen spam zijn?