Een offertecalculator voor je website die prijsindicaties omzet in aanvragen

Wanneer een directe prijsindicatie helpt, en wanneer niet

Directe prijscalculators werken voor diensten waarvan de prijs volgt uit een paar meetbare gegevens: vierkante meters vloer, te schoonmaken kamers, uren filmen, aantal gasten. Ze werken slecht als de prijs afhangt van een bezoek ter plaatse of een oordeel dat je niet in regels kunt vangen, zoals constructieve reparaties of ontwerp op maat. Zou je aan de telefoon geen prijsrange noemen, dan moet een calculator dat ook niet doen. Dan is een offerteaanvraagpagina met goede vragen de eerlijke keuze.

De vragen kiezen

Elke vraag moet de prijs veranderen of de lead kwalificeren. Doet hij geen van beide, schrap hem dan. Een goede set is kort en concreet:

1. De omvang van de klus in een eenheid die de bezoeker kent: kamers, niet vierkante meters, als de meeste mensen hun oppervlakte niet weten.
2. De belangrijkste optie die de kosten het meest verandert, als twee tot vier keuzes met elk een korte beschrijving.
3. Extra's als selectievakjes, elk met de eigen prijs erbij, zodat mensen zien waarom het totaal verandert.
4. Planning, als spoedklussen meer kosten.
5. Postcode of regio, alleen als reistijd de prijs verandert of je sommige plaatsen niet bedient.

Zet de contactvelden na de schatting, niet ervoor. Een e-mailadres vragen om een bedrag te laten zien voelt als een valstrik en veel mensen haken af; eerst het bedrag tonen en daarna een vaste offerte aanbieden levert meer van de aanvragen op die de moeite waard zijn.

De berekening goed krijgen

Schrijf je prijsopbouw als formule op voordat je om de app vraagt, want je moet de uitkomst controleren tegen klussen waarvoor je al een offerte hebt gemaakt. De meeste prijzen voor diensten passen in een patroon als: vast starttarief plus hoeveelheid maal tarief, plus extra's, maal een factor voor spoed of moeilijkheid, met een minimumbedrag.

Toon een range in plaats van één bedrag (bijvoorbeeld de uitkomst van de formule tot 15% daarboven), tenzij je prijzen echt vastliggen. Zet de aannames onder het resultaat: "Gebaseerd op kamers van gemiddelde grootte met standaard vloerbedekking. De definitieve prijs bevestigen we nadat we de klus hebben gezien." Die ene zin voorkomt de meeste discussies.

Wat Anticode bouwt

Geef de Architect je vragen, je formule en de tekst van je voorbehoud, bijvoorbeeld: "Een offertecalculator voor een tapijtreinigingsbedrijf. Vraag naar het aantal kamers, tapijt of vloerkleed, vlekbehandeling ja of nee, volgende dag of standaard. Gebruik deze tarieven. Toon een range en een uitsplitsing, en daarna een formulier voor naam, e-mail, telefoon en voorkeursdatum." Controleer elk tarief in het plan dat hij toont voordat je bouwt. Het model schrijft de calculator als één app die in de browser van de bezoeker draait, zodat het totaal meteen meeverandert als hij antwoorden aanpast, zonder dat de pagina opnieuw laadt.

De aanvraagstap gebruikt de formulierverwerking van Anticode: als de bezoeker zijn gegevens verstuurt, plaatst de app ze als contactinzending, met de antwoorden en de schatting toegevoegd aan het bericht. Je krijgt hem per e-mail en in het dashboard, en connectors kunnen hem doorsturen naar Slack, Google Sheets, Airtable, Notion, HubSpot of een willekeurige webhook, zodat hij terechtkomt waar je klussen al bijhoudt.

De prijscontrole op de server houden

De berekening van de calculator draait in de browser van de bezoeker, wat betekent dat een vastberaden bezoeker het bedrag kan aanpassen voordat hij het verstuurt. Voor een globale schatting maakt dat zelden uit; ga je het bedrag nakomen, reken het dan opnieuw uit op basis van de antwoorden voordat je bevestigt. Een sitefunctie die aan het ingebouwde contactformulier is gekoppeld, draait ook als de app de aanvraag verstuurt; de antwoorden komen binnen als regels in het bericht, dus om ze te controleren is een ondertekende aanroep naar je eigen endpoint nodig, en of de app de melding van de functie toont, hangt af van de app (vraag erom en test het). De andere route is een eigen formulier op een design-engine-pagina in plaats van een app: de sitefunctie daarvan draait op de server als het formulier wordt verstuurd, als een kleine formule over de ingestuurde getallen (kamers maal tarief plus extra's; formules werken alleen met getallen) of als een ondertekende HTTPS-aanroep naar je eigen endpoint, en het totaal verschijnt op de bedankpagina. Niets verandert terwijl de bezoeker typt, want die pagina's draaien geen scripts. De pagina over sitefuncties legt beide uit.

Beperkingen om te kennen

• Tarieven zijn wat jij invoert. De app kan geen materiaalprijzen, brandstofkosten of andere live gegevens van het web ophalen; pas de tarieven aan door om een wijziging te vragen.
• Geen betaling of aanbetaling. De calculator kan geen geld ontvangen. Link vanuit het bedankbericht naar een Stripe Payment Link of een vergelijkbare betaalpagina als je een aanbetaling wilt.
• Geen opgeslagen offertes voor de bezoeker. Er zijn geen klantaccounts; wil iemand een kopie, dan komt die uit jouw antwoord.
• Limiet op inzendingen. Gratis sites hebben per maand een bepaald aantal zichtbare inzendingen; zie prijzen voor de abonnementen.

Veelgestelde vragen

Ziet de bezoeker dezelfde schatting die ik ontvang?

Ja, de schatting en de antwoorden waarop die is gebaseerd zitten in de aanvraag, zodat je hem uit de antwoorden opnieuw kunt berekenen voordat je bevestigt.

Kan ik mijn prijzen later aanpassen?

Vraag om de wijziging in één zin, zoals "verhoog het tarief per kamer naar 40", en de app wordt bijgewerkt. Recente versies blijven in de versiegeschiedenis staan.

Kan hij de klus ook inplannen?

Een app-formulier kan een afspraakverzoek zijn met een dienst, een dag en een tijd, dat via dezelfde verwerking bij je aankomt. Een aanbetaling ontvangen kan het niet.