So I have left my current post on Composer half written because I am frustrated and angry. Probably not the best time to write a post, but I want to share while I am motivated. The problem, tech support.

I only get involved in support cases these days if:

• It is a complex issue that requires someone with deep knowledge to resolve. These that only applies to Documentum issues these days as there are better technical resources for everything else. I enjoy these cases because I learn something and they are a nice challenge.
• An issue is languishing and no resolution is being reached. I hate these issues because it means that their has been a communication breakdown somewhere along the line and fixing it is never fun.

Before I dive in, I just want to say that I have dealt with many vendor support organizations over my career.  Except when I was in pure evaluation mode of a product, my experiences have been consistently poor on average.  Some good, some bad, but no large vendor has ever been consistently good.

The Problem

Here’s the deal.  At a client, there was an issue in production. Keep in mind that my company has multiple teams using SharePoint, Documentum, and other products, so no finger pointing. A way to work around it existed, but it was time-consuming, and becoming more so every week. The team finally got enough time to reproduce it accurately, and consistently, in the test environment and opened a case with the vendor.

Two weeks passed with the only advice being to apply a patch that had already been deployed. Seeing frustration mount in the project manager and the client, I stepped in to try and resolve it. We finally get a long conversation with support to comb through logs and identify three concerns. The team is tasked with gathering more information on one concern and support agrees to work on the other two with engineering.

A week passed, during which the team identified the root cause of the 3rd issue and heard nothing on the vendor action items.

We contacted support, posting within the case a question on why we haven’t heard anything for a week.  Needless to say, by the end of the day, we are on the phone with support and an engineer to talk about the two follow-up issues.  This was fine because the vendor wanted to be sure that the details were clearly communicated. It is agreed that the actual commands to remedy the situation will be quickly entered into the case so that we have it documented and can try it in test.

After all, we have to wait to do this in Production after we validate that the solution works and get the necessary client buy-in. So having it written down seems reasonable.

No instructions arrive for almost 24 hours. We have to ping support multiple times before we get a response. Then, and this is the point I nearly lost it, the commands that were sent had INVALID SYNTAX! I was able to rectify that, but then they didn’t do what they were supposed to do. Not because support guessed wrong, but because the system doesn’t allow the desired modification in that fashion.

I’m now trying to wonder why my client is even paying for support.

Guide for the Support Center

I’ve overseen small support operations and done some 3rd-tier support. I’ve managed products and have some understanding of the challenges. The front-line support is usually fresh college types, and I understand that. I understand that the support person doesn’t know that I understand their product and they have to ask the standard, simple questions when a case is entered. That is life.

Here are a few tips for what a support center should do…

• DON’T say that something is documented and then fail to find it in the documentation. If it is in the documentation, point it out to me and I’ll be happy and maybe a little chagrined at not finding it myself. I know support doesn’t write documentation so I don’t blame them for something missing. They should be familiar with it and need to check before using it as a crutch.
• DON’T send instructions that aren’t in a vetted Support Note, internal or public, without trying it out first. Sometimes I have the time and environment to tinker. Sometimes, the problem is in a controlled environment where I am lucky if I can even touch the operating system. Typos are okay. Most support personnel are human. Commands that don’t do anything, or are incomplete, create more work for both support, my team, and my client.
• BE RESPONSIVE! If something happens and support cannot respond in the timeframe that was agreed upon, send a message stating as much and provide a new timeframe.  Don’t make me wait for days and only respond when I enter something in the case system that may impact your performance metrics.

If I break down and call support, then I know it is usually a difficult and complex issue. That means I don’t expect an overnight fix. I do expect to understand what is being done to resolve the case and when support is offered, I’m not doing the Quality Assurance for the advice given. I shouldn’t have to become overly assertive in order to get any progress on a case, especially one impacting a live production system.

I don’t expect miracles…

I don’t expect perfection…

I do expect a little attention to detail and a fair understanding of the product, or service, that is being supported.