- Who is this for?
- Operations managers, customer service teams, IT teams and transport directors
- Question addressed
- Understand how to automate the entry of a transport order received by email.
Key takeaways
- An email may trigger the workflow, but the transport record always extends beyond that message.
- Missing data is not necessarily unknown: it may be determined by an approved customer rule.
- Post-entry verification is part of the workflow, just like data extraction.
- An ambiguous case must be returned to the operations team with its context already reconstructed.
- A shared checklist defines what must be supplied, derived under an approved rule or requested before anything is written.
- The transport record connects every field to its source, the chosen action and the state read back from the TMS.
- A “created” status is reliable only after the order and its identifiers have been read back independently.
Order entry starts with an operational decision
A transport order contains visible fields such as origin, destination, date and goods, but it also involves implicit decisions. Which account should be used? Which time slot is acceptable? Does this amendment replace the previous request? Simple extraction cannot answer these questions.
The first task is therefore to classify the event. Is it a new order, an amendment, a cancellation, a follow-up or an additional document? This classification then determines which record should be created or updated.
The five layers of an actionable transport record
- 01Signal
Identify the channel, sender, time and likely nature of the request.
- 02Explicit data
Read references, addresses, time slots, quantities, constraints and attachments.
- 03Authorized context
Match approved customer practices and business rules for this workflow.
- 04Decision
Determine the permitted action, the data to request or the required escalation level.
- 05Evidence
Retain the sources used and verify the result after writing to the TMS.
Example: an incomplete email that can still be processed
A customer writes: “Same pickup as Tuesday, delivery Thursday before 10:00.” The message includes neither the pickup address nor the usual reference. The workflow must not invent this data. It searches the customer context within its authorised scope, proposes values from Tuesday’s record and clearly identifies their source.
If the approved rule allows those values to be reused and the checks pass, the order can be prepared or created. If two records from Tuesday match, the case is ambiguous: it is returned to the operations team with both candidates and the rest of the record already completed.
What to measure during a pilot
These measures provide factual evidence for expanding the scope. They are not a performance guarantee: results depend on the channels, rules, quality of incoming requests and chosen level of authorization.
- share of requests classified correctly;
- share of complete records requiring no human rework;
- reasons for escalation and resolution times;
- differences between the prepared action and the approved action;
- the result actually recorded in the TMS;
- amendments or cancellations correctly linked after order creation.
Checklist before writing anything to the TMS
This checklist acts as a pre-write gate. It must be adapted to the mandatory fields, customer rules and permissions of the workflow actually deployed. The transport order template provides a practical way to collect the information; the list below then supports the decision to write, request clarification or route the record to the team.
- The request has been classified as a new order, amendment, cancellation, follow-up or supporting document.
- The sender, customer, locations and references identify the request without ambiguity.
- The expected dates, time slots, addresses, goods, quantities and constraints are present or covered by an approved rule.
- Every value taken from a previous record, reference source or attachment retains its source and version.
- Conflicts between the email, documents and reference data are resolved under an approved precedence rule or routed to the team.
- The account, transport type and other structural TMS choices are determined without guesswork.
- The requested action is within the authorised scope and post-write checks are available.
- An owner and a reason for rework are defined for every incomplete, ambiguous or out-of-scope record.
Worked record: from source to reviewed state
Fictional example: an email requests collection in Lille on 9 September and delivery in Reims the following day. An attachment gives the pallet details, while an approved customer record specifies the TMS account and an appointment instruction. Before any action is taken, the record shows where each value came from and how it should be handled.
| Source | Fields retained | Workflow action | State read back |
|---|---|---|---|
| Incoming email | Customer reference, collection site, requested dates | Create a new request and retain the source message | Reference, sites and dates found on the order |
| Attachment | 3 pallets, stated weight, type of goods | Attach the document and prepare the corresponding lines | Quantities and units match the attachment |
| Approved customer record | TMS account, appointment instruction | Apply the rule within its scope and record its version | Correct account and instruction visible on the order |
| Consistency check | Delivery slot still to be confirmed | Pause final validation and request a specific detail | Pending status; no time-slot value invented |
| TMS after writing | Order identifier, status, recorded values | Read the screen or system response and compare it with the prepared record | Identifier retained and any differences routed for review |
Choose whether to write, request clarification or route the record
This distinction prevents two opposite mistakes: blocking every request because a field was not written in the email, or silently completing a record with an assumption. The right decision depends on the authoritative sources, approved rules and the ability to verify the result.
| Situation | Decision | Expected trace |
|---|---|---|
| Fields are complete and the relevant rules apply | Prepare or write according to the level of authorisation | Sources, rule used, action and state read back |
| A value is missing but an authorised source is definitive | Complete the field and identify its source | Value, source, version and check performed |
| One focused question can resolve the uncertainty | Request clarification before the relevant write operation | Question sent, answer received and new record version |
| Several records or values remain plausible | Route the case to operations without choosing on their behalf | Candidates, checks already completed and reason for ambiguity |
| The written state cannot be read back | Do not report the order as created; place the case in recovery | Action attempted, unknown state and outstanding check |
Frequently asked questions
Direct answers
Is a TMS API required?
Not necessarily. The user interface can be used within an approved scope. An API remains preferable when one is available and better meets reliability, volume or governance requirements.
What happens when information is missing?
The workflow searches only authorised context, requests clarification or routes the record to the operations team. It must not invent a value.
Can a later amendment remain linked to the order?
Yes, if the available information is sufficient to link the event to the correct record. Any ambiguity triggers human validation.
What information should be collected before entering a transport order?
The exact list depends on the TMS and the workflow. It generally covers the parties and locations, references, dates and time slots, goods and quantities, constraints, and the rules used to determine the account or transport type. The transport order template linked from this article helps structure that collection.
How can you prove that the order was created successfully?
Read the TMS after the write operation, retrieve the assigned identifier and compare the recorded fields with the prepared record. A click, a sent request or a progress message is not sufficient evidence of the result.
Can an incomplete email be completed automatically?
Yes, but only when an authorised source or approved rule determines the value without ambiguity. Its origin must remain visible. Otherwise, the workflow requests clarification or routes the record to the team.
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.