The checkout worked, so why were ready customers still leaving?

A checkout can work and still cost sales

The retailer's checkout had no obvious technical failure. Customers could add an item, enter an address, pay and receive confirmation. Pages loaded and orders arrived every day.

Yet plenty of customers reached the basket and started checkout but did not finish. The team had fixed visible bugs and shortened one form. None of that explained why people who appeared ready to buy were leaving.

The initial assumption was that checkout was too long, but that was not a useful diagnosis. Friction is not simply the number of taps. It is the effort and uncertainty involved in deciding whether to proceed.

Our task was to find where confidence dropped, identify the commercially important problems and give the team a fix list they could ship.

Starting with the evidence already available

We began with analytics, order data, payment logs and customer-service themes to locate the loss and expose gaps in the evidence.

The funnel showed a noticeable drop when customers moved from basket to delivery. Mobile visitors abandoned more often than desktop visitors. Payment failures were visible, but the raw event did not distinguish between a declined card, an input error, a customer closing the page or a tracking gap. Support messages frequently mentioned delivery timing, returns and promotion codes, although these were not tagged consistently.

We split the funnel by device, customer type, delivery region, payment method and acquisition source. We also checked whether analytics events matched the interface. If a delivery step sends two events or a payment redirect drops the session identifier, a tidy chart can tell a false story.

The data located likely concerns. It could not explain hesitation when delivery costs appeared or an error occurred. For that, we needed to watch people shop.

Moderated mobile checkout testing

Most checkout sessions happened on mobile, so mobile was the centre of the research. We recruited frequent and occasional shoppers who had recently bought similar products online. Participants used their own phones where practical, exposing complications such as password managers, browser autofill and interruptions.

Each person was given a realistic purchase task and a budget, then asked to choose a product and proceed as they normally would. We did not tell them which delivery option to select or when to look for returns information. The aim was to see what they needed at each decision point, not to test whether they could follow our instructions.

We observed the full journey from product page to confirmation, including:

  • when people looked for delivery cost and expected arrival dates;
  • whether guest checkout was clearly available and how account prompts affected willingness to continue;
  • whether returns information answered the question they actually had;
  • how autofill, address lookup and errors behaved on a small screen;
  • which reassurance messages answered a concern and which looked like sales copy;
  • whether the final total matched the price they thought they had agreed to.

We used a safe test environment and test payment details. We also noted hesitation, rereading and backtracking. A person can complete checkout while remaining unsure, so completion alone would have missed much of the problem.

What customers were reacting to

The checkout was not losing customers at one dramatic breaking point. It was accumulating small doubts and revealing important information too late.

Delivery was the clearest example. Product pages suggested quick dispatch, but the charge and estimated date appeared only after an address was entered. The charge itself was not always the objection. The surprise was.

Guest checkout existed, but the page presented account sign-in first and used a subdued link for continuing without an account. Several participants thought registration was required. The business regarded an account as convenient. Some customers saw it as a condition attached to buying.

Returns information was available in the help centre, but not where the decision was made. Customers wanted to know whether they could return the product, how long they had and who paid the postage. A generic "easy returns" message did little to answer those questions.

Payment errors caused the sharpest loss of confidence. One message cleared part of the form without saying whether payment had been attempted. The interface focused on correcting a field when the customer's question was, "Has my order gone through?"

Trust messages near the payment button also competed for attention. Reassurance works when it answers a concern at the right moment. A cluster of badges can look defensive and distract from the order total.

Mapping the journey around decisions, not pages

We turned the sessions, funnel evidence and support themes into a journey map organised around customer decisions rather than screens.

At the product page, the decision was whether the item and delivery promise justified adding to basket. At the basket, it was whether the total was complete and registration optional. At delivery, it was whether the charge and timing were acceptable. At payment, it was whether the transaction felt safe and errors were recoverable.

For each decision, the map recorded the customer's question, observed behaviour, business consequence and likely owner. This stopped every problem being handed to the design team. Some belonged to content, analytics, operations or the payment integration.

A prioritised fix list

We ranked recommendations by customer impact, likely revenue exposure, confidence in the evidence and implementation effort. We did not promise an uplift for each fix. Research can identify a credible problem, but it cannot guarantee a percentage before release.

The first release focused on points that affected many customers and could be measured cleanly:

  1. Show delivery cost ranges and realistic timing earlier, with postcode-specific detail when available.
  2. Present guest checkout as a clear, equal route rather than a secondary link beneath account sign-in.
  3. Keep the order total visible and explain any change immediately.
  4. Put concise, product-relevant returns information near the basket decision, linking to full terms.
  5. Rewrite payment errors to state what happened, whether a charge was made and what the customer should do next.
  6. Preserve entered details after a recoverable error and test that behaviour across common mobile browsers.
  7. Reduce competing trust badges and keep only reassurance supported by an actual policy or service.

Operational questions such as delivery-date accuracy were tracked separately. There is little value in polishing a promise the fulfilment process cannot keep.

Measuring what changed

We agreed the measurement plan before release. The primary measure was completed orders among eligible checkout starters. Supporting measures covered step progression, recovery from payment errors, guest checkout, support contacts and cancellations.

Guardrails mattered. Higher conversion would not be a win if customers bought with the wrong delivery expectation and then cancelled. We monitored delivery contacts, cancellations, returns and complaints alongside sales.

Where traffic allowed, we tested changes against a control. Otherwise, the team staged the release and compared matched periods while noting promotions, stock, seasonality and payment-provider changes. Short follow-up sessions checked whether the revised journey was clearer.

Illustrative results: sample reporting only

Sample results only: The figures below are invented examples showing how outcomes could be reported. They are not client results and should not be read as evidence of an actual engagement.
  • Sample result: mobile checkout completion increased from 41.2% to 48.7% during a controlled four-week comparison.
  • Sample result: abandonment on the delivery step fell by 18% after delivery cost and timing were shown earlier.
  • Sample result: use of guest checkout increased from 54% to 71% after it was presented as a clear route.
  • Sample result: successful completion after a recoverable payment error rose from 22% to 37%.
  • Sample result: delivery-related contacts per 1,000 orders fell by 24%, with no increase in delivery-related cancellations.
  • Sample result: the retailer recorded a 9.6% relative increase in revenue per mobile checkout starter, excluding a promotional period.

These sample figures need their method stated beside them. "Conversion increased" is incomplete without the baseline, period, audience, denominator and relevant changes elsewhere in the business. A credible case study must also report any measure that did not improve.

What the work demonstrated

Checkout optimisation is often treated as a hunt for a magic button or dramatic uplift. The work is more disciplined: find the decisions customers must make, separate observed problems from team opinion, fix the issues with the strongest evidence and then measure sales alongside customer consequences.

The checkout already functioned. The opportunity came from making price, choice, recovery and policy clearer at the point each became relevant. That is often more useful than a complete redesign.

Have a similar usability question?

Tell us which journey matters, what evidence you already have and what decision the research needs to support. We will recommend a proportionate audit or research approach.

Discuss the project

← All insights