Imagine a bacon-wrapped Ferrari. Still not better than our free technical reports.
See all our reports

Confessions of a Support Engineer

Stories, Tips and Tricks for Support Teams

At ZeroTurnaround, we know very well by now that technical support is an integral activity that makes our products better, our users happier and us engineers smarter and more handsome. Everyone involved is making a big difference by helping out our users when they come into trouble.

We’re lucky in the sense that JRebel is a tool for Java developers (the smartest developers in the world, right?), so the support requests come mainly from savvy techies, meaning that we get to enjoy all sorts of relevant questions.

Sometimes, however, we like to do a little support team “house cleaning” and get all of our complaining out at once in a hilarious rant – like when we get emails that make us wonder not only if the author codes in Java, but whether they even own a computer.

This blog post is to allow us to have a little fun while also offering some insight and tips for other support engineers dealing with similar communication in their teams. Let’s briefly go over the type and tone of emails we receive everyday:

Group A – These are emails from JRebel users having trouble getting started. This is our bread and butter – set up, installation, rebel.xml, and more. Joy!

Group B – These emails come from people that have heard of JRebel, but want us to support them with tools that have nothing to do with our company. Some memorable cases are:

  • “Well, we’ve got a problem running Eclipse & Websphere…and what was that “rebel” thing you mentioned?”
  • “Oops, I’m using .NET after all!”
  • (after 20 minutes) “Oh, this isn’t a Spring support hot line?”

Group C – These are emails from spambots that have nothing to do with JRebel at all….like: “Dear ZeroTurnaround – have you ever felt small in the presence of a woman?”

Luckily, our support team gets emails mainly from Group A – we let the marketing droids handle the rest of the non-JRebel communication that comes in. Based on those emails, we’ve put together a list of four common support case themes, our responses and insight for them, and what these support cases means for the support team and the entire company.

This post is separated into four sections with tips at the end of section – maybe some of  these relate to your & your support team:

Case 1 – Documentation: Make it fast, easy to find and sexy

Case 2 – It’s not you, it’s me: Why you are getting the same email again & again from users

Case 3 – Complex problems: Don’t run away, grab hold and don’t let go!

Case 4 – “Stupid” cases: Helping them to help you

***

Documentation: Make it fast, easy to find and sexy

Getting users started with JRebel is the most important, and most frequent, support case that we see. To handle these cases, we recommend Using the Force.

The Force here refers to JRebel Documentation, which will not let you do cool stuff–well, reading is cool–like dodging marketing droids and jumping over sales clones.

Unfortunately, engineers are often too smart to read our documentation – they try it first without referring to the docs, which is actually a reasonable thing to do. Being able to use a tool/framework/etc without having to read all the documentation is actually a good indicator for the product: if you manage to set it up without guidance then it means that the tool is really user-friendly. At the same time, JRebel is not an iPod – three-year-old children cannot use it “out of the box”…so that’s the bad news. The good news that it is getting better!

*****

…introducing (again) the rebel.xml configuration file…

*****

Often, our users have set up everything correctly and the application has been started with JRebel, but they can’t see the changes being picked up by JRebel. This leaves the impression that JRebel doesn’t work, which isn’t true and therefore sucks.

What if you no longer had to redeploy your Java code to see changes? The choice is yours. In just a few clicks you can Say Goodbye to Java Redeploys forever.

But let’s get to the root of the problem. Many of our customers are using Eclipse, which is the most popular IDE among Java developers. And most of them are using WTP to start the application server. Prior to starting the application server, WTP will copy the compiled classes from the project to some temporary location while the target directory for the compiler. And obviously, in this setup, when you make a change to your app the compiled classes appear to the location that is not monitored by JRebel agent. To solve this problem, the rebel.xml configuration file has to be bundled with the application. Then JRebel will be able to detect your changes.

Support Team Tip #1: Guiding your customers to your awesome documentation is nearly always the first step–it keeps them informed, and reminds you that no documentation is ever truly finished, but rather a living thing that requires care and attention to evolve. Just don’t feed it after midnight

***

It’s not you, it’s me: Why you are getting the same email again & again from users

One of the issues with the support stream is that people do have similar problems. In fact, sometimes they even ask the same questions. This could be an indicator that something is wrong either with the software itself, usability or the documentation. But it is not always that easy to eliminate such issues, as there just no good solution invented yet for that particular type of problem.

Sometimes, it starts to feel like the clones are attacking when devs keep asking the same questions about one particular problem, a-la “how to setup”, “how to configure”, etc.

