Seven Steps Before Hitting Send

0
73

Share on LinkedIn

We’ve all been there, scrambling for the undo/unsend button or wishing that the words coming out of our mouths had been rehearsed and polished just a bit more. A demanding text message from a coworker lights your fuse and you furiously type out a reply. A post criticizing your wife, children, family, or character sends you fuming and you launch into an attack. Or maybe it is not a coworker or a random anonymous social media user, but a customer… before you hit send or respond seven tips that will save your day.

1. Read or Repeat

Read or repeat the customer issue carefully. Reading seems like an oversimplified tip for improving your response and responsiveness to customers, but it is essential. If there’s an email, or if the customer has submitted a written request via your support portal or ticketing system, be sure to read the email and any case notes and details in their entirety. If there is a transcript available from the call, read it and make sure you have reviewed the entire transcript.

If you are in a live call with the customer, focus on listening first. As often as necessary, and it should be both often and necessary, repeat the customer’s explanation, questions and concerns back to them. Each time, listen closely to avoid asking repeat questions and to glean more information.

2. Identify the keys of the case

When reading or repeating, listen carefully to identify the keys of the case. Three areas to listen for:

a. Problem Description

What is the customer’s problem? Many times customers, especially those unfamiliar with a product or service, will not be able to state the problem clearly. They may simply provide a list of symptoms. While those familiar with the product or service may not state the problem clearly, but choose to provide you or your organization with solutions. As VP of Customer Experience, I received a case where the customer suggested we improve an area of the product to avoid an issue. As we worked to clarify and understand, we realized that the real problem was an invalid test case and an improperly configured system. In addition, whether they provide you with solutions or symptoms, the real problem may not be a product or service issue, but an issue of expectation, understanding, or something beyond the product or service. For example, the real problem may reside with the OS, network, or some other application on the system.

b. Times / Timelines / Timezone

Sandi Hamilton, Director of Customer Support at SIOS Technology Corp suggests customers reporting an issue provide helpful information on the time, timezone and timelines of events. In the absence of this information, though, it is important to research any supporting case notes, documentation, logs, or other data to establish a timeline of events and the time or times a problem occurs. This can be critical for proper root cause analysis, or for developing a workable solution or workaround. Several system level tools can also be helpful for building a timeline including system logs, application logs, audit and security logs, and command history windows.

In the winter of 2020 I opened a support ticket for some equipment being stored in my garage. The first agent immediately implicated cold weather as the cause and suggested the case be closed. After pointing out more information on the case thread in terms of timelines, times of occurrence a second agent was able to rule out cold weather and provide the assistance that ultimately determined the root cause, a defective control board.

c. Questions

Identify the questions from the customer. Sometimes a customer has multiple questions and in other cases they have only one underlying question. What questions are they clearly stating within the case, case notes and conversation? What, if any, are their implied questions? Read (or listen) carefully to understand what product they are inquiring about? What problem or issue are they encountering? What activity or outcome were they trying to achieve? Why are they asking these questions?

As VP of Customer Experience, we worked with a customer whose reason for an inquiry wasn’t because they were actively impacted by the issue, but because they were unable to find information in the technical manuals, knowledge base, or website about a potential scenario required for signoff. Be sure to not only look for clues to understand what, but why.

Lastly, be sure to develop a complete list of questions that you or your team may need answered.

3. Read it again

Armed with a first critical reading, an initial identification of the problem statement, times and timelines, and the questions needing clarification or answers the next step is to read the case, transcript, or requested ticket again.

Philip Merry, Software Engineering for Customer Experience once explained how a second, deeper reading of case notes allowed him to refine the actual problem area and remove from the scope of investigation many peripheral comments, details, and statements.

4. Understand the context

Greg Tucker, Sr. Support Engineer at SIOS recently undertook a response to a customer who had inherited a SIOS configuration through a company acquisition. After crafting his reply, Mr. Tucker explained during a team case review session his response and why he was able to help the customer with their issue and provide an upsell opportunity to the Sales team. The key was understanding the context of the case. Several things that helped Mr. Tucker can also help anyone responding to a customer case, and they include:

a. Understanding the customer’s situation

What’s the situation that prompted the customer to inquire for support? What’s their environment? What’s their current temperature?

b. Understanding the customer’s role

For technical calls or cases, this entails understanding are they an IT administrator, DB administrator, general administrator, system specialist, or do they have another role such as analyst, architect, or tester. Understanding their role will also help you understand their background, the urgency, and how to navigate the level of your response.

For non-technical calls or cases, understanding their role entails understanding are they an end user, or intermediary. As a young adult, I frequently opened and handled support inquiries on behalf of older community members who were not as adept at dealing with online or phone support systems. Perhaps your customer is the same.

c. Understanding the customer’s skill level

Are they an expert, enthusiast, hobbyist, or novice with respect to your product or service? Are they an industry expert, relative newcomer to the industry or product industry, or somewhere in between? Gauging their skill level will improve the types of responses you can provide and help determine how much detail is too much and how much is not enough.

d. Understanding the customer’s end goal as much as possible

A former Project Manager at SIOS Technology Corp. once joined a critical production down customer call. As he worked through the early stages of the case he was able to determine that while the customer stated they wanted a root cause analysis (RCA), their actual end goal was to restore the system to proper operation and deploy methods to stabilize the environment as quickly as possible. Rather than drafting a lengthy RCA, the project manager drafted succinct steps to restore the system operation, along with guidelines for stabilizing the area of impact. Each tied, as it were, to the identified and summarized RCA. Had he only provided the RCA the customer’s end goal would not have been achieved.

e. Understanding the customers fears

Key to crafting a solid response is also understanding the customer’s fears and concerns. What is driving the case? What underlying concerns are they needing to address or understand? As VP of Customer Experience, our team worked with a key customer whose fear was concerned that their system was out of compliance and no longer supported.

f. Understanding the customer’s limitations

How much authority or autonomy does the customer have to address the problem or root cause? Identifying this level of authority, along with their skill level, are essential to providing the best possible response. If your response requires “root” or “Administrator” access, knowing if the customer has this level of authority or ability is critical. If they do not, your response must indicate that this level of authority and access is required for proper resolution.

5. Write

The next step is to draft your response. This draft should encompass all the key learning and steps obtained from reading, identifying the keys, re-reading, and understanding the context. Write the response, even if you are on an actual call, so that you have the ability to revise it before hitting send (or saying it to the end customer). Use softening statements throughout. Be sure that you are addressing the keys, the questions, and the analysis within the write context and at the right level.

6. Review

After writing the draft, or preparing your verbal response, review it for clarity and to make sure that you have done the following:

  1. Removed any acronyms, insider notes and phrases
  2. Restructured the body to provide necessary information up front
  3. Simplified the response and removed any unnecessary steps or suggestions
  4. Avoided blame and unprofessional or unproven accusations

You should also review the draft and verbal response to make sure that you are answering the right questions and at the appropriate level.During this review, consider reading your response out loud to catch any lingering mistakes, and to make sure that it strikes the right tone.

7. Respond with gratitude

Finally, the last step is to respond with gratitude. This is the last step. Empathize and acknowledge their concerns, and be sure to follow up to make sure they have clearly heard and understood next steps. Thank the customer for their time and the opportunity to serve them.

While we may still have moments where we hit send a moment too soon, following these seven steps will help reduce the amount of time and regret we have over those emails or verbal responses.

Cassius Rhue
Cassius Rhue leads the Customer Experience team at SIOS Technology responsible for customer success spanning pre-sales, post-sales and professional services engagements. With over 19 years of experience at SIOS and a focus on the customer, his significant skills and deep knowledge in software engineering, development, design and deployment specifically in HA/DR are instrumental in addressing customer issues and driving success.

ADD YOUR COMMENT

Please use comments to add value to the discussion. Maximum one link to an educational blog post or article. We will NOT PUBLISH brief comments like "good post," comments that mainly promote links, or comments with links to companies, products, or services.

Please enter your comment!
Please enter your name here