Loading
Because three states cannot express a delivery process. Work waiting on a client, work in review and work genuinely being done all read as in progress, so the board says nothing about where the trouble is.
Custom statuses let a project define the states its work really passes through, rather than forcing everything into to-do, doing and done.
Each project or template defines its own set, with each status marked as open, blocked or closed so reporting still works across projects that name things differently.
Two tasks are stalled: one waiting on client sign-off, one blocked by an internal dependency. Separate statuses mean the weekly review chases two different people rather than asking the team about both.
They will not improve a process by naming it. Adding six statuses to a broken workflow produces a well-labelled broken workflow.
Boards column by them, capacity excludes blocked work from a person's live load, and the client portal maps them to states a client can read.
Yes, usually inherited from the template.
Through the open, blocked or closed class each status carries.
Yes — approved, for instance, can require the reviewer role.
Fourteen days, every module, no card. Or half an hour with someone who will run it on your own records and tell you where it does not help.