Working in a support-team is great!
In the front line, you get to help people understand and better use the software they bought. Behind the scenes you get to help improving it. We all love the software our company is implementing after all, aren’t we? What? You don’t? Oh, in this case , maybe you should consider changing companies ;-)
When it comes to our communication to the users, we have to be clear of what we can and what we cannot do.
‘Can’t’s
- You cannot control things.
- You cannot promise things (because you cannot control things)
- You cannot discuss with the user why a feature is important or not.
- You cannot tell how small/big the company or the size of your department is (well you can, but shouldn’t:-)
- You cannot make a department bad, in order for you and your department to look good
- You cannot say, ‘our software is faulty’ (every software has issues, so this is common sense but if you say it in these words, you are welcoming lawsuits)
- You cannot be sure that a fixed issue which works on your mac (PC, mobile device, or whatever), is also fixed on the device of the user.
- You cannot be personal to the user.
- You cannot throw a ‘sorry’ if you don’t mean it.
- You cannot apologize for the software, as you cannot control the software.
- You cannot provide documentation / training / consulting
‘Can’s
- You can explain existing features (you may say ‘as easy as that’, or ‘simply’ if it’s easy, otherwise leave it!)
- You can report issues to the developers
- You can forward feature requests to the management
- You can ask for information from other departments and inform the user about what you’ve found out
- You can use ‘we’ for things you do in the support.
- You can use ‘the developers/sales/documentation, they…’ for things happening in other departments
- You can ask for/and provide a developer build to a customer you think he/she absolutely needs it because it solves an issue he reported and you’ve tested that it’s now fixed
- If you cannot provide a developer build, and know that the issue is fixed (or feature implemented), which is very important to the user, you can admit that it will be possible
- You can and should apologize in case you misunderstood the user, or had a mistake in your reply
- You can point to training / documentation / consulting sources and forward to the colleagues the need of this particular user for a missing offer.
- You can keep your answers short, free of emotions, full of information and without ambiguity.
- You can refer to problems as ‘issues’ and not ‘bugs’. You can call the persons you are communicating with, ‘users’ and not ‘clients’ (nicer and less formal).
- And yes, by doing that you can help users of your software :-)
PS: This post had been mirrored from that other site of mine.