Admin request tracking with status visible to requesters

Visible status replaces chasing

Admin request tracking with visible status means every requester can look up their own request and see where it stands, who is handling it and what happens next, without messaging the admin desk. It works when the status labels are few, defined in plain language, and updated by the handler at the moment the work changes, not at the end of the week.

The payoff is fewer interruptions. A large share of admin desk messages are some version of any update on my request. Each one pulls a handler away from doing the work to report on it. When requesters can check status for themselves, the remaining messages tend to be genuine questions.

Visibility changes behaviour on the admin side as well. When handlers know a requester can see their request sitting unassigned since Monday, that work gets picked up sooner, without a team lead having to chase.

A status set requesters can understand

Keep the list short and make each label describe a state the requester recognises. Internal sub-steps can exist for the admin team, but the requester view should map to something like this:

• Submitted: received and waiting for a handler to pick it up
• Assigned: a named person in admin now owns it
• Waiting on you: admin needs information or a decision from the requester
• Waiting on approval: with a manager or budget holder
• Waiting on supplier: an outside party such as a vendor or contractor is involved
• In progress: admin is actively working on it
• Completed: done, with a note on what was delivered
• Closed without action: rejected, duplicated or withdrawn, with a reason

Why the waiting states matter most

Splitting waiting into who it is waiting on is the single most useful choice in this list. A requester who sees Waiting on you knows the delay is theirs to fix. One who sees Waiting on approval knows to nudge their manager rather than admin. Without these, everything looks like In progress, and the admin desk absorbs complaints about delays it does not control.

Every waiting state should carry a short note saying exactly what is needed: the cost centre, a second quote, the manager's sign-off. A label alone is not enough. For Waiting on supplier, name the vendor or contractor and the date they have committed to, if there is one.

Rules for handlers updating status

Status is only trustworthy if it changes when the work changes. Agree that handlers update the request whenever it moves between people or waits on something new, and that a request should not sit in one state for longer than an agreed period without a note explaining why.

Completion notes should say what was delivered, not just done. Replaced faulty socket in meeting room 3, tested OK is useful when the same fault comes back. Done is not. For travel, the completion note can confirm the booking reference and where the itinerary has been sent.

When a request changes hands inside admin, for example from the travel desk to the facilities coordinator, the handler name the requester sees should change at the same moment, with a brief note. Requesters who keep messaging the previous handler are a sign this step is being skipped.

Closed without action needs a reason every time. Staff accept a rejection far more easily when they can read why, and the reasons give admin leads a record of requests that should never have been raised, which often points to a missing policy or form.

Deciding what requesters see and what stays internal

Not every detail belongs in the requester view. Supplier pricing, internal comments between handlers and notes about other staff should stay internal. The requester sees the status, the handler's name, the latest public note and the expected date where one is known.

Be careful with expected dates. A date that keeps slipping damages trust faster than no date at all. Only show one when the handler is reasonably confident, and update it with a reason when it moves.

Making visible tracking part of daily admin work

Requesters need to know where to look. Put the link to their open requests in every acknowledgement and notification, and on the intranet page where they submit new ones. Keep notifications sparing: tell people when the request is assigned, when it is waiting on them and when it is complete. Notifying every internal step trains staff to ignore the messages.

Team leads should review open requests by status each morning, starting with anything waiting on admin for too long. After a few weeks, compare the chasing messages the desk receives against the period before, and note which statuses still prompt them. BukuAdmin, Fasttrade's company administration product, covers internal requests together with documents, bookings and cross-team follow-up; Fasttrade can confirm in conversation how far it fits the tracking approach you settle on.

Frequently asked questions