Capacity Planning

How Stat Server Handles Invalid Rules

If a capacity rule is invalid or missing, then the capacity rule for the next object in the chain of precedence prevails. If no rule applies at all to an object (because of invalidity or because no rule was assigned to the object), then the inherent Default capacity rule applies to the object. Refer to Capacity Rule Inheritance to learn which links contribute to the chain of precedence.

<tabber>

New Agent-Place Model=

Capacity Planning for New Agent-Place Model

Stat Server 8.1.0 and lower releases (8.1.0^-) always checked which place a DN belonged to as part of its algorithm for determining capacity. With this information, Stat Server 8.1.0^- was then able to link an agent, who was logged in to the DN, to the place. In a SIP Cluster environment, however, you do not create DN objects in Configuration Server (where Stat Server looks for DNs). Instead, DNs are managed within the SIP Cluster solution. Given this DN-less model and the independence that Agent and Place objects gained in the 8.1.2 and higher releases (8.1.2⁺), there is no theoretically correct way that the model used by Stat Server 8.1.0^- can associate an agent with a place. And, with multiple and different types of clients (multiple types of T-Server, SIP Server, and Interaction Server) - each potentially reporting different kinds of associations between agents and devices - there is no single entity in which Stat Server 8.1.0^- can maintain a one-to-one constraint of agent to place. So, the model in Stat Server 8.1.2⁺ was improved primarily for scalability but also to address this SIP Cluster environment.

Stat Server 8.1.2⁺ does not require that a DN be assigned to a particular place for the purposes of agent or agent-group reporting. In the 8.1.2⁺ release, when Stat Server receives the EventAgentLogin TEvent, Stat Server tries instead to identify the agent in configuration by matching the AgentID attribute of the TEvent with the EmployeeID attribute of an agent (Person object) in configuration. If Stat Server succeeds in finding a match, Stat Server then is able to link the configured agent to the DN. Any agent-state changes or interactions occurring at the DN can then be attributed to the agent for determining capacity. In this model, there is no association at all between agent and place.

Capacity Rule Inheritance

Capacity rule inheritance in the Stat Server 8.1.2⁺ release also differs from that of the Stat Server 8.1.0 release.

In the 8.1.0 release, Stat Server is able to create an implicit relationship between an agent and a place as described above. You can assign capacity rules to both Agent and Place objects in configuration (to Tenant object as well), and Stat Server will determine which rule prevails:

• If the agent has an explicitly defined and valid capacity rule, then that rule overrides the capacity rule that might be assigned to the place.
  
• If no capacity rule is assigned to the agent, the capacity rule explicitly assigned to the place prevails.
• If no capacity rule is assigned to the agent or the place, then the capacity rule explicitly assigned to the tenant prevails.
• If no capacity rule is assigned to the agent, the place, or the tenant, the inherent default capacity rule of no more than one voice interaction prevails.

Stat Server 8.1.2⁺ does not associate agents with places as it did in prior releases. The reasoning behind this improved logic enables advanced configurations where:

• Two (or more) DNs could be associated with one place. This configuration allows two independent agents to log in to these DNs.
• One agent might be logged in to more than one DN. This configuration allows DNs to belong to different places.

In both cases, Stat Server aggregates information without having to determine which one agent should be associated with the one place.

The Capacity Vector

The Universal Routing Server (URS) requests four statistics from Stat Server in order to determine which contact center object has the capacity to receive a routed interaction. The statistics all share the same statistical category (CurrentTargetState), but they each differ in object:
Agent, Place, GroupAgents, GroupPlaces

If an interaction appears on a DN, Stat Server 8.1.0^- reflects this information in the capacities of the corresponding Place and GroupPlaces objects. And, by association, this interaction would also be reflected in the capacities of corresponding Agent and GroupAgents objects. Stat Server 8.1.0^- returns one capacity vector only to URS when all four CurrentTargetState statistics are opened for the associated object.

In the 8.1.2⁺ release, however, Stat Server must send two capacity vectors - one vector for Place and GroupPlaces objects, the other for Agent and GroupAgents objects - because agents and places are not linked in this release.

|-| Voice Interactions=

Capacity Planning for Voice Interactions

Because many different types of telephony devices are continuously being developed, attention should be paid during capacity planning to some peculiarities in the ways that Genesys software routes voice interactions. Genesys software continually evolves to meet new capabilities. Whereas the initial release of capacity planning limited the number of voice interactions that the Genesys router could direct to a particular Genesys place to one, now the Genesys router can route more than one voice interaction to a Genesys place - under certain circumstances.

