When the Institute Stopped Living in Spreadsheets and Inbox Roulette
How we helped a national business-education institute run multi-city workshops, long cohorts, and tiered CRM on one portal—registration, GST-aware payments, homework, and support—without ops and finance reading two different truths.
The problem: Meet Rahul Jain, founder-director of an institute that has trained thousands of business owners across manufacturing, services, retail, and more— running everything from single-day open sessions in multiple metros to multi-day intensives and long-form programmes. The methodology was sharp in the hall; on paper it fractured into rosters, ad-hoc homework threads, and finance exports. Teaching IP lived in facilitator heads and slide decks while “the system” only knew payments. The worst Monday wasn’t a server outage—it was two cities with different seat counts for the same programme week, and coaches unsure which cohort was on which module.
The ops metrics that kept leadership awake:
“We weren’t short on curriculum,” Rahul says. “We were short on one spine where how we teach and how we run the business pointed at the same cohort.” The breaking point was a packed month: barcodes at the hall didn’t match the roster finance had closed on, while coaches couldn’t see whether homework for that week was even released—and GST lines waited on someone’s export.
The mandate was a single portal that treats each programme as a product: modules, sessions, assignments, and coach touchpoints are first-class—not bolted on after CRM and payments. Institute staff, tiered CRM, and participants all read the same progression; bulk tools and finance sit on that backbone so month-end isn’t export gymnastics.
What we built
Teaching design → programme objects: the same arc in the database
- Programmes modelled as sequences: intakes, modules, session dates—so “what we teach this week” isn’t a side spreadsheet
- Materials and homework tied to the programme journey; attendance and barcodes attach to the same session record
- One-day city events and long cohorts share one pattern: cohort → roster → where the class is in the methodology
CRM & coaching ops: Rahul-style delivery at scale
- Batch-scoped CRM so each coach sees their owners’ progress against the programme—not a generic contact list
- Homework submissions, video approvals, and coach messaging in one thread aligned to the batch
- Helpdesk when alumni and referrals spike—without breaking the teaching workflow
Participants: pay, then learn in the same product
- Dashboard where class lists, materials, and homework reflect what coaches released—same truth as ops
- Registration and GST-aware payments that unlock the right modules—commerce matches pedagogy
- Public city landing and pay links that feed the same roster the classroom runs on
Finance: collections, access, and refunds the board can audit
- Overdues, partials, and refunds with trails finance can defend—not screenshots
- Content access gated on payment status so delivery and revenue stay aligned
- Bank and company masters centralised for disbursements and month-end
Platform at a glance
We treated Rahul’s teaching stack as the product: courses, batches, homework queues, and coach scopes are data the UI routes on—not an afterthought to billing. SuperAdmin, CRM tiers, and participant apps sit on one guarded route matrix so nobody teaches from a different roster than finance.
Peak intake means dense grids and bulk CSV when a city drops hundreds of names; day-to-day means an owner pays an instalment or submits homework from phone—same backbone.
Session-backed admin; uploads for attendance, rosters, and partials with visible progress—ops owns release week; coaches aren’t blocked on engineering for every module drop.
Who the product serves
Menu trees follow who does what in Rahul’s delivery model: admins own programme structure and money; coaches own their batch’s progression and homework; participants see learn, pay, and help—without everyone staring at one overloaded dashboard.
Programme office
- Module/session structure per programme
- Multi-city calendar, barcodes, exports
CRM & coaches
- Batch-scoped: who’s on which module
- Homework, video queues, coach messaging
Participants
- Dashboard, classes, homework
- Payments, GST-aware receipts, terms
Access & revenue
- Content access vs payment status
- Overdues and partial pipelines
Alumni & referrals
- Structured follow-ups post-programme
- Tickets when volume spikes
Finance hooks
- Bank and company masters
- Refunds and invoice tooling
Data onboarding
- CSV for attendance and cohorts
- Bulk workshop updates
Public touchpoints
- City workshop registration
- Register-and-pay journeys
How we rolled out without freezing admissions
Delivery sequenced authentication shells and cohort flows before workshop barcodes and payment exceptions—so the institute could run real batches while edge modules caught up.
Map teaching journeys to routes first
We aligned programme → batch → module/session flows with how coaches actually deliver—then wired SuperAdmin, CRM, and participant journeys to one router. Pedagogy-shaped navigation beats a pile of one-off admin screens.
Ship slices the institute could run
Cohort and calendar flows landed before edge cases: bulk CSV, workshop barcodes, and payment exceptions shipped as explicit slices—not a single big bang that froze admissions.
- Shared list/detail patterns for batches, workshops, and participants
- CRM messaging and tickets parallel to student-facing help
- Protected layouts so authenticated subtrees fail closed
Stabilise operations and hand over the runbook
Load on representative cohort sizes, finance reconciliation dry runs, and CSV recovery playbooks—so ops owned release day instead of engineering owning every Monday.
Same teaching DNA for a one-day room or a nine-month cohort
Rahul’s formats differ in length, not in kind: there is always a programme, a cohort, a sequence of touchpoints, and homework that proves application. The portal reuses one pattern—lists, detail, homework, payments—so ops doesn’t run one playbook for “events” and another for “long programmes.” Teaching stays the product; the ERP is how the institute runs it at scale.
Institute operations
- Course and batch administration with attendance tooling
- Workshop lifecycle including barcodes and participant exports
- Calendar as the shared schedule of record
Participants & CRM
- Student dashboard with homework and class lists
- CRM-scoped messaging, homework, and video queues
- Tickets and help paths aligned to institute SLAs
Use cases: enrolment, delivery, and cash in sync
These patterns describe how information moves between programme staff, CRM, and finance—without the same cohort being typed twice.
Enrolment: programme design → batch → who’s in the room
- Course setup encodes the teaching arc; batches attach dates, city, and coach
- Rosters and attendance reflect the same programme object finance bills against
- Imports at scale without forking the methodology to a second sheet
Revenue: schedule → collect → reconcile
- Payment detail and overdue views for finance alignment
- Partial payments and refunds with audit-friendly trails
- Access gating tied to approval—not informal email unlocks
Delivery: session → materials → homework the coach can see
- Materials and assignments released in step with the programme—not a separate email chain
- Participant view and CRM view share homework status; video queues moderated before go-live
- Calendar shows what the cohort is doing this week; same field coaches and ops trust
Outcomes: calmer ops and defensible numbers
What the institute stopped duct-taping
- Teaching progression and money in one place—homework and modules aren’t divorced from billing
- Barcode and attendance exports that match the programme record coaches actually ran
- Fewer debates over which cohort was on which week of the methodology
What finance and access agreed on
- Overdue and access-payment flows visible to authorised roles
- Refund tooling that reduced back-and-forth outside the system
- Less emergency reconciliation after every intake weekend
What leadership measured
- Time to reconcile a batch after CSV import
- Ticket volume deflected by structured homework and messaging
- Release confidence: fewer hotfixes the week after go-live
Where to read more
For ERP positioning on education and training operations, see ERP for education & training companies. All case studies are listed on case studies.
Training operations portal — questions this case study answers
The portal is built so programme structure—modules, sessions, materials, homework, and coach visibility—is as much a first-class object as payments and rosters. Commerce (registration, GST, instalments) unlocks and tracks against that same teaching spine, so “what the owner paid for” and “what the cohort is doing this week” stay aligned.
City and batch dimensions sit on the same cohort model: each workshop or programme run gets dates, venue, capacity, and pricing—while participant identity and payment history stay unified. Bulk CSV and barcode flows attach to the specific event, so Delhi and another metro never maintain two “official” spreadsheets for the same programme week.
One codebase with role-based routing and menus reduces duplicate logic and keeps cohort data consistent. Staff and participants see different subtrees, but share the same design system, auth boundary, and API patterns—so fixes and features ship once.
Bulk paths are explicit screens with validation and feedback—used when scale beats manual entry—while daily work stays in searchable lists and detail views. Barcode and QR flows for workshops sit on the same participant records as the rest of the programme.
Institute-wide CRM admin, batch-scoped CRM, and participant-facing tickets and messages share patterns but different scopes—so coaches see only their cohorts while leadership retains oversight and helpdesk routing remains structured.
Payment status, overdue lists, and access approval queues are first-class surfaces so content unlocks and financial truth align—reducing informal overrides outside the system.
The portal operationalises training delivery, CRM, and participant experience. General ledger and deep ERP may still integrate with finance stacks; this case study focuses on the operational and participant layer we shipped in the browser.
MUI and React Router gave a stable foundation for hundreds of screens; disciplined list/detail patterns and protected layouts kept new modules from becoming one-off pages. Rich text and file upload were used only where the workflow required them.