Insights from Our Experts
Email Efficiency for the Technical Herd
The introduction and proliferation of various instant messaging platforms paved the way to quicker communication between people, and this would force one to think that the era of email is bygone, yet a recent study proves otherwise. In 2019, Adobe surveyed over one thousand American individuals to determine the average time they spend in checking emails. To everyone’s amusement, they confirmed that emails still form a major pipeline of communication, and on average an American worker spends over 3 hours every day in checking and responding to work-related emails.
Now, the big question is, for a task that consumes over 40% of an employee’s daily productivity, are they even monitored continuously for their efficiency? The question is not directed to the folks in the customer experience sector, because, for a fact, nothing gets more scrutinized than an email that they send out. The question is directed at all the so-called technical folks (including myself) - the developers, the designers, the team leads, the project managers, and all the other employees of a typical IT solutions provider, who needs to address the customer at some point during their professional journey. The short answer would be, no or not enough.
When an email gets sent out by you or your team to a stakeholder, they immediately become the poster boy for the organization’s branding, but yet, not enough attention is given to it, especially when the team member is a technical guru, rather than a management wizard. The email could make or break the bond that the sales team has carefully built over time.
With that being said, let’s focus on some of the key points that we should be careful about while addressing a client. Heads up, I’m not dwelling into the details of an email structure, as most of you already know that from your high school. Instead, I will be focusing exclusively on the email etiquette that a team member of an IT services provider, should follow while addressing the stakeholder queries or concerns, as mostly, when a developer, designer, tester or anyone from the production team writes to the client, it’s either to address a query or an issue.
The key here is to be minimal and informative at the same time, as it helps to retain customer loyalty and assure customer satisfaction, as customers tend to overlook long but well-written emails over a short yet informative one. In line with the mentioned statement, we at our organization designed a compact yet precise email template for addressing the queries, service requests and issues.
Address: The rules are simple here, the person(s) you want to address, type their email address(es) in the "To" column. Everyone else you would like to notify, place their email address in the "Cc" section. An easy mistake that most people commit is to send out an incomplete or incorrect email and it can be easily prevented by not entering the email addresses unless the entire email has been drafted and proofread. Saves potential embarrassments.
Subject: Short, crisp and informative. If it's related to a project or a task at hand, always mention the project/task, followed by a few words on what to expect from the body of the email.
Salutation: A formal salutation is always warranted however, it depends on the nature of the relationship you have with the client. If the client is friendly or if you are on a first-name basis with the client, it suits to have an informal salutation, however, in all the other cases, it's safe to adopt a formal one.
Body: The body would include the following sections:
Reported issue or Service/Feature request: Paraphrase the customer’s issue or request for service/feature, and explain your understanding of the requirement or problem. It helps in making sure that you are on the same page with the customer and it also gives clarity on issue/requirement. Empathize with the client and apologize if there has been a fall in the customer experience due to any incident for which your organization is responsible.
Actual issue: A root cause analysis using any of the root cause analysis tools like 5Why’s, or Affinity Diagram or Ishikawa Diagram, should be performed to understand the root cause of the problem or the service/feature being requested. Based on the output of the root cause analysis, the actual issue/feature and it’s reasoning should be explained in this section.
Resolution: A resolution based on the root cause analysis and the expected turnaround time for performing the required action must be provided. It is critical to respond even if you are unable to provide the final solution, as the customer experience would be impacted if the responses are delayed and the customer has to input further effort to elicit a response from your organization.
Closure: Whenever your team is signing off, make sure they reiterate the points discussed previously and reassure the client about the resolution being provided, and close the email with an open-ended statement.
Signature: Uniformity is the key here in providing a reassuring and uniform customer experience to the client. Always make sure that the signature that you and your entire team use are identical, standard and have a uniform template. Provide phone and instant messenger contact information along-with the signature as it provides the customer with greater trust.
I understand that whatever I discussed in this blog is not novel information, but reshuffling and reiterating, the points that we have learned for effective communication over the years. Yet, I chose to discuss the same because of the results that we achieved by adopting these simple practices. The email template explained above was chosen after running several pilot programs of responding to clients with various temperaments, and we found that even the most irate customers found the template satisfying as it was brief, yet informative. However, the key to the template lies in how words are crafted into each section and most importantly on the root cause analysis itself. If the root cause analysis is incomplete or the way it’s performed is flawed, it will result in an error being determined and resolved which may not be the actual issue and which may not(in the long run) resolve the client’s issues, thereby affecting the customer experience.
An emphasis has been given to root cause analysis even though I have not explained the steps for the same, and I understand it can be confusing right now, but root cause analysis itself is a vast field and it would not do justice to the topic if I had to include it in this section. So, in one of the upcoming blogs, I will be providing an insight into industry standards for understanding problems and determining root causes.
Have a go at it, and let me know the results.
We compose great codes and deliver them on time, just like great Emails!!Click here and we will send you some.