I thought I’d post up some tips on getting the most out of any support calls you put in. There are probably more then this so if I have missed anything that you find quirkly about support please respond and I will follow up.
Read the IBM Support handbook.
Pretty much everything is covered in the IBM support handbook to handle any situation you come across. When I started writing this I just found I was reproducing a lot of what is already mentioned there.
Define a clear business impact.
Give a very clear indicator of what your business impact is. This helps to prioritize your issue. Avoid phrases that don’t really mean anything.
Bad Business impacts
“User can’t use mail”
Good business impacts
“Production server with 1,000 users is crashing two times a day causing 20 minute downtime”. (Sev1/Sev2)
“My test server is crashing every 10 minutes. Doesn’t happen on anything else.” (Sev 3)
“User who deals with payroll approvals is unable to log onto the server” (Sev1)
With these we have a clear understanding of how important the issue is. You should also define any deadlines or if it is a migration/deployment/etc.
Severity works both ways.
The response times of a severity call normally relates to the person opening the call as well. For example if the call is marked as severity one but your refusing to respond to the issue until 5 days later then this is not a severity one.
Define your follow up with support if you need it.
According to the support handbook you will see default times based on severity. However in such instances you can agree follow up times with the support engineer. This helps them schedule for you. If your not getting a follow up when agreed you can send a mail or update the PMR. It gets attention by more then one engineer then.
Be aware of the follow up times with regards to severity as well. For example if you set your PMR to severity three but are requesting daily updates then your PMRs severity should increase.
Send your emails to firstname.lastname@example.org only.
Do not send emails directly to engineers. Doing this means your PMR is never flagged for attention. So if that engineer is out or away no one else will be able to action your PMR until it returns at the agreed follow up time.
It is better to complain when it happens then when it is over.
Part of my role is going through PMRs and see how they are being progressed as well as following up where customers may not be fully happy. If you don’t feel you are getting the full service you should expect from IBM then it is better to voice that concern at that point and not to leave it until the PMR is closed.
While your concerns in a survey later help to improve the service, if you voice it at the point it happens we are better equipped to remedy and help you to have your concerns dealt with.
Remember. You always have the right to talk to a manager!
How clear you explain the issue, the faster it gets to progress.
Normally the engineer should follow up with you first to get a clear understanding of the issue however any work you do before that helps should cut down on duplication of work by the engineer.
“Mail wont work”
“2am every morning the server crashes. We checked the server tasks and program documents but nothing of note happening. In the logs we noticed that cluster failed over just prior. We checked the following tech notes ….,”
“We are using a customized mail template but inbox code has not been changed. When we click new memo we get an error ….., and the mail does not send. We checked with standard template and the issue does not occur. Checked the following tech notes …. Here is the code change made in the memo …. “
One PMR for one issue only.
The PMR should only describe one issue only. If during the course of a PMR you get a new issue (after or during) then you should open a new PMR.
There is good reasons for this.
- Separate PMR means more time allocated to the issue or another engineer helping on resolving the issue for you.
- Stops polluting the issue with the older one. This is good if the PMR needs to be escalated. The next engineer/developer has to read the whole PMR so the less noise the better.
- Different teams handle different issues.So the current PMR may not have the full view of that particular team.
Make the engineer aware of other issues related to the server.
Normally the engineer will check but it is good to list what other PMR/issues you have going on in relation to the server. This stops engineers from accidently duplicating work, or suggesting debug which may have an adverse effect on your other PMRs.
Close the call when PMR is over.
Most administration work is chasing up for an update from the customer. Delaying closures tend to fall into:
- Customer got the answer and at this point doesn’t care about the PMR.
- Customer got an answer but is requesting to leave the PMR open until such time situation X occurs.
- Customer has gone on holiday and left no backup name.
PSP customers have their own personal IBM’er who keeps a track of these, but for PPA we do the chasing.
So if the issue is resolved then you should suggest to the engineer to close the call so they don’t keep mailing/ringing you. Likewise with supplied hotfixes. You should just close the call and reopen if you need further assistance on the issue.
If it is the case of say you got a once off crash, or crash happens once every 3-4 months then close the call and reopen the call when it occurs again.
One of the most common is when someone logs a bug they will often ask for the PMR to be left open until development fixes it. We normally close the calls in this instance regardless. But the point is that once the bug is logged it is in developments hands and support are not in a position to tell you when it will be fixed. When it is fixed you can see this externally.
The point to remember here is that closing the call does not mean that we have forgotten you! Your free to reopen the call within 28 days, after that you can create a new PMR and just cite the old one if you still have an issue.
There are a few common types of PMRs that tend to be pain points for customers. I will discuss ones I know of in further blog entries and clear up. But if you have any feel free to post here and I will respond.