{"id":23063,"date":"2019-01-02T00:00:00","date_gmt":"2019-01-02T08:00:00","guid":{"rendered":"https:\/\/www.helpshift.com\/web-chat-now-asynchronous\/"},"modified":"2024-04-15T02:09:45","modified_gmt":"2024-04-15T09:09:45","slug":"web-chat-now-asynchronous","status":"publish","type":"post","link":"https:\/\/www.helpshift.com\/web-chat-now-asynchronous\/","title":{"rendered":"Web Chat 2.0: Behind the Scenes of Creating Fully Asynchronous Web Messaging Capabilities"},"content":{"rendered":"

The following post explores how Helpshift’s product management team has redefined traditional web chat to address our customers’ largest pain points. There are plenty of use cases for brands to continue providing real-time support, but we wanted to give them an alternative when live chat is not feasible or preferable. <\/em><\/p>\n

Messaging platforms such as Whatsapp and WeChat have brought about a fundamental change in user behavior, one that resulted in conversations becoming <\/span>asynchronous<\/span><\/i>. <\/span><\/p>\n

Mobile app users are increasingly embracing the idea of sending a message, continuing with their daily responsibilities, and returning to the app to check for a reply minutes or even hours later. At Helpshift, we started to wonder if this behavior would hold true for web chat as well. <\/span><\/p>\n

Why We Prioritized Creating The Option for an Asynchronous Web Experience<\/h2>\n

Last year, we started collecting relevant data, and found that in a period of three months (Jan 1, 2018 to March 1, 2018), roughly 54 percent of website visitors that had sent a message to customer service did not see the reply. This meant that the user had left the web chat window and wasn\u2019t present to read the response sent by the brand. <\/span><\/p>\n

The conversation stopped, making it difficult to resolve issues without the user having to resend a message and start over. <\/span><\/p>\n

A few of our brands figured out a workaround to re-engage users after they left web chat: agents would manually create an email issue and continue the conversation over email. <\/span><\/p>\n

This can be a time-intensive and inefficient process. <\/span><\/p>\n

The realization that a majority of web visitors were leaving web chat and that our customers had to manually create email issues prompted us to investigate and prioritize the web messaging experience. We realized we needed web chat to support both live and asynchronous messaging experiences, and began to solve for this as a team. <\/span><\/p>\n

Here\u2019s an example: <\/span><\/p>\n

Imagine that a retail customer, Richard, orders a shirt and hasn\u2019t received it yet. Already frustrated, Richard visits the retailer\u2019s website, opens up the web chat widget and describes the problem with his order. Unfortunately, the support team is backlogged and can\u2019t respond immediately, so Richard must choose between being the 15th in queue or returning later to start over. This is a poor user experience. <\/span><\/i><\/p>\n

Now imagine if Richard was able to describe his problem in a message and then leave the browser. Then, when an agent becomes available, Richard gets an email notification with a link to the agent\u2019s reply. The link takes Richard back to the messaging window, with the conversation history fully intact. <\/span><\/i><\/p>\n

Richard and the agent can continue messaging back and forth at leisure until the issue is resolved, without Richard having to wait around in the browser or having to restart the conversation. <\/span><\/i><\/p>\n

With asynchronous web messaging, brands can ensure that users’ problems get solved even if they are no longer available on web chat. Creating this experience became our new goal, and as a product manager, I\u2019d like to walk you through my team\u2019s process and the principles that shaped this capability.<\/span><\/p>\n

How We Created Web Chat 2.0 in Seven Stages<\/h2>\n

Stage 1: Research<\/strong><\/h3>\n

From our data on web chat usage, we knew that 54.2 percent of users were leaving web chat. This gave us insight into \u2018what\u2019 users were doing. However, it didn\u2019t answer the \u2018why\u2019? Why were users leaving web chat? Were they leaving web chat because they didn\u2019t get connected to an agent quickly? Were they leaving web chat because they didn\u2019t like the agent\u2019s responses? Were there other reasons for leaving web chat? To get to the root of the problem, we decided to conduct exploratory research with several customers in order to understand why users were leaving web chat and found two key reasons:<\/span><\/p>\n