Just like a bad problem title is it’s evil twin: a poor or missing problem description. I’ve come to believe this is the hardest part for a “named caller” (the individual that opens the ticket) to articulate. Often the description includes details we don’t need while missing the details we do need. Unlike the title, you’re not confined by character limitations – at least I’ve never run into a customer that ran out of space describing the problem. Here’s some of my personal pet-peeves:

  • ABBREVIATIONS! A problem description that contains abbreviations specific or common to your company often escape us. For example, one company routinely abbreviates our product as “MFT” because it used to be called “managed file transfer” (apparently to them it doesn’t matter that it’s been decades since it was called that – or new support engineers won’t know the old product name).  Other abbreviations that make sense to you may stump us. I received contained several references to”MF” that I initially thought was MFT. About a half-an-hour into deciphering the rest of the problem description it dawned on me that MF meant “mainframe”. Abbreviations can also be difficult for support analysts where English isn’t their primary language.
  • No problem description or a description that asks us to call immediately. Most analysts don’t sit around all day without other customers or demands on their time. Likewise, an impromptu fact gathering call rarely results in resolving the issue on the spot. If you can’t take the time to devise a cogent problem description, perhaps you should wait to open the ticket when you can. Consider the thought that your spending time gathering log files and creating a meaningful problem description, allowed us to spend that time working another issue -and- because you provided us with the necessary information to perform cursory analysis our first call may result in resolving your issue. It’s only fair that we focus first on a customer that already spent time doing this.
  • Misinformation or leaving out important information. If I had a dime for every customer that told me “nothing changed” I’m certain I could’ve retired long before now. Likewise, I’ve probably kicked myself each time I’m a week into an issue before you confess something has been customized.

A decent problem description should clearly state:

  • The issue you’re facing – what is it you want us to solve for you.
  • When it start happening.
  • What potentially CHANGED since it last worked (operating system patches, a database outage, network modifications, new SSH or system certificate etc.)
  • Whether it’s working for some customers but not others
  • Is it failing in certain cases but not other (for example – traffic going in but not out)
  • What error message you’re getting (and often if you “google” the error message you may be able to solve this for yourself)
  • A brief explanation of your environment – does it contain other products of which we should be aware? For example is there a secure proxy, load balancers, firewalls, etc. – anything that could potentially be important pieces to the puzzle.

Remember the better picture you paint for us the quicker we’ll be able to zero in on the root cause.

Advertisements