Who can act when an order stalls between systems?

Start with one complete piece of work, such as an accepted order becoming a warehouse instruction. Bring together the people who promise delivery, prepare it and handle the records afterwards. Ask what each person needs to know before acting.

‘Sent’, ‘received’ and ‘ready for dispatch’ describe different events. A single green indicator can conceal those differences. Agree the meaning of each status before deciding where it appears on a screen. In particular, identify the point at which the business can safely make its next commitment to the customer.

Then decide how much delay the work can tolerate. An address correction shortly before dispatch needs different attention from a routine customer-record update. Set a follow-up threshold around that consequence. The technical design should make overdue work visible to a responsible role, rather than leaving colleagues to discover it through a customer complaint.

Choosing one application as the master of everything rarely answers the practical questions. Sales may own the agreed delivery date, while the warehouse owns the actual dispatch record. Finance may be responsible for the invoice status. Each fact has a different purpose and a different person authorised to change it.

Write down where an accepted change belongs and which other applications need it. Include the route for corrections. Updating a delivery promise must not silently imply that a parcel already on a vehicle has been stopped.

Ask employees to bring examples they currently resolve with calls, spreadsheets or handwritten notes. Those workarounds can reveal missing decisions. Keep the useful judgement they contain and give it a dependable place in the process. The aim is for colleagues to understand an exception without needing the one person who remembers every previous incident.

A message saying ‘integration failed’ leaves the operational work unfinished. An employee needs to identify the order, the last confirmed step, how long it has been waiting and who can take the next action. A technical maintainer may need detailed logs; a planner needs a clear account of what remains uncertain.

Use a small set of recognisable situations to agree the response:

What the team knows	A useful response to design
The receiving system has accepted the job but has not finished	Show the expected wait and prevent casual duplicate entry.
Required information is missing	Direct an authorised colleague to correct the source record.
A connection ended without a confirmed outcome	Establish whether the existing job was processed before sending another.
Earlier steps completed but a later step failed	Decide which completed work remains valid and what needs recovery.

These are starting points for design, not rules to apply blindly. A planner might be authorised to retry an unchanged request, while altering a released dispatch requires a warehouse colleague. Agree who covers an absence and when customer contact is needed. Responsibility without the means to act merely moves the problem onto the employee.

An unanswered request can leave its sender uncertain even when the receiver has acted. The Amazon Builders’ Library explains how an agreed request identifier helps a service recognise repeat attempts and avoid additional effects. This depends on support in the receiving service; attaching a number alone provides no guarantee.

Ask the supplier to demonstrate a repeated order submission and show the resulting records. Then change the order and repeat the exercise. A retry of the same instruction and a new business decision need distinct treatment.

Include the recovery arrangements in the handover documentation: how long repeat requests remain recognisable, where to find their outcome and what happens outside that window. If an existing package cannot support safe repetition, agree how staff establish the result before proceeding. A limitation that people can work with is more useful than a promise of automatic recovery that the interface cannot deliver.

Return to the warehouse example. Suppose the goods have been picked but sales never receives confirmation. Recreating the whole order could produce more work when all that is missing is one acknowledgement. The right recovery depends on what has already happened and what remains possible.

Microsoft's Compensating Transaction pattern describes recovery that follows business rules rather than simply restoring an earlier database state. Some situations still require human intervention.

For your own process, distinguish continuing, correcting and stopping. A database edit cannot physically recall a dispatched parcel. Give the responsible employee the current facts and the customer agreement, then record the chosen action and its reason. Another colleague should be able to continue from that record without piecing together several private conversations.

Begin with a limited flow, such as accepted orders moving into warehouse preparation. In a safe test environment, try a normal transfer, a duplicate message, missing information, a delayed response and failure after partial completion. Use fictional data and prevent real dispatches or customer notifications.

Let the people who will operate the process handle these scenarios with the proposed screens and guidance. Can they distinguish confirmed facts from unknown outcomes? Can they choose an authorised action and explain the next step to a customer? Afterwards, inspect both systems for the same intended business result. A successful technical response is only one piece of that evidence.

During initial use, review outstanding handovers, their age and the effort needed to resolve them. Discuss repeated causes with employees. Use the information to improve the process and its support, rather than to rank individuals dealing with its shortcomings.

Systems integration brings the connection, business rules and follow-up together. Where ownership or authority is still unclear, business process analysis can establish those decisions as a separate engagement. A useful starting point is one recent stalled handover: what had been promised, what could the employee see and which decision could they not safely make?