Ok, so this is was going to be a quick post...
I go to see customers as often as I possibly can, and one thing I get asked a lot is: how can I get my ticket addressed quickly? We've all felt the frustration of opening a ticket (with any vendor) and feeling like we get asked either the same questions over and over, or that we get asked for basic information that should be obvious. I have a couple of things I use to solve these problems. [tl;dr: a well-documented ticket get solved faster]
When I started at BladeLogic at the dawn of time (ca. late 2004), I was very fortunate to be in the first(?) generation of Professional Services people hired after @jboland. While there was organized training in early 2005, most of us were trained by Support, usually when we opened a poorly qualified ticket. Usually John O'Toole, Newton Nyante or one of his peers would take a minute and explain to me why "Job doesn't work" wasn't the best subject line for a ticket. One of the things I learned early was that if you wanted your ticket addressed quickly, you had to put what you wanted up front, what you'd already tried, and include the most relevant logs or errors.
So I made up a cheat sheet slide for "How to Succeed at BladeLogic Without Really Trying". (see footnote 2)
It basically boils down to four parts:
- What was I trying to do?
- What did I expect to happen?
- What happened instead?
- What do I want you to do about it?
There's some not-necessarily-obvious parts to this.
- The better you can explain not just what button you were clicking on, but what problem you were trying to solve, the more likely it is that the person on the other end of the phone/email/ticket will understand what's going on.
- If you're expecting something that doesn't quite work that way, or if there's a better/faster/easier way to accomplish what you're trying, this opens the door for them to help you get to the best way to do it. The more clearly you can communicate how you think it should work, the easier it is for the support person to understand and clarify.
- Sometimes what happened... is what's supposed to happen. "Works as designed" may be the most frustrating ticket response in the world, but it opens the door to "so, how would we do this?".
- Support (and Product Management, Development, and Customer Engineering behind them) can do a number of different things with any given issue, from simply:
- logging it for consideration for a future release or service pack or helping you open an Idea,
- identifying it as fixed in a current shipping release,
- suggesting a workaround, to
- escalating it and helping obtain a hotfix.
In the short term, depending on what kind of fix is needed, a workaround may be the most expedient way to get you working. It's rarely the most satisfying, but is usually the most productive, if there is a way. In the event that a hotfix is needed, the more clearly we can define how we want it to work, or what needs to be changed, the better. Smaller fixes or behavior changes generally require less development time, less QA, and will result in getting a fix that much faster. If the request is too big, it may end up having to go into a future release.
This is also the opportunity to identify the severity and priority of the issue: what's the business impact of feature X not working as expected?
Last thing: if you have a relevant, specific log snippet or screenshot, please include it (and ideally the timestamp and larger log file if practical). There are a bunch of well-identified issues logged with their relevant error message in the KB, and even if what you're seeing doesn't match there, by calling out which log (agent, appserver, gui, job, etc?) you're looking at, it'll help the support person verify the issue.
One unintended side effect of putting in tickets this way: I'd say 60% of the time, as I'm putting together my "4 points", I figure out the problem myself, or find the answer in the KB.
If you can hit all 4 of the "what to include", the likelihood of your ticket closing quickly and in a satisfactory way improve significantly. Without you having to work that much harder.
- How To Ask Questions The Smart Way. : sysadmin
- How To Succeed In Business Without Really Trying (2011 Broadway Revival) - Previ - YouTube