She is on her phone on a Tuesday evening, buying a gift voucher from a founder-run restaurant. The dinner is next Saturday. She found the site, she found the voucher page, she tapped the amount she wanted, and now she is looking at a checkout. What happens in the next ninety seconds determines whether the money arrives.
The scene, before any fixes.
This is a worked example, not a client case. Picture a founder-run restaurant that sells gift vouchers online through a standard checkout template. The shape of that checkout is a common one: more screens than the buyer expects, more fields than the transaction requires, and a total that appears only at the end. The buyer arrived with intent. The checkout is the only thing standing between that intent and a completed sale.
70.22% is the average documented online shopping cart abandonment rate. That means for every ten people who reach a checkout, roughly seven leave before paying. For a founder-run operator selling vouchers, event tickets, or prepaid bookings, each of those seven is a high-intent buyer who already chose you and then changed their mind at the counter.
Buying this way has been ordinary for years. In a Pew Research Center, 2016 survey, 79% of U.S. adults had made an online purchase of some kind, and 51% had bought something using a cellphone. The buyer on Tuesday evening is not an edge case. She is the case.
The field audit, run like a working session.
Open the checkout. Count the steps. Count the fields. The average checkout flow in 2024 runs 5.1 steps and contains 11.3 form fields. That is the measured baseline for the industry, not a worst-case outlier.
Now count what taking the money for a voucher actually requires. An amount, a payment method, somewhere to send the receipt. That is the transaction. Everything else in the checkout is overhead: some of it useful, some of it serving the database, some of it surviving only because the template shipped with it and nobody removed it.
The working-session question for each field is not whether it is harmless. It is whether removing it would break the transaction. If the answer is no, the field is a candidate for deletion.
The delta, field by field.
Go through the checkout one field at a time and sort each into one of three buckets.
- Serves the buyer. Email address (so the receipt arrives), payment card details (so the money moves), voucher amount (so the right product is created). These stay.
- Serves the database. Phone number, date of birth, how-did-you-hear. Useful for the operator later, invisible to the buyer now, and often the exact field where the phone goes back in the pocket. If it is not required to complete the transaction, move it out of the checkout entirely.
- Serves nobody. Duplicate address lines, a second email confirmation field, a fax number the template never removed, a title dropdown that nobody filters on. These are friction with no upside. Delete them this week.
“Every field that is not required to take the money is a door the buyer can walk out of.”
In this worked example, the restaurant's voucher checkout asks for a billing address in full: street, city, postcode, country. A digital voucher delivered by email does not ship anywhere. The address serves the template's default field set, not the buyer, and not the restaurant. It is a candidate for deletion.
The rebuild, one afternoon at a time.
None of the three fixes below requires replatforming. Each is a configuration or template change to an existing checkout. Sequence them in an afternoon each, starting with the one that costs the least and recovers the most.
- Put the full total on the first screen. Surprise costs at the end of a checkout are a primary reason buyers abandon. Show the price, any booking fee, and any applicable tax before the buyer has typed a single character. Nothing should change between screen one and the payment screen. If the total is the same throughout, make that visible from the start.
- Make guest checkout the default path. Account creation is a barrier, not a benefit, for a first-time voucher buyer. The guest path should be the prominent option, not the small link below the login form. Offer account creation after the transaction completes, when the buyer has already succeeded and has a reason to return.
- Delete fields until only the money-critical ones remain. Run the three-bucket sort above. Remove everything in bucket three. Move everything in bucket two to a post-purchase preference screen or a profile page. The checkout keeps only what the transaction requires.
If deleting a field would not prevent the money from arriving and the receipt from being sent, the field does not belong in the checkout.
For the illustrative restaurant, the rebuild would follow the same order: work through the field audit, remove the non-essential fields, and surface the total earlier in the flow. No new platform, no new payment processor, no development sprint. The example shows the method; it does not describe a completed client project.
The weekly count.
The teardown ends with two numbers: checkouts started and checkouts completed. One ratio. Pulled once a week and set next to revenue. For a founder-run operator, this screen is where vouchers, gift cards, event tickets, and prepaid bookings become money. A completion ratio nobody tracks will drift while storefront traffic still looks healthy.
Most analytics platforms surface pageviews and sessions readily. The checkout completion ratio usually requires one extra step: a goal or conversion event tied to the order-confirmation page. Set that up before touching a single field. The teardown starts with measurement, not opinions.
Checkout completion rate = completed checkouts ÷ started checkouts × 100. Reviewed weekly next to revenue, it is the one ratio that tells you whether the rebuild is working.
If the ratio improves after the rebuild, the removed fields were friction. If it does not move, the problem is upstream: price, trust, or the moment the buyer arrived at the checkout already uncertain. Either answer is useful. Neither is visible without the count.
The teardown takes an hour. The rebuild takes afternoons. The count takes a spreadsheet column. What it produces is a checkout that asks only what the transaction requires, shows the total before asking for anything, and gets out of the way of the buyer who already decided to buy.
Common questions.
Is cart abandonment really a problem for a narrow catalog like vouchers or event tickets?
Yes, arguably more so. With a small catalog, every abandoned checkout is a high-intent buyer who already chose the product. The average documented online shopping cart abandonment rate is 70.22%, and for a small operator each recovered checkout is real money, not a rounding error in aggregate volume.
Does fixing an abandoning checkout require a full redesign?
No. The operational causes are specific: a total that appears only at the end, a forced account-creation step, and a form that carries fields the transaction does not need. Show the total early, offer a guest path as the default, and remove the non-essential fields. The average checkout flow carries 11.3 form fields, and most of them are not required to take the money.
How can an operator tell whether the checkout is leaking?
Count it. Checkouts started versus checkouts completed, one ratio, once a week, next to revenue. If that number is not available today, adding the two event counts is the first step: the teardown starts with measurement, not opinions about what feels wrong.
Which fix should come first?
Surface the full total before asking for any personal information. It is the change most likely to affect the buyer who was close to completing and stopped when a fee appeared at the end. The guest-path and field-deletion fixes follow, in whatever order the platform makes easiest.
If the checkout teardown surfaces a problem that goes deeper than configuration, we run this as a structured engagement: start a conversation or read how we approach hospitality systems work.
Run this with us.
