Shane Murphy: Explaining a Failed Booking to a Cambridge Customer

I am Shane Ian Murphy, a former co-founder and Chief Business Development Officer of Limitless Mobile and the founder of Global Secure App. This is an affiliated founder's design note about how a service should explain a failed transaction. It sets out requirements I want to examine, rather than claiming that a particular process is already operating. The central question is simple: when the screen reports a problem, can the customer tell what happened to their instruction, their money and the task they were trying to finish?

Consider a fictional Cambridge customer booking a place at a local workshop. The customer presses the payment button, waits, and sees “Something went wrong.” There are several possible meanings. The instruction might never have reached the service. It might have been accepted without a response reaching the customer. A payment might be recorded while delivery is still unconfirmed. The same sentence cannot usefully describe all those situations.

The first design requirement is therefore an honest statement of what is known. “We could not confirm the outcome” is different from “The payment failed.” The service should not select the more reassuring description unless its records support it. Equally, uncertainty should not become an excuse for leaving the customer with an unexplained warning and no route forward.

A useful status gives the customer a reference and a next step. In our hypothetical example, the page could identify the purchase being checked and explain whether the customer should wait or contact support. Any instruction about trying again must reflect the actual behaviour of the system. Encouraging a second attempt without understanding the first can make the problem harder to resolve.

I would test that explanation using a small record of the event. It should distinguish the customer's request, the confirmation received from a provider, and delivery of the intended service. A missing confirmation should remain visible as a missing confirmation. It should not silently become proof of success or proof of failure.

These distinctions matter because the customer experiences one task, even when several organisations help perform it. They bought something or tried to move money. They did not volunteer to reconcile contradictory messages from a collection of systems. A single support entry point is useful only if the people behind it can establish who is investigating and what information is still needed.

A support handover should preserve the relevant facts already supplied. The receiving team should be able to identify the original instruction, the latest confirmed position and the unanswered question. Asking the customer to repeat the whole account may be necessary when information cannot appropriately be shared, but it should not become the default substitute for an organised case record.

Updates also need a reason. “We are looking into it” can acknowledge a report, but repeating it does not explain progress. A better update identifies a change: a provider has acknowledged the enquiry, a record has been located, or a particular confirmation is still outstanding. If nothing has changed, say that plainly and give the next agreed point for an update.

Timescales should be described with the same care. A target is not a guarantee. A provider's estimate is not a completed action. The customer needs to know which statement they are reading, particularly when another organisation controls the next step. A date should help them plan, not merely make the support response sound decisive.

The final record deserves as much attention as the first alert. If an entry was reversed, connect the reversal to the original item. If delivery eventually completed, explain how that relates to the earlier warning. If the investigation cannot establish a particular fact, the explanation should retain that limitation. Closing a support case does not by itself settle every uncertainty.

A practical review can follow the hypothetical purchase from beginning to end. Read the first warning, the support acknowledgement, each update and the closing message together. Do they describe the same event consistently? Does every claimed outcome have supporting information? Can a person unfamiliar with the internal systems understand what changed?

For me, this is a useful standard for product planning: the records and the customer explanation should tell a coherent story. A polished screen is only one part of service quality. The experience after an interruption shows whether the product has made room for uncertainty, responsibility and a clear account of the result.