Cut out Basket Rage by isolating service glitches on your website

Date: 14th February 2011
Author: Deri Jones

(This article by Deri Jones was first published in Internet Retailing magazine.)

Online shopping tends to revolve around helping visitors find and put things into the Basket: in order to reach the overall goal of having them Check Out and buy. But there are a number of areas where the overlap between the Business Teams’ specification of Basket features, and the limitations of technical implementations, mean that online shoppers can be left in a state of rage, frustrated that they can’t get the site to do what they want.

The Rage is even stronger when a site’s behaviour is unpredictable and does not 100% of the time show the symptoms. So two users doing the same task online at the exact same moment can find one hits the problem while the other doesn’t. And the same user can hit a problem one visit, and not the next time. The user can’t find a ‘work around’ strategy of handling the sites quirks, because the behaviour is not consistent.

Frustration builds

For example, a Visitor is left in the dark when trying to add a particular product to the basket on a clothing site. On the product page, the site offers different colours and different sizes for the same product. But, when they choose a size, and choose a colour and Click Add to Basket – sometimes they are told ‘this product is not available’. So the user tries a different colour in the same size – and if they are lucky, it works.

Root cause: the page does not check on the availability of all size/colour combinations until AFTER the Add to Basket click. The solution: sites like Boden show a visible table with only the available combinations of colours and sizes offered, so clicking always works.

A second example is where the product is not buyable at all but is offered to the user when they search. It’s hugely frustrating when a product from a live search you just performed, that you spent time looking at the product details and making a purchasing decision on, is then not for sale at all.

Root causes: for speed reasons, some sites keep a cached list of available products to use for things like search. The downside of this approach is if not set up correctly, the cache can become out of date and hence offer products no longer available. Such caching is also vulnerable to small software tweaks having unexpected impact on the caching accuracy. The solution: 24/7 monitoring of dynamic ‘Add to Basket Journeys’ to show what % of the time this problem is occurring; and help the tech team over-time prove that they have cured it.

‘The price has changed – WTF?!’

This is when a user searches or navigates at site, compares a few products that suit their needs and price but when they click Buy, the Basket shows the product at a different price. This really destroys your shopper’s web site confidence.

Root cause: some web technologies have price calculation engines built in to handle seasonal discounts, deals for special customers, end of line discounts, etc. If the pricing software model has a small bug, unexpected price changes can result. The solution: review the spec for the pricing module. Ask if it is explicitly checked every time any site software update is made and if it is checked explicitly in the User/Acceptance Testing stage.

Through testing your website systems and measuring keynote website performance constantly, all these issues can be overcome. It’s possible to substantially increase visitor rates and customer satisfaction levels by achieving gains in key journey delivery times, increasing ability to handle peak load levels, and reducing error rates on your site – confidence building that fewer Basket Rage incidents has got to be good for business.

At the end of the day: it’s vital to monitor what users do on your site, to experience what they experience.

Top