Screen Pop Identifies the Wrong Customer on Inbound Calls
A health insurer runs Pega Customer Service 23.1 with a CTI integration from a cloud contact center. On an inbound call, the CTI CallOffered event passes the calling number to the interaction portal. A data page named D_CustomerByPhone is requestor-scoped with DoNotReload and uses a report definition on the external data source. Phone numbers are stored in the source as (555) 123-4567 but CTI passes 5551234567. The screen pop takes 11 seconds, and 9% of calls show No customer found. In 3% of calls, the previous caller's name and policy appear. Agents sometimes create a new customer record for an existing caller, producing duplicates. Average call duration is 6 minutes; 28% of calls are from members calling about a dependent. The business wants screen pop under 3 seconds and no wrong-customer incidents.
1. Diagnose the wrong-customer and no-match symptoms.
Read the worked answer
Two separate defects share one symptom. The wrong-customer display is a scope problem: D_CustomerByPhone is requestor-scoped and DoNotReload, so the first successful lookup stays in the requestor for the session; when the next CTI event fires, the section can render the old page before or instead of a new lookup. The no-match is a data problem: the source stores (555) 123-4567 while CTI sends 5551234567, so an exact-match report definition finds nothing.
The 11-second pop is likely the report definition running against the external source on each event, with no normalized key or index. The dependent case adds ambiguity: the phone identifies the member, but the call may be about a dependent, so a single customer match is not the same as the right patient. These are not solved by adding a spinner; they need scope, normalization, and an explicit identity-resolution step.
2. Design the identity resolution and screen-pop flow.
Read the worked answer
Normalize before lookup. In the CTI event handler, run a data transform that strips non-digits and stores a normalized key; ensure the customer source has the same normalized key and an index. Make D_CustomerByPhone thread-scoped with Reload once per interaction, and pass the normalized number as a parameter. The CTI CallOffered event should call an IdentifyCustomer flow: lookup by phone, then by member ID or account number if the caller provides it; if exactly one match, open the interaction with that customer; if multiple, show a disambiguation list; if none, open an Unidentified interaction and offer search or create, with duplicate checks.
For dependents, after the member match, display the policy members and let the agent choose the patient, rather than assuming the caller is the patient. Target the 3-second pop by using an indexed lookup service or a cached node-scope reference table, not an unindexed report definition.
3. What safeguards would prevent duplicate customer creation?
Read the worked answer
Before any create, search on normalized phone, email, and member ID, and show possible matches even when the phone lookup failed. Do not auto-create on a no-match; open the unidentified interaction with a Create customer action that requires the agent to confirm no match. In the create flow, run a duplicate-check data transform and surface a warning with the candidate records; allow override only with a reason code.
Keep the thread-scoped data page so a new call cannot show the prior caller's record, and add an audit event whenever a customer is created from the interaction portal. Measure duplicate-creation rate weekly and review the no-match calls; many are format or dependent issues, not new customers. This combines prevention at the UI with detection in reporting.