“Please contact support.” Makes you cringe, doesn’t it? At Newton we encourage people to contact support—by email or phone. No, I’m not kidding.

We call it “Support Driven Design”.  I’ll explain this concept in just a bit, but first I’d like to give you some background on how we came to believe that free technical support results in better recruiting software: it makes it easier to use, faster to deploy, and paradoxically, makes supporting your customers cost less (which in our case means we can sell our hiring software for less money).

In the beginning providing free technical support, like we do at Newton, appeared to be purely a business decision: giving away support makes the buying decision easier for people. We also didn’t have the time to build a big FAQ on our site, so we were pretty much required to do this personally anyway. On top of this, we also don’t like paying for support, or reading online help, and felt that we shouldn’t make our clients do something we don’t like to do. Today we think it was a good business decision, and an even better product one.

Of course we were warned.  The “old-school” software folks, whose advice we openly take and whose success we jealously admire, told us that providing free technical support was a bad idea. “You’re going to have to charge for it sooner or later because it will eat your margins,” “support is a profit center,” they’d say. We’ve always had a problem with authority…

Design the Question Out of the System

One of the first things we tell any customer at Newton is, “If you don’t understand something, no matter how small, it’s our fault, not yours. Let us know.” We ENCOURAGE technical support emails and phone calls. Again yes, I am being serious.

As a result, and contrary to what you might think, we are hardly ever asked to provide support. The net result of Support Driven Design has been that today we get less than 1 support question per year per customer, or about .01 questions for each user per year, a group of business users can be trained in 5 minutes, and a recruiter in a mind-numbing 30.

In the beginning, and still today, our product managers, i.e. the people responsible for designing Newton’s applicant tracking software, did all the walkthroughs, customer training, and provided all support. Without knowing it, we had started a “Support Driven” design shop. When we’d get a question from someone, we didn’t add it to the user manual, we’d think about how we could redesign Newton in such a way so that we didn’t have to answer the question again.

I think this has been more than a modest breakthrough for us. Instead of teaching people how to conform to our recruiting software, instead of an online hiring FAQ, we take each question and “design the question out of the system”.

For example, early on we had this bad “More Info” button that people overlooked. Since all support email came through my desk, as it does today, I answered the same question three times in one week, “Where do I find this <something>?” One of our customers actually apologized for asking me a “silly question”! Have we come this far? Do software users really think that it’s their fault for not understanding something? Clearly, it didn’t look like a button, and clearly it was our fault.  That week spelled the end of that button. Support questions: 0. Easier to use: 1.

The Tail Wags the Dog

Since we’ve never charged for support we’ve learned to appreciate that if we design a confusing feature we’re going to pay for it later. Since we don’t force people to an FAQ page, we know immediately when something isn’t working. The tail of support wags the dog of design: if you can’t charge for it, you better make it work right out of the box.

As a result, we often design a feature and say to ourselves, “we can’t do this, it will create support tickets.” This approach is not for everyone (especially for companies that get paid for making confusing software). It puts tremendous strain on our design process, and is the single greatest reason why it takes us 4 times longer to design (i.e. mockup, whiteboard, wireframe, etc.) a new feature than it does for our development team to build it.

The output of this also means that we can provide free training. We don’t like losing money any more than anyone else and if it took us 4 hours to train our customers, or 40 emails to answer their questions, we’d never be profitable. Free support: design the question out of the system + design rigor = easy training.

Maybe paid support is why one of the more common questions asked in an RFP is if we have an online FAQ. Think about that. Buyers are actually asking if you have a way NOT to help them. Our answer is simple, “just call us.” You might counter with, “well, I would like to just figure it out myself, without contacting support.” Tail wags the dog: you need an FAQ because the software is confusing, it is confusing because instead of designing your question out of the software, it was built into a support guide.

I think it is worth noting that people aren’t accustomed to this business model.  People actually apologize for “bothering me”.  One of the things we try hard for at Newton is to change this behavior, to “re-train” people (in 5 minutes or less, 30 minutes for recruiters <wink>) into believing that we aren’t doing them a favor for answering their questions, they’re doing us a favor by asking one. I think it speaks to just how far software has moved away from the user, and how far it has yet to go towards providing real productivity.

So the net result is that free support has led to less support. Like I mentioned before, we get about 1 support email per year, per client. I can’t imagine that Newton will ever have a technical support department that’s not run by our design team. Unfortunately, it’s gotten rather lonely over here in the support department. Can someone please contact support? Have I mentioned it’s free?