Chat

Chatbots

Chatbots can be configured here to answer the incoming live chats first. The chatbot can change the category of the chat, add routing tags, and queue the chat for processing by an agent. The agent who then accepts the chat will subsequently see the customer’s complete dialogue with the chatbot from that chat session.

List

You get an overview of all chatbots of your own tenants in the list view. Clicking on New opens the editing dialog which can be used to create a new chatbot. If a chatbot is selected via checkbox, it can be deleted or activated or deactivated via More Actions.

Editing dialog

General tab

• Name (required): Unique name for the chatbot
• Description: Description of the chatbot
• Tenant: “All” or specific tenant

Integration tab

• Nickname of chatbot:
  The nickname of the chatbot defines the name which is used for chat messages sent by the chatbot. If no nickname is defined the system setting or default nickname will be used. (“Chatbot” or globally definined name) is used as a nickname.
• URL to novomind iAGENT Help REST API (required):
  Enter the URL to your novomind iAGENT Help REST API here. The URL should be in the following format: https://<URL to your novomind iAGENT Help System>/nmIQ/api/rest
• Name of agent in the knowledge base:
  Here you can enter the name of an agent in the knowledge base that should be explicitly addressed. This is an optional setting. If you do not complete this setting, the default agent will be used.
• Close inactive chats afterClose inactive chats after:
  
  Here you are able to define the time after which inactive chatbot chats should be automatically closed. In this context a chatbot chat is referred to as inactive if the customer doesn’t respond anymore in a dialogue.
• Route again to agents within:
  If the customer writes again after completing a chat, he/she will be routed back to an agent. This setting allows you to specify when new customer messages should be accepted again by the chatbot.
• Route to agent if chatbot is offline after:
  If the chatbot is no longer reachable, internally the customer message will be sent again to the chatbot. With this setting, you will be able to determine how long delivery attempts should be made until the chat is finally submitted to the queue for manual edit.
• Return chat to chatbot if no agent accepts the chat after:
  If no agent accepts the chat which was handed over by the chatbot within the specified timeframe, the chat will be returned to the chatbot.
• Enable typing events:
  Enables the chatbot to automatically send typing events to the customer. Enabling this option will cause the chatbot replies to be delayed by 1-2 seconds.

Categories tab

Categories can be associated with the chatbots here. Categories can only be assigned if they have been selected for the Chat in the category setting and match the chatbot’s tenants (if the chatbot has tenant “M”, only categories from tenant “M” or without tenant can be assigned; if the chatbot has tenant “All”, the categories of all tenants can be assigned). Under the routing tab in the category settings, a chatbot can be selected for the corresponding category.

Frontend

Depending on how it has been implemented a chat frontend provides either graphical or textual feedback to the user on certain events and states. Typical examples of such events or states are a broken network connection or temporary unavailability of a specific chat agent. Given appropriate system and frontend configuration, this textual and/or graphical user feedback can be edited here. Beside of that, frontend configurations have to exist for proactivity rules. This is only applicable when you have more than one chat frontend!

List

The list shows the following columns. A filter for each column can be activated through the filter button on the right-hand side:

• Name:
  Name of the chat frontend. The name must match the variable frontendID.
• Tenant:
  Tenant that is associated to this frontend. This information for overviewing purposes and for the privilege separation of the access rights of several tenant only. Example: Supervisors of tenant A don’t see the chat frontends of tenant B.

After selecting or entering a search criterion, the search will be started immediately. Afterwards, the list may be re-sorted through a click on the header. A following click on the currently sorted header switches the sorting direction of this column.

Through the preceding checkboxes, multiple entries may be selected to be processed altogether. Buttons appear disabled when their functionality is not implemented / does not make sense for multiple selected entries.
The checkbox in the header selects all displayed entries at once.

A click on an entry opens the editing dialogue.

Editing dialog

General tab

On this tab, general information for the chat frontend can be seen/changed

• Name:
  Name of the chat frontend. It must match the URL parameter frontendID when calling the frontend.
• Use new chat frontend:
  If using the new chat frontend, this check mark must be selected. This enables the configuration of the new chat frontend under the following tabs.
  As soon as the option Use new chat frontend is set for an old chat frontend, values for configurations and texts are written to a file in the installation directory. Going back to an old chat frontend would then only be possible by manually deleting these entries from this file.
  Depending on the selected frontend, the following tabs will change as well. With the old frontend, in addition to the General tab, the tabs Templates and Messages are available.
