Student Onboarding and Orientation

A student pays, and then goes quiet for three weeks. The provider treats enrollment as the finish line, sends a welcome email with a login and a handbook attached, and waits for the start date. What actually happens in that gap is that the decision cools. The student has not logged in, has not met anyone, has not done anything, and has nothing invested beyond the payment. By the time week one arrives, a predictable share of a paid cohort has not shown up, and the ones who do show up arrive unprepared because nobody made them do anything first.

The first week then compounds the problem. Orientation is a single live session that a third of the cohort misses. Access to the learning platform is granted manually by somebody who is also teaching. Paperwork - the learning agreement, the accessibility declaration, the emergency contact, the photo consent - is chased by email at random intervals until somebody gives up. Nobody knows which students have logged in and which have not, so the first person to notice a disengaged student is the tutor marking an empty first assignment in week three. At that point the intervention is a rescue, not a nudge.

This is where completion rates and refund requests are decided, and it is almost entirely mechanical. Every signal you need is observable: did they log in, did they complete the orientation module, did they return the paperwork, did they submit the first small task, did they turn up to the first live session. A build that watches those five signals per student, chases the specific missing one, and escalates to a human only when the automation has genuinely failed, turns the first week from a hope into a process.

Pipeline and stages

One pipeline, Student Onboarding, holding every enrolled student from payment to the end of week one. Each card carries the cohort so the whole intake can be read as a column of progress.

• Enrolled - Not Started - payment complete, nothing done.
• Welcome Sent - welcome pack and portal credentials issued.
• Access Confirmed - first successful login to the learning platform recorded.
• Paperwork Outstanding - a holding stage a student can sit in while progressing elsewhere; worked as a checklist, not a blocker.
• Orientation Complete - orientation module finished or live orientation attended.
• First Task Submitted - the small week-one deliverable is in.
• Fully Onboarded - closed-won: access, paperwork, orientation and first task all done.
• At Risk - a parking stage for any student missing two or more signals past their due date, with a human owner attached.
• Withdrawn Before Start and Deferred - closed-lost variants, reported separately because they mean different things.

Calendars

• Live Orientation - one session per cohort, scheduled a few days before the start date, with a recording published automatically for anyone who misses it.
• Tech Check Drop-in - 10-minute slots in the week before start, for students who cannot get into the platform or whose equipment needs testing. The single highest-value calendar in this build.
• Student Support One-to-One - 20-minute slots with the support team, released to anybody who declares a support need or lands in At Risk.
• Tutor Office Hours - recurring weekly slots published to the cohort from week one, so asking for help is a booking rather than a favor.
• Buddy or Peer Intro - optional paired slots where the cohort model supports it.

Custom fields

• Cohort Code, Course Name, Start Date, Delivery Mode, Tutor Assigned, Timezone
• Portal Account Created, Credentials Sent Date, First Login Date, Last Login Date
• Orientation Method (live attended, recording watched, module completed), Orientation Complete Date
• Learning Agreement Signed, Emergency Contact Provided, Photo and Recording Consent, ID Verified, Paperwork Outstanding as a list
• Support Needs Declared (yes or no only - the detail lives with student support, not on the marketing record), Support Contact Assigned, Adjustments Agreed
• Equipment Check Done, Platform Issue Flag
• First Task Due Date, First Task Submitted Date
• Onboarding Score - a count from zero to five of the signals completed: logged in, paperwork complete, orientation done, first task submitted, first live session attended. This one number drives every escalation in the build.
• Risk Flag Reason, Intervention Owner, Intervention Date
• Preferred Name and Pronouns if the provider collects them - used in message merge fields so the first contact gets the student's name right

Tags

• cohort-{{code}} and course-{{slug}} - the two segment tags every cohort-wide send uses
• welcome-sent, access-confirmed, never-logged-in
• paperwork-complete, paperwork-outstanding, agreement-signed
• orientation-live, orientation-recording, orientation-missed
• task-one-submitted, task-one-late
• tech-issue, tech-check-booked
• support-need-declared, support-contact-made
• at-risk, intervention-open, intervention-closed
• fully-onboarded, withdrawn-pre-start

