How a journey works
Every business outcome is a Journey
A Journey connects the people, information and capabilities required to deliver an experience.
1
Recognize the need
An advisor, agent, partner or customer initiates
2
Make the decision
Product, illustration, needs analysis or suitability, and application
3
Issue & administer
Policy, billing, commissions and downstream systems
4
Service & evolve
Service, changes, anniversary events and claims
LifeBridge carries the capabilities you already have alongside the new capabilities we bring, and others you may add in the future.
The example that follows
One journey, followed the whole way.
A journey is the approved sequence of people, decisions, information and systems required to complete an insurance outcome.
An annuity application does not end at issue. It carries through suitability, funding, the first commission and everything the policyholder does afterwards. Below, one journey appears three times: as it is designed, as it runs, and as the three roles inside it see it.
Phases covered
2 · Make the decision 3 · Issue & administer 4 · Service & evolve
01 · Design · LifeStudio
The journey is designed once, screens included.
One definition, not two projects
Steps, screens, questions, decisions, system calls, communications and waits sit in the same versioned definition. A process change does not become a separate portal release.
Branches and waits are declared, not discovered
A replacement takes the 1035 path. A transfer confirmation is a wait the process expects, not an exception someone chases.
Versioned and effective-dated
Every definition carries a version and an effective date, promoted through draft, test and production on the carrier’s own approval path.
The process owner holds the pen
The people accountable for the process configure it. Nothing reaches production without passing the gates that already exist.
Application intakeproducer submits · can-sell status checked
Every stage carries what the definition declares: the branch it takes, the rule set it checks and the wait it expects.
- Application intake producer submits · can-sell status checked
- Suitability and NIGO review branch: incomplete → requirement letter · rule set v9
- Issue and funding branch: replacement → 1035 path · wait: transfer confirmation
- In force and first commission policy issued · confirmation sent · compensation released
- Add to Apple Wallet policy card issued to the policyholder’s wallet
02 · Orchestration · LifeWorks
The approved version runs, step by step, and leaves its evidence behind.
Runs the published version
The runtime executes the definition that was approved. Work in flight completes on the version it started on.
Calls the systems you keep
Steps call LifeBridge systems of record or the carrier’s existing ones. The runtime does not care which side of the estate answers.
AI is a step, not a layer on top
Acuence steps, Prompt and Agent, sit in the same sequence as a person or a system call, bounded by the same rules and stopping where a person must decide.
Evidence as it runs, not reconstructed after
Prompt, sources, output, decision, approver and the rule version in force are retained beside the case that ran.
01Application intake
- PERSONProducer submits applicationLifeAdvisor
- SYSTEMCheck producer can-sell statusAccriva
- SYSTEMCreate policy recordVerion
02Suitability and NIGO review
- PROMPTExtract fields from submitted documentsPII masked
- AGENTCheck against suitability rule setRule v9 in force
- PERSONUnderwriter decisionServiceHub · approver retained
03Issue and funding
- SYSTEMRequest 1035 transferCarrier of origin
- WAITTransfer confirmationresumes on receipt
- SYSTEMIssue policyVerion
04In force and first commission
- COMMSSend issue confirmationemail · SMS · copy version retained
- SYSTEMRelease compensationAccriva · lineage retained
05Add to Apple Wallet
- SYSTEMIssue policy card to walletLifePortal
03 · Experience · LifeAdvisor, ServiceHub, LifePortal
Three roles, one process, no third release.
One change reaches all three
Because the screens are part of the definition, adding a disclosure or a requirement appears everywhere that role needs it, without a separate front-end project.
Each role sees its own stake
The producer sees the case moving. The service team sees the queue and the rule that flagged it. The policyholder sees documents and values.
Each is sold on its own
Any of the three can run against a carrier’s existing administration system. Integration required, platform not.
The same stage, read three ways
Nothing below is a separate system talking to a separate database. It is one process, presented to whoever is looking.
| Stage | LifeAdvisor Producer | ServiceHub Service team | LifePortal Policyholder |
|---|---|---|---|
| 01Application intake | Application and suitability questions, prefilled from the quote | Case created with its requirements listed | – |
| 02Suitability and NIGO | Outstanding items, and what will clear them | Review queue showing the rule version that flagged it | – |
| 03Issue and funding | Issue status and transfer progress | The 1035 wait, resumed on confirmation | Welcome and policy documents |
| 04In force and first commission | Commission statement, explainable to the penny | Servicing requests against the live record | Values and illustrations from the version in force |
| 05Add to Apple Wallet | – | – | Policy card in the phone, updated from the record |
What the three views share
Design, runtime, experience and record are one stack, not four integrations.
The reason a change can move from a decision to a governed release without a project is that the layer that designs it, the layer that runs it, the screens that show it and the record it writes to are the same system. Each layer is legible on its own; none of them is a hand-off.
Systems of record
Verion · Accriva · accounting and billing
The policy, the producer and the money
AI foundation
Acuence · isolated per-carrier deployment
Governed AI, evidence and separation of carrier data
Each layer is sold on its own. See how the platform is put together →
Try it on your own process
Bring one application flow and we will draw all three views of it.
Your stages, your rules, your systems of record. Designed, orchestrated and shown to each role, in one session.
Go deeper: how the definition is designed and run · see the three experiences