Every agency has a different workflow. Learn why custom statuses per project beat a one-size-fits-all board, and how to design statuses that reflect reality.
Here's a pattern I see constantly: an agency adopts a project management tool, keeps the default three-column board, and then spends the next six months working around it. Tickets pile up in "In Progress" because there's no "In Review" column. Done tickets sit there for weeks because "Done" means "deployed" to some people and "client approved" to others.
Why defaults fail
Default statuses are designed for the generic case. But agency work isn't generic. A web development project needs different stages than a brand strategy engagement. Even within the same agency, the workflow for a retainer client differs from a fixed-bid project.
Designing good statuses
A good set of statuses answers the question "where is this work right now?" without anyone needing to open the ticket. Some guidelines:
- Keep it linear. Statuses should flow in one direction. If tickets regularly jump backwards, your workflow has a gap.
- Name them after the current state, not the action. "In Review" is better than "Review" because it describes where the ticket is, not what someone should do.
- Five to seven statuses is the sweet spot. Fewer and you lose visibility. More and people stop moving tickets because it's too much friction.
- Include a "blocked" status. Waiting on client feedback? Waiting on API access? A blocked status makes invisible delays visible.
Different projects, different statuses
The key insight is that statuses should be per-project, not global. Your web development project might use Backlog → Design → Development → Code Review → QA → Done. Your content retainer might use Briefed → Drafting → Editor Review → Client Review → Published.
When you stop forcing every project into the same workflow, the board actually becomes useful. People look at it. They move tickets. They trust it as a source of truth.