Users Auto Responses Timers Routing
Agent UI Roles Queues Contact Points
Web Chat Stop List Management Webhooks Security
Usage Conversation Rules

Introduction

Quiq provides messaging for enterprises so that customers can use text messaging to connect directly to a company. With Quiq Messaging customers use the text apps (SMS, Facebook Messenger, and Kik) they are already familiar with from communications with friends.

Administering the Quiq system is intended to be intuitive and functionality driven. This area allows an administrator to configure system wide settings and user configuration. Admin permissions should only be granted to trusted individuals, as the most sensitive configuration of the Quiq system is available to Admin users.

Accessing Quiq Admin

Admin functions are accessed via the Quiq application at https://«your site».goquiq.com or via your CRM platform if integrated to a supported platform. Log in to the Quiq application using your Quiq credentials or those of the CRM application to which Quiq is integrated.

After logging in, note that you default to Agent mode. Select your desired eligibility (suggest unavailable so that your admin tasks are not interrupted). The buttons in the top right side of the banner allow access to the manager (Reports) and Admin screens. Click the Admin button.

Note - If the Admin button is not displayed, your account does not have Admin permissions. Contact your Quiq admin or Quiq support to change as needed.

The main Admin menu is presented on the left side of the page.

CRM integrated users may see an additional item at the bottom of the list containing settings specific to the CRM integration. Each section of the common configuration menu is covered in the sections below.

Users

Top

This section provides for creation and managing of user accounts.

Creating Users

Use the Create New User button to create a user, then fill in the appropriate fields. The email address must be deliverable, so the user can receive an automated email with password initialization instructions. Permissions allow assigning Manager and Admin permissions. Manager specifics are covered in the Quiq Manager User Guide. All Managers have agent permissions, and all Admins have Manager permissions. Roles are discussed in a later section. Note that all accounts will belong to the Everyone Role.

Customers with CRM integrations may not have the option to create users on this screen. This is due to the identity provider function being assigned to the CRM application. Use the CRM profile and user manager function for user management.

Reset password triggers an email to the user allowing the user to set a new password. This does not immediately invalidate the existing password. The link sent must be used within 24 hours. If the link is not used, no changes are made to the account.

Editing Users

Agents may have specific assignment limits applied. Reference the Routing section for details. Experienced agents may be given higher limits, while new agents have lower limits applied than the standard.

All fields but Username are available for editing via the Edit button for existing users. The email address must be valid to allow the user to receive password reset instructions. Manager and Admin permissions may also be applied to the account, and the user may be added to existing roles.

Disabling users

Click the Disable User button to bar the user from access to the Quiq system. Disabled users may be viewed by choosing the Show disabled users option from the dropdown menu. Disabled users may be re-enabled at will.

API Keys

API Keys are generated for a given user in order to allow calls to be made to Quiq API endpoints. Keys generated do not expire, but are disabled when the user is disabled. As such, these keys should be carefully secured and never stored in plain text files. API calls should only be made from server side applications and not exposed to the client.

Generating a Key

To generate a key, click the New API Key button, enter a description of the program or integration the keys will be used for, then click Save.

After saving, the API Secret is displayed. NOTE This is the last time the secret can be displayed. If the secret is not copied at this time or lost later, a new set of API keys must be generated. The description field may be edited as needed by clicking the field and making changes.

Auto Responses

Top

Auto Responses are no longer a separate function. Responses are now controlled by Converstion Rules.

Timers

Top

Multiple events are governed by timers to aid in efficiently routing and handling conversations. These values are all user editable and may be applied in seconds or minutes. It is important to understand the impact of these settings before changing from the default values. Organizations may implement different standards for conversation acceptance and response times. These standards should support the agent workflow in addition to customer expectations. Note also that Response Timeout, Conversation Inactive Time, and Conversation Close times, may be set both at the Contact Point level and the Platform level of each contact point. The most specific settings will apply.

Invitation Timeout - The duration that the conversation will be offered to an agent. A higher threshold increases the time a customer will wait for a response, but also allows multi-tasking agents to finish a task before accepting a conversation. Agents who fail to acknowledge a conversation offer before the timer expires will be placed in Current Conversations Only status. Reference The “Missed Invitations Limit” setting in the Routing section for additional information.

