I’ve recently been receiving hands-on training in how to piss off your customers.

 

I won’t mention the name of the company, which makes developer tools, but here is the sequence of events:

 

 

I placed an order on the vendor’s Web page. The final order page showed an error message. I received no email confirmation of the order, and the online order lookup form returned nothing.

 

 

Still no email confirmation of the order. So I called the vendor. The person I talked to said she would look up my information and call me back. By late afternoon, having received no callback, I tried the online order page again. And got the same error message. And, again, no confirmation email. So I decided to bypass the vendor and ordered a copy of the tool I needed from Programmer’s Paradise.

 

 

I receive a shipping notification from the vendor for the first order. Which is the first email I’ve ever received about this order. The first response at all. I reply to this email that it needs to be refunded, and that there is probably a second order that needs to be canceled.

 

 

I received my copy from Programmer’s Paradise. And then one from the vendor. I called the vendor and talked to a sales guy and explained that I needed a refund and a way to return the extra copy I now had. He said I needed to talk to someone else and took down my information, saying this “someone else” person would call me. 6 hours later, with no callback, I again called the vendor, was sent to the “someone else” person’s voicemail and left my information. Again.

 

 

I have still received no callback. But I did receive the shipping notification for the second, duplicate order and the second, duplicate copy of the tool. I did (finally) receive a reply to my email about the first order. Only 48 hours later. But–yes, there’s still more–this email only tells me that they have received my email and that I’m to receive another email with instructions for receiving a refund. Which email, no, hasn’t arrived yet.

 

This is, in a word, retarded.

 

 

Let’s review the important parts, so that you too can piss off your customers and rack up angry phone calls, emails and chargebacks.

 

 

I’m rather pissed off about all of this. As you might have noticed. Not pissed off enough to mention names, of course.

 

I hate running into this kind of incompetence, especially from vendors that I rely on for my development tools. It makes me question the wisdom of using their tools. Even if I do love the tools and wouldn’t be where I am today without them.

 

Damn it: good customer service is easy. How can people fuck it up so damn completely???

 

-David

 

Yesterday I received an email from someone who read my interview about The Journal in Bob Walsh’s 2006 book, Micro-ISV: From Vision To Reality. This reader asked some very valid questions:

 

 

So I’m going to fill the gaps on my interview in a 2-part (maybe 3-part) series.

 

 

The short answer: The extreme optimism of programmers.

 

Of course people will pay for my software. Duh.

 

 

The trip from “learn Delphi project” to “people will pay me for this” didn’t take all that long really. In retrospect, anyway. Seemed to take a while at the time. [1]

 

After I had a working 1.0 version of The Journal, I figured I had something that was at least worth showing off. So I put together an install package (I think Delphi used to ship with a stripped-down version of InstallShield which made that an easy task) and put it on various Delphi developer Web pages as a freeware “made-in-Delphi” application. That was the beginning of the summer, in June 1996. And, yes, I have this event recorded in The Journal.

 

Within a few weeks I started getting feedback from a small group of people (other Delphi developers mostly) with bug reports and feature suggestions. I recorded those in The Journal too:

 

 

Also during that period, prompted by the feedback, I went out and looked at the other journaling software that was available. There were quite a few, actually. (Probably too many. If I were doing that search today, I’d probably decide to do something else entirely. That is, if one of them met my requirements. [2]) Some of those other journal programs were less feature-complete than the The Journal 1.0 (no small feat, let me tell you) and were for sale (usually in the $10-$15 range) and presumably selling.

 

Between those 2 things, though, happy users and a “proven” market, I decided to go for it. I sat down and worked out the features I thought were missing from The Journal that *must* be in a selling version (full help file, export/import, backup/restore, etc [3] ) and then started working to check those off.

 

When I had implemented everything on the list, I figured I had “gone gold”.

 

 

The short answer: My initial users.

 

 

Actually, in this case, the short answer is … well … less than accurate.

 

I got a lot of help in the testing of The Journal 1.30 (the first for-sale/shareware release) by offering a free upgrade to anyone who helped with the testing. I have no idea how much money I gave away with that (I just found an entry where I estimated the giveaway at about $1200), but it seemed a good idea at the time. When I figured the software was as good as I was going to get it–which took about 3 months–I put The Journal (now at version 1.30) out there with a $15 price tag and a 30-day trial period and hoped for the best.

 

It looked something like this: [4]

 

 

And The Journal 1.30 lasted an entire 3 days before a critical error forced my first bug-fix release. Bah. Sometimes I hate software…

 