• Tenant:
  Tenant that is associated to this frontend. This information for overviewing purposes and for the privilege separation of the access rights of several tenant only. Example: Supervisors of tenant A don’t see the chat frontends of tenant B.

Configuration tab

Among other things, the color of various elements in the frontend can also be determined here. All colors can be defined either by means of six-digit hexadecimal color definition or by selection in the color spectrum after clicking on the color block next to the hexadecimal coding.

• Logo URL:
  URL to an image displayed at the top of the chat frontend page
• LOGO ALT-Attribut:
  Alternative text that is displayed when the logo image cannot be displayed.
• Favicon URL:
  URL to an image to be used as a favicon. A favicon is displayed e.g. next to the title on browser tabs, in bookmark lists, or on the home page of smartphones.
• Customer textinput:
  Defines whether the customer input field should be single-line or multi-line. In single-line mode messages can be send by pressing the enter button. Sending in multi-line can only be triggered by a mouse click.
• Agent avatar:
  Defines whether and which avatar a customer should see next to the agent’s text (the agent does not see their own avatar). With Standard, a preset image is used (); for Own, a URL to a custom image can be specified in the following line.
• Agent avatar URL:
  URL to an image that the customer sees as an avatar for the agent (deactivated if Standard or None is set in the previous line).
• Chat queue info:
  While transfering the chat to an agent, queue information like position and estimated waiting time can be displayed.
  
• Chat history per email:
  After the ending a chat, the customer has the option of having the chat history displayed and then sent as an email.
  Further information about further necessary configurations here.
  
• Use welcome screen:
  
  If the welcome screen is deactivated, the chat starts directly. Deactivation is only possible if only one category is assigned to the frontend.
  If the welcome screen is deactivated, the chat starts directly. Deactivation is only possible if only one category is assigned to the frontend.

  If the welcome screen is deactivated, the chat starts directly. Deactivation is only possible if only one category is assigned to the frontend.

  If the welcome screen is deactivated, the chat starts directly. Deactivation is only possible if only one category is assigned to the frontend.

  If the welcome screen is deactivated, the chat starts directly. Deactivation is only possible if only one category is assigned to the frontend.

  If the welcome screen is deactivated, the chat starts directly. Deactivation is only possible if only one category is assigned to the frontend.
• Privacy policy must be accepted:
  The property determines if the privacy policy has to be accepted in order to start a chat. If the welcome screen is deactivated, this property will be ignored and interpreted as deactivated.
  
• Text color:
  Color of most texts (not customer or agent messages).
  
• Primary color:
  The primary color is used for all main components like buttons or the background of customer messages
• Primary text color:
  Text color for elements with primary color as background
  
• Secondary color:
  Non primary buttons and the agent messages will be displayed in the secondary color.
  
• Secondary text color:
  Text color for elements with secondary color as background
• Link text color:
• IntelliLink text color:
• Highlightcolor:
  This color is used to mark mandatory selections or input fields (e.g on welcome page).
  
• Font Family:
  Font of all texts that appear in the frontend.
  

Categories tab

Here can be defined which categories can be selected when starting a chat. If only one category is stored, the customer will not have the option to select when starting the chat.

The list shows all available categories, it can be narrowed down after displaying the Filter (button on the right above the list).

Texts tab

Texts can be defined here for different languages (selectable languages are stored in the Routing.conf file), those concern e.g. the labeling of buttons or info texts that are displayed before, during or after the chat.

One language can be defined as default. The default language will be used if the frontend call of the browser (with the parameter language) does not specify a language.

Each text has a unique key that is displayed in the respective help text. This key can be used to reference a text module in another text module. For example, with @:company_name, the company name can also be used in the welcome text.

Default values for the text modules are only stored in the languages Arabic, English and German. If other languages are stored in the Routing.conf, they get the contents of the default language and must be translated manually.

Templates tab (old frontend)

Template and message names are entered as keys in this tab, in exactly the same way they shall be referenced in the chat frontend code. The key’s corresponding value is the code for the template or the text message, respectively.

Your frontend developer will know which states, templates and messages your chat frontend supports.

Click on the New button to create a new entry.

