You know what it feels like to be the hero who has just fixed “the thing”. Imagine you have spent hundreds or thousands of hours developing your solution, and now you’re ready to deploy it. Is your work done? The truth is that until now you have been playing your favorite game. Now the real life begins…
Your customer, your users are going to start using the solution. Until now you had enough time to think, elaborate, test, review, rewrite, and whatever you understand as “development”. Starting from now, everything your client asks for, whether it’s an issue to fix or a need to address by a new feature, everything needs to happen immediately.
If you attended FileMaker DevCon 2015 in Las Vegas you could come to our session where HOnza Koudelka presented how to become a troubleshooting hero for your clients. If you have missed the opportunity, or just want to recall some details, now you can watch the session recorded below.
If you prefer reading over watching a video, here is a brief text version of the session:
Imagine you get a call from a user: “My FileMaker is crashing when I try to print an invoice.” But you cannot replicate the issue. You spend maybe 10 more minutes on phone and very hard time trying to reproduce the problem that the user is having. Do you think the user is going to see you as a hero? Are you going to feel as a hero? No because you don’t even have a clue what’s happening there.
It’s all about users frustration
Have you ever had a similar situation accepting a tech support call like this and being in the same situation? This is actually something that happened to my team several years ago when we got a support call from our own user in 24U. Luckily at that time the effective feature was not as critical as invoicing, so had few days to try to reproduce the issue and fix it but we learned something very important about how user feels when calling for tech support. Frustrated.
The problem when a user calls for tech support is that the user has his task for the day and the software that he’s using is just a tool that he uses to accomplish the task. So when he calls for a tech support he calls because his tool has broken and he cannot do his work.
But users are very smart and before they call tech support they try to fix their tools themselves. So when they call you they are already behind a schedule. They are frustrated because of the situation and they are hoping that you can just use a magic wand and make the tool work again. But the true is that you have a negative time to fix the problem.
However it seems counterintuitive, your primary goal at this moment is not to fix the software! Your primary goal is to make the user able to work again as soon as possible. If you can do it immediately during the call, that’s what’s going to make you feel like a hero and to be perceive like a hero.
The biggest problem with the user helping you to fix the problem immediately is that a frustrated user hardly remembers what he was doing a minute ago. What you need to know is exactly what the user was doing to reach the situation, so that you can reproduce the issue and fix it. It’s much better to have another reliable source of that information.
With knowing in real time what exactly the user was doing, you may be able to help him simply by suggesting another (working) way to do the same thing, and gain time for proper bug fixing. In such case you will finish the call with the user immediately able to work again. Is that a better way to handle tech support?
Time is Money
OK, that was the emotional perspective but how about business perspective? How much does it cost you to take a support call? First of all you should take into account that there are at least two people who are wasting time when you’re on the tech support call. You and the user that’s calling you. And don’t forget that the user has already wasted some time trying to fix the problem himself. Also the more users are affected the more time they are wasting and of course the higher they are on the org chart hierarchy the more costly the time of the users is.
Do you know what a wasted minute of Tim Cook’s time is worth? I’m not saying that Tim Cook calls me to for a tech support, although that would be great, but everyone would be more nervous for every minute not being able to save to solve Apple CEOs issue. But even if you’re not helping as important person as a Apple CEO, there is also your time that’s costing you money.
Now what do you think, when do users call for support? Can you schedule that? And is the time that you schedule equally expensive as the time that you cannot schedule? Even when you get at 5-minute support call, the distraction is causing you to waste much more time, maybe double at least.
If you’re an average FileMaker developer, then the tech support guy and the developer are sharing the same body. In such case any tech support call time is at least twice as expensive for you as the development time which you can schedule. Based on my practice in most cases the cost of tech support call is at least four times as expensive as a scheduled development time.
24U FM Bench to the rescue
In the beginning I mentioned a support call that actually happened in 24U several years ago. What I didn’t mention is that later on during the past year or two we had many such support calls which already were related to critical features where the users couldn’t wait. Luckily these more serious issues happened after we started logging every user action so we had access to that another reliable source of information about what users were doing. Thanks to that we started to be able to reproduce the problem and fix it much faster than we were able three years ago.
We use our own tool called FM Bench for this purpose. We originally developed FM Bench as a tool for helping us to optimize FileMaker solutions’ performance but what we learned later is that we only used it about three times within a year to optimize our own solution. But within that same time frame we used the data that we are getting from FM Bench at least 15 times to help us troubleshoot problems. The value that we were getting from using it for troubleshooting may be 10 times higher than the value we are getting from the optimization. That was very interesting discovery.
The point is that we never turn it off. When a user calls for support we always have the log. We can check it and we know what the user was doing a minute ago or five minutes ago and if we don’t know enough details we can just add more logging in to the specific feature that has issues and the next time the users use that feature we immediately have enough information to fix it.
Proven by customer
Interestingly, about the same time we figured this out, my customer figured the same thing out. The customer was Dean Bedford, founder of a company called Planet Systems Group. He created a FileMaker based sales management system for his customer Mountain Lumber in central Virginia back in 1997.
After 16 years of continuous development, Dean bought FM Bench to implement it into this legacy system in order to find out how it’s being used by the users and how it could be optimized. After implementing FM Bench Dean was able to see which scripts were used and which were not. He was also able to audit the speed of his solution to identify the piece of the code that needed to be optimized. After examining how users use the system Dean was even able to make the customer become more productive.
Dean focused on a few key scripts and counted how many times each user is running those scripts. He discovered that the salespeople who run the scripts more often are making more sales than the users who run them less often. So he proved that his system is actually helping the company to make more sales and this was key finding. They could train the users who use the system less to use the system rather than trying to use their intuition and that helped them to make more sales.
One day Dean got a call from the customer saying: “Hey, Dean, I have this new sales person who’s saying that the system doesn’t work can you please call him and fix it so that he can do his work?”
Dean was quite surprised but he’s very serious about taking providing good customer care and the quality of his system so he first wanted to check where the problem might be. He would prefer to call the user with some knowledge already and say: “Hey, you’re doing this mistake and when you do this differently the system will start working for you.” So he checked the log that he already had and guess what he discovered…
The new sales person, after starting the system for the first time in the first day in the office, never used the system again. So the user was reporting that the system doesn’t work but the reason why it didn’t work was that he didn’t open it at all.
If Dean didn’t have the log, what do you think, he could spend maybe a day trying to fix the problem. By having the tool he knew immediately that the problem was the user and didn’t have to waste a day of support time. That single case might have saved him about thousand dollars worth of billable time.
Conclusion
The actual value we have got from having FM Bench implemented is a better way to handle tech support.
Instead of handling support calls from frustrated users we are not able to help efficiently, we can see what users were doing before they called, so we can help them much faster.
If you see some similarities with your practice, if you want to redefine your troubleshooting, don’t hesitate and start today. You can implement your own activity logging, or you can simply get 24U FM Bench. You can download FM Bench as a free demo so you can start free of charge. Or you can even hire us to help you with your change. Just schedule a call to discuss your needs.