Jump to: navigation, search


Section: statserver
Default Value: no
Valid Values: yes, no
Changes Take Effect: After restart

Determines whether Stat Server treats ACW activity as interactions while the associated DN is in after-call work (ACW) status. The routability of additional, simultaneous interactions to a device is dependent on the number of interactions that currently are occurring at that device. Setting this option to yes instructs Stat Server to treat any ACW activity as an interaction for the purpose of determining capacity—synonymous to any other type of voice interaction, such as handling customer-initiated (inbound) calls, internal calls among agents, and so forth. For the purpose of reporting current activity, this treatment does not increment the count of CurrentNumber or TotalNumber statistics.

The presence of ACW on a device also affects the routability of interactions of other media types, as defined in the capacity model for your environment. For information about defining capacity rules, refer the Genesys Resource Capacity Planning Guide.

If this option is set to no, Stat Server does not consider ACW-related activities that occur at a device in its calculation of the current_number component of the capacity vector. In fact, Stat Server may allow additional, simultaneous interactions to be routed to that device per the capacity rules defined in your environment.

Capacity Rules

A major element of Resource Capacity Planning is a capacity rule, which defines a resource's ability to handle multiple interactions. For RCP methodology, the term resource is synonymous to a Person object that is configured as an Agent and defined in the Configuration Layer. A capacity rule is a set of logical expressions that specify the boundaries of a resource's ability to handle one interaction or more than one simultaneous interaction of differing media types.

Even though the capacity planning tools enable you to define rules for all Genesys-provided media types, it makes sense to use only the media types that your set of Genesys solutions supports. The Multimedia 8.0 and higher releases, for example, support chat, email, sms (short message service), and open-media media types for capacity planning.

Interactions categorized under the webform media type, which was available in prior releases, are now processed as email interactions.

Applying a Capacity Rule to Resources

You can directly associate a capacity rule to an agent (a Person object, that is) using Genesys Administrator or Genesys Administrator Extension (GAX). In such a case, the capacity rule describes the agent's ability to receive interactions.

In most cases, you can also associate a capacity rule to a Place object (except for those environments in which Stat Server monitors interactions that are distributed from a SIP Cluster). Refer to Capacity Planning for New Agent-Place Model for more information.

Lastly, you can associate a capacity rule to a Tenant object. The capacity rule applies to all agents belonging to the tenant where no capacity rule is directly assigned to those agents (or their corresponding places). (In single-tenant environments, the tenant is the entire contact center.)

A capacity rules only affect the distribution of interactions. Capacity rules do not preclude the agent from initiating any number of interactions of any media type on his or her own prerogative.

Media Rules

A capacity rule consists of a set of media types and expressions. For every media type, a media rule within the capacity rule expresses the boundaries of the agent's ability to receive interactions of that particular media type.

By means of media rules, you might define an appropriate workload for an agent for every media that the agent is enabled to handle. While defining a rule for a specific media, you might consider the simultaneous workload for another media.

A media rule might be thought of as a logical expression that is applied against the current number of agent interactions per medium. These logical expressions (media rules) define when the system considers that agents are no longer available for a new interaction for that particular medium. Media rules are evaluated in runtime for agents, and the Universal Router Server uses these results to make intelligent routing decisions. Consequently, agents may have several simultaneous interactions. If capacity is reached for one particular media type, the agent might still be available for interactions of other media types.

When the any media condition is used in a Capacity Rule, the maximum stated number of interactions is allowed for any single available media type (not for all media types combined). For example, if the maximum allowed number of interactions is 5, the condition is met when there are 5 chat interactions or 5 email interactions; it is not met when there are 3 chat and 2 email interactions.

How to Use Capacity Rules

A useful application of resource capacity planning might be to create capacity rules and apply them to the following:

  • Agents or collections of agents (not agent groups) of different abilities. You can create different capacity rules for such cases and assign the different rules to agents who have different abilities. (At present, Stat Server does not support capacity rules for GroupAgents or GroupPlaces objects.) For example, you could create a Seasoned capacity rule and assign it to agents who can handle more chat interactions, for example, than less-qualified agents. (To the latter, you would assign any of the NewHire, AvgWorkload, or 1ChatOnly capacity rules that you might create.)
  • Expert agents–preserving their time by setting an artificially low setting of capacity, to prevent from overloading them.
Whether Stat Server considers (in its determination of resource capacity) the interactions that are initiated or received while the agent-associated directory number (DN) is in after-call work (ACW) status is configurable. For more information, see capacity-treat-acw-as-interaction.

Video: Creating Capacity Rules using GAX

This page was last edited on July 13, 2022, at 13:11.
Comments or questions about this documentation? Contact us for support!