Elk pipeline-rapport dat ik bekijk, heeft dezelfde zwakte. De fases zijn verouderd. Deals staan twee dagen na het ondertekenen van het contract nog op "Voorstel Verzonden" omdat een medewerker vergat een kaart over het bord te slepen. Het is een kleine omissie, maar die maakt je forecast onjuist, je velocity-cijfers onbetrouwbaar en je pipeline-reviews een giswerk.

Er is een eenvoudige oplossing. In plaats van mensen te vragen dealfases bij te werken, laat je het document zelf de overgang activeren. Wanneer een voorstel wordt verzonden, gaat de deal naar "Voorstel Verzonden." Wanneer een handtekeningverzoek wordt verstuurd, gaat de deal naar "Contract Verzonden." Wanneer het document is ondertekend, gaat de deal naar "Gesloten Gewonnen." Geen geheugen vereist.

Hier lees je hoe je automatische voortgang van dealfases instelt in HubSpot met de Document Status-eigenschap van Portant en standaard HubSpot-workflows. Als je pipeline altijd een paar dagen achterloopt op de werkelijkheid, is dit waarschijnlijk de reden.

Waarom handmatige updates van dealfases mislukken

Medewerkers hebben het druk. Ze zijn aan het bellen, schrijven e-mails en volgen kopers op. Een dealfase bijwerken is een taak met lage prioriteit die geen enkele waarde toevoegt aan de verkoop zelf. Dus wordt het overgeslagen, uitgesteld of aan het einde van de week in bulk gedaan.

De impact is groter dan de meeste leidinggevenden beseffen. Als vijf medewerkers elk drie deals per week vergeten bij te werken, staan er op elk willekeurig moment vijftien deals in de verkeerde fase. Je pipeline-rapport vertelt het management één verhaal. De werkelijkheid vertelt een ander.

Forecasting hangt af van fase. Als je forecastmodel deals weegt op basis van fasewaarde, leveren verouderde fases onjuiste cijfers op. Een deal die eigenlijk gesloten is maar nog als "Contract Verzonden" wordt weergegeven, onderschat je gesloten omzet. Een deal waarbij het voorstel mislukte maar nog steeds als "Voorstel Verzonden" staat, overschat je pipeline. Beide zijn slecht.

De oplossing is niet meer discipline of een extra Slack-herinnering. Je kunt mensen nooit trainen om betrouwbaar een CRM-veld bij te werken elke keer dat er een externe gebeurtenis plaatsvindt. De oplossing is de handmatige stap volledig te verwijderen en de gebeurtenis zelf de update te laten activeren.

De documentlevenscyclus als pipeline-signaal

Wanneer je Portant gebruikt met HubSpot, slaat Portant elk document dat je genereert op als een eigen record (een Custom Object) bij de deal. Dat record bevat een eigenschap genaamd Document Status, die automatisch wordt bijgewerkt naarmate het document door de levenscyclus gaat.

Dit is het signaal dat je pipeline nodig heeft. In plaats van medewerkers te vragen hun inbox in de gaten te houden en daarna HubSpot bij te werken, verandert de Document Status-eigenschap vanzelf wanneer er iets echts gebeurt. Een document wordt verzonden. Een handtekening wordt aangevraagd. Het document wordt ondertekend. Er gaat iets mis. Elk van die statuswijzigingen komt overeen met een echt moment in het verkoopproces, wat betekent dat elk ervan direct kan worden gekoppeld aan een dealfase.

Ik schreef een gerelateerd artikel over hoe je dealfases afstemt op documenttypen dat de conceptuele koppeling tussen fases en documenten behandelt. Dit artikel gaat een stap verder. Het automatiseert die afstemming zodat de pipeline zichzelf bijwerkt.

Portant Document Status-waarden