Forms and surveys

• Student Details and Agreement - the single paperwork form, done once: preferred name, pronouns if collected, emergency contact, learning agreement acceptance, photo and recording consent, and a yes or no on whether any adjustments or support are needed. One form rather than four separate chases.
• Support Needs Request - a separate, access-restricted form sent only to students who answered yes above, routed to student support and never to a general inbox.
• Tech and Equipment Check - device, browser, connection, headset, and whether the student managed to open the platform. Triggers the drop-in booking if anything fails.
• Orientation Knowledge Check - five questions proving the student actually absorbed the handbook essentials: how to submit work, where to get help, the attendance expectation, the assessment schedule, the conduct policy. Doubles as proof of orientation.
• Day One Pulse - three questions at the end of week one: how prepared do you feel, is anything blocking you, how was the onboarding.
• Goals and Context - two open questions on why the student is taking the course and what they want from it, passed straight to the tutor so week one feels personal.

Memberships and course access

• A membership or course area per cohort, with the orientation module published immediately on enrollment and the week-one content released on a date trigger rather than all at once.
• An orientation module built as short lessons: a two-minute welcome video from the tutor, how to navigate the platform, how to submit work, where to get help, the schedule, and the knowledge check at the end.
• Automatic enrollment into the cohort group or community space on payment, with a scripted introduction prompt so the first post is not an empty page.
• Progress tracking enabled so lesson completion fires back into the automations.

BO's role and guardrails

• BO handles the week-one question queue: where to find things, how to submit, when the session is, how to reset a password, what the attendance expectation is. These are the same twenty questions every cohort, answered from the handbook and the cohort record.
• BO chases the specific outstanding item, books tech-check and support slots, and confirms the schedule in the student's own timezone.
• BO may not grant or extend platform access, change a deadline, agree an adjustment or accommodation, discuss fees, refunds or withdrawal, or give pastoral or academic guidance. Each routes to the named human.
• Any declared support need, disability, health matter or personal difficulty is acknowledged warmly in one line and handed immediately to the student support contact. BO asks no follow-up questions and records no detail in the chat transcript.
• Any mention of withdrawing, a refund, or distress routes to a human within the hour, tagged intervention-open.

Numbers and channels

• One student services sending number per region for transactional week-one reminders, with cohort messaging kept off the marketing number entirely.
• The student services email address routed into the platform inbox so the tutor and support see one timeline per student.
• Web chat inside the course area and on the student portal page, where questions actually arise.
• Calendar sync for tutors and support staff (Google Calendar or Outlook), and the video platform for live orientation and office hours.
• LMS or student information system connection for login events, lesson completion and submission events. Where no API exists, a scheduled import keeps First Login Date and Last Login Date current - without those two fields this build cannot see anything.

1. A student completes enrollment and payment. The enrollment build hands the contact over tagged enrolled, and a card is created in Student Onboarding at Enrolled - Not Started with Cohort Code, Start Date, Tutor Assigned and Timezone stamped from the cohort record.
2. Within five minutes the welcome pack arrives: a short note from the named tutor, the portal link and credentials, the Student Details and Agreement form, the orientation module link, and the live orientation date in the student's own timezone. One email, four clear actions, no attachments nobody opens.
3. The membership area is provisioned automatically, the student is added to the cohort community space, and the orientation module is published to them. The card moves to Welcome Sent and the tag welcome-sent is applied.
4. An SMS follows thirty minutes later with the single most important action only: "Your login for {{course}} is in your inbox. First step is the 15-minute orientation - start here: {{link}}"
5. The student logs in that evening. The LMS login event writes First Login Date, tags access-confirmed, moves the card to Access Confirmed, and increments Onboarding Score to one. The never-logged-in chase sequence exits.
6. She completes Student Details and Agreement, answering yes to the support question. Paperwork Outstanding clears, Support Needs Declared is set to yes, and the restricted Support Needs Request form is sent with a one-to-one booking link. Student support gets the task; nobody else sees the detail.
7. She works through the orientation module and passes the Orientation Knowledge Check. Orientation Method records module completed, the card moves to Orientation Complete, and Onboarding Score reaches three.
8. Two days before the start date the cohort gets the week-one briefing: the schedule, what to bring or install, the first task and its due date, the tutor's office hours, and the community introduction prompt. First Task Due Date is written to every card.
9. She attends Live Orientation, meets the tutor and six classmates, and posts her introduction in the cohort space. Attendance syncs back and Onboarding Score reaches four.
10. Day two of week one: she submits the first small task. First Task Submitted Date is written, the card moves to First Task Submitted, then to Fully Onboarded with Onboarding Score at five, and every chase sequence exits.
11. End of week one: the Day One Pulse survey goes out. She reports feeling prepared with one blocker about file formats, which creates a tutor task rather than disappearing into a report.
12. A classmate in the same cohort never logged in. By 48 hours after the welcome, the never-logged-in sequence has sent two messages and a password-reset path; by 96 hours his card is in At Risk with Risk Flag Reason set and a call task on the student services owner.
13. The tutor opens the cohort board on the morning of day one and sees, in one view, who is fully onboarded, who is missing paperwork, who has never logged in, and who needs a support conversation - before the first class rather than three weeks into it.
14. At the end of week one the cohort onboarding report is posted to the internal channel: score distribution, the specific items still outstanding, and the names in At Risk. The contact is then handed to the cohort communication cadence build for the rest of the program.

