Operations documentation
Academy
A professional operating manual for the Academy flow in Elizabeth CRM: setup, lead intake, counselling, status movement, assessment, payment readiness, Accounts verification, student creation, batch allocation, fee collection, onboarding, academic delivery, monitoring, escalations, complaints, transfers, exams, certificates, reports, and exception handling.
2026
Complete Academy flow reference for all current CRM cases.
1. System Overview
The Academy module is the CRM operating layer for enquiries that become students. The system starts with master setup, accepts leads from multiple sources, tracks counsellor action, moves qualified leads into payment readiness, lets Accounts verify or collect fees, creates or links the student record, assigns the student to a batch, and then tracks delivery through academic, financial, and operational controls.
1Master setupBranches, courses, batches, fees, accounts, staff, roles, permissions, statuses, and gateways are prepared.
2Lead captureManual lead, self-added lead, Facebook lead, imported lead, or assigned lead enters the CRM.
3ScreeningDuplicate, department, branch, source, section, subsection, and assignment checks are completed.
4CounsellingStaff update status, notes, follow-up date, WhatsApp/call action, and admin review needs.
5AssessmentLead or student is assessed when academic level, course, or batch recommendation is required.
6Ready for paymentLead reaches ready-for-payment report stage directly or after assessment approval.
7Accounts queueAcademy payment request is created and Accounts is notified.
8PaymentAccounts confirms offline receipt, records advance, or generates and tracks a Razorpay link.
9StudentCRM creates or matches a student profile and marks the lead admission taken.
10Batch and feesEnrollment, invoice dues, receipts, fee ledger, discounts, and pending balances are maintained.
11AcademicsOnboarding, attendance, syllabus, mock tests, feedback, complaints, transfers, exams, and certificates continue.
12ReportsQC, CRE, academic, fees, attendance, screening, and management reports close the loop.
2. Master Setup Before Daily Operations
Academy operations depend on clean setup data. If setup is incomplete, downstream flows such as enrollment, fee sync, attendance, and reporting will be inconsistent.
| Setup area | What must be configured | Used by |
|---|---|---|
| Branches | Active branch records used by leads, students, batches, registration links, reports, and filtering. | Lead assignment, student profile, batch creation, registration link. |
| Courses | Course name, active status, and course relationship to batches. | Batch planning, student filtering, certificates, academic reporting. |
| Batches | Course, branch, code, start/end date, class time, capacity, active status, teacher/tutor, approval state, fee/account configuration. | Enrollment, waitlist, attendance, exams, certificates, fees. |
| Batch fees | Fee heads, due amounts, active flags, and due dates where applicable. | Student fee dues, invoices, fee ledger, reminders, fee reports. |
| Accounts setup | Cash/bank accounts, ledgers, invoice items, customers/vendors, posting configuration, tax where applicable. | Receipts, invoices, advances, payment posting, financial reports. |
| Payment gateway | Active Razorpay credential, key id, key secret, webhook secret, endpoint URL, currency, test/live mode. | Online payment link generation and webhook status updates. |
| Staff and permissions | User role, staff position, position mapping, and permissions such as manage-academy-assessments, manage-academy-fees, view-academy-reports. | Menu visibility, route access, ownership, notifications. |
| Lead statuses | Status tree, allowed transitions, final flags, and report stages such as ready_for_payment or converted. | Lead movement, reports, payment request automation. |
| Messaging/automation | Provider credentials, templates, automation rules, and logs where messaging is used. | Follow-up, notifications, payment communication, student updates. |
Setup principle: create the operational structure first, then run leads through it. Avoid enrolling or collecting fees against incomplete branch, batch, fee, account, or staff setup.
3. Roles and Access Areas
Access is controlled through permissions and Academy position middleware. The same user may see different menus depending on permission and staff position.
| Role / team | Main work | Typical modules |
|---|---|---|
| CRE / counsellor | Create or work assigned leads, call follow-up, notes, status movement, WhatsApp actions, assessment requests, onboarding support. | My LeadsAssessmentsOnboarding |
| Team lead / admin | Lead review, assignment, duplicate handling, escalation handling, QC follow-up, ready-for-payment oversight. | Lead ManagementQCEscalationsCRE Reports |
| Accounts | Payment gateway setup, payment request confirmation, invoice/receipt posting, fee reminders, exam fee support. | Payment RequestsPayment GatewayStudent FeesFee Reminders |
| HOD / Assistant HOD / Tutor | Assessment completion, syllabus review, mock tests, attendance, feedback, academic follow-up. | AssessmentsMonitoringAttendanceFeedback |
| Academic head / operations | Batch approvals, classroom/capacity decisions, complaints, transfers, escalations, reports, exam booking control. | BatchesTransfersComplaintsReports |
| HR / management | Staff control, complaint review, branch-level review, operational exceptions, and leadership reporting. | StaffComplaintsReports |
| Student | Can be created internally or through public registration link. Student profile is connected to user, lead, branch, batch, fees, attendance, and certificates. | RegistrationStudent Profile |
4. Lead Flow and Counselling Cases
Lead creation sources
- Manual lead: Admin or permitted users create a lead with name, phone, email, source, branch, section, subsection, course/interest, assigned staff, and notes.
- Self-added lead: Staff with add-lead permission can create their own lead from the self-add route.
- Facebook lead: Facebook credentials/forms can sync pending leads into the CRM, then staff review or assign them.
- Imported lead: Leads can be imported from template files and then processed like normal leads.
- Assigned lead: Admin, team lead, or permitted users assign leads to staff. Staff then work leads from the assigned-leads area.
- Admin review lead: Staff can transfer a lead to admin review when the lead needs confirmation, support, or management decision.
- Duplicate handling: Phone comparison uses normalized phone logic in several places, especially last-10-digit matching, so staff should avoid creating duplicate leads/students.
Status path
The configured Academy lead status tree starts at New Lead and branches through Not Connected, Connected, Interested, Conditional Interest, Follow-up, Future Lead, Call Back, Junk, Department Change, Ready for Payment, Payment Received, and Admission Taken cases.
| Case | How it works | CRM result |
|---|---|---|
| Not connected | Use busy, RNR, switched off, invalid number, or callback style status. Add follow-up date when action is still pending. | Status history and follow-up notification. |
| Connected but not ready | Use interested, conditional interest, demo requested, walk-in scheduled, hot/warm/cold follow-up, future lead, or not interested. | Lead remains in staff queue with status trail. |
| Needs admin help | Staff can request or transfer admin review for confirmed, problematic, or assistance-needed cases. | Lead stores transfer reason, notes, transferred user, and admin review flag. |
| Department change | Use department-change status or transfer handling when the enquiry belongs outside the normal Academy sales path. | Lead remains traceable and does not distort Academy conversion reporting. |
| Ready for payment | Lead status reaches the ready-for-payment report stage either manually or after assessment approval. | System can create a pending Academy payment request. |
| Partial/full/registration payment discussion | Use child statuses under ready for payment to describe the expected payment type before Accounts confirmation. | Sales and Accounts share context before receipt creation. |
| Admission taken | Accounts/student creation flow marks admission taken after payment confirmation or registration link completion. | Lead stores admission_taken, timestamp, user, and lead note. |
Rule: Staff should not treat a lead as converted just because a payment link was sent. Conversion is complete only when the student record and payment confirmation path are closed in CRM.
5. Payment Flow and Accounts Cases
Academy payment request creation
When a lead reaches ready-for-payment, the Academy payment request service checks the lead report stage and creates one pending request with a unique pending key for that lead. Accounts users and staff with account/academy fee permissions are notified.
Accounts pending queue
Accounts opens Academy Payment Requests, reviews lead details, checks matching students by lead, email, and normalized phone, then either confirms payment, rejects the request, or generates an online payment link.
| Payment case | Steps | Result |
|---|---|---|
| Offline payment confirmed | Enter received amount, payment date, mode, reference number, bank, student mode, batch, and Accounts notes. | Creates/links student, enrolls batch if selected, posts receipt, updates invoice or advance. |
| Existing student matched | Select existing student from matching or active list instead of creating a duplicate. | Payment request links to existing student and can enroll or post receipt. |
| New student needed | Accounts enters name, email, DOB, gender, phone, branch, address, optional student ID. | CRM creates user with role student and creates student profile tied to the lead. |
| Razorpay link | Accounts generates link using active Razorpay credential, amount, expiry, SMS/email notification options. | payment_gateway_links stores request payload, provider id, short URL, status, response, and lead note. |
| Webhook paid | Razorpay webhook verifies HMAC signature and updates payment link status to paid/cancelled/expired. | Link status and lead note update. Accounts should still confirm the CRM payment request for accounting closure. |
| Advance receipt | If no open invoice exists, receipt is recorded as advance with unused amount. | Money is captured in Accounts and can later be allocated/synced. |
| Invoice receipt | If an open invoice exists, receipt is applied against invoice balance. | Invoice status, balance, journal posting, and fee sync update. |
| Student fee collection | After admission, collect against enrollment fee rows from the student fee screen. | FeePayment and FeePaymentLedger track paid amount, discounts, method, reference, and notes. |
| Rejected payment request | Accounts enters rejection notes. | Request becomes rejected, pending key clears, lead note is added, assigned staff is notified. |
Accounting result
- If an invoice is found for the student/customer, the receipt is applied to the invoice and cannot exceed invoice balance.
- If no invoice is available, the receipt is stored as an advance with unused amount.
- Cash mode uses the cash account; other modes use primary active bank account or fallback account.
- The system posts invoice/payment accounting, recalculates account or bank balances, and syncs receipt back to Academy fee records.
- Gateway credentials are managed from Payment Gateways and include provider name/type, key ID, key secret, webhook secret, endpoint URL, currency, test mode, and active flag.
6. Student Creation, Registration, and Onboarding
Student creation paths
| Path | When used | Important behavior |
|---|---|---|
| Accounts payment confirmation | Best path when payment is the conversion trigger. | Creates/links student, can allocate batch, posts receipt, marks lead admission taken. |
| Students create form | Used by staff/admin to create a student directly or from converted lead. | Creates student user/profile and optionally allocates to batch; marks lead admission taken if lead id exists. |
| Public registration link | Used when student/family must fill profile details themselves. | Token stores branch, optional batch, optional lead, expiry, prefill data. Submission creates student and marks token used. |
| Existing student selection | Used for repeat admission, duplicate lead, or already-created profile. | Avoids duplicate student records and keeps payment linked to the right profile. |
Onboarding module
The Academy onboarding screen tracks students and onboarding tasks. It is used for admission follow-through, document collection, internal checklist updates, and ID card generation. ID card generation is blocked until required onboarding documents are complete.
- Student profile stores branch, lead id, student id, DOB, gender, phone, address, guardian details, photo, status, and notes.
- Student index shows latest enrollment and supports filters by branch, course, batch, and enrollment status.
- Prospective students are students without batch enrollment; active/completed/dropped/suspended/hold/upgraded depend on latest enrollment status.
Student record maintenance
- Edit student profile when branch, contact information, guardian details, address, status, photo, or notes need correction.
- Use transfer history to understand batch movement and avoid losing academic context.
- Delete student records only with care because related enrollments, fee payments, documents, and user account data can be removed by the controller flow.
7. Batch, Fee, Enrollment, Attendance, and Certificate Flow
Batch management
Batches belong to courses and branches and include code, dates, class time, active flag, capacity, fee settings, and approval controls. Batch approval/rejection and fee transaction configuration are handled from the batch module.
Fee setup
- Batch fees define due amounts attached to a batch. These fees later become student fee payment rows through enrollment/accounting sync.
- Fee payment reports can be viewed/exported from batch reports.
- Student fee collection supports normal fee rows, partial payments, discounts, custom fees, exclusion/re-inclusion of pending fees, and fee ledger history.
Enrollment and waitlist
Enrollment can happen from batch enrollment screens, student creation, public registration token, or Accounts payment confirmation. The Academy enrollment service handles active allocation and can waitlist when the batch is full if waitlist is allowed.
- Use batch enrollment screens for manual allocation, edit, show, and removal when staff directly manage batch membership.
- Use batch transfer flow when a student must move from one batch to another with proper history.
- Use classroom availability where classroom/capacity planning is required before opening or approving batches.
- Use tutor assignment when faculty/tutor ownership must be mapped to active batches.
Attendance and certificates
Tutors or permitted users mark attendance by batch. Reports can show attendance and absent students, and absence notifications can be sent. Certificates are created against course/batch/student, then approved, rejected, regenerated, downloaded, or viewed.
8. Academic Operations Cases
| Module | Purpose | Common statuses / outcomes |
|---|---|---|
| Assessments | Create assessment for a lead or student, assign assessor/faculty, record level/course recommendation and remarks. | Completed, approved, rejected. Approval can move lead to ready for payment and create payment request. |
| Academic monitoring | Track syllabus reviews and mock tests for enrolled students and batches. | Syllabus progress, review notes, mock test date/score/conductor, student academic tracking. |
| Backups | Academic backup monitoring for tutor/class continuity. | Backup owner, batch context, completion/follow-up tracking. |
| Feedback | Collect student feedback against batch/faculty/academic experience. | Feedback rows for review by tutor, HOD, assistant HOD, and academic head. |
| Exam bookings | Request and process exam registration/booking for students. | Assigned, student notified, approved, registered/completed, cancelled; can notify leadership and student. |
| Complaints | Track academic, faculty, payment, behaviour, and infrastructure complaints. | Open, assigned, in progress, resolved style operational tracking depending on controller updates. |
| Transfers | Transfer students/leads between batches, departments, or receiving teams. | Requested, accepted, rejected/handled; lead status may update when transfer is accepted. |
| Attendance | Mark attendance by batch, view attendance, report absentees, and send absence notifications. | Student attendance percentage and follow-up history are available for academic review. |
| Exam results | Create exam result records, enter batch/student scores, and review result history. | Academic performance evidence is stored against student and batch context. |
| Certificates | Create certificate requests, approve/reject, regenerate, view, and download certificates. | Completion evidence is managed after academic/course requirements are met. |
9. Quality Control, Escalations, and Governance
QC reviews
QC can create a review for a lead and update the review outcome. QC reports help leadership track lead quality, staff compliance, follow-up quality, and Academy pipeline control.
Sales escalations
Escalations track delayed responses, assignment concerns, or cases needing management attention. Statuses include open, acknowledged, and resolved. Resolution notes should explain the action taken.
Marketing upcoming batches
The marketing upcoming-batches page supports visibility into active/upcoming batch availability so lead follow-up and campaign messaging stay aligned with actual Academy capacity.
Notifications
The CRM creates system notifications for important handoffs: ready-for-payment to Accounts, payment confirmed/rejected to assigned staff, exam booking events, follow-up dates, and other workflow actions.
10. Communication and Follow-Up
Academy communication is split between staff activity notes, system notifications, messaging provider/template tools, WhatsApp actions, follow-up dates, absence notifications, payment links, and public registration links.
| Communication type | Trigger | Expected staff action |
|---|---|---|
| Lead note | Call, counselling update, admin review, payment link, payment rejection, admission taken. | Keep note short, factual, and action-oriented. |
| Follow-up notification | Lead status update with follow-up date. | Call or message on the date and update lead status again. |
| WhatsApp / template | Assigned lead communication or automation template. | Use approved content and keep CRM status aligned with real conversation. |
| Payment link | Accounts creates Razorpay link from pending payment request. | Share link, track link status, and confirm payment in CRM after verification. |
| Registration link | Staff generates public student registration token. | Send link to student/guardian and verify completion before onboarding closure. |
| Absence notification | Attendance module identifies absent students. | Notify student/guardian and add academic follow-up when required. |
| Exam/student notification | Exam booking approval, student notification, or registration completion. | Confirm student has received the instruction and update booking status. |
11. Important CRM Records Created Through the Flow
| Record | Created/updated when | Operational purpose |
|---|---|---|
| leads | Lead intake, assignment, status updates, admin review, admission taken. | Primary sales/enquiry record. |
| lead_status_histories | Every meaningful lead status move. | Audit trail for counselling and reporting. |
| lead_notes | Staff notes, system notes, payment link notes, rejection/admission notes. | Human-readable timeline. |
| academy_payment_requests | Lead reaches ready-for-payment report stage. | Accounts handoff and payment confirmation queue. |
| payment_gateway_credentials | Accounts/admin configures Razorpay. | Secure gateway setup for link generation and webhook verification. |
| payment_gateway_links | Razorpay payment link is generated or webhook updates status. | Online payment link audit trail. |
| users / students | Student is created manually, from payment confirmation, or public registration. | Student login/profile and Academy identity. |
| student_registration_tokens | Staff generates a public registration link. | Controlled self-registration with expiry and prefill data. |
| student_batch_enrollments | Student is allocated or transferred to a batch. | Batch membership, status, academic and fee connection. |
| fee_payments / fee_payment_ledgers | Fee dues are synced and payments/discounts are recorded. | Student-level fee balance and collection history. |
| invoices / payments | Accounts posts invoice and receipt or advance. | Financial accounting and receipt record. |
| assessments, QC, complaints, feedback, exams, transfers | Operational teams use Academy control modules. | Academic quality, student service, and management oversight. |
12. Reports and Monitoring
- Academy QC report: QC review trends, quality issues, and lead control follow-up.
- CRE report: Counsellor/CRE performance, lead movement, and sales pipeline visibility.
- Academic report: Academic monitoring, assessment, batch, faculty, and student delivery indicators.
- Screening and lead reports: Source-wise lead counts, staff performance, duplicates, Academy lead intake, and conversion-style metrics.
- Fee reports: Batch fee payments, student fee balances, pending reminders, invoice/receipt visibility, and account-side financial reports.
- Attendance reports: Batch attendance, absent student list, and notification follow-up.
13. Exception Handling
| Situation | Correct handling | Why it matters |
|---|---|---|
| Duplicate lead or student | Check normalized phone, email, existing lead id, and matching student candidates before creating a new profile. | Prevents split fee history and duplicate admissions. |
| Payment link generated but unpaid | Keep lead/payment request pending. Use awaiting payment or payment-link-sent status and follow up. | Sending link is not payment confirmation. |
| Razorpay webhook paid | Verify provider payment and complete Accounts confirmation in CRM. | Webhook only updates link status; CRM still needs receipt/accounting closure. |
| Accounts rejects request | Enter clear rejection notes and notify assigned staff for correction or re-qualification. | Gives staff an actionable reason instead of losing the lead. |
| Batch full | Allow waitlist when appropriate or select another batch after academic/operations confirmation. | Protects batch capacity and student expectations. |
| Invoice overpayment | Do not post more than invoice balance. Use advance handling only when no open invoice is attached. | Keeps account and fee ledgers accurate. |
| Complaint or transfer during active study | Create complaint/transfer entry, assign owner, update status, and add resolution notes. | Maintains operational audit trail. |
| Onboarding incomplete | Finish required onboarding checklist and documents before ID card generation. | Prevents incomplete student records from moving forward. |
14. Staff SOP Checklist
Before moving a lead to payment
- Confirm name, phone, email if available, branch, source, course/interest, and assigned staff.
- Add notes that explain discussion, fee amount, batch/course expectation, and next action.
- Check duplicates and existing student records.
- Use assessment approval when academic recommendation is required.
During payment confirmation
- Verify payment evidence, amount, date, mode, bank/reference, and payer/student identity.
- Select existing student when applicable; create a new student only when no existing profile matches.
- Select the correct batch when admission is tied to a batch.
- Confirm receipt and verify invoice/advance behavior.
After admission
- Check student profile, latest enrollment, fee dues, receipt, and lead admission-taken status.
- Complete onboarding tasks and documents.
- Track attendance, syllabus, mock tests, feedback, complaints, exams, transfers, and certificates as the student progresses.
At management review
- Review QC, CRE, academic, fee, attendance, transfer, complaint, and screening reports together.
- Check unresolved escalations, rejected payment requests, waitlisted students, overdue fees, and incomplete onboarding tasks.
- Correct setup issues before blaming staff performance: branch, batch, fee, account, permissions, and status setup all affect reports.