{"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 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 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 From the quantitative data, we concluded that the problem of users leaving web chat is important and impacts a high percentage of end-users. From the qualitative research, we knew why users leave web chat and what brand expectations are. Therefore, we decided to phrase the problem in the form of a \u2018How might we\u2019 statement as:<\/span> We understood that users leave web chat when there aren\u2019t enough agents to address their problem in real-time, or when the brand itself needs more time to solve the problem and prompts the user to leave web chat. Yet we wanted to probe further into a customer\u2019s needs and goals in order to understand what exactly our solution should achieve. As we continued conducting interviews with several customers, two key patterns stood out:<\/span><\/p>\n Having identified these key patterns, we were able to refine our problem statement from<\/em>: Given the two key goals encapsulated in our \u201cHow might we<\/em>\u201d statement, we generated concepts on how to help brands:<\/span><\/p>\n There were several approaches we could have taken to help brands contact their users, including:<\/span><\/p>\nWhy We Prioritized Creating The Option for an Asynchronous Web Experience<\/h2>\n
How We Created Web Chat 2.0 in Seven Stages<\/h2>\n
Stage 1: Research<\/strong><\/h3>\n
\n
Stage 2: Problem Framing<\/strong><\/h3>\n
<\/span>
<\/span>\u201cHow might we help brands continue solving a user\u2019s problem even if the user leaves web chat so that users stay happy with the brand\u2019s customer support.\u201d<\/span>
<\/span>
<\/span>In the early-stages of defining a problem, we focus solely on the goal that the brand wants to accomplish and refrain from incorporating any solutions in the problem statement. We take a \u201cBeginner\u2019s Mind\u201d approach so that we can open ourselves to any solution that would best solve the problem. The solutions we eventually ideated ranged from Dynamic Text in the browser tab, to web push notifications, to sending an email.<\/span>
<\/span><\/p>\nStage 3: Problem Refinement<\/strong><\/h3>\n
\n
<\/span>Our customers told us that they<\/span> believe the lowest burden on their users would be for them to not have to reach back out, so our customers want to be able to reach out to them.<\/span><\/li>\n
<\/span>Our customers told us that <\/span>it would be ideal if the customer could leave a thorough enough message so that they could resolve the issue in one touch.<\/span>\n\n
<\/span>\u201cHow might we help brands continue solving a user\u2019s problem even if the user leaves web chat so that users stay happy with the brand\u2019s customer support.\u201d
<\/strong>
to: <\/span><\/em>\u201cHow might we help brands contact a user when the brand has identified a resolution to the user\u2019s problem so that the user doesn\u2019t have to send any more messages \u2014 resulting in happier users.\u201d<\/strong><\/p>\n<\/blockquote>\n<\/li>\n<\/ul>\nStage 4: Concept Generation<\/strong><\/h3>\n
\n
<\/span><\/li>\n<\/ul>\n\n
However, this would require the browser tab to still be open. From our data, we knew that on average users take about four seconds to read a message sent by the brand. We therefore concluded that this feature wouldn’t have a significant impact since users are already reading messages in a timely manner. Plus, it wouldn’t be effective at all if the user had closed the browser tab.<\/li>\n
<\/span><\/span>\n