Archive for the ‘support’ category

Improving Support One Changelog At A Time

February 14, 2009

sales.rb Revision 539:

Unanticipated behavior: Some customers put Registration Key into Lookup My Registration Key form.  This looks up transactions by order number and email address, thus failing to find any matching records, then informs customer to email me to find their Registration Key.  This is suboptimal.

Fix: If input into LMRK form resembles a Registration Key, search for a line item which had that Registration Key assigned.  If one exists, then it was actually issued to a customer — redirect them to explanatory text with pictures on how to enter a Registration Key into the application, not the website.

If Registration Key does not exist, then tell customer to email me.


Minor Usability Errors In Checkout Funnel = You Lose Lots Of Money

May 12, 2007

Recently I discovered that I have been inadvertently making it very difficult for customers to order CDs, which are a very popular item.  They’re so popular that I think a significant portion of my customers would walk away if they couldn’t get them.  Here is the percentage of orders I’ve had which requested a CD since I made the CD an easy and obvious item to get:

February (CDs offered prominently midmonth) : 6 / 17 = 35% (its over 50% if you count only the orders past when I started offering CDs prominently)

March: 2 / 30 = 6%

April: 4 / 26 = 15%

May: 3 / 12 = 25%

Now, granted, part of this is natural variation and small numbers throwing things for a loop.  Part of it in March was a bug in my webpage which made it flatly impossible to order CDs through the two most obvious links.  I expected the CD rate to recover to 50% or so after fixing that, but it has been fairly low in April/May, and I recently discovered the reason why.

The problem was the e-junkie cart.  Basically, to ship a CD you have to mark it as a Shipping item.  If you have a Shipping item in your cart, the cart interface changes.  Try it out now on my website.

If you don’t have a shipping item in your cart, your cart looks like this:

Cart Without Shipping Item

You hit one of the two checkout buttons and you are instantly whisked to the checkout page in Paypal or Google Checkout.  Brilliant, you now have something approaching a 60% chance of giving me money (guesstimate from available analytics data).

If you do have a shipping item in your cart, you get

Cart With Shipping Item

So you click on the checkout button and are instantly whisked to… an error message.

Cart Error Message

Thats not good news, but being a computer user you don’t actually read the error message.  Roughly half of you abandon the checkout instantly.  The other half of you input your zipcode again and slam on the checkout button.  Where you get whisked to another error message.

Yep folks, like the old public service announcement said, reading is fundamental.  You have to click update cart then click checkout.  Only 20% of the people who reach this stage of the game are capable of completing those two steps in order.  For those keeping track, thats 50% lost at the first error message times, then 80% of the remainder lost at the second error message, means a total of 10% of the people who wanted to buy CDs make it through The Cart Gauntlet.  Then its on to checkout where the slightly miffed survivors convert at a 60% rate, meaning I lose NINETY FOUR PERCENT of the people who have expressed interest in buying a CD.

Clearly, this is a suboptimal state of affairs for me.  Luckily, my shopping cart was created by the best guys in the business, e-junkie.  I swapped a pair of mails with Robin detailing the problem and they’ll have a fix pushed out to all their carts in the world (hosted web apps: so nice) by the end of the weekend.  Other e-junkie users who sell to non-technical customers, I hope you enjoy your magically increased sales as much as I will.

So here’s the take-away lesson: you’ve got to sand down the rough edges in your checkout funnel or they’ll bleed you to death. 

Many people might say “Wait a second, isn’t the cart itself a rough edge, since you go directly to the checkout button?”  Oddly enough, no.  I can substantiate that with conversion numbers — the page performs much better with the cart than with buttons taking folks directly to Google Checkout and Paypal.  My guess is that this is psychology — you get one choice to make “Download or CD?”, you make it, and after you’ve committed to that the virtual salesman gives you another minor little prompt “So, how do you intend to pay for it?” and we’re off to the races.  If, however, you offer a bewildering array of options at the start of the process (“Would you like to buy the downloadable version from Paypal for $24.95, the downloadable version from Google for $24.95, the CD version from Paypal for $29.95, or the CD version from Google for $29.95?”), customers can get decision paralysis.

