To reduce abandoned carts, check where customers stop: after adding an item, while choosing delivery, filling out the form, or paying. Show the full purchase cost before order confirmation, allow customers to buy without registering, and check the entire journey on a smartphone. Start with errors that prevent customers from completing a purchase they have already chosen.
Adding an item to a cart does not necessarily mean the customer is ready to buy. Some visitors compare offers or put off their decision. So track carts, checkout starts, orders created, and confirmed payments separately. We recommend sending reminders only through a channel the customer has agreed to use, when the store has a proper basis for using that contact for this message.
How to tell browsing from a checkout problem
Baymard Institute explains that customers may leave carts while comparing prices, looking for gifts, or saving items for later. The institute also lists extra costs, mandatory account creation, complicated checkout, and site errors among the reasons purchases are not completed. You can use this list as a starting point for checking your store.
For internal analysis, we recommend grouping cases by what the visitor did. If someone only added an item, their intent is unknown. If they started checkout, selected delivery, and got an error, the store has a specific problem to investigate. If an order was created but payment was not confirmed, the manager should check its status before suggesting another purchase.
For example, in a hypothetical store, a customer added two shoe models, looked at the sizes, and closed the page. Those actions do not reveal why they left. Another customer selected one model and entered an address, but the site failed to load the carrier’s branches. In the second case, a developer can reproduce and fix the error.
We recommend adding a brief optional question after an error or a way to report a problem: “What prevented you from placing your order?” Offer a few clear answers and a field for the customer’s own comment. Do not require a phone number or email address if they are not needed to report the fault.
Which events to measure and how to calculate abandonment rates
Ask the developer to configure events that reflect actions actually taken on the site. Clicking the “Pay” button should mark the start of a payment attempt; confirmation from the payment service should record its result. Otherwise, a report may show successful purchases when customers only opened the payment page.
| Event | When to record it | What it helps you check |
|---|---|---|
| Item added | The item actually appears in the cart | How often customers add items; to count carts and checkout starts, the developer should group events using a technical cart identifier that contains no customer contact details |
| Checkout started | The customer opens the checkout form | Whether customers continue after viewing the cart |
| Delivery selected | The site accepts the delivery method and required details | Whether city, branch, or address selection works |
| Checkout error | The site rejects a field, gets no response from a service, or detects insufficient stock | Which specific error interrupts checkout |
| Order created | The system saves the order and assigns it a number | How many checkout starts result in an order |
| Payment attempt and result | The system creates a payment attempt and then receives its status | The share of confirmed, declined, and incomplete payments |
For every metric, define the denominator, unit of count, and observation period. For example, for an internal report, you could count unique carts created during a week and check their outcome 24 hours after creation. This is one possible approach: choose a period that reflects how customers buy in your store. Do not compare these carts with orders from a different period.
Hypothetical example: out of 200 carts, 120 proceeded to checkout and 90 resulted in orders. The checkout-start rate is 120 ÷ 200 × 100 = 60%. The checkout completion rate is 90 ÷ 120 × 100 = 75%, and the incomplete rate is 25%. In total, 110 of the 200 carts did not become orders, or 55%, but that figure alone does not explain why.
Analyze cash on delivery and prepayment separately. Do not count cash-on-delivery orders as abandoned carts just because there was no online payment. For payment errors, count both the number of failed attempts and the number of orders with such attempts: repeated clicks by one customer should not look like problems affecting many customers.
For diagnosis, send only the technical details you need to analytics: the step, device type, delivery method, payment method, and error code. Do not send phone numbers, addresses, field contents, or payment details. Restrict access to logs and set a retention period; do not try to identify visitors using data from other sources.
Show the full cost and delivery time before confirmation
We recommend showing the item cost, applied discount, and all known expenses associated with the selected purchase method in the cart. If delivery costs depend on the destination, let customers calculate them before filling out the rest of the form. For cash on delivery, explain whether a separate payment transfer fee applies, who receives it, and how the amount is calculated.
If an exact total is not yet available, label the amount as an estimate and explain what it depends on. Update the total after delivery is selected so the customer can review it before confirming. Supplement “delivery at the carrier’s rates” with an available estimate or a clear explanation of how the cost is determined.
A store may not impose an additional fee for payment using a payment instrument, app, or device, or set different prices for the same item for cash and cashless payments. This prohibition is established by paragraph 65 of the NBU Regulation on the issuance and acquiring of payment instruments. Show any separate fee charged by an independent payment service provider, such as a fee for transferring funds on delivery, identifying the recipient and the terms the customer agrees to before placing the order.
Hypothetical example for checking how the total is displayed: items cost UAH 1,200, the discount is UAH 100, delivery is UAH 80, and the agreed fee payable to an independent payment service provider for transferring funds on delivery is UAH 30. In this example, the store does not impose a surcharge for the payment method. The customer’s total cost is 1,200 − 100 + 80 + 30 = UAH 1,210. Show UAH 1,100 payable to the store, UAH 80 to the carrier, and UAH 30 to the payment service provider separately, as well as the total of UAH 1,210.
Also distinguish order preparation time from the estimated transit time. For example, if a hypothetical store dispatches an item on the next business day, that does not mean it will arrive the next day. For an item available on special order, show its status before checkout. Place the available return and warranty terms and a contact for questions nearby so the customer can review them before confirming the purchase.
Allow customers to check out without registering and test the form on a phone
We recommend making guest checkout available and easy to find. Collect information based on the delivery method: pickup does not require a full mailing address, and delivery to a branch does not require an apartment number. If the store needs an additional field, briefly explain its purpose to the customer.
After an order is created, you can offer an account for viewing purchase history. Customers should understand that creating one is an optional next step. We recommend collecting consent for marketing messages separately, with no box checked in advance.
The owner or responsible manager should complete checkout on an actual phone. For a test purchase, choose a regular item and check these actions in order:
- Add an item, change the quantity, and return to the catalog. Make sure the cart retains the correct contents.
- Open checkout without signing in. Check that this option is easy to find.
- Enter contact details and select delivery. Check that the keyboard does not cover suggestions or the continue button.
- Intentionally leave a required field empty. The site should explain beside the field what needs to be corrected and retain the other information entered.
- Change the city or delivery method. Make sure the list of branches and the total update.
- Return from the payment page. Check that the site shows a clear order status and what to do next.
Send every problem you find to the developer with the steps to reproduce it, the browser name, and the expected result. For example: “After the city is changed, the branch field keeps its previous value; it should be cleared and the branches for the new city loaded.” This description makes it easier to check a specific fix.
Check payment, delivery, and stock availability
Payment: save the order and check the payment status
We recommend checking successful payments, declined payments, payment pages being closed, and delayed responses. Use the payment service’s test mode where possible. After an error, the customer should see the saved order number and an available way to continue checkout.
If the payment status is not yet known, do not immediately ask the customer to pay again. First, the system or manager should check the result with the payment service. Use the same order for another attempt, and ask the developer to check protection against duplicate orders when the button is clicked repeatedly. The message to the customer should match the known status: the store should not state a reason for a bank decline that it has not received.
Delivery: prepare for an external service being unavailable
If the list of branches does not load, show a message about the temporary problem and offer the customer a way to try again. If the store can accept an order and confirm delivery details later, make clear that the delivery cost and time still need to be confirmed. The manager should agree on these terms with the customer before payment or dispatch, according to the process selected.
Stock: recheck the specific item variant
We recommend checking available quantity before order confirmation, especially when the website and physical store sell from shared stock. Check the selected size, color, or configuration specifically. If an item is no longer available, explain this beside the relevant item, preserve the rest of the cart, and offer available ways to continue.
For reservations, define the event that starts a reservation, its duration, and who is responsible for releasing the item. If the reservation is created after the order is placed, tell the customer how long it lasts. Do not say “item reserved” until the corresponding operation has actually been completed.
How to set up stock synchronization and order reservations in Torgsoft
If your store keeps its main records in Torgsoft, the paid “Synchronization with an Online Store” feature lets you send product and availability data to your website and import placed orders. A developer is needed to connect the website. Before launch, we recommend agreeing with them on which warehouse stock will be sent and testing a sample order from placement on the website through to receipt in the program. This exchange handles placed orders; recovering abandoned carts requires a separate solution on the website.
To automate the exchange, activate the task on the “Synchronization Time” tab and configure it to update products and import orders. Torgsoft must be running on the computer specified in the task under the specified user; otherwise, automatic synchronization will not run. Set the interval to no more often than once every 10 minutes, taking other synchronization objects into account. We recommend asking a manager to check the last successful exchange and any errors on the “Synchronization Log” tab, so they can quickly spot when stock has not been updated or an order has not been imported. Availability may change between exchanges, so check the available quantity before confirming a purchase.
If “Reserve invoice items” is enabled, the program uses the reservation date from the order or, if none is provided, the number of days set for the synchronization object. We recommend checking both scenarios and aligning the reservation period with the message sent to the customer. If an employee separately creates a reservation through “Sales” and moves the item to a temporary warehouse, the end of the reservation period does not automatically return it to the main warehouse. Assign someone to check expired reservations and return the item once the decision has been made to cancel the order.
How to send an appropriate reminder about an incomplete purchase
Before launching reminders, we recommend determining which contacts the store has a proper basis to message in this way. For a practical process, obtain separate, voluntary consent that specifies the channel and purpose, keep proof of consent, and make it easy to opt out of future reminders. Do not treat a phone number or email entered in a form as a substitute for consent to marketing contact.
If a customer has asked for help completing checkout, the manager can respond to that request. We recommend keeping help with a specific order separate from a promotional offer. Do not look for a visitor’s contact details in other databases or try to identify them from their browsing history.
Before sending each reminder the customer has agreed to receive, check whether the purchase is already complete, consent has not been withdrawn, the item is available, and the price is current. If payment is awaiting confirmation, check its status first. A link back to the purchase must not reveal the customer’s address, phone number, or other details to another person.
One possible starting point to test is a single reminder the day after an incomplete checkout. This is a working hypothesis, not a universal schedule. Sample text, if the customer has agreed to be contacted: “You agreed to receive a reminder about an incomplete checkout at [store name]. You can return to your cart here: [link]. If you had a problem with payment or delivery, contact us at [contact]. Unsubscribe from reminders: [link].”
Measure the number of completed purchases after the message against the number of recipients, as well as opt-outs and complaints. A purchase after an email does not by itself prove the email caused it. If there are enough contacts who have agreed to receive reminders, you can compare randomly selected groups that do and do not receive a reminder, using the same observation period.
How to organize fixes in the store
We recommend starting with errors that block purchases or could lead to repeat payments. Next, check the full price, delivery, and stock, then guest checkout and the form on a phone. Check reminders after customers can complete checkout without obstacles.
- Record the problem. Note the step, the conditions under which it occurs, and the number of cases relative to the number of relevant checkouts or attempts.
- Assign an owner. The developer checks the site, the manager checks order statuses, and the inventory employee checks stock and reservations.
- Define the expected behavior. For example, after a declined payment, the customer sees the saved order and an available next step.
- Check the fix. Repeat the problem scenario, including on a phone, and make sure the information and total remain correct.
- Compare results. Use the same event definitions and denominators, and account for changes in assortment, prices, and visitor sources. If customer inquiries point to a different problem, add it to the next review.
Go back to the previous step