Initial response times
350% faster than average.
Has your team ever found a bug or had one reported by your customers? If you are in the software business then you likely answered “yes.” So you direct the team to resolve the bug – while also performing other tasks which they were already working on. This alone has cost your team time. Your team states this will only take five minutes to resolve.
Eventually it is time to test and deploy the solution. During which time you find that testing fails, and you need to go back to the customer for additional feedback for a retest. Before you know it, five days have passed and you have not provided a solution but worse than that your customers have no idea what is going on because they have not been kept informed of what your company has been doing.
What can you do about it?
So the moment that you or aware that there is an issue with your product – before you start working toward the code fix – put together a process for how your brand will interact with it’s customers. This might include the following:
This does two big things for you right away.
For example – Let say your customers can’t update their profile information because of other work you are doing to the code that powers that section of the website, so all they get is an error message. That leads them to create a support request. These will come into you ticketing system in addition to the others that you receive already.
As a workaround, maybe you provide an alternate page with a simple form to gather that information or only their email address. Your team can then later enter that data manually into the database once the issue has been resolved OR advise the customers to do it themselves via email.
The primary point being, that the customer was not inconvenienced or left hanging while your team worked to resolve the issue.
One of you customers contacts you and says, “your product is great but it just stopped working for no reason after 6 months of working flawlessly. Please fix it as soon as possible, it is costing me money.”
1. You – I will certainly be happy to get this resolved for you, please tell me what version of the product you are using.
Your customer – what difference does that make, I just need for your to fix it.
2. You – Well we are here to help you but before we start troubleshooting, it is useful for us to know what version of the product you are using.
Your customer – I am using version X.
3. You – Version X is three releases / versions behind the current version. In fact, the current version contains several fixes and a new feature. Please update to the most recent version of the product through your WordPress dashboard, then test to see if the issue still exist.
Your customer – Well I updated and no longer have the problem. Thank you so much!
4. You – Thank you. We were glad to help. Please let us know if you have any further questions.
Thats four replies that were made to the customer, over any number of hours or days to inform them of something that should be considered a very basic first troubleshooting step before any further troubleshooting should take place.
That’s valuable time wasted to any business that could be better spent developing the product or marketing it and growing your business.
If any of this sounds familiar to you then you I have good news. You can avoid or at least reduce these types of support request with a few simple steps.
Reduce your support request by informing your customers of the importance of updates
1. Add or create an FAQ that informs your customer that many issues may be resolved by keeping WordPress, your theme and all of your plugins updated. A previous update may have resolved the issue and they should update then test to see if the issue was resolved before creating a support request.
2. Add or create a note in your contact form for support request that informs your customer that many issues may be resolved by keeping WordPress, your theme and all of your plugins updated. A previous update may have resolved the issue and they should update then test to see if the issue was resolved before continuing to create a support request.
Gravity forms is a very good tool and has this – conditional logic – functionality. You can see it in use on their support page. Make a few different selections and you will notice different information is provided.
3. Add a note to your support request auto responder – if applicable – that informs your customer that many issues may be resolved by keeping WordPress, your theme and all of your plugins updated. A previous update may have resolved the issue and they should update then test to see if the issue was resolved before continuing to create a support request.
As a plugin or theme user, consider and understand the following scenarios that happen every day:
If WordPress puts out an update tomorrow that breaks your favorite plugin – something that is beyond the developer or your control – and the plugin developer puts out an update to correct the issue. You would not receive that update and the plugin would not work. An update may resolve the issue.
If we your theme developer puts out a new update and it breaks a plugin that you are using – something that is beyond your control – and the plugin developer puts out an update to correct the issue. You would not receive those updates and the plugin would not work. An update to the plugin may resolve the issue.
If the plugin developer puts out a new update and it breaks a theme that you are using – something that is beyond your control – and the theme developer puts out an update to correct the issue. You would not receive those updates and the theme would not work. An update to the plugin may resolve the issue.
Objective: To share basic information about technical support tiers.
Audience: Anyone interested in information that can be used when structuring their support tiers or just interested.
All organizations provide support in a manner that works for them. There are many different variables to consider when structuring a support organization. Those are outside the scope of article but we would like to outline some of the basics of a tiered technical support structure.
This group usually acts as the first line of communications for your customer when they reach out for technical support. This tier usually checks that the customer actaully has an account or license. This tier confirms whether the issue is actaully technical support related or not. If not, they direct the request to the proper channel. This tier clarifies the issue that is being reported and request any other symptoms that may help with this clarification.
Once that information has been gathered, this tier generally answers basic questions such as those that are already documented in the FAQ or knowledge base, if those resources are in place. If those resources are not in place or the questions are not answered there, this tier would initialize basic troubleshooting and attempt to resolve the issue. If they are unsuccessful in resolving the issue, this tier would escalated the issue to tier 2 support.
Some examples of the type of request that this group commonly handles are; feature request, billing, installation and setup, and customization.
Note: In some models, Tier 1 and Tier 2 are considered the same group.
This group may at times act as the first line of communications for your customer if the team is busy. This tier usually receives a request from tier 1 support for additional assistance with resolving an issue. They already know that the customer has a valid account or license. They have clarification on the issue, the symptoms and what level of effort has already been attempted by the tier 1 technician.
In some support models, tier 2 will actually not work with the customer directly, instead, they will act as a guide or mentor for the tier 1 tech in the background and help tier 1 through to a solution. In this model, the tier 1 tech maintains the conversation with the customer but has to leave or place the customer on hold at times to engage with the tier 2 tech.
In other models, tier 2 will accept an introduction to the customer and an official handoff from tier 1 to tier 2 will happen. At which point tier 2 will own the conversation with the customer until the issue has been resolved by working directly with that customer. In my opinion, this offers the best customer experience. Although the customer is being transferred, which many customers do not like, they are placed in the hands of someone who is generally more experienced and has access to all of the resources that are required to resolve the primary issue and any others that may be discovered along the way.
Some examples of the type of request that this group commonly handles are; uncommon or unique issues, testing to replicate possible bugs, inquires that require responses from tenured troubleshooters.
Note: In some models, Tier 1 and Tier 2 are considered the same group.
This group rarely acts as the first line of communications for your customer. This tier usually receives a request from tier 2 support for additional assistance with resolving an issue that is likely a defect or bug in the product. They already know that the customer has a valid account or license. They have clarification on the issue, the symptoms and what level of effort has already been attempted by the tier 1 and tier 2 technicians.
In most support models, tier 3 will actually not work with the customer directly, instead, they will act as a guide or mentor for the tier 2 tech in the background and help tier 2 through to a solution. In this model, the tier 2 tech maintains the conversation with the customer but has to leave or place the customer on hold at times to engage with the tier 2 tech. While it is rare for a tier 3 technician to engage with customers directly, it does happen and can at times be required to resolve unique issues that have been identified.
Some examples of the type of request that this group commonly handles are; uncommon or unique issues, bugs or product defects, new feature request.
We would like to hear any thought or ideas that you might have on how you structure your support team.
The manner in which your company manages a crisis tells your existing and potential customers a lot about how you run your business. Sales pages and press releases are good but when everything is going well, it’s easy to say good things about your company. One the flip side, when things are going bad – during a time of crisis – that is generally not when we are at our best but it is actually an opportunity to shine.
In this article we will look at three reasons why documenting your status during a crisis is beneficial to both your internal organization as well as your customers.
Keeping your customer informed is a cornerstone of technical support and operations. It is a highly under rated method of keeping your operations running smoothly. During a crisis, your customers have no idea what you may be doing to fix the situation if you do not tell them. No customer likes to be left in the dark especially when the product or service that they paid you for isn’t working.
Let’s say you release a new version of your product and it contains new features that you consider to be non substantial. Well your customers – new and old – may not feel this way. In fact they may be down right confused, why, because the product has changed. No matter how minor the change, it has changed and that is enough to create confusion. This study done by the Harvard Business Review list ten reasons why people resist change. By keeping your customers informed, it increases your approval rating with your customers because they can see that you are addressing the issue proactively.
If something goes wrong your customers will contact you. That is how it works. However, if you identify an issue before the majority of your customers do, should you wait until they see the issue then contact you? Probably not, in fact by publishing your issue whatever that may be, you are making your customers aware that there is an issue, that you are addressing and maybe an approximate time when it might be fixed. As long as you place this is a public place, say a support form, forum or blog, your customer has no need to submit a support request. This allows your team to focus on resolving the crisis instead of repetitively responding to it.
When there is a crisis, how does your internal team including you know about it? Obviously the person that discovers it initially knows but what about the rest of the team? Putting a process in place that enforces the documentation is a good practice because it provides awareness for all of your team at the same time. It also provides content that your Support Team can reference and point customer to quickly providing the answers and freeing time for the normal support request.
Now that we have listed some of the reasons, let talk about how to deliver this information. Transparency maybe the most critical part of this article. The importance of transparency cant be stated enough. An informed customer may not be a happy one but will be more happy than a customer that has an issue and is kept in the dark. Delivery can be a simple post or page on your site – likely in the support section.
One of the more efficient first steps when troubleshooting an issue is to identify what your end users setup looks like. What we mean by that is you want to know if the web hosting environment where the WordPress site has been installed, meets the minimum system requirements for running your plugin.
If it does not and you do not know that upfront – because you expected your end user to actually read the minimum system requirements page of your knowledge base – then you could spend minutes or hours troubleshooting for no reason.
We – the team at wpSaaS – has found that some web host report incorrect information through cPanel and other hosting dashboards. Some of these things are php version, mySQL version, whether mbstring or mcrypt php extensions for encryption is active or not. While this may seem like small things to identify and correct, they are also very time consuming.
There are other plugins that serve this purpose however, Sysinfo – at the time of this post – is being updated on a regular basis. You can download it for free @ https://wordpress.org/plugins/sysinfo/, we also recommend n our theme and plugin conflict guide and use phpsys info, however, it has not been updated in quite some time.
It’s the end of the week and you are reviewing your support request in your help desk ticketing system and seeing spaghetti. A large pool of data that seems to be never ending. It’s taken you several minutes to find that specific ticket type that your are looking for. If this sounds like a challenge that you or your team members have or you never looked into tagging and it’s benefits, then this article may just help you.
What are tags? Tags are words or phrases that can be attached to a ticket in your help desk ticketing system. These tags can then be applied by you or your team. Most ticketing systems have this as a feature although it is often not used or explained by the ticket system company.
If you have ticket volumes that do not exceed 20 or so per day, then this information may not seem as useful to you but you should still consider including tags in your ticketing process. If for no other reason, as your business grows, so will the number of support request and its better to be ahead of that growth than to chase it from behind.
Here is a list of help desk ticketing systems that offer tags and good documentation for using them:
Tagging offers several benefits and I will address one of the most important ones of them today. Trends. Let’s say that you are looking at your past 30 days of ticket history. All you see is rows of data such as dates, times, customers names, email addresses, and the widely varying customer entered subject lines and or body of the request. It can all become a blur until you start to open each instance individually. That’s going to take forever!
What you can not see is that 50 of those are the same or are related to the same issue or root cause. Be it a bug or a misunderstood feature, whatever it is, it is buried. Simply placing a tag on each support request as they are created – a task that takes 10 seconds or less – soothes this pain by giving the ticket an obvious identity which is easy to spot in a pool of request.
So what you’ve done is saved yourself the 3 minutes or more that it takes to open each of those 50 tickets and scan them to learn more about them and given yourself and your team an instantaneous sense of the support request.
You’ve just recovered 2.5 hours (3 minutes X 50 tickets = 150 minutes/60 minutes = 2.5 hours) of your day by applying this easy task.
As I wrote this I realized that there were a few more benefits of tagging that I’d like to share with you. Stay tuned next week and I will talk about them in addition to how you can use tools like Gravity Forms to automate tagging for you. Have questions about tags? Comment here or email me.