Busiest Day For Customer Support Ever

April 26, 2007

I had not one but two issues that couldn’t be taken care of in a five minute email.  Oh no! 

a)  One customer still hadn’t received her Registration Key despite getting the automated email, emailing me about this yesterday, and getting a handwritten email from me yesterday.  Luckily, her signature included her voicemail number, so I left the voicemail.  Ahh, shades of my old job. 

b)  One customer hadn’t received their CD yet.  A quick check in SwiftCD showed that it was sent on March 29th.  Ahem, “oops”.  I mailed them to confirm their address (customer error in the input field is the #1 cause of non-delivery, by far, so any time you get a report of non-delivery you should suggest in a non-confrontational way “Could you just confirm your address for me so I can send this out?”) and will be FedExing them a new copy as soon as I receive it.  (Yes, at my expense.  Yes, that will eat up most if not all of the profit from this order.  Shipping bloopers fall into rounding errors in the greater scheme of things and you earn so much customer goodwill by addressing them promptly at cost.)

Speaking of which, I realize that I completely flew past my April 15th stats update.  Don’t shoot me, my birthday is April 16th, which after adjusting for timezone issues means that I was karaoke-ing until the break of dawn when I “should have” been telling you that sales for the first half of the month were crushed by Easter.  They’ve since picked up (not up enough to hit my $1,000 target, probably up enough to make a new record), and I’ll tell you the exact stats on the last day of the month.  Or thereabouts.

How Much Time A uISV Spends On Customer Support

March 13, 2007

“Not much.” 

I often hear a bit of grousing from folks who don’t quite understand selling B2C software that you’ll spend all your time telling people how to find the start menu, end up getting McDonalds-esque wages, live in a van down by the river, and have to beg for change from passerby.  Presumably you’d use that change to buy a latte at Starbucks and stay for using their WiFi to answer your support mails.  This is a slight exaggeration of the amount of work involved in supporting customers, even customers who are less than technically proficient.  Trust me, I do my fair share of instructing people in basic computer concepts (OK, to install a program you double click on the …), and I don’t spend all of my day doing this.

My uneducated estimate prior to starting Bingo Card Creator was that 5% of all customers will require support, ever.  However, given that I’ve got eight months of history to work with now, why go from an uneducated estimate?  I used the not very scientific method of iterating through all the emails in my outgoing mail folder (I follow the rule that the CS rep should always reply to every email) and subtracting the ones which were to myself or to peers instead of prospects and customers.  I did this for the period from February 1st through March 14th (Japan time), which is approximately 6 weeks of time and which includes the discovery and resolution of two major issues which escaped my notice and generated numerous customer emails.

During this six week period, I have in excess of 600 confirmed unique installations of Bingo Card Creator, at least 2,000 downloads, and 32 sales.  And how many emails did I write?

Twenty-seven.  Thats about .84 per sale, 4.5% of confirmed installations, and a percent and change of downloads.

Thats not support emails, incidentally.  Thats everything: pre-sales inquiries, support emails, “Thank you for bringing that to my attention” for folks who mentioned that I habitually butcher the word “convinient [sic]” on my blog, outbound inquiries to people who had purchased Bingo Card Creator multiple times asking if that was a mistake or not (someone wanted an extra CD for his sister), and outbound emails saying that an order was being held up by Google/Paypal for verification and asking if they would please accept this CD key with my apologies for the delay.

The breakdown:

Pre-sale inquiries/How do I do X inquiries: 10

Support (The program is broken!): 8

Payment Processor Issues: 4 (I initiated 3 of them)

Are you sure you wanted to buy two copies?: 1

Thank you for your comment: 3

Registration Key Not Received: 1

So lets talk about how return-munching this support burden is: The median mail takes me 3 minutes to write (registry key inquiry — 1 minute to check e-junkie for their key, 1 minute to write up a brief paragraph, one minute to type my key-issuing Direct Access autotext and check to see that the mail meets my standards) , with the most demanding email being 20 minutes and a significant number being 15 seconds (“Thank you for your interest in Bingo Card Creator.  Unfortunately, Bingo Card Creator does not support using pictures on bingo cards.”  — I have this macroed, too.)  If you assume my average is about 4 minutes an email, which is pretty close to accurate, then I am paying myself roughly $370 an hour, give or take, to support Bingo Card Creator.  This is slightly more than I made as a CS representative at Quill. 

Other ways to contextualize how little customer support actually costs me:

Its approximately 5 mails per 6 customers.

Its approximately 2 emails every 3 days.

If it scaled linearly with customers and I was selling 5,000 units a year (income in excess of $100,000 USD) I’d be writing a backbreaking 11 emails a day.  (Do you think that its a given that a real business generates many more emails than that?  Apparently somebody didn’t give these four major web apps the memo.)  I have strong doubts, incidentally, that support emails scale linearly with customers: my intuition says its actually closer to constant or perhaps logarithmic.

Will everyone have experiences like this?  No.  There are a couple of factors which make me send more email than other people, and a couple which make me send less. 

What makes me send more:

  1. My niche is one of the least computer-savvy available on the Internet.
  2. I am fanatical about customer service.  If Google Checkout holds up an order for 1.5 hours in authorization that customer gets an apology whether they’re miffed enough to write in about the incident or not. 
  3. I twice introduced critical bugs into my program/business which generated multiple repetitive emails.  (One build disabled a key feature of my software for about two weeks.  I shipped a handful of CDs with defective graphics on them.)

What makes me send less than other people:

  1. I sell a very simple application.  There are not too many things which can go wrong.
  2. I give very explicit directions to my customers at every step in the process.  My application’s main window includes a step-by-step how-to guide for the most common use case.  If you buy a CD from me you get your CD key and instructions on how to input it at the confirmation page for your order, in your email confirmation for the order, stamped on the envelope your CD arrives in, and printed on the face of the CD itself. 
  3. When I get multiple inquiries about a single subject I figure out how I can avoid getting them again.  Example: I got multiple inquiries about CD keys and implemented the above-described defense-in-depth.  I got multiple inquiries about Music Note bingo and made a blog post about it that I can just point people to now.
  4. I make judicious use of auto-text and templates to make the process of writing support mails quicker and more useful to the customers.  For example, I have an auto-text which inserts my “Thank you for buying, here is your key” template, which has instructions which I have endeavored to make as simple as possible.  This is an improvement to ad-libbing the directions every time I issue a key, which could result in some customers getting less optimized directions and me wasting my time rewriting the wheel, so to speak.  The key here is being judicious.  People aren’t paying you money so that Direct Access can have a conversation with them.  You need to read, understand, and resolve their issue rather than skimming, classifying, and auto-replying to their issue.
  5. Customer expectations for support for a $24.95 program are pretty low.  Suffice it to say that no school district has ever contemplated a Service Level Agreement for their mission critical bingo card needs.

Everything You Need To Know About Registration Systems

September 5, 2006

… but were afraid to ask.

One of the most common questions asked on the Business of Software board by a new aspiring uISV is “How do I protect my software?” This post is meant to be a comprehensive answer to that question, so folks can point to it and say “Alright, now get out of my hair!”. Kidding, kidding, we were all there once.

First, a brief discussion on why you want to protect your software. The only reason you want to protect your software is to enforce the limitations you have put on the trial version. Many people mistakenly come to the table with the assumption that protecting the software will somehow, magically, “protect my intellectual property” or something to that effect. This might be theoretically true but you will have an easier time conceptualizing your registration scheme if you think of it as primarily a marketing, rather than technical, measure. Its your salesman that encourages folks to pay you money.

Why is it important to remember your registration scheme is a salesman? Because salesmen do not typically kick their prospective customers where the sun doesn’t shine, and many registration schemes do. Aside from some clubs in Tokyo (and the less you know about them, the better, really), people generally don’t pay money for the privilege of being kicked. Yet many software developers keep including Nutcracker Suite protection systems, such as Starforce, which severely harm the user experience, out of the mistaken belief that this will eventually increase profits.

If you will permit be a bit of amateur psychoanalysis, I think this is because software developers in general, and uISVs in particular, feel violated when someone is using their software illegally. I know the feeling, it has happened to me (and, mark my words, it will happen to you). Someone who downloads your software and cracks it hasn’t cost you any more money than someone who picks your door and walks around your apartment for 20 minutes without touching anything, yet the feeling that your rights have been violated is the same. And perhaps in a fit of less-than-rational anger you might demand your apartment upgrade its security system to include dead-locks, pitbulls, a batallion of US Marines with shoot-to-kill-orders, and some cleverly disguised booby-traps involving acid or flaming oil, or perhaps just flaming acid. Of course, the local Girl Scout troop selling cookies will probably not react too well to the fortifications (aside from the “cute wittle puppy!”), so if you like having cookies delivered to your door this is probably not a good idea.

So lets talk about four classes of users and how they interact with your registration scheme.

The first type of user is perfectly honest and will always comply with your licensing scheme to the letter, even if ways to circumvent your registration scheme are obvious. Approximately everyone thinks they are this kind of user. To this kind of user, your registration scheme (a salesman for your software) can be only a hindrance in getting to use the software which he happily paid for.

The second type of user is mostly honest. He’s not a pirate, after all, he has a wife and kids and works at an insurance company. He scoffs at the kids on Napster who feel entitled to free music. And yet he also will happily buy one license of your software when your license tells him he really requires five, install and uninstall a time-limited trial version every two weeks, and perhaps even reset his system clock to get around a time limitation. But he won’t download a crack, no. A crack would be stealing, and stealing is wrong. This second type of user is where your protection (a salesman for your software!) will make most of his keep. How many of these users relative to totally honest users you have depends on your market, but sadly, they’re a lot more common than most non-developers would think.

The third type of user wants to use your software, but will pirate it given half the chance. Its too expensive, it doesn’t do quite what he needs, he doesn’t have the money, for-profit software development is evil, piracy is wrong but oh well… he has a lot of mental excuses. Some of this user group is very technically adept at finding cracks — they know what IRC channels to go to and what shady connections to excercize. Some of them rely on Google searches. You can potentially wheedle a small number of sales from this group with your protection scheme, and they’ll hate you for every minute of it.

The fourth type of user… “Do what you want ’cause a pirate is free, YOU ARE A PIRATE!” He flies the Jolly Roger and you will never, ever make a legitimate sale to him. Even if he does “buy” your software it will be with a stolen creditcard or chargebacked within 24 hours. You’ll find that there are countries on earth (*cough* China *cough*) where there are few users from any other type. Your protection system is not really relevant to this type of user, since he’ll be using the crack anyway.

Oh, yeah, lets talk about cracks a little bit. You. Will. Be. Cracked. I really strongly recommend you read that post, because its true: no protection scheme will survive indefinite contact with the adversary. Your goal in instituting a protection scheme is not to achieve 0 utilization of your software by the Jolly Rogers of the world. It is primarily to keep circumvention methods obscure enough that it will take dedicated effort to discover either a way around your software or find someone who has found a way around your software.

There are several varities of cracks which you have to worry about. We are now crossing into the technical portion of this article, and will be discussing implementation details rather than philosophy, so pay attention.

1) A single good key. The cracker discovers, either via a “legitimate” purchase or analyzing your code, one single good key, and publishes it. This is the least damaging type of crack, because you can just ban that key in further updates to your software, and because if you use keys which are tied to other user data it will prevent someone from using the good key without otherwise impersonating the user it is tied to.

