Checks 1–3: is the shipping cost, the total and a guest option visible before checkout starts?
The first three checks address the two most common reasons shoppers leave at the cart: a cost they did not expect and a demand they did not want. Shipping cost, or the rule that determines it, must be visible in the cart before the shopper clicks checkout. The total must be the total; taxes and fees that appear only at the last step are a late surprise. A guest checkout must exist and be as visible as the account option.
- Shipping: add an item on a phone as a new visitor; verify the shipping cost or threshold is shown in the cart, not only at checkout.
- Total: note the cart total, then proceed; verify the final total matches with no new fees appearing at the last step.
- Guest: start checkout as a new visitor; verify a guest option is offered without account creation.
Checks 4–6: do the forms validate clearly, autocomplete the address, and keep progress visible?
The form checks cover the friction shoppers feel with their thumbs. Field errors must appear next to the field, in plain language, at the moment the shopper can fix them, not on submit as a red block at the top. Address entry should autocomplete or at least not fight the shopper's format. A progress indicator should tell the shopper how many steps remain, because uncertainty about length is a reason to leave.
- Validation: enter an invalid email and postcode; verify the error appears by the field and says what to fix.
- Address: start typing an address; verify autocomplete or a format-tolerant field, and that country and region defaults are sensible.
- Progress: verify the shopper can see how many steps remain at every stage.
Checks 7–9: are the expected payment options present, is mobile checkout fast, and are errors tracked?
The payment and speed checks are read from data as well as by walking the flow. The payment options must include the wallets and methods the store's shoppers expect in their market; a missing one shows up as exits on the payment step. Mobile checkout speed must be tested on the checkout URLs themselves, not the home page. Error events must be tracked in analytics so that a failing payment or a form exception is visible as a count rather than as a mystery in the drop-off map.
- Payment: list the options on the payment step; verify the wallets common in your market are present and working.
- Speed: run a speed test on the cart and checkout URLs on a mobile profile; verify they are not the slowest pages on the site.
- Errors: verify analytics records checkout error events, and read the count for the last thirty days.
Checks 10–12: are trust and returns in view, does the promo field work, and does confirmation confirm?
The last three checks are about reassurance and closure. Returns and delivery information should be in view during checkout, not only on a policy page, because the questions they answer are the ones that stop a shopper at the last step. The promo code field must work and must not be so prominent that shoppers leave to search for a code. The confirmation page must confirm the order clearly, with what happens next, so the shopper does not reorder or write to support to ask.
- Trust: verify delivery time and the returns summary are visible during checkout without leaving the page.
- Promo: apply a valid and an invalid code; verify both behave clearly, and consider whether the field invites code-hunting.
- Confirmation: complete a test order; verify the confirmation states the order, the delivery expectation and the next step.
How should the checklist be run and recorded?
The checklist should be run on a phone first, as a new customer with an unfamiliar address, because that is the shopper most likely to leave, and then repeated on desktop. Record each check as pass or fail with a note, and keep the record; it is the baseline the next audit is compared with and the evidence for which fixes were worth the most. Repeat it after any theme, app or checkout change, because those are when checks that passed start failing.
Failures suggest hypotheses, not conclusions. A missing wallet is a hypothesis about payment-step exits; the experiment, or the analytics on that step, is what turns it into a finding.
What does the Conversion FTE add to a manual audit?
The Conversion FTE on ftes.ai runs these checks as part of its drop-off map, joins them to the analytics that show where sessions actually leave and how much revenue each leak represents, and turns failures into ranked hypotheses with evidence in the Funnel tab. It then proposes the fix as an experiment, with the change previewed and a sample-size plan, rather than as a redesign. Checks that fail after a theme update are caught the next morning because the map is refreshed daily.
What it does not add is a change to checkout on its own. Checkout fields and payment options are on the always-gated list; a fix there is proposed, and a person decides.