- Who is this for?
- Transport leaders, operations managers, order management teams, and IT teams
- Question addressed
- Understand how Vigilo identifies the intent of an event before acting on a transport record.
Key takeaways
- The same message may mean create, update, cancel, or simply add information to a record.
- Intent is a classification supported by traceable evidence and context, not mind-reading.
- Vigilo adapts this classification to each organization’s channels, TMS, and approved operating practices.
- Uncertain intent and sensitive actions remain subject to the defined escalation rule.
- A reliable change keeps the previous value, the requested value, its source, and the state read back from the TMS.
- A cancellation must identify what is being withdrawn: the entire shipment, a recent change, or an action that is still pending.
- When the record, sender, or intended outcome remains uncertain, requesting approval is an operational decision in its own right.
A message does not always include its own instructions
“Same transport as Monday, but deliver on Friday” may be a new order based on a previous template or a change to an open record. “Please disregard my last message” may withdraw one correction without cancelling the transport itself. The wording alone is not enough to determine the expected action.
Before writing anything to a system, Vigilo addresses an operational question: what does this event change in the record? This step protects the workflow from treating a change as a creation, a cancellation as an update, or an additional document as a new order.
The elements Vigilo brings together
These signals do not carry the same weight in every organization. An EDI reference may be decisive in one flow and secondary in another. A customer may require every cancellation to be confirmed in its portal. The workflow is therefore configured and tested against the systems and operating methods in use, rather than built around an assumed universal TMS model.
- 01Incoming signal
Channel, sender, timestamp, subject, content, attachments, and visible identifiers.
- 02Candidate record
Customer reference, TMS order, route, dates, contacts, and operational status.
- 03Timeline
Earlier requests, superseded versions, approvals, and actions already completed.
- 04Approved rules
Source priority, change deadlines, cancellation rights, and cases requiring approval.
- 05Expected outcome
Create, update, cancel, complete, request clarification, or hand the case to the team.
Three similar inputs, three different decisions
| Situation | Observed input | Decision | Outcome | Boundary |
|---|---|---|---|---|
| New order | An email contains a route, date, and reference that match no open record. | Classify the request as a creation and complete only approved data. | Prepare a TMS-ready record with its sources and any fields still requiring confirmation. | A reused reference or two close matches requires review. |
| Change | The customer moves the time slot and cites an order that already exists. | Attach the message to the record, compare the old and new values, and apply the change rule. | Update the slot or present it to the operator; keep the previous value in the timeline. | A late, conflicting, or out-of-scope change is handed to the team. |
| Cancellation | A message asks the carrier to “drop the shipment” and includes a known reference. | Check the targeted record, the sender’s authority, and the cancellation conditions. | Prepare or complete the cancellation according to the approved permission level, retaining the request. | Ambiguous language or sensitive consequences rule out a silent cancellation. |
Example: a change received less than 24 hours before pickup
A shipper writes: “For order 2847, please move tomorrow’s delivery to 2 p.m.” The reference matches an active record, but the new slot is requested less than 24 hours before pickup. Vigilo identifies that this is neither a new order nor information with no operational effect: the message asks for a change to an existing record.
The workflow then checks the rule for that customer and transport type. If changes inside 24 hours require operations approval, Vigilo prepares the difference between the previous and requested slots, assembles the source message and current TMS state, and requests that approval. Adaptability lies in this configuration: the threshold, reviewers, and action path follow the company’s actual way of working.
Reasoning like an operator without copying tacit habits blindly
An experienced operator does not read only the latest email. They recognize the contact, remember previous conversations, review the record, and know which operating habits matter. Vigilo follows the same continuity of reasoning while keeping the evidence it uses visible and reviewable.
Existing procedures accelerate setup. When similar human decisions recur in comparable contexts, Vigilo can also surface a candidate rule. The proposal remains connected to the cases behind it and becomes active only after the team validates its meaning, scope, and exceptions.
Adaptation across the full workflow
This adaptability does not mean that every TMS and every case is covered without preparation. It means that Vigilo combines reusable capabilities — observation, context, rules, action, and verification — and configures them for a real scope. Coverage expands as cases are observed, tested, and approved.
- the channels through which events arrive;
- the identifiers available to match a record;
- the vocabulary and formats used by partners;
- the fields, screens, and states of the existing TMS;
- the authorization, control, and escalation rules;
- the evidence the team needs to retain.
What the team should be able to audit
A useful pilot measures record matching, intent classification, and action quality separately. Accurate reading cannot offset an uncertain match, and correctly identified intent does not prove that the target system accepted the action. Every stage must remain observable.
- the event that triggered the classification;
- the record and sources used for the decision;
- the selected intent and discarded alternatives;
- the rule or approval authorizing the action;
- the observed outcome and the reason for any escalation.
Before and after: make every change verifiable
A change should never overwrite a value without showing what changed. The record must connect the state read before the action, the incoming request, the rule or approval applied, and the state read back afterward. This comparison protects against three separate failures: changing the wrong shipment, carrying over an incomplete value, or assuming that an update succeeded when the TMS retained the previous state.
Fictional example: TMS record TR-2847 shows delivery on September 11 between 8 and 10 a.m. for 18 pallets. At 9:42 a.m., an authorized contact asks to move delivery to September 12 between 2 and 4 p.m., with no quantity change. The prepared action covers only the date and time window. After execution, the expected read-back is therefore: September 12, 2 to 4 p.m., 18 pallets, and the same record reference. Any other difference, or a missing update, prevents the case from being closed.
| Field | Before | Incoming request | Expected after state | Check |
|---|---|---|---|---|
| Delivery date | September 11 | Move to September 12 | September 12 | Read the saved date from the targeted record. |
| Time window | 8–10 a.m. | Move to 2–4 p.m. | 2–4 p.m. | Compare both ends of the time window. |
| Quantity | 18 pallets | No change requested | 18 pallets | Confirm that a field outside the request was not altered. |
| Version and evidence | Current TMS version | Email received at 9:42 a.m. | New version linked to the email | Retain the source, timestamp, and observed outcome. |
Timeline: distinguish cancelling a shipment from withdrawing a change
The latest message can only be interpreted in light of the events that came before it. “Cancel my change” and “cancel the shipment” target different objects. In the first case, the record may need to return to an earlier version; in the second, the shipment itself changes status. If the wording does not settle the question, neither action should be inferred silently.
- 018:10 a.m. · Creation
An order is received, linked to a customer reference, and created for delivery on September 11.
- 029:42 a.m. · Change requested
The customer asks to move delivery to September 12. The event remains attached to the original order and defines a new expected version.
- 039:51 a.m. · Ambiguous message
The customer writes: “Cancel that—we will keep the first date after all.” “Cancel” probably refers to the rescheduling request, but not necessarily to the shipment.
- 04Decision · Targeted approval
The workflow presents the initial version, the requested change, and the latest message, then asks a closed question: return to September 11 or cancel the entire shipment?
- 05After the decision · Action and read-back
Only the confirmed action is performed. The record status, date, and version are then read back before the case is closed.
Decision matrix: create, change, cancel, or request approval
Intent classification must lead to an explicit decision. The matrix below is a general method: decisive references, permissions, and checks must be configured and tested for each workflow. A keyword alone is never enough to select a row.
| Decision | Minimum observable conditions | Prepared action | Check before closure | When not to act |
|---|---|---|---|---|
| Create | No matching record is found; the request contains the required data or an approved rule can supply it. | Prepare a new record without treating an old reference as proof of a match. | Find the new TMS reference and read back the key fields. | A similar record exists, a reference has been reused, or critical data is missing. |
| Change | One record is identified; the values to replace are explicit; the sender and applicable rule authorize the change. | Apply only the approved differences and retain the superseded values. | Read back the changed fields, critical untouched fields, and the record version. | Two records are plausible, sources conflict, or the change falls outside the authorized scope. |
| Cancel | The targeted record, object of the cancellation, sender authority, and applicable procedure are established. | Prepare or perform the approved status change without deleting the history or evidence. | Read back the status and confirm that no other shipment or event was cancelled. | The message may refer to a change, option, or pending action rather than the entire shipment. |
| Request approval | A required condition remains uncertain or the action explicitly requires human authorization. | Present the candidate records, before-and-after view, conflicting sources, and a closed question. | Record the decision, its author, its scope, and the state read back after any resulting action. | Never treat the absence of a response as implicit permission. |
Frequently asked questions
Direct answers
Can Vigilo understand every possible wording?
No. Quality depends on available sources, context, and the tested scope. Uncertain wording or situations are handed off according to the defined rules.
Do all rules have to be documented before the project starts?
No. Existing rules make setup faster. An observation phase can also uncover recurring decisions, which become candidate rules before any activation.
How does Vigilo adapt to a specific TMS?
The workflow is configured around that TMS’s fields, screens, states, access methods, and controls. An API can be used when appropriate; validated user-interface interaction can extend the scope where needed.
Can a cancellation be automated?
Only when scope, authority, controls, and permission level have been explicitly approved. It may remain a prepared action or an entirely human decision.
How can a change be prevented from creating a duplicate TMS record?
First link the event to one record, compare its current state with the request, and read back that same record after the action. If the match remains ambiguous, the workflow requests approval instead of creating or changing a record.
What should happen when a customer only writes “cancel the change”?
Reconstruct the timeline to identify the affected version and the state to restore. If several changes followed one another, or the message could refer to the whole shipment, request explicit confirmation before taking action.
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.