A demonstration closes a trip with one click. In daily work, a driver submits a document with a reservation, the customer changes the receiving time and finance disputes an additional charge. A transport director needs to test those transitions. Make one complete order journey the common basis for TMS selection, integration assessment and acceptance. The example below is hypothetical; its figures define test inputs and do not describe a customer implementation.
Start with the decision the system must support
A hypothetical distributor sends 12 pallets to two addresses. ERP holds the order and agreed rate, WMS confirms cargo readiness and a dispatcher selects a carrier in the TMS. After loading, the customer requests a different time for the second delivery. The process must retain the original promise, approve its replacement, replan the resource and preserve the basis for an additional charge. This is a test journey, rather than a list of desired screens.
Make the transport director accountable for selection. The warehouse confirms physical readiness, a finance manager defines settlement conditions and an architect assesses data exchange. Each identifies the event that actually completes their work. If finance requires document verification before closing its part of the trip, that pending work needs to remain visible alongside delivery completion.
The GOV.UK discovery guidance recommends understanding needs and constraints before building a solution. Our practical application is to collect actual examples of orders, corrections and settlements after removing personal data. Identify constraints that cannot change and those that could be addressed through process changes. Otherwise, suppliers will estimate assumptions that the client team has not yet tested.
Sources: [1]
Follow the order through every transfer of responsibility
The input package should contain an order identifier and version, addresses and time windows, quantities and units, resource requirements and the rate basis. Identify the system that owns each field. Submit the order twice and verify that only one trip exists. Then send an obsolete version: the system should visibly reject it or route it for review rather than silently overwrite current information.
The first destination accepts its full allocation. At the second, one pallet is recorded as damaged. The dispatcher receives a separate work item, an owner and a next review time. The document records accepted quantities and reservations; the vehicle position only adds context to the timeline. Finance retains the agreed price, the disputed additional charge and an authorised human decision for each item.
Interrupt the integration after an event has been recorded but before receipt has been acknowledged. When service resumes, a repeated message must not create a second cost entry. This is a proposed reliability test. It reveals whether the team can explain the difference between a transport event, a technical message and a financial transaction, then restore consistent records without manually guessing how many entries need repair.
Compare evidence and the cost of dependencies
Record whether each step uses a standard function, configuration, integration or custom development. Showing a standard function does not prove that it works with your roles and data. Repeat the action under a dispatcher account, then verify that this user cannot approve their own disputed charge. Judge the authority boundary by the observed result.
The comparison should include master data maintenance, exchange monitoring, customisation updates and evidence export as well as licensing. Do not turn uncertainty into a fictitiously precise price: record an estimate range and the condition that will narrow it. If a required integration depends on an external carrier, retain a separate checkpoint with an owner and a date for confirming availability.
NIST SP 800-160 addresses requirements, integration, verification and validation across the system lifecycle. Our proposed application is a reproducible chain of records for the chosen scenario. The publication does not certify a particular TMS or select a commercial winner. The decision table distinguishes demonstrated behaviour from work that still needs evidence.
↔ Scroll the table horizontally
| Observation | Decision | Evidence required |
|---|---|---|
| Scenario works as supplied | Retain the candidate | Records and action history |
| Configuration is needed | Retest after configuration | Identical data and roles |
| Development is required | Record the dependency | Separate acceptance test |
| Critical control is impossible | Reject the candidate | Recorded failed test |
Sources: [2]
Carry the scenario into acceptance and rollout
Before selecting the supplier, define expected outputs: one current order, one trip, two delivery results, a damage record, an approved change and a reconciled settlement. For each output retain its identifier, actor, timestamp and supporting record. Another employee should be able to reproduce the test result without the demonstrator explaining missing steps. An unproven function remains an open condition of the decision.
Run the pilot on a bounded group of orders that can be reconciled against existing records. Agree how the operation would return to the previous workflow: who decides, which new transactions stop and how completed work is carried across. A return must preserve the damage document and avoid resending an approved cost. Recovery therefore belongs in acceptance alongside an ordinary delivery.
After the pilot, the transport director compares observed exceptions with the agreed scenario. Separate new requirements from defects in behaviour already promised. Operations, data and finance owners confirm completion of the stage. The useful next step is to select one difficult delivery, reconstruct its evidence trail and turn it into a shared test for candidate systems.
Action checklist
- Freeze the initial order, version, cargo units and both delivery windows.
- Name owners for the receiving-time change, damage record and disputed charge.
- Test repeated messages, an unavailable integration and recovery of exchange.
- Retain inputs, outputs and unresolved dependencies in the acceptance record.
Questions and answers
Is one scenario enough to select a system?
One journey provides a common comparison baseline. Add scenarios when the transport mode, contractual model or critical constraint changes. Avoid expanding the test solely to increase the number of features examined.
How should a promised custom feature be assessed?
Record an unproven dependency with its expected result, delivery date and owner. Require a separate demonstration on agreed data before making a commitment that depends on the feature.