Een offerte met een looptijd: waarom een vast bedrag in je sjabloon je omzet kost

De verkoper vult twee getallen in; het sjabloon rekent, toont de staffel en zet het juiste totaal in de PDF. Dat scheelt fouten, en het maakt de offerte later ook nog bruikbaar voor je omzetprognose.

Het probleem in een zin

De meeste offertesjablonen zijn gebouwd voor een eenmalige levering: product erin, prijs erbij, klaar. Verkoop je diensten of abonnementen, dan is de prijs geen eigenschap van het product maar van de combinatie van product en duur. Twaalf maanden is per maand goedkoper dan drie maanden. Vierentwintig maanden weer goedkoper. Een sjabloon dat een vast bedrag plaatst, dwingt de verkoper tot een van drie dingen:

• Het bedrag met de hand overschrijven, en dan staat er in het CRM iets anders dan in de PDF.
• Een apart product aanmaken per looptijd, en dan heb je binnen een jaar drie keer zoveel producten als klanten.
• De offerte buiten het CRM in een spreadsheet maken, en dan is je pijplijn fictie.

Alle drie zijn ze in de praktijk te zien. De derde is de duurste, omdat je er niets meer over kunt rapporteren.

Wat er mis is met gewoon het bedrag invullen

Handmatig invullen lijkt de simpelste oplossing. De verborgen kosten: het CRM-bedrag en het PDF-bedrag lopen uiteen, want de verkoper past de PDF aan en niet het veld, waardoor je pijplijn iets optelt wat niemand heeft geoffreerd. Kortingen worden onzichtbaar: als er geen tarief en looptijd in het CRM staan, kun je niet achterhalen of er tegen staffelprijs of tegen een gunst is verkocht. En je kunt niet prognosticeren: een omzetprognose over abonnementen heeft de looptijd nodig om de omzet over maanden te verdelen. Staat die alleen in de tekst van de offerte, dan bestaat hij voor je rapportage niet. Een getal dat alleen in een PDF staat, is geen gegeven. Het is een plaatje.

De drie manieren om dit in te richten

• A, twee vrije velden: de verkoper vult tarief en aantal maanden zelf in. Volledige vrijheid, een halve dag bouwtijd, maar typefouten blijven mogelijk en bij een tariefwijziging moet iedereen het weten.
• B, staffel als keuzelijst: de verkoper kiest een looptijd en het tarief rolt eruit. Vrijheid binnen de staffel, met motivatie bij afwijking. Ongeveer een dag bouwtijd, fouten vrijwel uitgesloten, en een tariefwijziging is een tabel bijwerken.
• C, prijslijst per looptijd: elke looptijd is een eigen prijslijst op het product. Geen vrijheid, tenzij met korting. Een tot twee dagen bouwtijd, fouten uitgesloten, past bij veel producten met een vaste prijsmatrix.

De beslisregel: heb je vaste staffels, kies B. Is elk tarief onderhandeld maatwerk, kies A, met een ondergrens die een akkoord afdwingt. Heb je tientallen producten met elk een eigen matrix, dan pas C. De meeste MKB-organisaties die hier tegenaan lopen, komen uit op B met een handmatige ontsnapping: standaardtarief uit de staffel, met de mogelijkheid het te overschrijven en dan verplicht een reden op te geven.

De vier bouwstenen van een sjabloon dat meerekent

• Twee invulvelden op de offerte: looptijd in maanden (een getal of een keuzelijst) en tarief per maand (een bedrag). Beide op de offerteregel als de looptijd per regel kan verschillen, anders op de offertekop.
• Een berekend totaal: tarief maal maanden, eventueel maal aantal. Laat dit het systeem doen, nooit de mens.
• Een tarieftabel die de staffel kent: een plek waar staat welk tarief bij welke looptijd hoort, zodat een tariefwijziging een aanpassing is en geen rondmail.
• Een PDF-sjabloon dat beide toont. Niet alleen het eindbedrag, maar ook de regel eronder: 450 euro per maand maal 12 maanden. Klanten die het kunnen narekenen, bellen minder vaak terug.

Daarbovenop hoort een controle die vaak vergeten wordt: een waarschuwing als het ingevulde tarief onder de staffel ligt. Zonder die grens is een invulbaar veld een open kas.

Wat je ervoor terugkrijgt, buiten de offerte om

Zodra tarief en looptijd als echte velden in het CRM staan, kun je vragen beantwoorden die daarvoor niet te beantwoorden waren:

• Wat is de gemiddelde contractduur die wij verkopen, en stijgt die?
• Hoeveel omzet ligt er vast voor de komende twaalf maanden, en wanneer loopt die af?
• Verkopen we onze langste looptijden tegen te veel korting?
• Welke offertes lopen komend kwartaal af en moeten dus nu verlengd worden?

De laatste vraag is de meest lucratieve. Een aflopend contract dat niemand ziet aankomen, is verloren omzet die je zelf hebt weggegeven.

Veelgestelde vragen

• Kan Zoho CRM het offertebedrag zelf uitrekenen uit tarief en looptijd? Ja. Je voegt twee velden toe aan de offerte en laat het totaal berekenen, met een formuleveld of met een automatisering die het bedrag bij opslaan bijwerkt.
• Moet elke looptijd een apart product worden? Nee, en dat is juist de fout die je wilt vermijden. Een product met een tariefstaffel is beter te onderhouden dan vier producten die hetzelfde zijn op de prijs na.
• Komt het bedrag ook goed in de PDF-offerte? Ja, mits het PDF-sjabloon het berekende veld gebruikt en niet een los tekstveld. Zet in het sjabloon zowel het maandtarief als het aantal maanden als het totaal, zodat de klant de som kan volgen.
• Wat als de verkoper een lager tarief wil geven dan de staffel? Dat mag, maar leg het vast: een minimumtarief met een waarschuwing, en bij overschrijding een verplichte reden of een akkoord. Zo blijft de korting zichtbaar in je cijfers.
• Hoe lang duurt het om dit in te richten? Voor een enkelvoudige staffel is een halve tot een hele dag realistisch, inclusief testofferte en PDF-opmaak. Het meeste werk zit niet in de techniek maar in het vooraf op papier krijgen van de tarieven.
• Werkt dit ook als we in Zoho Books factureren? Ja. Houd de berekening dan op een plek, in het CRM, en laat de factuur het resultaat overnemen. Twee systemen die allebei rekenen, geven vroeg of laat twee bedragen.

Z.kracht richt offerteprocessen in Zoho in waarbij de verkoper invult wat hij weet, tarief en looptijd, en het systeem uitrekent wat daaruit volgt. Inclusief tariefstaffel, controle op ondergrenzen, en een PDF in de huisstijl die de klant kan narekenen. Zodat het bedrag in de offerte, het bedrag in het CRM en het bedrag op de factuur hetzelfde getal zijn.