List

The list shows the following columns. A filter for each column can be activated through the filter button on the right-hand side:

• Key:
  Key of your chat frontend element that shall be overwritten
• Value:
  Text that shall overwrite the existing frontend value of the element with the given key

After selecting or entering a search criterion, the search will be started immediately. Afterwards, the list may be re-sorted through a click on the header. A following click on the currently sorted header switches the sorting direction of this column.

Through the preceding checkboxes, multiple entries may be selected to be processed altogether. Buttons appear disabled when their functionality is not implemented / does not make sense for multiple selected entries. The checkbox in the header selects all displayed entries at once.

The keys of entries cannot be changed anymore. Its value however may be changed through a click on the displayed value.

If you need further support, please contact your novomind project manager.

Messages tab (old frontend)

Template and message names are entered as “keys” in this tab, in exactly the same way they shall be referenced in the chat frontend code. The key’s corresponding “value” is the code for the template or the text message, respectively.

Your frontend developer will know which states, templates and messages your chat frontend supports.

Click on the New button to create a new entry.

List

The list shows the following columns. A filter for each column can be activated through the filter button on the right-hand side:

• Key:
  Key of the text message of your chat frontend that shall be overwritten
• Value:
  Text that shall overwrite the existing message with the given key

After selecting or entering a search criterion, the search will be started immediately. Afterwards, the list may be re-sorted through a click on the header. A following click on the currently sorted header switches the sorting direction of this column.

Through the preceding checkboxes, multiple entries may be selected to be processed altogether. Buttons appear disabled when their functionality is not implemented / does not make sense for multiple selected entries. The checkbox in the header selects all displayed entries at once.

The keys of entries cannot be changed anymore. Its value however may be changed through a click on the displayed value.

If you need further support, please contact your novomind project manager.

Proactivity rules

Visitors to the webpage can be encouraged to chat by proactively displaying a chat offer. The chat offer may be in form of a floating flag on the left-hand side of the screen. The user is offered to start the chat through a chat start button. The conditions when this chat offer floats into the customers sight is configurable through this proactivity rules.

List

The list shows the following columns. A filter for each column can be activated through the filter button on the right-hand side.

• Name:
  Name of the proactivity rule
• Frontend:
  Frontend, for which this proacitvity rule will be applied
  The frontend receives its id through its source code (further information in chapter Frontend)
• First condition:
  First condition of this proactivity rule. It is possible to combine several conditions in one proactivity rule.
• Overall conditions:
  Count of all conditions of this proactivity rule
• Action:
  HTML or JavaScript Code that will be executed when all conditions of this proactivity rule are matching. This code contains the Chat start button.

After selecting or entering a search criterion, the search will be started immediately.

Afterwards, the list may be re-sorted through a click on the header. A following click on the currently sorted header switches the sorting direction of this column.

Through the preceding checkboxes, multiple entries may be selected to be processed altogether. Buttons appear disabled when their functionality is not implemented / does not make sense for multiple selected entries.
The checkbox in the header selects all displayed entries at once.

A click on an entry opens the edit dialogue.

Generate Code:

When exactly one entry in the list is selected, the “Generate Code” button will be enabled. Through a click on this button, a dialogue appears to enter the URL to the chat REST API on the Chat-Frontendserver.

Example URL:

https://chatserver.yourdomainname.com/iChatClient/JSPClient.jsp

A click on the Button Generate Code on this dialogue fills a text field with the code that has to be injected into the websites, on which the chat offer shall be integrated. To help you copying this code, a Mark button is below the text field. It selects all the text so that you only have to copy the selected text into your clipboard though CTRL-C or the context menu.

Editing dialog

General tab

The following information can be seen / edited on this dialogue:

• Name:
  Name of the proactivity rule
• Frontend:
  Frontend, for which this proacitvity rule will be applied
  The frontend receives its id through its source code (further information in chapter Frontend)
• Action:
  HTML or JavaScript Code that will be executed when all conditions of this proactivity rule are matching. This code contains the Chat start button.

Example for HTML Actioncode (please note that the stylesheets must be defined on the target site where this code snippet will be integrated!):

