All use cases

Convert

Insurance coverage check and prior-auth navigator

Your patient is ready to start, then asks the one question that stalls everyone — "will my insurance cover this?" — and most coverage in this category turns out to be a maze. Walk them through it instead of losing them at the gate.

Close the loopGet aheadSystem triggerBehavioral triggerChatEmailPushIn-appGLP-1 & PeptidesHealth & TelehealthInsurance

What it does

GLP-1 coverage is one of the hardest gates in the funnel: whether a plan pays depends on plan type and formulary, a prior authorization is usually required, and a large majority of patients find the medication is not covered at all. Faced with that uncertainty, a ready-to-start patient stalls — and coverage questions are also one of the heaviest, least glamorous ticket categories the support team carries. The agent runs the coverage check, explains the patient's formulary and prior-auth criteria in plain language, gathers the clinical facts the prior authorization actually needs (BMI, qualifying conditions), and assembles a prior-auth narrative for the clinician to review and sign — so an eligible patient who would have given up at "is this covered?" moves into therapy.

How it works

  1. 1
    Trigger. a patient asks about coverage or cost in any channel, or a coverage check is requested during intake; the agent opens the navigation flow with the patient's plan in view.
  2. 2
    Decision. the agent runs the eligibility/coverage check against the plan, reads the formulary and the prior-auth criteria that apply, and works out which clinical facts the authorization will require and which the patient or record can supply now.
  3. 3
    Action. it explains what the patient's plan covers and what the prior auth needs, collects the missing facts conversationally, and drafts the prior-auth narrative — the clinical justification — and routes it to the clinician to review and sign. Pricing or clinical questions beyond coverage go to the right channel rather than being answered as advice.
  4. 4
    Follow-through. the submitted prior-auth status is tracked and the patient is kept informed; a denial is handed to the appeal coach; the clinician always signs the narrative, and the agent never asserts a coverage decision the payer or clinician owns.
Example
AgentGood news on the first step — your plan does list this medication, but it needs a prior authorization before it will pay. That usually turns on your BMI and any related conditions. Can I confirm a couple of details so your clinician can submit it?
CustomerSure. I also have sleep apnea, if that matters.
AgentIt can matter a lot for an authorization — I'll include it. I'll put together the clinical write-up and send it to your clinician to check and sign, then I'll keep you posted on where it stands. You don't have to chase the insurer yourself.

Configuration

How the agent is wired for this use case.

Triggera coverage/cost question detected in conversation, or a coverage_check_requested event during intake, with the patient's plan attached.
Tools & actions
  • Billing system · run the eligibility/coverage check and read the patient's plan, formulary, and cost share.
  • Knowledge base · retrieve the formulary rules and prior-auth criteria that apply, and explain them in plain language.
  • Clinical/EHR system · pull the clinical facts the authorization needs and write the drafted prior-auth narrative back for clinician sign-off.
  • Messaging channel · collect missing facts conversationally and keep the patient updated on status.
  • CRM · log the coverage outcome and prior-auth status; route a denial to the appeal coach.
Autonomythe coverage check, criteria explanation, fact-gathering, and narrative drafting run unattended; the prior-auth narrative is always routed to the clinician to review and sign, and the agent asserts no coverage or clinical decision the payer or clinician owns. Clinical = surface and route, never diagnose or advise a dose.
Channelschat · email · push · in-app
Escalationa clinical question, an edge-case coverage situation, or a denial hands off — clinical questions to the clinician, a denial to the appeal coach — with the coverage context attached.

What you need

The inputs this use case runs on. Your channels stay yours; the agent supplies the judgment.

Signals

a coverage/cost question intent, or a coverage_check_requested event during intake, plus the patient's active plan identifier.

Data

the patient's plan and formulary, the prior-auth criteria per plan, the clinical fields a prior auth requires, consent state, anything already on file.

Guardrails

the agent presents coverage and criteria as information, never a payer decision; the prior-auth narrative is drafted for clinician sign-off, never submitted autonomously; consent before any outreach; every coverage interaction logged for audit; no clinical advice beyond the navigation.

Metrics it moves

  • conversion-rateup, by converting eligible patients who would otherwise stall at the coverage gate into started therapy.
  • intake-completionup, because the coverage question that freezes the funnel gets answered and worked rather than left hanging.
  • ticket-deflectionup, by resolving the heaviest coverage-and-prior-auth ticket category in conversation instead of in the queue.

Related use cases

Prevent / Care

Prior-auth narrative drafter (clinician-side)

the clinician-facing counterpart that drafts the narrative for sign-off

Retain / Save

Coverage-denial appeal coach

the save flow that fires when an authorization is denied

Onboard / Activate

Conversational intake and eligibility check

the intake this coverage step plugs into

See it on your own customer journey

Bring one drop-off, one churn cliff, or one silent segment. We will show you what a proactive agent with memory and judgment does with it.

Book a demo