A warehouse reports a damaged pallet. The carrier receives the photos. Customer service asks whether to arrange a replacement. Operations asks who can approve it.
Everyone can see the problem. The customer still cannot get a decision.
At Allmatics, we would approach this as a software problem spanning warehouse, transport, order and customer-service systems. The work is to connect their data, give people a shared view they can act from, and carry approved decisions through to a confirmed operational result.
The following is a worked design example, not an Allmatics client story. It follows a receiving team reporting damaged goods. The approval rules, time limits and actions must come from the actual operating process and commercial agreements.
Start with the decision the customer needs
We would start discovery with the people receiving, approving and executing the work. What decision does the customer need: can the order continue, does it need a replacement, or must someone agree another outcome? Who may authorise it, and which system records that decision? Those answers define the workflow before integrations are chosen.
Keep the physical outcome separate from the carrier claim. A replacement may be authorised while a claim is still being reviewed. Conversely, a claim reference does not prove that replacement goods reached the customer.
In this example, use a parent damage case with two linked workstreams: operational recovery and claim handling. Give each its own owner and closure rule. Show both in the case view so nobody mistakes progress in one for completion of the other.
Turn the report into a case that can be worked
The data layer needs to connect warehouse evidence to the affected order and shipment. We would map the source of each fact and the identifiers linking the records, then capture affected items and quantity, location, reporter, event time, source system, photographs and receiving notes. Missing information should remain visible rather than being filled by assumption.
Allmatics’ published barcode-scanning project provides a concrete example of operational data becoming a usable product: an Android application collects scanner activity, while a web application supports analysis and user management through a dashboard. For this damage scenario, we would extend the design from visibility into case handling. Evidence must be linked to the correct shipment and items; a photo attached to the wrong delivery goes to review.
Give the case its own identifier. Subsequent reports should attach to the right case; a genuinely separate incident must remain distinguishable. Do not use shipment ID alone as a universal duplicate key because one shipment can have more than one problem.
For an integration using Amazon SQS standard queues, AWS documents that a message may be received more than once and recommends idempotent processing. A practical design consequence is to make retries safe: repeated handling of the same source event must not create another case, authorisation or customer message.
Assign the next decision, not just a department
A queue labelled “Operations” is useful for routing. It is incomplete ownership once a case needs action.
For every active step, store a responsible person or explicitly covered role, the decision or task they owe, when it is due, and who takes over if they cannot act. Ownership should survive shift changes.
A handover needs acceptance. Until the receiving owner accepts it, the current owner remains accountable. If nobody accepts, send the case to a defined fallback rather than leaving it between two queues.
Waiting for photos and waiting for approval need different timers. Start the timer at the relevant transition. A repeated event or another reminder should not silently restart it. If a pause is permitted, record the reason and keep total case age visible.
Make the workflow explicit enough to implement
Reported: create or match the case, attach evidence and route it for triage. It leaves this state when an owner accepts the case.
Evidence needed: request the missing item from a named source. It leaves this state when the evidence is checked or an authorised decision records why the process may continue without it.
Decision needed: present the affected order, evidence and permitted options to the authorised role. It leaves this state when that person records a decision and reason.
Action pending: issue the approved instruction to the relevant system or person. It leaves this state when execution is confirmed; a successful request submission alone is insufficient.
Recovery verified: confirm the chosen operational outcome, record the customer update and close the recovery workstream. Leave any unresolved carrier claim visible.
Escalation should preserve the current blocker. An overdue approval remains “Decision needed” with an escalation marker, so the team can still see what must happen next.
Build the dashboard around decisions and actions
For this workflow, we would build an operational case view connected to the source systems. A colleague taking over should see the evidence, current blocker and permitted next action in the same place, with no need to reconstruct the case from email.
For the damaged-pallet example, show: shipment and order; affected quantity; evidence completeness; recovery state; claim state; current owner; next action; due time; blocker; and when each source last updated.
Include actions that match the viewer’s role: request evidence, accept ownership, approve a permitted recovery option, or confirm execution. Keep the decision history, previous values and source references available.
The integrations would carry the decision into the systems doing the work. In our example, the receiving report creates the case. Where supported and authorised, an inventory instruction places affected items on hold. Customer service records the agreed recovery, an approved replacement instruction reaches the order system, and execution updates return to the case. The dashboard shows whether each action is pending, confirmed or failed, with a route for retry or review.
Real-time visibility depends on the source. Where events are available, update the view from them. Where a carrier or legacy system only supports periodic checks, show that timing honestly. An old response must not look like a current fact.
Plan reconciliation as well as event handling: compare the case view against authoritative source records so missed updates, failed commands and stale states can be found and repaired.
Choose where automation can act and where approval stays
This is where Allmatics’ integration and process-automation capabilities are relevant. We would implement the agreed rules as evidence checks, task routing, requests for missing information, deadline tracking and approved downstream actions. The team gets both a live operational view where sources support it and a workflow that continues beyond the dashboard. Higher-impact actions retain the permissions and review rules agreed with the business.
Do not treat a damage report as an automatic finding of carrier liability. Nor should a language model approve a refund or decide whether goods are safe to release simply because it produced a plausible explanation.
If AI helps read notes or summarise evidence, preserve the source material and keep the output reviewable. The workflow still needs a clear decision owner and an explicit authorisation before consequential actions.
Test the awkward cases before launch
Send the same source event twice: the workflow should retain one incident and avoid a second outbound instruction.
Upload evidence for a different shipment: the case should flag the mismatch rather than move forward.
Transfer the case to an unavailable colleague: ownership should remain covered and the fallback should receive the task.
Make the replacement request fail after approval: the case should remain open with the failed action visible.
Finish the replacement while the claim is unresolved: the recovery workstream should close only on its own evidence, and the claim should remain open.
Measure waiting as well as completed cases
Track the interval from report to accepted owner, accepted owner to authorised decision, and decision to verified recovery. Report median and tail duration, such as the 90th percentile, so unusually slow cases remain visible.
Also track overdue steps, cases without accepted ownership, failed outbound actions and reopened recoveries. Define which incident types you compare and whether a timer uses elapsed or business hours. Keep paused time and its reason inspectable.
Measure carrier-claim resolution separately. Otherwise, a long claim investigation can obscure whether customers are receiving timely recovery decisions.
Start with one exception, connect the full path
Allmatics’ logistics offering covers tracking, analytics and integration with existing transport systems and IoT devices. In a project like this, we would bring those software components together around one agreed operational outcome: discovery, connected data, the case interface, workflow rules, system actions and verification.
The barcode-scanning case demonstrates operational data collection and analytics. The damage workflow described here is a proposed design, not a claim that Allmatics has delivered a damage-claims engine.
A first implementation should cover one incident type through to a verified outcome. Agree the decision rules, map the systems that own each fact, build the interface and integrations, then test retries, failed actions and shift handovers. This gives operations and engineering a complete workflow to evaluate before adding more exception types.
To assess the software components involved, explore Allmatics logistics solutions. Start the process review with one question: if the person who raised the incident goes off shift, can the next person see what is owed, who owes it, and what will prove it is done?