Een status lijkt vaak een klein veld in een portaal of interne applicatie. Toch bepaalt dat veld voor een groot deel of gebruikers vertrouwen hebben in het proces. Is een aanvraag nog in behandeling? Is een contract verzonden of al ondertekend? Is een zending ontvangen, gecontroleerd of afwijkend?
In maatwerk software worden statussen vaak pas laat concreet gemaakt. Eerst gaat het over schermen, rollen, koppelingen en dashboards. Maar zodra teams ermee gaan werken, blijkt het statusmodel de ruggengraat van de applicatie. Het stuurt acties, notificaties, rapportages en verwachtingen.
In dit artikel lees je hoe je workflowstatussen ontwerpt die logisch blijven wanneer processen groeien. Met voorbeelden uit logistiek, contractflows, klantportalen en interne tickets.
Een goed statusmodel begint niet bij techniek, maar bij gedeeld begrip van het proces.
Waarom workflowstatussen zo belangrijk zijn
Workflowstatussen geven context. Ze vertellen niet alleen waar een object staat, maar ook wat de gebruiker ermee kan doen. Denk aan een order, ticket, contract, zending, aanvraag of AI-concept.
Een goede status beantwoordt drie vragen:
- Wat is er gebeurd? Bijvoorbeeld: een document is verzonden, een zending is ontvangen of een concept is gegenereerd.
- Wat moet er nu gebeuren? Bijvoorbeeld: controleren, aanvullen, goedkeuren, ondertekenen of afhandelen.
- Wie is aan zet? Bijvoorbeeld: de klant, de backoffice, de planning, de accountmanager of een extern systeem.
Als die drie vragen niet duidelijk zijn, gaan gebruikers het proces zelf interpreteren. Dan ontstaan losse Excel-lijsten, extra chatberichten, dubbele controles en handmatige follow-ups. Precies de dingen die maatwerk software juist moet verminderen.
Daarom is een statusmodel geen detail. Het is procesontwerp in compacte vorm.
Veelgemaakte fouten bij statusmodellen
Statussen lopen vaak vast omdat ze organisch groeien. Er komt een uitzondering bij, daarna een extra team, daarna een koppeling met een extern systeem. Voor je het weet bestaan er twintig statussen waarvan niemand meer precies weet wanneer ze gebruikt worden.
Dit zijn de fouten die we vaak zien:
- Statussen beschrijven acties in plaats van toestand. Bijvoorbeeld: mail sturen als status. Dat is een actie, geen duurzame processtand.
- Statussen zijn te technisch. Een gebruiker ziet bijvoorbeeld api_pending, terwijl hij wil weten of hij moet wachten of ingrijpen.
- Statussen overlappen. Bijvoorbeeld: in behandeling, wordt verwerkt en onder review, zonder duidelijke grens.
- Uitzonderingen krijgen geen eigen plek. Afwijkingen worden dan verstopt in opmerkingen, waardoor rapportage en opvolging lastig worden.
- Iedere rol ziet hetzelfde. Een interne medewerker heeft andere informatie nodig dan een klant in een portaal.
De oplossing is niet altijd minder statussen. De oplossing is vooral scherpere betekenis. Elke status moet een functie hebben in het proces.
Statussen worden pas echt waardevol wanneer ze ook rapportage en sturing mogelijk maken.
Statussen zijn iets anders dan acties
Een belangrijk onderscheid: een status beschrijft de huidige toestand, een actie verandert die toestand.
Bij een contractflow kan een contract bijvoorbeeld de status concept, verzonden of ondertekend hebben. Acties zijn dan: genereren, verzenden, herinnering sturen of archiveren. Bij een logistieke flow kan een zending aangemeld, ontvangen, gecontroleerd of afwijkend zijn. Acties zijn dan: scannen, foto toevoegen, afwijking registreren of vrijgeven.
Als je acties en statussen door elkaar haalt, wordt de workflow onduidelijk. Gebruikers weten dan niet of iets al is gebeurd, nog moet gebeuren of alleen mogelijk is.
Een praktisch ontwerpprincipe:
- Beschrijf eerst de toestanden die relevant zijn voor de gebruiker.
- Bepaal daarna welke acties een status mogen veranderen.
- Leg per actie vast welke rol die actie mag uitvoeren.
- Bepaal welke notificaties of koppelingen daardoor worden gestart.
Zo voorkom je dat statussen een losse lijst worden. Ze vormen samen een bestuurbare workflow.
Ontwerp uitzonderingen bewust
In veel processen gaat het niet mis op de ideale route, maar op de uitzonderingen. Een zending mist gegevens. Een contract wordt niet ondertekend. Een AI-concept moet opnieuw worden beoordeeld. Een ticket kan niet worden afgehandeld omdat informatie ontbreekt.
Als je uitzonderingen niet ontwerpt, verdwijnen ze in vrije tekstvelden. Dat voelt flexibel, maar maakt het proces moeilijk te beheren. Niemand kan eenvoudig zien hoeveel items vastlopen, waarom dat gebeurt en wie moet ingrijpen.
Maak daarom onderscheid tussen normale voortgang en uitzonderingsstatussen. Bijvoorbeeld:
- Wacht op klant, wanneer externe input nodig is.
- Afwijking gevonden, wanneer controle een probleem oplevert.
- Hercontrole nodig, wanneer een stap opnieuw moet worden uitgevoerd.
- Geannuleerd, wanneer het proces bewust stopt.
Let op dat je niet voor elke kleine variatie een nieuwe status maakt. Soms hoort detailinformatie in een redenveld, categorie of logboek. De status blijft dan de hoofdlijn, terwijl de oorzaak apart wordt vastgelegd.
In logistieke processen is dit extra belangrijk. In een flow met pre-registratie, scanning en fotologs wil je snel kunnen zien welke zendingen normaal doorlopen en welke aandacht vragen. Lees ook hoe dit werkt in de praktijk bij pre-registratie, scanning en fotologs in logistiek.
Een statusmodel moet eenvoudig genoeg zijn voor dagelijks gebruik en precies genoeg voor uitzonderingen.
Rollen bepalen welke statusinformatie zichtbaar is
Een status heeft niet voor iedere gebruiker dezelfde betekenis. Een interne medewerker wil weten welke acties beschikbaar zijn. Een klant wil vooral weten of hij moet wachten of iets moet aanleveren. Een manager wil zien waar vertraging ontstaat.
Daarom ontwerp je workflowstatussen samen met rollen en rechten. Niet iedereen hoeft dezelfde statusnaam, detailinformatie of actieknoppen te zien.
Een voorbeeld uit contractmanagement: intern kan een contract verschillende technische stappen doorlopen, zoals aanmaken, aanbieden bij Signhost, wachten op ondertekening en verwerken na retourmelding. Voor de eindgebruiker kan dat eenvoudiger worden weergegeven als concept, verzonden en ondertekend. De interne workflow blijft precies, terwijl het portaal helder blijft.
Meer over dat soort koppelingen lees je in het artikel over Signhost-integratie in contractmanagement.
Een goed statusmodel houdt dus rekening met twee lagen:
- Interne processtatussen, voor sturing, rechten, logging en koppelingen.
- Gebruikersgerichte statussen, voor duidelijke communicatie in portalen en dashboards.
Notificaties: stuur alleen wanneer het gedrag verandert
Niet elke statuswijziging verdient een notificatie. Te veel meldingen zorgen voor ruis. Te weinig meldingen zorgen voor onzekerheid en handmatige opvolging.
Een nuttige regel: stuur een notificatie wanneer iemand iets moet weten om ander gedrag te vertonen. Bijvoorbeeld wanneer een klant moet ondertekenen, een planner een afwijking moet beoordelen of een supportmedewerker een ticket kan afronden.
Stel bij elke statusovergang deze vragen:
- Wie moet hiervan op de hoogte zijn?
- Moet die persoon iets doen, of is de melding alleen informatief?
- Is directe notificatie nodig, of volstaat een dashboard of dagoverzicht?
- Moet de notificatie ook naar een extern systeem, bijvoorbeeld via een API-koppeling?
Zo voorkom je dat notificaties een tweede proceslaag worden naast de workflow. Ze ondersteunen de status, in plaats van deze te vervangen.
Rapportage vraagt om stabiele statusdefinities
Statussen zijn niet alleen handig voor gebruikers. Ze vormen ook de basis voor rapportage. Hoeveel aanvragen wachten op goedkeuring? Waar ontstaan afwijkingen? Hoe lang blijven tickets open? Hoeveel contracten zijn verzonden maar nog niet ondertekend?
Daarvoor moeten statusdefinities stabiel zijn. Als teams dezelfde status anders gebruiken, wordt rapportage onbetrouwbaar. Als statussen te vaak wijzigen zonder migratie of mapping, kun je trends moeilijk vergelijken.
Leg daarom per status minimaal vast:
- De betekenis van de status.
- Welke status ervoor en erna kan komen.
- Welke rol verantwoordelijk is.
- Welke acties toegestaan zijn.
- Welke momenten worden gelogd voor rapportage.
Bij AI-ondersteunde processen is dit net zo belangrijk. Als een portaal AI-concepten genereert, wil je bijvoorbeeld onderscheid maken tussen concept aangemaakt, klaar voor controle, aangepast en definitief gebruikt. Anders wordt het lastig om te zien waar menselijke beoordeling nodig is. Lees meer over dit type proces in het artikel over het Equaflor-portaal met AI-jobs.
Een praktisch stappenplan voor je statusmodel
Een statusmodel ontwerp je het best samen met de mensen die het proces dagelijks uitvoeren. Niet alleen met management of alleen met development. Je hebt proceskennis, gebruikersperspectief en technische haalbaarheid nodig.
Gebruik dit stappenplan als basis:
- Breng de hoofdobjecten in kaart, zoals order, contract, ticket, zending of aanvraag.
- Beschrijf de ideale route van begin tot eind in gewone taal.
- Noteer per stap wat de gebruiker moet weten en doen.
- Maak onderscheid tussen toestand, actie, reden en opmerking.
- Ontwerp uitzonderingen die rapportage of opvolging nodig hebben.
- Bepaal per rol welke statussen en acties zichtbaar zijn.
- Koppel notificaties alleen aan relevante statusovergangen.
- Controleer of externe systemen dezelfde betekenis gebruiken.
- Test het model met echte scenario’s, inclusief randgevallen.
Dit past bij hoe wij maatwerk software benaderen: eerst het proces scherp krijgen, daarna pas bouwen. Bekijk ook onze pagina over bedrijfsprocessen automatiseren en onze aanpak.
Wanneer is je statusmodel goed genoeg?
Een statusmodel hoeft niet perfect te zijn voordat je begint. Het moet goed genoeg zijn om het proces betrouwbaar te sturen en eenvoudig genoeg zijn om te begrijpen.
Je zit meestal goed wanneer gebruikers zonder uitleg kunnen zien wat er aan de hand is, wanneer ontwikkelaars de overgangen eenduidig kunnen bouwen en wanneer managers bruikbare rapportage krijgen. Als één van die drie groepen steeds extra toelichting nodig heeft, is het model waarschijnlijk te vaag of te complex.
Workflowstatussen zijn daarmee een vroeg ontwerpbesluit met langdurige impact. Ze bepalen hoe soepel een portaal, orderflow, contractflow of interne applicatie voelt in dagelijks gebruik.
Wil je sparren over een workflow die nu te veel handwerk, uitzonderingen of onduidelijke statussen bevat? Neem dan contact op met House of Devs. Dan kijken we samen waar het proces scherper en slimmer kan.