2) Keygen, or “key generators”. You have one of these lying around on your PC or server which generates good keys for your software. The cracker’s goal is not to replicate your system, but instead write one which produces at least some subset of the keys your system will produce. Many crackers prefer to write keygens because they get a psychological thrill out of “beating” you, but to most user groups there is no difference between one download and another.

3) A patch/crack which strips off your protection. For example, if you leave in a debug mode (if (!debug) {checkRegistrationKey();} else {registered = true;}), all the patch has to do is modify your executable to flip the debug bit and then your software is locked into the registered version. Creating a patch requires that your executable be a stable binary, as if the offsets of the bits to flip change applying an old patch will be impossible.

4) A cracked executable. This is the cracker’s least favorite method, because then he has to spend non-trivial amounts of bandwidth hosting the executable, and since he wants to host literally tens of thousands of executables this is irksome to him. However, remember, bandwidth is cheap — this is a speed bump, not a security mechanism.

In general, it is to your advantage to force the adversary to use countermeasures which are higher up that list. This means that your protection scheme should:

1) Require user-specific data so that a single good registration key does not break your software everywhere. The most obvious choice is username, but this is not very secure. Other popular choices include hard drive serial numbers, MAC addresses, GUIDs, etc. Remember, this will inconvinience legitimate users — you will have users who spell their name differently on their Paypal accounts versus in your software (example: McKenzie != Mckenzie has gotten my mother a few times, Bob Smith versus Robert Smith), you will have users who expect (and are perhaps, depending on your license, entitled) to use the software both at work and at home, you will have users whose hard drive dies and your software will cease to work on the new one. All of these become support issues for you, because your salesman is busy trodding on the toes of people who have already given you money. Consider carefully how much pain you will authorize him to inflict. For myself, I thought the risk of a serial key leaking was less than the amount of difficulty I would have policing unique serials, so while I ask folks for their name to generate my keys they’ll actually work for any name you put in (Shh, don’t tell the crackers 🙂 ).

