Connected work
A connection needs an exception queue people can understand
Show unresolved transfers as work with an owner, rather than hiding them behind a successful-looking dashboard.
An order connection works for most records. The few that fail are the ones staff discover through customer complaints. A useful connection needs a visible, manageable path for exceptions as well as a way to transfer normal records.
Name the unfinished business action
For a fictional Estonian supplier, imagine a delivery instruction that cannot reach the fulfilment tool because a required destination detail is missing. The office needs to know which order is affected, what information is missing and who should resolve it.
“Integration failed” describes a technical event. “Order requires a delivery contact before release” describes work a person can act on. Keep suitable diagnostic detail available to authorised support without making it the customer's explanation.
Decide what a retry means
Record whether correcting the source should automatically retry the transfer or whether a colleague must approve it. Consider a record that may already have arrived even though its acknowledgment was lost. Repeating an action should not quietly create a second order.
W3C's notification guidance supports clear feedback about outcomes. The business rules for retries and duplicate handling still need to be designed for the actual tools; the guidance does not choose those rules.
Review the queue as a working day
Prepare three invented exceptions: missing information, unavailable destination and a suspected duplicate. Ask the team to identify the next action for each. Check whether the queue distinguishes a new issue from one already being investigated.
A system integration project should leave the business with this handling process. A transfer percentage is useful context, but it is not a substitute for knowing what happens to the records that need attention.
Further reading: W3C guidance on understandable outcomes.