Statuslabels in workflows zorgen voor duidelijke overdrachten tussen tools. Ontdek 5–7 praktische statussen, wat elke status betekent en hoe je ze consistent houdt op web en mobiel.
Vage statuslabels in workflows veroorzaken verwarring die op drukte lijkt. Mensen schuiven items door, maar niemand weet precies wat er veranderd is. Een ticket met “In Progress” kan betekenen “ik begin erover na te denken”, “ik zit vast”, of “ik ben klaar en wacht op review”, afhankelijk van wie er als laatste aan werkte.
Die mismatch veroorzaakt drie voorspelbare problemen: herkansingen, gemiste overdrachten en lawaaierige notificaties. Als een status niet zegt wat de volgende persoon moet doen, gaat werk heen en weer. Als een overdracht verstopt zit in een vaag label, blijft het liggen totdat iemand het opmerkt. Als iedereen statussen bijwerkt alleen om activiteit te signaleren, wordt je feed een waas en zijn echte veranderingen moeilijk te zien.
Een ander veelvoorkomend symptoom is dat hetzelfde label op verschillende schermen anders gebruikt wordt. De één gebruikt “Ready” als “klaar voor review”, de ander als “klaar om te beginnen”. Een manager die het bord bekijkt, kan niet zien of het team wacht, aan het werk is of klaar is.
Het doel is niet om elke randvoorwaarde te beschrijven. Het doel is om het normale pad duidelijk te maken met minder statussen en helderdere betekenis. Als statussen overal hetzelfde betekenen, krijg je snellere handoffs en minder vragen als “Is dit echt klaar?”.
Als je team niet weet waar te beginnen, mik op 5–7 statussen die het meeste werk dekken: één voor nieuwe items, één voor actief werk, één voor wachtende of geblokkeerde items, één voor review/goedkeuring en één voor klaar. Voeg detail toe alleen nadat de basis stabiel is en iedereen dezelfde betekenissen gebruikt.
Een statuslabel is een gedeelde belofte over wat er hierna gebeurt. Als iemand een status verandert, moet iedereen de volgende stap kunnen voorspellen zonder aanvullende vragen.
Goede statuslabels beschrijven de huidige werkelijkheid van het werk, niet iemands mening erover. Als het label waar is, kan het team zien of het item beweegt, wacht of geblokkeerd is, en wie het daarna moet oppakken.
Een status is niet hetzelfde als prioriteit, eigenaar, categorie of voortgangsnotities. Die velden kunnen belangrijk zijn, maar ze door elkaar gebruiken in de status maakt die onbetrouwbaar.
Het helpt ook om “state” en “stage” te scheiden. State is wat nu waar is (bijv. “Blocked: wacht op reactie klant”). Stage is waar het item in je proces zit (bijv. “review”). Je kunt ze combineren, maar als één status beide probeert te beschrijven, wordt het vaak vaag.
Een nuttige status moet één van drie dingen triggeren:
Eenvoudige realiteitscheck: kan iemand het label lezen in een kleine lijst en toch weten wat hij of zij moet doen? Als het antwoord “dat hangt ervan af” is, verbergt het label waarschijnlijk een beslissing die ergens anders gemaakt moet worden (zoals prioriteitsregels of toewijzing).
Een statussysteem moet het werk in één oogopslag leesbaar maken. Te veel statussen en mensen stoppen met vertrouwen op wat ze zien. Te weinig en je verliest detail dat nodig is om overdrachten te managen.
Voor de meeste teams is 5–7 statussen de gulden middenweg. Het past op één scherm, werkt goed in een Kanban-bord of simpele lijstweergave, en geeft genoeg signaal om de dagelijkse vragen te beantwoorden: wat is geblokkeerd, wat wordt er aan gewerkt, en wat wacht op review.
Het klein houden van de set vermindert ook “status hunting” (raden welke van 12 opties het dichtst in de buurt komt), maakt rapportage makkelijker en dwingt je om prioriteit, eigenaar en type als aparte velden te houden.
De namen kunnen verschillen, en dat is prima. Het belangrijkste is dat de betekenis niet varieert. Als “In Review” soms “wachten op QA” betekent en andere keren “wachten op een klant”, wordt je bord ruis.
Om betekenissen consistent te houden, zet één bron van waarheid op: een kort teamdocument met elke status, wat het betekent en de regels voor wanneer iets in- en uit die status gaat. Houd het kort genoeg om in twee minuten te lezen. Gebruik diezelfde set statussen overal waar je werk toont.
Als je statussen wilt die op termijn duidelijk blijven, begin dan met een kleine set die drie vragen beantwoordt: wie is er nu eigenaar, wat gebeurt er daarna, en wat betekent “klaar”.
Hier is een eenvoudige set van 7 statussen die voor de meeste teams werkt zonder te veel detail:
| Status | Wat het betekent (in gewone taal) | Standaard eigenaar | Volgende stap |
|---|---|---|---|
| New | Het verzoek is vastgelegd, maar niemand heeft het nog beoordeeld. | Request triage (lead/PM) | Beoordeel en beslis: direct doen, inplannen of afwijzen. |
| Triaged | Het is beoordeeld en gerouteerd (bug vs feature), en het team bevestigt dat het geldig is. | Lead/PM | Verduidelijk scope en beslis of het de moeite waard is. |
| Ready | Het kan gestart worden zonder ontbrekende info of afhankelijkheden. | Lead/PM | Wijs een eigenaar toe en start het werk. |
| In Progress | Iemand werkt er actief aan. | Assignee | Ga door totdat het klaar is om gecontroleerd te worden. |
| In Review | Het werk is voldoende voltooid om te controleren (peer review, QA, stakeholdergoedkeuring). | Reviewer | Keuren of terugsturen met duidelijke aantekeningen. |
| Blocked | Het werk kan niet doorgaan vanwege een specifieke afhankelijkheid. | Assignee | Verwijder de blokkade of escaleer naar degene die het kan oplossen. |
| Done | Het voldoet aan de afgesproken definitie van klaar en vereist geen actie meer. | Niemand | Bewaren voor rapportage; heropenen alleen met een nieuwe reden. |
Belangrijk: gebruik niet alleen “Waiting”. Als iets vastzit, noem het Blocked en benoem de afhankelijkheid in de notitie (bijv. “Blocked: reactie klant” of “Blocked: toegang verleend”).
Duidelijke statuslabels werken het beste wanneer elk antwoordt op de simpele vraag: wat is er nu waar?
New
Wat waar is: het item is vastgelegd, maar niemand heeft het nog beoordeeld.
Wat niet waar is: prioriteit, scope of eigenaar zijn afgesproken.
Entry: een verzoek is ingediend.
Exit: iemand leest het en zet het op Triaged.
Voorbeeld: “Een supportmedewerker logt een bugrapport met één screenshot.”
Triaged
Wat waar is: het team begrijpt het verzoek genoeg om het te routeren en te bevestigen dat het geldig is.
Wat niet waar is: het is klaar om te starten.
Entry: iemand voegt basiscontext toe (samenvatting, impact, getroffen onderdeel).
Exit: het wordt voorbereid voor werk (Ready) of bewust afgewezen (buiten de workflow afgehandeld).
Voorbeeld: “De PM markeert het als een echte bug en noteert reproduceerstappen.”
Ready
Wat waar is: het kan gestart worden zonder ontbrekende info.
Wat niet waar is: het werk is begonnen.
Entry: acceptatiecriteria zijn duidelijk en afhankelijkheden zijn geregeld.
Exit: iemand start en doet de eerste betekenisvolle wijziging (In Progress).
Voorbeeld: “De velden van het formulier en validatieregels zijn afgesproken.”
In Progress
Wat waar is: er wordt actief aan gewerkt.
Wat niet waar is: het wacht in een wachtrij.
Entry: iemand pakt het op en begint te werken.
Exit: het is voldoende af om gecontroleerd te worden (In Review) of het loopt vast op een afhankelijkheid (Blocked).
Voorbeeld: “Een developer bouwt de nieuwe statusdropdown en slaat de logica op.”
In Review
Wat waar is: het wordt gecontroleerd (peer review, QA of stakeholdergoedkeuring).
Wat niet waar is: er worden nog nieuwe features toegevoegd.
Entry: de uitvoerder dient het in voor verificatie.
Exit: het is goedgekeurd en voldoet aan de definitie van klaar (Done), of het gaat terug met feedback (In Progress).
Voorbeeld: “QA bevestigt dat het op zowel web als mobiel werkt.”
Blocked
Wat waar is: werk kan niet doorgaan vanwege een specifieke, benoemde afhankelijkheid.
Wat niet waar is: het item heeft simpelweg een lagere prioriteit.
Entry: de toegewezen persoon stuit op een afhankelijkheid die hij/zij niet alleen kan oplossen.
Exit: de afhankelijkheid is verwijderd en het werk gaat verder (meestal In Progress).
Voorbeeld: “Blocked: wacht op toegang tot production logs.”
Done
Wat waar is: het voldoet aan afgesproken acceptatiecriteria en is (klaar om te) worden uitgezet.
Wat niet waar is: het heeft nog review, testing of follow-up nodig.
Entry: review is geslaagd en release-stappen zijn afgerond (volgens de teamdefinitie).
Exit: geen; heropenen start een nieuwe cyclus met een duidelijke reden.
Voorbeeld: “De fix staat live en de bug is niet meer reproduceerbaar.”
Je kunt rommelige statussen in één gerichte meeting oplossen. Het doel is geen perfect model, maar een gedeelde set labels die overeenkomt met hoe werk echt beweegt, met regels die je team kan herhalen.
Neem één persoon van elke rol die met het werk te maken heeft (aanvrager, uitvoerder, reviewer, goedkeurder). Deel een scherm met je huidige bord of lijst.
Traceer eerst de echte workflow (niet de ideale). Kies één typisch item en volg wat er daadwerkelijk gebeurt, inclusief wachttijd. Schrijf de stappen op als simpele werkwoorden (“opstellen,” “reviewen,” “goedkeuren”). Als een stap soms voorkomt, noteer het als een tak.
Vervolgens: verwijder duplicaten en hernoem onduidelijke labels. Merge labels die hetzelfde betekenen (“In Progress” vs “Doing”). Hernoem vage labels (“Pending”) naar iets waarop je kunt handelen (“Blocked: reactie van klant”). Als je een label niet in één zin kunt uitleggen, is het nog niet klaar.
Voeg daarna definities toe met entry- en exitregels. Voor elke status, schrijf wat waar moet zijn om erin te komen en wat waar moet zijn om eruit te gaan. Houd het kort. Voorbeeld: “In Review begint wanneer werk is ingediend, en eindigt wanneer feedback is verwerkt en de reviewer goedkeurt.”
Wijs daarna eigenaren toe voor elke overdracht. Elke status moet een standaard eigenaar hebben (een rol is prima). Dat voorkomt dat items vastlopen. Voorbeeld: items in “In Review” zijn eigendom van de reviewer, niet van degene die het werk deed.
Test tenslotte op 10 recente items en pas aan. Pak 10 afgeronde of actieve items van de laatste weken en ken elk een status toe op elk tijdstip. Als je vaak discussieert, overlappen je labels. Als je een item niet kunt plaatsen, mis je een status of mix je twee ideeën in één.
Na de meeting publiceer je de definities op één plek en zorg je dat de labels overal overeenkomen met wat mensen zien.
Als een status op het web iets anders betekent dan op mobiel, verliezen mensen het vertrouwen. Ze gaan in chat vragen, details opnieuw controleren of creëren hun eigen “echte status” in opmerkingen. Het doel van statuslabels is gedeelde waarheid, niet decoratie.
Behandel de status als één gedeeld veld met één bron van waarheid. Hetzelfde label moet met dezelfde spelling, hoofdletters en betekenis overal voorkomen: lijsten, detailschermen, notificaties, exports en pushberichten.
Mobiele schermen vergeven geen lange namen en zwakke visuele keuzes. Een status die op desktop prima is, kan op een telefoon een afgekapt, verwarrend badge worden.
Plaatsing doet er ook toe. Zet de status bij de titel in de detailweergave zodat het zichtbaar is voordat iemand de volledige beschrijving leest. In lijstweergaven, toon het altijd op dezelfde plek.
Toegankelijkheidsbasis helpt iedereen. Kleur is een hint, niet de boodschap. Toon altijd het tekstlabel en overweeg een simpel icoon (zoals een vinkje voor Done) zodat mensen met screenreaders of kleurenzienstoornissen de betekenis snel krijgen.
Statussen drijven af wanneer ze niet meer betekenen “waar het werk is” maar “hoe mensen zich voelen over het werk.” Zodra dat gebeurt, ziet je bord er druk uit maar is niemand het vertrouwen.
Een veeloorzaak is te veel labels die elk klein stapje matchen. Als een taak drie keer per uur kan bewegen, stoppen mensen met bijwerken of kiezen ze een “ongeveer goed” status. Een kleine set werkt het best als elke beweging een echte verandering in gereedheid of verantwoordelijkheid is.
Een ander knelpunt is het mengen van verschillende dimensies in één veld. Prioriteit en urgentie zijn belangrijk, maar horen in aparte velden, niet in de status. Als “Urgent” een status wordt, concurreert het met “In Review” en wordt je rapportage zinloos.
Let op deze patronen:
Om drift te voorkomen, wijs één eigenaar aan voor de set statussen en maak wijzigingen zeldzaam. Als je iets verandert, noteer wat er veranderde, waarom en wat het vervangt.
Een klant schrijft naar support: “Op mobiel toont de bestelgeschiedenispagina een lege staat terwijl ik bestellingen heb.” Support legt één item vast dat een productfix en later een release wordt.
New: Support voegt screenshots, apparaatdetails en wat “correct” zou moeten zijn toe.
Triaged: De producteigenaar bevestigt dat het een echte bug is, kiest waar het thuishoort (mobile app, niet backend) en verduidelijkt de impact.
Ready: Reproduceerstappen zijn bevestigd en acceptatiecriteria zijn duidelijk.
In Progress: Een engineer reproduceert het probleem, ontdekt dat de API data terugstuurt maar het scherm het verkeerd filtert, en begint de fix.
Blocked: De engineer ontdekt dat de UI afhangt van een veld dat ontbreekt in oudere accounts en heeft een backendwijziging nodig. Het item wordt Blocked met een duidelijke notitie: "Blocked: backend needs legacy field mapping." (noteer de afhankelijkheid).
In Review: Nadat de afhankelijkheid is opgelost, controleert QA op iOS en Android en verifieert dat de lege staat alleen verschijnt wanneer er echt geen bestellingen zijn.
Done: De fix is goedgekeurd en uitgerold (of ingepland voor het volgende releasevenster, als dat voor jouw team als done telt). Support bevestigt dat het live is en antwoordt de klant.
Merk op wat verwarring voorkomt: “Blocked” heeft één reden en één volgende actie, en eigenaarschap blijft stabiel. Iedereen kan het item openen en begrijpen wie de bal heeft.
Als je bord rommelig aanvoelt, zie je meestal binnen 10 minuten waarom.
Loop het bord door en let op deze signalen:
Als mensen het oneens zijn over waar een kaart hoort, overlappen statussen elkaar of zijn ze niet genoeg gedefinieerd.
Open dezelfde workflow op een telefoon en controleer of de labels nog werken in krappe ruimtes.
Statussystemen blijven nuttig als je ze behandelt als een regelboek: stabiel, maar te herzien. Het doel is geen constante verandering, maar consistente toepassing.
Plan een lichte cadans, zoals een maandelijkse review van 30 minuten met één persoon uit elke rol die het bord raakt. Neem 5–10 recente items mee en zoek naar uitzonderingen die je kunt oplossen.
Een paar eenvoudige signalen om bij te houden:
Als iets niet goed voelt, voeg dan niet meteen een nieuwe status toe. Voeg alleen een status toe als de nieuwe toestand echt anders is, verandert wat mensen daarna doen en vaak voorkomt. Meestal is de oplossing eenvoudiger: verscherp de definitie, voeg een entry-regel toe of verduidelijk eigenaarschap.
Als je de workflow in een intern hulpmiddel bouwt, behandel statussen als gedeelde data in plaats van schermspecifieke tekst. In AppMaster (appmaster.io), bijvoorbeeld, kun je het statusveld één keer definiëren in de Data Designer en hergebruiken in web- en native mobiele apps, wat helpt voorkomen dat "op mijn telefoon betekent het iets anders" drift optreedt.
What’s a good number of workflow statuses for a team?Begin met 5–7 statussen die het normale verloop dekken: bijvoorbeeld New, Ready, In Progress, In Review, Blocked en Done. Laat elke status één duidelijke betekenis hebben en gebruik de status niet om prioriteit of persoonlijke notities uit te drukken.
How do I know if a status label is actually “clear”?Een status moet iemand vertellen wat er nu waar is en wat er daarna gebeurt zonder extra overleg. Als een label geen volgende eigenaar, volgende actie of een duidelijke wachtoorzaak impliceert, is het te vaag om nuttig te zijn.
Should we use “Waiting” or “Blocked”?Gebruik "Blocked" wanneer werk niet door kan gaan vanwege een specifieke afhankelijkheid en noteer die afhankelijkheid in het ticket. "Waiting" is meestal te vaag omdat het verbergt waar je op wacht en wie de volgende stap moet zetten.
What should “Ready” mean in practice?"Ready" betekent dat het item direct gestart kan worden zonder ontbrekende informatie; het behoort vaak tot degene die triage doet en de backlog voedt. Als er nog vereisten, toegang of beslissingen ontbreken, is het nog niet Ready.
How do we stop “In Progress” from becoming a parking lot?"In Progress" mag alleen aangeven dat er actief aan gewerkt wordt, niet dat iemand er even naar heeft gekeken of dat het simpelweg toegewezen is. Als het stil staat of op input wacht, verplaats het naar Blocked of naar een eerdere status.
Do we really need entry and exit rules for statuses?Schrijf één zin per status: wat moet waar zijn om erin te komen en wat moet waar zijn om eruit te gaan. Houd het kort en behandel het als het gedeelde regelboek voor iedereen die met de workflow werkt.
How do we keep status meanings consistent across web and mobile?Kies één canonieke set statuswaarden en hergebruik hetzelfde veld overal: web, mobiel, notificaties en exports. Als verschillende schermen statussen hernoemen of anders ordenen, verliezen mensen vertrouwen in de workflow en bedenken ze hun eigen betekenissen.
What status naming tips matter most for mobile screens?Houd labels kort, bij voorkeur één of twee woorden, zodat ze niet afgekapt worden in lijsten. Zorg dat de tekst op zichzelf duidelijk is, want kleur kan op kleine schermen gemist of anders weergegeven worden.
What’s the fastest way to redesign our statuses as a team?Kies één typisch item en traceer wat er daadwerkelijk gebeurde van request tot done, inclusief wachttijden. Merge dubbele labels, hernoem vage labels naar actiegerichte termen, voeg entry/exit-regels toe, wijs standaard-eigenaren toe, test op 10 recente items en pas aan.
How can a no-code tool help prevent status drift over time?Behandel de status als gedeelde data, niet als schermtekst, zodat elke interface dezelfde bron gebruikt. In AppMaster (appmaster.io) kun je bijvoorbeeld één statusveld in het datamodel definiëren en hergebruiken in web- en native apps om drift tussen schermen te verminderen.
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.
