The Customer Isn’t Always Right… But the User Is

Today, as I labored mightily to get a usable ComicBase 12.1d1 out the door, a frantic email came in from a very upset customer. This same customer had earlier found a way to embed tab characters into their issue notes by the ingenious application of cut and paste from other web sites, and I’d spent part of Friday figuring out how it was that they’d managed to concoct a sales file which Atomic Avenue couldn’t process. In fact, one of the items on my day’s “to do” list was to put in a fairly simple fix to make sure that no future user could ever duplicate that user’s feat.

Now, on a Sunday where I was cooped up in the office sucking down coffee by the quart while I tried to figure out various currency conversion issues for ComicBase, the customer’s email flickered onto my screen demanding immediate action as the customer claimed ComicBase had somehow wiped out all their data.

“Alright, calm down… ” I was thinking. “She almost certainly just opened the wrong database by accident and is freaking out because it looks like all her work disappeared.” This has been a periodic problem that crops up a couple times a year ever since we made it possible to work with multiple databases. Basically, the customer starts working in one database, forgets that they were doing so, then does something to reset their preferences (or simply clicks on the wrong database file) and has an immediate heart attack when the data they’d slaved over entering appears no longer to be there.

I dashed off a quick note to that effect to the user, and a moment or two later regretted the somewhat rushed tone of the email. To make amends (and to more completely explain the scenario so that future users who managed to get themselves into a similar fix could find help on their own), I quickly wrote out a “Tip of the Day” on what serves as our in-house knowledgebase.

“Everything’s going to be fine” I thought, “so long as she wasn’t doing something stupid like working from their backup copy, then saving over it with a blank database while they thrashed around looking for the database she’d been working in.” This was the one worrisome scenario which could ever come up and cause a ComicBase user to lose work, and I’d written any number of newsletter, forum, and email posts warning folks never to do it. I made particular note of it in the Tech Tip so that I could point to it in posterity (or my successor could point it out after I passed out at my desk from too many Vente Mochas).

Naturally, this is exactly what the user in question had done, and although she’d only lost a few hundred books’ worth of data in the process (and I’d even offered to get much of her data back from Atomic Avenue), she was well and truly ticked off, and wanted a refund.

Here at Human Computing, we have an almost absurdly lenient refund policy. To wit: if you’re not amazingly happy with ComicBase, we’ll give you your money back—end of story. We don’t have a big involved RMA process for doing so, since even with this policy in place, we generally only get one or two refund requests per year—that’s less than 30 over the 15-year history of the company. Is it because we write perfect software? I’m afraid not. But our tech support is second to none, and we can usually help with just about anything that goes wrong—even if it’s a Windows issue, computer failure, or just something bizarre that the user did.

In this particular case, the user had done a number of wrong things, the most tragic of which was saving a “blank” database on top of their work, and not keeping any other sort of offline backup. From the sound of it, she even panicked and saved over the automatic backup that the program makes.

So was the user unreasonable to demand want an apology for a problem that she’d almost certainly caused? Yeah. Did she send about a dozen emails sniping at a guy loaded with coffee who was bending over backward on a Sunday night to help her recover from the problem? Yes again. And in the end, she wound up rejecting any further offers of help, and I quickly gave her a refund for her full purchase price ($49.95). I felt miserable.

I know a software company where the policy on tech support is that if the user can’t follow the single page of instructions to install and set up the software, they are asked to simply box the whole thing up and send it for a refund—just so the company can “fire” the customer and save a fortune in future technical support. In my darker moments, I envy this company.

But although I don’t believe that the customer is always right, I believe that the user of a software program is. If the user does dumb things, enters invalid data, abuses the program, and just generally does everything in his power to shoot himself in the foot, it’s ultimately my problem—not theirs. There are limits to what can be done, but—little by little—we try to make sure that we change the program in a way so that future users don’t run into the same difficulty. As ace programmer Joel Spolsky (Correction: It was apparently actually Dave Winer) famously said, consumer software is a game of inches. Each tiny improvement to the fit and finish of a piece of software helps someone. Add enough improvements up, and you’ve eventually got a world class product.

Before returning to the currency conversion problem at hand, I took some time and tried to brainstorm a solution to prevent especially persistent folks from accidentally recreating the exact, convoluted scenario which had cost me a customer tonight. Maybe the code I wrote to prevent this will never actually be triggered by an errant user’s efforts…or maybe it’ll save someone from wiping out their work. When 12.1d1 finally gets built–probably in the wee hours of the morning at this rate–it’ll also go out with the “No embedded tabs in the Notes field” fix which went into the code earlier today.

Here’s to moving the ball a few more inches in the right direction…