Shane Murphy: What a Bahamas Travel Example Reveals About Support

By Shane Ian Murphy | Global Secure founder commentary

Support is often discussed as a separate function after the main product has been designed. I prefer to consider it inside the journey. An invented traveller in the Bahamas, facing an unclear payment status, provides a useful design exercise for Global Secure. No actual customer case or service availability is being reported.

The traveller’s first problem is understanding what has happened. They may not know whether the issue concerns connectivity, an unfinished action or a completed action whose confirmation has not appeared. A support entry point should help them describe the situation without requiring them to diagnose a system they cannot see.

The handover should carry relevant context. A user who has just followed a sequence of screens should not have to retell every visible detail from memory. At the same time, the design should explain what information is shared with support and avoid encouraging people to send secrets or unrelated personal material.

Next comes the expectation of a response. “We have your message” is different from “the issue is resolved.” A useful status separates receipt, investigation and outcome. If an estimated response time is offered, it should have a sound basis and should be revised clearly when circumstances change.

The end of the support journey needs attention as well. A customer should understand what was resolved, what remains open and whether any action is required from them. A closed ticket can be administratively tidy while leaving the person confused. The customer’s understanding is part of the result.

For the invented support scenario, I would write a short incident description using only what the traveller can observe. The screen shows a pending status, the purchase confirmation has not appeared, and the person wants to know what to do. That is enough to begin a useful conversation. Asking the customer to choose an internal technical category before describing the problem may create friction without improving the quality of the information. The support journey should begin with the person's experience and then gather the context needed to investigate.

Next, I would examine each request for information. Is the detail necessary to understand the problem? Does the person know where to find it? Is there a safer, simpler way to identify the relevant action? A well-designed support form should not invite people to paste recovery material or unrelated private documents into an open text box. It should explain what is useful and make clear that sensitive access secrets are not part of a routine support description.

The response can be tested with a change of handler. If another authorised colleague takes over the question, can they understand the steps already attempted and the customer's remaining concern? A clear record should distinguish observations, proposed actions and confirmed results. That helps avoid a frustrating cycle in which each new person asks the same questions or presents an earlier unsuccessful step as a fresh solution. Continuity matters to the customer even when internal responsibility changes during the course of an investigation.

At the end, I would ask the traveller to describe the outcome in their own words. Do they understand whether the purchase completed, what action they need to take and where to return if the issue continues? If they cannot, the closure message needs improvement. A support case is useful as a design lesson too: recurring confusion may reveal a missing explanation in the product itself. The team should examine that possibility before treating every question as an isolated customer misunderstanding.

This hypothetical Bahamas example encourages me to examine support as a continuation of product communication. The best handover starts with the information already available, gives the person a clear next step and keeps uncertainty visible until it has actually been resolved.

Disclosure: This founder commentary was drafted with AI assistance. Illustrative cover photograph; it does not depict a company project or asset.