Documentation:HTCC:IWWDep:SettingUpSupervisors:9.0.0

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 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 Cloud_Cluster object exists in the Configuration Database.
• One or more agents who have the Supervisor role.

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 Cloud_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.
3. Review the following Team Lead privileges for more information about the monitoring privileges available for supervisors:
   • Voice:
     • privilege.teamlead.can-monitor-voice
     • privilege.teamlead.can-monitor-current-voice
     • privilege.teamlead.can-stop-monitoring-voice
     • privilege.teamlead.can-coach-voice
     • privilege.teamlead.can-coach-current-voice
     • privilege.teamlead.can-switch-to-barge-in-voice
   • Chat:
     • privilege.teamlead.can-monitor-chat
     • privilege.teamlead.can-stop-monitoring-chat
     • privilege.teamlead.can-coach-chat
     • privilege.teamlead.can-switch-to-barge-in-chat

End

Enabling Supervisors to Manage Workbins and Interaction 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 interaction queues.

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

• reassign it by moving it to another workbin or another interaction 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 interaction 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.workbin.can-search-my-workbins-trees: Enables agents to search for workbins in the navigation tree of the My Workbins View.
• 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 Interaction 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.
• privilege.interaction-management.case-data.can-edit: Enables supervisors to edit case data for interactions directly from Workbins and Interaction Queues without pulling the interactions first.

You can use the following configuration options in the interaction-workspace section to control the way that interactions are displayed in Interaction Management views and how the list of agent workbins are displayed in the Workbin Explorer:

• 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.
• my-team-workbins.agent-page-size: Specifies the value for the number of agents per page in the My Team Workbins sub-tree of the My Workbins view.

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 Extension 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 interaction queue, or a comma-separated list of interaction 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 interaction 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 Cloud_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 interaction 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.

Enabling Supervisors to use the My Agents view

The My Agents view enables supervisors to view the status of agents they supervise and change the agent state on one or more channels.

You can grant the following privilege in the interaction-workspace section to enable supervisors to use the My Agents view:

• privilege.myagents.can-use

Use the following configuration options to specify how the My Agents view looks and what actions a supervisor may perform:

• teamlead.myagents.available-page-sizes: Specifies the possible values for the number of rows per page in the My Agents view.
• teamlead.myagents.default-page-size: Specifies the default value for the number of rows per page in the My Agents view. The value is defined by the teamlead.myagents.available-page-sizes option.
• teamlead.myagents.enabled-channels: Specifies the channels that are displayed in the My Agents view. Channels are displayed in the order in which they appear in the list.
• teamlead.myagents.pagination.limit: Specifies the maximum number of agents displayed per page in the My Agents tab.
• teamlead.myagents.refresh-rate: Specifies the frequency, in seconds, to refresh the list of agents. To disable automatic refresh, specify a value less than 5 to indicate manual refresh. Automatic refresh is also disabled if the value of the accessibility.visual-impairment-profile option is true.
• teamlead.myagents.manual-refresh.enabled: Specifies whether the manual refresh button is displayed in the My Agents view. Manual refresh is automatically enabled if automatic refresh is disabled by the teamlead.myagents.refresh-rate option.
• teamlead.myagents.thresholds.enabled: Enable thresholds to be used in the My Agents view for channels specified by the teamlead.myagents.thresholds.<media-type> option.
• teamlead.myagents.thresholds.<media-type>: Specifies the name of a threshold section that determine when an agent state is considered to be Busy or Not Ready for the specified channel. You must create the threshold sections on the Application object.

  Threshold sections are similar to Contact Center Statistics and KPIs, but they must include a state name as a prefix. For example: busy.error-level-high or not-ready.error-level-high. Assign a key, such as error-level-high, and a value, such as 300, to the threshold.