2) Obfuscate your code. Especially if you are using an interpreted language, such as .NET or Java, decompilers exist which will print out your protection routines in their entirety. This was how my very first hacked in version 1.0 happened, and that resulted in a keygen (i.e. total tactical victory for the bad guys). I’ve since started using ProGuard, a lovely OSS utility which takes your nice, easily decompileable JAR file and returns gibberish which still executes. This plus a (partial, backwards compatible) fix for the earlier keygen has kept me from getting hit with another wave of me hearties from China, although I know of at least one functioning keygen out there — but its buried beyond the reach of my casual pirate customers, which is a total strategic victory for me. Obfuscation is nice in that unless you need reflection or debugging stack traces it can’t hurt a legitimate user.

3) Change binaries early and often . Frequently changing your binary, via any method you want (obfuscation utilities can often do this — so can minor patches to your code), forces pirates to either host the executable themselves or deal with “customer support” requests like “Waaaaaah your patch doesn’t work anymore lol”.

OK, now, finally, on to license key generation algorithms. Some design considerations:

1) Are you going to run this offline, or are you going to run this on a server?

2) How much information from your customer does the algorithm require? How are you going to get this? e.g. if you require their hard drive serial number, you suddenly add the requirement “Customers can only purchase my application through my application”, which may be less than desireable.
3) Are you going to roll your own, or use an off-the-shelf system like Armadillo? In general, you’re not paying for security (although its likely that their system is more secure than yours, its not totally secure), you’re paying for convinience. Armadillo has been broken before and will be broken again, like every other security system.

