Conversation Rules
Overview
Conversation rules provide a mechanism for administrators to customize how conversations are routed and the messages sent when certain events occur (i.e., auto responses).
Rule sets are defined in versions to allow for an easy way to reinstate a previous working set. Previous versions are listed on the main screen and offer two choices, Re-publish or New Draft. Republishing replaces the current rule set with the selected version immediately. New Draft places a copy of the selected rule set into the draft workspace. Drafts and versions encompass ALL the rules defined.
The Draft workspace may only contain a single instance of rules being edited. Creating a new draft overwrites the existing draft set. A draft may be saved and edited multiple times.
Publishing a draft immediately places the draft set into production and clears the draft area. If the new set does not work as expected, the previous version may be implemented by selecting the version and choosing re-publish. The current rule set is shown at the top and only offers a new draft from this version. Previous versions offer a new draft or re-publish options.
1. Who published this version.
2. The date the version was published.
3. Use this button to set a previous version of Conversation Rules live.
Creating a New Rule
Using the information and descriptions above, new rules may be added to implement specific message flows or routing options for distinct business units. Conversation rules are intended to apply as many data points as possible to decisioning, and to allow very simple to very complex flows to be created. Keep in mind that the Draft workspace is safe but publishing pushes the rule set into production. Save often and publish sparingly.
Editing Rule Sets
Rules are fired by events and are composed of decisions and actions. An action may be taken without a decision, or as a result of a decision based on complex conditions, allowing multiple conditions with ALL or ANY logic to be met. Multiple decision steps can branch the rule leading to many different actions as a result. Care should be taken to craft each rule with specific purposes in mind, and to evaluate whether rules overlap or conflict. The actions and decision steps of a rule are executed top down, so position matters.
Events
Rules are triggered by events. Every rule is triggered by at least one but possibly many events. Selecting the correct event(s) allows actions to be taken at the appropriate time. The conversation rule interface will provide guidance for you to determine which event is best used to meet your business rules. Below are examples of the different types of events available:
| Event | Description |
|---|---|
| Is starting | Occurs whenever a conversation starts including both customer-initiated (through new messages) and agent-initiated messages. This event is commonly used for setting the initial queue of a conversation as well as setting its priority. |
| Is routed | Occurs whenever a conversation is routed to an agent. When routing occurs, agents receive an invitation to accept or reject the conversation. At this point the conversation is not yet assigned to the agent. |
| Is routed to an agent when it starts | Occurs whenever a conversation is routed to an agent when it starts. This event will not fire if the conversation is initially enqueued and does not fire if the conversation is routed later in its lifecycle. |
| Begins waiting in a queue | Occurs whenever a conversation begins waiting in a queue because there are no agents availble or none have capacity to take the conversation. This is the only other result when a conversation starts. It is either queued or routed. |
| Lands in queue when it starts | Occurs whenever a conversation lands in queue when it starts. This event will not fire if the conversation is initially routed and does not fire if the conversation becomes enqueued later in its lifecycle. |
| Is in queue and awaiting a response | Occurs whenever a conversation is in queue and is awaiting a response to a customer message. This can occur when a conversation waiting in queue receives a new customer message or when a conversation with an unsatisfied customer message lands in queue. |
| Is still waiting in queue | Occurs periodically when a conversation is waiting in a queue. This event will fire at least once every 5 minutes on a waiting conversation and provides an opportunity to react to the passage of time or changes in staffing, queue wait times, etc. |
| Is assigned | Occurs whenever a previously unassigned conversation is assigned to an agent. A conversation is not assigned until an agent has accepted the invitation, if invitations are enabled. This event can fire multiples times during a conversation's lifecycle. |
| Receives a new customer message | Occurs whenever a new message is received from a customer, including when that message starts a new conversation. |
| Receives a new customer message while waiting in queue | Occurs whenever a new message is received from a customer while the conversation is waiting in queue. |
| Is closed | Occurs whenever a conversation is closed, whether it is done so explicitly by an agent, a bot action or by a system timer. |
Actions
Actions are what you want to happen when the rule criteria is met. The follow actions are available for use:
| Action | Description |
|---|---|
| Send a message | Send an auto response to the customer that may contain rich content or vary by platform. A message may also include the following variables as merge fields: {{companyName}}, {{newNumber}}, {{contactPoint}}, {{estimatedWaitTime}}, {{conversationId}} Salesforce CRM specific: {{caseId}}, {{caseNo}}, {{leadId}} Oracle CRM specific: {{incident}} Zendesk CRM specific: {{ticket}} |
| Send to queue | Sends the work item to the specified queue |
| Send a summary of this conversation to Slack | Send a summary of the conversation to Slack (if configured). |
| Send to the least loaded of several queues | Sends the conversation to the queue with the lowest workload among those passed to the action. |
| Send a catalog message | Send a Catalog Message to the customer that may contain rich content or vary by platform. |
Decision Steps
Decisions evaluate conditions. When conditions are combined, ALL or ANY operators may be selected. Decisions may also be nested. Decision paths may be left blank, but most result in an action. The decision branches are shown in varying shades of gray color boxes to indicate scope. Once a decision is determined false, the next branch at that level is evaluated and any subsequent logic at that level is bypassed. A true decision completes the rule once the specified actions are taken.
Default Rules
There will be at least four default rules in place but any number of rules may be added. The defaults are described below.
Initial Queue Assignment
Use both system and conversation variables to determine which queue the conversation should be sent to. A number of options are available with the values specific to the field chosen. The first selection determines when the rule is applied. Most will want the “is starting” event to handle where a new conversation is directed.
Add a conditional check next, using the IF and the dropdown of available fields to evaluate.
Four main categories of fields are context, conversation, time, and workload.
-
Context: fields related to events or conditions at the time the rule is being evaluated.
-
Conversation: data fields in the conversation. Consider that at the beginning of a conversation, many of these fields will not yet be populated.
-
Time: allows a comparison of the time the rule is executed to a defined time/day parameter.
-
Workload: current measures of queue conversation counts and agent availability in relation to queues.
Condition is context sensitive based upon the selected field. Condition determines what type of comparison is being made (is/is not, contains, >/<, etc.).
Value is also context sensitive depending upon the field selected. Fields with a fixed set of values will only have those displayed. Conditions that set a range will cause the value to select beginning and ending values.
Example Rules
Example 1
If the contact point the conversation was started on is “end user support”, route the conversation to the Default queue.
1. Create the conditional statement:
2. Add the action:
3. Select the queue:
4. Scroll up and click Save to retain the changes to the draft.
Example 2
- Add another condition:
2. Choose whether all the conditions or any need be true to satisfy the rule element:
3. Follow the same field addition steps from above.
The below rule element routes the conversation to the Default queue if the contact point is End User Support or the platform is Facebook:
Initial Auto Response
When a conversation starts, it is either sent to a queue, or routed to an agent. For both of these cases a message may be sent. A message sent for the routed to an agent case may prompt the customer for information the agent will need, or simply inform the customer an agent is reviewing the conversation. When a conversation is sent to a queue, the customer may have a bit of a wait. Sending a message that informs the customer of the expected wait provides a better experience.
Consider that two main branches of the sent to queue path are the queue is staffed with available agents but agents are busy (soft limits reached), and there are no available agents (off hours). Send the proper message for both cases.
Note
The option to “Skip if the customer had a recent conversation" is important to consider. Receiving multiple auto responses may degrade the interaction so this option suppresses the message if the same customer had a previous conversation end within the last 15 minutes.
Waiting in Queue Auto Responses
Customers may send a message while a conversation is in queue, even if they have received the initial auto response. The message defined here reminds the customer that they are still in queue and will be addressed when an agent becomes available.
Closing Auto Responses
The closing auto response is blank by default. Many organizations send a thank you message here, or may include a link to a feedback survey, or possibly a promotional link.
Updated 9 months ago