Healthcare · Playbook
The healthcare playbook. Built in the builder, decided by your hospital system.
Ten journeys, each drawn below as it runs. The decision comes from your hospital, lab or pharmacy system or criteria you set; the journey carries it. Clinical decisions stay in your system. Aims are targets to agree in the pilot, not results.
PLAYBOOKS · 01Illustrative journey
Reach the result nobody opened.
A result released by your lab system sends a notice to the Inbox with no result inside, checks whether your app reported a view within forty-eight hours, and if not sends one WhatsApp with View result or Call me, then a call for silence.
- Decides
- your lab system's release; the patient.
- Aim
- results seen, on the record.
Built in the journey builder
Reach the result nobody openedHEALTHCAREThe notice carries no result; the result stays in your system, behind your login.
Campaign Start · APIResult released (from your lab system)
Push + InboxNotice to the Inbox, no result inside
Event CheckViewed within 48 hours? (your app reports)
Viewed
Not viewed
End
WhatsApp FlowWhatsApp: View result / Call me
View result
Call me
No reply
End
API CallCallback task to your desk (your system)
End
IVR CallVoice call: a result is waiting
End
Drawn as it would run in the builder. Thresholds, windows and channel order are the ones you set; the decision at each API step comes from your system.
- Intended outcome
- results seen, on the record.
- Trigger
- result released (your lab system)
- Events and identifiers
- result released (your lab system). The trigger arrives from your system by API with your customer identifier and the fields named in the trigger. Example inputs; map them to your own event names and identifiers at setup. Every event carries your customer identifier.
- Your systems in the loop
- call me: task to your desk. Your system validates and executes each of these; the journey sends the request and branches on the answer.
- Consent
- Checked inside the journey at the step shown, and per channel before any send.
- Stops when
- yes: stop. The message is delivered on the first channel that reports delivery, or the fallback order is exhausted and the failure is recorded.
- If a channel fails or nobody answers
- A channel that reports failure advances the fallback order on that carrier signal; when the last channel in the order has reported failure, the message is recorded as failed with the reason. Delivery callbacks that arrive late update the record when they arrive.
- Success metric
- results seen, on the record. Population: contacts who entered the journey in the window. Compared with the baseline window agreed before the pilot, on the conversion events you define. A before-and-after difference is a comparison, not proof of cause.
What it takes to run
PLAYBOOKS · 02Illustrative journey
Offer the health check when the pattern says it is due.
A patient not seen in fourteen months enters a segment; your system confirms the check is due and not booked, then one WhatsApp offers Book a slot or Not now, and a tap fetches the open slots and books in your system.
- Decides
- your screening rules and your scheduler.
- Aim
- screenings booked without a call list.
Built in the journey builder
Offer the health check when the pattern says it is dueHEALTHCAREYour system confirms the check is due and not booked before anything is offered.
Segment EntryNo visit in 14 months, screening due
API CallDue and not booked? Ask your system
Due, not booked
Booked, or not due
WhatsApp FlowWhatsApp: Book a slot / Not now
Book a slot
Not now
No reply
API CallOpen slots from your scheduler
Button ClickedPatient picks
API CallYour system books it, confirmation sent
End
End
End
End
Drawn as it would run in the builder. Thresholds, windows and channel order are the ones you set; the decision at each API step comes from your system.
- Intended outcome
- screenings booked without a call list.
- Trigger
- segment entry: no visit in 14 months
- Events and identifiers
- segment entry: no visit in 14 months. Segment membership is recomputed from the contact's own events on the window you set; the identifier is the contact record. Example inputs; map them to your own event names and identifiers at setup. Every event carries your customer identifier.
- Your systems in the loop
- due? not booked? (your system) · open slots from your scheduler · your system books it. Your system validates and executes each of these; the journey sends the request and branches on the answer.
- Consent
- Per-channel consent on the contact record is checked before any send.
- Stops when
- no tap: silence. The customer completes the step the journey waits for, the deadline on a wait passes, or the branch drawn for silence ends.
- If a channel fails or nobody answers
- A channel that reports failure advances the fallback order on that carrier signal; silence takes the path drawn for it, with the deadline you set. Delivery callbacks that arrive late update the record when they arrive. An API step that answers no, or fails, takes the branch drawn for it; the platform does not act on your system's behalf beyond that request.
- Success metric
- screenings booked without a call list. Population: contacts who entered the journey in the window. Compared with the baseline window agreed before the pilot, on the conversion events you define. A before-and-after difference is a comparison, not proof of cause.
What it takes to run
PLAYBOOKS · 03Illustrative journey
Offer home sample collection the day a test is ordered.
A test ordered in your lab system asks whether collection covers the patient's address, then sends one WhatsApp with Collect at home or Visit the lab; a tap books the collection in your system and confirms the time window.
- Decides
- your lab system and its collection coverage.
- Aim
- more samples collected, fewer tests never taken.
Built in the journey builder
Offer home sample collection the day a test is orderedHEALTHCAREYour lab system confirms coverage before the offer; a tap books the collection.
Campaign Start · APITest ordered (from your lab system)
API CallCollection covers their address?
Covered
Not covered
WhatsApp FlowWhatsApp: Collect at home / Visit the lab
Collect at home
Visit the lab
No reply
API CallYour system books the collection
Message · WhatsAppConfirmation with the time window
End
End
End
End
Drawn as it would run in the builder. Thresholds, windows and channel order are the ones you set; the decision at each API step comes from your system.
- Intended outcome
- more samples collected, fewer tests never taken.
- Trigger
- test ordered (your lab system)
- Events and identifiers
- test ordered (your lab system). The trigger arrives from your system by API with your customer identifier and the fields named in the trigger. Example inputs; map them to your own event names and identifiers at setup. Every event carries your customer identifier.
- Your systems in the loop
- covers their address? (your system) · your system books the collection. Your system validates and executes each of these; the journey sends the request and branches on the answer.
- Consent
- Per-channel consent on the contact record is checked before any send.
- Stops when
- visit the lab or no tap: silence. The customer completes the step the journey waits for, the deadline on a wait passes, or the branch drawn for silence ends.
- If a channel fails or nobody answers
- A channel that reports failure advances the fallback order on that carrier signal; silence takes the path drawn for it, with the deadline you set. Delivery callbacks that arrive late update the record when they arrive. An API step that answers no, or fails, takes the branch drawn for it; the platform does not act on your system's behalf beyond that request.
- Success metric
- more samples collected, fewer tests never taken. Population: contacts who entered the journey in the window. Compared with the baseline window agreed before the pilot, on the conversion events you define. A before-and-after difference is a comparison, not proof of cause.
What it takes to run
PLAYBOOKS · 04Illustrative journey
Book the follow-up the discharge letter asked for.
A discharge with a follow-up due waits three days, asks your scheduler whether it is booked, and if not sends the open slots in one WhatsApp; the patient picks in the message, and silence gets a call from your desk.
- Decides
- your scheduler; the patient.
- Aim
- follow-ups booked before they are forgotten.
Built in the journey builder
Book the follow-up the discharge letter asked forHEALTHCAREYour scheduler answers first; the patient picks a slot in the message.
Campaign Start · APIDischarged, follow-up due (from your HIS)
Wait TimeWait 3 days
API CallFollow-up booked? Ask your scheduler
Booked
Not booked
End
API CallOpen slots from your scheduler
WhatsApp FlowWhatsApp: pick a slot
Picked
No reply
API CallYour system books it
End
IVR CallCall from your desk
End
Drawn as it would run in the builder. Thresholds, windows and channel order are the ones you set; the decision at each API step comes from your system.
- Intended outcome
- follow-ups booked before they are forgotten.
- Trigger
- discharged, follow-up due (your HIS)
- Events and identifiers
- discharged, follow-up due (your HIS). The trigger arrives from your system by API with your customer identifier and the fields named in the trigger. Example inputs; map them to your own event names and identifiers at setup. Every event carries your customer identifier.
- Your systems in the loop
- booked? (your scheduler) · no: open slots from your scheduler · picked: your system books it. Your system validates and executes each of these; the journey sends the request and branches on the answer.
- Consent
- Per-channel consent on the contact record is checked before any send.
- Stops when
- yes: stop. The customer completes the step the journey waits for, the deadline on a wait passes, or the branch drawn for silence ends.
- If a channel fails or nobody answers
- A channel that reports failure advances the fallback order on that carrier signal; silence takes the path drawn for it, with the deadline you set. Delivery callbacks that arrive late update the record when they arrive. An API step that answers no, or fails, takes the branch drawn for it; the platform does not act on your system's behalf beyond that request.
- Success metric
- follow-ups booked before they are forgotten. Population: contacts who entered the journey in the window. Compared with the baseline window agreed before the pilot, on the conversion events you define. A before-and-after difference is a comparison, not proof of cause.
What it takes to run
PLAYBOOKS · 05Illustrative journey
Catch the refill before it lapses.
The journey waits until the refill date your pharmacy system holds, sends Order refill with one tap, checks seven days later whether the refill was collected, and only then reminds once more and calls.
- Decides
- your pharmacy system's date and stock.
- Aim
- fewer refills that quietly lapse.
Built in the journey builder
Catch the refill before it lapsesHEALTHCAREWaits for the date your pharmacy system holds; checks before anyone is reminded twice.
Campaign Start · APIRefill due (from your pharmacy system)
Wait Until DateWait until the refill date
WhatsApp FlowWhatsApp: Order refill / Already have it
Order refill
Already have it
No reply
API CallYour pharmacy system processes it
End
End
Event CheckCollected within 7 days? (your system)
Collected
Not collected
End
Message · WhatsAppOne more reminder
IVR CallStill not collected: call
End
Drawn as it would run in the builder. Thresholds, windows and channel order are the ones you set; the decision at each API step comes from your system.
- Intended outcome
- fewer refills that quietly lapse.
- Trigger
- refill due (your pharmacy system)
- Events and identifiers
- refill due (your pharmacy system). The trigger arrives from your system by API with your customer identifier and the fields named in the trigger. Example inputs; map them to your own event names and identifiers at setup. Every event carries your customer identifier.
- Your systems in the loop
- tap: your pharmacy system processes it. Your system validates and executes each of these; the journey sends the request and branches on the answer.
- Consent
- Checked inside the journey at the step shown, and per channel before any send.
- Stops when
- The customer completes the step the journey waits for, the deadline on a wait passes, or the branch drawn for silence ends.
- If a channel fails or nobody answers
- A channel that reports failure advances the fallback order on that carrier signal; silence takes the path drawn for it, with the deadline you set. Delivery callbacks that arrive late update the record when they arrive. An API step that answers no, or fails, takes the branch drawn for it; the platform does not act on your system's behalf beyond that request.
- Success metric
- fewer refills that quietly lapse. Population: contacts who entered the journey in the window. Compared with the baseline window agreed before the pilot, on the conversion events you define. A before-and-after difference is a comparison, not proof of cause.
What it takes to run
PLAYBOOKS · 06Illustrative journey
Turn a booking session into a booking.
A session with the booking screen opened three times and no appointment made checks consent, fetches the open slots from your scheduler, and sends one WhatsApp with the slot they were looking at; a tap books it in your system.
- Decides
- your scheduler; the patient.
- Aim
- more bookings from the sessions that stalled.
Built in the journey builder
Turn a booking session into a bookingHEALTHCAREA session rule, a consent check, the slots your scheduler holds, one message.
Campaign StartBooking screen three times, no booking (session)
Check Channel ConsentCheck consent
API CallOpen slots from your scheduler
WhatsApp FlowWhatsApp: Book the slot you viewed
Tapped
No reply
API CallYour system books it
Message · WhatsAppConfirmation
End
End
Drawn as it would run in the builder. Thresholds, windows and channel order are the ones you set; the decision at each API step comes from your system.
- Intended outcome
- more bookings from the sessions that stalled.
- Trigger
- session rule: booking screen, no booking
- Events and identifiers
- session rule: booking screen, no booking. Captured by the SDK or web tracker as the session runs, tied to the identified contact. Example inputs; map them to your own event names and identifiers at setup. Every event carries your customer identifier.
- Your systems in the loop
- open slots from your scheduler · your system books it. Your system validates and executes each of these; the journey sends the request and branches on the answer.
- Consent
- Checked inside the journey at the step shown, and per channel before any send.
- Stops when
- no tap: silence. The customer completes the step the journey waits for, the deadline on a wait passes, or the branch drawn for silence ends.
- If a channel fails or nobody answers
- A channel that reports failure advances the fallback order on that carrier signal; silence takes the path drawn for it, with the deadline you set. Delivery callbacks that arrive late update the record when they arrive. An API step that answers no, or fails, takes the branch drawn for it; the platform does not act on your system's behalf beyond that request.
- Success metric
- more bookings from the sessions that stalled. Population: contacts who entered the journey in the window. Compared with the baseline window agreed before the pilot, on the conversion events you define. A before-and-after difference is a comparison, not proof of cause.
What it takes to run
PLAYBOOKS · 07Illustrative journey
Confirm tomorrow's appointment, or reschedule it in the message.
A reminder waits for confirm, reschedule or cancel by button, reply or keypad, fetches open slots from your scheduler if asked, and calls the patient who says nothing.
- Decides
- your scheduler; the patient.
- Aim
- fewer no-shows.
Built in the journey builder
Confirm tomorrow's appointmentHEALTHCAREYour scheduler answers mid-journey.
Campaign Start · APIAppointment tomorrow (from your HIS)
WhatsApp FlowReminder: Confirm / Reschedule / Cancel
Confirm
Reschedule
Cancel
No reply
API CallMark confirmed in your system
End
API CallOpen slots from your scheduler
Button ClickedPatient picks
End
API CallRelease the slot in your system
End
IVR CallVoice call, keypad confirms
End
Drawn as it would run in the builder. Thresholds, windows and channel order are the ones you set; the decision at each API step comes from your system.
- Intended outcome
- fewer no-shows.
- Trigger
- appointment tomorrow (your HIS)
- Events and identifiers
- appointment tomorrow (your HIS). The trigger arrives from your system by API with your customer identifier and the fields named in the trigger. Example inputs; map them to your own event names and identifiers at setup. Every event carries your customer identifier.
- Your systems in the loop
- reschedule: slots from your scheduler. Your system validates and executes each of these; the journey sends the request and branches on the answer.
- Consent
- Per-channel consent on the contact record is checked before any send.
- Stops when
- The customer completes the step the journey waits for, the deadline on a wait passes, or the branch drawn for silence ends.
- If a channel fails or nobody answers
- A channel that reports failure advances the fallback order on that carrier signal; silence takes the path drawn for it, with the deadline you set. Delivery callbacks that arrive late update the record when they arrive. An API step that answers no, or fails, takes the branch drawn for it; the platform does not act on your system's behalf beyond that request.
- Success metric
- fewer no-shows. Population: contacts who entered the journey in the window. Compared with the baseline window agreed before the pilot, on the conversion events you define. A before-and-after difference is a comparison, not proof of cause.
What it takes to run
PLAYBOOKS · 08Illustrative journey
Fill the slot a cancellation frees.
A cancellation in your scheduler sends push and Inbox to the waitlist segment for that clinic; the first tap books the slot in your system and confirms, and everyone else hears nothing more.
- Decides
- your scheduler; the waitlist you define.
- Aim
- freed slots filled the same day.
Built in the journey builder
Fill the slot a cancellation freesHEALTHCAREThe waitlist is a segment you define; your scheduler decides who got there first.
Campaign Start · APISlot cancelled (from your scheduler)
Push + InboxPush and Inbox to the waitlist segment
Button ClickedTake the slot
Tapped
No tap in 2 hours
API CallYour system books it, first tap wins
Message · WhatsAppConfirmation to that patient
End
API CallSlot back to your desk
End
Drawn as it would run in the builder. Thresholds, windows and channel order are the ones you set; the decision at each API step comes from your system.
- Intended outcome
- freed slots filled the same day.
- Trigger
- slot cancelled (your scheduler)
- Events and identifiers
- slot cancelled (your scheduler). The trigger arrives from your system by API with your customer identifier and the fields named in the trigger. Example inputs; map them to your own event names and identifiers at setup. Every event carries your customer identifier.
- Your systems in the loop
- your system books it, first tap wins. Your system validates and executes each of these; the journey sends the request and branches on the answer.
- Consent
- Per-channel consent on the contact record is checked before any send.
- Stops when
- no tap in 2 hours: slot back to your desk. The customer completes the step the journey waits for, the deadline on a wait passes, or the branch drawn for silence ends.
- If a channel fails or nobody answers
- A channel that reports failure advances the fallback order on that carrier signal; silence takes the path drawn for it, with the deadline you set. Delivery callbacks that arrive late update the record when they arrive. An API step that answers no, or fails, takes the branch drawn for it; the platform does not act on your system's behalf beyond that request.
- Success metric
- freed slots filled the same day. Population: contacts who entered the journey in the window. Compared with the baseline window agreed before the pilot, on the conversion events you define. A before-and-after difference is a comparison, not proof of cause.
What it takes to run
PLAYBOOKS · 09Illustrative journey
Check in after discharge, and escalate the worried.
A day-three WhatsApp with three buttons sends I'm worried to your care team by API the same minute, books a callback for Some questions, and schedules the day-ten check-in for the rest.
- Decides
- the patient's answer; your care team.
- Aim
- the worried patient reached the same day.
Built in the journey builder
Check in after discharge, and escalate the worriedHEALTHCAREThree buttons; the worried answer becomes a task for your care team the same minute.
Campaign Start · APIDischarged (from your HIS)
Wait TimeWait 3 days
WhatsApp FlowWhatsApp: Fine / Some questions / Worried
Fine
Some questions
Worried
No reply
Wait TimeWait 7 days
Message · WhatsAppDay-10 check-in
End
API CallCallback task to your desk
End
API CallTask to your care team, now
End
Message · SMSSMS with the desk number
End
Drawn as it would run in the builder. Thresholds, windows and channel order are the ones you set; the decision at each API step comes from your system.
- Intended outcome
- the worried patient reached the same day.
- Trigger
- discharged (your HIS)
- Events and identifiers
- discharged (your HIS). The trigger arrives from your system by API with your customer identifier and the fields named in the trigger. Example inputs; map them to your own event names and identifiers at setup. Every event carries your customer identifier.
- Your systems in the loop
- worried: task to your care team, now · questions: callback from your desk. Your system validates and executes each of these; the journey sends the request and branches on the answer.
- Consent
- Per-channel consent on the contact record is checked before any send.
- Stops when
- The customer completes the step the journey waits for, the deadline on a wait passes, or the branch drawn for silence ends.
- If a channel fails or nobody answers
- A channel that reports failure advances the fallback order on that carrier signal; silence takes the path drawn for it, with the deadline you set. Delivery callbacks that arrive late update the record when they arrive. An API step that answers no, or fails, takes the branch drawn for it; the platform does not act on your system's behalf beyond that request.
- Success metric
- the worried patient reached the same day. Population: contacts who entered the journey in the window. Compared with the baseline window agreed before the pilot, on the conversion events you define. A before-and-after difference is a comparison, not proof of cause.
What it takes to run
PLAYBOOKS · 10Illustrative journey
Bring back the patient who has drifted.
A patient whose visits have lapsed past the window you set gets one message from the clinic, not an offer; a reply becomes a task for patient services, and silence waits thirty days, checks for a visit, and ends with a call.
- Decides
- the visit window you set; your patient services team.
- Aim
- the drifting patient reached before they are lost.
Built in the journey builder
Bring back the patient who has driftedHEALTHCAREOne message from the clinic, not an offer; a reply reaches a person.
Segment EntryVisits lapsed past your window
Message · WhatsAppOne message from the clinic, not an offer
Reply
No reply
API CallTask to patient services (your system)
End
Wait TimeWait 30 days
Event CheckVisit recorded? (your HIS)
Visited
No visit
End
IVR CallCall from patient services
End
Drawn as it would run in the builder. Thresholds, windows and channel order are the ones you set; the decision at each API step comes from your system.
- Intended outcome
- the drifting patient reached before they are lost.
- Trigger
- segment entry: visits lapsed past your window
- Events and identifiers
- segment entry: visits lapsed past your window. Segment membership is recomputed from the contact's own events on the window you set; the identifier is the contact record. Example inputs; map them to your own event names and identifiers at setup. Every event carries your customer identifier.
- Your systems in the loop
- yes: task to patient services. Your system validates and executes each of these; the journey sends the request and branches on the answer.
- Consent
- Checked inside the journey at the step shown, and per channel before any send.
- Stops when
- The customer completes the step the journey waits for, the deadline on a wait passes, or the branch drawn for silence ends.
- If a channel fails or nobody answers
- A channel that reports failure advances the fallback order on that carrier signal; silence takes the path drawn for it, with the deadline you set. Delivery callbacks that arrive late update the record when they arrive. An API step that answers no, or fails, takes the branch drawn for it; the platform does not act on your system's behalf beyond that request.
- Success metric
- the drifting patient reached before they are lost. Population: contacts who entered the journey in the window. Compared with the baseline window agreed before the pilot, on the conversion events you define. A before-and-after difference is a comparison, not proof of cause.
What it takes to run
Where a step says your system decides, the journey calls your system and branches on its answer. xNotify carries the journey; it does not become the model.