Response Timeout - When an agent is in an active conversation with a customer, and a customer sends a message, the agent must respond in this timeframe. If the agent does not respond before this timer expires, the conversation is re-queued, and the agent is placed in Current Conversations Only status. The best customer experience is achieved when an agent can maintain the conversation, or gracefully hand off to another agent. This timer should reflect agent workflow and allow for multi-tasking as needed. This timer should also account for the adaptive response timer (below) and never have a value lower than the Adaptive Response Maximum.

Adaptive Response Minimum - Quiq’s Adaptive Response Timer (ART) measures the cadence and pace of a conversation, and coaches the agent to respond accordingly. SMS conversations may have longer periods between messages than chat, so the ART takes these into account, and provides a visual queue to the agent as to when the agent should respond. The minimum value is the shortest span the timer would display for a given conversation.

Adaptive Response Maximum - Similar to the above, this is the maximum time amount the ART will display. There is no consequence of the ART timer expiring, but this maximum should not be set higher than the Response Timeout value to ensure the agent is coached appropriately.

Adaptive Response Weight - This slider dampens or heightens the ART consideration of the customer response time. More adaptive is recommended, and allows the customer to drive the pace of the conversation. Less adaptive pushes the timer closer to the Adaptive Response Maximum.

Conversation Inactive Time - When no messages have been sent on a given conversation for the period defined here, the system will automatically mark the conversation inactive. Agents may only maintain a certain number of active and inactive conversations based upon the Routing settings (see ROUTING below). An agent may mark a conversation inactive at any time. Marking a conversation inactive allows the agent to move on to a new conversation when needed. Inactive conversations are retained by the agent and become active when the customer responds. If the agent limit is reached, or the agent is unavailable the conversation will be requeued and offered to another available agent. Adjust this to allow most conversations to stay with a single agent, but still allow timely movement of conversations when needed. An attentive agent will typically mark a conversation inactive before this timer expires.

Conversation Close Time - This timer begins when a conversation is marked inactive, either by an agent or by the system. This allows inactive conversations to be removed from agent lists and finalized. Setting this too low will result in a single interaction spanning multiple conversations. A too high setting will cause inactive conversations to accumulate with agents. Note that the customer’s awareness of multiple conversations is driven by the auto responses received. The conversation history is displayed for the agent in any given conversation, so no information is lost as a result of closing a conversation.

Routing

Top

Both individual agents, and an organization’s entire staff, have a finite capacity. Routing settings allow an organization to match assigned load to capacity.

Soft Assignment Limit - Setting a limit on the number of active conversations an agent can maintain allows for timely responses and avoids allowing agents to hold more conversations than they can maintain. This setting instructs the system not to offer new conversations to an agent with this many active work items.

Hard Assignment Limit - Inactive conversations assigned to an agent may reactivate at any time. When enough reactivate to reach the hard limit number, any further inactive conversations that become active will be requeued.

Allow Agents to Request Additional Conversations - When enabled, agents must display the Agent Queue Summary Table to have the Request conversations button displayed. If there are conversations queued for any queue the agent covers, this button will be displayed for the agent, allowing them to be offered a conversation, even if the agent has reached the soft assign limit.


Reactivated Conversations Go to Back of Queue - By default, if a conversation is re-queued, it becomes the last conversation in queue. It will not be offered to an agent until all other conversations in queue have been offered and routed. Turning this off would place re-queued conversations at the beginning of the queue, making them the next conversation offered to an agent. The customer experience chosen depends upon the the workflow of conversations. If the desire is to allow conversations that were previously engaged to be re-engaged sooner, this setting should be OFF. If new conversations are of higher priority, this setting should be ON.

Missed Invitations Limit - Conversations are offered to the agent via invitation. A missed invitation my indicate the agent is too busy or otherwise occupied. The default behavior of the system is place an agent that misses an invitation into Current Conversation status, so that no new conversations are offered. This setting allows the number of missed invitations which may occur before the status change is made. The status change may be disabled completely by setting this field to 0.

Queue Size - New conversations not routed to an agent are instead held in queue. The queue would be considered backlog for all agents and should be set based upon expected throughput of the agent pool, and the acceptable time customers may wait until a conversation is routed to an agent. When the queue size value is reached, all new conversations receive the When the Queue is Full message (see AUTO RESPONSES above) and then terminated. A too high value could create an insurmountable backlog and cause customers to wait too long for an agent response. Setting the value too low would cause conversations to be discarded when they could have reached an agent.

