When Customers contact you for assistance, you want to ensure that they are routed to the best Agent who can help them most efficiently. Gladly's Routing engine brings intelligence so Customers are helped as fast as possible.
How routing is different in Gladly
Ticket-Based Routing (Others)
Traditional ticket-based systems might assign conversations across Channels into separate tickets, or work items, for each Channel. So, what's the problem? You might end up with multiple Agents addressing the same issue. Not only does this result in overlapping work, but your customers could receive inconsistent responses from your business.
When Channel separates communications, and each communication is treated as a single transaction, the process is prioritized over people.
You can leverage the Customer Profile to route more than a "place in line." With Gladly, you can use the Customer Profile and situational scenarios to route Customers tailored to your business.
Customer-Centered Routing (Gladly)
Yes, all the traditional routing concepts (e.g., Rules, Business Hours) are still available in Gladly and are still crucial to how Gladly routes Customers. But we can take it a step further by utilizing other tools unique to Gladly, like People Match and the Customer Profile so that you can have complete visibility and context about your Customers.
How Customers are routed in Gladly
The Routing Engine looks at different factors to route Customers to an Agent. At a high level, the default process of routing Customers to Agents looks like this:
Routing looks like this if Lookup before Rules is deactivated:
Routing flow
The Customer reaches out using their preferred Channel.
Gladly checks the Channel from which the inbound Contact (e.g., a phone call, an SMS, a chat, etc.) came.
If applicable, Dedicated Hero logic and People Match boost runs.
The Lookup Adaptor runs and retrieves custom attributes from external systems (e.g., Shopify). Based on the custom attribute, this can be used in Rules to route Customers to a specific Inbox or Agent.
Lookup before Rules is the default routing behavior where the Lookup Adaptor pulls Customer custom attributes from an external system (like Shopify) to Gladly to use with Rules with a custom attribute Condition.
Note – This behavior can be deactivated so Rules can run without waiting for a lookup to occur.
Note – Voice Contacts (i.e., a phone call) can route anytime and before Rules run if there are Agents available, meaning a custom attribute may not always be ready when Customers are routed — otherwise, any Rules for phone calls run after the lookup. Data dips can be implemented if you want custom attributes to be retrieved before lookup and routing.
Expect an increase in queued-to-fulfilled time reporting with Lookup before Rules activate. The increase depends on how fast your Lookup Adaptor retrieves custom attributes.
If there are multiple Lookup Adaptors, a lookup for each instance occurs within the timeout period, and it’s possible for the lookup to timeout before all attributes are retrieved. See Lookup before Rules for more information.
This process is skipped if there’s no Lookup Adaptor.
Rules are assessed after the Lookup Adaptor runs. Depending on the Rules configured, it can move Contacts to a different Inbox or assign a Contact to an Agent.
Rules always run before routing for incoming Contacts. In all other cases, it’s not guaranteed that Rules will run before routing. For example, when an assigned Agent’s status changes or the Conversation's due date changes.
Rules continue to execute until they are completed based on Rule status (i.e., if Rule active or not) and sort order. Also, Rules are only evaluated once.
Routing ends if a Rule runs, resulting in an Agent assignment. Otherwise, routing continues to route the Contact to an Agent or Inbox.
Note – Rules before routing do not apply to the Voice Channel/phone calls and may route ahead before Rules execute.
If an Agent is available and assigned to the same Inbox, the Customer is routed after Rules run. Once the Routing Engine selects an available Agent, they are either offered (pushed) the Conversation (meaning the Agent still needs to accept the assignment) or automatically assigned. At this point, the Customer is now considered “routed.”
An Agent must be assigned and available in the Inbox to receive Customers from said Inbox.
Sometimes, after a Contact is routed/assigned to an Agent, it may need to be reassigned, which is a manual transfer of Contact from one Agent to another that bypasses the Routing Engine. In this case, the assigning Agent performs the act of routing.
When a Customer is reassigned to another Inbox (when the current Agent is “unassigned”), manually or automatically, the routing process begins again. The Routing Engine will begin looking for an Agent to assign the Customer to.
Routing follows a Push and Pull model.
Push
Implies that the Routing Engine automatically sends (either offers or assigns) new work to an Agent.
Going available on Channels and automatically receiving Customers (e.g., a phone call, a new SMS) to the "most available" Agent is a Push model.
A Push model is an Agent exiting Focus mode and available in Channels to receive Customers automatically.
Pull
Implies that the Agent requests additional work from the Routing Engine manually.
Clicking Next or Close & Next is a Pull model.
The Routing Engine gets more intelligent by looking beyond conventional Customer information. This includes data points like their:
History
Situation
Needs
This enhanced routing model is possible with People Match to truly help Customers get to the right Agent at the right time.
How Routing Customers is enhanced with People Match
While also using basic identifying rules like Wait Time and SLA, People Match can look at varying factors to decide which Customers to prioritize, how to route the Customer, and who to route them to.
Route by Customer History
Route the Customer by their status, behavior, sentiment, and overall satisfaction.
Status
VIP, Lifetime Value, Loyalty Potential
Behavior
Frequent Purchaser, Brand Influencer, Negative Actions
Satisfaction
Sentiment, At-Risk Activity, Recalled Product
Route by Customer Situation
Route the Customer by the context of their situation and the overall urgency of the request.
Urgency
Flight Cancellation, Appointment Today, Wait Time
Consultation
Vacation Planning, Previous Travel, Exploring Products
Purchase
Abandoned Cart, Clicked on Ad, Returns
Route By Customer Needs
Route the Customer to the Agent with the best set of skills and knowledge to help.
Expertise
Billing Question, Product Type, Local Knowledge
Characteristics
Language, Time Zones, Availability
Familiarity
Dedicated Hero, Favorite Agent, Relationships
Non-People Match requirements
The scenarios listed above are not completely reliant on People Match as some of them can be achieved through enhanced usage of Rules.