Interesting bit of marketing spin this week from Marie Claire magazine – who reckon that their latest recommended must-have beauty product was so much in demand that it crashed the Boots.com web site!
Confidence in Boots takes a knock from that, doesn’t it? And today (3 days later) , the product is in stock.
Humm, kind of bad manners of them to tell tales on Boot’s website problems.
And actually…today July 22nd I read that:
‘…a Boots spokeswoman told Web User that the Boots site didn’t crash at all…”
So was it purely a journalists fevered desire to spin a story and truth was the casualty?
But in general, is it ever polite for one company with a website to point out the failings of others’ websites?
In this case, there may even be a case of the pot calling the kettle black: Marie-Claire’s own site has a shopping section, and you’ll soon find as you browse there that it’s not all good: un-friendly error messages like this are not far away:
Not Found The requested URL /flashtalking/ftlocal.html was not found on this server.
But actually this is a dilemna faced by web performance and user journey testing teams like ourselves the world over: when we come across problems at major companies on line, should we name and shame, or keep it quiet.
If you’re doing a short project to measure patterns across a bunch of companies in a sector and find that some are better than others – should the write-up name the worst performers or not?
Naming the best performers is of course more acceptable, praise is rarely rejected!
Whereas naming and shaming is not such a polite way of treating others, who may even be potential clients of course!
Mentioning a bogus Boots web site crash is showing Marie Claire in a bad light.
In my previous company where we did security testing, there was no question: it would be very dangerous to name web sites that have security issues exposed!
But back at the Boots.com site: they do seem to have a lot of products offered online that you can’t actually buy online, due to being out of stock: about 100, (if Google was up to date).
Boots also allow you to navigate by Brand A-Z and find ‘Kylie Couture’ – only to get a page with no products at all on it
Of course these are merchandising decisions: whether to hide products that can’t be bought right now, or to let people find them, hoping that they will not be too unhappy to realise they’ll have to come back at a later date to order them. Of course, a likely outcome is that instead they may buy from an alternative site.
Some merchandisers allow the user to request to be emailed when the product is back in stock -that’s a nice touch.
As web user journey testers, we come across a number of subtle merchandising complexities in 24/7 web monitoring of core User Journeys like Add to Basket:
Home page -> click on Womenswear Womenswear – > enter a random product search word and click search Products list – > choose a product at random from the list Product page – > chose colour/ size and click Add to Basket Basket page: check basket has updated and finish
With the fact of not all products being buyable – there is the problem that the Journey cannot actually get to the end, any time that it randomly finds a product that is not buyable.
What to do? We commonly have to script Journeys to intelligently re-navigate the site and find a product that can be added to the basket: more complexity for our test team, but our test engine is good at that sort of thing; and it allows an otherwise non-monitorable website to get performance measures for crucial money-making Add to Basket and Check-Out journeys.
And for some merchandisers: we can play a crucial role in finding out immediately if unbuyable products are on their site: if they have tasked their eCommerce hosting company with ensuring this should never happen, but then hear rumours that now and again it does: then our hard evidence metrics can help them see how big the problem is, and help them to negotiate with their hoster to design the problem out.