Optimizing Insurance Conversion: Strategic Decision-Making in Complex Org Structures

Led the strategic design and implementation of a creditor insurance widget that resolved complex inter-departmental collaboration challenges between Banking and Insurance teams. Conducted comprehensive analysis of inflow vs. post-activation placement options, optimizing for revenue impact while balancing technical complexity and user experience trade-offs.

Client

RBC Insurance & Banking

Date completed

November 2024

Role

Product Manager, RBC

Creditor Insurance Widget - Optional insurance for royal credit line

The Challenge

The creditor insurance integration faced a fundamental organizational challenge: two departments with competing priorities and conflicting ownership models. The Banking department controlled the entire customer experience for line of credit and mortgage applications, while the Insurance department needed to make changes to insurance-related steps but had to wait for Banking team prioritization—creating bottlenecks and delays.

Line of Business Dynamics

Banking Department
  • Owned the complete customer experience for financial products
  • Focused on conversion rates and technical integration complexity
  • Prioritized their core product roadmap
Insurance Department
  • Needed to iterate on insurance offerings within Banking flows
  • Required autonomy to optimize their products
  • Lacked control over their customer touchpoints

Current State Problems

The existing model created operational inefficiencies that impacted both departments:

graph LR A[Insurance Team
Needs Changes] --> B[Request to
Banking Team] B --> C[Banking Team
Prioritization] C --> D[Development
Queue] D --> E[Implementation] E --> F[Release] style A fill:#e74c3c style B fill:#e67e22 style C fill:#e67e22 style D fill:#e67e22 style E fill:#f39c12 style F fill:#27ae60

Key Problems:

  • Dependency Bottlenecks: Insurance team waited for Banking prioritization, delaying improvements
  • Ownership Conflicts: Banking owned the entire experience, limiting Insurance's ability to iterate
  • Development Complexity: Every insurance change required Banking coordination, reducing agility

The Solution: Widget Architecture

I proposed creating a self-contained creditor insurance widget that could be owned and managed by the Insurance department while seamlessly integrating into Banking flows. This approach would minimize Banking development work while giving Insurance the autonomy they needed.

graph TB subgraph "New Model: Widget Architecture" A[Banking Flow] --> B[Integration Point] B --> C[Insurance Widget] C --> D[Shared Screens] D --> E[Complete] F[Insurance Team] -.->|Owns & Iterates| C G[Banking Team] -.->|Owns| A H[Both Teams] -.->|Collaborate| D end style C fill:#3498db style A fill:#2ecc71 style D fill:#9b59b6 style F fill:#3498db,stroke:#2c3e50,stroke-width:2px style G fill:#2ecc71,stroke:#2c3e50,stroke-width:2px style H fill:#9b59b6,stroke:#2c3e50,stroke-width:2px

Widget Benefits:

  • Insurance team can iterate independently on their screens
  • Banking team maintains control of core banking experience
  • Shared screens enable cohesive end-to-end flow
  • Clear ownership boundaries reduce coordination overhead

Strategic Decision Framework

I led a comprehensive analysis of two placement options, evaluating multiple dimensions including technical complexity, revenue impact, user experience, and ownership autonomy.

The Two Options

Inflow Widget (During Banking Activation)

  • Technical Complexity: Moderate—required shared screens implementation
  • Revenue Impact: Faster uptake—users encounter insurance during active engagement
  • User Experience: Seamless—insurance feels like natural part of the process
  • Ownership: Partial—some screens shared with Banking
  • Integration: Complex—shared screens and content management

Post-Activation Flow (After Banking Completion)

  • Technical Complexity: Lower—standalone widget with single handoff
  • Revenue Impact: Potentially lower—risk of drop-off after primary task completion
  • User Experience: Seamless but separate—clear division between Banking and Insurance
  • Ownership: Full—Insurance owns all steps independently
  • Integration: Straightforward—single handoff point
Widget Inflow vs Widget Afterflow - Comparison of two placement strategies

Decision: Inflow Widget Approach

Despite the moderate technical complexity, I recommended and successfully advocated for the inflow widget approach. This strategic decision prioritized revenue optimization and user experience over technical simplicity.

Key Rationale:

  • Revenue Optimization: Capturing users during active Banking engagement would deliver significantly higher conversion rates than post-activation approaches, where drop-off was a significant risk
  • User Experience Excellence: Insurance would feel like a natural extension of the Banking process rather than an afterthought, increasing perceived relevance
  • Strategic Timing: Users were most receptive to additional financial products during their primary Banking task, not after completion
  • Manageable Trade-offs: The technical complexity could be addressed through careful shared screen architecture
graph LR subgraph "Decision Factors" A[Technical
Complexity] --> D{Inflow
Widget} B[Revenue
Impact] --> D C[User
Experience] --> D D --> E[Selected
Approach] end style A fill:#e67e22 style B fill:#27ae60 style C fill:#27ae60 style D fill:#3498db style E fill:#2ecc71

Inflow Integration Architecture

Insurance widget inflow user flow - detailed screen-by-screen architecture

Implementation Strategy

To address the technical challenges while maintaining departmental autonomy, I designed:

Shared Screen Components

  • Created shared screens for document review (Step 5) and final completion (Step 6)
  • Allowed both departments to maintain their experiences within a unified flow
  • Established clear ownership boundaries

Independent Insurance Screens

  • Steps 4a-4b fully owned by Insurance team
  • Enabled independent iteration without Banking coordination
  • Maintained widget encapsulation

Minimal Banking Development

  • Focused on simple integration points rather than custom implementations
  • Reduced Banking team burden while enabling Insurance autonomy

Impact

Revenue Optimization

Strategic inflow placement decision maximized insurance uptake by capturing users during peak banking engagement, delivering projected revenue improvements through higher conversion rates compared to post-activation alternatives.

Departmental Autonomy

Successfully resolved inter-departmental collaboration challenges by giving Insurance team ownership over their widget while enabling seamless integration into Banking flows, eliminating dependency bottlenecks and enabling independent iteration cycles.

Technical Architecture

Designed shared screen architecture for document review and completion phases, balancing technical complexity with business requirements while maintaining clear ownership boundaries between Banking and Insurance systems.

User Experience Excellence

Created cohesive banking-to-insurance flow with optimized form design, progress indicators, and seamless transitions, making insurance enrollment feel like a natural extension of the banking process rather than a separate experience.

Scalable Framework

Established reusable decision framework and integration patterns for future cross-departmental product collaborations, providing systematic approach to complex trade-off analysis and technical implementation strategies.