Remembering to chase the things other people owe you
The invoice, the reply, the review. Waiting-on items have no natural moment to be written down, which is why organised people still forget them.
There is a specific kind of forgetting that gets people who are otherwise organised. You do your bit — send the invoice, submit the application, ask the question, request the review — and then it is out of your hands, and you stop thinking about it.
Three weeks later you find out nobody did anything.
This is not a discipline failure. It is a structural one, and it has a specific cause: a waiting-on item has no moment at which you would naturally write it down. When you send the invoice, the invoice is done. That is the completion, and completions do not prompt you to create work. The follow-up only becomes obvious later, at which point you have already forgotten.
The usual answers and where they leak
A to-do item. Works if you make it. You have to remember, at the moment of finishing something, that finishing it creates a future obligation — and that is exactly the moment your attention is leaving.
Email flags and snooze. Genuinely good if the thing lives in email. Useless if it lives in a web app, which most of them now do: the invoice is in a billing tool, the pull request is on GitHub, the application is on a portal, the ticket is in a helpdesk.
Remembering. No.
The pattern with all three is the same: the follow-up needs to be created at the moment of completion, and it needs to point at the page where you will actually check.
Declare the follow-up when you create the original
The approach that fixed it for me is to write the follow-up in advance, attached to the thing that triggers it, and let it appear when I finish the first thing.
“Apply for this job” on Friday, and “did they reply?” a week after you actually apply — which might be Friday, might be the following Tuesday, because you might not do it on time.
In Latr, a reminder can carry a follow-up: you declare it on the original, and it is created when you mark that one done. Not when it fires — when you finish it. That distinction is the whole design.
If it spawned on firing, you would get a follow-up for a notification you ignored, which is the product talking to itself. Completion means the work happened, which is the only event that makes a chase meaningful.
Two limits, both of which turned out to be necessary:
- Never on a repeating reminder. A repeat already comes back; one follow-up per occurrence turns a weekly reminder into two.
- A follow-up carries no follow-up of its own. Otherwise it regenerates forever, which is a repeat with extra steps.
And undoing the completion takes the follow-up away with it, so a mis-click does not leave a chase for something you did not finish.
Where the page matters more than the alert
The reason this belongs in a browser rather than a to-do list is where the checking happens.
“Did they reply?” is answered by opening a specific page — the portal, the PR, the billing dashboard, the thread. A to-do item saying chase invoice leaves you to go and find the invoice. A reminder that reopens the invoicing page has you looking at the answer already.
For the ones where you check the same page repeatedly, a per-site rule can set it up automatically: everything you save from the billing tool gets a waiting on tag and opens a week out, without you choosing anything.
When it is not a follow-up but an order of operations
There is a related case that is not the same shape: two things both need doing, and the second is pointless before the first.
- “Book the flights” is meaningless before “get the dates confirmed”
- “Publish the post” is meaningless before “get the review back”
- “Chase the invoice” is meaningless before “send the invoice”
Here both reminders already exist, and the problem is that the second one will fire while the first is still outstanding, and you will dismiss it, and then it is gone.
Dependencies handle that: the second one waits, visible in the queue, doing nothing, until the first is completed. Then it starts counting down normally. If you delete the first, the second is released rather than stranded — a reminder that can never fire is a silent failure, and silent failures are the one thing this category cannot afford.
A tag is worth more than it sounds
Whatever you use, put everything you are waiting on behind one tag — waiting, chase, whatever you will type.
The value is not organisation. It is that you can look at the whole set in one click and see what is outstanding across every system at once: the invoice, the PR, the council application, the reply from the accountant. That view does not exist anywhere else, because each of those things lives in a different tool that only knows about itself.
I look at mine on a Friday afternoon. It takes about ninety seconds, and roughly once a month it catches something that had been silently stuck for a fortnight.
The rule underneath all of it
Anything you hand to another person should leave a mark on your own system on the way out.
Not a task for them — a date for you. The date is when it stops being reasonable that they have not come back to you, and that number you already know: a week for a colleague, a fortnight for an invoice, a month for a formal application.
Write it down at the moment you let go of the thing. It is the only moment you will have all the context, and it is the moment you are least inclined to bother.
Related: the life of a reminder · task dependencies · reminders for the things you check on a rhythm