A project manager I know described her week as "asking four people the same question until one of them answers." That is not project management. That is being a human cron job.
The frustrating part is that stalled approvals almost never come from disagreement. Nobody is sitting on your design review because they hate it. They are sitting on it because your request landed in a form that made it easy to defer, and deferring has no cost to them.
So before you build a process or start chasing harder, it is worth working out which kind of stall you actually have. There are four, and they need different fixes.
Stall one: nobody knows they are the decider
You posted the request in a channel with six people in it. Everyone saw it. Everyone assumed someone more senior would handle it.
This is the most common stall and the easiest to miss, because from your side it looks like six people ignoring you. From their side, nobody was asked.
The fix is boring and it works. Name one person. Not a team, not a channel, not "whoever has bandwidth." One name, in the first line, with the word "you" in it.
If you genuinely do not know who decides, that is the real blocker and no amount of following up will clear it. Find out first.
Stall two: the ask is bundled with a discussion
Compare these two messages.
Here is the updated scope doc. I have changed the timeline on phase two and added the analytics work we discussed. Some open questions on resourcing in section four. Let me know your thoughts.
Approving this needs one decision from you: do we include the analytics work in phase two, yes or no? Everything else is unchanged. Details in section four if you want them.
The first one is a conversation. Conversations can wait. The second is a yes or no question, and a yes or no question sitting unanswered starts to feel like rudeness after a few days.
Most stalled approvals are the first kind. The request is buried in context, and the reader cannot tell what they are actually being asked to do, so it goes on the pile of things to read properly later. Later never arrives.
Separate the decision from the discussion. Put the decision first, in one sentence, in a form that can be answered with a single word.
Stall three: there is no deadline, so it is never late
A request without a date is never overdue. It just gets quieter.
This is why "whenever you get a chance" is one of the most expensive phrases in project work. It feels considerate. What it actually does is remove the only mechanism that would have moved your request up someone's list.
Give every approval a date and a consequence. The consequence does not have to be dramatic, and it should not be a threat. It just has to be real.
Need this by Thursday or the build slips to the following sprint.
That is not pressure. It is information the other person needs in order to prioritise correctly, and most people appreciate having it.
Stall four: it is genuinely not their priority
Sometimes the request is clear, owned, and dated, and it still sits there. That usually means it matters less to them than it does to you, and no amount of rephrasing will change that.
This is the one case where following up more is not the answer. What you need is either a different decision maker, a smaller ask that fits inside the attention they can spare, or an escalation to someone who can reprioritise it.
Knowing when you are in stall four rather than stalls one through three is most of the skill. The tell is that they have acknowledged the request and still not acted. Silence usually means the first three. Acknowledgement followed by nothing usually means the fourth.
The follow-up problem underneath all of this
Fix all four and you still have a residual problem, which is that even a perfectly formed request sometimes needs chasing.
This is where most project managers end up doing something they hate. They set a personal reminder, they check a list on Monday morning, they send the nudge, they feel like a pest, and they do it again on Wednesday. It is low value work that expands to fill whatever time you give it.
The instinct is to build a process around it. A tracker, a status column, a weekly review. Those help with visibility but they do not remove the chasing, they just document it.
What actually removes the chasing is having the follow-up happen without you. Not a reminder telling you to send a message, which is just a to do item wearing a hat, but the message itself going out on a schedule you set once. We wrote about setting that up without a workflow builder in how to automate project approval follow-ups.
Why automated chasing usually feels worse
There is a good reason people resist automating this, and it is worth taking seriously.
A badly automated follow-up is worse than a manual one. If the same flat reminder arrives every three days, forever, with no acknowledgement that anything has changed, it stops being a nudge and becomes noise. People filter it. Now you have automated the part that does not work.
Two things separate automation that works from automation that annoys.
The first is escalation. A first reminder and a fourth reminder should not read the same. The first can be light. By the fourth, if a build is genuinely slipping, the message should say so plainly. That progression is what makes the sequence feel like a person paying attention rather than a timer going off.
The second is stopping. The moment someone approves, or replies to ask a question, the sequence has to end. Nothing torches goodwill faster than a reminder about a decision the person made yesterday. It tells them nobody was listening.
That second point is the one most tools get wrong, because it requires the system to notice something rather than just count days. autoremind.ai pauses a sequence as soon as someone replies, and it does that without connecting to your inbox at all, which we explain in follow-up automation that does not need access to your inbox.
Fixing it without micromanaging
Micromanaging is not about frequency either. It is about whether the other person feels watched or supported.
Chasing daily for a status update is micromanaging. Sending a clear request with a date, then having a reminder arrive on that date, is not. The difference is that the second one has a rule the other person can see, and the rule is about the work rather than about them.
In practice, this is what it looks like. One named owner. One decision, stated first. One date with a real reason behind it. Then a short sequence that escalates in tone and stops the moment they engage.
That combination removes the two things that make approval chasing miserable. You stop carrying it in your head, and they stop feeling supervised.
FAQs
How long should I wait before following up on an approval? Two to three working days for a routine decision, longer if you asked for something that needs real review time. Sooner than two days reads as impatient unless you flagged urgency in the original request.
What if the approver keeps saying they will get to it? That is stall four. More follow-ups will not help. Reduce the ask, get a different decision maker, or escalate to someone who can reprioritise.
Is it rude to set a deadline for someone more senior? No, as long as the deadline comes from the work rather than from you. "The build slips if this lands after Thursday" is a fact about the project. "I need this by Thursday" is a demand.
Can I automate approval follow-ups without a workflow builder? Yes. Describe the reminder in plain language and let the tool handle the schedule and the escalation. Tools like autoremind.ai write each message and stop when someone replies, with no triggers or branches to configure.
Stop being the reminder. Start autoremind.ai free, three reminders, no card needed.
See also: How to Automate Project Approval Follow-Ups Without Building a Workflow · Slack vs Email for Business Reminders · Why Most Follow-Up Emails Fail