Tip

A single-DN place is a device that has only one directory number ascribed to it.
Multi-DN places or multiline DNs are devices that have more than one directory number ascribed to them.

As a general rule, in regard to Genesys environments that uses a nonSIP (Sessions Initiated Protocol) Server, Genesys capacity planning enables routing to single- or multi-DN places where an agent performs a login to each DN. When DNs exist at a place to which the agent does not log in, Genesys software does not consider those DNs in its calculation of resource capacity.

Routing of more than one call to a multiline DN within a Genesys environment is currently unavailable in this release. Meridian and Meridian Link Symposium phones, for instance, present special examples of multiline DNs that occupy two DNs for each Genesys place - a Position DN and an Extension DN. For this particular configuration, the Genesys Stat Server logs DN status against the Position DN, but only the Extension DN is accessible to the Genesys router for directing calls. Ensure that you consider this when incorporating capacity planning into your routing strategies. IVR phones present additional examples of multiline DNs for which the Genesys capacity model is unable to direct more than one voice interaction at a time.

There are two exceptions to this general rule:

• The Genesys router can route calls to voice treatment port DNs (IVR DNs) without requiring that agent logins be simulated on these DN types.
• In a Meridian 1/Meridian Link Symposium model, it is the Position DN that the agent logs in to, not the Extension DN. However, the Genesys router routes calls - one at a time - to the Extension DN, given an agent login on the Position DN.

|-| Multimedia DNs=

Capacity Planning for Multimedia DNs

Prior to the 7.6 release, Genesys capacity planning, from the routing perspective, treated multiline DN devices (such as IP phones that have simultaneous video and multiline DN capabilities) as single-line, voice DNs. Genesys software permitted the routing of one and only one voice interaction, for instance, to these DNs, provided that no other voice interaction was already occurring at the DN. The presence of an interaction on a DN prevented the routing of another interaction to that DN, even though the DN was capable of handling an additional interaction of a different media type. Furthermore, each DN was associated with a single media type.

The Stat Server 7.6 release introduced support for the multimedia DN - a DN type that is controlled by SIP Server.

Tip

A multimedia DN is a single directory number that can receive simultaneous interactions of more than one media type.

To specify the physical capacity of a multimedia DN, the voice configuration option was introduced in the Framework 7.6 release for Extension-type DN objects. Setting this option to true enables you to specify whether capacity for voice interactions applies to the multimedia DN. Multimedia DN capacity settings propagate to capacity rules for supported resources. Refer to the “Configuring DNs to handle instant messaging” procedure in the Genesys Instant Messaging Solution Guide for more information on this topic.

Unlike a single-media DN, a multimedia DN supports multiple media (for example, voice and chat) on each DN. Introduction of this multimedia DN to a Genesys contact-center environment enhances the resource capacity model by enabling the Genesys Universal Router Server (URS) to route multiple interactions to a single instance of such a DN. The model now enables URS to route one or more of chat and/or voice interactions to the same DN if the DN is configured as multimedia, its type is Extension, and the servicing T-Server is SIP-compliant.

To support this new functionality, the semantics of actions that are generated by Stat Server for statistic and status calculation of multimedia DNs have been updated. In addition to prior classifications, actions can now be media-dependent or media-independent. Furthermore, media-dependent actions can be further classified as media-unique or media-common.

An action is media-unique if only one action of a particular media type can exist on a device. For example, the LoggedIn action is media-independent. Generation of this action does not rely on the media channel to which an agent registers. Contrarily, the CallInbound action is media-dependent, because inbound interactions in the current capacity model are always associated with only one media type. Furthermore, the CallInbound action is media-common. In fact, all call-related actions are media-dependent and media-common. The WaitForNextCall, NotReadyForNextCall, and AfterCallWork actions that occur on multimedia DNs are classified as media-dependent and media-unique.

Prior classifications of actions ran along the following lines and are still applicable to multimedia DNs:

• Actions are either durable or instantaneous.
• Actions are either related to interactions or not.
• Actions are generated for either mediation DNs or regular (or multimedia) DNs.

Refer to the Framework Stat Server User's Guide for a complete listing of how Stat Server–generated actions are categorized.

Important

SIP Instant Messaging interactions and e-Services chat interactions use the same media type "chat", they cannot co-exist for the same Place/Agent. Such deployment is not supported by Genesys Capacity Model.