Routing rules
livechat.com
2021/2022
Product Design
livechat.com
2021/2022
Product Design
Introduction
Routing rules (formerly URL rules) are a set of automatic commands that define to what group of agents redirect the customers who are starting a chat. In the pre-redesigned version of the feature, customers could only set URL conditions meaning that if end-users visited a particular page address, they would be routed to a specific group of agents.
Introduction
Routing rules (formerly URL rules) are a set of automatic commands that define to what group of agents redirect the customers who are starting a chat. In the pre-redesigned version of the feature, customers could only set URL conditions meaning that if end-users visited a particular page address, they would be routed to a specific group of agents.
Introduction
Routing rules (formerly URL rules) are a set of automatic commands that define to what group of agents redirect the customers who are starting a chat. In the pre-redesigned version of the feature, customers could only set URL conditions meaning that if end-users visited a particular page address, they would be routed to a specific group of agents.
Introduction
Routing rules (formerly URL rules) are a set of automatic commands that define to what group of agents redirect the customers who are starting a chat. In the pre-redesigned version of the feature, customers could only set URL conditions meaning that if end-users visited a particular page address, they would be routed to a specific group of agents.
Who are the users?
Customers who work as a LiveChat partner - managing many companies chat widgets. Those users often create new rules from scratch to customize the chatting experience for specific businesses.
The problem
Customers couldn't route end-users based on the geolocation condition.
There wasn't a clear indication of what order rules will be applied.
Customers couldn't combine many conditions within a single rule.
Conditional logic made simple
Building an interface that allows users to set up custom logic is quite hard. Fortunately, Routing rules didn't have that many conditions users could set up. URL, Domain, and Geolocation were the only three variables determining with which agent an end-user would be chatting. Besides routing to a particular group, we also allow customers to turn off the widget when the end-user meets the specified conditions.
Conditional logic made simple
Building an interface that allows users to set up custom logic is quite hard. Fortunately, Routing rules didn't have that many conditions users could set up. URL, Domain, and Geolocation were the only three variables determining with which agent an end-user would be chatting. Besides routing to a particular group, we also allow customers to turn off the widget when the end-user meets the specified conditions.
Conditional logic made simple
Building an interface that allows users to set up custom logic is quite hard. Fortunately, Routing rules didn't have that many conditions users could set up. URL, Domain, and Geolocation were the only three variables determining with which agent an end-user would be chatting. Besides routing to a particular group, we also allow customers to turn off the widget when the end-user meets the specified conditions.
Conditional logic made simple
Building an interface that allows users to set up custom logic is quite hard. Fortunately, Routing rules didn't have that many conditions users could set up. URL, Domain, and Geolocation were the only three variables determining with which agent an end-user would be chatting. Besides routing to a particular group, we also allow customers to turn off the widget when the end-user meets the specified conditions.
Naming convention
Before the redesign, we've been referring to the last uneditable rule as the Fallback rule. Naming it that way doesn't necessarily tell the user about its purpose, so we've decided to remove the name and explicitly describe to the user what it does.
Naming convention
Before the redesign, we've been referring to the last uneditable rule as the Fallback rule. Naming it that way doesn't necessarily tell the user about its purpose, so we've decided to remove the name and explicitly describe to the user what it does.
Naming convention
Before the redesign, we've been referring to the last uneditable rule as the Fallback rule. Naming it that way doesn't necessarily tell the user about its purpose, so we've decided to remove the name and explicitly describe to the user what it does.
Naming convention
Before the redesign, we've been referring to the last uneditable rule as the Fallback rule. Naming it that way doesn't necessarily tell the user about its purpose, so we've decided to remove the name and explicitly describe to the user what it does.
Priority order
Customers didn't know what rules would be applied first in the pre-redesigned version. We've added an ordered list with draggable items and an arrow after every item indicating the priority.
Priority order
Customers didn't know what rules would be applied first in the pre-redesigned version. We've added an ordered list with draggable items and an arrow after every item indicating the priority.
Priority order
Customers didn't know what rules would be applied first in the pre-redesigned version. We've added an ordered list with draggable items and an arrow after every item indicating the priority.
Priority order
Customers didn't know what rules would be applied first in the pre-redesigned version. We've added an ordered list with draggable items and an arrow after every item indicating the priority.
Creating/Editing view
We wanted to utilize the same pattern of creating elements as in other LiveChat feature called Targeted messages. Because users are setting up conditions in both cases, we assumed that it would be easier for the customer to understand the UI. We've divided the screen in two, and instead of using IF/THEN traditional naming convention, we added more context to the content below.
Creating/Editing view
We wanted to utilize the same pattern of creating elements as in other LiveChat feature called Targeted messages. Because users are setting up conditions in both cases, we assumed that it would be easier for the customer to understand the UI. We've divided the screen in two, and instead of using IF/THEN traditional naming convention, we added more context to the content below.
Creating/Editing view
We wanted to utilize the same pattern of creating elements as in other LiveChat feature called Targeted messages. Because users are setting up conditions in both cases, we assumed that it would be easier for the customer to understand the UI. We've divided the screen in two, and instead of using IF/THEN traditional naming convention, we added more context to the content below.
Creating/Editing view
We wanted to utilize the same pattern of creating elements as in other LiveChat feature called Targeted messages. Because users are setting up conditions in both cases, we assumed that it would be easier for the customer to understand the UI. We've divided the screen in two, and instead of using IF/THEN traditional naming convention, we added more context to the content below.
Corridor tests
Based on the few non-moderated tests, we've gathered a lot of insights in terms of usability and wording for particular sections in the feature. All recordings were analyzed and mapped into a complex Miro board by Data & Research team. We've implemented an onboarding and planned to introduce descriptive empty states to enhance the experience based on the research insights.
Corridor tests
Based on the few non-moderated tests, we've gathered a lot of insights in terms of usability and wording for particular sections in the feature. All recordings were analyzed and mapped into a complex Miro board by Data & Research team. We've implemented an onboarding and planned to introduce descriptive empty states to enhance the experience based on the research insights.
Corridor tests
Based on the few non-moderated tests, we've gathered a lot of insights in terms of usability and wording for particular sections in the feature. All recordings were analyzed and mapped into a complex Miro board by Data & Research team. We've implemented an onboarding and planned to introduce descriptive empty states to enhance the experience based on the research insights.
Corridor tests
Based on the few non-moderated tests, we've gathered a lot of insights in terms of usability and wording for particular sections in the feature. All recordings were analyzed and mapped into a complex Miro board by Data & Research team. We've implemented an onboarding and planned to introduce descriptive empty states to enhance the experience based on the research insights.
Back to all projects