I’ve recently been communicating with an anti-virus vendor the company I work with has been using for a while. While I like their product a lot, and they have made major improvements over even the time we have been using them, they have also been a major problem in several regards. Without going into much detail (I don’t want to say who it is), they have illuminated a number of principals that are good general business practice.

I understand that agility is important in the security field. I also understand that no software update is without bugs; heck, my software is sometimes more bugs than features. There are still a number of fundamental policies that will help you and your potential customer have a less tenuous relationship. Here are some ideas:

If you say a feature will be coming soon, have an outer limit on that. In my example, there was a feature that is critical to us which was stated to be in the next version. At the time the next version came out, it was not there, and we received a similar story. We are about 4 major and 3 minor versions down the road at this point, and it still isn’t there. We were fine with waiting under the knowledge that it was coming “soon”. Had we known this was not the case, that may have changed the product we purchased. Obviously that isn’t a great prospect from a sales point, so maybe they thought fudging the time was ok. Now you have a customer that can’t trust you. Not a great trade off.

Make sure your support staff reads the question, and responds to the whole question. From example again, I made a support ticket to get a product feature enabled which was listed as the proper method to handle a problem on a machine. Instead, I get asked what machine so that they can work on just that machine. When called out, they said it was because they could not enable the feature. This will lead to another point, but it’s also not the only time this happens. If you are going to request more information from the customer, please make sure it’s not already in the ticket.

Check your documentation! As in the above example, their support KB said explicitly that a feature being enabled was the proper solution. Why then, is that solution not available? In another example, and I will call this company out (Dell), I bought a server a few years back (A T110 II). When investigating, their documents said it supported non-ECC RAM. This was not a critical system, so I wanted to save the money on not getting ECC RAM. I contacted my rep, which confirmed this was true. I looked at the manual online, which said this was true. It wasn’t. When the server arrived, I ordered some RAM for it. It took me a bit, so this was a few weeks later. This was also a few months after that model was released. When I couldn’t get it to work, they pointed out it required ECC. Even at that time, the resources still said it did not.

When you change a policy, for the love of all that is holy, make sure your support team knows. I have a number of occurances of support techs directing me to do things their company no longer supports. My latest example is ATT telling me they will ship me a macrocell. I had 5 different agents offer this. Five. They don’t even make them anymore, and haven’t for months. I know that support agents often work from a knowledge base just like your customer may try to, so again, check your documents.

This is just a vent, but having played both sides (I did retail for a while, and customer facing support for years), these are big issues, that aren’t even that tough to fix. Really it comes down to two things: know what you are talking about, and don’t lie when you don’t.