How to Get Better Tech Support

This article is really written about CAD and engineering software in general, but could be applied to a number of different tools where you need to get technical support.

A lot of us tend to think that if things ever get to the point where you are actually considering picking up the phone and calling tech support, all is lost. I admit to being part of this group. Being self-sufficient is a good thing, but to truly be self-sufficient, you’ve really got to know a lot of things, and it’s not easy to obtain the amount of experience required to do that. The problem is not just about the technology you’re trying to support, but also psychological, software and hardware, local and network. In any human-software-hardware system, there are a lot of things that can possibly go wrong, many of them not really the responsibility of the people making or selling the tool. If you add the fact that you’ve got several companies with competing profit-based interests in there, getting timely, professional and authoritative support on any tool can be a challenge.

I’ve worked in many sections of the engineering software cycle – research, end user, purchaser, support, trainer, administrator, sales, pre-sales, post-sales, implementation, consultation, marketing, community… I’ve got a reasonable idea what it takes to get good support – from both the customer and the vendor points of view. This article of course focuses on the customer point of view.

Tech support secrets

I used to really love to do tech support. It’s fun to solve problems (when you have the answers). But when you run tech support as part of a business, it’s not always what you think it should be.

When a raw recruit is hired, they are put on tech support. It’s a great way to train someone who knows nothing and have the customers pay for it. Once the recruit learns the ropes, they get promoted to training, or maybe to contract design work. And then to sales demos. The most senior tech people are probably doing implementation, customer visits, advanced problem solving, consulting, and so on – basically stuff that requires extensive customer skills and technical knowledge.

You really learn a lot of stuff working in tech support, but the way most resellers do it, you learn sometimes from the people you are supposed to be supporting. I have no mercy on TS noobs because I don’t think this kind of training makes any sense. Your organization gets a reputation when you have the clueless on the tech support hotline. I think learners should observe for a couple of weeks, and learn the most common questions. Start answering phones and doling out support, and eventually start answering some themselves. Management is often not sophisticated enough to know much about mentoring. It’s just this archaic “learn or die” approach.

Part of the problem here is that work places are often political, and employers don’t always recognize skills where they exist. They want to magically inherit an employee, not build one. I’ve seen really top notch talent get ignored or misapplied. This is a management failure that you see frequently at technology resellers. Or you might find a technical genius who lacks people skills have his extreme technical talent go completely unused for years. Sometimes you can ask for specific people to get help from, so you should keep your talent scout intuition handy, and ask other people at your organization who they get the best results from.

Another problem with tech support is that it is high turn over and high burnout. If you do tech support every day for a month, you’ll (or at least I) start to get weary. It’s a hard job. You never know what to expect, and you’re constantly learning, researching, trying, looking stuff up, reading, etc. It’s great for customers to have consistency in this area. One place I worked had people do shifts in tech support. I think that worked out well for the most part (for the employees), but it meant customers got a mixed bag when they called in. But using this method, the employee never really got burned out, and kept learning. Some people aren’t good with customers face to face, but were ok on the phone, and those people tended to get more support shifts. The rest went to training and demos.

Do your pre-sales homework

Sometimes you as the customer are just handed a situation, in which case you’ve got to start further on in the process, but sometimes you get the opportunity to start fresh with a new engineering software tool. If you are involved in buying a tool, make sure to do a number of things before you sign the PO and take delivery:

• Call reseller references. Not just the references the reseller gives you, but anyone you can find. You can find other (possibly more objective) references  by attending user group meetings, or talking to people online. Ask several questions about the quality of the support, the level of the issues (advanced or simple), and if there have been any additional charges. Also try to get a sense for the training level of the people requesting the support. Some companies will cheap-out on training, and try to make that up on support. Some companies go the other way around, paying for training, and trying to get answers to support type questions in the training forum.
• Do a trial period.  A log of resellers will resist a free trial period. I worked for someone who would become belligerent, or even insulting when asked for one. Try to come up with a deal where it works to both companies advantages  – such as a contingent order, or a certain percentage down, or the promise to get training before the trial, or have a technician spend a day with you to get it set up properly. You can also threaten them to go somewhere else, although this can backfire on you, especially if the vendor has established territories, and there are few resellers in your area.
  If you are able to get a trial period, make sure that one of the things you try out is the tech support. They are bound to be on their best behavior, but at least you’ll know what the upper limit of what you can expect will be.
  Make sure that you use not just the telephone support, but any online tools that may also be available, like chat, software sharing applications/remote access, and dropbox type support file access. If you find yourself waving your hands at the phone describing the screen or emailing large assemblies in 2018, it’s time to upgrade your vendor.
• Send a subordinate to get help. If the support people know you, and know what you know, they will be more predictable. But if you send someone they are not familiar with, they may be tempted to talk down to this person. Any reseller support person who does not treat you with respect should be someone you don’t want to deal with. During support, you can waste a lot of time clearing inter-personal hurdles, and sometimes a fresh face in support becomes cocky with a little information under their belt. So try to get to know as many people in the organization as you can. Tech support is a high burnout, high turnover type of position. You’ll likely get trial support from a senior person, but after your purchase, that will change very quickly.

Get training and maybe implementation consulting

