- Applicants sign up, apply and pay an application or acceptance fee online.
- Your backend can send events at each step (the Node, Go and PHP SDKs, or the HTTP API).
- An admissions team can call applicants who stall before paying.
| How | What |
|---|
| Events from your app or website (needs a developer) | Your admissions portal sends the four funnel events and sets the stage trait. |
| Kind | Name | What it does | Lands |
|---|
| Team | Admissions | Calls applicants who haven't paid; gets the weekly report. | Empty |
| Team | Admissions leads | Hears about calls not made in time. | Empty |
| Segment | Signed up, no application | Signed up in the last 30 days but never applied. | Ready |
| Segment | Applied, not paid | Applied (or started checkout) but hasn't paid. | Ready |
| Segment | Paid applicants | Paid the application fee. | Ready |
| Template | Start your application (email) | Nudge to start an application. | Ready |
| Template | Complete your application (email) | Reminder to complete payment. | Ready |
| Template | Complete your application (SMS) | Last payment reminder by SMS. | Ready |
| Template | Payment received, next steps (email) | Next steps after payment. | Ready |
| Question | Report: applications | Applications in the report's period. | Ready |
| Question | Report: paid applicants | Paid applicants in the report's period. | Ready |
| Question | Report: sign-ups | Sign-ups in the report's period. | Ready |
| Funnel | Admissions funnel | Sign-up → application → checkout → paid, within 30 days. | Ready |
| Dashboard | Admissions | The funnel and this period's numbers. | Ready |
| Report | Weekly: admissions | The week's sign-ups, applications and payments, and where applicants stand now. | Off |
| Follow-up | Admissions 1: start your application | Signed up but didn't apply? Two nudges, stopping once they apply. | Off |
| Follow-up | Admissions 2: complete your application | Applied but didn't pay? Email, then SMS, then a call from admissions; each step skipped once they pay. | Off |
| Follow-up | Admissions 3: payment received | Next-steps email when the payment comes in. | Off |
| # | Question | Default | Fills in |
|---|
| 1 | What should messages call your school? | none, must answer | org_name |
| 2 | Where do applicants apply or pay? (a link to your portal) | none, must answer | application_url |
| 3 | Which team calls applicants who haven't paid? | Admissions | admissions_team |
| 4 | Who should hear if admissions doesn't call in time? | Admissions leads | escalation_team |
| 5 | Which address should emails come from? | none, must answer | email_from |
These have defaults. Change any that don’t fit.
| Setting | Default | Key |
|---|
| Sign-up event | Signed Up | signup_event |
| Application submitted (unpaid) event | Application Submitted | application_event |
| Checkout started event | Checkout Started | checkout_event |
| Payment succeeded event | Payment Successful | payment_event |
| Stage trait your backend sets | lead_status | stage_trait |
| Time zone for the report | ‹workspace timezone› | timezone |
| Greeting when a first name is missing | there | greeting_fallback |
| Weekly admissions report | 0 8 * * 1 | report_cron |
- Signed up, no application: a nudge after 1 day and another 3 days later; it stops as soon as they apply.
- Applied, not paid: an email reminder after 1 day, an SMS 2 days later, and a call task for admissions 1 day after that, due in 48 hours and escalated after 48. Each step is skipped once they've paid.
- Paid applicants get the next-steps email straight away.
- Weekly admissions report: 0 8 * * 1 in ‹workspace timezone›.
| Channel | Needed for | Before it can send |
|---|
| email | Nudges, reminders and next steps | A verified sending domain for ‹Sender address›. On a self-hosted (BYOD) data plane, your own email connection. |
| sms | The last payment reminder | An SMS provider, or Origamy managed SMS after business verification (KYC). |
- Send the four events from your backend, and set lead_status with an identify call before each one, so a follow-up starting on the event sees the new stage: application_submitted, checkout_initiated, then paid_application. Only application-fee steps should move the stage, so a paid applicant never drops back.
- Give each event a stable messageId per occurrence (for example payment_successful:<payment reference>), so webhook retries are dropped.
- Send the applicant's country with their phone number, so the number is stored in international format.
- Add people to the Admissions and Admissions leads teams.
- Verify the sending domain; for the SMS, connect a provider or finish business verification.
- Switch the follow-ups and report on (a follow-up only runs once it's on), run one test applicant through with your own phone and email, check every message, then erase the test applicant.
- Identify before you track. The school’s backend sets the stage trait with an identify call
just before each event, so a follow-up starting on the event already sees the new stage.
- One stage trait, moved only by application steps. A paid applicant who opens a tuition
checkout keeps
paid_application.
- Event-named traits for segments. The school also saves each funnel event’s properties in a
trait named after the event (for example
Payment Successful.amount), so segments can filter
on them. A trait only holds the latest occurrence.
- Retries are safe when every event carries a stable messageId per occurrence.
- Email on a self-hosted data plane goes through your own email connection; give it its
own events queue to get delivery reports.
The request used to test the copilot on this playbook (a live eval):
We're an online school. Our backend sends Signed Up, Application Submitted, Checkout Started and Payment Successful, and sets lead_status. Nudge people who signed up but never applied, remind applicants who haven't paid by email then SMS, and if they still haven't paid have admissions call them. Send a next-steps email after payment, and email the admissions team a weekly funnel report.
It passes when every piece is a valid draft and everything lands off, with at least: segment, workflow, message_template, report.
