Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?

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."
This discussion has been archived. No new comments can be posted.

Practices, Resources & Other Suggestions for Cust. Support?

Comments Filter:
  • by DNAGuy ( 131264 ) <brent@brentrockwo o d .org> on Saturday October 26, 2002 @06:01AM (#4536108) Homepage
    Whenever considering a new vendor or product, I always visit the customer service/support web site. It's important to me to be able to solve most of my problems on my own. Access to a knowledge base, user manuals, and other technical data over the web can save me hours on usenet or on the phone, especially if the product is not widely used. A good customer service site also tells me that the vendor is serious about customer satisfaction. The added bonus, of course, is that the vendor can save some serious dough for every customer who is able to solve their own problems. Win-win all around.
  • Tools and Freedom (Score:3, Informative)

    by SilentDissonance ( 516202 ) <dissonance@spamcop.net> on Saturday October 26, 2002 @06:07AM (#4536121)

    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:

    • Fast, easy-to-use documentation database
      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.).
    • Customizable Knowledge Base
      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.
    • Freedom
      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. :)

  • by Anonymous Coward
    read the BOFH columns.
    use google to find them.

    thank you for ringing customer support.
  • by floydigus ( 415917 ) on Saturday October 26, 2002 @06:45AM (#4536169)
    First, get yourselves a decent problem management tool.

    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.

    • I currently work at a help desk for a small business isp and all of the above it true and it is a dream to work there

      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.

  • by floydman ( 179924 ) <floydman@gmail.com> on Saturday October 26, 2002 @07:49AM (#4536252)
    I am a Tech.Support team leader my self, and this is what i get:

    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 :)..(they go around corrupting ur software and when asked whem happened, they say "it just went crazy!!!")

    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..... ....HE IS ALWAYS RIGHT....
    • Actually, on this last bit, this is the one realm where the customer is not always right. Remember that Sturgeon's law also applies to your lusers. If "it just went crazy", even if the problem can be attributed to luser error, as far as they are concerned it is your fault, and you must fix it - but it's up to you to explain to the user why he should not pour water on the keyboard (or something similarly stupid) again.

      But then again, don't go assuming your lusers are all id10ts. Just my $.02.

    • One of the suptleties (spelling?) of customer support is rarely, if ever, taught in training. Try to avoid saying "sorry" to the customer. Even if they "are always right" the instant you say "sorry" it is a psycological jump in the customer's mind, that you admitted that you (either personally, or as a representative of the company) are wrong.

      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.

    • Perhaps you need to bone up on spelling and grammar first.
    • 6) Hire people who know how to spell and write. If you're going to be communicating with customers via email or your own documentation, and it looks anything like the above message, they won't take you seriously.
  • Ok;

    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
  • 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.

  • I'm currently working in a Customer Service Repair Center for a small company that is in the process of being swallowed by a big company. My previous job was doing design and documentation (and IT, and assembly, and apprentice machinist...) at a very small company. Here are the things I've learned in the last few years:

    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!

  • Try reading some real-life examples of customer relations strategems here. [actsofgord.com]
  • You'll undoubtedly want to make certain measurements so you know how good a job you are doing. Be careful to measure the right thing.

    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.
  • you should definitely read up on this (though I am not aware of any first-rate books on managing customer support), and get a decent theoretical grounding in the subject.

    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...
  • I have worked three years in a small-grew-to-medium-sized software development company as webmaster/support tech (all levels)/documentalist/trainer (trained tech support staff, both in Sweden and our US subsidiary) and a year and a half in a medium-sized software development company as webmaster/documentalist and these are my experiences:

    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.

I go on working for the same reason a hen goes on laying eggs. -- H.L. Mencken