Dashboard ↗Get an API key
Flows

Flows funnel builder

Build quiz → intake → checkout acquisition funnels where AI and the clinic own the marketing copy but every clinical screen comes from a certified questionnaire a licensed provider approves before publish.

Flows is neolife's AI-powered patient-acquisition funnel builder. A clinic assembles a quiz → medical intake → checkout funnel, publishes it, and patients flow through into the same fulfillment rail that already carries your orders. The builder is where you author the top of the funnel; the rest of the platform is what makes the bottom of it real.

The line that separates Flows from every other funnel tool is what it won't let AI do. AI drafts, a licensed provider signs. PathwAI gets the patient to your door; neolife gets the medication to theirs — and the only reason that handoff is safe is the two-plane model below.

The two-plane model#

Every flow is split into two planes that are governed differently, on purpose.

Plane What it holds Who authors it
Presentation Landing and outcome copy, theme tokens, the marketing quiz, A/B variants AI and the clinic, freely
Clinical Medical questions, disqualifiers, consent blocks Only neolife's certified questionnaire corpus

The presentation plane is marketing. Change the headline, swap the hero, run three variants of the promise — none of it touches eligibility, so you and the AI move as fast as you want.

The clinical plane is the intake. Its questions, its disqualifying answers, and its consent language come only from the certified questionnaire corpus. AI never authors a live clinical screen. It can draft one, but a deterministic validator gates the draft and a licensed provider approves it before it can gate a real patient. This split is the E&O/certificate moat: because the clinical plane is certified and provider-approved rather than AI-written, the funnel manufactures the same tamper-evident certificate every one of your other channels does.

Rule: the presentation plane is yours to rewrite at will; the clinical plane is certified corpus a provider stands behind. AI drafts either, but only the presentation plane goes live on the AI's say-so.

The builder#

Flows lives as a Funnels section in the clinic console. It gives you:

  • A flow list — every funnel for the tenant, with status and analytics.
  • A template picker — the entire certified questionnaire corpus wrapped as ready-to-publish funnels, so the fastest path to a live funnel is picking a certified one and editing its copy.
  • A form-based editor — edit presentation copy, set brand theme tokens, wire the checkout handoff, and reorder steps.
  • Publish — a licensure-gated action (see below) that records the funnel and mints its approval record.

You do not hand-write clinical screens in the editor. You pick certified ones, reorder them, and dress the funnel around them.

AI generation#

Describe the program in plain language and AI builds the funnel around a certified questionnaire.

Match an existing questionnaire. POST /flows/ai/generate takes your description, matches it to a certified questionnaire in the corpus, and writes the presentation plane — copy and theme — around it. The clinical plane is selected, never written.

Draft a new questionnaire. For a product the corpus doesn't cover yet, AI can draft a full questionnaire in the certified schema via POST /intake/questionnaires/ai-draft. That path is gated by the counsel-gated flow_ai_freeform_medical flag, a deterministic validator gates the draft, and a licensed provider approves it with POST /intake/questionnaires/:id/approve before it becomes a usable certified tenant questionnaire. Only then can a flow use it.

Both endpoints run offline against a deterministic stub, so a demo build produces the same shape without a model in the loop.

Publish is a licensure act#

Publishing a flow is not a save button — it is the moment a clinical plane goes live in front of patients, so it is gated exactly like provider approval elsewhere on the rail. Publish requires the FLOWS_PUBLISH role, and it records:

  • a hash of the clinical plane (the certified questions, disqualifiers, and consent as published), and
  • the licensed provider who approved it.

Together those are the flow approval certificate — the durable proof that a named provider stood behind exactly these clinical screens. Change a clinical screen and you re-publish and re-approve; the presentation plane can change without it.

Hosted and embeddable renderer#

A published flow ships two ways, both self-contained:

  • Hosted page at /f/:embedKey — served from neolife's BAA-covered API, never from the static marketing host, because the runtime touches patient answers.
  • Embed snippet — a flow.js loaded from /embed/v1/flow.js that renders the funnel inside the clinic's own page.

Themes are applied through --nl-flow-* CSS variables, so the brand tokens you set in the editor drive both surfaces. On publish, the clinic gets a hosted URL and an embed snippet.

Rule: the runtime is served from the BAA-covered API, not the marketing CDN. A funnel that collects medical answers cannot run on static hosting.

Runtime and the handoff to fulfillment#

The patient-facing runtime is a small public API. It never sees your secret key — it authenticates with the flow's embedKey.