Show Decline Button - When an agent is offered a conversation, the Decline button may be hidden based upon this switch. With no ability to decline, an agent must allow the invitation to expire to avoid accepting the conversation (see TIMERS above).

Flash Conversation Tab on New Conversation - Provides a visual indicator to agents when a new conversation is being offered. This can be beneficial to multitasking agents or distracting to agents working continuously in the Quiq Messaging console.

Sticky Routing Window - Agents can likely recall their recent interactions with a customer. Routing new conversations to the last agent to converse with the customer puts this recollection to use, leading to faster handle times and higher customer satisfaction. This is a timer setting in hours from the time the last conversation from the customer ended. Sticky routing will not override above limits and so the receiving agent must have availability for the work item.

Work Item Weights - Certain platforms or channels drive different conversation behaviors. SMS is often more asynchronous in nature, where web chat is often more synchronous. Synchronous channels may have more weight assigned as they have higher demand upon the agent for responsiveness. Assign weights here based upon the experience of past conversations on the given platform, and agent capability. Note that weights assigned here impact the soft and hard limits described above. Platforms not configured may not be edited.

Agent UI

Top

Agent Settings

Toggle the listed settings to allow or disallow the use of the emojis, giphys, and stop and block selections. These settings are universal across the application.

Emojis Enabled - Master switch to enable the use of emojis by agents. This does NOT block emojis customers send in the conversation. Turning this off removes the ability to add emojis to conversations, collaborations, and snippets. Allowed Emojis - Allows the selection of allowed or disallowed emojis. Certain emojis may be removed to ensure an agent does not send an inappropriate emoji. If Included is selected, only the chosen emojis will be available to agents. This allows a small, safe set of emojis for agent use.

Giphy Enabled for conversations - Disabled by default. Most messaging applications support Gif search and insertion into conversations. This option can provide a more engaging and personal experience, but may be too informal for some organizations.

Giphy Enabled for Collaborations - As above, this setting allows gif insertion into internal facing collaborations. This is enabled by default and allows agents to provide expressive gifs specifically in the collaboration. Collaborations are NOT visible to the customer.

Add Contacts to Stop List Enabled - Allows an agent to add a customer to the Stop list (essentially opting the customer out of messages). This opt out takes place as soon as the exiting conversation is complete. This provides agents the means to opt a customer out at the point of contact vs. submitting to an Admin user.

Block Contacts Enabled - This option allows an agent to block incoming messages from the given contact, after marking the conversation as spam. The block takes place immediately. See also Agent Blocking and also Manager Blocking

UI Extensions

Customer name, phone number, and messaging handle are useful elements in allowing agents to provide personalized assistance to customers. These basic elements are stored in the Quiq system and once entered, may be displayed for any future conversation with the customer. These fields may be configured for display or not as needed, and are displayed to the right side of the conversation pane. These fields are typically not displayed for CRM integrated systems as this date resides in the CRM and is not propagated back to Quiq.

In addition to (or in some cases, instead of) the Quiq fields, external system fields may be displayed by adding a securely hosted (HTTPS) webpage to the Quiq application. Some examples of usage would include order management system lookups associated to mobile numbers or CRM contact pages. Implementing these extensions requires system integration expertise. Quiq developers have released a UI extension SDK on GitHub to streamline these integrations.

Start Conversation Fields

For sales or other use cases where agents often initiate conversations, the ability to set conversation custom fields when starting the conversation may be beneficial. Note that custom field creation must currently be requested via support@quiq.com. Available fields may be selected and subsequent fields will then be available.

Roles

Top

Organizations with a basic Quiq implementation may not find the need to utilize roles. A default role titled Everyone is created by default and includes all users and provides access to the default queue.

More complex implementations of Quiq utilize multiple queues to align with different business units, functions, or brands. Roles provide a method to associate users to these queues, and specify which queues agents may receive conversations from, and route conversations to.

Agents may belong to multiple roles. This should be considered to note the impact to the agent and understand that conversations may be offered to these multi-role agents from various queues.

Creating a New Role - Click the Create New Role button to open the role editor. Enter a label that indicates the purpose of the role. The entire list of configured agents is displayed under the Members heading. Click the agent to be added to the role, and click again to deselect. After the role is created, members may be added or removed at will.

Queues are specified as Receive or Route. Queues selected as Receive will have the unassigned conversations in that queue offered to members of the role. Route queues allow an agent to move a conversation to a different queue. Roles may be specified without queues to provide access to users who may not converse with customers, but need access to the Quiq application, or used to grant Send Notification or Start Conversation privileges in Contact Point configuration.