4) How do you get the registration key to the user? Do you want to display it on a website, display it on an email, or update the application directly (sometimes called “automatic key injection”? A lot of the payment processors (including e-Sellerate, as I recall) promote systems that have this as a feature. Its quite nice, as it reduces customer support headaches (what was my registration key? How do I input it again?), particularly with non-technical customers. I didn’t do this myself, primarily because it required more development effort than my schedule had time for.

OK, if you’re still with me, lets talk some strategies for key generation if you want to do it yourself.

1) Public key encryption. Basically, your registration key sends a message: “Bob Smith, I hereby give you the right to use my software, in exchange for the consideration you have given me”. The problem is that Jolly Roger wants to be able to forge the message and replace Bob Smith with Jolly Roger, thus bamboozling your program into functioning for him. Luckily, there is a solution to this: public key cryptography. Public key cryptography works like this: you have a pair of keys. One of them is public and you can give it out to everybody, including the adversary. One of them is private and you guard it with your life. Since your trial version will be in the hands of the adversary, the only thing the trial version can know is your public key.

Practically speaking, you first take the hash value of all the identifying information you have. Then, you encrypt this with your private key: the output of this encryption is your “registration key/serial number”. Your software then performs the same calculation of the hash value in parallel, and decrypts your serial number using your public key, which results in a hash value. If the two hash values match, you unlock the software. If not, you display a nicely worded message to contact support (remember, your protection mechanism is a salesman).