<div id="chat_start_box">

 <div id="chat_start_content">

  <p>Any questions?<br/>We may help you out!<br/><br/>Start a Live-Chat with us.</p>

 </div>

 <div id="chat_start_button">

  <a href="#" onclick="window.open('https://chat.domain.com/chatRest/frontend?frontendid=myFrontend&language=en', '_blank', 'dependent=yes,height=660,width=525,location=no,menubar=no,status=no,toolbar=no');return false;">

   Start Chat

  </a>

 </div>

</div>

Conditions tab

It’s possible to define multiple conditions for one proactivity rule. All of them must be met in order for a proactivity rule to be executed. The sequence of the rules can be modified via the arrow buttons in the condition list entries.

Conditions involving requests to the iAGENT system (such as “Chat Available” or Javascript calls) should be checked for last in order to avoid unnecessary system request.

The list shows all the conditions that are defined for this proactivity rule in their execution order from top to bottom.

Conditions consist of a type (predefined events / properties) that are compared to an entered value.

Add a condition

New conditions can be added through clicking on the button New. A small dialogue appears, where the type of the condition has to be chosen. The types are:

• Daytime:
  Here, a time can be determined within which a chat service is available.
  Parameters:
  – From: time of day (e.g. 00:00)
  – To: time of day (e.g. 24:00).
  
  
• Day of week:
  This rule matches if one of the given days is the actual day.
  Parameters:
  – Day of week: The days of the week on which the chat will be offered.
  
  
• URL match:
  Is met if the user is located on one of the listed URLs. The wildcard (*) also permits to specify partial URLs.
  Parameters:
  – URL: the URLs that should match the user location
  
  
• Referrer Match:
  Is met if the user has been referred from one of the listed URLs. The wildcard (*) also permits to specify partial URLs.
  Parameters:
  – URL: The URL the user has been referred from
  
  
• Time Since Visit:
  Is met if the user has dwelled on the frontend domain for longer than the specified threshold time.
  Parameters:
  – Seconds: the time period that has to be passed to fulfill the condition.
  
  
• Time Since Load:
  Is met if the user has dwelled on the frontend domain for longer than the specified threshold time without a page reload (e.g., to navigate to a subdirectory).
  Parameters:
  – Seconds: the time period that has to be passed to fulfill the condition
  
  
• Chat Available:
  Is met if a chat agent from one of the specified categories is available. Availability will be checked for in time intervals specified (in seconds) under “Retest”
  Parameters:
  – Chat: The chat category (internal name)
  – Retest: Recheck interval in seconds.
  
  
• Check JS-Variable:
  Is met if value of a given Javascript variable meets the conditions specified here. The check ends after the time interval specified here (in seconds). Entries all are OR-joined.
  Parameters:
  – Variable: A JavaScript Variable.
  – Operator: Operator
  – Condition: The value, the content of the external JavaScript variable will be compared with.
  – Timeout: Time threshold in seconds, after which the check will be aborted.
  
  
• Check JS-Function:
  Is met if the return value of the specified Javascript function evaluates to Boolean “true”.
  Parameters:
  – Function: A JavaScript function.
  – Parameter: Function Parameters
  – Timeout: The time after the comparison will be ended.
  
  
• Microphone available:
  This rule matches when the customer has a microphone connected to their computer.
  Parameters:
  – Default behaviour: In case a microphone can’t be detected because of the used browser, you can choose the default behavior here. If ‘true’ is choosen it’ll be assumed that the user has a microphone connected.
  
  
• Camera available
  This rule matches when the customer has a webcam connected to their computer.
  Parameters:
  – Default behaviour: In case a camera can’t be detected because of the used browser, you can choose the default behavior here. If ‘true’ is choosen it’ll be assumed that the user has a camera connected.
  
  
• Number of visits:
  Here, the number of visits can be specified (the count will increase if the time span between two visits is more than 2 hours).
  Parameters:
  – TO: Up to a number of visits a chat is being offered.
  
  
• New visitor:
  This function determines if the user visits the site for the first time.
  
  
• Recurring Visitor:
  This rule matches if the user already visited the site and thus is a recurring user.
  
  
• Number of chat offers:
  This function determines how often a chat will be offered to visitors.
  Parameters:
  – Number: How often should a chat offered.
  
  
• WebRTC supported:
  This rule matches if the customer has a WebRTC compatible browser with the WebRTC plugin installed.

The changes on the single conditions must be saved through the Save button on top of the dialogue.