Editing a Role - Select an existing role to display the editor. Select Edit in the Members or Queues sections to change the selected items. Note that the Everyone role may have queue changes, but the members must include all users.

See Also

Queues

Top

Queues serve as collection points for conversations and a marker to define handling processes. Conversations may flow to a queue from specific contact points, or may be routed to a queue manually by an agent.

An escalation queue is used to allow a separate or special set of agents to address conversations that an initial set of agents could not address. Escalation queues do not have matching contact points, and only receive conversations from agents servicing a process queue.

Process queues are associated to a contact point and can receive conversations from contact points and via agent re-queue actions.

Creating a New Queue - Click the Create New Queue button to open the Queue editor. Enter a label for the Queue and note that the ID mirrors the name, replacing spaces with hyphens, and lowercasing any capitals.
PRO TIP: If the Queue ID matches a Contact Point ID, conversations from the Contact Point automatically route to the queue under default conversation rules.

Editing a Queue - Once a Queue is created, only the label may be changed. Select an existing queue and click the Edit button to change the Queue label.

See Also

Contact Points

Top

Contact points are typically aligned with different lines of business, functions, or divisions by language. All Quiq tenants have at least one contact point. This control panel allows an Admin to enable web chat or configure additional platforms for the contact point, configure the options available for web chat, and manage Stop Lists for a given contact point.

See Also

General Tab

General Settings Contact point ID’s are fixed, but labels may be changed by clicking the Label item, making the desired change, and clicking the Save button.

Contact Point Timer Settings These settings override the tenant level settings applied under Admin > Timers for the given contact point. This allows specific use cases among different contact points.

Outbound Roles Roles may be given rights to start a conversation or send notifications from the contact point.

An agent may send an SMS message to a customer using one of two methods, Start Conversation or Outbound Messaging. Start Conversation immediately begins a conversation and assigns it to the agent, while a Notification does not generate a conversation unless the customer replies. Reference the Outbound Messaging Guide for additional details.

The Outbound Roles provides an administrator with a method of limiting these actions to specific roles. This is best explained via an example. A site with a Sales and Service contact point may wish only users in the respective departments to use those contact points. Roles defined along these departmental lines allow the Admin to limit the Sales contact point to the Sales role, and the Service Contact Point to the Service team. A Manager role may be given access to both contact points.

Additionally, each function (Start Conversation and Send Notification) is managed separately for each contact point. In the above example, Sales may be given access to the Send Notification item for Service in order to message about service specials, but not added to the Start Conversation list, as only Service reps should have Service conversations.

Click the Edit link to alter the list of Roles authorized to use each function. Once changes are made, ensure the Save button at the top of the Contact Point configuration page is clicked to retain the changes made.

Additional Roles may be considered for the purpose of managing this access.

SMS Tab

Platform Timer Settings Just as these may be overridden at the contact level, the timer settings may be further overridden at the platform level, with the most specific set of timers being applied. Other platform tabs will provide the same options specific to conversations taking place on the given contact point and platform. This allows a specific “SLA” to be applied to each platform. Web Chat and Apple Business Chat my have shorter timers given the nature of the platform and customer expectations of a more real-time interaction.

SMS Numbers The numbers configured for this contact point will be of the following types:

  • Standard - Numbers that both send and receive SMS messages
  • Incoming Only - Numbers that receive messages, but conversations are diverted to a standard number. This is typically used for toll free numbers to avoid the lack of MMS support on those numbers.
  • Blocked Outbound - Numbers that may receive messages but conversations are diverted to a standard number. These numbers have been identified as being blocked by the carrier. See this knowledge article for blocking information.

Stop List Recipients of text messages must always have the option to opt out of receiving them. The opt out is based upon the contact point because different contact points may have different uses. A customer may wish to opt out of a certain type of messages, but still receive others. For example, a customer may wish to stop receiving Sales messages, but still interact with the Service or Support team. In this case, the customer would be added to the stop list of the sales contact point, but removed from the support contact point stop list.

Quiq detects and applies STOP and START messages sent by a recipient, however these messages must be just the single word. Customers may send “Please stop texting me” which would not be detected as a stop message, and would have to be processed manually.

Removing a customer from a stop list may not automatically allow them to begin receiving messages. A carrier block may still be in place, and the customer must text START to the contact point number in order to lift the carrier block.

