A sign-off step is supposed to stop the wrong thing from happening. Set it up carelessly and it stops the right thing from happening too, and nobody finds out until much later.
The fix is not to remove the approval. It is to decide, before you need it, how the request reaches a person and what happens when it does not.
An approval only protects you if someone is there to give it. Otherwise it is a delay.
Why people add a sign-off step
Putting a person between an automated process and an important action is a good instinct. Before the system sends the email, pays the invoice, deletes the records, or installs the update, someone looks and says yes. That is what "human in the loop" means in practice: the machine does the work, a person makes the call.
Most tools now make this easy. You tick a box, and the action waits for a click before it goes ahead. It feels safe, and on the day you set it up, it is. You are right there, watching, and the request appears in front of you.
The trouble is that you will not always be right there.
What actually happens when nobody answers
When a request for approval goes unanswered, one of three things tends to happen, depending on how the tool was built.
- It waits forever. The work sits in a queue until someone notices. Nothing bad goes out, and nothing good goes out either.
- It times out and cancels. After a set period with no answer, the system gives up and drops the action. This is often the default, because it is the cautious choice.
- It times out and goes ahead. Rarer, and worse, because the approval step was never really a gate.
The first two feel safe because nothing goes wrong in a way you can see. That is exactly the problem. The work quietly stops, and there is no error and no alarm to tell you it did. The step that was meant to keep you informed has left you out of the loop.
The example that prompted this
This week a software update on a second computer of mine waited for my approval. The request showed up in a chat window I was not watching. After five minutes with no click, it timed out and was cancelled. The update never ran.
Nothing broke, and that is the point. The approval step did exactly what it was set up to do: no click, no change. It also meant the update did not happen. The safeguard worked, and the work stopped anyway, because the request landed where nobody was looking.
It is a small case. The same shape shows up in places that matter more.
Three questions to answer before you add one
Every approval step has three parts, whether or not anyone designed them. Make them a decision instead of an accident.
Where does the request show up?
An approval is a message. It has to land somewhere: an email, a chat app, a dashboard, a text message, a notification on a phone. Pick the place the approver already looks during the hours the request is likely to arrive. A dashboard nobody opens is not a place. Neither is a chat window that is only open when you are at that one desk.
Who actually sees it?
Name a person, and a second person. "The team" is not an approver, because everyone assumes someone else saw it. If the one person who can say yes is on holiday, asleep, or in a meeting all afternoon, the request needs somewhere else to go.
What happens if nobody answers?
This is the question most setups skip, and the one that decides whether the step protects you or stalls you. Choose deliberately, and choose differently for different kinds of work.
A worked example
The right answer depends on what is at stake if the action goes ahead without a look, and what is at stake if it does not happen at all. The rows below are illustrations, not a client story.
| The action | Cost if it runs unchecked | Cost if it never runs | Sensible "nobody answered" rule |
|---|---|---|---|
| Routine software update | Low | Medium, it piles up | Remind once, then retry at a quieter time and say so |
| Refund to a customer | Medium | High, an unhappy customer | Pass to a second approver after an hour |
| Bulk email to the whole list | High | Low, it can go tomorrow | Hold, and send a clear "this is waiting" note |
| Deleting old records | High, hard to undo | Low | Never go ahead without a yes, and report the stall daily |
Notice that "cancel quietly" appears nowhere in the last column. Whatever the rule, the person who cares about the outcome should find out that the work did not happen. A cancelled action with no notice is the worst of both worlds: no protection gained, and no one aware of the cost.
A simple way to set it up
When you add a "check with a person first" step to anything:
- Write down where the request will appear, and check that the approver actually looks there.
- Name a first approver and a backup.
- Set a time limit that matches the work. Five minutes is fine for someone sitting at the screen. It is not fine for a task that runs overnight.
- Decide what happens at the limit: remind, pass it on, hold, or proceed.
- Make sure a stall always leaves a visible trace: a message, a line in a daily summary, something a person will see.
Then test it the honest way. Trigger a request when you are away from your desk, and see what happens.
What to take away
- Treat every approval step as a message that has to reach a person, and pick where it lands on purpose.
- Name who answers, plus a backup, so a request never waits on someone who is not there.
- Decide in advance what happens when nobody answers, and make sure a stall is never silent.
A sign-off step is one of the best ways to keep a person in charge of what an automated system does. It only works if the person can actually be reached. The AI does the busywork. You still make the calls, as long as the call can find you.