1. Enrollment Handover and Welcome Pack

Trigger: tag enrolled applied, or the enrollment pipeline card reaches an Enrolled stage.

• Create the card in Student Onboarding at Enrolled - Not Started. Stamp Cohort Code, Course Name, Start Date, Tutor Assigned, Timezone, First Task Due Date. Apply cohort-{{code}} and course-{{slug}}. Set Onboarding Score to zero.
• Provision the membership or course area, add the student to the cohort community space, publish the orientation module, and write Portal Account Created. On a provisioning error, retry once after 5 minutes, then notify the internal channel and assign a task - never send credentials that do not work.
• Wait 5 minutes. Email the welcome pack: "Welcome to {{course}}, {{preferred name}}. I am {{tutor}} and I will be teaching your cohort. Four things to do this week, in order: 1. Log in - {{portal link}} 2. Complete your student details and agreement - {{form link}} 3. Work through orientation, about 15 minutes - {{module link}} 4. Join us live on {{orientation date}} at {{local time}} - {{calendar link}}. Reply to this email with any question at all."
• Wait 30 minutes. SMS, one action only: "Welcome to {{course}}. Your login is in your inbox - first step is the short orientation: {{link}}"
• Move to Welcome Sent, tag welcome-sent, write Credentials Sent Date.
• Wait 24 hours, then send Goals and Context: "Two quick questions before we start - what made you sign up, and what do you most want to be able to do by the end? Your tutor reads every answer." Route responses to the tutor.
• Exit: first login recorded, or the card reaches Withdrawn Before Start.

2. Never-Logged-In Escalation

Trigger: tag welcome-sent applied.

• Condition: First Login Date is empty.
• Wait 24 hours. Email: "{{Preferred name}}, your {{course}} account is open but has not been used yet. If the login did not work, this resets it in one click: {{reset link}}. If something else is in the way, reply and we will fix it."
• Wait 24 hours. SMS: "Still cannot get into {{course}}? Grab a 10-minute tech check with us - we will get you in: {{tech check link}}"
• Wait 24 hours. Tag never-logged-in and at-risk, move the card to At Risk, set Risk Flag Reason to no login after 72 hours, assign a phone call task to the student services owner due same day, and notify the tutor.
• Wait 48 hours. If still no login and no human contact logged, escalate to the program manager and flag for a withdrawal conversation - the student may have changed their mind and nobody has asked.
• Exit immediately on any login event, on a reply to any message, on a tech check being booked, or on tag withdrawn-pre-start.

3. Paperwork Completion Chase

Trigger: tag welcome-sent applied.

