Customer Disservice

Datamation content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More .

I’ve had a rather frustrating time with my ISP.

The company paid to host my website provides services that includes email and a Majordomo email list server. As part of my publishing and research efforts, a newsletter is sent out twice a week on events and resources in the worlds of security, regulatory compliance, risk management, and so on.

The list started small and was something I could readily manage in Outlook using Distribution Lists. For some time I’ve known I needed to move to a list server to automate various functions and reduce the chances of error.

It seemed simple enough to put the Majordomo email list server into use and instead of having it up and running in a matter of hours with some testing, I instead have a case study in how not to provide support.

A little more than two weeks ago I used my ISP’s web interface to create my email list and then wanted to restrict access to certain commands for the sake of security and privacy. Additionally, I also wanted to limit the posting of emails to the list just to myself.

Not hard, right? Wrong! After using an overly simplified web-based wizard repeatedly to no avail, I called the ISP’s customer support group and they created an incident ticket. The support person could clearly see there was an issue with the wizard they used in relation to my site and he then escalated the call to level two support and assured me that I would hear back from them later in the day.

Needless to say, the day came and went. The tech had given me his email address so I emailed him additional diagnostic info plus a few questions about how to set certain parameters as I couldn’t see how to access them via the web interface. I then asked him for a status update several times. In fact, I sent him five emails over two days with not one reply.

I then called their support number and they asked for the ticket number. I made the mistake of not asking for the number on the first day and, to make matters worse, they could not look it up as the ticket had already been passed to level two and the level one people, the ones helping the callers, were locked out of those tickets. Wow – that’s the worst workflow approach I have heard in the last year!

Thus, rather than my harping on how bad their service has been and how, after a week and a half, I still do not have my email list operation and I have not heard anything from them, let’s instead look at what should have been done.

The Right Way

From an ITIL perspective, the Service Desk (SD) function is a vital one. It should serve as the single point of contact with customers and users to collect and distribute information both reactively and proactively, plus it should own the incident tickets to make sure they are properly managed.

In this regard, I should have been able to call the ISP’s SD and given them the information they needed via a script the tech should have followed. He should have opened an Incident record and provided me with a record number – ideally by phone and automatically by email.

If they could have speedily restored service, great. If not, the ticket should have been escalated to level two support, either by the SD person or by the system. If the root cause was unknown, then a Problem Management record should have been spawned in parallel.

The whole while, I should have been able to call the SD and receive status information to the extent that they could tell publicly what was going on. Moreover, if they really wanted to impress me with their abilities, they should have been emailing me about the status, which could have been largely handled by the system automatically.

Next, note the protracted amount of time. They claimed to have automatically escalated my ticket, but I had no way to ensure this actually happened. If they did indeed escalate after 24 hours, which is what they claimed when I called several days later, then their system should have alerted me.

At the same time, their system could have been triggering alerts to management that there was a escalation requirement and automatically selected the correct workflow path based on skills or authority requirements. All the while, the people at the SD should have been able to see progress and be able to respond to my questions versus “It’s in level two – we don’t know what’s going on.”

So, here I am almost two weeks later with not one communication from my ISP’s support group. I’m definitely irritated and so would anybody else who had a concern and never heard back from IT. We need to ensure our SD processes and systems adequately facilitate communication and that our people are appropriately trained.

Any service will have problems – that is a given. What can really impress people is how well the service is recovered and how they are treated during the recovery process. Let me assure you, my ISP has made a lasting negative impression on me.