CivicActions Project Support Best Practices
Respect for our users and clients is one of the primary values in our work. As CivicActions support staff, we demonstrate this by emphasizing helpfulness, timeliness and kindness in our working practices.
All communication from CivicActions Support should be as accessible as possible. Using plain language when communicating with each other, end users and clients is critical for people with different cognitive abilities, speakers of a non-English language, or those who rely on audio to listen to text. Try to keep the reading level of your responses between a 6-8 grade reading level. Use of a plain language tool such as the Hemingway App can help you achieve accessible communication.
When answering a user question, we always strive to provide helpful information. Many support interactions in the world seem designed to make the user go away. Our aim is the opposite: We want to solve the problem. We want to help.
To be helpful, we use the following tactics:
Our users know more about their problem than we do. However, users' ability to explain their problem may vary widely from person to person and from circumstance to circumstance. If the initial question comes to us in writing, we read the question carefully. If it's being explained out loud, we listen carefully. We may begin by restating the problem as we understand it. This can often surface misunderstandings early and prevent frustration or wasted effort; it may also result in important clues that we'd otherwise have missed.
If we don't have enough information, we may ask for clarification. We exercise our best judgement here: Often a bit of quick research will save time and effort. We never use clarification as a defensive measure or a way to put the burden of effort onto the user.
Once we have enough information to begin, we may decide that we need to learn more about the problem. For some web applications, this may involve replicating the user's behavior in order to provide clarity or technical details. In other cases, we may need to study documentation or consult our engineering team. The details about this will vary from project to project. We're cautious never to let research interfere with our ability to respond to the user; there are a lot of fascinating things to learn, and we focus our effort on helping users first and educating ourselves second.
Once we have enough information to address an issue — even if the question is not completely resolved — we deliver a helpful response. The level of detail should be pitched toward the user's technical proficiency, but truthfulness should not: Our explanations should always be candid, open and informative. Some users (for instance, one-time end-users who have a simple question about a specific feature), however, need very little detail, while others (for instance, long-term clients who are deeply engaged in our work) may want all the detail that we can provide. More importantly, our response should, whenever possible, help move towards a solution or improve the problem that resulted in the original request.
Our responses are respectful, clear and concise.
Often when someone asks a question about a web application, responding quickly may make the difference between them giving up or being successful. We want to help them succeed, so we respond quickly. For a given project, we may observe specific SLA (Service Level Agreement) times, but our motivation is never the SLA time itself; our motivation is to be timely so that we can best support the user. Because of this, in most instances our actual first response and resolution times will usually be much quicker than required by SLA numbers.
First Response Time
The first step toward helping users feel attended-to is to always reply promptly. Any reply is better than no reply. Users and clients like to know that we've read their correspondence, and that we're looking into the issue. We don't have to know everything in order to begin an interaction, and we don't even have to be specific about next steps; often our first response may be as simple as:
Thanks for sending this over! It sounds like you're experiencing a problem with (statement of problem). We'll (research some more about this / put it in front of our engineers immediately / see if I can solve that problem), and we'll follow up once we've got more information.
Let me know if I can help with anything else in the meantime!
The simple act of sending a response that acknowledges a question helps create a mutually beneficial partnership, and tells the user that they're not alone.
We always follow up. We check and re-check our ticket queues frequently. If a person hasn't yet responded, we reach back out, and make sure all is well at least twice before closing the ticket. There may be times when this is inappropriate (spam doesn't need a response, and someone angrily unsubscribing from a website may want to be done with the interaction as quickly as possible), but in most cases we reach out to make sure an interaction is complete.
We do our best to solve problems quickly. We can't always do this; sometimes problems require lengthy engineering engagements, or simply can't be done, or shouldn't be done. But when possible, we come to an actual solution quickly and let the user know. If our resolution doesn't solve the original request, we'll explain why and what's being done instead.
If a given support interaction requires engineering time or work that's outside support staff's capacity (for instance, if it means opening an engineering work ticket, or requesting approval or information from a stakeholder), we'll inform the user of the next steps, make sure they know everything they need to know, and communicate with other people involved to make sure those next steps can and will be taken, before our support interaction can be considered complete.
As with First Response time, our primary goal will be solving users' problems in the most effective way possible. The timeliness of our resolution is important, but is always in service to providing a good user experience.
Websites and web applications are frustrating; we've all experienced this. At CivicActions we put ourselves in our users' shoes, and recognize that they may view the site and the situation at hand from an entirely different perspective than those of us involved in building or maintaining web applications. Our perspective is not better than theirs; if we know more about a web application's construction, the end-user probably knows more about the subject area that it's designed for. Our goal is to partner with users to make our tools easier and more effective to use.
We always remember that just because a feature makes sense to us doesn't mean that it makes sense to end-users! Users may or may not have a strong background in computers and technology. Website users may be new to a particular browser environment or website type, or be limited to frustrating hardware and software requirements by their employer. Our goal is to do what we can to make the tools fit their needs. It's always in our mutual best interest to try to meet users where they're at.
It may sometimes be necessary to reassure that we're here to help. Many support interactions in the world are not helpful, and users may sometimes assume the worst. We can change that by simply saying "We'll do our best to solve that!" or "I'll get to the bottom of this and find out the answer for you".
At times, as with any kind of work, communication with users can be frustrating, but every interaction is a chance to learn and grow, and we're at our best when we're collaborating from a standpoint of humility and appreciation. When we experience what appears to be impatience or rudeness from a user, our first choice in response is to express empathy so that the user knows we're on their side. This is surprisingly effective at solving problems. It also reflects our own personal motivations — we're actually here to help — and the CivicActions company values.