If you are interested in the math behind encryption, which gets kind of heady, Wikipedia has a nice article on RSA. I’ll give you my dirty little secret: I’ve got a very incomplete understanding of a lot of the number theory involved, and I don’t trust myself to implement encryption. Neither should you. Really, trust Bob Schneider, you’ll probably just end up breaking something. Instead, take the crypto library which comes with your package of choice, and USE IT. Look for “MD5 digest” or “message signing” in your documentation if you’re unfamiliar with the whole field and just want to be done, quickly.

2) Everything else. Any other mechanism is insecurity which you’re tolerating for the sake of preserving your time as a developer. With that in mind, for preventing casual piracy you don’t need to go as far as public key crypto, although I would oh-so-strongly suggest doing so. I ignored my own advice though, and did something similar to the following: take two random constants A and B, which are “secret” in the sense that you have to actually decompile my program to find them (“But Patrick, thats not very secret is it. After all, the program is in the hands of the adversary.” EXACTLY). if (serial ^ A) % B == 0, then the serial is good. Note this doesn’t allow for any use of identifying information, and was chosen totally because I could implement it in 30 seconds. If I did another product today, I would spend 30 minutes instead and use Java’s excellent crypto libraries. The weaknesses of my approach are obvious: with access to the code breaking it takes a matter of seconds, one serial number will work for any number of computers, etc etc. But it was sufficient to my purposes because my target customer has enough difficulty getting a legitimate version installed, to say nothing of navigating the dark corners of the Internet where the keygens flourish.

Where/when to check the serial number: I check once on startup. A lot of people say “Check in all sorts of places”, to make it harder for someone to crack by stripping out the check. If you want to be particularly nasty to the cracker, check in all sorts of places using inlined code (i.e. DON’T externalize it all into SerialNumberVerifier.class) and if at all possible make it multi-threaded and hard to recognize when it fails, too. But this just makes it harder to make the crack, not impossible, and remember your goal is generally not to defeat the cracker. Defeating the cracker does not make you an appreciable amount of money. You just need to defeat the casual user in most instances, and the casual user does not have access to a debugger nor know how to use one.

Alright, that about wraps it up. This article is a work in progress, so I might beef it up some more, perhaps with code samples or techniques to impose, e.g., time limitations. Someday. In the meanwhile, I hope you learned something.

[Edit: Yo ho, me hearties.  If ye be wantin’ to stick it to a pirate without having to program a thing, cast yer glass over this way.]

What Should Starbucks Do

September 1, 2006

I spotted this on Seth Godin’s blog.  Starbucks had an incredibly ill-conceived promotion where they mailed some fraction of their employees with an email coupon for a free iced drink, then told them to mail friends and family members.  Oh boy, a chain letter, no possible way that could get out of hand, right?  Well, it did, and as a result Starbucks canceled the promotion.

Seth opines that, were it his call, he would have notched the driver’s license of anyone who used the promotion and given them the free drink.  The business problem this solves is that it prevents someone from going to the 46 Starbucks within walking distance from, say, the Sears Tower and getting 46 free ice lattes or whatever it is Starbucks sells.  His rule #3 (“We never accept online promotions.  However, if you were scammed by one, have *a free premium which the company can give out almost at will*.”) is, in my opinion, a brilliant solution to this problem for a chain which doesn’t have it yet.  But it doesn’t help Starbucks since they can’t force the cat back into the bag.

