Practices, Resources & Other Suggestions for Cust. Support? 18
drshannon asks: "I have recently been placed in charge of our small Customer Support part of the company (just 2 people right now). I have never done any customer support before, and would like to ask the community about tools, policies, resources or ideas that work well for them. I'm sure there are a ton of resources, and most Google searches turn up specific help desks for companies, not ideas about supporting customers! What is a good CRM for a small business? How do you handle documentation to easily publish documents for User Guides, and for the web? What are common tools for a good customer support desk. We try and pride ourselves on good support, but we do need to improve, and can with your suggestions."
Publish everything you can.... (Score:4, Informative)
Tools and Freedom (Score:3, Informative)
As someone who's worked on a phone help desk for 4 years, I've run into a couple things that I've found that help me when I provide support:
Note the "easy-to-use" part. No repition of data, easy to reopen tickets and the more integration the better (user's name should bring up address/ph#/passwords/etc.).
Let the techs make their own knowledge base on the intranet. We know what we want there, more than the best content authors you can find. A good KB will keep all your techs (no matter how many) on the same page.
Let the techs solve the issues, and not get bogged down by red tape. Give them hard guidelines on what to support, then give them a say statement or the like if they can go outside them to get a user going. That just looks good to a customer, and it'll keep the company and techs out of hot water.
That's just the tip of the iceburg, but I do hope it helps you out. :)
Link to interesting info (Score:2, Funny)
use google to find them.
thank you for ringing customer support.
Problem Management Software (Score:4, Insightful)
Steer away from the market leaders like Peregrine and Remedy (or Heat, Quetzal, Helpdesk etc.) as they are vastly over complicated, over priced, opaque in use and just generally suck the fat one.
Get something simple, or get it developed in house. 9 times out of 10 you don't need the bells and whistles offered by a 'professional' system as these are just bundled in to make a weak product easier to sell. If you develop it yourself then you can at least add the bits you need later on.
Second, some kind of knowledge base. It needn't be a big whizzy database - you can get all the detail you need in a word document or html page.
Third, get headsets for your phones. You might think they are a bit wussy or funny looking at first, but you will soon realise how much more efficient they make you and your staff; you can actually type whilst on the phone. Which brings me onto...
Four: make sure you can all type at least 40 wpm. If you can't do this then you shouldn't be allowed to use a computer, let alone be an IT professional (who in their right mind would employ a developer at $80 per hour who can't type > 20 wpm - but it happens!).
This will make the whole experience a whole lot more enjoyable for both the customer and the operator.
Five: If you can't get technical experts for staff, get intelligent, pleasant people. Do not pay minimum wage and get people who want to move into IT from, say, shelf stacking. Make sure they know they need to be polite, considerate and efficient with all customers (note: this includes 'internal customers')
Running a support desk is hard work, but is also essentially a simple thing to get right - just keep thinking about customer service the whole time and your 3/4 of the way there.
Just my £0.02.
Re:Problem Management Software (Score:2, Informative)
We do have an internal crm solution that was devel'ed in house and it is very sweet, web based and will soon be open sourced.
We have head sets, it is the only way to go, remember to get the type with VERY long cords.
All of the rest of the above is true, however I would ask that you remember one thing. Some customers will complain, it happens, when they get passed to managment make sure you are not going to shout at the staff afterwards, it is most of the time not their fault (if you have done well in selecting the staff it won't be) this will mean that your staff will not be afraid to transfer them through. (not that this happens in my place)
Oh yea, and let them use any system they like as long as they can get their work done, it sounds silly, but I am more efficient with linux than windows because I know it better, same goes with mac users, they are going to do a hell of a lot better with a mac than win.
Out of my personal experience... (Score:3, Informative)
1) Vague statments from customers that donr know how to define the problem. So first of all, design a standard questionare (ASAP-as simple as possible) , cause usually customes are ppl with lots of money that know shit
2) Manage ur knowledge, never let a valuable piece of info pass by without recording into a DB that u know its design, therfore i recommend the suggestion above about ut own SW to control ur KB.
3) Give ur techs their chance to strenghten their knowledge, Support is not like programming, when ur a support tech, u have to know lots of issues regarding various and extreme technologies, cause u might be supporting ur product on several platforms and db engines, its not like u have 1 or 2 programming languages and thats it.
4) Minimize customer interaction, by adding a support page with FAQ's and info on first aid troubleshooting steps on ur website. This will eliminate a big percentage of problems.
5)Last but not least, if the cusotmer has paid his support fees, contract or whatever....then.....
Re:Out of my personal experience... (Score:2)
But then again, don't go assuming your lusers are all id10ts. Just my $.02.
Re:Out of my personal experience... (Score:2, Insightful)
I know tonnes of people in support/service who only figured this out after 6 months or more on the job, and it makes the tech-support job a lot less stressful (which in turn makes finding solutions quicker, and happier customers). Customers are not your enemy, but a customer who has spent the last 10 hours trying to fix something will be stressed-out at least, and may be looking for an excuse to take it out on you. This is especially true when dealing with end-users or individual software licencees. Sysadmins, or those dealing with software on a network are usually a) more computer literate and b) know that there are things that go wrong, that one cannot plan for. These people are likely to be a lot more patient with you, and therefore you should extend them the same courtousy.
Re:Out of my personal experience... (Score:1)
Re:Out of my personal experience... (Score:3, Informative)
A list of ideas; (Score:2)
Strong manager that shields the support people form politics of the office and form the presser of unreasonable customers. This is the only way to keep good support people and have them be effective. If sales or the customers are pushing them around they can't be the experts they need to be.
Support from engendering when there are is a real question about how something really works.
Fixes and improvements, if what support find as bugs or needed improvements makes it into the product quickly support people will work very hard to find and suggest fixes and improvements. If they (support) is ignored then moral will suffer and you will not keep support people.
Never ask a support person to lie!
Clear policies on what is and is not supported. If you have time to exceed the policies on a case by case bases you can.
Simple tracking tools. I have been far happier with lotus notes with just a touch of custom code than I have been with any of the "big" CRM programs. I am not saying lotus is good it just that it not overly structured. In fact in a lot of cases a directory full of text files would work better than some of CRM stuff I have had to work with.
Team work and knowing what is going on with the customers, the products, and the other members of the support team. A big white board tracking open problems is a big help. Support problems often come in groups. (not always for a reason). but in groups. knowing what other members of the team have or are doing can provide guidance or warning or what is to going on.
Charles Puffer
Partner with other groups (Score:2)
Have the support group join forces with the QA, Documentation, and Training groups. You are all "customers" of what development produces. Thus, you have a common perspective and interest. In short: work together and share the knowledge!
This is synergy at its finest:
- The Support group learns of a bug from a customer; pass it on to the QA group. They get real-world information on what is important to be tested. If the code has a defect, but no customer encounters it, is it really a bug? When looking at the whole universe of potential inputs to the code, it is a big win for QA to know how customers actually use the product. They can tailor their tests accordingly.
- The QA group, while testing a new release of the product, discovers a bug in unrelated code that has already been released. They can pass that info on to the support group so they are prepared should a customer report it. Saves wasting hours trying to isolate and reproduce a bug -- already have the details. Being able to locate and isolate bugs quickly makes you look good to the customer.
- The Documentation group often finds errors, too. There's an old saying: "If you really want to understand something, try explaining it to somebody else." In the course of writing the documentation, they are going to find things that others miss. Their prespectives can be helpful to QA (Hey, you might want to add this to your tests) and to Support (This feature is complicated and customers are likely to call with problems in using it.)
- The Training group can cut off problems before they happen. There's usually a number of different ways to perform a task with the product. Users often take a "recipe" approach -- they just do things the way they were shown. Training can guide users into a common approach to using the product. The more consistent the customer's use of the product, the fewer permutations that Support needs to be knowledgeable on.
There's more, but I think I've made it clear that there is much in common between these groups.There will come up a time when you have a customer who has a problem, but development is not willing to give a priority to fixing it (maybe they are already behind schedule on the next release). If you discuss the situation with these other groups it's possible that you can provide a united front that will sway development. Or, you may find a workaround of which you were previously unaware.
Lastly, I worked in the QA department at a company where these groups were viewed as a necessary evil; development was king. But, through the approaches outlined above, we were eventually recognized as an ally and were all invited to participate in the design of the next release of the product.
My recomendations (Score:2)
First of all, good documentation is absolutely essential, but also the hardest thing to get. Getting good documentation to the customers is a good and noble goal, but more importantly your department needs to have complete documentation for every product you deal with. Without it you'll have a very hard time troubleshooting costomer problems. Complete documentation can be obtained in 2 ways: you steal an employee from another department who really knows the product and make him write everything down, or you visit engineering. The former method is easier, but either will likely require the liberal application of a 2-foot length of rubber hose.
Second, you need a database, and it needs to be easily searchable (that includes the notes field). You could put all your documentation in the database, but I've found that simply having it in HTML form with sensable crosslinks and homepage(s) is sufficient in that area. It's your call, really. What I really recommend the database for is tracking problems and resolutions. This will be really helpful down the road, especially if you expect the department to grow. A coworker and I had the idea of setting up a newsgroup for each product, but we haven't been able to actually implement it.
Anyway, hope that helps. Good luck!
Get advice from the experts (Score:1)
Tracking and measurement (Score:2)
I read an interesting story about a tech support department that tracked the number of open tickets. The number was low and everyone was feeling good about themselves, but the users weren't too happy.
It turns out that the really hard problems were being left alone and the easy ones were being solved first. So there were only a few open tickets, but they had been open for a long time.
So the moral of the story is to track the right thing. In this case, the department started tracking the average length of time a ticket was open, resulting in an increase in customer satisfaction.
People, not tools or processes (Score:2)
However, I think most vendors emphasize the tools over the people using them. I'd suggest working on allowing the people working in your team to do the best work they possibly can do - protect them from corporate politics, establish a good relationship with whoever can fix actual problems you have to escalate, get them whatever tools they ask for, and make sure you have a decent working environment.
If you have to grow the team, make sure you hire the very best - ideally give the existing team a say in the process.
At the end of the day, the attitude of the person answering the phone is a lot more important to the customer than which trouble ticket system you use...
My experiences (Score:2)
Get or make a good trouble-report database. We rolled our own in Notes. Make sure there are no nook and crannies where troublesome customers/problems can fall in and stay hidden. You need the ability to select different views - measure response-times, see if any of the employees are lagging behind and why, etc.
Treat your people good. This is a good idea for several reasons but it is also difficult for a number of reasons. You need to (as tech support group leader) stand by your crew when they get attacked, both from customers and from management. Do not let any shit pass you, either way. This is important. You take the blame and if needed, you can dish out your own, later - but you can not ever let any of that pass you by unfiltered. You need to be in the loop to keep on top and you need your troops' confidence in you or they will not do a good job for you. You are their platoon sergeant. Once in a while, take them out for a meal or something (I have treated my US team on a night at a Japanese Steakhouse and presented them with Apollo 11 mission patches to build team spirit, from my own money - not expensed and I let that fact leak out to them discreetly ;-).
Treat bad customers good, too. Some customers will scream and rant at the firstline people because they think this will get them escalated to second. Some customers will do it because they are assholes. This is one of the most difficult problems I have encountered and I have no quick fix except standing by your people and let them escalate these customers directly to you. Talk to the customer about their behaviour but do not get into a shouting match or let your people do it either. Try to keep the customer on the phone while you give them a kind and well-meaning lecture about how their behaviour might get them less support than they would being kind and try to make sure they understand that a support contract gives them the right to obtain technical support for a product, it does not give them a right to call up and abuse tect support staff. Most customers will respond favourably to this, but it's a minefield.
I had one frontline girl who would ignite fairly quickly when one of these customers called. My super wanted to sack her or pull her off tech support completely, but I like to think I got her trained, at the cost of taking one of her customers over completely, personally (this was the t-shirt customer mentioned below, BTW. Hi, Jodi! ;-). One could also have frontliners mention that all calls are recorded - this seems to cool most of them down.
Treat your customers good. This sounds like a no-brainer but it's surprisingly often that techs talk crap about customers when they think they've muted them. :-) Do not encourage that. Encourage empathy and foster a culture of siding with the customers against the company. Or, at least make it SEEM so. Bond with them. They will love you, one and all. I have gotten t-shirts and other sundry gifts sent to me from happy customers, just because I listened and I made my people listen to them. Which brings me to the next point:
Listen to your customers. Many customers do not primarily need to get their problem fixed, the need a sympathetic ear - someone that listens to them. Consultants on site may need someone to blame and Sysadmins may want a human to talk to for a bit - so give it to them. It's their dime.
And, like someone else mentioned - integrate tech support, documentation, QA and training. In my case, I worked in all of them and while I formally was employed as webmaster, I soon wound up running the documentation and training team and we all did scheduled tech support - even the developers. This was invaluable for feedback into the training, website and documentation, not to mention that we could get better response from the developers if we could prove that we could cut down on their tech support duties if we got them to fix their software and document it better. Make the developers truly responsible.
Tech support isn't about technology, it's about psychology.
It's not about software and hardware, it's about people.
I am now a private consultant and do give courses and training seminars in this area (among others) - contact me if you need me.