When adding or removing numbers, multiple numbers may be input using comma delimited format. Up to 50 numbers may be added or removed at one time.

Export Stop List The stop list numbers may be exported to a CSV file. Toggle the Export Across Contact Points option to get stop lists for all your contact points.

Web Chat

Web Chat Enabled - This is the master switch allowing the Admin to control whether web chat is turned on or off. Toggling to off makes the remainder of the options unavailable. Conversely, toggling on makes the options available again. Enabling Web Chat here is not the same as implementing it on a web page. Reference the Quiq web chat SDK for details on placing the chat client on a web site.

Web Chat Status - Indicates whether the web chat button would be visible given the Agent Availability Rules configured for the web chat platform on this contact point. After a rules change, this will be re-evaluated and may take up to a minute to update.

Email Transcript - Causes a button to appear at the end of a web chat conversation that allows the user to request a transcript of the web chat conversation.

User File Attachments - Enables the ability for the customer to attach files to a web chat, making the file available to an agent. This is essentially the same functionality as SMS attachments but can be disabled in web chat for added security. Only a certain set of file types are available for upload such as images and PDF files.

Agent File Attachments - Enables the ability for agents to attach and send files to a customer via web chat.

Emojis - Enables a set of emojis for the customer to include in messages sent.

Play Sounds - Sound notifications for the end user brings attention to notifications generated by the web chat. Toggle this off to disable sounds.

Title Bar Notifications - Toggle on to allow the browser tab to be changed indicating web chat events.

Whitelisted Domains - Entries here control what web sites are allowed to host chat clients associated to the contact point. A blank entry allows any server. Quiq recommends this always be completed for security purposes. Use wildcards to allow multiple hosts to display the chat client.

Mobile Options - Allows Mobile users to be redirected to their SMS application and a new message window with the phone number entered here as the recipient on the mobile messaging app. This allows redirection of mobile devices away from web chat and to the native mobile messaging platform.

Menu Options - Allows offsets and additional items or links to be added to the end user’s web chat menu.

Web Chat Colors - Color styling may be accomplished here vs having to apply extra JavaScript parameters to the web implementation. This allows a Quiq Admin to change the web chat appearance without any web developer time consumed or change orders required. The preview to the right allows a realtime review of how the chat window will appear the the end user.

Web Chat Fonts - Allows selection of a specific font to be used for the end user web chat window. Note the specifics in the settings description here.

Welcome Form - This section allows creation of a Welcome form which is displayed to end users before they are passed to the chat dialog screen. Fields may be marked as required and thus must be filled to allow the user to submit the form. Fields are placed in the order added to the form. Ensure that the desired top field is added first, and subsequent fields are added in order.

Custom Fields must be edited after being added, to change the label and required options.

After changes are made to the form, click the Save button at the top right of the panel.

NOTE - The form defined here will override any form field definitions implemented by your web team. Welcome form fields will be deprecated in the web chat client, and defining the welcome form here will permanently disable their use via JavaScript.

Agent Availability Rules - Complex conditions and parameters may be set here to define when the web chat option is visible on a page. While the title suggests the original capability of just being shown when agents are available. Rules may now consider a large set of variables to determine if the web chat icon is displayed. Note that this may be overridden by the JavaScript used on the page where web chat is provided. These rules will work for a default implementation.

Conditions may be added for time of day or day of week, queue volumes, available agents, etc. Reference the Conversation Rules section for specifics on the Rule editor. Once changes are made, it is necessary to scroll to thetop of the page and click the green Save button to ensure changes are applied. Once saved, the Web Chat Status will update to indicate if the chat button should be displayed.

Facebook

Connecting an existing Facebook page to Quiq causes all Messenger traffic directed to the page to be sent through Quiq. This turns Facebook interactions into Quiq conversations and potentially CRM records if your Quiq instance is integrated to a CRM. The person configuring the Facebook integration must be signed in to a Facebook account that has admin privileges, within a different tab of the same browser where Quiq is being used. This ensures the scripted actions work without issue and allows the integration to flow smoothly.

Once configured, Platform Timer Settings and Page Association sections are available.

Platform Timer Settings - Just as these may be overridden at the contact level, the timer settings may be further overridden at the platform level, with the most specific set of timers being applied. Other platform tabs will provide the same options specific to conversations taking place on the given contact point and platform. This allows a specific “SLA” to be applied to each platform. Web Chat and Apple Business Chat my have shorter timers given the nature of the platform and customer expectations of a more real-time interaction.