Het Portant Document Object volgt negen statuswaarden. Dit is wat elke waarde betekent en wanneer die van toepassing is.

  • Pending: Portant heeft het documentrecord aangemaakt, maar het genereren is nog niet begonnen.
  • Draft: Portant heeft het document gegenereerd, maar het staat nog als concept en is nog niet definitief.
  • Approved: Je team heeft het document intern beoordeeld en goedgekeurd. Dit is van toepassing als je de approval workflows.
  • Sent: Portant heeft het document afgeleverd bij de ontvanger.
  • Signature Requested: Portant heeft een eSignature-verzoek verstuurd naar de ondertekenaar of ondertekenaars.
  • Partially Signed: Ten minste één ondertekenaar heeft getekend, maar anderen moeten nog tekenen.
  • Signed: Alle ondertekenaars hebben hun handtekening gezet.
  • Completed: De documentlevenscyclus is afgerond, inclusief eventuele stappen na de ondertekening.
  • Error: Er is iets misgegaan tijdens het genereren, verzenden of ondertekenen.

Niet elke deal doorloopt alle negen statussen. Een eenvoudige offerte kan van Pending naar Sent gaan zonder dat een handtekening nodig is. Een contract kan Sent, Signature Requested, Partially Signed, Signed en Completed doorlopen. De workflows die je bouwt, moeten rekening houden met de statussen die er in jouw proces werkelijk toe doen.

Raadpleeg voor volledige details over hoe deze eigenschappen werken de Portant-documentatie over het activeren van HubSpot-workflows op basis van documentstatuswijzigingen.

De workflows bouwen

De instelling maakt gebruik van de standaard workflow-tool van HubSpot. Je maakt deal-gebaseerde workflows die worden geactiveerd bij wijzigingen in de Document Status-eigenschap op het gekoppelde Portant Document Object.

Dit is de kernkoppeling die ik aanbeveel voor de meeste verkoopprocessen.

Workflow 1: Document Sent → Verplaats naar "Voorstel Verzonden"

  1. Ga naar Automation > Workflows in HubSpot.
  2. Maak een nieuwe deal-gebaseerde workflow aan.
  3. Stel de inschrijvingstrigger in op: Gekoppeld Portant Document Object > Document Status is "Sent."
  4. Voeg een actie toe: Stel dealeigenschap in > Dealfase op "Voorstel Verzonden" (of welke equivalente fase dan ook in jouw pipeline).
  5. Sla op en activeer.

Wanneer Portant een voorstel of offerte aflevert bij de koper, verandert de Document Status naar "Sent." Deze workflow vangt die wijziging op en verplaatst de deal automatisch vooruit.

Workflow 2: Signature Requested → Verplaats naar "Contract Verzonden"

Zelfde structuur, andere trigger.

  1. Inschrijvingstrigger: Document Status is "Signature Requested."
  2. Actie: Stel dealfase in op "Contract Verzonden."

Dit dekt het moment waarop het ondertekeningsproces begint. De koper heeft het document ontvangen met een eSignature-verzoek en de dealfase moet dat weerspiegelen.

Workflow 3: Signed of Completed → Verplaats naar "Gesloten Gewonnen"

  1. Inschrijvingstrigger: Document Status is "Signed" OF "Completed."
  2. Actie: Stel dealfase in op "Gesloten Gewonnen."

Je kunt "Signed" of "Completed" gebruiken, afhankelijk van hoe jouw proces werkt. Als je wilt dat alle stappen na de ondertekening zijn afgerond voordat je de deal sluit, activeer dan op "Completed." Als de laatste handtekening jouw sluitmoment is, activeer dan op "Signed."

Workflow 4: Error → Stel de dealverantwoordelijke op de hoogte

  1. Inschrijvingstrigger: Document Status is "Error."
  2. Actie: Stuur een interne melding naar de dealverantwoordelijke met een bericht zoals: "Een document bij [Deal Name] bevat een fout. Controleer het document en verzend het opnieuw indien nodig."

Deze workflow is belangrijk omdat foutstatussen onzichtbaar zijn zonder een melding. Een medewerker merkt mogelijk niet dat een contract niet is gegenereerd of dat een handtekeningverzoek is mislukt. Een directe melding voorkomt dat deals ongemerkt vastlopen.

Alternatief: één workflow met vertakkingen

