Education CRM
Admissions enquiries, counselling batches and follow-up in one pipeline.
- Modules
- 6
- Journey steps
- 4
- Integrations
- 4
- Indicative build
- 5–8 weeks
How to read this page: Concept specification: this page documents a system TECH360 can build. It is not a delivered client project, a verified case study, a working demonstration or a measured outcome.
B · Problem & target users
What this system is designed to replace
- Enquiries arrive from several channels and none share a queue.
- Follow-up depends on individual memory rather than an assigned owner.
- Management cannot see source, stage or response time from first-party data.
Target users
- Admissions counsellors
- Institution management
- Prospective students and guardians
C · Objectives & intended benefits
Design intent, not measured outcomes
- Give every enquiry one identity regardless of entry channel.
- Assign each enquiry a named counsellor and a due date.
- Report funnel stage and response timing from recorded events.
These are goals the build is designed to serve. No efficiency, revenue or conversion result is claimed.
D · Product overview
What the system is, and where it runs
An admissions CRM for coaching centres, institutes and training providers: capture enquiries from every channel, assign counsellors, track follow-up, and report on the funnel.
Counsellor workspace
Queue, record view and follow-up scheduling.
Management reporting
Read-only funnel and source breakdown.
Public enquiry form
Accessible capture form with consent and validation.
Platforms listed describe the intended build. A specific engagement may narrow or extend them after scope approval.
E · Module inventory
Modules in the specification
- Multi-channel enquiry capture
- Counsellor assignment and queue
- Follow-up scheduling and reminders
- Batch and seat allocation
- Guardian and student communication log
- Funnel and source reporting
Capabilities the system is designed to provide
- Issue one Client ID per enquiry regardless of entry channel
- Route new enquiries to a named counsellor with a due date
- Keep the full message history on the student record
- Report on source, stage and response timing from first-party data
F · Screen gallery
No verified product screenshots for this concept
This project has not been built, so there are no application screenshots to show. The image on this page is a generated concept visual, not a capture of working software. Presenting it as a product screenshot would misrepresent the system, so this section says so explicitly.
G · User journey
The intended path through the system
Step 1
Capture
An enquiry arrives from the website, phone note or messaging channel and is normalised into one record.
Step 2
Assign
Routing rules give the enquiry a counsellor and a first-response due date.
Step 3
Follow up
The counsellor logs each contact attempt; reminders fire on the agreed cadence.
Step 4
Convert or close
The enquiry moves to enrolled or closed with a recorded reason.
H · Roles & permissions
Who can do what
| Role | Access boundary |
|---|---|
| Counsellor | Own assigned enquiries and their communication log. |
| Admissions lead | All enquiries, routing rules and reassignment. |
| Management | Aggregate reporting; no personal contact editing. |
I · Architecture & API
Service boundary and HTTP surface
| Endpoint | Purpose |
|---|---|
| POST /api/enquiries | Capture a normalised enquiry with consent metadata. |
| PATCH /api/enquiries/:id/stage | Move stage with an audited actor and reason. |
| GET /api/reports/funnel | Stage and source counts for permitted roles. |
Endpoints are the intended contract. Authorisation is enforced server-side per role, never only in the interface.
J · Data entities
Core entities and relationships
| Entity | Relationship |
|---|---|
| Enquiry | Has many contact attempts; belongs to one counsellor. |
| Person | One student or guardian; may have many enquiries. |
| Batch | Has capacity; enrolments reference it. |
| ContactAttempt | Belongs to one enquiry; records channel, time and outcome. |
K · External integrations
Provider-dependent integration points
- Website enquiry form
- WhatsApp / SMS
- Google Sheets or CSV export
- Website form
- Messaging provider
- CSV export
Each integration is configured and accepted against the specific provider account before go-live.
L · AI & automation
Opportunities and their human gate
Classify enquiry intent and language to route it to the right counsellor.
Human gate: Admissions lead reviews routing rules; misroutes are reassignable.
Draft a first reply from approved templates.
Human gate: Counsellor sends every message; drafts are never auto-sent.
M · Security, privacy & accessibility
Controls the build is specified to enforce
- Guardian and student contact data is visible only to assigned roles.
- Every stage change records actor, timestamp and reason.
- Exports are limited to permitted roles and logged.
Accessibility is treated as an acceptance criterion for keyboard, focus and contrast on every screen. No certification or audit result is implied.
N · Testing & quality assurance
What would have to be proven before handover
- Routing rules covered by table-driven tests.
- Duplicate-enquiry merging tested against identity collisions.
- Form validated for missing, malformed and duplicate submissions.
O · Deployment & hosting
Where and how it would run
- Containerised application
- Managed relational database
- Nightly backup with restore drill
P · Maintenance & scalability
Keeping it maintainable
- Routing rules are configuration, not code
- Reporting queries are indexed for growing enquiry volume
- Retention policy per institution
Q · Optional advanced features
Out of the initial scope, available later
- Guardian portal for application status
- Automated document checklist
- Multi-campus reporting
R · Related
Related solutions and next step
Sector blueprint: Education solutions
What this page does not claim: No enrolment or response-time improvement is claimed. Messaging providers must be configured and accepted before go-live.
Claims policy: this page is checked against a forbidden-claim list (6 patterns, including invented percentage results, “case study” and guarantee language) by the repository test suite.