Page Association - Click the link to view the checklist and identify any errors in the configuration. A healthy configuration will appear as follows:

NOTE The Facebook Page Identification section blanks as soon as it is submitted. Quiq does not retain the URL, but uses it to find the page ID. So long as the other sections are green, the integration is functional. A yellow section will indicate a problems, and the Facebook admin should re-complete the checklist.

Twitter

Connecting an existing Twitter account to Quiq allows all Twitter Direct Messages to be sent through Quiq. This turns Twitter interactions into Quiq Conversations and potentially CRM records if your Quiq instance is integrated to a CRM. Note the warning displayed on the configuration page. The Twitter configuration is tightly scripted and will easily complete for a user with proper credentials.

The Twitter account used should also be configured to allow direct messages (DMs) from anyone.

Additional Platforms

Additional Platforms may be added such as Apple Business Chat, Google RBM, and Google Messages. These require coordination with the messaging providers. Contact Quiq Support via support@quiq.com for assistance with these platforms.

Webhooks

Top

Customers may implement webhook handlers to capture data emitted by the Quiq system when certain conversation and agent based events occur.

New Webhook

Click the New Webhook button to add the URL of a webhook handler, and to choose the events the handler is subscribed to. Reference the Quiq Webhook Overview for detailed information about the data provided. Webhook URL’s must implement HTTPS.

Once the webhook is created, a GUID is generated for use as a Shared Secret. Click the Show Secret link to reveal this GUID and copy it for use in verifying the webhook posts. Use the buttons to the right of the webhook definition to edit the entry , delete the entry, or refresh the Secret .

Security

Top

Certain items have been consolidated in the Security menu for ease of administration.

Public API Keys

API keys are used to abstract a user account’s credentials for the purposes of making calls to Quiq API endpoints such as StartConversation or SendNotification. This page provides a list of all the keys created for various users. Keys are managed in the Users section.

Audit Log

Certain key events are now logged for review by Quiq application admins. The current event types include configuration updates and user creates and edits.

Usage

Top

The Usage section displays aggregate counts of conversations and notifications based upon the selected time interval. Because this feature was added recently, some customers may not see a full history of their conversations available.














Conversation Rules

Top

NEW FEATURE

As organizations wish to provide a more customized experience to their users, and more specific ways to handle conversations for their agents, the need for rules available to admin users has been answered with this feature. Note that the Auto Response feature has been incorporated into Conversation Rules. The logic of when to send a message fits well within the other actions available in this component.

Rule sets are defined in versions to allow for an easy way to reinstate a previous working set. Previous versions are listed on the main screen and offer two choices, Re-publish or New Draft. Republishing replaces the current rule set with the selected version immediately. New Draft places a copy of the selected rule set into the draft workspace. Drafts and versions encompass ALL the rules defined.

The Draft workspace may only contain a single instance of rules being edited. Creating a new draft overwrites the existing draft set. A draft may be saved and edited multiple times.

Publishing a draft immediately places the draft set into production and clears the draft area. If the new set does not work as expected, the previous version may be implemented by selecting the version and choosing re-publish. The current rule set is shown at the top and only offers a new draft from this version. Previous versions offer a new draft or re-publish options.

Editing Rule Sets

Rules are fired by events and composed of decisions and actions. An action may be taken without decision, or as a result of a decision based on complex conditions, allowing multiple conditions with ALL or ANY logic to be met. Multiple decision steps can branch the rule leading to many different actions as a result. Care should be taken to craft each rule with specific purposes in mind, and to evaluate whether rules overlap or conflict. The actions and decision steps of a rule are executed top down, so position matters.

EVENTS

Rules are triggered by events. Every rule is triggered by at least one but possibly many events. Selecting the correct events allows actions to be taken at the appropriate time. The conversation events in the dropdown list each provide a brief description.

  • Is Starting: Conversation has just begun
  • Is Routed: The conversation is offered to an agent or assigned if invitations are disabled.
  • Is Routed to an Agent When it starts: Indicates the conversation was routed when it started.