Als je liever minder workflows beheert, kun je één deal-gebaseerde workflow maken met een If/Then-vertakking die de Document Status-waarde controleert en naar de juiste actie verwijst. De logica is identiek, alleen de organisatie verschilt. Ik begin meestal met aparte workflows omdat die makkelijker te debuggen zijn, en consolideer later als het team een overzichtelijkere weergave wil.

Dealtags toevoegen voor pipeline-zichtbaarheid

Dealtags zijn kleurgecodeerde labels die op dealkaarten verschijnen in de boardweergave van HubSpot. Ze geven medewerkers en managers een snel visueel overzicht wanneer ze de pipeline scannen zonder elke deal te hoeven openen.

Met Portant kun je dealtags toevoegen op basis van Document Status, zodat je pipeline-board in één oogopslag laat zien waar elke deal staat in de documentlevenscyclus. Bijvoorbeeld:

  • Een groene tag voor "Signed"-deals
  • Een gele tag voor "Signature Requested"-deals
  • Een rode tag voor "Error"-deals
  • Een blauwe tag voor "Sent"-deals

Dit is vooral nuttig tijdens pipeline-reviews. In plaats van elke deal te openen om de documentvoortgang te controleren, kunnen managers het board scannen en direct deals spotten die aandacht vereisen, of het nu gaat om een vastgelopen handtekening of een fout die er doorheen is geglipt.

Raadpleeg voor installatie-instructies de Portant-handleiding voor het toevoegen van dealtags op basis van documentstatussen.

Randgevallen om rekening mee te houden

Geen enkele automatisering werkt vanaf dag één perfect. Dit zijn de situaties die ik teams zie struikelen, en hoe je ze elk aanpakt.

Meerdere documenten per deal

Een enkele deal kan een offerte, een voorstel en een contract bevatten, elk met een eigen Documentstatus. Als de offerte "Voltooid" is maar het contract "In behandeling", welke status bepaalt dan de dealfase?

Mijn aanbeveling: gebruik de status van het meest recente document als primair signaal. In je workflowregistratie kun je filteren op de documenttemplate of naam als je consistente naamgevingsconventies gebruikt. Dit vergt wat testen, maar als je het goed instelt, voorkom je dat een voltooide offerte de deal voortijdig sluit terwijl het contract nog niet eens is verstuurd.

Opnieuw verstuurde voorstellen

Als een medewerker een voorstel opnieuw verstuurt omdat de koper wijzigingen heeft aangevraagd, doorloopt de Documentstatus zijn waarden opnieuw. Je workflow moet herregistratie ondersteunen, zodat de dealfase correct wordt bijgewerkt wanneer een nieuwe status "Verstuurd" verschijnt voor een ander document.

Houd er rekening mee dat dit een deal terug kan zetten in de pipeline. Als er een nieuw voorstel wordt verstuurd nadat een contract al in behandeling was, kan de deal terugvallen naar "Voorstel verstuurd". Overweeg of je workflows fases alleen voorwaarts mogen verplaatsen en nooit achterwaarts. Voor de meeste teams raad ik een alleen-voorwaartse logica aan, met een aparte, bewuste workflow voor eventuele achterwaartse bewegingen.

Foutstatussen

Een fout betekent niet dat de deal verloren is. Het betekent dat er iets technisch mis is gegaan, zoals een mislukte templatesamenvoeging of een time-out van de ondertekeningsservice. De meldingsworkflow in Workflow 4 is hier je vangnet. Zorg ervoor dat de melding voldoende context biedt voor de medewerker om actie te ondernemen: de naam van de deal, de naam van het document en een verwijzing om de status te controleren in Portant.

Gedeeltelijk ondertekende documenten

Voor contracten met meerdere ondertekenaars is "Gedeeltelijk ondertekend" een nuttige tussenstatus. Je hebt er misschien geen aparte dealfase voor nodig, maar een dealtag zoals "Wacht op handtekeningen" helpt managers bij te houden welke contracten in behandeling zijn versus welke vastlopen op een specifieke ondertekenaar.

Wat dit betekent voor pipelinerapportage

