Revenue is lost every year because of unexpected things that go wrong during a user’s online experience. Sophisticated companies have contingency plans for when things go unexpectedly wrong — or unexpectedly well. Today, a look at some best practices in contingency planning.
Every industry uses contingency planning to account for the unexpected. Event planners book indoor locations in case their outdoor location is rained out. Project managers add 10-15 percent to their budgets, just in case something unexpected is needed. Programs such as MS Word have “auto save” features in case the system freezes.
Why, then, do online experiences tend to suffer from the unexpected? Too often, a terrifically designed Web site apologizes for having “technical difficulties.” I’m the first to tout the benefits of great design and user experience (and its effect on profitability and customer loyalty), but a great design can’t make up for lousy technical implementation. If a user’s shopping cart blows up or the site crashes, users can’t purchase. It doesn’t matter how nice the experience was before the problem arose.
Anticipate Weak Points
The other night, I was entering a lot of special instructions for an online order. The text box was a WYSIWYG editor plug-in. After spending 10 minutes writing, I clicked “submit.” Due to a bug in the plug-in, Internet Explorer crashed. I lost everything I’d done. Instead of returning to the site and placing the order again, I turned the computer off in frustration.
When users spend time doing something on your site, make sure there’s a contingency plan to recoup that information in case of a crash or failure. We have an extranet we use with our clients. One module is a bug-tracking tool that uses a similar WYSIWYG text editor. We’ve experienced browser crashes now and again (what is it about those plug-ins?). Because things take a long time to enter, a crash at the end of the process means 20-30 minutes of wasted time.
To combat this problem, we built a contingency plan into the extranet. Every time a user presses “submit” on a form, all the form data is copied to that user’s clipboard. If the browser crashes, the server load is too high to deliver the next page, or anything else goes wrong, the user still has all the data. We just press “paste” and the data is back in the form. This has saved us on numerous occasions.
Personalization, Dynamic Content, and Server Load
Personalization and dynamic content make the Internet interesting. They also take time to execute (because they read from a database or cache). When a site’s server load is really high, these features may actually bring the site to a screeching halt.
News services such as CNN know this all too well. They’ve built contingency plans for high server load. During news spikes, some maintain a static version of themselves (some are always static for this reason), and others shut off personalization features.
We designed a personalization engine for a client a few years ago that automatically dials back its personalization complexity based on server load. The user can set efficiency thresholds for the engine to maintain at the expense of advanced, time-consuming features.
Shopping Cart Explosion
Sites that can’t complete an order due to “technical difficulties” must have a contingency shopping cart: bare-bones, with no bells or whistles. The checkout process is stripped of things such as cross-sells, multiple ship-tos, gift purchases, and other complicated logic that slows the system down.
At its simplest, a bare-bones checkout stores the cart in a database for later or sends an email to the sales department to process all the order details manually. In any event, some contingency planning must be thought of in advance.
Anticipate the Worst, Minimize Revenue Effects
Contingency planning doesn’t just mean anticipating the worst. It also means anticipating too much success. A broken shopping cart or corrupted database is as big a problem as a 300 percent traffic increase over the holidays or the fact everyone in the world visits CNN.com when something catastrophic occurs.
If we plan for these events in advance, we can minimize their effects on revenue. Even if revenue is reduced due to a bare-bones, fallback plan (such as a cart with no cross-sells), reduced revenue is better than no revenue at all.
Until next time…