Running the cohort — the operations playbook

What ops can and can’t do

Operations is the day-to-day hands-on role. Ops sees and acts on the cohort but can’t change platform-wide things like the catalog or branding. The split between ops and admin is intentional: ops moves fast on student-facing work without risking global changes.

What you can do

• Review every application — approve, defer, reject, archive.
• Create and manage batches (cohort instances of a course).
• Mark students as enrolled, active, completed.
• Mark attendance for any session.
• View payment records and flag reconciliation issues.
• Send broadcast and targeted messages to students.

What only admin can do (escalate up)

• Create or modify user accounts (trainer, ops, admin).
• Edit the course catalog (fee, cohort dates, descriptions).
• Issue or revoke certificates manually.
• Change branding (colours, names, custom domain).
• Override the payment gate for a student (controlled path).

The operations workbench

Your home page is /operations. Sections:

• Today’s queue — applications + payments that need a decision right now.
• This week’s sessions — live sessions across all active batches, with attendance status.
• Active batches — cohorts currently running.
• Recent payments — last 7 days of payment events with Razorpay reference IDs.
• Messages outbox — what got dispatched, what bounced.

The admissions workbench and roster page are the two surfaces you’ll bounce between most. Both are linked from the operations dashboard.

Reviewing applications

New applications arrive via the public /apply form. Every application starts in submitted stage; ops reviews, then advances or defers.

Application lifecycle stages

• submitted — student filled the form, hasn’t paid yet.
• paid — Razorpay webhook confirmed payment. Triggered automatically.
• enrolled — ops has assigned them to a batch. Student now sees full LMS access.
• active — cohort has started; student is participating.
• in_progress — past mid-cohort, on track.
• completed — finished the cohort, passed or failed the test.
• certificate_issued — passed + cert auto-issued.
• archived — withdrew, refunded, or never enrolled.

Reviewing a fresh application

1. Open /admissions. Filter by stage = submitted or paid.
2. Click into the row. You see name, contact, programme, source, education, and payment status.
3. Decide the action — usually: enrolled + assign to the right batch. Click Mark enrolled.
4. The student receives the enrollment-confirmation email + login credentials.

Batches & cohorts

A batch is a specific cohort instance of a course — e.g. P·01 May 2026 batch. Each batch has start and end dates, a roster of enrolled students, scheduled sessions, and a primary trainer.

Creating a batch

1. Operations dashboard › Batches › New batch.
2. Pick the course (e.g. P·01).
3. Set start date and expected end date.
4. Assign the primary trainer (must already exist as a user).
5. Save. The batch appears in the active-batches list with capacity = 24 (the default for the small-group format).

Assigning students to a batch

When you mark an application enrolled, the system attempts to auto-assign to the most-recently-updated batch for that course code. If you want to assign to a specific batch instead:

1. Open the application row.
2. Click Reassign batch.
3. Pick the target batch from the dropdown.
4. Save.

Enrolling a student — the standard flow

1. New application arrives. You see it in the submitted queue.
2. Student pays via Razorpay. The webhook flips the application to paid within seconds.
3. You open the row, verify everything looks right (name spelling, programme match), click Mark enrolled.
4. Student receives:
   • Enrollment-confirmation email.
   • Login credentials email.
   • WhatsApp message with the cohort group invite link (when configured).
5. Student logs in to the portal and sees the locked modules + first live session date.

If the student didn’t receive credentials

Check the messages outbox — was the email dispatched? If sent but not received, ask the student to check spam, then forward you their email confirmation as evidence. You can re-send via /messages. If the message wasn’t dispatched at all (status: failed), the integration may be down — escalate to admin.

Attendance & the live-session roll

Attendance is logged two ways: automatically when a student joins the Zoom meeting (the Zoom webhook fires) and manually by ops or the trainer for edge cases.

The auto path

The Zoom webhook fires participant joined and participant left events. The platform records these and marks attendance status as present if a student was in the meeting for at least 30 minutes. No action from you.

Manual corrections

1. Operations dashboard › This week’s sessions.
2. Click into the session row.
3. You see the roster with auto-detected attendance status.
4. Override where needed — set a student to present, absent, or excused.
5. If you set excused, enter a short reason for the audit trail.
6. Save.