Wanneer dealfases automatisch worden bijgewerkt op basis van echte documentgebeurtenissen, verbeteren er drie dingen.

Nauwkeurigheid van de prognose. Fases weerspiegelen wat er werkelijk is gebeurd, niet wat een medewerker heeft onthouden te loggen. Als je prognosemodel gebruikmaakt van fasekansen, zijn die kansen nu gebaseerd op de werkelijkheid in plaats van op een schatting van de gegevensopschoning van afgelopen vrijdag.

Pipelinesnelheid. Metriek voor tijd-in-fase wordt betekenisvol. Je kunt meten hoe lang het daadwerkelijk duurt van "Voorstel verstuurd" tot "Contract verstuurd", omdat beide overgangen zijn gekoppeld aan documentgebeurtenissen en niet aan handmatige klikken. Dat geeft je echte gegevens over waar deals vertragen.

Pipeline-hygiëne. Verouderde deals worden gemakkelijker te herkennen. Als een deal al twee weken in "Contract verstuurd" staat en de Documentstatus nog steeds "Handtekening aangevraagd" toont, is er iets mis met de deal, niet met de gegevens. Managers kunnen hun pipelinebeoordelingen richten op coaching in plaats van audits van gegevensinvoer.

Je stelt dit eenmalig in, en elke deal die door de pipeline loopt, krijgt een nauwkeurigere fase zonder dat iemand er nog bij hoeft na te denken.

Aan de slag

Als je al gebruikmaakt van Portant met HubSpot, staat de eigenschap Documentstatus al in je documentrecords. Begin met de vier kernworkflows die ik hierboven heb beschreven. Test ze op een aantal deals voordat je ze uitrolt naar het volledige team.

Als je dieper wilt ingaan op hoe fases en documenten conceptueel met elkaar verbonden zouden moeten zijn, lees dan mijn eerdere artikel over het koppelen van dealfases aan documenttypen.

En als je Portant nog niet gebruikt, legt de HubSpot-integratiepagina uit wat het doet en hoe je aan de slag kunt gaan.

Veelgestelde vragen

Werkt dit met elke dealpipeline in HubSpot?

Ja. De workflows worden geactiveerd op basis van de eigenschap Documentstatus van gekoppelde Portant Documentobjecten, die niet gebonden is aan een specifieke pipeline. Je kunt verschillende fasetoewijzingen instellen voor verschillende pipelines via workflowvertakkingen.

Wat als mijn dealfases niet overeenkomen met de voorbeelden?

De toewijzing is volledig flexibel. De voorbeelden die ik heb gebruikt ("Voorstel verstuurd", "Contract verstuurd", "Gewonnen") zijn veelgebruikte labels, maar je moet wijzigingen in de Documentstatus koppelen aan welke fases je pipeline daadwerkelijk gebruikt. Het belangrijkste is dat elke statuswijziging wordt gekoppeld aan een betekenisvolle faseovergang voor jouw proces.

Overschrijft dit handmatige fasewijzigingen?

Dat hangt af van hoe je de workflows instelt. Als een medewerker een deal handmatig naar "Gewonnen" verplaatst voordat het document is ondertekend, zal de workflow dit niet terugdraaien, tenzij je dit specifiek hebt ingesteld. Ik raad aan workflows te bouwen die fases alleen voorwaarts verplaatsen. Als je achterwaartse beweging nodig hebt, voeg dit dan toe als een aparte workflow met extra waarborgen en duidelijke documentatie voor het team.

Kan ik dit ook gebruiken in combinatie met goedkeuringsworkflows?

Ja. Als je team gebruikmaakt van de goedkeuringsworkflow van Portant, wordt de Documentstatus bijgewerkt naar "Goedgekeurd" na interne beoordeling. Je kunt een workflow toevoegen die de deal verplaatst naar een fase zoals "Klaar voor verzending" of "Klaar voor koper" wanneer dat gebeurt. Dit is handig voor teams die goedkeuring van een manager nodig hebben voordat een voorstel naar een klant wordt gestuurd.