Meditation Student Portal: operations workflow analysis
Reconstructed public case-study artifact Prepared October 2026
Source basis
Unlike the financial-sector documents above, this example is derived from an independently developed product with an inspectable public codebase. The operator confirmed that the portal is actively used. The flow below is simplified, and no private student records, live metrics or account details are included.
Public repository: https://github.com/pusulamkendim/meditation-student-portal
Operational problem
A recurring one-to-one student service coordinates onboarding, payment notification, manual approval, subscription periods, four scheduled meetings, daily practice reminders, responses and renewals. Manual handling across messaging apps and calendars introduces avoidable coordination overhead.
Actors
- Student: starts enrollment, submits payment notification, receives plan and messages
- Administrator: reviews payment, approves activation and maintains appointments
- API: applies deterministic business rules and records state changes
- Background worker: schedules and sends eligible communications
- AI support functions: knowledge retrieval or summaries within defined boundaries
Core lifecycle
- Student begins registration through a supported messaging channel.
- System collects required enrollment information and checks applicable permissions.
- Student submits a payment notification or proof.
- A human administrator verifies and approves the payment.
- Membership period is created or activated.
- Admin-managed meeting schedule and daily practice plan are applied.
- Worker prepares reminders and follow-up messages.
- Eligibility and consent state are rechecked before a message is delivered.
- At the appropriate point, renewal or expiry rules apply.
The system deliberately does not permit an AI agent to approve a payment.
Acceptance criteria (representative, not an exported client test suite)
- If payment is awaiting approval, activation does not happen automatically.
- If the administrator approves a payment, a new membership period follows the configured package rules.
- When a student has no active eligible period, proactive practice messages are suppressed.
- When a student withdraws relevant AI consent, subsequent AI processing for that consent scope stops.
- The same inbound webhook should not cause multiple independent registration or payment records.
- Where a delivery is uncertain, operations require inspectable handling rather than silent loss.
Illustrative test cases
| ID | Scenario | Check |
|---|---|---|
| OPS-01 | Registration started through WhatsApp | Student and channel context preserved |
| OPS-02 | Payment notification arrives | Review record created, no autonomous approval |
| OPS-03 | Admin confirms payment | Eligible membership period created |
| OPS-04 | Subscription expires | Future proactive messages suppressed |
| OPS-05 | Reminder worker retries | Duplicate delivery protected by idempotency semantics |
| OPS-06 | Consent revoked | Future constrained AI work rejected |
| OPS-07 | Meeting rescheduled | Associated calendar and notification state reconciled |
Implementation boundary
The repository contains Next.js administration, NestJS API, PostgreSQL/Prisma, pg-boss workers, channel webhooks and tests. Public documentation also records historical risks concerning message dispatch recovery and fine-grained permissions; those issues require a fresh security review before expanded exposure.
Outcome statement
Confirmed: the product is in active use and the repository contains the documented modules. Not established: number of users, hours saved, retention improvement, delivery SLA, conversion lift or commercial scale.