How to deploy Live Chat in 3 Steps

Live Chat is a native channel of Oracle Service Cloud (OSvC), and one that is more and more in vogue. Text-enabled, real-time, conversations are the preferred way for many customers when engaging with companies.

One of the most popular ways of deploying OSvC Live Chat is placing the Conditional Chat Link syndicated widget in the company’s website. This is done in 3 simple steps:

Step 1 – Placed this snippet of code above any individual syndicated widget script. For performance reasons the recommended best practice is to place the code just before the closing tag and above any syndicated widget instance tags.

< script type=”text/javascript” src=”//yourdomain.widget.custhelp.com/euf/rightnow/RightNow.Client.js” >< /script >

Step 2 – This snippet of code is specific to the syndicated widget instance. For performance reasons the recommended best practice is to place this snippet of code just before the closing tag.

< script type=”text/javascript” >
RightNow.Client.Controller.addComponent(
{
container_element_id: “myChatLinkContainer”,
info_element_id: “myChatLinkInfo”,
link_element_id: “myChatLink”,
instance_id: “sccl_0”,
module: “ConditionalChatLink”,
type: 7
},
“//yourdomain.widget.custhelp.com/ci/ws/get”
);
< /script >

Step 3 – Place this snippet of code on your page(s) wherever you would like the Conditional Chat Link syndicated widget to appear.

< div id=”myChatLinkContainer” >
< div id=”myChatLink” >
< div id=”myChatLinkInfo” >
< /div >
< /div >
< /div >

Once you place the above code in your company’s website page(s) you should be able to see the Conditional Chat Link syndicated widget display.

But to deliver a good customer experience, you need to manage customer’s expectations, therefore you don’t want to have the Conditional Chat Link syndicated widget available in your website if there isn’t anyone available to respond.

The Conditional Chat Link syndicated widget has various configuration settings, and some of the most used are:

min_sessions_avail – Minimum number of open agent sessions that must be available in order for the Conditional Chat Link to be actionable.
wait_threshold – Maximum wait time where the customer should still be allowed to launch a chat.

Note: Please notice that min_sessions_avail will always override wait_threshold.

So, for example, if you want to set min_sessions_avail to 2 and wait_threshold to 5 mins (or 300 seconds), you would need to set it on the syndicated widget and OSvC would generate new code adding the following lines to step 2:

min_sessions_avail: 2,
wait_threshold: 300,

In this scenario, where the Conditional Chat Link syndicated widget is unavailable, it is also useful to configure the setting label_unavailable_busy_template which is the label to be displayed when chat is unavailable due to agent session (Minimum Sessions Available) or wait time conditions (Wait Threshold).

By default, label_unavailable_busy_template is “All agents are busy“ but you might want to configure it to something more appropriate.

If you would like to know more information about the behaviour of the Conditional Chat Link syndicated widget, you can use the Conditional Link Stats report, which is used to display Conditional Chat Link syndicated widget statistics.

This report is out-of-the-box and displays the number of times the widget was loaded, the number of times the widget was active, the number of times the widget was clicked, and the respective percentages of each.

How to check where Chat is coming from?

This is one of the requirements that many companies using Oracle Service Cloud (OSvC), and indeed other platforms, have.

There are many live chat touch-points across the website, in different pages, and it would be valuable to know where are customers coming from.

Simon Kilgarriff, ex-RightNow and Oracle employee, now working for Capgemini, shares in this video one of the ways to achieve it.

This solution requires that companies license and implement the Engagement Engine (EE), a legacy ATG solution that Oracle integrated into OSvC a while ago.

It is a great tip for those who have similar setups. However, if you don’t have or need EE (sometimes it is a sledge-hammer to crack a nut), there are always alternatives.

Knowledge Base Search – How does it work?

This is a question that several of our customers have asked us, when they start to build their own knowledge base of answers, to enable customer web self-service.

The knowledge base search (knowledge foundation) is not a simple mechanism. That is why it is so powerful, intelligent, dynamic and self-learning.

A picture is worth a thousand words, so I decided to put together a diagram that depicts the process, and below leave you with a few definitions to be better understand the different components.

Weight

When a search is performed, each keyword and/or phrase entered by the customer is compared to the contents of the answers.

The Weight is a numerically calculated value, based on the number of occurrences, capitalisation, and location of a word. It is equal to the sum of the weights of all the matched words from the search.

