Support contracts – also known as the get out of jail free card. Allow me to illustrate the situation. You have run into a production outage. You have tried all the normal fixes and every googled the crap out of the problem without any resolution. Now you are left with admitting you have no idea how to resolve the problem or calling the support team. You have avoided calling support because you are convinced that you will be able to solve the problem in a few minutes. You know that calling support means you will have to spend the next hour on the phone trying to explain the problem to someone who will ask you if it’s plugged in. It’s painful… but sometimes it’s the only way to get resolution. I have been known to be brutal to vendors. I learned from the best. It seems that these days the vendor needs to be scared of loosing your business before they will pull in the right resources. Right? — Wrong!
Help support help you
I recently started working with VMware BCS (Business Critical Support) support. For those not familiar it’s an elevated support contract that allows you to get access to a support engineer. In addition you have access to BCS engineers for first line support. The quality of the engineers in BCS is a lot higher. My time to resolution has really been reduced. They really read the longs and can be required to provide detailed root cause analysis on problems. In short I have been really impressed. So does my story end with a plug for BCS or buy more VMware? Nope. What really impressed me was an email from my BCS assigned engineer Frederic Giroux. Here is his email posted with his permission (trimmed some sections that may not apply to non-BCS customers):
As most of you do not know, in a previous life, I was a paramedic (for 16 years). Very early in training, we are taught how to gather a story from patients, family members or simple bystanders. The accuracy of the story might very well change the outcome. Will the patient have permanent damages or not or even if he will survive the traumatic events he is facing are often based on the story provided to the medical staff.
In IT, the story of a support case is certainly not as critical. Nobody will die (or should not anyway except in rare cases), but disturbances can be quite important and how the story is gathered will also affect the outcome in the sense that it will take more or less time to resolution. A good story, clearly identifying the symptoms and putting them in perspective will allow the IT staff (you, your colleagues, VMware Support and other vendors) to better isolate the solution and work faster.
You may have already faced a situation, or seen one, where the medical staff asks questions to a patient, looking like they are not doing anything short of asking questions, and the patient or family members getting very impatient (or even panicking) and starting yelling at the staff. I know I have often faced this situation. Getting the story out is almost as important as the treatment itself. Asking about allergies, medication, time of last meal, description of symptoms, etc. is paramount.
Do not give up… I have a point to make In IT, it is similar. Again, the outcome may not be as critical as in the medical field, but when you are stuck in a bad situation, with the pressure coming from all sides, you may very well feel like it is close to life-threatening I know the feeling…
Now, the point to all of this… When I read the story in SRs, I realize that very few of you have a medical backgrounds The stories are often sketchy, poorly documented and we, TSEs, are trying to guess what the issue really is. So, I wanted to give you some tricks on how to write a good description and help us help you in resolving the case.
Start with a general description of the symptoms. Include the exact error message (if available) and, if possible, a screenshot.
Then, answer the following questions:
- What products and versions are involved? Include build numbers.
- What is affected? What VMs, hosts, clusters or systems? Please provide names.
- How severe are the symptoms? Down, partially down? Mission critical or not?
- Do you know what could have provoked the symptoms (changes recently made)?
- Did it start suddenly or gradually? Details.
- Provide dates and times. When did it start? When did you try the failed operation? Looking at logs, it helps tremendously to know where (or when) to look.
- What steps have you taken to correct the issue? Did it work (partially or in full)?
- Do you have a workaround? If so, what is it and is it sustainable and, if so, for how long?
These three are not always necessary:
- Provide the host server brand and model. Please include firmware versions.
- For storage issues, provide the storage array brand and model. Please include firmware versions.
- If applicable, do not hesitate to include the topology of the environment as an attached document.
If you do not know an answer, say it. That way, we will know you do not know and it will be clear.
Finally, add further description as you see fit. Do not hesitate to tell us about KB articles you already checked and the outcome.
Trick #1: Take the above questions and paste them into the case log with your answers. Do this for every case, even the ones looking more obvious as they may not be obvious to the TSE working the case.
Trick #2: When you create the case, you may open with it with the brief description and, after that is done, you can send a full email with all the details. It is easier to write in full screen and you can easily add screenshots into the email.
Trick #3: Do this for every SR you open, even non urgent ones. Practice makes perfect
Some guidelines should be respected to avoid delays and confusion.
- Make sure your text is clear, concise and to the point. Review it carefully and, if possible, have someone review it as well. This is time well spent as it may save hours, even days, because it is better understood by support (remember my example above on medical staff gathering a story while the patient is panicking).
- Avoid political information. Remain technical and factual.
- Upload all the necessary files immediately. Do not wait to be asked. You will be saving time.
— End of Quote
Wow! that’s a lot of information
Points to Fred this is the first time my support infrastructure has provided me education on how to make my experience better. I don’t know how many tickets I have opened with a single one line statement and logs. (Fred knows and it’s not a good number). I love that my support engineer took the time to help refine the process. As I tell my co-workers all the time just let me know the human protocol to get it done and I will follow it. Fred is giving us the support protocol to get it done. Also as you answer these questions you might find that you resolve the issue yourself. As anyone who has done design might tell you it’s the process that makes provides good infrastructure not the idea. I suggest that you consider following his process provided and see if it helps your support situation.
What do you think?
Have you had a good experience with support ? What made it that way?