Pega Customer Service Developer study materials
Pega Customer Service Developer study resources

Pega Customer Service Developer: Customer Service Implementation

Pega Customer Service Developer · Work through your exam, one topic at a time.

All guide sections

Customer Service Implementation

Customer Service Implementation

This domain tests whether you can turn a customer-service requirement into a working Pega Customer Service application. Expect questions on the Interaction case, service case types, the Account–Contact data model, SLAs, routing, and the rules that connect them. The exam tests design inside the Pega Customer Service framework.

Core rules and concepts

  • The Interaction case is the contact container. CSRs start an interaction, verify the customer, then launch service cases from it. Service cases inherit context (customer, account, channel) from the interaction.
  • Model the customer using Pega Customer Service data types: Account, Contact, and relationships. Service cases reference these rather than duplicating customer fields.
  • Service case types represent the work (e.g., Address Change, Billing Dispute). Use service intents and tasks where the framework expects them; do not create a new top-level case for every sub-step.
  • SLAs on service cases drive due dates and escalation. Assign goals and deadlines at the case-type level, then let routing move work to queues or skills.
  • Use data pages for customer and reference data so the UI and case rules read current values. Avoid connectors inside UI rules.

Worked example

A utility company needs a 'Meter Reading Dispute' case. The CSR opens an Interaction for the account, selects the meter, and creates the dispute. Design: create a service case type 'Meter Reading Dispute' with a data reference to Account and Meter; add an SLA of three business days; route to the Billing Disputes queue; expose a 'Create Dispute' action on the Interaction. Reasoning: the Interaction supplies customer context, the service case owns the work and SLA, and the data reference keeps customer data authoritative. If you instead create a standalone case, you lose the interaction audit trail and the CSR's context.

Traps

  • Treating the Interaction as a service case, or creating service cases outside it.
  • Hardcoding customer IDs instead of using data references.
  • Putting SLAs on the Interaction when the service case owns the deadline.
  • Forgetting to add the new case type to the application and access roles.
  • Using a connector in a section instead of a data page.