Making your Web Chat asynchronous provides an option for your end users to start a conversation via Web Chat, then close the Web Chat, widget switch tabs, close their tab, close their browser, or even shut down their system – and still return to the conversation later on.
This gives your users the flexibility to respond to your team when they are ready, and allows your support team to solve problems for Web Chat users without having to meet the expectations of a live chat experience. You can also harmonize your Web Chat support experience with your in-app messaging experience by using the same Bots and Automations for the same types of Issues across platforms.
When the user leaves the conversation, a follow-up email is sent letting them know where they left off and providing them with a link to return to the conversation.
Our system detects if the user has left the Web Chat window based on whether or not they have read the latest response sent by your team within a set time frame. This determination is made if our system detects that the user has done one or more of the following:
- Closed the Web Chat widget
- Went to a different tab
- Closed the tab with Web Chat in it
- Closed their browser
- Went offline completely
To prepare to integrate asynchronous Web Chat with your workflow, we recommend first deciding what data for Web Chat Issues you will want to make available to Agents via Custom Issue Fields. This data can be different than what you set for in-app Issues. We will still collect default metadata for Web Chat Issues, such as the browser and location.
Before enabling follow-up emails, please note the following:
We recommend not using the ‘Business Hours’ toggle together with follow-up emails. If you use these features together, the user may end up clicking the link outside of the email during non-business hours, which results in a frustrating support experience. Instead, you should use Automations to communicate your non-business hours.
The Web Chat conversation can be opened on a different browser than it was started from, as long as the user logs in. For this reason, we strongly encourage you to enable User Identity Verification when using follow-up emails. This is to increase security for users who are logging in to access their previous Web Chat conversation. To learn more about this feature, see What is User Identity Verification, and how do I set it up?
Our system must know the user’s email address in order to send follow-up emails. You can set up the Identity Bot to prompt new users for this information.
To enable follow-up emails, first navigate to the Settings page in your Dashboard.
Next, navigate to Settings > app settings > select the app you’d like to enable follow-up emails for.
On the page that appears, scroll down to the Web Chat section, then click the ‘Configure Web Chat’ button.
Please contact the Helpshift Support team to enable the 'Follow-up via Email' feature.
Once enabled, activate the 'Follow-up via Email' toggle on the in-app configuration page.
After you enable the toggle, you’ll be prompted to select a time duration for unread messages. This is the amount of time that has passed since the last new message was sent by a Agent, Automation, or Bot where the user has not read that message yet.
When follow-up emails are enabled and a new message is sent by an Agent, Bot or Automation, our system monitors the Issue to see if the end user has read that message within the time frame defined in this section. If the time frame passes without the end user reading the new message on their own, then the follow-up email is sent to them.
Under circumstances where an Agent, Bot, or Automation sends another new message during that time frame, then the time frame restarts to send the email starting from when the new message was sent. This is important to keep in mind if you are using Automations or Bots to trigger follow-up messages to end users as part of your workflow.
In this area you can also set the URL that the users should be taken to when they click the reply button in the follow-up email. This can be the web page where they initially started the conversation, or a custom URL configured by your team.
To learn more about using a custom URL, see When should I redirect users to a custom URL in a follow-up email?
Once the follow-up email is enabled, the user experience will vary based on whether or not the conversation started with an anonymous or logged in user. For details, see What is the end user experience like with follow-up emails?
Webhooks can be used with our HSAPI to automatically update Issues when follow-up emails are sent. To learn more, see our FAQ How do I use Webhooks & HSAPIs to update Issues when follow-up emails are sent?