Een offerte laten lezen door de juiste contactpersoon

Begin met een diagnose. Neem je laatste tien offertes en noteer per offerte drie dingen: wie de aanvraag deed, wie uiteindelijk antwoordde en of die twee dezelfde persoon waren. Zo zie je waar je offertes blijven hangen. Dat geeft geen cijfer dat je kunt veralgemenen, maar je eigen patroon.

Maak daarna onderscheid tussen rollen in een koopproces. Een aanvrager zoekt informatie, een gebruiker werkt later met je dienst of product, een beslisser keurt het budget goed, en soms is er iemand die juridisch, technisch of financieel nakijkt. Eén persoon kan meerdere rollen hebben, vooral in een kleine kmo.

Vraag je jezelf af welke rol je niet kent. Is dat de beslisser, dan heeft je offerte weinig kans om alleen door de aanvrager te komen. Dat is geen wet, wel een reden om die vraag te stellen vóór je een uitgebreid voorstel opstelt.

Vraag niet alles in je eerste formulier. Het formulierenmateriaal van web.dev behandelt hoe je gebruikers helpt de juiste gegevens in te voeren en hoe je formulieren test. Het W3C stelt dat overbodige of excessieve gegevensvragen de kans vergroten dat gebruikers een formulier afbreken. Of extra vragen over budget of beslissingsmacht in jouw geval afschrikken, bronnen zeggen dat niet; dat meet je zelf.

Kies daarom een eenvoudige verdeling:

1. Aanvraagformulier: alleen wat je nodig hebt om te reageren, zoals naam, contactgegevens en een omschrijving van de vraag.
2. Eerste reactie of telefoongesprek: vraag dan naar de rol van de contactpersoon en of anderen meebeslissen.
3. Net voor je offerte: bevestig wie de offerte moet krijgen en wanneer een beslissing nodig is.

Houd de vragen concreet en open. 'Wie kijkt met jou mee naar deze offerte?' is een open vraag die meestal meer informatie oplevert dan 'Ben je de beslisser?', dat met ja of nee te beantwoorden is. Test welke formulering bij jouw contacten werkt. Leg uit waarom je het vraagt: je wilt de offerte afstemmen op wie ermee moet werken en wie ze moet goedkeuren.

Als je toch een veld wilt toevoegen aan je formulier, controleer het dan met deze lijst. De punten volgen uit de richtlijnen over toegankelijke formulieren.

• Label: elk veld heeft een zichtbaar label, gekoppeld aan het veld. Volgens de formulierhandleiding van W3C WAI helpen labels onder meer mensen die spraakbesturing of een schermlezer gebruiken.
• Instructie: een korte uitleg waarom je de vraag stelt, bijvoorbeeld 'zodat we de offerte aan de juiste persoon bezorgen'.
• Verplicht of vrijwillig: markeer helder wat nodig is. Houd het aantal verplichte velden klein.
• Gegroepeerd: horen meerdere velden bij elkaar, bijvoorbeeld een tweede contactpersoon, groepeer ze zichtbaar.
• Validatie: controleer invoer in de browser voor snelle feedback, en ook aan serverzijde. MDN waarschuwt dat clientvalidatie geen volledige beveiliging is, omdat die te makkelijk te omzeilen is.
• Foutmelding: zeg wat er mis is en hoe je het oplost.
• Geen tijdsdruk: vermijd een tijdslimiet op het formulier. Is er toch een nodig, bijvoorbeeld om beveiligingsredenen, laat de gebruiker die dan uitzetten of verlengen.

Test het formulier daarna op meerdere apparaten en met toetsenbord. Of je formulier voldoet aan een wettelijke norm, valt buiten dit artikel.

Gebruik de tabel om te bepalen hoe je de offerte aanbiedt. Pas ze aan op je eigen aanbod.

Stuur geen offerte naar een derde zonder dat je contactpersoon dat weet of heeft toegestaan. Dat voorkomt wrevel, en bij persoonsgegevens kan het ook een privacykwestie worden waarover een gekwalificeerde adviseur kan oordelen.

Een offerte van meerdere pagina's wordt zelden volledig gelezen door iedereen. Voeg daarom één gedeelde samenvatting toe die je contactpersoon zonder aanpassing kan doorsturen. Houd haar korter dan één pagina en gebruik dezelfde opbouw bij elke offerte:

1. Vraag: wat de klant wil bereiken, in zijn eigen woorden.
2. Voorstel: wat je levert, in enkele zinnen.
3. Omvang en prijs: wat is inbegrepen en wat niet, met totaalprijs of prijsbasis.
4. Planning: startdatum, belangrijkste stappen en wat jij van de klant nodig hebt.
5. Beslispunten: wat de lezer moet goedkeuren en tot welke datum de offerte geldt.
6. Vragen: wie bij jou antwoordt, en hoe.

Schrijf het zonder vakjargon, zodat een lezer die het gesprek niet voerde het toch begrijpt. Vermeld ook welke aannames je maakte. Een klant kan dan snel zien welke ervan niet kloppen.

Een fictief voorbeeld van invoer en verwachte controles, zonder resultaten. Een aanvrager vult je formulier in met naam, e-mailadres en een korte omschrijving. In je eerste reactie vraag je: 'Wie kijkt nog mee naar de offerte, en wat gebeurt er intern nadat jullie ze ontvangen?' De aanvrager antwoordt dat een collega het budget goedkeurt. Je noteert in je CRM: aanvrager, tweede lezer met rol, en gewenste beslissingsdatum.

Je stuurt de offerte met de gedeelde samenvatting en zegt in de begeleidende mail dat de samenvatting bedoeld is om door te sturen. Je verwachte controles, zonder voorspelling van het resultaat:

1. Is de rol van elke lezer genoteerd vóór je de offerte verstuurt?
2. Bevat de samenvatting vraag, voorstel, prijs, planning, beslispunten en contact?
3. Heb je een vervolgmoment afgesproken en wat doe je als het uitblijft?
4. Noteer na elke offerte of de beslisser die je verwachtte ook effectief reageerde.

Na tien offertes kijk je of je rolvraag het patroon uit sectie één veranderde. Dat is een eigen vergelijking en geen bewijs dat de vraag de oorzaak is.

Wil je zien welke formulier- en contactsignalen bezoekers publiek op je website aantreffen? Bekijk de publieke signalen van je site via Marketing Scan. De scan meet zichtbare signalen en kan je interne offerteproces of formulierinstellingen niet beoordelen.