Someone recently asked me how I should handle a vendor that wasn't being responsive: "Twice now I've sent the support team requests and received an automated response and little else. The first ticket took a month for them to answer. The second was closed with a note that they had tried to call me, but I didn't answer. Mind you, they never emailed me to say they had called."
I've found that when opening a "case" or "ticket" with a vendor you have to "stay on them" or, more accurately, "manage it ruthlessly until the issue is resolved". Very few vendors are good at follow-through on tickets. Here's what I do:
I call them every day, first thing in the morning, and always refer to the same ticket; and I keep good notes.
Let's break that down:
a. I call them...
I don't rely on them to call me back. If they tell me they'll call me, I say that's fine but I let them know that if I don't hear from them by (for example) 10am, I'll call them.
b. ...every day.
I call and ask for an update every day. If they say something with take N says, then I don't call back for N days, but otherwise I call them daily. If is apparent that they are frustrated by my frequency, I either lie and claim that I have a mean boss that demands daily updates and graciously apologize ("I hope you understand") or I ask them when I should call next for a status update. I don't accept "we'll call you with a status". I just don't.
c. ...first thing in the morning.
By calling them early in the day you are setting them up to spend the day working on your issue. If you call them at the end of the day, they'll decide to do your request "tomorrow morning" and now you are gambling that no other squeaky wheel will get their attention when they come into the office. Plus, you are giving them 12+ hours to forget your request. This is a Jedi mind trick to manage their time without them knowing.
d. ...always refer to the same ticket.
Don't let them create a new ticket number if it is the same problem. If a problem re-occurs months later, request that they re-open that ticket. There are two main reasons for this: it takes away their excuse that "you just brought this to our attention" (this is important if the issue gets escalated) and as new people get involved it helps them to be able to read the complete history of the issue.
e. and I take notes.
Every time an escalation goes wrong I wish I had taken notes ("evidence") from the start so now I always take notes. I ask the person their name (in a friendly "I'm just introducing myself" way), the date, and any commitments they make.
Two other tips:
f. Define the problem for them, and define it at a high level.
Defining the problem properly is actually quite difficult:
Once I opened a ticket that "I can't ping server xyz" and ended up talking to a zillion very confused people. It turns out I was supposed to start accessing a different server and was never informed. To make matters worse, the server I had been using was decommissioned. By escalating the issue the company nearly took the old machine out of the trash. I should have reported the problem as "I'm unable to do lookups in your LDAP server". By stating it at a higher level of abstraction (what I'm trying to achieve, not what I think the problem is) it lets them do their job better. In my case, what I wasn't trying to achieve was ping a machine... it was doing an LDAP lookup. If I had reported it this way from the start, they would have addressed this as an LDAP issue, not a networking issue, and it would have been resolved quicker. As a sysadmin you are most likely more technical than someone working customer support, therefore we tend to do our own diagnosis. It is actually better to give the high level complaint, let them digest a little, then feed them the diagnostic data you've accumulated so far.
Another time I asked the wrong question was dealing with a salesperson. The question I asked was along the lines of "is there anything else I need to do?". A week later the equipment I had ordered wasn't received. I called and he again told me there was nothing else I needed to do. A week later (this is before I learned that daily calls work better) I called to complain that I hadn't received the equipment and now my deadline is in jeopardy. He said "Of course you haven't gotten it yet! I can't even place the order into my system until your company establishes a credit line with us." You can imagine how angry I was. He, on the other hand, was confused why I would be so upset. He hadn't lied to me... there was nothing Tom Limoncelli needed to do: credit line was a something the CFO does. At this point my CFO hadn't been contacted. (Don't these people work on commission?) Well, that's the day I learned that the right question to ask is, "What day should I expect the box to arrive". That's the "higher level of abstraction" that covers all the bases. If I get a date, fine. If I don't get a date, it starts a conversation about why they can't give a date yet. If I know the roadblocks, I can work them until they are removed. I can take responsibility for making sure they get resolved. Credit line not established? Ok, I can talk with the CFO. If all roadblocks are cleared and they still can't give me a date, then I ask for a date they'll be able to give me a date. Now I know when to call back and ask the right question.
Luckily my current position doesn't involve dealing with external providers. However my previous job was at a very small company therefore we were too small to do many things ourself. We had to rely on external companies for a variety of things: Internet connection, web hosting, hardware depot repairs, and so on. Hopefully you can benefit from these lessons that I've learned.
