When Customers initiate Chat on your website and are logged into their online account/portal/members page, Glad App can identify Customers’ email addresses without needing to go through the onboarding process again of asking for their email address to find their Customer Profile, providing personalized service and making Customers feel known.
With JWT authentication, chats begin by greeting Customers by their first name, skipping onboarding if they are authenticated and logged into their account.
There are two methods to onboard Customers in Gladly automatically:
Standard identification without Javascript Web Token (JWT)
Utilizing setUser(), you can skip onboarding for your Customers when you know how to identify them because they are logged into their secure account/portal/members page where Glad App is also available.
To implement standard identification, make a single API call using setUser() after initializing Glad App and pass the Customer name and email address or phone number to Gladly. Note that if Glad App Onboarding setting is activated and a Customer is not authenticated in their account/portal/members page, Glad App will ask for their name and email address before a chat session can begin.
When a chat session ends, and you’d like to programmatically un-associate Customers from Glad App after they log out of your secure portal/member webpage, use the clearUser() API.
Tip – Documentation on configuring Glad App and using Glad Apps API is found in our developer guide.
Secure authentication with Javascript Web Token (JWT)
An extension of using setUser() to authenticate Customers is possible by allowing the passing of a User Identity Javascript Web Token (JWT) that can be used to identify Customers in a trusted way using their email address. JWT provides secure communication between Gladly and your Customers.
Configure authentication with JWT
See Configure Glad App With User Identity JWT to learn how to set up authentication via this method.
Additional notes when implementing JWT for Chat authentication
Level of effort
We recommend having developer resources implement and maintain this type of authentication, especially if you don’t develop and own account authentication on your website, meaning you may need third-party developer support.
Reporting
No reports indicate the number of authenticated Conversations. Authentication status only appears in the Conversation Timeline.
Authentication experience with Sidekick
Rules may be created within the Thread Builder to adjust behavior based on the Customer's authentication status, allowing for a more personalized experience in Sidekick.
Mobile implementation (iOS/Android)
Mobile SDKs are currently not supported, but you can still use the standard authentication.
Customer and Agent experience if authenticated using JWT
Train your Agents to understand the authentication UX
Train your Agents to understand the various UX they may encounter based on how Customers verify their identity during the Chat onboarding process.
The key difference between utilizing secure authentication with JWT and standard identification without JWT is the appearance of the Trusted Message icon in the Conversation Timeline, indicating that Glad App identified that the Customer is logged into their secure account/portal/members page.
The green trusted message icon shows that the Customer logged into the account they’re chatting from. An Agent can have a trusted Conversation with a Customer, eliminating the need to ask Customers to confirm their identity manually.
Trusted messages on closed Conversations display a gray trusted message icon, and non-trusted messages appear without the icon.
Customer and Agent UX samples using JWT
Note the subtle differences in how chat messages are presented to Customers and Agents based on authentication order, ranging from the most ideal to the least desired.
(Most Ideal) Customer is already logged into their account when they start Chat
The most ideal scenario for secure authentication using JWT is a Customer is already logged into their secure account/portal/members page before starting a chat. This allows the Agent to have a trusted and personalized chat Conversation with a Customer without asking the Customer to authenticate their identity.
(Ideal) Customer is not logged into their account, opens Chat, and proceed to log into their account before the Chat begins
Customers can still have a trusted and personalized chat Conversation before being routed to an Agent by logging into their secure account/portal/members page before the chat begins. The First Message in Glad App must include a link to your secure login page.
(Standard) Customer ignores the link to log into their account and continues with standard Chat onboarding
Customers can start a chat by providing their email address without logging into their secure account/portal/members page. They will still be routed to an Agent with their existing (if there is one) Customer Profile (if there is one) with past Conversations. Agents can ask the Customer to log into their account anytime for a trusted Conversation.
(Undesired) Customer ignores the link to log into their account, continues with standard Chat onboarding, and then logs into their account using the same email
Customers can start a chat by providing their email address without logging into their secure account/portal/members page. They will still be routed to an Agent with their existing (if there is one) Customer Profile (if there is one) with past Conversations. Agents can ask the Customer to log into their account anytime for a trusted Conversation. Still, the better process is if authentication can be accomplished before the chat is routed.
(Most Undesired) Customer ignores the link to log into their account, continue with standard Chat onboarding, and then log into their account using the same email
Customers can initiate a chat by providing their email address, even if they haven't logged into their secure account/portal/members page. Gladly will still route them to an Agent with their existing Customer Profile (if they have one) and past Conversations. However, Agents may ask Customers to log in for a trusted conversation at any time. Suppose a Customer provides a different email address than the one they provided to start the chat. In that case, the system will consider them a different person and route them to a different Agent accordingly.
Glad App configuration tips when implementing JWT
Your Customers must be logged into their secure account/portal/members page to authenticate using JWT. For Customers chatting in who are not already logged into their account/portal/members page, set up Glad App to include a link to your login page in the First Message, allowing the Customer to authenticate their identity before the chat is routed to an Agent.
Note – Onboarding does not need to be activated in Glad App for JWT.
It’s ideal to encourage Customers to authenticate before they’re routed to an Agent, hence the ask to log into their account in the First Message in Glad App.
You can encourage Customers who do not have an account to create one before starting a chat. Otherwise, they can provide their email address, which could create a new Customer Profile if it’s the first time they’re reaching out using the email address or find any past Conversations if they’ve reached out in the past.
Encourage Agents to have authenticated Conversations with Customers
While Customers can start a Conversation using their email address and Agents can see past Conversations, encourage Agents to ask Customers to log into their account (if they have one) to have a secure Conversation, especially if questions are account-related or in situations where additional verifications should be required. Agents should do this as early in the Conversation as possible, but remember the UX nuances based on when a Customer authenticates in the chat process.
You must establish your own guides and protocols on how to best guide Agents in supporting authenticated (i.e., known accounts) and non-authenticated Customers.