At ten in the morning, a warehouse supervisor in Midrand opens four things: the order system, a shared spreadsheet, the courier's tracking page and a WhatsApp group. She is not doing any work yet. She is finding out where the work stands. Later, a finance clerk will message her to ask whether order 4417 has gone out, and she will repeat part of the exercise for one customer. By the end of the week, a surprising share of her time has gone on looking, asking and reassuring.
Manual status checking is the habit of finding out what is happening by asking people or opening several systems. It feels like diligence, yet it is a sign that the business has no reliable way to tell people where things stand. This article looks at why the habit takes hold and how to reduce it without losing control.
Why people check manually
Nobody chooses to spend hours chasing updates. The habit grows from reasonable motives.
- The status is not recorded where people look. The truth lives in someone's head, a private message or a paper note, so the only way to get it is to ask.
- The recorded status cannot be trusted. If the system said "shipped" last month for an order that had not gone, people learn to verify. Distrust is expensive and long lasting.
- The status is scattered across tools. Each system holds one piece, and nobody has a single view.
- Silence is ambiguous. When nobody has said anything about a job, there is no way to tell whether it is going well or has been forgotten. Checking is the only way to find out.
The last of these deserves attention. Our article on why a quiet workflow is not proof it worked describes the same ambiguity from the automation side. If a process only speaks when it fails, people have to keep looking in case it has.
Count the cost before you fix it
It is easy to dismiss status checks as small. A two-minute check repeated forty times a day across a team adds up quickly, and it also interrupts the people being asked, whose work is broken into pieces. A simple measurement helps. For one week, have each person tally the number of times they ask for or look up a status and roughly how long each takes. Add a note for any occasion when a wrong or missing status led to a mistake, such as a double shipment or a promise to a customer that could not be kept.
The tally rarely needs to be exact. What matters is that the cost becomes visible enough to justify a change, and that the checks cluster around a few repeated questions. In most businesses, five or six questions account for the bulk of the traffic: has it been paid, has it been approved, has it been dispatched, who has it, and when will it be done.
Decide which questions deserve a recorded answer
The next step is to turn each frequent question into a defined status that is recorded once, in one place, at the moment it changes. Do not try to track everything. Choose the handful of states that people ask about, give each a precise meaning, and name the event that moves a job from one to the next. "Approved" should mean that a named person has accepted the request, not that someone thinks it was probably fine.
A status that is recorded as a by-product of the work is far more reliable than one that depends on someone remembering to update it. If dispatch is confirmed when the courier collection is scanned, the status is true by construction. If it depends on the supervisor remembering to tick a box at the end of a busy day, it will drift. This is why our guide to designing a handoff that cannot depend on memory is relevant here: reliable status comes from the process recording itself.
Push the status to people instead of making them pull it
Once a status is recorded reliably, the second shift is to move from pull to push. Instead of the finance clerk asking about order 4417, the system tells her when the order is dispatched. Automation tools can do this for many routine cases. Microsoft's overview of cloud flows in Power Automate describes flows that start from a trigger, such as an item being created or modified, and then carry out actions such as sending a notification. Equivalent features exist in most business platforms, so the principle does not depend on one product.
Push works best when it is selective. A flood of notifications trains people to ignore them. Three practical rules help:
- Notify only on a change that someone needs to act on or that closes a question they have been asking.
- Send the message to the person who asks the question, not to a broad group.
- Include enough detail to avoid a follow-up: the order number, the new status, the time and the next step.
Where an approval is the thing people are waiting on, a structured approval request is better than an email thread. It gives the approver a clear prompt, records the decision and makes the status visible to everyone with access. Our article on why approval processes become bottlenecks covers how to keep those steps from stalling.
Give people one place to look
Notifications handle the cases people know to ask about. For the rest, there should be one view where the current state of work can be seen at a glance, such as a board or a simple dashboard of open jobs by stage. The aim is not a polished report but a screen that answers "where is everything" in under a minute. Be wary of building a dashboard before the underlying statuses are reliable. Our piece on why more dashboards do not automatically create better decisions explains why a good-looking display of untrusted data makes the problem worse.
The view should show exceptions prominently. Jobs that have sat in one state longer than expected are the ones that cause customer complaints, and a list of them lets a supervisor manage by exception instead of reviewing everything.
Check the checkers
If you automate status updates, you create a new dependency: the updates themselves must work. A notification that silently stops arriving is worse than none, because people have stopped checking. Make sure a person is told when an automated update fails to run. Microsoft's guidance on error handling in Power Automate flows describes how to catch failures and respond to them, and the general idea carries over to other tools. A related architectural idea is the health endpoint monitoring pattern, in which a system exposes a simple check that an external tool can poll to confirm it is working. For a small business, the equivalent might be a daily message that confirms the status job ran, with an alert when it does not.
Practical next actions
- For one week, have your team tally every status question they ask or answer, then list the five most frequent.
- For each of those questions, define a precise status and name the event that changes it, preferring events that happen automatically as part of the work.
- Choose one question, such as "has it been dispatched", and set up a targeted notification to the person who asks it most often.
- Create one shared view of open work by stage that highlights items stuck longer than expected, and retire the private spreadsheets it replaces.
- Add a failure alert to every automated status update, so a person is told when an update does not run.
Sources and further reading
- Overview of cloud flows - Power Automate (last verified 10 October 2026)
- Employ robust error handling - Power Automate (last verified 10 October 2026)
- Health Endpoint Monitoring Pattern - Azure Architecture Center
Related Mellorca reading
- How to Avoid Creating a Fragile Automation Stack
- Why chasing people for updates is a systems failure
- How to find automation opportunities from operational evidence