Bouw een dealdesk-app voor kortingsgoedkeuringen met een eenvoudig aanvraagformulier, gelaagde routering en een volledig beslissingslogboek voor rapportage en audits.
Kortingsgoedkeuringen lopen vaak spaak als ze in chatthreads en verspreide e-mails leven. Een verkoper vraagt om “even een uitzondering”, iemand antwoordt “ok” en een week later weet niemand meer wat er precies was goedgekeurd, waarom, of onder welke voorwaarden.
De problemen beginnen meestal klein en stapelen zich op:
Een korting raakt meer mensen dan teams verwachten. Sales is eigenaar van de deal, maar finance kijkt naar marge en betalingsvoorwaarden, managers letten op consistentie, en legal op contractrisico. Zonder één plek om te coördineren wordt elke deal een uitzondering.
Een dealdesk-app lost dit op door iedereen één gedeeld proces te geven: dien een aanvraag in, routeer naar de juiste goedkeurder, leg een duidelijke beslissing vast en bewaar alles voor later. Het doel is niet om extra bureaucratie toe te voegen, maar om dubbel werk en “goedkeuring uit het geheugen” te stoppen.
Zo ziet dat er in de praktijk uit. Een verkoper biedt 20% aan om een verlenging binnen te halen, daarna vraagt inkoop 25% plus net-60 betalingstermijn. In chat kan een manager “25% is ok” goedkeuren, terwijl finance later bezwaar maakt omdat de betalingstermijn de economie van de deal verandert. Met een goed aanvraag- en goedkeuringsproces dient de verkoper het volledige pakket één keer in, beoordelen de juiste mensen dezelfde versie en is het uiteindelijke antwoord eenduidig.
Je weet dat het werkt als sales sneller antwoord krijgt, last-minute uitzonderingen afnemen, discussies over “wat was afgesproken” verdwijnen en je eindelijk schone data hebt om op te rapporteren.
Een aanvraagformulier voor korting moet één vraag snel beantwoorden: is deze deal het waard om op deze prijs goed te keuren?
Begin met het minimale aantal velden dat een goedkeurder laat zien wat hij nodig heeft zonder in spreadsheets te hoeven zoeken:
Cijfers alleen verklaren niet waarom de korting wordt gegeven. Voeg een kleine hoeveelheid gestructureerde context toe en één kort notitieveld. Bijvoorbeeld: een dropdown voor de primaire reden (concurrentie-match, risico bij verlenging, uitbreiding, pilot), een veld voor de belangrijkste concurrent en een kort notitieveld voor specifics zoals “Concurrent biedt 25% korting als we deze week tekenen.”
Guardrails voorkomen dat zwakke aanvragen de wachtrij verstoppen. Focus op een paar vereisten die echt herwerk verminderen:
Houd het formulier snel door alleen echt gebruikte velden verplicht te maken. Als een veld zelden invloed heeft op een beslissing, maak het optioneel of conditioneel verplicht (bijvoorbeeld: vereis “concurrent” alleen wanneer de reden “concurrentie-match” is).
Bepaal toegangsregels vroeg: wie kan indienen (alle sales versus Sales Ops) en wie aanvragen kan bekijken (aanvrager, manager, finance, dealdesk). Machtigingen zijn belangrijk als notities marge, verlengingsrisico of klantproblemen bevatten.
Goedkeuring van kortingen loopt vast wanneer de regels vaag zijn. Mensen gokken, goedkeuringen stuiteren heen en weer en resultaten hangen af van wie toevallig online is.
Begin met tiers die passen bij hoe je bedrijf naar risico kijkt. Houd ze simpel zodat sales zoveel mogelijk zelf kan doen:
Voeg daarna een klein aantal override-regels toe voor zaken die echt de economie of het risico veranderen: nieuw logo versus verlenging, meerjarentermijnen, strategische accounts, niet-standaard contracttaal en afwijkende betalingsvoorwaarden. Maak de overrides expliciet zodat een 15% bij verlenging niet hetzelfde wordt behandeld als 12% bij een nieuw logo.
Ken goedkeurders toe op rol in plaats van op naam. Rollen overleven vakanties en org-wijzigingen. Voor elke tier definieer je wie moet goedkeuren en in welke volgorde. Finance controleert typisch marge en betalingstermijnen; legal stap alleen in wanneer voorwaarden veranderen of risico toeneemt. Als legal voor elke aanvraag verplicht is, vertraagt dat goedkeuringen en zoeken mensen naar omwegen.
Sales werkt met deadlines, dus reactietijden zijn belangrijk. Stel een duidelijk doel zoals “eerste reactie binnen 4 werkdagen”, plus een backup-plan (delegatie, on-call-rotatie of escalatie na een ingestelde tijd).
Maak beslissingsredenen verplicht zodat uitkomsten later bruikbaar zijn. Houd ze consistent en kort:
Als verkopers het formulier vermijden, verhuizen goedkeuringen terug naar chat en raak je het record kwijt.
Houd het formulier voorspelbaar en moeilijk te verpesten. Gebruik duidelijke labels, slimme standaardwaarden en keuzelijsten in plaats van vrije tekst waar mogelijk (dealtype, regio, valuta). Schrap alles wat geen invloed heeft op een beslissing of rapportage.
De snelste formulieren gebruiken conditionele vragen. Vraag eerst naar de korting en toon alleen wat nodig is voor die tier.
Veelvoorkomende vervolgvragen die goed werken:
Goedkeurders moeten geen basale fouten hoeven afkeuren. Voeg eenvoudige controles toe (korting binnen bereik, sluitingsdatum niet in het verleden, verplichte rechtvaardiging voor grotere kortingen). Als je een marge-minimum hebt, valideer daartegen.
Een kleine maar effectieve verbetering is een “voorbeeld voordat je indient.” Laat de verkoper de verwachte tier en wie gevraagd zal worden om goed te keuren zien. Voorbeeld: “22% korting: Salesmanager + Finance.” Dat voorkomt verrassingen en vermindert heen-en-weer.
Maak het formulier mobielvriendelijk: éénkoloms layout, grote tapdoelen en korte tekstvelden.
Een goede routing flow voelt onzichtbaar voor sales. Ze dienen één aanvraag in, krijgen snel een duidelijk antwoord en weten altijd wat er volgt.
Een praktisch proces dat de meeste teams kunnen overnemen:
Wanneer een definitieve beslissing genomen is, sluit de aanvraag, informeer belanghebbenden (verkoper, manager, finance, dealdesk) en vergrendel velden die niet meer mogen veranderen na goedkeuring.
Snel goedkeuren is belangrijk, maar het record is even belangrijk. Je wilt een spoor dat antwoordt op: wie keurde, wanneer, op basis van welke informatie en wat er onderweg veranderde?
Log elke statusverandering als een event, niet alleen het eindresultaat. Elk event moet een timestamp en de persoon (of het systeem) bevatten die de wijziging heeft gedaan.
Leg vast wat je later echt nodig zult hebben:
Revisies zijn waar teams het vaak laten afweten. Als een verkoper na indiening looptijd of betalingstermijnen wijzigt, moet het auditspoor dat duidelijk tonen en, als beleid dat vereist, een hergoedkeuring triggeren. Behandel wijzigingen als nieuwe events, geen stille bewerkingen.
Bepaal vroeg bewaartermijnen en exportregels: hoe lang je aanvragen en bijlagen bewaart, wie mag exporteren en of exports moeten worden gelogd.
De echte winst is niet alleen “snellere goedkeuringen.” Het is de geschiedenis gebruiken om toekomstige beslissingen sneller, eerlijker en makkelijker te onderbouwen.
Begin met een paar betrouwbare metrics: tijd tot beslissing, goedkeuringspercentage en gemiddelde korting. Zodra die stabiel zijn, snijd je op dimensies die aansluiten bij hoe je team werkt: verkoper/manager, regio, product, dealgrootte, tier en reden-code.
Die inzichten tonen patronen die je niet in chats en spreadsheets ziet: frequente overrides, herhaalde afwijzingsredenen, bottlenecks rond één goedkeurder en kortingstrends in specifieke segmenten.
Maandelijkse rapportage blijft praktisch als je begint met vragen:
Om rapportage schoon te houden, standaardiseer de velden die analyse aandrijven. Notities mogen vrije tekst zijn, maar sleutelvelden moeten gestructureerd zijn: segment, product, lijstprijs, gevraagde korting, uiteindelijke goedgekeurde korting, tier en een stabiele lijst met reden-codes.
Een salesrep, Maya, sluit een jaarplan van $48.000. De prospect vraagt om 22% korting omdat een concurrent 20% biedt en ze willen het contract voor vrijdag tekenen.
Maya dient een aanvraag in met de dealbasis (account, pakket, looptijd, sluitingsdatum), de cijfers (lijstprijs, gevraagde prijs, kortings%) en korte context (concurrentiedruk, deadline, wat de klant returneert). Ze voegt bewijs toe als dat volgens de tier verplicht is.
De workflow berekent de tier. In dit voorbeeld wordt alles vanaf 21% eerst naar een manager gestuurd en daarna naar finance. De manager keurt goed onder voorwaarde: 12 maanden en jaarlijkse vooruitbetaling. Finance controleert marge en betalingstermijnen en keurt daarna goed met voorwaarden, wijst af met een duidelijke reden of stuurt terug voor een specifieke wijziging.
Maya ontvangt een beslissing die ze direct naar de klant kan communiceren, met de voorwaarden in duidelijke taal. Elke stap is gelogd: wie besliste, wanneer, wat veranderde en waarom.
De meeste vertragingen komen niet door “trage goedkeurder.” Ze ontstaan omdat de workflow ruimte laat voor discussie, herwerk of blinde vlekken.
“Grote kortingen hebben goedkeuring van leiderschap nodig” valt uit elkaar zodra iemand vraagt “Hoe groot?” Maak tiers specifiek en noteer wat de route verandert (looptijd, betalingstermijnen, nieuw vs. verlenging, niet-standaard taal).
Als het formulier als administratief werk voelt, zoeken reps een omweg. Een betrouwbaar principe: als een veld niet gebruikt wordt voor een beslissing of later voor rapportage, maak het dan niet verplicht. Vul zoveel mogelijk automatisch in en hou bijlagen drempel-gebaseerd.
Als elke aanvraag een uniek verhaal is, leer je er niets van. Gebruik een korte, stabiele lijst reden-codes en houd vrije tekst voor ondersteunende details.
Als prijs, kortings%, looptijd of betalingsschema verandert na goedkeuring, behandel dat als een belangrijke wijziging. Routeer automatisch opnieuw wanneer beschermde velden worden bewerkt.
Reps blijven hangen als ze niet kunnen zien waar een aanvraag staat. Goedkeurders raken afgeleid als elke aanvraag iedereen pingt. Houd status duidelijk (“Wachten op Finance”) en meldingen gericht op de aanvrager en huidige goedkeurder.
Voordat je uitrolt, doe een korte praktische test: kan een verkoper indienen in minder dan twee minuten, kunnen goedkeurders beslissen zonder details na te jagen en kan finance de beslissing maanden later uitleggen?
Gebruik deze checklist om veelvoorkomende problemen vroeg te vangen:
Operationele regels zijn net zo belangrijk als het formulier: wat gebeurt er als een verkoper na feedback wijzigt, hoe escalatie werkt en hoe afwezigheidsdelegatie geregeld is.
Als je snel wilt prototypen, bouw dan eerst het datamodel (aanvragen, goedkeuringen, opmerkingen, versies), daarna het formulier, daarna de routering en tenslotte het automatische beslissingslog.
Als je dit bouwt met AppMaster (appmaster.io), kun je het request-datamodel maken in de Data Designer en de routering instellen in de Business Process Editor, zodat formulier, workflow en auditspoor op één plek leven en consistent blijven als je regels veranderen.
21 jan 2026
8 min
20 jan 20268 min
20 jan 20267 minExperimenteer met AppMaster met gratis abonnement.
Als je er klaar voor bent, kun je het juiste abonnement kiezen.
