Eén aanvraag met meerdere diensten goed doorzetten

Dien zelf een testaanvraag in voor twee of drie diensten tegelijk en volg het pad. Noteer bij elk punt wat er gebeurt.

• Kan het formulier meerdere diensten aanduiden, of dwingt het tot één keuze en een vrij tekstveld?
• Krijgt elke dienst een aparte melding of aparte ticket in je mailbox of CRM?
• Wie neemt als eerste contact op, en weet die persoon dat er ook andere diensten gevraagd werden?
• Stelt elke collega opnieuw naam, adres, timing en budget voor?

Krijgt de klant meerdere aparte meldingen of intakes, en wist de eerste contactpersoon niet van de andere diensten, dan zit het probleem waarschijnlijk in routing en overdracht, niet bij de klant. Noteer ook wat de bevestiging aan de klant zegt: weet hij wie hem opvolgt?

De toegankelijkheidstutorial van W3C voor formulieren raadt aan alleen te vragen wat nodig is voor de transactie, omdat overbodige of irrelevante vragen de kans op afhaken vergroten. Pas dat toe op een aanvraag met meerdere diensten: vraag algemene gegevens één keer en dienstspecifieke vragen alleen voor de aangevinkte diensten.

Dezelfde bron beschrijft ook technieken die hier direct bruikbaar zijn: elk veld een label geven, verwante velden groeperen met fieldset en legend, en lange formulieren opdelen in logische stappen met zicht op de voortgang. Kies bewust tussen één pagina met secties en meerdere pagina's: bij meerdere pagina's moet je tussentijdse invoer bewaren en testen of terugkeren niets wist. Een werkbare opbouw is: stap 1 contactgegevens, stap 2 aanvinken welke diensten, stap 3 per dienst enkele gerichte vragen, stap 4 samenvatting met bevestiging. Laat de klant ook aanduiden wat de hoofdvraag is, bijvoorbeeld via een keuze 'wat is voor jou het belangrijkst?'. Dat veld helpt je later bij het kiezen van de eigenaar.

Eén persoon is aanspreekpunt van de klant. Kies die persoon met vaste regels, niet naar wie toevallig het eerst reageert.

De andere collega's worden meelezers: zij leveren input aan de eigenaar en nemen geen rechtstreeks contact op met de klant, behalve na afspraak. Leg dit vast in een korte interne regel, zodat het niet van personen afhangt.

Maak één notitie per aanvraag die iedereen kan lezen. Minimale velden: naam en contactgegevens, gevraagde diensten, hoofdvraag, gewenste timing, budgetindicatie indien gegeven, vragen die de klant al beantwoordde, afspraken over contactkanaal, naam van de eigenaar en de plaatsvervanger.

Die notitie is maar bruikbaar als de data klopt. De uitleg van MDN over formuliervalidatie beschrijft dat validatie in de browser fouten meteen zichtbaar maakt, maar dat je invoer ook op de server moet controleren, omdat validatie aan de clientzijde gemakkelijk te omzeilen is. Praktisch betekent dat: verplichte velden en formaten (zoals e-mail) in het formulier afdwingen, en daarnaast in je verwerking controleren of er minstens één dienst en één bruikbaar contactkanaal is voor je een aanvraag aanmaakt. Zo komt er geen halve aanvraag bij een collega terecht.

Dit is een verzonnen testgeval, zonder uitkomsten. Voer het uit in een testomgeving of met duidelijk herkenbare testgegevens (bijvoorbeeld de naam 'TEST') en een eigen e-mailadres, zodat er geen echte klant of collega verkeerd wordt gecontacteerd. Verwijder het testrecord achteraf en controleer dat een time-out of dubbelklik geen tweede record aanmaakt.

Invoer: een testaanvraag met drie aangevinkte diensten (A, B en C), hoofdvraag B, voorkeur voor contact per e-mail, één opmerking over timing.

Verwachte technische controles:

• Er ontstaat één aanvraagrecord, geen drie.
• Het record toont alle drie de diensten en markeert B als hoofdvraag.
• De eigenaar is de verantwoordelijke voor B, de plaatsvervanger is ingevuld.
• De verantwoordelijken voor A en C ontvangen een melding met de gedeelde notitie en de instructie niet rechtstreeks te antwoorden.
• De klant ontvangt één bevestiging met de naam van de eigenaar en een overzicht van de gevraagde diensten.
• Laat je het veld voor contactkanaal leeg, dan weigert het formulier of de verwerking de aanvraag met een begrijpelijke melding.

Test na elke aanpassing met minstens drie profielen: één dienst, twee diensten en alle diensten. Test ook met enkel toetsenbord, op een smal scherm en met een bewust fout ingevulde waarde. De cursus Forms van web.dev bevat onderdelen over het testen en analyseren van formulieren, toegankelijkheid en testen op verschillende toestellen en browsers. Gebruik die als checklist voor je technische test, en laat het team één echte aanvraag volgen tot en met de eerste klantreactie.

Grenzen: de bronnen gaan over webformulieren, validatie en toegankelijkheid. De interne eigenaarsregels in dit artikel zijn een voorstel dat je aan je eigen werking aanpast. Een test toont of je proces werkt in de geteste situaties, niet of elke toekomstige aanvraag goed verloopt. Waar je routing, mailregels of CRM-velden instelt, controleert je beheerder in de eigen systemen.

Wil je ook weten welke publieke signalen je website uitstraalt rond contact en aanvragen? Je kunt die laten bekijken via Marketing Scan. Een publieke scan ziet wat zichtbaar is en kan je interne routing of formulierverwerking niet bewijzen.