~note~ Consider the separate events above. All conversations will start. All should eventually be routed. Only some will be routed at the same time they start. This occurs when agents are available and there are no queued conversations ahead of the new conversation.

  • Begins Waiting in a queue: Any time a conversation is queued and waiting for an agent.
  • Lands in a queue when it starts: No agents are available or none have capacity to take the conversation when it starts, so the conversation is queued. This is the only other result when a conversation starts. It is either queued or routed.
  • Is in queue and awaiting a response: The last message in the conversation was from the customer and the conversation is queued.
  • Is still waiting in queue: Periodic event when the conversation is queued.
  • Receives a new customer message: regardless if the conversation is queued.
  • Receives a new customer message while waiting in queue: New message received and the conversation is queued.
  • Closes: The conversation is ended by the agent, a bot action, or the close timer.

ACTIONS

The only actions available to conversation rules are to send a message on the conversation, and to send the conversation to a queue.

DECISION STEPS

Decisions evaluate conditions. When conditions are combined, ALL or ANY operators may be selected. Decisions may also be nested. Decision paths may be left blank, but most result in an action. The decision branches are shown in varying shades of gray color boxes to indicate scope. Once a decision is determined false, the next branch at that level is evaluated and any subsequent logic at that level is bypassed. A true decision completes the rule once the specified actions are taken.

DEFAULT RULES

There will be at least four default rules in place but any number of rules may be added. The defaults are described below.

INITIAL QUEUE ASSIGNMENT RULE

Use both system and conversation variables to determine which queue the conversation should be sent to. A number of options are available with the values specific to the field chosen. The first selection determines when the rule is applied. Most will want the “is starting” event to handle where a new conversation is directed.

Add a conditional check next, using the IF and the dropdown of available fields to evaluate.

Four main categories of fields are context, conversation, time, and workload.

  • context: fields related to events or conditions at the time the rule is being evaluated.
  • conversation: data fields in the conversation. Consider that at the beginning of a conversation, many of these fields will not yet be populated.
  • time: allows a comparison of the time the rule is executed to a defined time/day parameter.
  • workload: current measures of queue conversation counts and agent availability in relation to queues.

Condition is context sensitive based upon the selected field. Condition determines what type of comparison is being made (is/is not, contains, >/<, etc.).

Value is also context sensitive depending upon the field selected. Fields with a fixed set of values will only have those displayed. Conditions that set a range will cause the value to select beginning and ending values.

EXAMPLE 1 - If the contact point the conversation was started on is “end user support”, route the conversation to the Default queue.

  • create the conditional statement:

  • add the action:

  • select the queue:

Scroll up and click Save to retain the changes to the draft.

EXAMPLE 2 - Add another condition.

  • choose whether all the conditions or any need be true to satisfy the rule element.

  • follow the same field addition steps from above.

The below rule element routes the conversation to the Default queue if the contact point is End User Support or the platform is Facebook.

INITIAL AUTO RESPONSE

When a conversation starts, it is either sent to a queue, or routed to an agent. For both of these cases a message may be sent. A message sent for the routed to an agent case may prompt the customer for information the agent will need, or simply inform the customer an agent is reviewing the conversation. When a conversation is sent to a queue, the customer may have a bit of a wait. Sending a message that informs the customer of the expected wait provides a better experience.

~note~ Quiq users starting before August 2019 had a separate Auto Response area where these messages were configured. The events available for classic Auto Responses were rigid and limited users from complex arrangements. Auto Response functionality was migrated to conversation rules. Those with simple auto response requirements may simply edit the test in these rules and leave the actions and decisions unchanged.

Consider that two main branches of the sent to queue path are the queue is staffed with available agents but agents are busy (soft limits reached), and there are no available agents (off hours). Send the proper message for both cases.

Note the option to “Skip if the customer had a recent conversation”. Receiving multiple auto responses may degrade the interaction so this option supresses the message if the same customer had a previous conversation end within the last 15 minutes.

WAITING IN QUEUE AUTO RESPONSES

Customers may send a message while a conversation is in queue, even if they have received the initial auto response. The message defined here reminds the customer that they are still in queue and will be addressed when an agent becomes available.

CLOSING AUTO RESPONSES

The closing auto response is blank by default. Many organizations send a thank you message here, or may include a link to a feedback survey, or possibly a promotional link.

CREATING A NEW RULE

Using the information and descriptions above, new rules may be added to implement specific message flows or routing options for distinct business units. Conversation rules are intended to apply as many data points as possible to decisioning, and to allow very simple to very complex flows to be created. Keep in mind that the Draft workspace is safe but publishing pushes the rule set into production. Save often and publish sparingly.