Bijlagen bij offerteaanvragen: voorkom vastlopende uploads

Een bijlage passeert een hele keten: het toestel van de bezoeker, de formuliercode, de webserver of een tussenlaag zoals een proxy of firewall, en daarna de verwerking van de aanvraag (mail, CRM of opslag). Elke schakel kan een eigen limiet hebben, en die limieten zijn zelden gelijk. Een bestand dat het formulier aanvaardt, kan dus door de server geweigerd worden, waarna de bezoeker een onduidelijke fout of helemaal niets ziet. Welke limieten bij jou gelden, lees je in de instellingen van je hosting, je formulierplugin of bij je ontwikkelaar. Vraag ze op en noteer ze.

Onderscheid daarna drie symptomen, want ze wijzen naar verschillende oorzaken:

• De knop doet niets: meestal een controle in de browser die zwijgt over de reden.
• De voortgang blijft hangen: een limiet of time-out in de server of een tussenlaag, of een zeer trage verbinding.
• Het formulier lijkt verzonden, maar er komt geen bericht binnen: de fout zit in de verwerking na de upload.

Begin met de vraag welke bijlagen je echt nodig hebt. De W3C-tutorial over toegankelijke formulieren adviseert alleen te vragen wat nodig is om het proces af te ronden, omdat overbodige vragen de kans op afhaken vergroten. Dat is een algemeen principe en geen bewijs voor jouw uploadveld. Een verplichte bijlage is dus een bewuste keuze die je zelf toetst. Gebruik dit blad per veld:

Test met neutrale proefbestanden, nooit met echte klantgegevens. De formulierlessen op web.dev bevatten een onderdeel over het testen van formulieren op verschillende toestellen en platformen; gebruik dat als uitgangspunt en vul het aan met onderstaande stappen.

1. Maak zes proefbestanden: een klein toegestaan bestand, een bestand net onder jouw laagste limiet, een bestand net erboven, een niet-toegestaan type, een bestand met spaties en accenten in de naam, en twee bestanden samen.
2. Kies minstens een desktopbrowser en een telefoon. Simuleer in de ontwikkelaarstools van je browser ook een trage verbinding.
3. Vul het formulier in met een duidelijk testadres en verstuur telkens één proefbestand.
4. Noteer per run: wat de bezoeker ziet tijdens de upload, welke melding bij een fout verschijnt, of de aanvraag aankwam en of de bijlage bruikbaar is.
5. Doe dit in een testomgeving of met een duidelijk herkenbare testaanvraag (uniek onderwerp per run). Controleer na een fout of time-out in je inbox of CRM of de aanvraag toch is opgeslagen, en of opnieuw proberen een dubbele aanvraag veroorzaakt.
6. Zet de resultaten in een tabel.
Een rij waar bezoeker en inbox niet overeenkomen, is je eerste prioriteit.

Meet de duur gerust zelf mee, maar trek er geen vaste tijdsbelofte uit: die hangt af van bestand, verbinding en server.

Een controle in de browser geeft snel feedback, maar de MDN-uitleg over validatie waarschuwt dat die niet volstaat als beveiliging: de server moet bestanden en gegevens altijd zelf opnieuw controleren. Laat je ontwikkelaar dus beide lagen bevestigen en test ze apart.

Beoordeel daarna wat de bezoeker te zien krijgt. De W3C-tutorial vraagt om meldingen bij succes en fouten, met instructies om het te herstellen. Controleer:

• Verschijnt de bestandsnaam nadat je een bestand koos?
• Is er tijdens het uploaden een zichtbare toestand, zodat de bezoeker niet opnieuw klikt?
• Noemt de foutmelding welk bestand het probleem is, wat de reden is en wat je kunt doen?
• Blijven de ingevulde velden staan na een fout?
• Zegt de succesmelding wat er nu gebeurt, bijvoorbeeld dat je de aanvraag bekijkt?

Een bijlage hoeft nooit de enige weg naar een offerte te zijn. Voeg bij het veld een zin toe als "Lukt de upload niet? Verstuur de aanvraag zonder bestand, dan bezorgen we je een veilige manier om het later aan te leveren." Kies zelf het kanaal: een beveiligde bestandsdeling met toegangsbeperking, post of een telefoongesprek. Vraag via gewone e-mail geen gevoelige documenten, zoals identiteits- of financiële stukken. Bepaal eerst of je ze voor een offerte echt nodig hebt. Voor juridische vragen over bewaring en verwerking raadpleeg je een specialist.

Overdrachtsvoorbeeld met fictieve getallen, bedoeld voor je ontwikkelaar:

• Invoer: formulier voor een offerte, optionele bijlage met plattegrond in pdf.
• Genoteerde limieten (fictief): formulier 10 MB, server 8 MB, mailverwerking 5 MB.
• Verwachte technische controle: de laagste limiet, 5 MB, bepaalt wat je belooft. De tekst bij het veld noemt 5 MB, en je test met een bestand net onder en net boven die grens.
• Verwacht gedrag boven de grens: duidelijke melding, ingevulde velden blijven staan, het alternatieve pad is zichtbaar.

Herhaal na elke aanpassing de volledige testset, ook als je maar één limiet verhoogde. Een hogere limiet in het formulier helpt niet als de server lager blijft. Bevestig bovendien in je inbox of CRM dat de bijlage heel en leesbaar aankomt, en loop het alternatieve pad één keer van begin tot einde door. Plan dezelfde test na een update van plugin, hosting of mailinstellingen, want die kunnen limieten stilletjes veranderen. Of daardoor meer aanvragen binnenkomen, kan niemand vooraf beloven. Je kunt wel aantonen dat de bekende foutsituaties beheerst zijn.

Wil je ook weten welke publieke signalen je website rond formulieren en conversie toont? Bekijk ze via Marketing Scan. Een publieke scan ziet alleen wat zichtbaar is en toont niet of je upload aan serverzijde werkt.