Stages are the smallest piece of structure that makes everything else possible. Without them you cannot answer "where is this?" consistently, you cannot promise an update cadence, and you have nothing to show a client. With them, all three become nearly free.
The default five
| # | Stage | Means | Waiting on |
|---|---|---|---|
| 1 | Received | Work is booked, not started | You |
| 2 | In progress | Actively being worked on | You |
| 3 | Waiting on client | Paused pending something from them | Them |
| 4 | In review | Done, being checked or approved | You or them |
| 5 | Complete | Delivered and closed | Nobody |
The one stage people leave out is the third, and it is the most valuable of the five. Separating "we are working on it" from "we are stuck waiting on you" is what lets you see, in one glance, which files are your problem and which are not β and it makes the difference visible to the client too, which quietly ends a category of complaint.
Naming rules
A client should read it without explanation
"In review" passes. "QA2", "Stage 3" and "Pending PM" do not. If you have to explain it, it is an internal code, not a stage.
Name the state, not the task
"Waiting on documents" describes where the file is. "Chase client" describes what you should do. Stages are locations; tasks belong elsewhere.
Say who is holding it
The best stage names make the answer to "whose move is it?" unambiguous. That single fact prevents most status questions.
Keep two labels where useful
Your team can keep precise internal names while the client sees a plain one. Both stay accurate and neither is compromised for the other.
| Internal | What the client sees |
|---|---|
| Intake β docs pending | Waiting on your documents |
| Prep β first pass | In progress |
| Partner review | In review |
| Awaiting client sign-off | Waiting on your approval |
| Filed / delivered | Complete |
Worked examples by industry
Each of these is the default five, renamed. None adds more than one stage β the point is that most businesses need vocabulary changes rather than structural ones.
| Business | Stages |
|---|---|
| Bookkeeping | Docs requested β Reconciling β Waiting on client β Review β Closed |
| Tax preparation | Intake β Preparing β Waiting on client β Ready to file β Filed |
| Mortgage brokerage | Application received β Document review β Waiting on docs β With the lender β Funded |
| Immigration support | Intake β Preparing application β Waiting on documents β Submitted β Decision received |
| Business formation | Intake β Name search β Waiting on signatures β Filed with registry β Complete |
| Claims administration | Claim opened β Gathering paperwork β Submitted to insurer β Insurer query β Settled |
| Design studio | Brief received β In progress β Your approval β Waiting on assets β Delivered |
| Consulting | Scoping β Discovery β Milestone review β Final report β Closed |
When to add a stage
Add one only when a missing stage has actually cost you something β a file that sat in "in progress" for three weeks because nobody could see it was really waiting on a third party, or a review step that keeps being skipped because it is not visible.
- Add when two genuinely different situations are hiding inside one stage.
- Add when you repeatedly need a filter that does not exist β "show me everything at the lender".
- Do not add to record work you did; that is history, not state.
- Do not add because one client asked for more granularity; that is a communication problem, not a workflow one.
Rolling it out to work already in flight
The usual reason a stage list fails is not the design β it is that it was applied to new work only, so for months you have two systems and the old one keeps winning. Existing files need assigning in one sitting.
List every open file
Every one, including the awkward dormant ones. The dormant files are the whole point: they are the ones quietly costing you a client relationship.
Assign a stage in one pass
Do not think hard. First instinct is right, and a wrong stage is fixed the moment someone looks at the file. An hour for thirty files is normal.
Look at what landed in "waiting on client"
This is the useful output. Files sitting there for weeks are ones the client is also waiting on, usually believing the ball is with you.
Send one update per file
Then send a short update on everything in that stage. This single pass typically clears more stuck work than the next month of normal activity.
That last step is worth doing even if you adopt nothing else here. Assigning stages surfaces the files that went quiet, and files that went quiet are where client relationships are lost β not through bad work, but through silence nobody noticed.
Setting it up
A stage list you will still be using in six months
- Three to six stages, written down in one place
- At least one stage that means "waiting on the client"
- A plain client-facing label for every stage
- Every active file assigned to a stage today, with no exceptions
- One person clear on who moves a file, and when
- The list applied to every client, not customised per engagement