Offerte-wizard

Probleem

Een offerteaanvraag kwam binnen als vrije tekst, en juist wat je nodig hebt om te kunnen offreren zat er meestal niet in. Of een vrachtwagen bij de locatie kan komen, hoe ver hij dan nog moet lopen, wat de ondergrond is en of er haringen in mogen: dat bepaalt of een klus überhaupt uitvoerbaar is en wat hij kost. Diezelfde kennis, plus het aantal palen per tentmaat en de vuistregels over werkgebied en last-minute aanvragen, zat in de hoofden van de mensen die de offertes maken en in een leverancierstabel. Iedere aanvraag betekende dus eerst uitzoekwerk en daarna handmatig overtypen, terwijl de aanvrager zat te wachten op een prijs.

Diagnose

Het vastlopen zat niet in het offreren zelf maar in alles ervoor, en dat is precies het deel dat uit vaste regels bestaat. Ik heb de vragen die daarover open stonden bij de klant uitgevraagd en de antwoorden één op één in de flow gezet, inclusief de palentabel die ik letterlijk heb overgenomen in plaats van na te rekenen. Wat ik bewust niet heb geautomatiseerd is het beprijzen zelf, want een prijs die naar buiten gaat is niet terug te draaien en hangt af van factoren die de klant per aanvraag weegt. De scheidslijn is daarom: alles wat een regel is doet de software, de beslissing blijft bij een mens die een kant-en-klare aanvraag voorgeschoteld krijgt.

Aanpak

1. De wizard draait ingebed op de site van Alphatenten, via een eigen WordPress-plugin die de framehoogte meet, meescrolt bij een stapwissel en de herkomst van de bezoeker meestuurt.
2. Stap 1 legt naam, mail en telefoon vast achter een spamcheck en een snelheidslimiet, zodat de lead bestaat ook als iemand daarna afhaakt.
3. Stap 2 en 3 halen de tenttypes, maten en dagprijzen live uit Rentman, het verhuurpakket dat ze al gebruikten, tonen een 3D-preview met een palenindicatie, en zoeken bij het adres de wegafstand vanaf het depot op.
4. Stap 4 stelt de locatievragen apart, zodat bereikbaarheid, ondergrond en vrije ruimte gestructureerd binnenkomen in plaats van als vrije tekst.
5. Bij verzenden herleidt de server de afstand opnieuw uit het ingezonden adres, herberekent de indicatie, claimt de aanvraag zodat hij nooit dubbel wordt verwerkt, en maakt hem met alle regels aan in Rentman.
6. Daarna gaat er een interne mail uit met de plattegronden als bijlage en een bevestiging naar de aanvrager. Haakt iemand halverwege af, dan sturen twee herinneringsmails uit een wachtrij hem terug; die vervallen zodra hij afrondt.

Afwegingen

• De laatste klik blijft bij een mens

  De wizard zet een complete aanvraag klaar, met de tent en de opties als echte regels, maar bouwt zelf nooit een offerte en verstuurt zelf nooit een prijs. Het alternatief, de hele offerte automatisch opbouwen en de klant laten ontvangen, heb ik gebouwd en weer weggegooid toen bleek dat de Rentman-API die velden niet schrijfbaar heeft en dat het pad alleen op papier werkte. Wat ervoor in de plaats kwam is bewust de simpelere bouwsteen die het pakket wél ondersteunt, waarna sales met één klik omzet. De automatische aanmaak zit bovendien achter een schakelaar die standaard uit staat, zodat de flow ook zonder die koppeling blijft werken en dan op de interne mail terugvalt.

• Een bandbreedte op het scherm, de echte som op de server

  De indicatie loopt van onder tot boven de dagprijs en wordt afgerond, juist om geen exacte indruk te wekken bij iets dat sales later definitief maakt. De transportafstand kwam eerst uit de browser, en dat was zowel te manipuleren als verouderd zodra iemand na de adreslookup zijn adres nog aanpaste. Die waarde is nu alleen nog schermindicatie; de server herleidt het bedrag zelf uit postcode en huisnummer. Lukt dat niet, dan gaat de indicatie zónder transport de deur uit met een notitie voor sales, in plaats van terug te vallen op de clientwaarde, want dan zou een geforceerde lookup-fout precies het gaatje zijn.

• Een testmodus telt nooit als aflevering

  Een aanvrager kon het succesbericht zien terwijl er in werkelijkheid niets was verstuurd, omdat een mock-verzending en een mislukte verzending er voor de code allebei uitzagen als geslaagd. De startupcontrole weigert nu een productiedeploy zonder minstens één echt afleverkanaal, en bij het verzenden geldt dat een aanvraag die langs geen enkel kanaal een mens bereikte een nette fout oplevert in plaats van een succesbericht. Het alternatief was vertrouwen op de bestaande succesmelding en het simpel houden. Dat was goedkoper, maar liet stil dataverlies bestaan.

• De 3D-tent is gekalibreerde geometrie, geen AI-generatie

  De preview moet interactief blijven en over tientallen maten kloppen, dus alles wat platte plaatjes of video oplevert viel af, en beeld-naar-3D was te zwak voor strak gespannen doek. Ik heb de silhouetwiskunde daarom als pure functies gebouwd die zonder browser draaien en die invarianten afdwingen: symmetrie, het aantal pieken, de doorhang tussen twee masten. De esthetische eindbeoordeling is bewust een menselijke stap gebleven, via screenshots naast de referentiefoto. Toen er later echte ingemeten modellen beschikbaar kwamen, schaal ik die vanaf de voetafdruk van het doek en herhaal ik modulaire delen, in plaats van ze uit te rekken, omdat uitrekken de palen op onmogelijke afstanden zet.

Status en resultaat

De flow staat compleet in de repo en is met tests dichtgezet, van de prijsberekening en de submitbeveiliging tot de migraties, die bij elke run tegen een echte Postgres in Supabase worden nagedraaid. Wat nog openstaat is de laatste uitrolstap bij de klant en een beslissing over de 3D-look. Conversiecijfers heb ik niet: de ingebouwde A/B-test op de prijsweergave heeft nog geen uitkomst.