Training is expensive, but making mistakes because you don’t know what you are doing is even more expensive. When you are getting started with the software, you have to make certain decisions that will be with you for a long time. You don’t want these to be uninformed decisions. Things like Toolbox. Should you use it? If you just go to training, you will think “of course we should use Toolbox, it’s just part of the software”. Well, yes, and no. The training is well written. That means a lot of things. One of the things it means is that everything works. Everything is set up so that it will work in the situations that you are put into in the training. Unfortunately, training and implementation consulting are two different things. In training you use everything, regardless how realistic it is. In your particular situation, things are likely not just like the training scenario, so there may be things you want to do or not do.

I knew a lot of customers who took training, and then by reflex, installed and started to use Toolbox without any idea how it really worked. Then on tech support, they found out about situations where they could lose a lot of assembly data by using Toolbox with the installation defaults. Suddenly, they had to shift course, with a lot of live Toolbox configurations that were not set up the same throughout the organization. Or with a network which could not support what they were trying to do with shared libraries.

Try to answer your own question

This can be a double edged sword. Sometimes its good to figure out your own problems. Search the help. Search the web. Do some experiments and try to break the software so you learn its limits. Sometimes it’s the blind leading the blind. In the year 2018, there is no reason for a company not to have a resident expert on most software packages that have been around for a long time now. You really need a local champion. And the champion really needs to have an apprentice. Mentoring is an important part of being an expert (read my CAD Administrator To Do List blog post).

Make use of available resources

SolidWorks has a very active forum. However, the quality of the answers you can get there varies quite a bit. You’d have to know the right answer yourself to select from the range of answers you get on any given question. You get the entire range from literally unintelligible to perfectly spot on, but how do you know the difference? Unfortunately, this is kind of like going to the web doctor. You’ll find that your symptoms could indicate anything from a hangnail to death by gravity. I encourage you to use the forums, and develop your intuition about the “best” answers. Plus, some answers might be right in some situations and wrong in other situations. In the end, the answer that gets you to the correct situation the fastest and sets you up for success the next time you have to use the model in question is the best. It’s not just about getting it correct right now. It’s about reusing the data to make it easier next time as well. If there is no “next time”, maybe you can throw the best practice rule book out the window.

Formulate your question carefully

If you go on the SolidWorks forum, you see a lot of questions. 8 times out of 10, the first 4-5 responses are to clarify the question because the person asking the question assumes everybody is already familiar with the problem and how they work (which is almost always wrong).

Is your problem data specific or system-wide? This can be a tough question on its own. You need to be able to show what causes the problem. Yes, to an extent, this is what tech support people should be doing, but if you don’t do this, it will never get done.

Try to state whatever special conditions you might have. Spaceball? Running on a Mac? Files on the network? In process of saving virtual parts? Backing up a drive while accessing its files? Just hit Undo 20 times?

Try to use standard terminology. I know I’m sometimes guilty of inventing terminology, but only when SolidWorks or Windows does something stupid. Like “shortcut”. What does that mean? Be more specific, like “hotkey”, or “desktop shortcut” or “S toolbar”. Or are you using a Layout? Is that a “layout” or a “Layout”. SW sometimes makes dumb naming conventions, like using generic words to name specific functions. This just causes confusion. Be aware of language barriers, if that is part of what you have to deal with. Asking a good question gets you most of the way to getting a good answer. Be as complete as you can be. Try to give information you think is relevant the the current situation first, and then give additional info that has general relevance. It may take you some time to prioritize this information.

Single point of contact

Some companies are able to establish a single point of contact. If you are the CAD Admin, you are elected. Your company’s employees should bring their problems to you, and then if you can’t solve them, you should take them to the support organization. This way you avoid duplicate questions, and you will be able to answer some questions right on the spot. While slightly bureaucratic, it is also more efficient. The more you can keep your technical questions from leaving the company, the better, for a lot of reasons including speed, internal learning, and security.

You can win the goal tender game

Sometimes tech support people play the “goal tender” game with you. Not all support providers do this, but some will. They will do whatever they can to deflect and block your question from becoming an official inquiry. They don’t want to assign a bug number, or a case number. They might give you an offhand generic suggestion, and consider the matter closed. They might call it operator error, or blame it on your video card driver, or a network conflict, or sunspots. Tech support people have several levels of BS that they might channel you through.

One of my favorites here is the “enhancement request” response. They say that your issue is “working as designed” even though that’s a ridiculous answer. Try this. Report the “Undercut Analysis tool” as a bug. The whole feature. It’s easy to demonstrate that it’s wrong 98% of the time. Support will tell you “it’s working as designed – fill out an enhancement request.” This is the most bureaucratic, idiotic… you get that this frustrates me. Sometimes it is labeled as a training issue, or beyond the scope of tech support – a consulting issue.

The last thing they want is to admit there is a bug, and they think their job is primarily to prevent you from scoring. Just call back and get a different person, and make sure you have your situation documented and have tried to account for other common problems.

Sometimes support techs will automatically shunt a particular person into goaltender mode because that individual has a reputation for imagining or mislabeling problems. Make sure you don’t get on this list. Make sure your problems are documented and you have all of the information they are going to ask for up front.

The result of the goal tender game is generally that people just stop reporting problems, because it’s just too much hassle, and you rarely see a real result. Everybody loses with this result except for the resulting PR campaign that claims “XX% drop in tech support!” Since I started using the software again about a year ago, I’ve made one call to tech support, and it was unpleasant enough that I haven’t called back. I’ll post my problems to the forum, because I think public dirty laundry is the one thing that really makes things move at software providers. I will own up to a little personal frustration in this regard.