Skip to main content
phealth

The receptivity edge

Same window. Random minute. By design.

A score per member, per window — variable-ratio timing, the most durable schedule in behavioral science.

Display mode never touches PHI — no BAA required. Start in 5 minutes.

One member · weekday mornings window 7–9 am

Same shaded window every day. The delivery minute is drawn at random inside it — no minute is favored.

Mon
7:38am
Tue
8:11am
Wed
7:52am
Thu
8:27am
Today
8:04am

← drag to explore →

1/120
Chance of any given minute
Uniform — every minute equal ★ Verified in our delivery logs

Same window Random minute By design

§1 · The receptivity threshold

The same message lands very differently depending on state.

Two curves, one crossing point. The dashed curve is what we usually optimize for — a message's content quality, its source authority, the clarity of the call to action. The solid curve is what actually predicts behavior change — the patient's state at the moment the message arrives. The crossing point is where the message becomes more important than the readiness to receive it. Below it, even a perfectly crafted message bounces off.

receptivity ≈ 0.50 · at threshold

Why this is the whole pitch

Health-content products that ignore the solid curve compete on the dashed one — better copy, better data, better claims. Signal competes on the solid curve. Every cue carries a 0–1 receptivity score that tells you which side of the threshold this patient is on right now. You spend your copy budget where it matters; we tell you when your copy actually has a shot.

The score is built from three configurable inputs (see §2). It does not require any data we don't already have — no biometric stream, no wearable integration, no extra patient-facing form. The inputs are what every cued-stream product already collects.

§2 · Anchor-and-jitter mechanic

Three configurable knobs feed one runtime score.

Receptivity is not a black box. The score is built from three knobs that each side of the contract — patient, partner, Uphealth — gets to turn.

7–9am window 12a 6a 12p 6p 12a quiet quiet

Illustrative pattern — the shape of the mechanism, not one member’s data.

  • Window the member picks the hours
  • Jitter drawn at random inside the window — no minute favored
  • Quiet hours a hard floor and ceiling, never crossed

Knob 1

Window

The patient picks the time-of-day window — for example, "morning routine, 7 to 9 AM." That's the anchor; the patient knows roughly when a message arrives. Inside that window the minute is unpredictable — that's the jitter. Same window every day, different minute. Variable-ratio reinforcement (Skinner) — the schedule pattern that drives the most durable behavior in animals + humans alike — built into delivery, no per-template tuning required.

Knob 2

Cadence

The template defines the arc length and the message frequency. A 30-day Pharma Init arc fires once a day; a Wellness arc fires three times a week; a Postpartum arc tapers from daily to weekly over six months. The cadence is a property of the template, not a knob the patient turns mid-arc — switching cadence means switching templates.

Knob 3

Audience

Every message carries include/exclude audience tags. The patient's roster carries matching tags. The intersection determines which messages are even in the pool for this patient's next cue. The receptivity score is computed across the in-pool set only; an excluded message doesn't drag down the score.

Why anchor-and-jitter, not "send at the optimal time"

"Optimal time" delivery — picking the single best minute for each patient — sounds great and degrades fast. The patient adapts to the predictable clock time, the message becomes background, the open rate decays. Anchor-and-jitter trades a small amount of predictability (the window) for a large amount of novelty (the minute) — mere-exposure habituation is defeated structurally, not via per-message tuning.

This isn't a hunch — it's measured. Because our engine draws the delivery minute at random inside the member's window, our logs form a running randomized experiment over send minutes — evidence a fixed-schedule sender can never produce. The verdict strengthens the design: within a window the member chose, no clock minute beats another. Clock time is not where response lives — novelty and member state are, which is exactly what variable-ratio delivery is built to use.

The behavioral-science substrate: variable-ratio reinforcement (Skinner) drives persistence; novelty + anticipation (Berlyne) drives attention; mere-exposure habituation (Zajonc) is what we're defeating. None of this is new — it's the same mechanism that makes slot machines, social-media feeds, and unread-message badges work. Signal applies it to a health-content channel, where the goal is durable behavior change rather than dwell time.