The location of the word is important. It is ordered and weighed as per the diagram – e.g. words that match the Summary field will have higher weights than those that appear in the Answer field.

Computed Score

The Computed Score of an answer is usually the same as its Score, unless its Display Position is set to fix it at top/bottom. In that case, the Computed Score is calculated using the score of the answers located at the top or bottom of the list.

To better understand, if a new answer is created, and set with Display Position = “Fixed at the top”, once it is published, its Score will be zero, but the Computed Score will be larger than the highest score for all the published answers.

Score

The Score is a calculated value that ranks the order of answers, and indicates the usage of the answer, as well as how helpful that answer has been to customers. It is calculated based on the Solved Counts:

75% of the score is based on Solved Count, linked to customer usage
25% of the score is based on Solved Count, linked to agent usage

An answer with a large score indicates that several customers (and/or agents) have viewed that answer and that the answer was somehow useful to them.

Solved Count

The Solved Count collects information about the usefulness of answers in the Knowledge Base. Two types of data is gathered:

Implicit data – compiled by how customers select and view answers. If a customer views an answer, the solved count of the 1st answer is increased, but not as much as the 2nd viewed answer. In other words, the answer that the customer views last receives the largest solved count increase.
Explicit data – compiled by how customers rate individual answers – from the responses to the question “Is this answer helpful?”

Customer Portal: Staging your changes

After changing the Customer Portal pages in the development area, you can stage them to see how your changes will appear on the production site. Note that the staging area replicates the production site but the pages are not yet exposed to the customers.

Step 1: Click the Configuration button on the navigation pane.

Step 2: Double-click Customer Portal under Site Configuration.

Step 3: Select the interface you want to stage from the Interfaces column.

Step 4: On the ribbon, click the Stage button on the Customer Portal section.

The window displays a list of files that have been changed in the development area. By default, all new and edited files are selected to be copied to the staging area, and any files you have removed from the development pages have the Remove From Staging action.

Step 5: Edit the Actions if desired and click Next to continue.

Step 6: In the second tab Version Changes to the framework or widgets are displayed. Select Yes if you want to push any framework or widget version changes, and click Next to continue.

Step 7: In the third tab Select Configurations page set mapping differences are displayed. By default, No Action is selected for the listed page sets, but if you have disabled a page set, the action will be Remove From Staging. Click Next to continue.

Step 8: The fourth tab Stage summarizes the selections from the earlier pages of the staging process.

Step 9: Add a comment and click Stage button, to pass your changes from the development to the stage area.

Step 10: Confirm you want to stage changes by clicking Stage button on the confirmation pop up window.

Step 10: Wait whilst all the files changed are compiled and copied to the staging area

Step 11: Confirm that your staging process is complete with the message “Staging completed successfully“.

Now that you staged your changes, you are ready to Promote them to Production. This will be addressed in a another post.

Customer Portal: Edit pages usign WebDAV and Text Editor

As it was stated before, to create or customize the Customer Portal pages, you will need a WebDAV client to download/upload the files, and you will use a text editor to edit the files. This post shows how to do it.

Step 1: Download and install a WebDAV software. Oracle recommends Cyberduck.

Step 2: Run Cyberduck and open a new connection.

Step 3: Set up a connection to your Customer Portal:

If you input your RightNow Customer Portal site on the Server field, the URL and port should come automatically. Then un-tick the Anonymous Login check box, input your admin credentials and click Connect.

Step 4: Open the folders and sub-folders until you find the file you want to change (in this case we went to the home.php file by navigating to cp/customer/development/views/pages)

Step 5: Select the file you want to change, right-click and choose Download to save the file in your local machine.

Step 6: Open the downloaded file in a text editor, change it and save it.

Step 7: Go back to Cyberduck, right-click the file you want to update and choose Upload.

