Documentation:HTCC:IWWDep:SettingUpSupervisors:9.0.0DRAFT

Setting Up Supervisors On The System

After you have created Agent objects you can set up your agents and supervisors to use different functionality. The following procedures assume that you know how to use the Genesys Administrator Extension application to configure agent objects.

Defining a User as a Supervisor

Purpose: To set up an agent as a supervisor. You can also define a user as an agent group supervisor.

Prerequisites

• A working knowledge of Genesys Administrator Extension (GAX).
• A WS_Cluster object exists in the Configuration Database.

Start

1. In the configuration layer, by using GAX, specify that the user type is Supervisor. In the annex of the person object, in the htcc section, specify the values Supervisor,Agent for the roles option.

End

Defining a User as an Agent Group Supervisor

Purpose: To set up an agent as a supervisor for one or more agent groups.

Prerequisites

• A working knowledge of Genesys Administrator Extension (GAX).
• A WS_Cluster object exists in the Configuration Database.

Start

Complete the steps below for each agent group you want the user to supervise:

1. In the configuration layer, use GAX to select an agent group to be used to specify the list of agents that a supervisor can monitor.
2. If necessary, add the agents to be monitored to the agent group.
3. In the Configuration tab for the agent group, open the Advanced view.
4. In the Supervisor field, add the name of the user that will be acting as supervisor for that agent group.
5. Save the changes to the Agent Group object.

End

Enabling a Supervisor to Monitor Agents

You can enable a supervisor to use the monitoring features to Listen (Monitor Next Interaction), Whisper (Coach Next Interaction), and Barge-in (join—available as a transition from the other modes) to agent voice and chat interactions.

The following transitions are supported:

• Monitoring to barge-in.
• Coaching to barge-in (chat only).
• Coaching to monitoring (chat only).
• Barge-in to monitoring.
• End Monitoring.

Purpose: To enable a supervisor to use the monitoring features to Monitor, Coach, and Barge-in to agent voice and chat interactions.

Important

• Voice call monitoring is supported only for SIP Server environments
• Route point monitoring for which calls are routed to IVR is supported only for SIP Cluster environments
• In SIP Server environments without SIP Cluster, the supervisor is engaged only when the call is routed to an agent and the agent has answered the call

Prerequisites

• A working knowledge of Genesys Administrator Extension (GAX).
• A WS_Cluster object exists in the Configuration Database.

Start

1. In the configuration layer, use GAX to navigate to the annex of the person (or tenant, application, and so on) object you want to be a supervisor. In the interaction-workspace section, specify the value true for the privilege.teamlead.can-use.
2. In the same interaction-workspace section, you should also specify the scope of monitoring (call or agent) by using the teamlead.monitoring-scope option.
   Important

   Set the value of the teamlead.monitoring-cross-site-based-on-activity-enabled option to true in environments where supervisors monitor agents across multiple sites.

3. Review the Team Lead options for more information about the privileges available for supervisors.

End

Enabling Supervisors to Manage Workbins and Queues

If an agent is set up as a supervisor for an Agent Group, you can configure that supervisor to read and manage the contents of workbins that belong to other agents in the group. You can also configure the supervisor to manage the contents of queues.

Supervisors can select a single interaction in a workbin or a queue and:

• reassign it by moving it to another workbin or another queue
• mark the interaction as Done, if it's an inbound email
• delete the interaction if it's an outbound email

You can grant the following privileges in the interaction-workspace section to enable supervisors to manage workbins and queues:

• privilege.my-team-workbins.can-use — Enables the Team Lead to see the Workbins of agents who are members of the Agent Group for which the Team Lead is specified as a Supervisor.
• privilege.interaction-management.can-use — Enables the Team Lead to see interactions that are filtered by pre-defined criteria.
• privilege.interaction-management.can-move-to-queue — Enables the Team Lead who can use Interaction Management to move items from displayed workbins or from an Interaction Filter to an available Queue.
• privilege.interaction-management.can-move-to-workbin — Enables the Team Lead who can use Interaction Management to move items from displayed workbins or from an Interaction Filter to another workbin.

You can use the following configuration options in the interaction-workspace section to control the way that interactions are displayed in Interaction Management views:

• interaction-management.available-interaction-page-sizes: Specifies the possible values for the number of rows per page in the Interaction Management content view. Values grater than 100 are not recommended due to performance impact. The maximum value depends on the content of interactions and the robustness of your network. If you specify a value that is too high, the request to get a snapshot fails and an error message is displayed.
• interaction-management.default-interaction-page-size: Specifies the default value for the number of rows per page in the Interaction Management content view.
• {{Optionslink|link=Options:Web_Services_and_Applications:interaction-workspace:
• {{Optionslink|link=Options:Web_Services_and_Applications:interaction-workspace:
• {{Optionslink|link=Options:Web_Services_and_Applications:interaction-workspace:
• {{Optionslink|link=Options:Web_Services_and_Applications:interaction-workspace:

Creating Interaction Filters for Team Leads

Agents who are granted privilege.interaction-management.can-use can view "snapshots" of interactions from the Interaction Server database. To do this, system administrators should use Genesys Administrator or Configuration Manager to build interaction filters (database requests that Workspace Web Edition sends to the Interaction Server database) and then set the interaction-management.filters to assign the filters to Team Lead agents.

Here are a few examples of criteria you could use to create a filter:

• mediaType: The media type, such as email, of the interactions you want to request from the database.
• age: The age of the interactions you want to extract. You could use this criteria to find interactions that have been received in the last four hours, or interactions that are older than one day, and so on.
• Priority: The priority of the interactions you want to extract.
• Queue: The name of the queue, or a comma-separated list of queues, where the interactions you want to extract are stored.
• Time in Queue: The time that the interactions you wan to extract have been in the queue.
• Received At: The date and time at which the interaction was received. The query can specify that the filter returns either all the interactions created on, before, or after this date, or within a range of two dates.

To create and use a filter in Workspace Agent Desktop, complete the following steps:

1. Create a new section on the WEWS Cluster application object that is same as the name of the filter (for example: [FilterEmailAge]).
2. Configure options for the filter by using the names of fields in the Interaction Server database. The options correspond to the criteria for the interactions you want to extract from the database. The filter section must contain the following options:
   • category: The name of the category that contains the filter — for example: Email
   • condition: The complete filter — for example: (priority >= 2) AND (MediaType='email') AND (_age() > 172800). See Specifying Filter Conditions for information about how to define the conditions of a filter.
   • display-name: The display name of the filter — for example: Older Than Two Days
   • displayed-columns: (Optional) The list of columns that are displayed for interactions in this filter — for example: From,To,Subject,Received. If this option is not set, the displayed columns are taken from the interaction-management.interactions-filter.displayed-columns option.
   • queues: The list of queues to which this filter applies — for example: email-routing-queue-inbound,email-default-queue.
   • case-data.business-attribute: (Optional) Specifies the name of the Business Attribute that contains the Business Attribute Values that are used to filter and render attached data for an interaction displayed in this filter. Use this option to enable agents who are configured to be supervisors to view different interaction content than the agents whom they supervise. This option is not mandatory. If it is not specified, Workspace Agent Desktop displays the case data that is specified by the interaction.case-data.format-business-attribute option.
3. For the Application object, Agent Group, or Agent, configure the value of the interaction-management.filters option to specify a comma-separated list of filters by the section name that you configured. For example:

[interaction-workspace]
interaction-management.filters=FilterEmailAge

Specifying Filter Conditions

A filter in Workspace Agent Desktop is defined by specifying different property filters and linking them together by using AND and OR logical operators.

A property filter is composed of a property name (for example: MediaType, Queue, or SubmittedBy) and a property value — for example, MediaType='email'.

Refer to the eServices Interaction Properties Reference Manual for details about keywords, operators, and properties that can be used to query the Interaction Server database. Be sure to read about the different System properties and how to configure Custom properties — you can use both kinds of properties to define interaction filters.

You can use the following property types for System and Custom properties:

• Integer
• String — Strings are bracketed by single quote characters — for example: 'email'.
• Timestamp — Use the _timestamp keyword from Interaction Server for the value — for example: _timestamp('2013-11-21 14:12:00')

Filter conditions use comparators and logical operators to test the value of a property against the value that is stored in the database field. The following operators are supported:

• > (greater than)
• < (less than)
• >= (greater than or equal)
• <= (less than or equal)
• = (equal)
• != OR <> (different from/not equal)
• LIKE (contains the string) — for example, MediaType LIKE '%a%' finds all of the media types that contain the letter a. The % character acts as a wildcard. If MediaType LIKE 'ema%' is used, then media types that begin with ema are found. If MediaType LIKE '%at' is used, then media types that end with at are found.
• NOT LIKE (does not contain the string)

For interaction properties that have the String type, you can avoid issues with database formatting differences for empty strings by using the _empty and _not_empty keywords. For example, to filter all the interactions that have an ExternalId property that is non-null, use _not_empty(ExternalId).

For interaction properties that have the Timestamp type, use the keywords that are described in the Translations section of the eServices Interaction Properties Reference Manual. For example, to find all interactions that were received between November 24 and November 29 in 2013, you would use the following conditions: ReceivedAt >=_timestamp('2013-11-23 00:00:00') AND ReceivedAt <= _timestamp('2012-11-29 00:00:00').

Important

To make the columns in the Interactions table sortable, in the Interaction Custom Properties Business Attribute, you must explicitly declare the attribute as a column of the 'interactions' table of Interaction Server database.