Administration workflow between business units without lost requests

Requests get lost at the boundary

An administration workflow between business units avoids lost requests by giving every request a single record that travels with it, by making transfers between units explicit rather than forwarded emails, and by ensuring there is always a named owner, even while a request is moving. Requests rarely disappear inside a unit. They disappear in the gap between one unit's process and the next.

This is common in groups where each subsidiary or division runs its own admin team but relies on a shared service for some work, such as travel bookings at group level or facilities managed by the property arm. Each unit's process works internally. The joins between them are where nothing is written down.

Mergers and restructures make it worse. When a new subsidiary joins the group, its admin team keeps its own habits, and requests to group services arrive in whatever format that team used before.

Agree a shared intake and a shared reference

The simplest structural fix is a common reference for every request, whichever unit receives it first. When a request moves from a subsidiary's admin desk to group procurement, it keeps that reference, so both sides and the requester can talk about the same item. Agree the format too: a short prefix for the unit that first received the request, followed by a running number, shows at a glance where a request started.

A shared intake form helps too. It does not have to replace each unit's own processes, but it should capture the same core details in the same way: requester, unit, site, request type and needed-by date. That consistency is what lets requests move between units without being re-keyed and re-interpreted.

Rules for transferring a request to another unit

A forwarded email has no owner on the receiving side until someone opens it and decides to act, so forwarding does not count as a transfer. Write the agreed sequence into each unit's procedures so it does not depend on individuals remembering it. A proper transfer runs like this:

• Sending unit checks the request has the details the receiving unit needs
• Sending unit assigns it to the receiving unit's queue, not a person's inbox
• Receiving unit acknowledges within an agreed period and names a handler
• Until acknowledged, the sending unit still owns the request
• Requester is told which unit now holds it and under what reference
• If the receiving unit rejects it, the request returns with a reason rather than closing

Handling requests nobody wants

Some requests fit no unit's remit cleanly, such as a shared car park issue between two subsidiaries in the same building. These bounce between units until the requester gives up. Name a default owner for unclassified requests, usually the group or head office admin lead, whose job is to decide where the request belongs within a short period and record that decision.

Each decision becomes a precedent. Keep a running list of these rulings so the next similar request goes straight to the right unit.

Some requests cross remits by nature, such as a change to a shared building that needs agreement from both occupants. These need a joint decision, and the default owner can convene it instead of letting each unit wait for the other to move.

A monthly review of stuck and transferred requests

Once a month, the admin leads from each unit should look at transferred requests together. Useful questions are which transfers took longest to acknowledge, which requests were transferred more than once, which were returned, and which have been open longest with no update. Bring three or four specific examples rather than summary figures; examples are easier to fix.

The review should end with changes to the transfer rules, remit list or intake form, recorded and shared with each unit. Without that output, the meeting becomes a status update and the same problems return.

Rotate the chair between units so the review does not feel like head office auditing the subsidiaries. Units speak more openly about their own delays when the discussion is shared.

Choosing tools that cross unit boundaries

Separate systems per unit make transfers harder, but a single shared system without agreed rules simply moves the confusion into a new place. Agree the transfer rules first, then test any candidate tool with a few real cross-unit requests from the past month, checking that each keeps its reference, owner and history through every transfer.

Fasttrade's BukuAdmin is built for company administration with cross-team follow-up as one of its areas, next to documents, internal requests and bookings; Fasttrade confirms availability and how it applies across business units in conversation.

Frequently asked questions