Here’s my solution: for every customer who comes in asking for their free iced fraparamadingdong, tell them “We’re very sorry, that promotion has been abused so we have to ask you this: what’s your first name and the last four digits of your telephone number?”  Then make a show of writing it down, and give them the product.  The only purpose of this system is to keep honest men honest and to remind folks that there is no presumptive right to free Starbucks, the way that many college students have come to believe that there is a presumptive right to free music.  The information collected can’t be enough to make a person hesitate for fear of their privacy, but that plus the fact that it is recorded is just enough to make them remember “Oh, thats right, I’m being watched”.

Here’s the rationale: the impact of one scammer who realizes he can beat the system (and, if you think of it, there is no system to beat here) is one ice drink per store.  The stores are franchises so you basically evaluate the damage to their profits on an individual level, where 1 or a 100 ice drinks is pocket change (here’s the secret to Starbucks: no matter how much they charge you, making the drink didn’t cost more than 10 cents!).  The damage to the brand from having to put that sign up everywhere, on the other hand, is at literally many orders of magnitude above the individual store.

Support Does Not Scale. Customer Service Does.

August 3, 2006

I’m a big fan of all things scaling, because thats what takes you from having to scramble for money on an hour-to-hour basis and gets you to the whole “Making money while drinking pina coladas on the beach” (or, in my case, iced tea in the shade) ideal uISV existence. Two of commenters recently left well-reasoned comments to the general effect that “Support costs a lot of your time and most users don’t need it. Don’t go overboard. Instead, help out the vast majority of your customers who don’t need support.” My comments:

Cutting a customer off: There is a certain school of thought that says you should have a maximum level of tolerance for any particular customer using support resources, and after that point you say “No more”. I actually think this is (potentially, depending on execution) a decent idea, which might suprise people in light of my recent paen to excellent customer service posts. You might also be suprised to learn that I’ve described someone doing it in the last 24 hours.

Here’s the cruel math of telephone customer service: the average cost of servicing a phone call is $12. The average profit of a small order is less. You cannot afford to absorb a support call for every small order. Class poll: who caught the fact that when the the representative offered free shipping and cookies to a minor no-profit-in-this-transaction customer it terminated a (potentially hostile) support incident in under a minute, totally obviated the need for a second call or an escalation to the supervisor, and still got the sale? And that that customer was so ecstatic to be brushed off he came back bearing hundreds of thousands of dollars? Thats the difference between support and customer service. As a support incident, that call was a waste of time/money. As an opportunity for demonstrating you’ve got an unparalleled dedication to customer service, that call is as good an opportunity as every other customer contact you make.

Saving Money/Time on Support: Your first line of defense against “wasting time” (never, ever, ever think of talking to a customer as a waste of time: see below) in support is producing a quality product. I sell to a rather non-technical market. I could be spending the rest of my life fielding calls on how to use the product — and I rather don’t want to, so I coded the project to be immediately usable by anyone who is capable of finding the Internet. The handholding starts at downloading/installation (clicking enter until you can’t anymore works and will dump you at my program’s main screen) and continues to my main screen (which doesn’t just explain what you need to do, it reads my app’s typical use case out to you, step by step). Improving your application is probably one of the best-scaling support investments you can make: if you consistently find yourself copy-pasting a canned “That feature is in the Tools Menu, 3rd from the bottom” response, you should probably go about making it more obvious. If you have a work-around for that annoying printing bug, fix the annoying printing bug.

