Volume constraints

Within a volume constraint definition, you can define the combination of constraints for one or more actions with one or more channel types.

In situations where a customer is eligible for multiple actions, you can apply volume constraint with one of three modes, depending on the business requirement. You might specify whether to apply volume constraints to actions as a group (for which a customer qualifies) or evaluate each action for which a customer qualifies separately.

Individually for each action

In this mode, the top action for which a customer qualifies passes through the set of defined volume constraints, and the system validates each action against each constraint type. If the action passes through all the constraints, the system selects the action and delivers it to the customer. The customer always receives a maximum of one action, even though the limits for the other low-priority actions is not reached. The top action is selected based on priority calculations (p*c*v*l) defined in Next-Best-Action Designer arbitration.

For example, consider a customer who is eligible for the Standard card, Rewards card, and Rewards Plus card credit card actions, and the Standard card is the top priority card. Also, assume that the remaining volume for the top action (Standard card) and priority 3 action (Rewards Plus card) is above zero, and the remaining volume for the priority 2 action (Rewards card) is zero. When you set volume constraints mode to Individually for each action, the customer sees only the top priority action, Standard card, as shown in the following figure:

If the volume remaining for the top priority action is zero, then the next priority action is validated against the constraint types.

Return any action that does not exceed constraint

In this mode, each action a customer qualifies for passes through the set of defined volume constraints, and the system validates each action against each constraint type. If an action passes the set of constraints, the system delivers the action. If an action does not satisfy a constraint, the system does not deliver an action. The system considers all actions for which a customer qualifies, and the order in which the check occurs is irrelevant. The result is that a customer receives all the actions for which they qualify provided that the actions do not reach the volume limit. The Return any action that does not exceed constraint mode is the recommended approach, even though the system does not consider priority during the volume constraint phase. This mode ensures that the limit handling is separated from arbitration logic.

For example, consider a customer who is eligible for the Standard card, Rewards card, and Rewards Plus card actions. Also, the remaining volume for Standard card and Rewards card is above zero, but the volume of the Rewards Plus card action reached zero. When you set volume constraints to Return any action that does not exceed constraint, the customer receives Standard card and Rewards card but not the Rewards Plus card, as shown in the following figure:

When the system evaluates each action separately, Pega Customer Decision Hub can present all actions that pass the engagement policy conditions to the customer.

Volume constraints fall into three categories depending on the level at which you apply the constraints: action, channel, or property, as shown in the following figure:

Action constraint

An action constraint limits the volume of actions that the system can send to customers.

An action constraint is useful when you have a limited number of actions that you can send to customers, for example, 500 gift vouchers. Configuring an action constraint ensures that you do not offer more actions than are available.

Channel constraint

A channel constraint limits the volume of actions that the system can deliver through a certain channel.

You can use a channel constraint for channel capacity planning. For example, assume that your call center can only handle up to 1000 inbound calls daily due to limited capacity. If your company sends out 50,000 emails per day to customers, it's reasonable to anticipate that 2-3% of the recipients may follow up with an inbound call, which translates to approximately 1000-1500 calls daily. This volume of calls would exceed the capacity of your inbound call center. Therefore, to prevent the call volume from surpassing the handling capacity, it would be necessary to restrict the number of outbound emails sent to 35,000 per day.

Property constraint

By default, actions fall into the issue-group business hierarchy. By using a property constraint, you can limit the volume of a set of actions across different issues and groups by grouping them using a property value.

For example, you can group all credit card actions by setting a property, CreditCardType, to VISA. Then, you can define a constraint to limit the action volume where you do not want to send more than 500 VISA credit cards in a month.

In an outbound run, the system considers a segment of the audience for an outbound communication. When customers are eligible for multiple actions, the system applies volume constraints across customers to limit the volume of actions that it delivers. After the next-best-action logic runs, the system executes the volume constraint limits in a non-predefined order of the customers.

Consider a simplified example of five customers to better understand how the limit constraint engine works. The following table shows the set of customers from the audience, the actions for which they qualify, the channel for which a treatment is defined, and the priority of the action. The priority represents the final priority calculation (p*c*v*l) as defined in the Next-Best-Action Designer arbitration.

The following table shows the volume constraints configured in the system. There are two types of volume constraints configured:

1. A channel constraint with a limit of 2 actions for the Push channel.
2. An action constraint with a limit of 1 for the BOGO action.
   

Mode 1: Individually for each action

If there are no volume constraints configured for a particular channel, action, or property, the system does not apply limits, and the actions pass through for outbound communication.

Therefore, CUST-02 and CUST-04 pass through as there are no limits defined for these actions (Gold Card and Free Shipping) or channel (Email, Direct mail).

The system considers the rest of the customers in a non-predefined order. Assume that it picks CUST-03 and CUST-05 first. Note that for CUST-03, the system chooses the BOGO action with higher priority. In this mode, the system delivers only one action for each customer and ignores the other two actions.

CUST-05 qualifies for two actions: BOGO (priority 50) and Free Shipping (priority 25). Because the system picked the BOGO action for CUST-03 and exhausted the action limit, it selects the next action, Free Shipping, for CUST-05.

Because the system selected two Push channel actions and one BOGO action, both reach their volume constraint limits, and CUST-01 receives no action.

Mode 2: Return any action that does not exceed constraint

CUST-02 and CUST-04 pass through as no limits are defined for these actions.

Assume that the system picks CUST-03 and CUST-05 first. In this mode, CUST-03 receives all the actions for which they qualify because the actions did not reach the limit.

CUST-05 receives only the Free Shipping action and not the BOGO action, as the BOGO action reaches the volume constraint limit when the system offers the action to CUST-03.

Finally, CUST-01 does not pass through because the Push channel reaches the volume constraint limit.