Simon O'Doherty

 It probably got missed with Lotusphere going on, but there is now a new feature in EMEA support called Tech Chat . when you open a PMR you can sametime chat to the engineer assigned. It also allows you to log into the community and have an engineer ping you if they need you.

Wondering if anyone has used it yet, or plans to?

What separates a call center from a support center is that the former is more focused on just resolving the technical issue. With the support center you need to be more focused on "fixing the customer". Although I hate that term as it kind of implies the customer is broken when this isn't true at all.

The best way to explain it is from start to finish of a support call you are offering a service to your customer. You could solve the customers issue to exactly how they want it but they can still walk away dissatisfied. Giving peace of mind, keeping customer updated and understanding the customers history are all factors. This service can have a huge impact on future business (especially in a recession).

With that I do read up on this stuff along with the technical aspects of my role. I'm a big fan of Gitomer but a book I am currently reading* is "What'S The Secret?: To Providing a World-Class Customer Experience" by John R. DiJulius. What Gitomer calls "Wow factor" DiJulius calls "The secret service".

When reading it, I know a lot of people will take it to be obvious. But it tends to be obvious after the fact. :) Trying to remember to offer the WOW takes continual practice. Not to have this one sided. I would like to know if anyone else can recommend similar material if this is something your interested in.

* Another thing I've found recently is the joy of Safari Books online. :) Works out cheaper then what I normally pay for books in a year. Plus it was a WOW moment from their service people that pushed me over the edge to get the account.

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
"High"
"1"
"red"
"Important"
"Server crashing"
"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 lotus_support@ecurep.ibm.com 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.

Bad example
"Server crash"
"Mail wont work"

Good example
"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.

Pain points...
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.

 

My son is just over 4 years old. I got him a iTouch (mainly because I couldn't get my hands on the Nokia M810. another story). All I had to show him was how to switch on/off get into items. I'm amazed at how quickly he picked it up. So I have a couple of his DVD's on it, some pictures (mainly word association pictures) and some kids games.

So what does support have to do with this? Well I thought I might as well try writing some apps for the device. As there are a few games and things in real life that could port over and he would enjoy.

So I find that you have to own a Mac to actually do this. :( I did a google around but nothing that easy to follow. So I figured maybe I can just buy leopard and install in a VMWare. Again I can't find anything of note there. So I ring the customer sales support line. It went a little something like this (short version)..

Me: Hi I want to know is it possible to run leopard in VMWare?
Rep: Oh sure! VMWare runs on apple macs fine and you can run all the windows programs.
Me: No I mean I want to run leopard in VMWare.
Rep: Oh you can do that although leopard normally runs on the mac itself and you run windows in the VMWare.
Me: No I mean run it in VMWare in Windows.
Rep: Yes VMWare runs windows fine.
Me: No I mean I want to run the VMWare on windows
Rep: Oh you can't run VMWare on windows, it only works on the Mac.
Me: Ok I want to use a windows to run windows vmware which will run leopard OS.
Rep: Oh no you can't do that.

I half expected this but the overall conversation was funny as it reminded me of the Simpsons where Marge is asking an Australian bartender for coffee.

So now I need to find a Mac to play with. will see if I can souce a cheap one.

I read almost daily planetlotus.org and numerous blogs. I also read LDD forums infrequently. It really is quite interesting and a buzz to not only see people using a product you work on but also the cool tricks they get up to. So much so I am at a loss to what to blog about. Anything of a technical nature is internal or goes into a technote/wiki.

So thought I'd write about what I know and that is level 2 support. so I will do a few posts on common issues to help make your support experience better. If anyone has any questions in general to get the ball rolling feel free to let me know (note: I can't talk about customer issues or internal processes).