top of page
Partners (3).png

PCC Upgrade Best Practice 

  • Rebuild screens into PCC 2.4 (legacy intent mapped into new UX)

    Action

    • Rebuild all PCC 1.1.1 screens into PCC 2.4 using the widgets framework.

    • Screens are not visually or structurally the same as 1.1.1 due to the new framework.

    • Business intent and information content are mapped from legacy screens into the new UX rather than redesigned.

    • No deliberate rethinking of user journeys, decision ownership, or capture points.


    Target State Score
    2 / 5

    Change Impact
    5 / 5

    • This is a completely different layout and user experience for agents and admins.

    • Users must relearn navigation, screen behaviour, and interaction patterns.

    • Training, SOPs, and support materials must be fully rewritten.

    • From an operational perspective, this feels like a major transformation.


    Business Benefit
    1 / 5

    • Despite the scale of change, this option is not perceived as a business uplift.

    • The new UX is effectively a technical re-skin of legacy screens.

    • Existing problems are carried forward into a new visual construct.
       

    What this option gets

    • PCC 2.4 implemented.

    • End-of-life risk for PCC 1.1.1 resolved.

    • Legacy screen content is available in the new framework.

    • Very limited opportunity to review or rationalise individual screens during rebuild.
       

    What this option does not get

    • No reduction in the 20+ screens and applications agents work across.

    • No simplification of user journeys or task flows.

    • No improvement in decision clarity or speed.

    • No resolution of existing user complaints relating to:

      • data inconsistencies

      • screen defects

      • duplicated capture

      • inefficient navigation

    • No meaningful productivity uplift.
       

    Accelerator

    • Cursor can support:

      • screen inventory and dependency mapping

      • rationalisation recommendations at a conceptual level

      • documentation of target layouts and rebuild plans

    • However, most screens still need to be rebuilt manually in PCC 2.4 configuration.

    • Opportunity for Cursor to review the virtual worklist concept:

      • Virtual worklists cannot be built natively in PCC 2.4.

      • Alternatives may include reporting-layer views or custom code solutions.
         

    Key Risks and Considerations

    Business Risk

    • High change fatigue driven by visible UX change without outcome improvement.

    • Strong risk of negative user sentiment: “everything changed, nothing improved”.

    • Productivity dip during transition with no recovery upside.

    • Increased reliance on workarounds and shadow systems.
       

    Delivery Risk

    • Screen rebuild effort is often underestimated due to assumed similarity.

    • Widget-driven UX introduces new defect patterns and data dependencies.

    • High UAT volumes driven by usability and behaviour differences, not functional failure.

    • Risk that rebuild absorbs capacity needed for higher-value improvements elsewhere

  • Rebuild screens using Mini Apps

    Action

    • Rebuild collections screens using Mini App architecture rather than PCC 2.4 native widgets. 

    • PCC 2.4 remains the execution, decisioning, and audit layer, not the primary user interface.

    • Leverage existing core customer and account screens rather than rebuilding them in PCC.

    • Align collections UX with the broader Mini App ecosystem rather than treating collections as a standalone build.


    Target State Score
    5 / 5
     
    Change Impact
    4 / 5

    • Material change to how users interact with collections, but with a clearer and more intuitive UX.

    • Reduced retraining compared to Option 1 due to reuse of common customer and account screens.

    • Change is perceived as purposeful rather than technical.
       

    Business Benefit
    5 / 5

    • Significant reduction in the number of applications and screens agents must work across.

    • Direct integration with other Mini Apps, including provisioning and real-time data views.

    • Reduction in PCC screens by using core customer screens as the primary interface. 

    • Enables a common dashboard model, including the ability to pull Pega views into a single interface, reducing platform sprawl. 

    • Creates alignment with future Mini Apps such as Knowledge AI.

    • Positions PCC as a decision engine and system of record rather than a front-end UI.
       

    What this option gets

    • Immediate alignment to the target-state architecture.

    • Material reduction in PCC data requirements, improving batch performance and stability.

    • Clear separation between:

      • capture channels

      • decisioning and execution

      • audit and regulatory traceability

    • Enables external and digital channels to capture information, with PCC acting as the authoritative decision and audit layer.

    • Supports Care and CAT operating models following a one-way, same-way execution pattern. 
       

    What this option does not get

    • Virtual worklists are still not natively solved and require a separate design decision.

    • PCC-native work allocation constraints still apply underneath the Mini App layer.

       

    Key Risks and Considerations
     
    Business Risk

    • Core dependency on PCC 2.4 being delivered and stable.

    • Competing priorities with other PCC-dependent projects.

    • Risk that collections requirements are deprioritised relative to broader Mini App initiatives.
       

    Delivery Risk

    • Scope creep if Mini App capability expands beyond agreed collections needs.

    • Dependency on prioritisation and capacity of the Mini App team (not OOM).

    • Risk of delaying other projects that are dependent on PCC if sequencing is not tightly managed.
       

    Accelerator

    • Cursor is already building Mini Apps at speed. 

    • Approximately 125 screens fall away, leaving only:

      • container screens

      • collections-specific screens

    • No requirement to rebuild core customer or account screens.

    • Decouples collections UX from PCC proprietary configuration, providing greater control and flexibility.

    • Screens are built within the scope of existing or approved PCC 2.4 functionality. 

    • No reinvention or redesign of business requirements; this is a change in delivery mechanism, not intent.

  • Retain legacy PCC 1.1.1 screens within a PCC 2.4 environment

    Action

    • Seek agreement from Experian to retain or retrofit PCC 1.1.1 legacy screens within the PCC 2.4 environment. 

    • Minimise UX change by preserving existing screen layouts and workflows.

    • Treat PCC 2.4 primarily as an infrastructure and compliance uplift rather than a functional or UX change.
       

    Target State Score
    1 / 5
     
    Change Impact
    2 / 5

    • Minimal visible change to the user experience.

    • Existing navigation, layouts, and workflows are retained.

    • Training effort is largely avoided.
       

    Business Benefit
    1 / 5

    • Preserves current user familiarity.

    • Avoids immediate retraining costs.

    • Resolves the most pressing end-of-life concern in the short term.
       

    What this option gets

    • Short-term resolution of the PCC 1.1.1 end-of-life issue.

    • Continuity of the existing user experience.

    • Minimal change management and training requirements.
       

    What this option does not get

    • No progression toward a viable target state.

    • No reduction in technical or architectural complexity.

    • No improvement in UX, data quality, or defect patterns.

    • No foundation for future Mini App or digital channel integration.

    • No incentive or structural pathway to revisit and fix the underlying problems later.

       

    Key Risks and Considerations

    Business Risk

    • High risk of creating a “Frankenstein” architecture that solves the immediate burning issue while entrenching longer-term problems. 

    • Strong likelihood that once the immediate pressure is removed, no further investment is made to properly fix the environment.

    • Works only as a short-term measure if PCC is not intended to be retained long-term.

    • Any benefit from UX continuity is outweighed by the risk of future instability and remediation effort.
       

    Delivery Risk

    • Retrofitting legacy screens into PCC 2.4 may take longer than a clean rebuild.

    • High likelihood of introducing new defects and regressions due to architectural mismatch.

    • Debugging and support complexity increases materially.

    • Vendor supportability and future upgrade paths may be compromised.
       

    Accelerator

    • None material.

    • This option is heavily dependent on Experian agreement and bespoke engineering.

    • Any acceleration achieved in the short term is likely offset by rework and instability later.

  • While this option appears attractive from a change and training perspective, it is strategically weak. It resolves the immediate problem without addressing the actual issues and materially increases the risk of future failure.

    If PCC is intended to remain a core platform, this option delays the inevitable at a higher eventual cost.

  • 1. Data Layer Design and Availability
    Scope

    • Attribute definition and ownership

    • Aggregations and derived fields

    • Performance and batch impact

    • Alignment between CDL, PCC-native data, and reporting needs

    This underpins every other component. Decisions here directly affect widgets, APIs, reporting, and performance.

    ​

    2. PCC 2.4 Widget Configuration Capability and Constraints

    Scope

    • What can and cannot be built natively in widgets

    • Limits on layout, interaction patterns, and worklist behaviour

    • Dependency on PCC-supported configuration versus custom solutions

    This is where many “assumed capabilities” break during delivery.

    ​

    3. Activity UX Design and Supporting Data Structures

    Scope

    • How activities are presented to users

    • What data is captured, validated, and written back

    • Differences between TM activity behaviour and PCC 2.4 expectations

    • Audit, controls, and downstream impacts

    Activities are often treated as small, but they drive a disproportionate amount of rework.

    ​

    4. API Usage Decisions (Screen-Driven vs External Capture)

    Scope

    • Which processes are executed via PCC screens

    • Which are executed via defined PCC APIs (e.g. arrangements)

    • Which APIs mutate data only (flags, attributes)

    • Channel ownership (portals, Mini Apps, PCC)

    This is a strategic architectural decision, not a technical afterthought.

    ​

    5. Reporting Requirements

    Scope

    • What must be visible to users in real time

    • What must be auditable for risk, compliance, and regulators

    • What can sit outside PCC versus what must be system-of-record

    • Rebuild of legacy TM reports

    This is where many PCC programs fail silently until audit.

    ​

    6. Training, SOPs, and Operational Readiness

    Scope

    • Training effort driven by UX and workflow change

    • SOP rewrites and control documentation

    • Operational cutover and stabilisation

    • Support and BAU ownership

    This is the human cost of every technical decision above.

    Core Execution Components

    These are the engine-level components that will also need Option 1 / 2 / 3 treatment.

    ​

    7. Segmentation

    • Ownership of decision logic (SM vs PCC vs legacy)

    • Object level (account, customer, group, case)

    • Regulatory explainability

    • Drift, challengers, and maintenance

     

    8. Routes

    • Automated treatment paths

    • State management and lifecycle progression

    • Dependency on segmentation outcomes

    • Embedded legacy logic risk

     

    9. API (Execution and Data Mutation)

    • Process APIs (e.g. payment arrangements)

    • Data update APIs (flags, attributes)

    • Event triggers and sequencing

    • Failure handling and reconciliation

    Distinct from API usage decisions above. This is about what exists and how it behaves.

    ​

    10. Events

    • System and business events

    • Triggers for segmentation, routing, activities, reporting

    • Timing and sequencing issues

    • Dependency on batch vs real-time processing

    Often invisible until something goes wrong.

    ​

    11. Groovy Scripts

    • Custom logic embedded in PCC

    • Control overrides and edge-case handling

    • Upgrade and support risk

    • Long-term maintainability

    This is where technical debt hides.

    ​

    12. Tasks

    • Task creation and lifecycle

    • Ownership and assignment

    • Relationship to worklists and activities

    • Backlog visibility and ageing

    Critical for operational control and MI.

All Posts

bottom of page