Details last reviewed on 5 October 2026. Rules and products change often. This is general information, not legal or tax advice, so confirm specifics with a qualified professional.
If you run operations, much of your day is two questions: "has it been approved?" and "where is it?" Neither is hard to answer. The answer lives somewhere you cannot see, so you ask a person, wait, and ask again.
This guide covers where chasing comes from and how to design it out: the approval workflow, the status updates that should go out unasked, a worked purchase order example, and the numbers worth watching. We end by saying plainly what OpsGrids does today, which is narrower than the design.
Where chasing comes from
Chasing is a symptom. It appears when four things are missing.
- A request sits in an inbox. The approver has not refused; they have not seen it among sixty other messages.
- No deadline. Nothing says the step is overdue, so nothing happens when it is.
- No escalation. If the approver is travelling or busy, the request waits for them, because no one else is allowed to act.
- Status held in people's heads. "Ask Meena, she knows where it is." When Meena is on leave, the status goes with her.
The founders of OpsGrids see the same pattern: work stalls in handoffs, and approvals wait in inboxes. Tally, Excel and WhatsApp are each good at their own job, but none carries a request from one person to the next with a clock on it. That needs a route with a named approver and an escalation time.
Design the approval workflow
A good approval workflow answers six questions before the first request is raised.
1. Thresholds by value
A small consumable can be approved by a team lead; a large capital purchase needs finance. Write the bands down as amounts, with your own numbers, so a requester can see before raising anything who will decide.
2. The reporting line is the route
The simplest route is the one that already exists: the requester's manager, then that manager's manager. Approvers named per form go stale as people change roles; the reporting line is one record to maintain instead of many.
3. A deadline per step
Each step gets a time limit, such as one working day for routine requests. The deadline is what turns "waiting" into "overdue", which is an event someone can act on.
4. Escalation to the next manager
When the deadline passes, the request moves to the approver's manager. It does not disappear from the first approver's list; it gains a second person who may decide.
5. Delegation when someone is away
Escalation should be the fallback, not the plan for every holiday. Let an approver name a delegate for dates they will be away. The record then shows who decided on whose behalf.
6. One decision record
Whatever the outcome, store who decided, when, at which step and with what comment, against the thing being approved. A decision that exists only in a chat thread gets reconstructed at the worst moment, such as a dispute with a supplier.
| Design choice | What goes wrong without it | What to write down |
|---|---|---|
| Value thresholds | Everything goes to the owner, or nothing does | Amount bands and who approves each |
| Reporting line as route | Approver lists go stale | Who reports to whom |
| Deadline per step | Requests wait silently | Hours or days per step |
| Escalation | One absent person blocks the chain | Who is next, and when |
| Delegation | Holidays stall work | Named delegate and dates |
| Decision record | Disputes rest on memory | Who, when, step, comment |
Design the status updates
The second half of chasing is "where is it?" The cure is to decide, in advance, which events deserve a message. Do not message everything; people stop reading. For each event ask: who must know, on which channel, with what wording and with what proof.
WhatsApp suits short, time-sensitive notices; email suits anything with a document attached or that someone will search later. The mechanics are in WhatsApp automation for Indian businesses and email automation for business events. If you message customers or suppliers on WhatsApp, Meta's policy expects their opt-in, so check the current terms.
Proof is the part most teams skip. "Sent" is not "delivered"; if an update fails, the record should say so, so a person picks up the phone.
A worked example: a purchase order approval
This is good practice, not a description of a product feature. Suppose a purchase order raised by a store executive for a supplier.
- Raise. The requester enters the supplier, lines and amount, and a reason for any unusual item.
- Threshold. Up to the first band, the reporting manager decides. Above it, the manager decides and then the department head. Above the top band, finance is the last step.
- Deadline. Each step has one working day. At the deadline the request moves to the approver's manager.
- Decide. Approval changes the PO's status in the same moment, so nobody has to update a sheet by hand. Rejection requires a comment.
- Tell. The requester hears the outcome, and buyer and accounts payable are told when the PO is approved.
- Close the loop. Goods receipt happens against the approved PO, which is the basis for checking the supplier's invoice. Our procure-to-pay guide shows why that match matters.
None of this needs a clever tool. It needs the thresholds, route and clock written down, then enforced by something other than memory.
What to measure
Three numbers show whether chasing is going away. Set your own targets.
- Time to decision. From request raised to decision recorded, by approval type. Watch the slowest step, not only the average.
- Number of escalations. A few are healthy. A steady rise means a particular approver, band or deadline needs revisiting.
- Items with no owner. Requests whose current step has no named person, for example because an approver left. This should be zero.
A checklist before you automate
- Amount bands are written down, with an approver for each.
- The route follows the reporting line, and that line is current.
- Every step has a deadline.
- Escalation goes to a named next person.
- Approvers can name a delegate for planned absence.
- One decision record holds who, when, step and comment.
- Each status event has an audience, a channel and a proof of delivery.
- Someone reviews time to decision and escalations monthly.
Common mistakes
- Approvers named per form. They go stale. Use the reporting line.
- A deadline with no consequence. If an overdue step triggers nothing, it is a wish.
- Escalating to a group inbox. Escalate to a person.
- Treating "sent" as "delivered". Keep the receipt.
- Approving in chat and recording later. The record depends on someone remembering.
What OpsGrids has today
One approval chain is live end to end: the attendance correction in HRMS. A correction request routes up the employee's reporting line, escalates to the manager's manager if unanswered, and applies the moment it is approved. See HRMS and, for the attendance side, our attendance and geofencing guide.
Routing a purchase order above a threshold up the same reporting line is designed, not built. Today a PO's status in Operations is a local field. Operations has purchase orders down to the line and goods receipt against them, but no automation rules, and the receiving screens are still marked coming soon in the app.
Notification rules do route events, such as an approval being decided or an approval step escalating, to people on WhatsApp or email, with a delivery receipt coming back. See automations and the wider product overview.
FAQ
What is an approval workflow? It is the defined route a request takes to a decision: who approves, in what order, by when, what happens if they do not, and where the outcome is recorded.
How do I set thresholds for purchase order approval? Pick amount bands that match the risk each level should carry, name the approver for each, and review them when budgets change. Your finance lead should set the figures.
What should escalation rules do? Move an unanswered request to the approver's manager after a fixed time, tell both people, and keep the history. Use delegation for planned absence.
How do I get status updates without chasing? List the few events that matter, assign each an audience and channel, and keep proof of delivery on the record. Then people can see status without asking you.
Let the route do the chasing
If you want to talk through an approval route for your own operations, Talk to our team.
Sources (checked 5 October 2026)
- Meta, WhatsApp Business Platform documentation and Business Messaging Policy (developers.facebook.com)