§3 · The score

A 0-to-1 advisory float · returned with every cue.

Every cue response includes a receptivity field — a single float between 0.00 and 1.00. The number is advisory: it tells you Signal's confidence that this patient is above the threshold right now. What you do with it is up to your mode.

Display mode

You decide what to do with it

Deliver mode

Reach composes it for you

How it works
The cue endpoint returns the score; you receive it as metadata alongside the message.
The score combines with Reach's per-message-class tier model (Bright / Open / Steady / Soft / Quiet) into a final action.
Who decides
You. Route however your application logic dictates — send everything, hold below 0.4, pass to an A/B rig as a covariate.
Reach. Returns one action — send · route · defer · hold · bypass — composed from receptivity + Land deliverability + tier.
Best for
Analytics, A/B tests, partners with their own delivery surface, anyone keeping PHI in-house.
Default send/hold logic; partners offloading routing + minute selection to anchor-and-jitter.

§4 · Signal vs Reach

Signal picks the message. Reach picks the moment.

Two questions, one decision. Signal answers "what is the right next message for this patient on this arc day?" Delivery intelligence answers "should this person get any message right now, and on what channel?" — then draws a random minute inside the window. In Display mode you read the score and decide; in Deliver mode delivery intelligence resolves the action for you.

One decision resolved @ T+41 ms
  • Readiness tier Open
  • Chosen window 7–9 am local
  • Last open 37 h ago
  • Channel health push softened

Action

Send → email, jittered to 7:48 am

Why: tier is Open and the window is live; push has softened, so email carries the cue; the minute is drawn at random inside the window — the unpredictability is deliberate.

[decision] member=m_44182 tier=open window=07-09 chan=email jitter=07:48 action=send
writes to the audit log · Deliver mode fires your webhook
  • Send Cue goes out now, jittered to a minute inside the window.
  • Route Same message, a better channel — push when the inbox is cold.
  • Defer Hold for the next window today or tomorrow; receptivity is not there yet.
  • Hold Pause the stream — awaiting feedback, a frequency cap, or quiet hours.
  • Bypass Audience-safety filter excludes this member; no cue, silently.

A score is an input. Delivery intelligence is the answer.

The receptivity score sets when. The readiness tier sets how hard to push. Together they resolve the one question that matters about every message: send it now, somewhere else, later, or not at all.

That engine is delivery intelligence — it ships inside every Signal cue.

SIGNAL

Picks the message · advisory

REACH

Picks the moment · binding

TOGETHER

What + when (decided)

End-to-end

A buyer running Deliver mode calls Signal once a day per active patient. Signal returns the next message + receptivity 0.74. Reach receives the message + the score + the patient's window setting, picks a random minute inside the 7-9 AM window (jitter), checks deliverability (Land), and sends. If Land says the address is failing, Reach swaps to a fallback channel. If receptivity is below 0.3 and the message-class tier is "Quiet," Reach holds for the next day's cue. The buyer sees one webhook per actually-sent message; everything else is silent + auditable.

§5 · Display vs Deliver

Two integration modes, one receptivity engine.

Receptivity is returned with every cue in both modes. What changes between modes is who renders the message, who picks the minute, and whether real PHI passes through Uphealth.

Display

Buyer renders · default

Deliver

Uphealth sends · opt-in

Who sends the message
Your application
Uphealth (email + push)
PHI permitted
No — mock patient_ref only
Yes — real PHI under BAA
BAA required
Not required
Required before keys activate
Tier
Discovery and above
PMPM and above
API scopes granted
create · cue · read · metadata
+ stream:deliver
Onboarding speed
20 minutes (self-serve)
Same-day (manual review + BAA)
Webhook required
Optional (your channel reports its own engagement)
Required (engagement reported back to you)
Receptivity score
Returned — your routing logic uses it
Returned + composed with Reach for routing

Evaluating Signal? Let Claude or ChatGPT do the vendor legwork — paste one prompt.

See how →