• Condition: Paperwork Outstanding is not empty.
• Wait 48 hours. Email naming only the items actually missing: "Almost there - we still need {{outstanding items}} before {{start date}}. It takes about four minutes: {{form link}}"
• Wait 72 hours. SMS: "{{Preferred name}}, {{count}} item(s) outstanding for {{course}} enrollment. Four minutes: {{link}}"
• Wait 72 hours. Email with the reason rather than the demand: "We need your learning agreement and emergency contact on file before your first session - it is a condition of enrollment and it protects you as much as us. {{link}}"
• At 2 days before Start Date, if still outstanding: assign a task to student services, and send: "Your course starts on {{start date}} and we still need {{outstanding items}}. Reply here or call us and we can complete it with you over the phone."
• On submission: clear Paperwork Outstanding, tag paperwork-complete and agreement-signed, increment Onboarding Score, and run the support branch below.
• Branch - support question answered yes. Tag support-need-declared, set Support Needs Declared to yes, send only the restricted Support Needs Request form plus a Student Support One-to-One booking link, and assign the task to the named support contact due in 1 working day. The detail never enters the general record or any automated message: "Thanks for letting us know. {{Support contact}} looks after this and will be in touch within one working day - or book a time that suits you here: {{link}}"
• Exit: paperwork complete, or the card reaches a closed stage.

4. Orientation Completion Drive

Trigger: tag access-confirmed applied, or 5 days before Start Date, whichever is first.

• Condition: Orientation Complete Date is empty.
• Immediately: "Next step is orientation - 15 minutes, five short videos, and a few questions at the end so we know it landed. Do it before {{orientation date}} and the live session will make much more sense. {{module link}}"
• Run the live session reminder cadence in parallel: 24 hours before by email with the joining link and agenda, 2 hours before by SMS, 10 minutes before by SMS.
• Branch A - live session attended. Write Orientation Method as live attended, tag orientation-live, move to Orientation Complete, increment Onboarding Score.
• Branch B - live session missed. Tag orientation-missed. Wait 2 hours. Send the recording with a timestamp index and the module link: "Sorry we missed you last night. Here is the recording, and the orientation module covers the same ground at your own pace. Either one counts - we just need it done before your first class. {{links}}" Reminder at 48 hours, then at 1 day before Start Date an SMS.
• Branch C - module partially complete and stalled for 48 hours. Send one nudge naming the lesson they stopped at, with a resume link.
• Branch D - knowledge check failed. No pass-or-fail language. Send: "A couple of those answers suggest one bit of the handbook is worth a second look - here is the section, then give the questions another go. {{link}}"
• Exit: Orientation Complete Date written by any route.

5. Tech and Equipment Readiness

Trigger: 7 days before Start Date, for every card not in a closed stage.

• Send Tech and Equipment Check: "Two minutes now saves a frustrating first class. Check your setup here - device, browser, sound, and whether the platform opens properly for you. {{form link}}"
• Branch A - everything passes. Write Equipment Check Done, no further messages on this thread.
• Branch B - any failure, or the student reports being unable to open the platform. Tag tech-issue, set Platform Issue Flag, and send the Tech Check Drop-in booking link immediately: "Let us sort this before Monday rather than during it - grab 10 minutes here and we will get you running: {{link}}" On booking, tag tech-check-booked and notify the technical contact with the reported fault.
• Branch C - form not completed after 3 days. One SMS reminder. After a further 2 days, stop; absence of a tech check is not itself a risk signal.
• At 1 day before Start Date, any card still carrying tech-issue with no drop-in booked is assigned to the technical contact for a direct call.
• Exit: check passed, or the issue closed by a human.

6. Week One Rhythm and First Task

Trigger: 2 days before Start Date, cohort-wide to tag cohort-{{code}}.

