Dealfases zijn niet zomaar een mooie pipeline. In een gezonde HubSpot-omgeving geven ze je team het signaal wat er vervolgens moet gebeuren, inclusief welk document de koper op dat moment nodig heeft. Als fases vaag zijn, improviseren vertegenwoordigers, en gaat het verkeerde document op het verkeerde moment de deur uit.

De oplossing is eenvoudig: geef je fases eerst een naam op basis van de werkelijkheid van de klant, en koppel daarna elke fase aan één primair documentresultaat. Als die lijn duidelijk is, verlopen automatisering en overdrachten soepeler, en stoppen vertegenwoordigers met improviseren in Slack.

Voor het volledige overzicht van hoe documentgeneratie, samenvoegen van gegevens en eSignature samenwerken in HubSpot, zie de complete gids voor documentautomatisering in HubSpot.

Waarom dealfases je documenten bepalen

HubSpot dealfases beschrijven waar een koper zich bevindt in zijn beslissing, niet waar jouw interne checklist toevallig staat. Wanneer fases verworden tot vage labels zoals "bezig" of "follow up", vullen vertegenwoordigers het gat met hun eigen gewoonten. De ene vertegenwoordiger stuurt een voorstel te vroeg. Een andere wacht te lang met een offerte. Operations achtervolgt daarna versies in plaats van het proces te coachen.

Ik behandel elke fase als een afspraak met het team. Als een deal zich in een bepaalde fase bevindt, zijn we het eens over drie dingen. Wat we geloven dat waar is over de koper, wat we hen vervolgens verschuldigd zijn, en welk artefact bewijst dat we het hebben gedaan. Dat artefact is meestal een document. Een offerte kan commerciële voorwaarden bevestigen. Een voorstel kan de scope en waarde uiteenzetten. Een contract legt de juridische kant vast. Als de fase niet een van deze impliceert, is de fase waarschijnlijk te vaag.

Deze manier van denken helpt ook RevOps. Rapportages blijven betrouwbaar omdat een verschuiving betekent dat er iets is veranderd in de echte wereld, niet dat iemand op een knop heeft geklikt om een dashboard op te schonen.

Hoe ik fases koppel aan documenttypen

Ik begin met een overzicht in gewone taal op een whiteboard of een eenvoudige tabel, nog niet in HubSpot. Links zet ik de fases die we willen in de klantreis. Bovenaan zet ik de documenttypen die we daadwerkelijk gebruiken, zoals offertes, voorstellen, contracten, orderformulieren of statements of work. Vervolgens teken ik één primair document per fase.

Vroege pipelinefases hebben misschien alleen een lichte offerte of een ruwe schatting nodig, zodat finance en de koper dezelfde cijfers delen. Middenfases hebben vaak een voorstel nodig dat product, prijs en tijdlijn samenvoegt. Late fases hebben een contract of orderformulier nodig dat overeenkomt met wat al was afgesproken. De regel die ik hanteer is één primair document per fase. Secundaire bijlagen kunnen bestaan, maar iedereen moet het belangrijkste te leveren product kennen.

Wanneer je die kaart verbindt met hoe je werkt in HubSpot, kun je gebruikmaken van Portant's HubSpot integration zodat de juiste sjabloon live deal- en bedrijfsgegevens ophaalt in plaats van kopiëren en plakken. Dat is het moment waarop documentautomatisering stopt een nevenproject te zijn en onderdeel wordt van de pipeline.

Een eenvoudig fasepatroon dat schaalt

Je hebt geen twintig fases nodig om precies te zijn. Ik raad vaak een basisstructuur aan die weerspiegelt hoe B2B-kopers daadwerkelijk kopen, en pas je de labels daarna aan voor jouw branche. Een patroon dat voor veel teams werkt, ziet er zo uit.

Discovery en kwalificatie richten zich op fit en autoriteit. Het document hier is misschien een korte scopesamenvatting of een vroeg commercieel overzicht, soms geleverd als een eenvoudige offerte zodat beide partijen het erover eens zijn dat je in de goede richting zit. Evaluatie is waar een uitgebreider voorstel thuishoort, met duidelijke opties en aannames. Mondelinge toezegging of inkoop is waar juridische taal verschijnt, dus je contract of MSA moet aansluiten bij wat het voorstel al vermeldde. Closed won is waar je alles operationeels afrondt, zoals een orderformulier dat overeenkomt met SKU-niveau detail.

Het gaat er niet om mijn labels woord voor woord te kopiëren. Het gaat erom dat wanneer een vertegenwoordiger een deal verschuift, ze zeggen: "We hebben nu het papierwerk bijgewerkt dat bij dit deel van de verkoop hoort."

Vangrails die vertegenwoordigers op één lijn houden

Fases werken alleen als mensen het erover eens zijn wanneer ze worden verschoven. Ik gebruik lichte definities opgeslagen in een playbook van één pagina of in de helptekst van HubSpot-eigenschappen. Elke fase krijgt twee of drie bulletcriteria. Zo kan "Voorstel verstuurd" bijvoorbeeld vereisen dat er een benoemde economische beslisser is, een gedocumenteerde behoefte, en een voorstelbestand dat is geregistreerd bij de deal. Als die ontbreken, mag de deal niet in die fase staan.

