HiQOR

Architecture Overview

Insurance Flow Architecture

Collaborative system view to align on integration and conversion approach

Race FlowGym FlowCarrier Integration

Race Registration Flow (Partner-Controlled Environment)

Primary Integration Flow

HiQOR receives/originates records, normalizes payloads, and routes consent-aware flows to Olli and carriers

API Integration Layer
Secure endpoints (AWS) · Token auth · Flow-specific routing
1

Stage 1

Orchestration at HiQOR

Race Platform

Spartan / TicketSocket / Active / etc

  • User registers for race event
  • AD&D awareness + opt-in presented at checkout (TCPA consent capture TBD)
  • Registration + AD&D preference data emitted to HiQOR

Race partner generates/distributes Olli activation link/session

One-way activation handoff into Olli ecosystem

Registration + event data

HiQOR

Central Orchestrator · System of Record

  • Generate UUID for this lead
  • Evaluate initial consent state

Engagement Lanes in Olli

All users route into Olli. These lanes describe how engagement plays out downstream — not routing decisions made at HiQOR.

Lane A · AD&D bind → Olli ecosystemTransactional
Lane B · Post-bind engagement → Olli ecosystemTCPA req'd
2

Stage 2

Parallel Execution in Olli

Olli Platform

Parallel execution engine

UUID-linked

Track A · AD&D Binding

Transactional
  • Immediate / transactional execution
  • AD&D policy binding
  • Carrier communication

Track B · Post-Bind Engagement

TCPA required
  • Additional engagement consent captured post-registration
  • SMS / Email engagement (Olli or HiQOR)
  • Call center outreach (Olli)
  • Product quote flows (life insurance, training insurance, etc.)
  • Policy bind on acceptance

Events + Policy Data → HiQOR

Returned for attribution, reconciliation, and lifecycle reporting

3

Stage 3

Closed-Loop Return + Carrier

HiQOR Orchestration + Reporting Layer

Maintains attribution, reconciliation, reporting, and downstream carrier alignment

  • Maintains user-level attribution and lifecycle tracking across partner ecosystems
  • Reconciles UUID + consent context across registration and conversion flows
  • Receives conversion events, engagement signals, and downstream lifecycle activity from Olli
  • Routes enriched user + conversion data to Mutual for attribution, billing triggers, and lifecycle reporting
Carrier lifecycle reporting

Carrier Layer

Mutual / Allstate / etc

  • Receives bound policy data
  • Underwrites AD&D coverage
  • Issues AD&D and life insurance products

Stages flow: 1 → 2 → 3 (left-to-right on larger screens)

OrchestrationTransactional laneAsync laneClosed-loop return

1) Orchestration at HiQOR

  • Race or microsite data lands in HiQOR first.
  • HiQOR evaluates initial consent state and routes to Olli.
  • AD&D bind always executes. Post-bind engagement depends on TCPA consent — which can be captured in Olli, not necessarily at registration.

2) Execution in Olli

  • Once a user binds AD&D coverage, Olli can engage them digitally within its ecosystem — no TCPA required for in-product digital engagement.
  • TCPA consent is required only for outbound channels (SMS, email, call center) and can be collected inside Olli at any point.
  • Both paths remain linked to the same HiQOR UUID.

3) Data loops back to HiQOR

  • Olli returns execution data to HiQOR before carrier routing.
  • Application status + policy status.
  • Product type + premium.
  • Lifecycle timestamps for operational reporting and reconciliation.

Integration Model (High-Level)

  • HiQOR exposes secure API endpoints (AWS-based).
  • Endpoints vary by workflow context (race registration, gym/microsite, and partner paths).
  • Partners authenticate using token-based credentials.
  • Requests include user data, initial consent state, and routing context. TCPA consent for outbound channels may be captured in Olli post-bind.
  • Olli processes the selected flow and returns real-time status + event data to HiQOR (no batching or aggregation).

System of Record + Data Requirements

HiQOR responsibilities and the required data contract with Olli

HiQOR Responsibilities

Identity & Matching

  • Lead UUID

    Primary identifier for all downstream systems

  • Email

    Secondary match key for reconciliation

Routing & Orchestration

  • Consent-aware routing

    Routes to Olli; TCPA evaluated for outbound channels, capturable in Olli

  • Trigger AD&D vs Conversion

    Downstream flow management

  • Manage downstream integrations

    Orchestrates Olli and carriers

Reconciliation & Billing

  • Policy attribution

    Source of truth for partner credit

  • Revenue tracking

    Partner and channel reporting

  • Billing source of truth

    Canonical billing record

Required Data from Olli

Identity

  • UUID

    Must be returned — primary join key

  • Email

    Match key for deduplication

Application + Policy

  • Application status

    Started, completed

  • Policy status

    Submitted, bound, declined

  • Product type

    AD&D vs Life / Upsell

  • Premium

    For billing and attribution

Event Timestamps

  • Outreach initiated

    Timestamp — required

  • Application started

    Timestamp — required

  • Policy bound

    Timestamp — required

System Responsibilities

Clear ownership boundaries between HiQOR and Olli

HiQOR

System of Record
  • UUID / identity layer across partner and downstream systems
  • Payload transformation and normalization layer
  • Consent-based routing layer for allowed actions
  • Carrier data routing layer
  • Operational reporting layer

Olli

Execution Layer
  • AD&D binding layer
  • Digital insurance experience layer
  • Conversion/upsell execution layer
  • Engagement layer where permitted (SMS/email)
  • Returns event and status data to HiQOR

Flow Comparison

Key differences between Race and Gym integration paths

Race Flow

Partner-led
  • Partner-controlled UI and checkout
  • Limited embedding options without partner work
  • Handoff-based conversion — user leaves partner site
  • Post-registration SMS/Email is primary today

Gym Flow

HiQOR-led
  • HiQOR-controlled UI — no partner dependency
  • Flexible embedding and entry point control
  • Immediate handoff supported natively
  • Direct conversion paths with higher conversion potential