Help Your Customers Succeed with Best Practices Guidelines
If you hired a contractor to remodel your kitchen, wouldn’t you expect her to tell you about that load-bearing wall?
You don’t hire a professional just because you don’t have the hours to do some hammering and electrical wiring; you’re also hiring their experience and the knowledge they’ve built up.
A good contractor will recognize that your ideas about kitchen design will leave you tearing your hair out later when you realize there are no outlets to plug in the blender, and propose alternate suggestions.
The same thing applies to your customers. They aren’t buying software – they’re buying problem solved.
I hear some of you saying, “yeah, but I’m not a consultant! It’s not scalable to look at every customer’s unique situation.” To that I say:
- Is there more than one way to use your product?
- Is your product delivered as a white-labeled or configurable service?
- Do your customers make decisions on how your product is used, discovered, or integrated into their existing websites or processes?
If you answered “yes” to any of these questions, you need a Best Practices guide for your customers. Without one you are not providing a whole product solution because you’re not providing your experience and subject matter knowledge. How else can you maximize their chances at success and satisfaction?
What belongs in a Best Practices guide? Well, it’s going to depend on your product, but you may want to think about:
Installation / Integration. In an ideal world, how would a customer install or integrate your product? If you yourself are not the installer/engineer/IT person, find the person responsible for this internally and ask them.
More often that not, you’ll hear something like “well, of course they’ll want to create a new database table for that”… something that would NOT be obvious to your customer. Especially if you’re selling into large companies, IT resources are limited. Their engineer shouldn’t have to read through dozens of pages of installation manual to know that they will need the DBA’s help installing.
Configuration. What are the impacts of certain configuration options? Will enabling feature X decrease performance? Does disabling feature Y make the product far less usable?
A few years ago, I worked with a customer who wanted to disable a feature. Users of our web application could either pay a bill one time, or opt into having that bill automatically paid. The latter was more profitable to the customer, but caused many users to exit the registration funnel. Because we did not clearly communicate the usability and usage consequences of disabling this feature, we had a lose-lose situation.
User Interface / User Experience. Are there text labels or headlines that draw more users’ attention? Should/shouldn’t your web application open a new window? Have certain visual designs resulted in better performance? Show screenshots of customers who are seeing good results.
Demos, Help, or Splash Pages. What works in getting new users up to speed with your product? If Flash demos make it seem dead-simple, recommend that your customers create one (or better yet, offer them a bare-bones generic on.) If you’ve noticed higher registration completion when the splash interstitial says “free”, that’s information your customers should know before they start creating their branded splash interstitial.
Customer Service Responses / FAQs. What questions can your customer’s service people expect to get? How should they respond to certain questions? You may not think it’s your job to create canned answers for someone else’s customer service rep, but no one else has the same combination of a) invested in the product’s success and b) deep product knowledge.
Expectations. If the customer takes all of your recommendations, what benefits can they expect? BE HONEST. You need to make it clear that following your recommendations are worth their while; you also want to set expectations appropriately.
This list isn’t comprehensive (it’s probably too web-application-centric to be that) – but hopefully it gives you somewhere to start on your document. If in doubt, brainstorm. What do our best customers look like? What do our bad customers look like? and use that to identify your best (and worst) practices.
Note: if you’re lucky, you have “good” customers to reference. I haven’t always been that lucky. With one of my products, the first customer, the one that was supposed to be the Reference Customer, had a terrible deployment. Through web analytics and raw input from their customer service department, I was able to identify what they’d done wrong.
(But I didn’t – and would not recommend – writing the guidelines as “Don’ts” instead of “Do’s”. Instead, I took the opposite of what they did and codified those as guidelines. When other customers asked, verbally I would admit “here’s what another unnamed customer did and the bad results we saw” but I don’t generally recommend putting negative recommedations in writing.)
Did you like this post? Tweet it! 
Stumble This Post
Tags: best practices guide, Communication, deployment, examples, make it easy, the whole product
-->