When you set up a deadline tracker, the statuses look like the easy part: two or three labels and you are done. They are also the first thing you end up rebuilding, usually a few months in, when you notice that half your deadlines are stuck on the same status and you can no longer tell what is going on.
The problem is not how many statuses you have. It is that they tell the story of the renewal from the wrong angle — the service’s, rather than the work you actually have to do.
A set of statuses that holds up over time has a single quality: looking at it, you know what to do today without opening anything else.
A status is not a label, it is a decision already made
The temptation is to use statuses to describe the service: active, expired, suspended. It looks tidy and it serves no purpose, because the date already tells you that. If the deadline is two months away the service is active, and you do not need a label to know it.
Useful statuses describe something else: where you stand with that entry. Have you notified the client? Once or twice? Did you renew and cover the cost yourself? Have you been paid? Each of these is a question you answer dozens of times a month, and every time the answer is not in the system you have to go looking for it in an inbox.
Hence the criterion: a status deserves to exist if changing it changes something you have to do. If nothing changes, it is a note, and notes belong in the notes field.
The set that holds up, and why it is built this way
In practice, six statuses cover almost everything:
- To renew — the deadline has come close enough to fall within your reach. It is the starting status, and entries get there on their own.
- Notified — the client has been told. From that moment the ball is in their court, which is different information from “about to expire”.
- Notified twice — the first notification produced nothing. It is the status that flags an entry turning into a problem while it is still early to treat it as one.
- Awaiting payment — the service has been renewed, the money has gone out, the client has not paid yet. It is the most important row in the system, because it is the one where you are covering the cost.
- Paid — closed. The entry drops out of the count of what you are owed.
- Canceled — the service is not being renewed. That is not a failure: it is a decision, and it should be recorded as one instead of leaving the row to rot.
What is worth noticing is that four of the six talk about communication and money, not about services. That is why they hold up: those are the only things that genuinely change from one day to the next.
Why does the second reminder need a status of its own?
This is the choice that looks most debatable and that, in practice, solves the most problems. Without a second level, “notified” becomes a container holding both the client told yesterday and the one who has ignored three emails over a month, and the two cases call for opposite behaviour.
With two levels you get an objective threshold for stopping the emails and picking up the phone. It is also the point where it makes sense to decide whether to renew anyway and cover the cost, or wait: a decision that would be premature at the first notification and too late at the third.
And if you find the second level always stays empty, that is useful information too: it means your clients respond to the first notification, and you can simplify.
Statuses that look useful and are not
“In progress” is the most common one. It sounds sensible, and in practice it collects everything you do not know where to put, until it becomes the fullest column and the least readable. Same fate for “to check”: it describes a doubt of yours, not the state of the entry.
Then there are the statuses that duplicate information already held elsewhere. “Expired” you get from the date. “Recurring” is a property of the deadline, not a status. “Client in arrears” is a characteristic of the client, and putting it on a single entry means having to update it in ten places.
The practical rule: if a status goes unused across a month of work, remove it. If a status holds half your entries, split it in two.
Statuses have to make something move
As long as you move statuses by hand, they will lag behind — it is a law of nature for deadline trackers. They become reliable only when something moves them for you: the approaching deadline brings an entry into “to renew”, sending the notification moves it to “notified”, recording the payment moves it to “paid”.
The other half of it is that statuses have to feed numbers, otherwise they stay decorative. Add up the amounts of the entries to renew, notified and awaiting payment and you get what you expect to bring in; add up the paid ones and you get what has actually come in. Two figures nobody works out by hand, and they belong at the top of the screen.
What are the most common mistakes with deadline statuses?
- Describing the service instead of your own work. Active, suspended, expired: information you already have.
- Confusing “renewed” with “paid”. They are the two ends of the window in which you are covering the cost, and keeping them together makes that window invisible.
- Adding a status every time an odd case comes up. A year later there are fifteen and nobody uses them.
- Never closing the entries you have canceled, and dragging along dead rows that skew every total.
- Moving everything by hand. A status updated from memory is worse than no status at all, because you end up trusting a figure that is wrong.
Where do you start setting up statuses?
- List the questions you actually ask yourself when looking at a deadline. There are four or five of them, and those are your statuses.
- Start with the short set and only add to it once you have seen a real case that does not fit.
- Give each one a colour, keeping the warm tones for the statuses that need action from you. It lets you read the list without reading it.
- Decide what moves each status: which event takes an entry to the next one. If the answer is “me”, that transition will be skipped sooner or later.
- Look at the totals by status once a week. If you are still on a spreadsheet, the comparison with a proper deadline tracker explains where it breaks down; the full setup is in how to organise a client deadline tracker in a web agency.
How do we set up statuses ourselves?
The six statuses above are the ones Dotify starts with — the deadline tracker we built for ourselves at EnneStudio, and it is our own tool. They are not a theory: they are what was left after removing, over time, every status that did not make anything move.
They stay editable, because the right set depends on how you work: you can rename them, change their colour, add some or take some away. What mattered to us was that they moved on their own — the notification rules take an entry from “paid” to “to renew” as the deadline approaches, and from “to renew” to “notified” when the notification goes out — and that they fed the two totals at the top: expected revenue and revenue received.
If you want to see how they are configured, the documentation on deadline management goes into detail, and the one on notifications and emails explains what moves what.
