V4 Update #2: Live chat automations, operator skills, logic and groups
Welcome to the second in a run of Version 4 development updates and previews.
In this preview, we are taking a look at live chat. This preview only shows the new logic and automation related functionality we are introducing to live chat. We will be taking a closer look at the new operator desktop application, chat windows and other live chat features in another preview.
Live chat automations, operator skills, logic and groups
One of the main themes of V4 is automation. On-line customer service involves a lot of repetitive work and patterns. In real-time customer service (live chat), operators tend to work with a lot of time-sensitive information. Where there are patterns, things can be automated. Where there is a lot of information, information can be classified and organized.
Live chat in V4 introduces a number of new and innovative features that make organizing information, identifying your visitors and engaging your customers simpler by logic, rules and automation.
Before we jump in, here is an overview of the new functionality we are going to look at:
- Visitor groups - most likely groups of site visitors. Visitors can be placed in groups by rules (see below) or manually by a live chat operator. Each group has a title and a color, and visitors can be sorted by groups in the operator’s desktop application.
- Operator skills – most likely groupings of operators (personnel users), based on ‘Skills’. Skills can be used to logically group operators according to their specialities, or any other mark, independently of department assignments.
- Visitor rules and automations – rules can be triggered when a new visitor lands on your site or when a visitor lands on any page within your site. The rules can match a number of criteria including location, referrer, search engine keywords, number of pages visited, etc. and can result in a number of actions - such as an automatic chat request, a skill assignment, a visitor group assignment, etc.
- Thought routing - per-department routing options for the “Place a thought” messages left by visitors when an operator is unavailable.
Visitor groups
Making a new visitor group
A visitor group is a most likely grouping of visitors to your website. Visitors can be manually (by the live chat operator’s desktop application) and automatically (by visitor rules, described below) placed in groups.
In the operator’s desktop application, visitors can be sorted and filtered into their groups and represented in the color specified when making the group, as shown in the screenshot above.
We reckon the visitor grouping feature will be especially vital in improving lead spotting and lead conversion. Combining the grouping functionality with visitor rules, potential leads can be automatically organized and prioritised.
Operator skills
List of example operator skills
Operator skills can be used to mark/group operators (personnel users), independently of department assignments. Typically, this feature can be used to identify operator’s particular specialities and skills. This enables your operators to transfer chats to a collection of operators that have a particular skill, rather than just transferring a chat to a particular department or individual operator.
The operator skills functionality makes the choice administer for your first point-of-friend operators quicker and simpler. Rather than having to manually consider, identify and ensure the availability of the best operator to handle a query, the chat can be transferred to an abstract skills pool.
For example, if a visitor requests a chat for help with an installation problem relating the Microsoft Windows platform, your first point-of-friend operator can transfer the chat to the Windows and IIS skills pool (shown in the screenshot above). The chat will be placed in a queue until an operator with the particular skill is available.
An operator skill can be assigned to a visitor by automated visitor rules (described below). This means that that system can automatically make the ‘best operator for the job’ choice based on the visitor’s way, search engine query, referrer, landing page, number of pages browsed and many other criterion. Having been assigned a skill in this way, when the visitor comes to raise a chat the system will look for an operator with that particular skill first. If a match is not found, the visitor will be seamlessly entered into the normal chat queue.
By operator skills, your customers will find the right person and have their query dealt with quickly and efficiently. Your operators will also save time routing the query – especially if you use visitor rules to route the query for you, in which case the system does all of the work for you.
Inserting an operator skill
Assigning operators (personnel users) to a skill
Visitor rules
There are two types of visitor rules:
- When a visitor enters the site for the first time – matching rules are checked when the visitor first enters the site, and starts his or her session
- When a visitor opens a page – matching rules are checked on every page load during a visitor’s session
List of visitor rule criteria
Each rule has a number of criteria and a number of actions that are executed if the criteria is met.
Visitor rule criteria
The current list of rule criteria available for construction visitor rules (if you have suggestions, place a comment and let us know):
- Browsing patterns – number of pages browsed, previous page URL, previous page title, referring URL
- Search engine related – search engine found, search engine name, search engine query string
- Visitor details – browser, IP address, current page URL, current page title, visited pages URL, visited pages title, repeat visit
- Operator statuses- online personnel, online personnel with skill, online personnel assigned to department
- Time – time spent on site
- Location (GeoIP) – latitude, longitude, country, city, region, establishment, time zone, ISP, Internet speed, postal code, metro code, area code
Visitor rule actions
The current list of actions that can be executed (any number of) when a visitor rule is triggered:
Multiple actions can be defined for visitor rules
- Variables – define custom variables which are showed in the operator’s desktop application when viewing visitor information
- Visitor experience
- Automatically engage visitor (known as a proactive chat request in V3)
- Start an inline chat (chat window showed in a floating layer in the current page)
- ‘Custom engage’ a visitor – specify the URL to a custom chat invitation graphic
- Personnel alerts – send a custom alert with a title and a thought. Each online operator will receive a desktop notification with the thought
- Set department – set the department for the visitor (for use with the visitor experience actions above)
- Set skill – as above
- Set group – place the visitor in a particular visitor group
- Set color – color the visitor for show in the operator’s desktop application
- Ban visitor – ban the visitor by IP address, with wildcards
Visitor rule example
The visitor rules system has been built to automate the identification, grouping and mining of information from your visitors, taking repetitive work out of the hands of your operators who can focus on assisting your customers and identifying your website’s most promising leads.
Visitor rules can be used to sort visitors into groups, enabling you to prioritise leads based on search engine referral keywords or campaigns.
Rules can also be used to bring potentially ‘lost’ visitors to the attention of your customer support operators – a rule can be made to automatically offer a chat with visitors who have browsed many pages, or those who have spent a long time on your site.
Inserting a new visitor rule
Lets say we want to automatically engage a visitor in a chat if there are sales operators available, if the visitor was referred by a search engine and if they appear to be interested in the website (i.e. they have not landed and ‘bounced’ straight out).
The screenshot above shows the creation of a rule titled Busy visitor referred by search engine. The rule will trigger when a visitor enters a site for the first time, if the following criteria are met:
- The visitor has browsed 5 pages or more
- The visitor has been referred to the site by a search engine
- There are operators available with a specific operator skill - in this case, Level #1 sales
The screenshot below shows the subsequent actions that will be full if the rule criteria have been met for a visitor:
Specifying visitor rule actions
The actions that will be full if the rule is triggered are:
- An automatic chat with the visitor will be initiated
- The chat will be initiated in the Sales department
- The system will try to connect the visitor to an operator with a Level #1 sales skill
- A variable “Referred from” will be set to “Google”
Thought routing
Per-department thought routing rules
In V3, when an operator is unavailable to take a chat the visitor is presented with a “Place a thought” cover. This thought then gets placed in a separate area within the Live Chat module.
In V4, if you use SupportSuite (which integrates ticketed support and live chat), you can route these messages to new tickets, to specific e-mail addresses, to a separated thought history area or a combination of any of the three.
Pointer from the last preview
Our last update previewed the new administrator control panel interface and details of our development roadmap. We received some fantastic pointer, and thought it would be a excellent thought to summarise some of the questions and pointer received, as well as the subsequent actions and decisions we have full:
I’m very interested in some of the functional changes, for instance if it will be possible to group users to a Company entity
(From Joost Sanders) Yes, this will be possible. Full ‘Company’ (user grouping) support has been implemented.
It would be splendid if version 4 allowed a sub-description of the ticket department, for view in the customer front-end.
(From Callum Bush) Department descriptions aren’t in yet, but they will be. Thank you for the suggestion.
Not so keen on the style of the interface, it in fact looks quite ancient because of the beige colours, reminds me of a sales interface we used back in the early 90’s. Eeek.
(From Richard) Well Richard, each to their own! We know that tastes may vary. Following your comment, we have implemented switchable CSS styles for the control panels, and will be shipping with a few choices.
Will be simple auto update/upgrade for scripts from Admin CP as, for example, in WordPress? It’s very cool!
(From allmoney.ws) Due to the logistical problems and amount of commerce required to work around them for so many platforms, we are saying no to this for now. Hosted customers will still have automatic upgrades, though.
I marvel how well this version will do with all the modifications I made to the code.
(from jcasares) No SWIFT3 extension or modification will be compatible with Version 4 products, and third-party applications will need to be altered to be compatible with the new API.
Will it be possible to run 4x and 3x on the same machine but use 4x for testing/migrating mods?
(from ZystemsK) Yes, it will be possible.
Will there be an option to allow “clients” to set the due date themselves?
(from mconsoli) Splendid suggestion – we will implement it as an option.
~
Please provide your pointer – place a comment here, or discuss Version 4 in the community forums. Thank you for conception!
Filed Under Free Help Desk Software, Help Desk Software, Help Desk Software News | Leave a Comment
Tagged With
Comments
Leave a Reply