As the information technology industry migrates from on premise to cloud and hybrid applications, the number of potential variables affecting a successful product installation is increasing rapidly. The challenge facing tech companies is how to increase customer satisfaction to hold on to existing customers as well as earn new accounts.
Customer satisfaction is something that can’t be bought, but must be earned. It’s easy to get a new customer to try your new product or service, but if you can’t keep them happy, they’ll soon leave you to try whatever competitor is shouting the loudest.
If you were a tech company, and you knew of a best practice that would prevent 40%+ of your support hotline calls from being made, would you follow it? Of course you would. Would you tell your customers to follow it?
Ah, that’s the issue. Not IF you would tell your customers, but HOW to tell them. And therein lies the concept of Best Practices Consistency.
Some years ago, I was appointed to an end user task force by a major technology company who wanted to improve end user satisfaction. As part of this task force, the manufacturer analyzed their technical support call center data to find out what were the most common problems and solutions.
The answer was simple, and it blew everyone’s mind: over 40% of ALL tech support calls were resolved by asking the customer to apply all outstanding patches and fixes, reboot, and attempt to recreate the original problem.
Obviously, this was a best practice that needed to be communicated. But how?
Customer satisfaction with technical products and services depends upon a “three legged stool” of” Training, Professional Services, and Support. It could be argued that Development adds a fourth leg --as we’ll see later—but I’m concentrating on the customer-facing departments of a typical product/service manufacturer.
Each of these functional areas feeds into and is fed by the other two areas. Failure or absence of any of these functions leads to increased stress and reduced customer satisfaction in the other two areas.
In this case, the manufacturer set the best practice of “Patch, Reboot, Reproduce” at the top of their technical support engineers’ call checklists, right after establishing customer contact information and product type/version.
Next, the manufacturer had its instructors teach this best practice in end user technical training classes. “After installing the product, make sure you’ve patched and rebooted. If you run into any problems after installation, always check and apply new patches before calling Technical Support.”
Finally, the manufacturer’s professional service consultants were also instructed to discuss and demonstrate this best practice with every client during each consulting engagement.
Unsurprisingly, while the number of technical support calls didn’t decline immediately, the average length of time for such calls dropped steadily. Eventually, as customers internalized the best practice, the tech support call volumes started to drop.
During this period, customer satisfaction with the manufacturer’s products started to rise.
I tell this story not to teach the best practice itself, but to illustrate that creating and teaching best practices leads to wonderful things for all parties concerned.
Establishing Best Practice Consistency begins with defining a list of best practices for your technical product or service. Some best practices might actually be considered product prerequisites, but should still be included in the list to be taught to customers.
The rule I follow: if a specific practice will prevent product malfunction, customer frustration, or a technical support call, it belongs on the Best Practice List.
Once you’ve established a list of best practices, circulate it internally between your company’s Development, Support, Training, and Professional Services groups. All of these groups must have input. Keep in mind that a product engineer may make assumptions about a customer’s technical environment which are different from those of a trainer, support engineer, or consultant.
With an agreed-upon list in hand, it’s time to insert that content in a number of places:
How does this impact the customer? Let’s think about that for a moment using a sample best practice.
Jane has been tasked with implementing a new complex application from XYZ Company. As part of the implementation, she’s sent off to a training class, after which she’ll meet with one of XYZ’s consultants to begin installing the application.
During training class, she’s warned “Make sure that you have at least one physical server time-synced to a reliable external time source.” The class curriculum guides her through checking time synchronization, further making her aware of the need for the best practice.
The next week, when XYZ’s consultant comes in to help Jane install the product, Jane is asked by the consultant if she’s checked her network time sync. Jane remembers this was discussed in class. Since consistency of information is generally perceived as familiar (and therefore reassuring), Jane probably feels an increased level of comfort. Not only was what she was taught a common practice, but her consultant knows about it, too. This gives them a common concept and/or vocabulary to assist in building an effective professional rapport during the installation.
Several months after the product’s been successfully installed, Jane has a problem and calls tech support. They ask her if her network time sync is in order. Again, the consistency of information is reassuring to Jane, putting her more at ease. Even if she’s impatient at that point (“Yes, yes, time is fully synced!”), she knows that the tech support engineer is working through the same list that she was taught, the same list that was reinforced by the company’s consultant. The support engineer’s job is easier, because Jane already has a time-synchronized network, so they can move on more advanced potential causes of problems.
This entire situation applies to not just best practices, but also to technical vocabulary. Establishing a set of common concepts (best practices) using a consistent vocabulary will also help facilitate better communications between customer and manufacturer.
However, when the dissemination of best practices is applied inconsistently (or not at all), customer satisfaction will decrease as support difficulties (or perceptions of same) increase. For example, if a critical best practice isn’t taught during training classes, then the customer will be (probably unpleasantly) surprised during the first interaction with a consultant or technical support. “But nobody ever told me that!” is a terrible way to begin a support interaction.
Customer satisfaction is something that can’t be bought, but must be earned. It’s easy to get a new customer to try your new product or service, but if you can’t keep them happy, they’ll soon leave you to try whatever competitor is shouting the loudest.
If you were a tech company, and you knew of a best practice that would prevent 40%+ of your support hotline calls from being made, would you follow it? Of course you would. Would you tell your customers to follow it?
Ah, that’s the issue. Not IF you would tell your customers, but HOW to tell them. And therein lies the concept of Best Practices Consistency.
Some years ago, I was appointed to an end user task force by a major technology company who wanted to improve end user satisfaction. As part of this task force, the manufacturer analyzed their technical support call center data to find out what were the most common problems and solutions.
The answer was simple, and it blew everyone’s mind: over 40% of ALL tech support calls were resolved by asking the customer to apply all outstanding patches and fixes, reboot, and attempt to recreate the original problem.
Obviously, this was a best practice that needed to be communicated. But how?
Customer satisfaction with technical products and services depends upon a “three legged stool” of” Training, Professional Services, and Support. It could be argued that Development adds a fourth leg --as we’ll see later—but I’m concentrating on the customer-facing departments of a typical product/service manufacturer.
Each of these functional areas feeds into and is fed by the other two areas. Failure or absence of any of these functions leads to increased stress and reduced customer satisfaction in the other two areas.
In this case, the manufacturer set the best practice of “Patch, Reboot, Reproduce” at the top of their technical support engineers’ call checklists, right after establishing customer contact information and product type/version.
Next, the manufacturer had its instructors teach this best practice in end user technical training classes. “After installing the product, make sure you’ve patched and rebooted. If you run into any problems after installation, always check and apply new patches before calling Technical Support.”
Finally, the manufacturer’s professional service consultants were also instructed to discuss and demonstrate this best practice with every client during each consulting engagement.
Unsurprisingly, while the number of technical support calls didn’t decline immediately, the average length of time for such calls dropped steadily. Eventually, as customers internalized the best practice, the tech support call volumes started to drop.
During this period, customer satisfaction with the manufacturer’s products started to rise.
I tell this story not to teach the best practice itself, but to illustrate that creating and teaching best practices leads to wonderful things for all parties concerned.
- Customers who are taught product installation best practices feel more empowered and less frustrated than those who are just handed a manual and installation media.
- Professional services consultants use best practices to not just empower clients, but to establish a rapport and provide added value.
- Technical support engineers who speak with customers who are following best practices will have an easier time troubleshooting issues, leading to reduced frustration on everyone’s part and shorter call times.
Establishing Best Practice Consistency begins with defining a list of best practices for your technical product or service. Some best practices might actually be considered product prerequisites, but should still be included in the list to be taught to customers.
The rule I follow: if a specific practice will prevent product malfunction, customer frustration, or a technical support call, it belongs on the Best Practice List.
Once you’ve established a list of best practices, circulate it internally between your company’s Development, Support, Training, and Professional Services groups. All of these groups must have input. Keep in mind that a product engineer may make assumptions about a customer’s technical environment which are different from those of a trainer, support engineer, or consultant.
With an agreed-upon list in hand, it’s time to insert that content in a number of places:
- Every professional services consultant should have that list ready to show and hand to clients.
- Every training course should include a copy of that list as part of the curriculum. (Extra points if the training class guides students through each of the best practices!)
- The best practices checklist should be part of technical support’s basic call checklist.
- Product engineers should have copies of the checklist to refer to as they make changes to code, so that if their base assumptions about the product environment change, they can notify the other teams.
How does this impact the customer? Let’s think about that for a moment using a sample best practice.
Jane has been tasked with implementing a new complex application from XYZ Company. As part of the implementation, she’s sent off to a training class, after which she’ll meet with one of XYZ’s consultants to begin installing the application.
During training class, she’s warned “Make sure that you have at least one physical server time-synced to a reliable external time source.” The class curriculum guides her through checking time synchronization, further making her aware of the need for the best practice.
The next week, when XYZ’s consultant comes in to help Jane install the product, Jane is asked by the consultant if she’s checked her network time sync. Jane remembers this was discussed in class. Since consistency of information is generally perceived as familiar (and therefore reassuring), Jane probably feels an increased level of comfort. Not only was what she was taught a common practice, but her consultant knows about it, too. This gives them a common concept and/or vocabulary to assist in building an effective professional rapport during the installation.
Several months after the product’s been successfully installed, Jane has a problem and calls tech support. They ask her if her network time sync is in order. Again, the consistency of information is reassuring to Jane, putting her more at ease. Even if she’s impatient at that point (“Yes, yes, time is fully synced!”), she knows that the tech support engineer is working through the same list that she was taught, the same list that was reinforced by the company’s consultant. The support engineer’s job is easier, because Jane already has a time-synchronized network, so they can move on more advanced potential causes of problems.
This entire situation applies to not just best practices, but also to technical vocabulary. Establishing a set of common concepts (best practices) using a consistent vocabulary will also help facilitate better communications between customer and manufacturer.
However, when the dissemination of best practices is applied inconsistently (or not at all), customer satisfaction will decrease as support difficulties (or perceptions of same) increase. For example, if a critical best practice isn’t taught during training classes, then the customer will be (probably unpleasantly) surprised during the first interaction with a consultant or technical support. “But nobody ever told me that!” is a terrible way to begin a support interaction.
RSS Feed