Payment reconciliation

99% of payments happen automatically through Razorpay. The 1% that need ops attention:

The student paid but the application still shows pending

1. Ask the student for their Razorpay payment ID (it’s in their bank/UPI statement).
2. Check the payments list in the ops dashboard — search by Razorpay ID.
3. If you can see the payment but the application isn’t linked: there’s a reference mismatch. Capture the payment ID + application ID and write to admin/engineering — they’ll reconcile.
4. If the payment isn’t in our system at all: the webhook didn’t arrive. Pull the Razorpay dashboard, confirm the payment captured, then have admin manually mark paid via the controlled override.

The student wants a receipt

Every payment generates a public receipt page at /payment/receipt/<applicationId>?tenant=.... The link is in the enrollment-confirmation email. If the student lost it, you can find their application, click Receipt, and copy the link to share.

Refunds & cohort transfers

Refunds are an admin-only action because they touch money. Your role is to capture the case clearly and pass it up.

Capturing a refund request

1. Get the student’s written request (email or WhatsApp — saved).
2. Note application ID, programme, fee paid, days since payment, and the stated reason.
3. Mark the application as refund_requested with a note containing the above.
4. Notify admin with a short summary. Admin reviews against the refund policy and processes via Razorpay.
5. Once the refund clears, admin will archive the application. You’ll see it move to archived.

Cohort transfers

Sometimes a student needs to defer to a later cohort (medical, work emergency). The standard approach is: keep the fee, transfer the student to the next cohort batch, send a confirmation. No money changes hands.

1. Confirm there’s capacity in the target batch.
2. Reassign the student’s application to the new batch.
3. Send them a transfer-confirmation message via /messages.
4. Note the transfer reason in the application’s notes.

Sending student communications

The messaging center at /messages is where ops sends broadcast or targeted messages.

Targeting

• All students — broadcast (use sparingly; you’ll dilute the signal).
• By cohort — e.g. “P·01 May 2026 batch” — the bread-and-butter scope.
• By individual — for personal follow-ups.

Channels

• Email via Resend. Best for longer / formal content.
• WhatsApp (when the WhatsApp template is configured). Best for time-sensitive nudges.
• Both for important announcements (e.g. cohort start date).

What to write

• Keep subject lines short and specific. “P·01 — session moved to Saturday” beats “Important update.”
• Open with the action item — what the student needs to do, if anything.
• Sign off with a contact for replies (so they don’t reply-all to the broadcast).

A typical week — the ops checklist

What a healthy operations week looks like, day by day:

Monday

• Clear the application queue accumulated over the weekend.
• Confirm last week’s attendance was finalised correctly.
• Send the week-ahead message to active cohorts (session times, expected submissions).

Tuesday – Thursday

• Same-day enrollment for any payments received the day before.
• Monitor live sessions — be available in the cohort WhatsApp group for Zoom hiccups.
• Mark attendance corrections before the daily cron fires.

Friday

• Review the weekly cohort report — completion %, attendance %, payments owed.
• Flag anyone whose attendance dropped below 75% for a check-in.
• Send the weekend-prep message (any catch-up reading, optional resources).

Monthly

• Review payment reconciliation — every Razorpay payment should map to one application.
• Audit the certificates issued in the last 30 days against the test pass list.
• Sync with admin on the next month’s cohort planning.

When to escalate to admin

Don’t hesitate. Escalation isn’t a sign of weakness — these are the cases where the platform’s audit trail and role boundaries are explicitly designed for someone else to act:

• Money out — refunds, partial refunds, fee waivers. Always admin.
• Catalog changes — fee change, cohort date change, new programme.
• Certificate issues — wrong name on a cert, suspected cheating, revocation request.
• Suspected duplicate-application fraud — same person under different emails.
• Trainer or ops account changes — new hire, role change, removal.
• Branding or copy changes — name spelling on the homepage, footer email address, etc.
• Anything legal — student threatens to sue, regulator inquiry, RTI-like request.
• Anything that feels weird — trust the instinct.

How to escalate: WhatsApp first for urgent (under-30-min response needed), email for everything else. Always include:

• Application ID or student email (whichever you have).
• What happened (one paragraph).
• What you tried (one paragraph).
• What you think the right next action is (one sentence).