Step 8: To check your changes open a browser, navigate to your Customer Portal admin site (http://example.rightnowdemo.com/ci/admin) and click View Development Area.

Step 9: Make sure that the Customer Portal you are viewing has the Customer Portal Development Area sign on top.

Customer Portal: Basic config on Admin interface

Before getting started with the customization of the Customer Portal pages and widgets, some basic configuration is necessary on the administration interface.

Assign permissions to staff members

Permissions have to be given to the staff members. An Admin can grant the following types of permissions through a staff member’s profile:

CP Edit permission lets staff members with this profile access the Customer Portal Administration site and edit customer portal pages in the development area using WebDAV. Staff members with CP Edit permission, but not CP Stage or CP Promote permission, cannot access the Customer Portal editor on the administration interface. Nor can they access the Deploy tab on the Customer Portal Administration site.

CP Stage permission lets staff members copy the development files to the staging area. Staff members with CP Stage permission but not CP Promote permission will not have the Promote and Rollback buttons enabled on the Customer Portal editor on the administration interface.

CP Promote permission lets staff members promote the pages from the staging area to the production area where customers can view them.

Note: Staff members who have CP Stage permission automatically have CP Edit permission as well. Staff members with CP Promote permission automatically have CP Edit and CP Stage permissions.

To assign permissions for your customer portal:

Click the Configuration button on the navigation pane.
Double-click Profiles under Staff Management.
Double-click the profile you want to assign permissions to.
Click the Permissions button on the ribbon.
Give staff members the permissions (editing, staging, or promoting).

Define configuration settings

The Customer Portal gives complete flexibility in creating templates, pages, and widgets. However, other configuration must occur on the administration interface. Configuration settings are used to define common features of the Customer Portal.

Enabling the development area: MOD_CP_DEVELOPMENT_ENABLED must be enabled before any changes can be made to the development site. If this setting is not enabled it is not possible to make changes to the Customer Portal.

Click the Configuration button on the navigation pane.
Double-click Configuration Settings under Site Configuration.
To open a specific configuration setting, type its name in the Key field and click Search.
To display all configuration settings, click the Search button.
Type MOD_CP_DEVELOPMENT_ENABLED it in the Key field and click Search
In the row for the configuration setting, click the drop-down menu in the Value column and select Yes.

Now that you have enabled your development area, you can begin editing other configuration settings that affect your customer portal.

Modify settings for pages on the Customer Portal

Some other general configuration settings, accessed through the administration interface, control functionality. For example, these settings let you configure searches, including how search results are returned, whether suggested searches are enabled, and whether search text feedback is given to customers.

You can configure the following pages:

Answers page: Configuration options include answer solved count, search results, search-field weighting, suggested searches, search text feedback, the aliases word list, search priority words, and stop-words.
Answer details page: The configuration option for the answer details page is the privileged answers feature.
Ask a Question page: You can configure SmartAssistant suggested answers for the Ask a Question page as well as specify an expiration time during which the form must be submitted.
Your Account pages: Configuration options include disabling an email link to a customer’s incident in confirmation emails, letting customers see all incidents from their organization, defining the length of time an answer subscription stays active, and allowing duplicate email addresses.
Log In, Create an Account, and Change Password pages: You can configure the security and strength of customer passwords.

Customer Portal: Folder Structure

The Customer Portal incorporates an intuitive, easy-to-navigate file structure that lets you clearly identify the files you can edit. The main directory is called cp, and it includes the following main folders:

The core folder: All the non-editable Customer Portal files.

The customer folder: The Customer Portal files you can edit, including all pages and custom widget files used on your development site, as well as assets (CSS, images, and themes) and error pages.

The generated folder: All staged files and all files you have promoted to your production site.

The logs folder: Logs for each staging, promoting, and rollback operation.

Core Folder

The core folder contains all of the underlying Customer Portal code. You cannot add or remove files in this folder, nor can you edit any of the folder names or files.

assets: The core/assets folder contains all web assets used by the Customer Portal Administration site, organized in the following subfolders: debug-js, default, ejs, and images. The default subfolder contains the CSS, images, and themes for the pages, templates, and widgets in the reference implementation. You can always use these files to view and revert to the reference implementation.

framework: This folder is the core of the Customer Portal code base and contains all view files for the pages and templates. It also contains files and information about version changes, controllers, libraries, models, and utilities.

widgets: The widgets folder contains the files for all standard widgets, including controllers, views, CSS, images, logic, and YAML information files. You can use these files to the view the code for the standard widgets.

Customer Folder

The customer folder contains all the Customer Portal files you can modify, organized in the following subfolder structure.

assets: This folder contains the assets you can add, edit, and delete, including the subfolders css, images, and themes. Assets include all files for your customer portal that are not pages, templates, or widgets, including CSS, JavaScript, images, video, and other rich web media. You can add, remove, edit, and execute files and add subfolders to the assets folder. In addition to the css and images subfolders, the assets folder includes a default subfolder that contains default versions of the asset files provided in the reference implementation. If you make changes to any of the assets and then decide to revert to the standard assets, you can copy them from the default subfolder.

Important Note: With the exception of the themes subfolder, all other files in the assets folder are shared by development and production files. Even if you don’t stage and promote your development pages, changes you make may affect the look and function of your production pages. For example, if production pages call a file in the assets folder and you modify that file in the course of your development work, the change will be immediately visible to your customers.

Important Note: Although all other files in the /cp/customer/assets/ folder are shared between the production and development areas, files in the themes subfolder of /cp/customer/assets/ are used strictly by the development files. When you stage the develop- ment pages, these files are copied to a time-stamped folder in the staging directory and called from that folder. The themes you develop are kept in this isolated sandbox that cannot be accessed by production files. The themes are applied to your production site only when you promote the staged files into production.

development: The development folder is your working folder, containing all templates and pages to create and update your customer portal. It contains the following subfolders.

error: Contains three editable error pages and splash.html, which is a page displayed to customers when your site is being upgraded. You can edit the splash file to display whatever information you want.

Generated Folder

The generated folder contains two subfolders: production and staging, which mirror the structure of the /cp/customer/development subfolders. The staging subfolder contains the development files that you have staged through the CX Console or the Customer Portal Administration site. Your customers cannot see the files in the staging folder. The production subfolder contains the staged files that have been promoted into production. Those files are visible to your customers. Both subfolders also have a backup subfolder that contains the original source code from the previous staging and promoting activities. The staging folder includes a themes subfolder that is copied from your development site when you stage the development pages. These folders allow the rollback function. None of the files in the generated folder can be edited or deleted. Nor can you add any files.

The logs folder

The logs folder contains logs for every stage, promote, and rollback operation performed on your site as well as a log that documents changes made to Customer Portal files so you can see when and by whom the files were modified.

Customer Portal: File Structure and Page Sets

The Customer Portal is the company’s customer support interface, where customers can search for information, submit questions to the support team, request chat sessions or even ask the peer-to-peer community (if there is one) for help. Normally the Customer Portal is embedded on the company’s website.

The configuration of the Customer Portal is done by editing Templates, Pages, and Widgets which are part of the site. So it is important to understand the structure of the Customer Portal. Other Customer Portal configurations can be done through the Admin interface (aka Agent Desktop or Console).

Before going deeper on the Customer Portal stuff, it is important to keep in mind the following:

There is something called the reference implementation that is the set of default pages and files that make up the Customer Portal as it exists before you configure and customize it. There are two default reference implementations: one for the standard pages (desktop browsers) and one for display on mobile devices.

To create or customize the Customer Portal pages, you will need a WebDav client to download/upload the files, and you will use a text editor to edit the files.

To set up other functionalities – such as SmartAssistant and search options – you will use the Admin interface (aka Agent Desktop or Console)

Customer Portal File Structure

As stated before the templates, pages, widgets, and other assets used to create the Customer Portal are available through WebDAV.

The customer portal uses WebDAV to help you manage your website files. WebDAV offers a familiar file structure, easy uploading and downloading of multiple files, and file security through login access. After you set up a WebDAV connection to upload and download files, you can use any text editor you want to create and edit files for your customer portal, or you can use Adobe Dreamweaver, which uses its own WebDAV protocol for site management and configuration (Oracle recommends using Cyberduck for WebDAV access to Customer Portal files)

Important Note: You must enable MOD_CP_DEVELOPMENT_ENABLED before you can make changes to your development site. If you do not enable this setting, you cannot make changes to your customer portal and your customers will see the default reference implementation with no customization.

To view the Customer Portal files from the Customer Portal Administration site, using a URL:

In a web browser, type http://<your_site>/dav.
If you have not already logged on to the Customer Portal Administration site, enter your RightNow user name and password.
Click the cp link to display the folders.
Click the folder you want to display files for and continue drilling down through subfolders to display the file you want.
When you click an individual file name, it will open

Important Note: Although it is possible to edit files directly on the server, it is recommended downloading files to the local workstation, making changes locally, and then uploading them back to the server.

Page sets

The Customer Portal contains four sets of pages, each of which can be viewed from the Customer Portal Administration site.

Development files: These are the files to work with when you want to make changes to the Customer Portal. They cannot be seen by the customers until you stage and promote them. The page and template files are in the /cp/customer/development/views folder, and the custom widgets are in /cp/customer/development/widgets/custom.

Staging files: After editing the development pages, you can stage them, which means they are compiled and optimized to look and perform as they will on the production site. These files, located in /cp/generated/staging, are not editable, nor are they visible to the customers.

Production files: The production files, located in /cp/generated/production, have been promoted from the staging site and are visible to the customers.

Reference implementation files: These are the default, read-only files that make up the original customer portal reference implementation before you modify them. They are located in /cp/core/framework/views and /cp/core/widgets. If you’ve made changes to one of your development files that you don’t want to keep, you can revert to the original file by copying the original from its reference implementation folder and pasting it to the appropriate subfolder in /cp/customer/development, effectively overwriting your changes.

Custom Fields

Custom Fields are created in the knowledge base to allow the collection of business-specific information, to best meet the organization’s needs.

After being created, custom fields can be added to workspaces and scripts, be used as search filters in reports, or as audience filters in RightNow Marketing and RightNow Feedback.

When creating a custom field, Admins can specify whether it is visible and editable on the Agent Desktop and, for some custom fields, visible and available to gather details on the Customer Portal.

Admins can also specify a data type for the field, choose whether the field is required or not, and set a default value.

Text field data types allow you to create an input mask to require that information entered in the field matches a defined format.

When Admins add or edit custom fields, those modifications may be completed in real time or scheduled and performed in the background.

Custom field visibility

When adding custom fields, there are several visibility options. The visibility options define where and how custom fields are presented on the Agent Desktop and the Customer Portal. For example, you can make a contact custom field visible to staff members when adding an incident, but restrict their ability to edit it.

Custom fields with end-user visibility are displayed on the Customer Portal. If you display a custom field that is not editable by customers, it does not appear on the Ask a Question page. There are other ways to determine visibility on the Customer Portal, such as widgets and page code.

Answer, incident, contact, opportunity, organization, sales quotes, and tasks custom fields must also be added to the appropriate record’s workspace.

The Admin Edit visibility setting must be selected in order for a custom field to be available to add to workspaces and scripts. Once a custom field is added to a workspace or script, its visibility, read-only, and required attributes are determined by the properties set in the workspace or script.

Customer Portal: Proactive Chat triggers and definitions

Triggering chat offers on time

The default setting of 0 for the seconds attribute does not mean chats are offered immediately (after 0 seconds). Instead, it means chats will never be offered based on the amount of time customers spend on a page.

However, you might decide that the amount of time spent on a page is a valid trigger for offering a chat. If you want to offer customers a chat session if, for example, they have been on a page for 60 seconds without any activity, you can set the seconds attribute to trigger a chat at that time.

To trigger chat offers based on page time, add the seconds attribute to the code so it resembles the following.

<rn:widget path=”chat/ProactiveChat2″ seconds=”60″ />

Triggering chat offers on number of searches

The default setting of 0 for the searches attribute means that chats will never be offered based on the number of searches conducted by customers. You might decide to use number of searches as a trigger for offering a chat. If customers have conducted several searches without finding what they’re looking for, an invitation to chat might be useful.

To trigger chat offers based on number of searches, add the searches attribute to the code so it resembles the following.

<rn:widget path=”chat/ProactiveChat2″ searches=”3″ />

Triggering chat offers on profile attributes

The default null values for the profile_ attribute means that chats will never be offered based on customer profile information, but you might decide to set those values because you want to offer chats based on customer profile information.

When you configure the ProactiveChat2 widget to offer a chat based on customer profile information, you must define all three profile attributes for the widget: the profile item, the operator, and the value.

Let’s assume you want to offer a chat to all customers from ABC International, which has an organization ID of 81945. In that case, the widget code would resemble the following.

<rn:widget path=”chat/ProactiveChat2″ profile_item=”org_id” profile_operator=”equals” profile_value=”81945″ />

Triggering chat offers based on customer SLAs

If your organization requires SLAs in order for customers to chat with agents, you’ll want to verify that the customer has an SLA with available chat incidents before a chat session is offered. The profile attributes of the ProactiveChat2 widget can do that for you.

An SLA defines the total number of incidents a customer can submit, as well as specific numbers of chat, staff member, email, and web self-service incidents.

To check for chat SLAs prior to offering a chat, add the profile_item, profile_operator, and profile_value attributes to the code for the ProactiveChat2 widget. You will want to set the slac item to be greater than zero to be sure the customer has remaining chat incidents available on their SLA. You will probably also still want to include the seconds or searches attributes so the chat invitation is not immediately offered when the customer lands on the page with the widget. Your edited code will resemble the following.

<rn:widget path=”chat/ProactiveChat2″ seconds=”30″ profile_item=”slac” profile_operator=”greater than” profile_value=”0″ />

Editing the chat invitation

By default, the chat invitation says “A Chat Assistant is available to help. Would you like to start the session?” That message can be edited by editing an attribute of the ProactiveChat2 widget.

To edit the chat invitation, add the label_chat_question attribute to the code so that it resembles the following.

<rn:widget path=”chat/ProactiveChat2″ seconds=”30″ label_chat_question=”Staff members are available now. Would you like to chat with someone?” />

Changing the chat login page

When customers click Yes to accept the chat offered by the ProactiveChat2 widget, the Live Help page opens by default. You might want to direct customers to a different page instead.

To change the chat login page, add the chat_login_page attribute to the widget code so it resembles the following. Note that the path to the page must begin with /app/.

<rn:widget path=”chat/ProactiveChat2″ seconds=”30″ chat_login_page=”/app/chat/alternate_chat_launch_page” />

Defining how the chat login page opens

By default, the chat login page opens in a new window that lets you configure its height and width. You can also set the chat login page to open in the same window.

To change the size of the chat login window, add the chat_login_page_height and chat_login_page_width attributes to the widget code, defining the new values for height and width. Your code will resemble the following.

<rn:widget path=”chat/ProactiveChat2″ seconds=”30″ chat_login_page_height=”500″ chat_login_page_width=”600″ />

To open the chat login page in the same window, add the open_in_new_window attribute and set it to false so your code resembles the following.

<rn:widget path=”chat/ProactiveChat2″ seconds=”30″ open_in_new_window=”false” />

Determining product or category

By default, the ProactiveChat2 widget tries to determine the product or category by evaluating search information or product/category information from an answer or incident page. It “guesses” to the deepest level that can be found and then, if product/category information is available, that information is sent to the server to determine what queue the chat request should be routed to, whether agents are available for that queue, and what the estimated wait time is. You can disable this feature for either product, category, or both.

To disable product or category determination:

To prevent trying to determine what product should be used to route the chat session to a specific chat queue, set the guess_prod_val attribute to false. Your code will resemble the following.

<rn:widget path=”chat/ProactiveChat2″ seconds=”30″ guess_prod_val=”false” />

To prevent trying to determine what category should be used to route the chat session to a specific chat queue, set the guess_cat_val attribute to false. Your code will resemble the following.

<rn:widget path=”chat/ProactiveChat2″ seconds=”30″ guess_cat_val=”false” />

Defining the minimum number of agents

If the seconds, searches, or profile attributes of the chat widget have been met, an AJAX request is made to the server, which sends back the number of available agents. If you have defined the minimum number of agents required to offer a chat session that value will be compared to the number returned from the chat server. If the number of available agents is greater than or equal to the number you defined in the min_agents_avail attribute, the chat is offered to the customer.

To define the minimum number of agents, add the min_agents_avail attribute to the widget code so it resembles the following.

<rn:widget path=”chat/ProactiveChat2″ seconds=”30″ min_avail_agents=”2″ />

Defining the maximum wait time

If the seconds, searches, or profile attributes of the chat widget have been met, an AJAX request is made to the server, which sends back the wait time for a chat session. If you have defined the maximum time the customer will have to wait in a queue, that value will be compared to the number returned from the chat server. If the wait time is less than the value you defined for the wait_threshold attribute, the chat is offered to the customer.

To define the maximum wait time, add the wait_threshold attribute to the widget code so it resembles the following. Note that the wait time value is measured in seconds.

<rn:widget path=”chat/ProactiveChat2″ seconds=”30″ wait_threshold=”60″ />

Note: It is recommended that you set min_agents_avail to 0 when you set the maximum wait time.

Triggering a chat offer by an event

If you want to trigger chat offers only when a specific event occurs, you must first create an event called evt_customProactiveInitialization using custom code. Then set the initiate_by_event attribute of the ProactiveChat2 widget to true. This tells the widget’s logic file to listen for the event before triggering a chat offer.

Note: For specific information about defining evt_customProactiveInitialization, refer to the initiate_by_event attribute definition on the Customer Portal Administration site at http://<your_site>/ci/tags/widgets/standard/chat/ProactiveChat2.