Education · Playbook
The education playbook. Built in the builder, decided by your records.
Ten journeys, each drawn below as it runs. The decision comes from your admissions system, your LMS, your ledger or criteria you set; the journey carries it. Aims are targets to agree in the pilot, not results.
PLAYBOOKS · 01Illustrative journey
Offer the next course the day the last one ends.
A final module completed asks your catalogue whether the next course in the track is open and not yet taken, then sends one WhatsApp with Enrol or Not now; a tap goes to your system to enrol them.
- Decides
- your catalogue and your enrolment rules.
- Aim
- the next enrolment without a sales call.
Built in the journey builder
Offer the next course the day the last one endsEDUCATIONYour catalogue answers before anyone is offered anything.
Campaign Start · APIFinal module completed (from your LMS)
API CallNext course open? Enrolled? Your catalogue
Open, not enrolled
Already enrolled
WhatsApp FlowWhatsApp: Enrol / Not now
Enrol
Not now
No reply
API CallYour system enrols them
Message · WhatsAppConfirmation with the start date
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
- the next enrolment without a sales call.
- Trigger
- final module completed (your LMS)
- Events and identifiers
- final module completed (your LMS). 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
- next course open? enrolled? (your catalogue) · your system enrols them. 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
- the next enrolment without a sales call. 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 early-bird renewal while they are still learning.
A plan ending in thirty days checks whether a lesson was opened this week, fetches the plan and price from your billing system, then sends one WhatsApp with Renew early or Not now; a tap goes to your billing system to renew.
- Decides
- your billing system and the window you set.
- Aim
- renewals before the plan lapses.
Built in the journey builder
Offer the early-bird renewal while they are still learningEDUCATIONOnly a learner active this week is offered the early price; the rest get the standard notice.
Campaign Start · APIPlan ends in 30 days (from your billing)
Event CheckLesson opened this week?
Yes
No
API CallPlan and price from your billing
WhatsApp FlowWhatsApp: Renew early / Not now
Renew early
Not now
No reply
API CallYour billing renews the plan
Message · WhatsAppConfirmation
End
End
End
Wait TimeWait until the standard notice date
Message · EmailStandard renewal notice
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
- renewals before the plan lapses.
- Trigger
- plan ends in 30 days (your billing)
- Events and identifiers
- plan ends in 30 days (your billing). 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
- plan and price (your billing) · your billing renews the plan. 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
- not active: the standard notice, by email. 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
- renewals before the plan lapses. 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
Finish the application that stopped at the documents step.
A session with the documents step opened and no upload sends one WhatsApp with a link back to the step and the deadline from your admissions system, reminds once before the deadline, and calls if it is still open.
- Decides
- a rule you set, and the deadline your system holds.
- Aim
- more applications submitted before the deadline.
Built in the journey builder
Finish the application that stopped at the documents stepEDUCATIONA session rule, a consent check, the deadline from your system, one reminder, then a call.
Campaign StartDocuments opened, no upload (session rule)
Check Channel ConsentCheck consent
API CallDeadline from your admissions system
WhatsApp FlowWhatsApp with a link back to the step
Tapped
No reply
Event CheckSubmitted?
Yes
No
End
Message · WhatsAppOne reminder before the deadline
IVR CallStill open: call
End
Message · SMSSMS with the same link
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 applications submitted before the deadline.
- Trigger
- session rule: documents step opened, no upload
- Events and identifiers
- session rule: documents step opened, no upload. 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
- deadline (your admissions system). 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
- submitted? 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
- more applications submitted before the deadline. 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
Catch the deposit that went quiet.
A student with the deposit paid and no portal login in twenty-one days enters a segment and gets one message with the next step, from admissions; a reply becomes a task for an admissions officer, and silence reaches the parent per consent.
- Decides
- your segment definition and consent.
- Aim
- fewer admitted students lost before the first day.
Built in the journey builder
Catch the deposit that went quietEDUCATIONOne message with the next step; a reply reaches a person, silence reaches the parent.
Segment EntryDeposit paid, no portal login in 21 days
Message · InboxOne message with the next step (admissions)
Reply
No reply
API CallTask to the admissions officer (your system)
End
Wait TimeWait 7 days
Check Channel ConsentParent consent?
Yes
No
Message · SMSSMS to the parent
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
- fewer admitted students lost before the first day.
- Trigger
- segment entry: deposit paid, no login in 21 days
- Events and identifiers
- segment entry: deposit paid, no login in 21 days. 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 the admissions officer. 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 admitted students lost before the first 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 · 05Illustrative journey
Reach the student who stopped opening lessons.
A student with no lesson opened in fourteen days gets one push and Inbox message to pick up where they left off; if nothing opens in three days, a WhatsApp from the tutor, and if there is still no reply, a task in your system.
- Decides
- the window you set.
- Aim
- fewer students lost mid-course.
Built in the journey builder
Reach the student who stopped opening lessonsEDUCATIONOne message on their own channel, then the tutor, then a task for a person.
Segment EntryNo lesson opened in 14 days
Check Channel ConsentCheck consent
Push + InboxPush and Inbox: pick up where you left off
Event CheckLesson opened within 3 days?
Yes
No
End
WhatsApp FlowWhatsApp from the tutor
Reply
No reply
End
API CallTask to the tutor (your system)
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 students lost mid-course.
- Trigger
- segment entry: no lesson opened in 14 days
- Events and identifiers
- segment entry: no lesson opened in 14 days. 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
- no reply: task to the tutor. 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
- lesson opened within 3 days? 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
- fewer students lost mid-course. 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
Act on attendance the week it falls.
An attendance mark below the line you set for a second week checks the parent's consent, then sends one WhatsApp with two buttons, Call me and I am aware; the answer is written back and the tutor gets the task, and silence becomes a call.
- Decides
- your attendance threshold and consent.
- Aim
- absences addressed in the same week.
Built in the journey builder
Act on attendance the week it fallsEDUCATIONThe parent answers with a tap; the answer is written back and a person picks it up.
Campaign Start · APIAttendance below your line, second week (SIS)
Check Channel ConsentParent consent
WhatsApp FlowWhatsApp to the parent: Call me / I am aware
Call me
I am aware
No reply
API CallTask to the tutor (your system)
End
API CallAnswer written back to your records
End
IVR CallCall the parent
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
- absences addressed in the same week.
- Trigger
- attendance below your line, second week (your SIS)
- Events and identifiers
- attendance below your line, second week (your SIS). 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 the tutor · aware: answer written back. 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 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
- absences addressed in the same week. 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
Turn a low mock score into a tutoring session.
A mock exam below the pass line asks your system whether a session is already booked, then sends one WhatsApp with Book a session or Not now; a tap fetches the open slots, the student picks one, and the booking is confirmed.
- Decides
- your system's bookings and the pass line you set.
- Aim
- sessions booked before the real exam.
Built in the journey builder
Turn a low mock score into a tutoring sessionEDUCATIONYour system confirms nothing is booked, then the student picks a slot from the ones you hold.
Campaign Start · APIMock exam below the pass line (from your LMS)
API CallSession already booked? Ask your system
Not booked
Booked
WhatsApp FlowWhatsApp: Book a session / Not now
Book a session
Not now
No reply
API CallFetch open slots from your system
Button ClickedStudent picks a slot
Message · WhatsAppConfirmation
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
- sessions booked before the real exam.
- Trigger
- mock exam below the pass line (your LMS)
- Events and identifiers
- mock exam below the pass line (your LMS). 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
- session already booked? (your system) · open slots (your system). 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
- sessions booked before the real exam. 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
Remind the fee on the real date, then escalate.
The journey waits until the due date your ledger holds, sends Pay now to the payer, stops when your ledger says paid, and escalates by channel if not, with the outcome written back.
- Decides
- your ledger's due date and paid status.
- Aim
- fewer late fees, lower cost to collect.
Built in the journey builder
Remind the fee on the real date, then escalateEDUCATIONWaits until the date your ledger holds, stops when paid, escalates by channel if not.
Campaign Start · APIDue date (from your ledger)
Wait Until DateWait until the due date
Message · WhatsAppPay now, to the payer
Event CheckPaid? Ask your ledger
Yes
No
End
Message · SMSSMS
IVR CallCall
API CallOutcome to your ledger
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 late fees, lower cost to collect.
- Trigger
- due date (your ledger)
- Events and identifiers
- due date (your ledger). 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
- outcome to your ledger. 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
- paid? 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
- fewer late fees, lower cost to collect. 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
Tell students and parents about a change, each their way.
A published change goes by push and Inbox to students on the app, with SMS for any who do not read it, and by SMS to parents per consent, so each person is reached on the channel they consented to, once.
- Decides
- your system; consent per contact.
- Aim
- everyone informed, each once.
Built in the journey builder
Tell students and parents about a change, each their wayEDUCATIONPush and Inbox to the student, SMS if unread, SMS to the parent per consent.
Campaign Start · APITimetable change published (your system)
ConditionApp user?
Yes
No
Push + InboxPush and Inbox to the student
Delivery StatusRead?
Yes
No
End
Message · SMSSMS to the student
End
Check Channel ConsentParent consent?
Yes
No
Message · SMSSMS to the parent
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
- everyone informed, each once.
- Trigger
- change published (your system)
- Events and identifiers
- change published (your 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
- None beyond the platform's own records: the contact, its consent, and the delivery record.
- 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
- everyone informed, each once. 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
Welcome the accepted with a Story, and catch the melt.
An accepted offer with the deposit paid starts a first-week Story in the app or on your domain; if it is not completed in a week, one message with the checklist follows, and a student who still has not logged in enters the segment that reaches a person.
- Decides
- the event, and the window you set.
- Aim
- fewer first-week questions, fewer admitted students lost.
Built in the journey builder
Welcome the accepted with a Story, and catch the meltEDUCATIONA Story tracked page by page, one reminder, and the quiet ones handed to the segment that reaches a person.
Campaign Start · APIOffer accepted, deposit paid (your SIS)
StoryStory: your first week, in the app
Wait TimeWait 7 days
Event CheckStory completed?
Yes
No
End
Message · WhatsAppOne message with the checklist
Event CheckPortal login since?
Yes
No
End
Segment EntrySegment: deposit paid, gone quiet
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 first-week questions, fewer admitted students lost.
- Trigger
- offer accepted, deposit paid (your SIS)
- Events and identifiers
- offer accepted, deposit paid (your SIS) · segment: deposit paid, gone quiet. 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
- None beyond the platform's own records: the contact, its consent, and the delivery record.
- Consent
- Per-channel consent on the contact record is checked before any send.
- Stops when
- Story completed? stop · portal login since? 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
- fewer first-week questions, fewer admitted students 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.