Background
A Pearl River Delta training group (HQ in Guangzhou, plus nearby campuses) relied on spreadsheets and chat for scheduling, enrollments, and attendance. They needed a permissioned academic admin system. Changsha Moore Information Technology Co., Ltd. delivered discovery, prototypes, build, and acceptance remotely under our web admin system development offering.
Phase 1 goal: get scheduling and front-desk staff using one system daily with trustworthy numbers — not shipping every training-SaaS feature at once.
This case shows we do not only serve Changsha: out-of-province clients can ship in phases when the main workflow is clear and online reviews are possible.
Pain points
- Classroom conflicts discovered too late across campuses
- Enrollment/renewal data scattered; finance vs academic reconciliation painful
- Campus managers lacked live local views; HQ roll-ups lagged
- No clean path to a parent query app or mini program later
Feature list (phase 1)
- Courses, classes, room/time resources with conflict hints
- Enrollment orders, student records, basic renewals
- Attendance plus campus-scoped permissions
- Weekly/reconciliation exports and API hooks for later channels
- Optional reminders for class starts / pending enrollments
UI sketch
Sketch: multi-campus scheduling in one admin (not a confidential client screenshot)
Timeline & outcomes (indicative)
About 10–14 weeks for a first production release: discovery/prototype → build → import sampling → trial cutover. See the admin system project timeline.
Indicative ranges from similar projects; acceptance data wins.
Implementation steps
- Unify course/class/room/permission models; write an explicit out-of-scope list.
- Ship scheduling + enrollment + basic reconciliation before heavy reports.
- Agree required fields and de-dupe rules, then import history with sampling checks.
- Train academic/front-desk staff; trial one campus before full cutover.
- After stability, evaluate payments, teacher mobile, or parent query as phase 2.
Roles
- Academic ops: schedule, reschedule, resource conflicts
- Front desk / sales: enrollments and student basics
- Campus lead: campus-only operational view
- HQ: cross-campus roll-up and permission audit
- (Optional phase 2) teacher mobile / parent query
Data & integration notes
- Define required fields, phone de-dupe, and void-order handling before imports.
- If payment channels already exist, decide phase-1 integration vs manual posting early.
- Keep parent query out of phase 1 to protect the go-live date.
- Scope permissions by campus + role to prevent cross-campus edits.
Acceptance examples
- One campus runs a real week of scheduling/enrollment without blockers
- Export samples match finance checks at the agreed sample rate
- Campus accounts cannot see other campuses’ sensitive data
- Ops guide covers open class, reschedule, enroll, attendance
FAQ
Payment gateway integration?
Yes when scoped in discovery — channels, reconciliation fields, refunds. Or record manually in phase 1 and integrate later.
Do teachers need a native app in phase 1?
Often mobile web is enough for attendance/schedules; native/mini programs after usage stabilizes — requirement change control.
How are multi-campus permissions handled?
Campus isolation by default; HQ roles can roll up. Granularity is confirmed in prototyping.
Messy historical data?
Clean a sample first, then full import with rules for unmatched rows — don’t “import then fix forever.”
software project cases · contact for software projects