HiQOR
Insurance Flow Architecture
Collaborative system view to align on integration and conversion approach
Race Registration Flow (Partner-Controlled Environment)
Primary Integration Flow
HiQOR receives/originates records, normalizes payloads, and routes consent-aware flows to Olli and carriers
Stage 1
Decision at HiQOR
Race Platform
Spartan / TicketSocket / Active / etc
- User registers for race event
- Consent captured at checkout
- Registration data emitted
HiQOR
Central Orchestrator · System of Record
- Generate UUID for this lead
- Evaluate consent state (TCPA)
- Branch routing decision
Branch Outputs
Stage 2
Parallel Execution in Olli
Olli Platform
Parallel execution engine
Track A · AD&D Binding
Transactional- Immediate / transactional execution
- AD&D policy binding
- Carrier communication
Track B · Conversion / Upsell
Async- SMS / Email outreach
- Product quote flows (life insurance, training insurance, etc.)
- Policy bind on acceptance
Events + Policy Data → HiQOR
Returned before carrier routing
Stage 3
Closed-Loop Return + Carrier
HiQOR Routing Relay
Reconciles + forwards canonical bind data
- Accepts returned events from Olli
- Reconciles UUID + consent context
- Routes canonical bind payload to carrier
Carrier Layer
Mutual / Allstate / etc
- Receives bound policy data
- Underwrites AD&D coverage
- Issues Term Life coverage
Stages flow: 1 → 2 → 3 (left-to-right on larger screens)
1) Decision at HiQOR
- Race or microsite data lands in HiQOR first.
- HiQOR evaluates consent and decides branch activation.
- No consent: execute AD&D only. Consent: execute AD&D + conversion.
2) Parallel execution in Olli
- Path A (no marketing consent): AD&D/base coverage actions.
- Path B (marketing consent): AD&D plus conversion/upsell actions.
- Both lanes 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, consent state, and routing context.
- Olli processes the selected flow and returns status + event data to HiQOR.
- Can upsell / marketing-driven offers (e.g., life insurance, upgrades) be shown without TCPA marketing consent, or must they be suppressed until consent is captured?
- If a user does not opt into TCPA, what is the allowed engagement scope? Transactional only (e.g., coverage confirmation), In-flow UI offers only (no SMS/email follow-up), or No upsell at all?
- Should AD&D (transactional coverage) and marketing consent flows remain decoupled, or do we introduce a progressive (step-up) consent model?
- What conversion ownership model are we aligning on? Olli owns upsell + conversion, HiQOR owns routing + attribution, or Hybrid model (shared SMS/email engagement, coordinated touchpoints, unified tracking)?
- What event-level data must Olli return to HiQOR for Attribution (who drove conversion), Billing (tier progression / revenue triggers), and Lifecycle tracking (started → quoted → bound)?
- Do we support real-time upgrade paths (AD&D → life policy) within the same session, or defer to post-registration engagement?
- Where does the insurance experience live by workflow? Race/event: embedded upstream in partner registration environment. Gym: HiQOR-controlled experience with option to embed or route into Olli.
- What is the purchase / conversion flow architecture by vertical? Race/event: occurs upstream of HiQOR. Gym: any upsell or purchase occurs via Olli (embedded widget, hosted flow, or backend handoff).
- What is the face scan → conversion handoff model? HiQOR OR Olli can drive the user into the face scan to capture consent. Quote/coverage shown on results screen. On engagement, user is routed into Olli frontend flow or passed to Olli via backend (call center or digital).
- What real-time data must Olli return to HiQOR (user-level)? Quote started, application started, policy bound, declined, abandoned. Product type, premium, carrier, timestamps. Required for attribution, billing, and lifecycle tracking. Aggregated reporting alone is insufficient.
- Who is the merchant of record, and how are payments and fees handled? Whose brand is visible to the user? Carrier-first, with optional Olli co-branding. Confirm post-sale ownership: Olli owns customer portal, claims, renewals, upgrades, and servicing.
When Does User Engagement Occur?
Timing of conversion touchpoints relative to the registration event
1. Registration
User completes race sign-up. Consent is captured at this moment.
2. Immediate Redirect
User is sent directly to an Olli-powered insurance flow during or right after checkout.
3. Post-Registration SMS / Email
Olli initiates outreach after registration. User re-engages on their own time.
Conversion Paths
Two implementation approaches — areas for alignment
In-Flow / Embedded
Requires partner integrationIdeal conversion path — insurance offer is part of the registration experience
Post-Registration
Lower dependency — near termScalable async approach — outreach after registration completes
Olli may initiate outreach and manage the full conversion lifecycle
Gym / Microsite Flow (HiQOR-Controlled Environment)
Direct Integration Path
HiQOR controls the full experience — no partner dependency. Direct connection to Olli with no branching required.
HiQOR Gym Microsite
Full Control Over
- Conversion timing
- UI and brand experience
- Entry point into insurance flow
Advantage vs Race
- No partner dependency for embed
- Immediate handoff supported natively
Olli Platform
AD&D
- Policy binding execution
Conversion
- Quote + bind flow
Carrier Layer
Policy issuance and binding
- Underwrites AD&D coverage
- Issues Term Life coverage
- Policy confirmation returned
HiQOR Gym Microsite
- Conversion timing control
- UI and brand experience
- No partner embed dependency
Olli Platform
- AD&D binding
- Conversion flow
Carrier Layer
Policy issuance and binding
- Issues coverage, returns confirmation
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-based routing
TCPA-compliant flow selection
- 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