Verplichte velden zijn je vriend. Als een fase impliceert dat er een contract in het spel is, vereis dan de velden die contracten daadwerkelijk nodig hebben, zoals factuuradres, ondertekenaar, of regels voor inkooporders. Dat klinkt streng, maar het bespaart de juridische en financiële teams van het worden van de klachtenbalie.

Voor offertes specifiek stem ik faseverschuiving af op prijsgoedkeuring. Als een offerte intern niet is goedgekeurd, mag de deal niet springen naar een fase die een formeel voorstel of een contract belooft. Die ene regel voorkomt veel beschamend terugkrabbelen.

Automatisering en workflows zonder de chaos

Zodra de kaart duidelijk is, is automatisering veiliger. Ik zie workflows als dienaren van de fasedefinities, niet andersom. Een workflow die wordt geactiveerd bij het betreden van een fase, moet één duidelijke taak uitvoeren, zoals een documentrecord aanmaken, een manager informeren, of een goedkeuringspad starten. Als een workflow vijf dingen tegelijk probeert te doen, wordt debuggen pijnlijk en verliezen vertegenwoordigers het vertrouwen.

Portant is gebouwd voor dit soort HubSpot-eerst workflows. Teams gebruiken workflows in Portant om documenten te genereren wanneer een deal de juiste fase bereikt, sjablonen te bewaren in Google Docs of Office-bestanden die ze al hebben, en outputs terug op te slaan in HubSpot zodat rapportages in één systeem blijven. Het belangrijkste voordeel: documenten worden hun eigen records in HubSpot, zodat leidinggevenden de status kunnen zien zonder vertegenwoordigers te achtervolgen.

Ik raad nog steeds een pilot aan. Kies één team, drie tot vijf fases, en één documenttype per fase. Voer het een paar weken uit, los de wrijving op, en rol daarna breder uit. Grootschalige implementaties van faselogica leiden bijna altijd tot stille omwegen.

Waar ik op let tijdens reviews

In pipeline reviews zoek ik naar een mismatch tussen de fase en de documenten bij de deal. Als deals zich opstapelen in een late fase maar de activiteitentijdlijn geen contract of voorstel laat zien, is de kaart kapot of slaat het team stappen over. Ik let ook op dubbele documenten. Twee voorstellen met verschillende totalen betekenen meestal dat de faseregels onduidelijk waren of dat gegevens na verzending zijn bewerkt.

Een ander signaal is tijd in een fase zonder klantgerichte actie. Als deals met "contract verstuurd" verouderen zonder vergaderingen, opens of taken, kan het probleem liggen bij het document, het contactpersoon, of de fasecriteria. Los de criteria eerst op. Vaak beloofde de fase meer betrokkenheid dan de koper daadwerkelijk had gegeven.

Wanneer het proces helder is, besteden vertegenwoordigers minder tijd aan administratie en meer tijd aan verkopen. Portant verzorgt de documentgeneratie zodat vertegenwoordigers zich kunnen concentreren op de deal, waarbij de pipeline iedereen vertelt wat er als volgende komt.

Veelgestelde vragen

Moet elke dealfase een document versturen?

Nee. Ik gebruik fases om de werkelijkheid van de koper te markeren, niet om papierwerk te spammen. Sommige fases zijn alleen intern, zoals wachten op juridische beoordeling. Zelfs dan wil ik nog steeds één duidelijk documentresultaat gekoppeld aan de volgende klantgerichte fase, zodat het team weet wat er komt. Interne fases kunnen klantverzendings overslaan, maar mogen verantwoordelijkheid niet overslaan.

Wat als mijn team weigert fases op tijd te verschuiven?

Vertegenwoordigers vermijden faseupdates vaak wanneer de definities willekeurig aanvoelen of wanneer een verschuiving extra werk oplevert. Maak de definities strakker, verminder de vereiste klikken, en koppel faseregels aan automatisering die helpt in plaats van straft. Wanneer het verschuiven van een fase het juiste document voor hen aanmaakt, verbetert de adoptie meestal.

Hoeveel dealfases is te veel?

Als een vertegenwoordiger de fases niet uit zijn hoofd kan opnoemen met een korte uitleg voor elk, heb je er waarschijnlijk te veel. Ik streef naar de kleinste set die nog steeds vroege verkenning, actieve evaluatie, commerciële overeenkomst en gesloten resultaten van elkaar scheidt. Je kunt dealeigenschappen en playbooks gebruiken voor nuance in plaats van elke microstap een eigen fase te geven.

Kan ik documenten automatiseren zonder mijn fases te wijzigen?

Je kunt het doen, maar je haalt er minder waarde uit. Automatisering zonder discipline in je fases bespaart nog steeds tijd op opmaak, maar het lost verkeerde timing of verkeerde templates niet op. Ik stel liever de fases licht bij zodat ze aansluiten op de documenten die je al nodig hebt, en automatiseer daar vervolgens bovenop. Zo sluit elk gegenereerd bestand aan op hoe je daadwerkelijk verkoopt.