• Email the week-one briefing: the full schedule in the student's timezone, what to install or bring, the first task and its due date, the tutor's office hours, and the community introduction prompt. "Your first task is small on purpose - it is due {{first task due date}} and should take about half an hour. Getting it in early is the single best predictor of a good term."
• On Start Date, SMS to the cohort: "Day one. Session at {{local time}} here: {{link}}. See you there."
• Wait until 1 day before First Task Due Date. Branch - not yet submitted: "{{Preferred name}}, first task is due tomorrow - half an hour, and your tutor would rather see a rough attempt than nothing. Submit here: {{link}} Stuck? Office hours are {{times}}."
• On the due date passing without submission: tag task-one-late, increment nothing, and send one supportive message with no penalty language: "Your first task is past its date. That happens - it is not a problem yet. Reply and tell us what is in the way, or book office hours: {{link}}"
• On submission: write First Task Submitted Date, tag task-one-submitted, increment Onboarding Score, move to First Task Submitted, and notify the tutor.
• Publish Tutor Office Hours to the cohort on day one and repeat the link in every week-one message.
• Exit: task submitted, or the card moves to At Risk under workflow 7.

7. Onboarding Score Watch and At Risk Intervention

Trigger: scheduled daily during the week before and the week of Start Date, plus on every Onboarding Score change.

• Condition: evaluate each card against its cohort dates rather than a fixed clock, so an early-enrolling student is not flagged for not having done week-one work.
• Branch A - score of 0 at 72 hours after welcome. Covered by workflow 2; ensure no duplicate messaging fires.
• Branch B - score of 1 or 2 at 2 days before Start Date. Tag at-risk, move to At Risk, write the specific gaps to Risk Flag Reason, set Intervention Owner, and assign a personal call task due same day. No automated message fires on this branch - the next contact is a human voice.
• Branch C - score of 3 or 4 at end of week one. Assign a light-touch task to the tutor: one personal message, not a sequence.
• Branch D - score of 5. Move to Fully Onboarded, tag fully-onboarded, exit every chase sequence on the contact, and hand to the cohort communication cadence build.
• On intervention logged: tag intervention-closed, write Intervention Date, and either return the card to its correct stage or move it to Withdrawn Before Start or Deferred with the reason recorded.
• If an At Risk card has no logged contact after 2 working days, escalate to the program manager. The stage exists to force a conversation, not to store students.
• Exit: Fully Onboarded, or a closed stage with a recorded reason.

8. End of Week One Pulse and Cohort Report

Trigger: 7 days after Start Date.

• Send Day One Pulse to the whole cohort: "One week in. Three questions: how prepared do you feel, one to five? Is anything blocking you right now? And was anything about getting started harder than it should have been?"
• Branch A - preparedness 4 or 5 with no blocker. Thank them, point at office hours, and nothing further.
• Branch B - preparedness 1 to 3, or any blocker named. Create a tutor task with the student's own words attached, due in 1 working day, and reply: "Thank you - that is useful and we are not going to leave it. {{Tutor}} will come back to you on this within a day."
• Branch C - any answer mentioning withdrawing, refund, or personal difficulty. Route to a human within the hour, tag intervention-open, and send nothing automated beyond an acknowledgement.
• Post the cohort report to the internal channel: Onboarding Score distribution, count by outstanding item, At Risk names with reasons, orientation coverage, first task submission rate, and the pulse themes verbatim.
• Wait 14 days. Send one onboarding-quality summary to the program manager comparing this cohort to the previous two on the same measures, so the retrospective has numbers in front of it.
• Exit: report issued and the pulse branches resolved.

The gap between payment and start stops being dead time. The student does something within hours of enrolling - logs in, signs the agreement, watches a two-minute welcome from the person who will actually teach them. That early action is what makes the start date feel like a continuation rather than a fresh decision.

Disengagement is caught in days, not weeks. A student who has not logged in by 48 hours is chased specifically for that, and is in front of a human by 96 hours. The tutor stops discovering problems at the first assignment deadline.

Paperwork completes itself. One consolidated form, chased on the specific missing item, with the sensitive follow-up routed to the right team rather than the general inbox. Staff stop spending week one as administrators.

Week one is the same for everyone. Live orientation, the recording and the module are three routes to the same outcome, all recorded identically, so a student who could not make Tuesday evening is not permanently a step behind.

The tutor opens day one informed. Preferred names, goals, declared support needs flagged (not detailed), and who is already behind. That changes the quality of the first hour of teaching.

Metrics to watch

