edurise — the student affairs operating system
One automation-first workspace that connects students and teachers end to end: capture, match, schedule, deliver, follow up. Built so a coordinator runs the whole day in the fewest possible taps.
Standard operating procedure
The lifecycle of one student↔teacher engagement, from first contact to follow-up. Each phase lists who acts, what the system does, and what fires automatically.
Exception & escalation handling
| Trigger | System response | Routed to |
|---|---|---|
| No-show / no reply to 2 reminders | Auto-flags booking, drafts reschedule message | Coordinator |
| Teacher declines or unavailable | Re-runs auto-match, surfaces next best teacher | Coordinator (1-tap) |
| Repeat technical / quality issue | Escalation flag, posts to Lark manager channel | Manager |
| Payment unpaid at T-12h | Auto payment-reminder, holds Zoom link release | System |
| Complaint keyword in WhatsApp reply | Sentiment detection raises priority ticket | Manager |
System architecture
A single HTML/CSS/JS dashboard sits at the centre. It speaks to the channels students and teachers already use, and to an automation layer that does the repetitive work. The interface stays thin; the logic lives in clearly separated layers so any piece can be swapped or scaled later.
Build & integration approach
- Phase 1 — standalone HTML app. The entire dashboard ships as one HTML/CSS/JS bundle with an in-memory or local data store. It is fully usable on day one with the team entering requests manually — exactly what you're interacting with above.
- Phase 2 — connect the channels. Each integration is an isolated adapter so it can be added without touching the UI: a website webhook for the booking form, the WhatsApp Business API for messaging, the Zoom API for link creation, and Lark for internal routing.
- Separation of concerns. Interface, automation rules, and data never mix. A new channel or a new rule is an additive change, never a rewrite.
Dashboard layout
The dashboard answers one question the moment it opens: "What needs me right now?" Nothing the system can handle alone is shown as a task. Everything is one scroll, one tap deep.
Today
KPI strip, your action queue, and the day's schedule. The first thing staff see each morning.
Bookings
Every booking as a card in its status column. Advance with one tap — the system does the rest.
Sessions
Upcoming online and in-person classes, calendar-synced, ready to start.
Automations
A read-only log of everything the system did, so trust is visible and nothing feels like a black box.
What appears, and when
| Zone | Shows | Why it's there |
|---|---|---|
| KPI strip | Sessions today · awaiting action · automated today · escalations | Whole-day health in 4 numbers, no clicks |
| Action queue | Only items needing a human — matches to confirm, escalations | The to-do list after the system filters out everything it handled |
| Schedule | Today's sessions in time order with channel + status | Glanceable timeline, tap for detail |
| Detail drawer | Full booking, lifecycle timeline, next action | Context on demand without leaving the page |
Recommended user journey
A coordinator's whole day, designed to be near-effortless. The system front-loads the work so the human steps in only at decision points.
- Morning glance (10 seconds). Open Today. The KPI strip and action queue show exactly what needs a human. Overnight requests are already captured, acknowledged, and waiting as draft matches.
- Clear the queue (a few taps). Each queued item has its next action on the card — Confirm match, Review escalation. Tap, done. The system then schedules, links, and notifies on its own.
- Let the day run itself. Reminders fire, links go out, calendars sync — all in the background. The coordinator watches the Automations feed only if they want reassurance.
- Handle exceptions as they surface. A no-show or complaint becomes a single flagged card with a drafted response ready to approve.
- Wrap up. Completed sessions auto-trigger feedback and rebooking. The coordinator reviews notes and closes — the relationship loop continues without a manual hand-off.
Automation flow design
Each transition between statuses is a trigger. When a booking enters a stage, the engine runs that stage's automations and only pauses where a human decision is genuinely needed.
| When booking enters… | Automation that runs | Human step? |
|---|---|---|
| New request | Parse fields · create booking · acknowledge on WhatsApp · suggest teacher | None |
| Matched | Notify teacher in Lark to accept | Confirm (1 tap) |
| Confirmed | Generate Zoom link · write calendars · send confirmation | None |
| Scheduled | Schedule 24h + 2h reminders · track replies | None |
| In session | Start timer · capture join event for attendance | Mark attendance |
| Completed | Queue feedback survey · draft progress note · prepare rebook offer | None |
| Follow-up | Send survey + rebooking link after 1h | Review & close |
Status tracking system
One status field drives the entire platform — the pipeline columns, the colour coding, what notifications fire, and what the coordinator sees. Status changes are logged, so every booking carries its own audit trail (visible in the drawer's lifecycle timeline).
| Status | Meaning | Owner | Auto-advances when |
|---|---|---|---|
| New request | Captured, not yet matched | System | A teacher is auto-suggested |
| Matched | Teacher proposed | Coordinator | Coordinator confirms |
| Confirmed | Teacher accepted, slot locking | System | Link + calendar created |
| Scheduled | Locked, reminders armed | System | Session start time reached |
| In session | Class in progress | Teacher | Attendance marked / session ends |
| Completed | Delivered | System | Follow-up sequence queued |
| Follow-up | Survey + rebooking out | Coordinator | Closed & logged |
Notification system
Notifications go to the right person on the channel they already use — students/parents on WhatsApp, teachers and managers on Lark — and the team gets escalations only. No notification noise, no one chasing anyone by hand.
| Event | Recipient | Channel | Type |
|---|---|---|---|
| Request received | Student / parent | Auto | |
| Teacher match to approve | Teacher | Lark | Auto |
| Booking confirmed + Zoom link | Student & teacher | WhatsApp + Lark | Auto |
| 24h & 2h reminders | Student & teacher | WhatsApp + Lark | Auto |
| Payment due | Student / parent | Auto | |
| Post-session feedback + rebook | Student / parent | Auto | |
| Escalation raised | Manager | Lark channel | Auto → human |
| No-show after 2 reminders | Coordinator | In-app + Lark | Auto → human |
UI / UX recommendations
Modern SaaS standards, tuned for speed and minimal training. The interface should feel obvious — a new hire productive in a day.
Clear visual hierarchy
Display type for headings, restrained body text, mono for IDs and times. Colour means something: it always signals manual vs automated.
One-tap actions
The next action lives on the card itself. No menus, no digging — the most common move is always the most visible.
Low cognitive load
Only what's needed, when it's needed. Detail hides in the drawer until summoned.
Light & dark mode
Full theming via design tokens; respects the device's system preference automatically. (Toggle it in the sidebar.)
Accessible
Visible keyboard focus, 44px touch targets, reduced-motion support, and readable contrast in both themes.
Plain language
Buttons say what happens — "Generate Zoom + notify", not "Submit". An action keeps its name through to the confirmation toast.
Mobile experience design
Mobile-first, not mobile-also. Coordinators and teachers often work from a phone, so the phone layout is the primary design — desktop is the roomier version of it.
- Bottom tab bar replaces the sidebar — thumb-reachable, four destinations, an alert badge on escalations. (Resize this window narrow to see it.)
- Horizontal snap-scroll pipeline — columns swipe one at a time so the board works on a small screen without shrinking cards.
- Full-screen detail sheet — the drawer becomes a sheet, with the primary action pinned to the bottom where the thumb is.
- Safe-area aware — respects notches and home indicators; targets stay at least 44px.
Employee workflow optimization
Every design choice is measured against one question: does this remove a tap, a wait, or a chance to make a mistake?
| Old manual way | edurise way | Saved |
|---|---|---|
| Re-type enquiry details into a sheet | Auto-parsed into a booking | ~100% data entry |
| Search a spreadsheet for a free teacher | Best-fit suggested instantly | Minutes per match |
| Create Zoom link, copy, paste, send | Generated & sent on confirm | 4 steps → 0 |
| Message each student a reminder | Reminders auto-scheduled | Dozens of messages |
| Chase feedback after class | Survey + rebook auto-sent | Full follow-up loop |
| Update a status column by hand | Status follows the action | Every update |
Future scalability recommendations
The architecture grows without rework because the interface, rules, and data are separate, and channels attach as independent adapters.
- More channels, same UI. Add Telegram, SMS, or a parent app as new adapters — the dashboard doesn't change.
- Multi-branch / franchise. Add a location dimension to bookings and teachers; the same pipeline scopes per branch with a roll-up view for head office.
- Roles & permissions. Layer in teacher and manager logins; teachers see their own sessions, managers see escalations and analytics.
- Smarter matching. Evolve auto-match from rules to learned preferences — pairing on outcomes, ratings, and student progress, not just availability.
- Analytics & forecasting. Turn the status log into dashboards: utilisation, no-show rates, teacher load, revenue per subject — and predict demand to staff ahead of it.
- Self-service for teachers & parents. Let teachers set availability and parents rebook directly, shrinking the coordinator's load even as volume grows.
- Payments & packages. Attach billing, prepaid lesson packages, and auto-renewals to the same booking record.