Company-Specific Configuration
What's hardcoded to life insurance and what needs to change for other companies
The lead system was built for life insurance sales agencies. This page catalogs everything that's domain-specific and what would need to change to support other companies — starting with another life insurance company, but with an eye toward other industries.
Lead types
Where defined: lead_types database table, LEADS constant in src/constants/leads.ts
Current types are specific to the lead sourcing methods used by the current customer base: Free Will Kit (FWK), Child Safe Kit (CSK), Beneficiary Referral (BR), Union, No-Cost Referral (NCR), Point of Sale (POS), Discount Card (D-Card), Final Expense (FE), Globe, and lapsed variants (LGlobe, LPOS).
What needs to change: Lead types should be configurable per agency or company. The lead_types table already supports this structurally, but the LEADS constant in the frontend is hardcoded. A new company would need its own set of lead types.
Approach: Move lead type definitions to a database-driven configuration that the frontend fetches at startup. The LEADS constant becomes a fallback or is replaced entirely.
Products
Where defined: products database table, referenced in lead_sale_details.product
Current products are life/health insurance specific: Final Expense (FE), Income Protector (IP), Accidental Death Benefit (ADB), term policies (T4, T20, T65, T100), and others.
What needs to change: Products must be configurable per company. Different life insurance companies will sell different product lines.
Approach: Products are already in a database table. The presentation system reads from this table when building offer options. A new company would need its own product rows. The frontend currently hardcodes some product-specific display logic (labels, grouping) that would need to be data-driven.
Demographics fields
Where defined: leads table columns, lead-details-demographics.tsx, submit_lead_presentation RPC
The demographics schema assumes a life insurance use case:
- Primary/secondary insured model (two people per household)
- Life-insurance-specific fields:
nicotine,health_dq,life_dq, coverage amounts by type (term, whole, work) - Family fields:
num_children,num_grandchildren,has_mortgage,has_bank_account
What needs to change for another life insurance company: Probably minimal — these fields are broadly applicable across life insurance. Some companies may need additional fields or may not use all of them.
What needs to change for a non-insurance company: This entire section would need to be replaced with industry-appropriate fields.
Approach: For life insurance companies, keep the current schema. For other industries, consider a flexible demographics JSONB column with a schema defined per company, or a separate demographics table with configurable fields.
Outcome fields
Where defined: leads table (is_sale, sold_at, primary_alp, primary_ahp, secondary_alp, secondary_ahp, primary_is_trial, secondary_is_trial), lead_sale_details table
These are deeply life-insurance-specific:
- ALP (Annual Life Premium) and AHP (Annual Health Premium) are industry terms
- The primary/secondary split maps to the two-insured-per-household model
- Trial sales (free-look period) are an insurance concept
waiver_of_premiumis an insurance rider
What needs to change: Another life insurance company might use similar fields but with different product lines. A non-insurance company would need completely different outcome fields.
Approach: Keep the current fields for life insurance. For a new company type, the outcome data model would need to be redesigned.
Presentation system
Where defined: src/components/presentation/, src/prompts/script-agent/, the pop-out window system
The presentation system is the most company-specific part of Onsidian:
- Scripts are tailored to each lead type
- Slide flow (rapport → fact-finding → needs analysis → offers → close) follows an insurance sales methodology
- Offer calculations use insurance-specific formulas
- Product selection UI is built around insurance product types
What needs to change: Each company needs its own presentation flows. The presentation framework (slides, scripts, pop-out window, progress tracking) is reusable, but the content and calculations are not.
Approach: The script/slide system already supports different flows per lead type. Extending this to support different flows per company is the natural next step.
Stage/status state machine
Where defined: update_lead_status_based_on_activity trigger function, LEAD_STAGE constant
The state machine is relatively generic for any outbound sales workflow:
new → attempted → callback/scheduled → sale/no_sale/terminalThis flow works for most sales processes where you contact prospects, schedule meetings, and close deals.
What's specific: The constraint that sale/no_sale can only come from scheduled stage assumes every sale requires an appointment. Some sales models (e.g., inbound, e-commerce) might not require this.
Approach: The state machine works well for any appointment-based sales model. For companies with different sales flows, the trigger function would need to support configurable transitions.
Contact methods
Where defined: CONTACT_METHOD constant, log_contact_with_outcome RPC
Current methods: call, text, email. These are universal and work for most sales contexts.
What might change: Some companies might want additional methods (in-person, video call, social media). The RPC already accepts any string for p_method, so adding new methods only requires UI changes.
Reporting
Where defined: lead_reports, lead_report_metrics tables, get_lead_reports_aggregate RPC
The WAR report structure tracks contacts, leads worked, appointments, and production metrics (ALP/AHP). The production metrics are insurance-specific.
What needs to change: The activity tracking (contacts, leads worked, appointments) is generic. The production metrics (ALP, AHP, trial sales) would need to be replaced with industry-appropriate measures for non-insurance companies.
Lead source images
Where defined: get-lead-source-img.ts
Currently only maps 'onsidian' to an icon. Other sources have no image.
What needs to change: Each company/vendor integration would want its own source icon. This is a simple mapping function.
Summary: effort by scenario
Another life insurance company (similar to current)
| Area | Effort | Notes |
|---|---|---|
| Lead types | Low | Add rows to lead_types, update frontend constant |
| Products | Low | Add rows to products table |
| Demographics | None | Same fields apply |
| Outcomes | None | Same ALP/AHP model |
| Presentations | High | New scripts and slide flows needed |
| State machine | None | Same sales process |
| Reporting | Low | Same structure, new lead types show up automatically |
Different industry
| Area | Effort | Notes |
|---|---|---|
| Lead types | Medium | New type system needed |
| Products | High | Complete redesign |
| Demographics | High | New field schema |
| Outcomes | High | New outcome data model |
| Presentations | High | Completely new flows |
| State machine | Medium | May need different transitions |
| Reporting | Medium | New production metrics |