I was shopping at a pharmacy in Toronto recently when I came across the discount tag depicted at below. (Take a moment to study the picture closely if you don’t see the issue). I’ll start with the most likely scenario: an antiquated system without safeguards created a $0 discount as a side-effect of a large pricing change.
Not knowing the internal systems of this particular retailer, I can only guess what happened, but it seems likely that their pricing systems include fields for a regular price and a markdown price (or perhaps multiple markdowns and promotional prices, each with effective dates). The system might print bright yellow discount tags whenever there is an entry in the markdown field. It might also require the business user to select an option to do so, but in any case, this item met the criteria in their system to trigger the label to be printed. A simple safeguard would be to ensure that the markdown price is less than the regular price. It might make even more sense to have a threshold: for example, only print a discount tag if the markdown price is at least 5% less than the regular price.
Safeguards to prevent this type of mistake sound obvious, and they are, but frequently they are not implemented, especially in legacy systems. I’ve personally seen ecommerce systems that display “markups,” where the system displays a higher price as a discount, with the lower regular price in strikethrough font: “$19.99 Now $24.99!” More dangerous to the business, I’ve even seen systems lacking appropriate safeguards (coupled with a dubious business process) that resulted in products frequently being sold for 1 cent.
As an aside, I have personally benefited from a system that lacked appropriate safeguards: as a starving college student, a $100 check deposited to my near-empty bank account was accidentally keyed in by the bank teller as over $350,000. A simple check might have detected that my balance had never been above a few thousand dollars and thus an extra confirmation by the teller was in order. I’m guessing there was no such check. In any case, the transaction went through and you can imagine my surprise when I saw my balance at the ATM later that day. Despite a brief fantasy of cashing out and living life on the run, I informed the bank of the issue the next business day. I’ve always wondered if they would have detected the mistake themselves. Sadly, I didn’t get to keep the full amount, but they were gracious enough to allow me to keep the interest for the four days it sat in my account. Win!
It is difficult when building a system to predict all the ways, both intentionally and accidentally, that it will be used. It’s even possible that there are scenarios where we’d want to display a $0 discount or a 1 cent price. As a product manager building software that could be in use for a decade or more, I always tried to walk the fine line between giving my end users enough flexibility to achieve their (not always predictable) future business goals and not so much that they would shoot themselves in the foot. Rather than trying to lock things down from the outset (AKA, “paving the cowpaths”), my philosophy when implementing a new system is to avoid encoding hard rules that enforce process, except where you know a scenario must absolutely never be allowed to occur. Instead, give end users some latitude, and then, as mistakes like this one happen, work with them to define appropriate detection and safeguards. In some cases, you might want to put up hard barriers to prevent the scenario, whereas, in others, you might choose to simply warn the user but still allow the “bad” thing to happen. Critical to making this approach work, of course, is that the product manager has to remain engaged with the end user and understand how the product is being used in the wild, and she also has to have the resources to implement and deploy updates to the product.
A second possibility is that the retailer was experimenting. I think this is extremely unlikely to be the explanation, but it is actually more interesting to me. The single most effective way to drive sales of an item is by reducing its price. It is my belief that most retailers should focus the bulk of their online testing efforts on exploring the impact of price changes on their business. And by price changes, I mean not just the regular and marked down prices that retailers charge, but also how prices and discounts are displayed throughout the experience. So perhaps this $0 discount was actually a next-level experiment trying to determine if the little yellow discount tag drives sales independent of an actual price reduction! Ok, probably not, but truly engaged retailers should be doing everything they can to understand the factors that influence their customer’s buying behaviors.
So was this simply a lack of safeguards or a sophisticated test of customer behavior? Of the two choices, I’m going with lack of safeguards. But part of me, perhaps the part that bought that tasty chocolate despite having to pay full price, hopes I’m wrong.