How to Think of Support: I would generally advise against thinking that you’re wasting time doing support. Most people are rather poor actors — heck, most actors are rather poor actors. If you’re annoyed by the incident thats likely to come across to your customers. Think of it as an investment if it helps you — you’re investing in your reputation as a customer-service powerhouse. Against a reputation like that, firing off a few emails every day is cheap. (Think of it: suppose that 5% is an accurate accounting of the number of “needy” customers you have. Suppose you’re rolling in the dough at 1,000 orders a month. 5% of 1000 is 50, multiply by say 4 inquiries each is 200, averages to 7 per day. 7 emails a day is nothing — you can take care of that while brewing coffee.)

Politeness and a smile are free: You can’t always say yes to a customer request (although I’d strongly suggest defaulting to yes and requiring good reasons to say no, rather than the other way around). You can, however, have 100% of your customer-facing communications be polite and positive. For instance, compare the following two emails.


You emailed me about this support issue 4 times this week. I’ve done what I can for you. Its obvious things aren’t working out. I’m refunding your purchase price.

Sincerely, Peevish uISV

Thats the wrong way to do things.

Dear Bob,

I have done some research regarding your support request. As it turns out, our product is regrettably not the best on the market for your needs. In our professional opinion, MicroFoos’ Foozle 2006 is a closer fit for your requirements. While it pains us to have not been able to help you, here at Pleasant ISV we are totally dedicated to customer satisfaction. Accordingly, we could not in good conscience accept your money with these issues outstanding, and have instructed our credit card processor to refund you.

Thank you for choosing Pleasant ISV and we look forward to the opportunity of serving you in the future.

Sincerely, Pleasant ISV

Content-wise, these emails describe the exact same set of circumstances. In terms of customer perception, these two emails are worlds apart from each other. Peevish ISV’s mail is, well, brusque and strongly leaves the impression that there was something wrong with the customer. Pleasant ISV’s mail doesn’t blame anyone (no, really, read it again — it doesn’t say or imply a single negative thing about Pleasant). It screams “we’re competent, we’re professionals, and we don’t accept anything less than the best”, and it leaves the door open rather than slamming it on your customer’s fingers.

An inspirational quote: “ We are what we repeatedly do. Excellence, then, is not an act, but a habit.” — I have seen this one variously attributed to Aristotle and Adlai E. Stevenson. In any event, if you make excellence the routine in your customer service, people will know the difference. Promising good support/promising good customer service scales very well for your business. Think of it like the guarantee: you can’t afford for everyone to ask for their money back, but you know in advance that the overwhelming majority of people will not ask for their money back. And you know that the number of customers reassured by having the guarantee outweighs what you’ll spend on it. Support is exactly the same. Most people won’t need it, but lots of people are reassured by the fact that it is available if they do need it. Your customers have been trained for years to distrust software, despite the fact that most customers will not have any problems: software is impersonal, software gets in the way of them doing what they need to do, software breaks, and when software breaks they spend 10 hours in tech-support heck talking to people who hate them and don’t have any answers.

What if you could reassure customers? What if you had a deserved reputation for *not* blowing up in people’s faces, and for being a joy to work with? So beat the drum and beat it loudly:

If you have any problems, or just want to ask a question, talk to us. We have an actual human here. Even better — not just an actual human, you’ll get all your support emails answered directly from the head engineer/company president! (Try that with your other software vendors some time!) We care about your concerns and will work to make them right. Take a look at what Mary Sue of Normal, IL and Bob Smith of San Fransisco had to say about us: “Wow, I had expected to get a canned reply but they got back to me within 15 minutes and kept working until my problem was solved.” and “Pleasant uISV is the best in the industry, bar none. Once I bought one of their products and it wasn’t working out for me. They gave me my money back without me even asking and referred me to a competitor! It was more important that I be happy than that they make a buck. I’ll never stop using Pleasant and I recommend them to everyone I do business with.”

Or, you could say something like

Support incidents: Every customer has a maximum of four support incidents, after which they must pay a non-negotiable charge of $24.95 per incident. We do not answer requests about generic computer configuration problems, setting up web pages, etc etc.

Which of these two companies would you rather do business with? Which sounds like a risky investment? Which sounds warm and inviting?