The issue might be regarding one particular application server, framework, or just the environment that people are trying to cope with.

To weaken the clone attack we can use a shield – a tutorial, an article or any other means revealing the particular aspects of the problem. FAQ is a good thing to have. Also, a screencast is a good thing to check out when dealing with non-trivial issues: we can record a screencast and just show it to the users. I can confirm that it’s helpful when users can see immediately what is wrong with their setup.

Support Team Tip #2: Support case clones means that you have a fairly common issue that isn’t being managed well – either you have a problem somewhere that is not getting enough attention, or all of your customers have been hypnotized. Make sure your documentation is in good order, and consider the navigability of your site – can users find what they are looking for easily? Remember: attack by email clones is better than attack by gremlins, so just keep improving your docs, FAQ section, screencasts, blog post, etc.

***

Complex problems: Don’t run away, grab hold and don’t let go!

Before going on to the more whimsical support email examples, I want to also mention that we do have fun with some “extreme cases” – we kind of like these the best.

Once in a while, a user will report JRebel misbehavior in some specific environment and provide an unbelievably detailed account and example for reproducing the problem. Sometimes, they even send us a VM image with the full environment. Not because we asked for it, but because the user wanted to get the feedback as quickly as possible.

Support Team Tip #3: It may be that the most challenging issue remains challenging for the support team because it hasn’t been reproduced properly. It’s fair to say that a frustrated customer will not “go the extra mile” to help you fix a problem that has already caused them to abandon your product (even an awesome, time-saving product!) A user that takes the extra steps to help you understand the root of the problem is worth keeping happy and in contact with…

***

“Stupid” cases: Helping them to help you

As I wrote before, some emails come from people that don’t seem to own a computer, let alone code in Java. But is this really the issue? These next three examples might seem to have just fallen out of the stupid tree, but don’t judge so fast…these emails say a lot about your relationship with, and understanding of, your users.

1. Check out this extract from a recent email (note: the From address has been changed to prevent this author from getting attacked by angry coders on the street):

To: support@zeroturnaround.com
From: cantread@wontlearntoread.com
Subject: “Where can I download JRebel?”

First reaction: WTF? Obviously, this person managed to find the support email on our website, but couldn’t find the download link? While I acknowledge that our website is a little weird and sometimes it is hard to find things, there are at least 2-4 still the download page isn’t that hard to find I believe. But don’t let perceived stupidity/laziness cloud what is really going on here, which is simply that they are blind. (Joke!)

2. “I saved the license file to C:\. What’s next?”

This is kind of an odd question, isn’t it? This user hasn’t even started using JRebel yet, and already they are asking for support. Obviously, if you’re using some tool you have to set it up first. Every tool for developers has documentation, especially if it is a commercial product. Try to find out if this is simple laziness, or maybe your website broke overnight and they really can’t find it. Once you tell them explicitly where to go, they should be fine from there. If not, forward the email to China.

3. “Uh, it doesn’t work”

Back to square one, eh? This user has probably  installed it, but probably hasn’t set it up. In this case, it would be useful to try to get the user to see the situation from your POV – explain in a friendly (i.e. canned response) way what information  you need in order to help them, and what you will do with that information. The more transparent the support process is for them, the more helpful the user will be.

I remember being such a user myself until some of more experience colleagues showed me this: How To Ask Questions The Smart Way. I think this is the text every user (and support engineer) should read!

Support Team Tip #4: In North America, school teachers often say things like “There is no such thing as a stupid question.” Before ridiculing the latest experiment in idiocy, ask yourself: have you ever been confused by something so simple that once you found out the correct answer, you felt like shooting yourself? No one is an expert in everything, so be patient, first try for yourself the steps you are recommending, and explain what tools and info you need in order to provide them with the best support you can and what the support process looks like. The results might surprise you!

***

The Support Case as a Mirror

In the end, being on the support team keeps us close to our customers and lets us get into their heads (which sometimes we don’t want to do). It’s crucial that we interact this way; after all, what might start out as a question that we think is silly may, over time, become the most frequent support case that we have – then who looks silly? The people asking the “silly” question, or the fact that we are enabling this silly problem to continue unchecked?

Ultimately, a support case acts like a mirror, reflecting the ease of set-up for your product, the quality & availability of your documentation/resources and, perhaps most importantly, let’s you really see the type of customers depending on your team for happiness.

For ZeroTurnaround, it’s like when the student becomes the teacher…but we never hear that the teacher can also go back to being the student from time to time.

  • Nikita

    эхх, рай а не работа :)

  • приходи работать :) 

  • приходи работать :)