Once requisitions exist as a process, managing them is largely queue management. Requests arrive, wait for a decision, and either become orders or do not. The organisational skill is keeping the queue short and visible, because a slow requisition queue is the direct cause of people buying things another way, which is the failure the whole process exists to prevent.
Visible status, so nobody has to chase
The requester should be able to see where their request is and who holds it. Most informal chasing exists purely to obtain that one fact, and it consumes the approver's time as well as the requester's. Making status visible removes work from both sides and makes the process feel reliable, which is what drives adoption.
Named approvers and automatic cover
A request assigned to a group is a request nobody owns. Assign to a person, allow reassignment, and cover absence automatically. Absence is the biggest single contributor to the long tail of slow requests, and automatic cover is the cheapest fix available because it needs no change in anybody's behaviour.
A rule for the unroutable
New cost centres, unfamiliar categories, requests from somebody outside the usual structure. These need a named default owner rather than a limbo queue. It is worth reviewing what lands there monthly, because a growing default queue is a signal that the routing rules no longer match how the organisation is shaped.
Questions people ask about requisition management
What should we measure?
Elapsed time to decision, the age of the oldest open request, and the share of invoices arriving with a purchase order behind them. The third tells you whether the process is winning.
How do we handle requests that are declined?
Say why, promptly. A declined request with no explanation is the most reliable way to teach somebody to buy on a card instead.
Should requests expire?
Ageing them out with a notification is reasonable, provided the requester is told. Silent expiry is indistinguishable from the request being lost.