Proactive Chat Deployment Best Practices
Note: This Article Applies To Moxie Channels NetAgent all versions. (Proactive Chat)
Deployment Preparation
Due to ease of configuration of Proactive Workflows and the potential impact they can have on the customer experience on your website, it is important to plan and test changes prior to deployment in a production environment. The following considerations should to be made prior to deploying the proactive code snippet on your production websites:
- Website Traffic
- Monitoring Purpose for Selected Web Page
- Analysis of the Default Behaviour of the Proactive Image on the Monitored Web Page
- Documentation of Proactive Chat Workflows
Website Traffic
What is your website traffic to this page? Specifically how many concurrent users do you have visiting that page at any given time? Each proactive server can handle 2,000 monitored visitors and approximately 3,000 unmonitored each, for a total site traffic of 5,000 visitors per proactive server. To ensure the system does not try to monitor more than the recommended limit of 2,000, set the Monitoring limit on the Proactive Settings page. Setting the time-out period will also prevent monitoring customers that have walked away from their customers, but left the browser open.
Monitoring Purpose for Selected Web Page
Will this page be used to launch an invitation or is it used for tracking purposes? Many pages may only be used to track if a visitor visited that page or so that the page visit counts toward their total page count. Having this information documented is useful for testing as testers know what to expect when visiting this page. If the page is only meant for tracking and they receive a proactive invite, they know a rule has been configured incorrectly.
Analysis of the Default Behaviour of the Proactive Image on the Monitored Web Page
How will the default behaviour of the proactive image work with the page? Will it cover important information that could annoy a client, or will capture the client’s attention? There are many considerations and if needed, additional JavaScript variables can be added to the page so that page launches the proactive invitation differently than the default method. Below is a sample script for setting page specific initiation settings.
<SCRIPT>
var talInvTop = 300; // Top position in Pixel, where invitation starts
var talInvLeft = 300; // Left position in Pixel, where invitation starts
var talSlidingOpt = 2; // Type of slide, 0 for none, 1 for horizontal, 2 for vertical
var talStopLoc = 600; // Position where image should stop sliding
var talSlideDist = 3; // how far pixel should slide per interval, controls speed of slide
</SCRIPT>
If a more customized solution is desired, please contact your Moxie Software Account Manager to arrange for help from the Moxie Software Professional Services team.
Documentation of Proactive Chat Workflows
Once the list of pages to tag have been determined and documented, the workflows can be documented. When documenting workflows it is important to capture all details required to configure the workflow and note the purpose of the workflow with a more in-depth description than what is provide in the workflow description. The purpose may seem obvious now, but may not be so clear a year from now or to somebody else that may take over management of the workflows.
Items to note when defining a rule include but are not limited to the following:
-
Rule Type – Lands on page, time based, enters site, etc.
-
Rule Number – This is important when ordering the pages within the workflow, each workflow type has a unique order
-
Rule Name – Should note the business group that created the rule, as well as a unique identifier of the rule.
-
Rule Description – Unique and detailed description of the rule
-
Rule Criteria – Summary of conditions and actions of rule. This should be a multi-line list of all conditions to use and should specifically note which ‘Join’ operator (AND/OR) to use and if condition groups are needed. Rules should use a Current Page URL condition to ensure the rule only fires on a specific page, not on any tagged page.
-
Action – What does the rule do, invitation, agent alert, set value, etc. Use multiple lines if multiple actions are to be taken.
-
Notes or Purpose – What is the benefit or purpose of the rule? Does it add volume, target specific types of clients, etc?
-
Portal Information – If using an invitation be sure to define which Portal to use. Note: A master list of Portals, Portal Styles and Service Lines used by Proactive Chat should be documented as well.
Other fields to consider:
-
Sales value target
-
Lead Type – Document if you want to set lead types for visitors
The attached spreadsheet can be used to store all of the above information. The spreadsheet contains three tabs:
-
Portals – This is a summary of the Portals to be used by Proactive and their specific settings.
-
Proactive Rules – A complete list of workflows by type, all fields noted above are listed
-
Proactive Track Only – A list of URLs to be used for tracking purposes only and a brief description of their purpose.
Roll out
Once the workbook has been filled out with details of what is to be implemented, the configuration and testing can begin. It is recommended to use a test or staging CIM environment to deploy proactive rules pointing to a test or staging website. This way testing of the rules and regression testing of the website does not have the potential to affect customers. The test or staging website should be tagged with a Proactive code snippet that points to the CIM staging environment, this can easily be swapped out with the production URL upon final deployment. Once the pages are tagged, browsing to the tagged pages should create a session visible in the proactive monitor. If production site volume is high, Customer monitoring should be disabled, so testing in a staging environment allows monitoring to be enabled and to track a client as soon as they enter the site instead of only after they’ve been pushed an invitation. Once you are able to confirm you see your session in the proactive monitor build the rules as defined in the Proactive workbook. Update the workbook as you make changes to the actual rule to ensure they stay in sync.
Once testing of the rules is complete a brief regression of the web pages can be conducted to ensure the Proactive JavaScript does not conflict with any JavaScript on the website.
When testing rules with OR condition joins, be sure to test the conditions individually to ensure you don’t get an invite or alert when you shouldn’t. Proactive tracking only pages should also be tested to ensure they don’t trigger invites, but do add entries to the customer’s history in the Proactive Monitor.
Deployment to production should be handled by production administrators. These administrators should ensure that the page tags are added to the website with the correct proactive domain name before deploying the rules. For rule creation they should either use the Proactive workbook, or copy and paste details of the rules from the CIM Staging Administrator. This method allows the CIM Administrator to not have in-depth knowledge of how to configure the rules as they are just copying the details from one system to another or using a workbook which has all details noted. Once configuration is complete the business can do their final acceptance tests in production.
If you have additional questions, please contact our Support group at 877-373-7848 (option 2) or via email at cimsupport@moxiesoft.com.
