Esri Chat bot Implementation
Esri chatbot implementation
Q4 of last year my team and I were asked to solve a series of big problems:
Esri sales chat was being used by users to get in touch with technical support and customer service, and vice versa. This caused us to spend money, time, and resources on directing users to the right department.
We noticed that more sales were closed via chat than via the forms on our product marketing pages.
We were tasked with a mission:
Reduce friction for our customers
Create an at-scale chat experience. (Right now chat only appears on a select number of pages).
Requirements gathering:
Before we could really start thinking about chat, the one thing we needed to do was gather requirements, from various affected departments in order to understand our needs.
As such, I led a series of workshops, with key members from Content, Sales, Customer Service, Technical support, and e-commerce. My goal was to gain alignment across departments to get everyone’s needs met and make sure that they are heard.
We asked stakeholders to define the stages of chat:
They were:
Pre chat (with the chatbot)
Chat (with an Esri employee from either sales, tech support, or customer service)
Post chat (what happens when a chat ends?)
We then asked them to list out as many requirements as they needed for each phase, within a 20 minute period. All stakeholders participated in this activity. The idea was to get a knee-jerk reaction from them and put down whatever came to mind.
Affinity Mapping:
After this phase was complete I grouped post-its into groups to extrapolate the big ideas. I did two rounds of this. The first time to get clusters of ideas. I then grouped clusters together, to see if I could pull even bigger ideas out from them.
High-level requirements:
Allow users to edit and update canned responses.
Chatbot comes with an option to dynamically enable/disable web contact forms to lead with Chat vs online form
Chatbot has the ability to get users to the right chat queue. EX: Sales, technical support, customer service.
Personalized content and prompts are informed by data, from users’ onsite behavior.
During the chat, the chat/chatbot should be collecting data on on-site behavior for a given user to allow us to analyze the site. behavior/purchasing patterns, as well as pull up user transcripts, to further assist our customers.
Chat enables users and agents to connect via other communication channels: video chat/call.
Chat allows agents to facilitate follow-ups with prospective and current customers.
Chat provides attribution to sales agents, as well as a full suite of features for purchase history.
Questions:
What happens when the agent isn't available during business hours?
Once customers initiate a chat, how do we keep them there?
What information is required to initiate a chat?
Note: These questions become the crux of the feature analysis. More on this later.
Documents that came from this exercise:
Chat requirements document
RFI (Request for information), which was sent to various chat vendors.
Assumptions gathering:
We also collected assumptions about what we thought users would want from chat. The reason for this is to create criteria, that we can then test against, once the chatbot is implemented.
High-level takeaways
Some themes emerged. We believe users want a chat experience that centered around:
Friendliness:
As a user I want chat to make me feel valued ad welcome.
Helpfulness:
As a user, I want to get to be directed to the right person to answer my questions.
Expediency and speed:
As a customer, I want to talk to a customer service agent as quickly as possible.
As a user, chat means that I can get answers quicker.
As a user, getting my questions answered quickly is important to me.
Transparency:
As a customer, I want transparency in how data I provide is being used, and want to be able to opt-out in giving it.
As a customer, I want context, for why I am being asked engagement questions.
Knowledge sharing:
As a user, if I do not understand the nuances of a product, I want to chat with someone who has extensive knowledge of the product landscape, to help me answer my questions.
As a user, I want to understand I want to trust and feel confident about the information I am getting and know that it was from a trusted source.
Other Assumptions
As a user, I don't want to have to call.
As a user, I want to be able to tailor my question to get a more detailed and nuanced response.
As a customer, I want to know that help is readily available
Chat feature analysis
We also looked at chatbot features from a group of vendors. These were B2B chatbots such as Ubisend, Drift, Chatbot, and Salesforce, as well B2C experiences, such as BestBuy and Purple Mattress. These were then aligned with articles found around the web about chat best practices. This was created to give us guidelines, that we can stand behind, as we suss out potential chat vendors.
Questions from the requirements gathering phase were used to drive this experience. The reason is, that I wanted to see anything that could be answered via competitive research, to save us time, energy, and to connect it to our requirements and their corresponding chat phase. These were also tempered by suggestions and action items
Some of these questions and findings
What information is required to initiate a chat?
In all instances thus far, it looks like at least an email address is required to start chatting.
Recommendation: Focus on which contact information matters most to us when collecting and where we want to collect it during the journey. This should at Minimum be an email address, and at max be first name, last name, business email address, phone number.
Action Item: Discuss with key members of GBD to find out what the "Happy Medium" amount of information is.
What happens when the agent isn't available during business hours?
In most instances, chatbots communicate that they are aware of and respect a user’s time in a number of ways. The first is when not available, they will allow a way to connect with them in off-hours. This is typically an email that can be sent, via the chatbot.
The second way they let users know that they respect users’ time is, they let users know where they are in the chat queue and how many users are ahead of them.
Recommendation: Be mindful of a user’s time at every step of the journey. Communicate that their time is important When chat agents are not available:
Designing the chat tree:
Lastly gathered stakeholders from each department and had them create their branch of the chat tree. These options under each bucket center around the needs of each department.
When designing the chat experience initially thought of these in three buckets:
Sales: Users are routed to three options: Get a demo, map a business need to an Esri product, and pricing. All of these options connect a user to a sales specialist. Based on the feature analysis we also determined that before connecting to a sales specialist, the chat must also serve up Esri's privacy and data messaging legal requirements.
Support: Since support is currently using its own chat client, one must be qualified to seek support. They must A) pay for support services, B) be certified by Esri, and deemed the point of contact for their department. The reason is, Esri’s software is B2B and deployed, department-wide. Therefore, all roads in support lead to the support page, email alias or web form they can fill out via chat.
Customer Service: Customer service was hard to nail down, as it has a lot of overlap with tech support. It is ultimately used for password retrieval, help with activating a demo, etc. As such questions were designed to center around those needs. As such people usually get in touch with customer service via email. Thus the chat would serve up with an FAQ, or if they still need help, it would serve up an email alias via the chat.
