Configuring payment plans
You can use Pega Collections to configure debt repayment programs that help customers who are in collections pay off their debt. Payment plans are easily configurable Customer Decision Hub actions that the CSRs can use during live interactions when they run the Schedule payment plan service request.
Configuration steps
Consider a business scenario: U+ Bank, a retail bank, wants its CSRs to offer a new payment plan to customers who are in collections. U+ Bank needs to configure the payment plan to spread the customers' default into three equal installments.
To implement this business requirement, log in to Pega Customer Decision Hub™ as a Business user. You can create a new payment plan action by using Pega 1:1 Operations Manager.
As a business user, you create a change request to capture the business context of the required change.
The change request category indicates the type of change. In this case, you want to create a new payment plan, so click Create >Action.
In the action creation window, you can select the pre-defined action type, that most closely matches the use case or you can create the custom action change request. Opting for the predefined action type automatically populates certain data within the change request.
In the change request form, enter a name that describes the purpose of the request.
As a business user, you provide the completion date as the expected timeframe in which the next-best-action specialists complete the request.
You can use the Description section to provide any additional business details that are useful for the next-best-action specialists.
Create the new change request.
The change request is currently in the Plan stage.
Observe that the first task to be completed is . The purpose of this task is to capture additional details from the business user about the new action to help the next-best-action specialists who work on it later.
In the Define attributes section, enter a name for the new action. Add the description of the payment plan and select the appropriate Business issue and Group.
In the Define attributes Stage, you can also provide details about the purpose of your action or upload the marketing brief file to generate the Marketing Summary.
Customer Decision Hub uses this information as input for large language models (LLMs), along with elements such as Brand Voice and Cialdini’s principles, to generate consistent and effective treatment content across channels.
The Marketing Summary feature is available only when Pega GenAI™ capabilities are enabled.
Continue to define availability.
In the Define availability section, you can provide details on action availability.
Click to define the engagement policy.
Select the Use condition builder option to see four categories to define the criteria.
Eligibility rules are rules that qualify a customer for an action. For example, the customer is in collections.
Applicability rules are factors that determine if an action is appropriate at this point for this customer. For example, the customer has an active payment plan.
Suitability rules are conditions that determine if an action is deemed appropriate and is in the best interest of the customer. For example, customer is alive.
Contact policy conditions help avoid customer fatigue through over-communication.
Continue to define the treatments.
In the Define treatments section, you can select the channel and add details about the channel in which the action is presented.
As a team lead, you are responsible for two tasks in the Plan stage.
The first task is to prioritize the available change requests so that the NBA Specialists can plan their day and work on the most important tasks first.
The second task is to assign peer reviewers to verify the engagement policy defined in the Build stage.
You must first rank the change request. By default, the rank of a new change request is 0. In the Rank field, provide a numerical value that represents the relative priority of the change request compared to others in the work pool.
Proceed to the next task.
Now assign a peer reviewer. A peer reviewer can be any operator who can verify the change request details given by the business user against the configuration made by the NBA Specialist. In this case, the peer reviewer is the business user.
Complete the task.
As an NBA Specialist, you can access the change request that is in the queue on the Change requests landing page. Open the request.
As an NBA Specialist, you have various build tasks to complete that the system generated to implement the business requirements that the business user defined. In this case, you have three tasks.
The Define action details task corresponds to defining the basic action attributes. Assign the task to yourself and continue. The fields are prepopulated with values based on the information that the business user provided when creating the change request. However, you can change the prepopulated values in this Build task.
The fields correspond to the action attributes in Pega Customer Decision Hub™. For example, Name is the action name, and Business issue and Group decide the categorization of the action in the business hierarchy. Ensure that the Availability>Always is selected. Complete the task.
On the Configure engagement policy tab, you can view the engagement policy that the business user defined per the business requirement.
The last task is to design assist treatment for the action. Enter the respective details and complete the task.
Generate artifacts from tasks.
Validate and approve the generated artifacts.
As the Team Lead, open the change request to verify it. Approve the change request to promote it to the Deployment Stage.
As a revision manager, you need to push the changes made by the business operations team to the pipeline for deployment. Access the change request by clicking Revision Management in the navigation pane.
You can see the change request in this revision. Now, continue to the validation stage, write a comment, and continue.
Check the status of the artifacts to validate the revision. Once the status is pass, you can deploy the revision and complete the change request.
The revision changes are first queued and then get merged to the deployment pipeline.
With this pipeline, you can merge changes to the development system of record, version the application, and generate a release artifact.
Deployment Manager then deploys the artifacts to the production environment.
Complete the revision.
This Topic is available in the following Module:
Want to help us improve this content?