Route What it does
GET /public/flows/:embedKey Returns the patient-safe flow definition
POST /public/flows/:embedKey/sessions Starts a session
POST .../sessions/:id/steps Partial save as the patient progresses
POST .../sessions/:id/submit Submits — delegates to the deterministic intake engine
POST .../sessions/:id/events PHI-free analytics beacon

Submit is the join to the rest of the platform. It delegates to the deterministic intake engine, which issues the certificate, drops the submission into the provider review queue, and hands it to pharmacy routing. From that point the funnel-sourced order is indistinguishable from any other order on the rail.

Checkout is a handoff, not a charge. On qualification the funnel hands off to the clinic's own store, carrying the certificate token — neolife never holds patient money, because an Rx can't run on a generic card rail. You gate the prescription, not the cart: the store collects payment, the certificate proves the clinical gate was cleared.

A/B experiments#

Experiments run on the presentation plane only. A variant can change the headline, the theme, or the marketing quiz — it cannot change a clinical question, which is why the certificate is identical across every arm. Assignment is deterministic and sticky server-side, and you get live control-vs-variant qualify rates. You can optimize the promise without ever forking the medical screen.

Analytics that cannot leak PHI#

Funnel stats are PHI-free by construction — views, sessions, qualified, disqualified, and per-step drop-off, keyed on session ids and closed-vocabulary event names, never on answers or identity. This is analytics that cannot leak PHI — by schema, not by policy: the events beacon has no field to put PHI in, so there is nothing to redact. The same discipline that keeps your webhooks and events out of PHI scope keeps the funnel dashboard out of it too.

Integrations#

Destinations are split into two tiers by how much they're trusted to receive.

Ad-pixel destinations — Meta Conversions API, GA4, TikTok — receive hashed identifiers and a closed-vocabulary event only, never a raw email and never any health context. They fire only on an eligible outcome, never on disqualified, and the whole tier is gated by the counsel-gated funnel_ad_conversions flag (which stays off until a signed tracking-tech memo is in place).

First-party CRM/CDP destinations — Segment, HubSpot — run under the clinic's own BAA and may receive the lead's email and name plus a neutral funnel label, never clinical detail. This tier is gated by flow_cdp_destinations (Growth and up).

Zapier connects through the existing signed flow.* webhooks — flow.published, flow.session.qualified, flow.session.completed, flow.checkout.completed. Every destination is configured per tenant, and secret values are never returned by the API once set.

CDP identity and funnel-to-fulfillment attribution#

Every submitted lead is merged into a unified Contact keyed on a PHI-free emailHash (email and name are encrypted at rest). After provider approval, the Contact links to a Patient — which closes the loop from the ad click to the shipped medication. That funnel-to-fulfillment attribution is something nobody without the pharmacy rail can offer. The console gives you a Contacts view and a per-contact journey.

Custom domains#

A clinic can serve a flow from its own subdomain — start.theirclinic.com — through Cloudflare for SaaS. You add the domain, get the CNAME and TXT records to set, and verification polls Cloudflare until it resolves. Gated by flow_custom_domains (Growth and up).

Access control and flags#

Roles scope who can do what, and the publish role is deliberately a clinical/licensure act:

Role Grants
FLOWS_VIEW See flows and their definitions
FLOWS_MANAGE Create and edit flows
FLOWS_PUBLISH Publish a flow — a licensure act
FLOWS_ANALYTICS_VIEW Read funnel analytics

Feature flags gate capability by risk. Open: flow_builder, flow_ai_generation, flow_hosted_pages. Open, Growth and up: flow_experiments, flow_custom_domains, flow_cdp_destinations. Counsel-gated: flow_checkout, funnel_ad_conversions, flow_ai_freeform_medical — these stay off until the paperwork behind them is signed.

Packaging#

Flows is bundled into your existing tier, not sold as a separate SKU — the builder manufactures routed orders for the per-order meter you already pay, so it pays for itself where the rail already earns.

Tier Flows included
Pilot ($0 / 60 days) 1 flow, AI generation included
Starter ($699 + $4/order) 3 flows, embed + hosted, basic analytics
Growth ($1,999 + $3.50/order) Unlimited flows, A/B, ad tracking, integrations, custom domains
Scale ($6,000 + $3/order) White-label
Enterprise SSO

Two things published pricing makes plain against a contact-sales incumbent: a BAA is on the table at every paid tier, not held back for Enterprise, and the price is on the page.

Next steps#