The abandonment rate everyone quotes, and why it's misleading
Most e-commerce dashboards report cart abandonment somewhere between 60-80%, and the number gets treated as a fixed cost of doing business online. It isn't. A large share of that number is unavoidable window-shopping and price comparison. But a meaningful chunk of it is self-inflicted: checkout flows that ask for an account before anything else, shipping costs that appear on the last step, or forms that don't work correctly on a phone.
Where the friction actually lives
When we audit a checkout flow, we're rarely looking at the “abandon” button. We're looking at the step right before it. Forced account creation is still one of the most common blockers we find — a shopper who's ready to buy gets stopped by a password field. Shipping and tax costs revealed only at the final step is another: the moment a total jumps unexpectedly, trust drops with it. And on mobile, a form that scrolls awkwardly or a payment field that doesn't trigger the right keyboard is often enough to make someone give up on an otherwise-completed purchase.
What we build instead
Guest checkout as the default path, with account creation offered after the order completes, not before
Shipping estimates shown as early as the product page, not held back for a surprise at the end
A clearly-progressed checkout flow with a visible step count, so shoppers know exactly how close they are to done
Real-time validation on payment and address fields, so errors surface immediately instead of after a failed submit
Saved payment and address details for returning customers, so a second purchase takes seconds, not minutes
Recovery is not the same as prevention
Abandoned-cart email flows have their place, but they're a recovery mechanism for a problem that already happened. The more durable fix is removing the friction that caused the abandonment in the first place — and that's a checkout and information-architecture problem, not a marketing one. When we take on e-commerce work, we start by watching real users go through the existing flow before changing a single line of code, because the actual point of drop-off is rarely where a client assumes it is.