• Time from enrollment to first login, median and the long tail. The tail is where the withdrawals live.
• Share of the cohort fully onboarded by the start date - the headline number for this build.
• Onboarding Score distribution per cohort on the start date and at end of week one.
• Never-logged-in count at 48 and 96 hours, and how many were recovered after human contact.
• Paperwork completion rate and median days to complete, before and after consolidating the forms.
• Orientation coverage - live, recording and module combined as a single percentage of the cohort.
• First task submission rate and on-time rate, the earliest reliable predictor of completion in most programs.
• Week-one withdrawal and refund request rate per cohort, tracked over consecutive intakes.
• At Risk volume and resolution time, plus how many at-risk students reached Fully Onboarded after intervention.
• Day One Pulse preparedness score, and the blocker themes, reviewed every cohort to fix the onboarding rather than re-chase the students.

Content and schedule

• The orientation module built and recorded before the first cohort runs. Short lessons, a tutor on camera, and a knowledge check. This is the single biggest piece of work in the build and it cannot be improvised in week one.
• A defined first task: small, achievable in under thirty minutes, with a due date in the first few days. Its purpose is behavioral, not academic. A heavy first assignment produces the opposite of engagement.
• A cohort record per intake with the start date, the live orientation date and time, the tutor, the schedule and the first task due date. Every message in this build merges from those fields.
• The student handbook as structured answerable content rather than a PDF, so BO can answer from it and the knowledge check can test it.
• Named owners: the tutor, the student services contact who works At Risk, and the student support contact who receives declared support needs.

Integrations

• LMS or course platform connection delivering login events, lesson completion and submission events. If the platform cannot emit these, agree a scheduled export via Zapier or Make - but be honest with the client that the build's visibility is only as fresh as that sync.
• Automatic account provisioning on enrollment, or an API call that creates the account and returns the credentials. Manual provisioning is the most common failure point: it quietly reintroduces a human delay at the moment speed matters most.
• Calendar sync for tutors and support staff, and the video platform for orientation and office hours, with attendance data flowing back.
• Community or group platform connection if the cohort space is separate from the course area.
• Document storage for signed agreements and ID, with access restricted to the staff who need it.

Numbers, messaging and compliance

• Provision the student services number and complete A2P 10DLC registration in the United States before the first cohort. These are transactional messages to enrolled students; register the campaign accordingly and submit sample copy that matches what the build sends.
• Collect SMS consent at enrollment with wording that covers course-related reminders, and keep it separate from any marketing consent. A current student should not be messaged about other courses on the same consent.
• Honor STOP, UNSUBSCRIBE and HELP on every number, and build the email fallback explicitly - a student who opts out of SMS still needs the schedule, so the automation must switch channel rather than go silent.
• Set quiet hours so no automated SMS sends outside roughly 08:00 to 20:00 in the student's own timezone. Online cohorts commonly span continents; messages that merge a local session time but send at 3am undo the goodwill the build is trying to create.
• This build touches genuinely sensitive data. Declared support needs, disabilities, health information, adjustments and emergency contacts need tighter handling than the rest of the record: keep a yes-or-no flag on the student record and the detail with student support, restrict field visibility by role, and never merge support detail into automated copy.
• Decide and document the retention period for signed agreements, ID documents and session recordings, and get explicit consent for recording live sessions where students appear - with a stated route for a student who declines.
• Where the provider operates under GDPR, UK GDPR, FERPA or similar regimes, confirm the lawful basis for each processing purpose, the privacy notice, the role-based access model, and the rules on contacting students after the course ends. Safeguarding duties may apply where any student is under 18, which changes consent, contact and recording requirements materially.
• None of this is legal advice. Have the client's own counsel and data-protection adviser confirm the consent wording, the access model, the retention schedule and any safeguarding or sector-specific obligations before the first cohort runs.

People and process

• A named owner for the At Risk stage who checks it daily during week one. The build generates the signal; a human still has to make the call.
• An agreed escalation standard: contact attempt within one working day of a risk flag, and a documented outcome before the card leaves the stage.
• A short cohort retrospective after each intake, reading the Day One Pulse themes and the score distribution, with one onboarding fix carried into the next cohort.
• Scoping and pricing are per build. Book a call at bookings.appbo.io to work through the LMS integration, the orientation content and the support-data access model.