- Who is this for?
- Transport operations managers, customer service teams and transport planners
- Question addressed
- Turn a shared transport operations inbox into an assigned work queue so that no request is left without a response.
Key takeaways
- A read message remains an open request until it has an owner, a status and a next action.
- Ownership applies to the operational request, not merely to the email conversation.
- A document, change or follow-up should join the relevant record rather than create a parallel task.
- The end-of-day review starts with requests that have no owner, no due time or no evidence of completion.
Why “read” does not mean “processed”
In a shared inbox, the read indicator only shows that someone opened a message. It does not show whether anyone understood the request, checked the attachments, created or amended the order in the TMS, replied to the sender or verified the outcome. Several people can therefore assume that a colleague is handling a request when it has no owner at all.
The risk grows when one conversation carries several events: a new order in the first message, a corrected time slot in the reply and a document attached to a follow-up. Tracking email alone confuses the message, the task and the transport record. The unit of work should be the operational request and its expected effect on that record.
Give every request an owner and a status
A workable procedure states who classifies new messages, who becomes responsible for each request type, and who may reassign or escalate it. The owner does not necessarily perform every action, but remains accountable for moving the record forward and making any waiting period explicit.
Statuses should describe the state of the work without becoming needlessly granular. A short set may be enough: to classify, assigned, in progress, waiting for a third party, awaiting approval, completed and escalated. Moving to “completed” requires an observable result, such as a reply sent, a document linked or a verified state in the target system.
- 01Classify
Identify the type of request and the relevant record, or flag that the link remains uncertain.
- 02Assign
Name the person or role accountable and make the ownership time visible.
- 03Plan
Set the next action and the operational deadline that applies to this case, without inventing a universal response time.
- 04Process
Retain sources, decisions, replies and completed actions throughout the life of the record.
- 05Check and close
Verify the expected outcome, then record the evidence that supports closure.
A tracking table ready to adapt
The table below is a working template. It can live in whichever tool the team selects, provided that its fields remain shared, searchable and up to date. The sample values are fictional and illustrate the structure rather than a universal process.
| Field | Question it answers | Fictional example |
|---|---|---|
| Request ID | Which unit of work are we tracking? | REQ-2026-0142 |
| Received / source | When and where did the request arrive? | 7 Sep, 08:17 · operations inbox |
| Type | Is it a new request, document, change, follow-up or out-of-scope item? | Change |
| Record / reference | Which transport movement does the event belong to? | Customer order TR-4812 |
| Owner | Who is accountable for the next step? | Northern operations role |
| Status | What is the actual state of the work? | Awaiting approval |
| Due time | When must the team act or review the request? | 7 Sep, 10:30 |
| Last action | What has already been done and checked? | New time slot matched to the order |
| Next action | Which decision or execution is still required? | Approve the change before writing to the TMS |
| Closure evidence | Which result will allow the request to be closed? | Time slot verified in the TMS and reply sent |
Triage matrix for incoming messages
Triage is not about keeping the inbox tidy. It determines the first decision, the record that must change and the closure condition. If the request type or record link remains ambiguous, the message should be handed over with the candidate records and completed checks rather than filed on a guess.
| Incoming type | First action | Ownership and status | Closure or escalation |
|---|---|---|---|
| New request | Confirm that this is a new order, gather the required data and open the record. | Assign to order intake; mark “in progress” or “waiting for information”. | Close after verified creation, or escalate if a decisive item remains ambiguous. |
| Document | Identify the document type and version, then find the destination record. | Keep the record owner; remain “in progress” until the link is confirmed. | Close after a verified link; escalate when several records match or the document cannot be used. |
| Change | Compare the new instruction with the current state and retain the before-and-after values. | Record owner; mark “awaiting approval” if the change falls outside authorised rules. | Close after the amendment and its check, or hand over the decision with both versions. |
| Follow-up | Retrieve the initial request and check its real status before replying. | Reactivate the existing owner; use the status that reflects the next step, never “completed” by default. | Close when the expected answer is supplied; escalate when the deadline or impact requires it under the procedure. |
| Out of scope | State why: wrong recipient, uncovered request or unauthorised action. | Assign to the routing role; mark “escalated” or “redirected”. | Close with an explicit, traceable handover, not by simply archiving the message. |
Link replies, documents and follow-ups to the same record
An email thread is useful, but not always sufficient: the subject line may change, a document may arrive in a new message, and one conversation may refer to several orders. Linking should therefore use the available references, parties, dates, sites and timeline, with an explicit rule for conflicting cases.
Every event retains its source, timestamp and effect. A sent reply is not evidence that the expected action succeeded. Likewise, saving a document does not prove that it is linked to the right version of the record. When doubt remains, the team should see the candidate links and the decision still required.
- retain the initial request and each subsequent change;
- separate the received value, the retained value and the action actually performed;
- link a follow-up to the reason for waiting that is already recorded;
- prevent a new reply from creating a second, competing owner;
- check the result in the TMS or relevant tool before closing the request.
Priorities, end-of-day review and controlled automation
Priority should not depend only on arrival order or an “urgent” label in the subject line. It combines the operations rules that have been approved: transport deadline, blocking action, customer commitment, dependency on a third party and the consequence of delay. The exact criteria belong to each company and should be explainable.
At the end of the day, the manager reviews requests that remain unclassified, unowned, overdue, waiting without a review date or closed without evidence. Sensitive or out-of-rule cases are escalated with their context. Legitimate waiting items remain open with an owner and a review date; they do not disappear into a generic “to do” folder.
Vigilo can help connect events, documents, rules, decisions and actions across tools within a configured and approved scope. This does not automatically turn every inbox into a reliable process: ownership, statuses, priority rules, action rights and checks must first be defined. An ambiguous action, or one whose result cannot be verified, goes back to the team with its context.
- no received request without a classification or documented exclusion reason;
- no active request without an owner and a next action;
- every missed deadline explained, reassigned or escalated;
- every external wait paired with a review date;
- every closure supported by an observable outcome.
Frequently asked questions
Direct answers
Should every email be assigned to one person?
What matters is a single owner for each operational request. Several people may contribute, but shared responsibility without an explicit owner makes unanswered requests more likely.
Which status should we use while waiting for the customer?
Use an explicit status such as “waiting for a third party”, together with the accountable owner, the question asked and a review date. Waiting should not remove the request from the active queue.
Can inbox triage be fully automated?
Triage can be prepared or automated within an approved scope, but ambiguous, conflicting, sensitive or out-of-rule cases must go back to the team. Quality is checked through the correct record link, ownership and final outcome, not classification alone.
Sources and methodology
This resource describes Axonovia's product approach based on transport workflows. The examples are illustrative and do not constitute a performance commitment or a universally applicable contractual rule.
Product review: Axonovia team · next review recommended before 31 August 2027 or following a material change in scope.