8 days after the release of The Journal 1.30, 5 days after the release of The Journal 1.31 bug-fix, I received my first payment.

 

So, really, for this gap the short answer should be: I received my initial sales from offering The Journal for sale.

 

Seriously. It’s hard to get that first sale without actually putting something up for sale.

 

My next post will cover the questions about competition.

 

-David

 

[1] Because summers seem to last forever when you’re young. <sigh> Like I was. 11 years ago…

 

[2] My requirements weren’t that steep, really: formatted text in entries, copy-and-paste capability, easy access to the current date and simple review of past entries. And yet, nothing in 1996 offered those features together in a journal program (3 out of 4 was the best I could find). Bizarre. My requirements today are much steeper. See The Journal.

 

[3] There are competing products out today that still don’t have some of those features, especially backup & restore and import & export. Kinda scary, really. I guess that’s another example of the extreme optimism of programmers.

 

[4] A year later, actually, in late 1997, The Journal looked something like that. I seem to have lost all screen shots from 1996. And all install files for The Journal prior to 1.44. Oops.

 

For years, from approximately 2000 to late 2005, users of The Journal requested one feature over and over: reminders. They wanted to set reminders for themselves and mark recurring special days in their calendars and manage simple tasks.

 

And I said, over and over, “No.”

 

I had my reasons, of course. “The Journal is a recorder,” I explained. “Not a planner.”

 

In fact, I had been avoiding planner-like features since I first started selling the product. Not the least because I didn’t want to look like I was trying to compete with real planner software, like Microsoft Schedule+. Other software had already solved that whole planner thing, I figured. So I focused on making The Journal a damn fine journal. (Because Schedule+, and later Outlook, were lousy journals.)

 

Finally, though, in late 2005 I announced that I was going to add simple–and I repeated simple–reminders to The Journal. Because people were still asking me for them, and because … well … I had run out of strategic (and reasonably low-hanging) new features to add to my damn fine journal software.

 

Once I had reminders implemented enough that I could play with them in testing, I realized: My customers had been right all along. The Journal did need reminders.

 

Further, I went on to reverse my original decision to charge for reminders as a separate add-on. Because the reminders, simple or not, were suddenly an obvious extension of the base software. For some reason, once the reminders were there, I couldn’t imagine The Journal without them. It had just taken me, the designer and developer, 10 years (and a nearly complete implementation cycle) to understand that.

 

Before reminders, my customers were also right about:

 

And since reminders, my users have also been right about this one:

 

Just like for reminders, I had reasons for not doing any of these. In order:

 

All of those were true when I uttered them, and they remain true. But they completely missed the point.

 

Where I screwed up was not understanding that, to my users, The Journal was not working the way it was “supposed to”. They expected a particular functionality or capability, and they weren’t getting it. All I was doing was telling them they were wrong and offering an unsatisfactory workaround.

 

Admitting this punctures my pride a bit. Because I’ve always prided myself on listening to my users and making The Journal as intuitive as possible. So how could I have so blatantly missed the mark on these issues?

 

I think it’s because, at heart, I’m still a programmer.

 

More to the point, I can see that I resisted suggestions that went against the grain of–or, like reminders, flew in the face of–how I envisioned the software. How a journal should work, what features should be available and how they should function. I had already made all these decisions. These pesky users with their strange requests just didn’t understand the software. They were using it wrong.

 

Except that’s arrogant and stupid, isn’t it?

 

(Admit it. That’s stupid.)

 

It’s also very typical of designers and engineers and programmers. And probably just guys in general.

 

The customer may not always be right.

 

But, yeah, they probably are.

 

-David

 

It’s easy. Say,

 

 

If there’s something specific you want to apologize for, mention that:

 

 

Or:

 

 

And that’s it.

 

Don’t give excuses. No matter how valid you think those excuses might be. Your customers don’t care if your server was down, and don’t want to hear about your flight home. Nor do they care if you wrote the help file as best you could. Nor do they want a lecture about how you did an extensive study and found that it’s 0.3% more efficient to put the “File” menu vertically down the left side of the UI. And they sure as hell don’t want to be told that a particular issue is their fault.

 

Take responsibility.

 

Apologize.

 

Then get on with the task of answering their questions and fixing their problems.

 

-David

 

“Adversarial Words” might be a better phrase.

 

I pick words as focused as I can. And then Google goes to work finding ways to broaden those words to match anything and everything they possibly can.

 

It’s fun.

 

In the same way that owning a chainsaw with the built-in goal of removing one of your legs is fun.

 

-David

 

Sorry.

 

-David