Welcome to the second in a series 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 using logic, rules and automation.

Before we jump in, here is an overview of the new functionality we are going to look at:

• Visitor groups - logical groups of site visitors. Visitors can be placed in groups using 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 – logical groupings of operators (staff users), based on ‘Skills’. Skills can be used to logically group operators according to their specialities, or any other label, 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.
• Message routing - per-department routing options for the “Leave a message” messages left by visitors when an operator is unavailable.

Visitor groups

Creating a new visitor group

A visitor group is a logical grouping of visitors to your website. Visitors can be manually (using the live chat operator’s desktop application) and automatically (using 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 creating the group, as shown in the screenshot above.

We think the visitor grouping feature will be especially important 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 label/group operators (staff 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 decision process for your first point-of-contact operators quicker and easier. 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 assistance with an installation problem involving the Microsoft Windows platform, your first point-of-contact 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 using automated visitor rules (described below). This means that that system can automatically make the ‘best operator for the job’ decision based on the visitor’s footprints, 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.

Using 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 (staff users) to a skill

Visitor rules

There are two types of visitor rules:

1. 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
2. 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 building visitor rules (if you have suggestions, leave 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 staff, online staff with skill, online staff assigned to department
• Time – time spent on site
• Location (GeoIP) – latitude, longitude, country, city, region, organization, 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 displayed 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 displayed in a floating layer in the current page)
  • ‘Custom engage’ a visitor – specify the URL to a custom chat invitation graphic
• Staff alerts – send a custom alert with a title and a message. Each online operator will receive a desktop notification with the message
• 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 display 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 created 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 taken if the rule criteria have been met for a visitor:

Specifying visitor rule actions

The actions that will be taken 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”

Message routing

Per-department message routing rules

In V3, when an operator is unavailable to take a chat the visitor is presented with a “Leave a message” screen. This message 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 message history area or a combination of any of the three.

Feedback from the last preview

Our last update previewed the new administrator control panel interface and details of our development roadmap. We received some fantastic feedback, and thought it would be a good idea to summarise some of the questions and feedback received, as well as the subsequent actions and decisions we have taken:

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 great 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 actually looks quite old 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 understand 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 engineering 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 wonder 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) Great suggestion – we will implement it as an option.

~

Please provide your feedback – leave a comment here, or discuss Version 4 in the community forums. Thank you for reading!