Multi campus admissions CRM software should track one prospective student across enquiries, campus choices, applications, offers and enrolment without confusing duplicate contacts with separate applications. Buyers should test routing, counsellor ownership, seat commitments and fee-linked handoffs to the student system. A lead dashboard alone cannot prove that an admission was completed correctly.
Prepared by Dork Industry. The examples and thresholds are illustrative evaluation recommendations, not client results or a regulatory certification.
What business problem makes this investment worthwhile?
An education group can receive more enquiries while losing visibility into who owns the next action. A family may enquire at two campuses, submit an application at one and accept an offer at another. If each campus keeps a separate spreadsheet, management can double-count demand, counsellors can repeat calls, and seats can be promised without a shared record. This is an enterprise CRM and student-system integration problem for admissions directors, campus heads and IT leaders.
For an illustrative group operating campuses in Rohini and Dwarka, a family’s preferred campus may change after a visit or transport discussion. A transfer should retain consent records, source attribution, application history and accountable owner while applying the receiving campus’s actual programme and seat rules. No locality-specific admissions rule is assumed here.
According to Frappe Education’s official Student Applicant documentation, applicant records support the admission process and enrolment workflow. Separately, Cyborg’s published education CRM description connects lead and application data to admission, fee and student-information workflows. These source examples support the boundary between CRM and student systems; they do not prove Dork has implemented that particular product or achieved its advertised outcomes.
Which multi campus admissions CRM software requirements matter?
How should data model work?
Separate person, family contact, enquiry, application, programme, intake, campus, offer and student. Decide which fields may be shared and which belong to one application.
How should ownership transitions work?
Every stage needs a responsible role, next action and due time. Transfers should be accepted, rejected or escalated explicitly.
How should capacity rules work?
Define whether an offer reserves a seat, when it expires and how cancellations restore availability. Confirm campus and programme restrictions with the institution.
How should erp contract work?
Agree how approved applications create student records and how payment, documents and programme identifiers are mapped. Failed handoffs require owned exceptions.
For each stage, record the source identifier, responsible role, allowed action, previous state, new state and failure route. Dork Industry’s ERP and enterprise integration services can be scoped around these boundaries. A mobile workflow may be useful when staff act away from a desk; its role should be justified by the actual process.
Which eight tests should the buyer run?
Run the demonstration with authorised anonymised records and a written expected outcome. Include normal transactions and deliberately difficult exceptions. Save the actual outcome, evidence reference, owner and severity before deciding whether a test passed. A polished dashboard cannot substitute for this evidence.
- Identity versus application: Submit enquiries for one person across two channels and two programmes. Preserve one person where justified and separate legitimate applications.
- Shared family contact: Use one parent phone number for two children. The system must not merge the children merely because contact information matches.
- Campus transfer: Move an application to another campus. Retain history and obtain acknowledgement from the receiving owner before the previous owner closes the task.
- Seat commitment: Issue concurrent offers for the last available seat. Apply the documented hold, expiry and acceptance rules without creating two confirmed commitments.
- Fee-linked handoff: Confirm the required payment status before converting the application to a student record. A browser success page alone should not determine enrolment.
- Cancellation and re-entry: Cancel an offer, release its seat according to policy and reopen a new application without deleting the original history.
- Duplicate event: Replay an accepted-offer or payment notification. There should be one enrolment effect and one linked student identity.
- Attribution and export: Trace an enrolled student back to the originating enquiry and approved campaign attribution. Export the connected records without losing campus and application identifiers.
How should the worksheet be used?
Illustrative counting example: 40 enquiries represent 30 distinct prospective students, 36 programme applications and 12 confirmed enrolments. Enquiry-to-enrolment conversion is 12 divided by 40, or 30%. Distinct-person-to-enrolment conversion is 12 divided by 30, or 40%. Both calculations are correct for their stated denominator; combining them would mislead campus comparisons. These are fictional worksheet values, not institution results.
| Worksheet field | What to record | Decision supported |
|---|---|---|
| Scenario | Identifier, starting state and input | Can another reviewer reproduce it? |
| Expected outcome | Approved rule and required evidence | What does passing mean? |
| Actual outcome | Observed state, amounts and linked records | Did the system implement the rule? |
| Exception | Severity, owner, next action and due date | What prevents rollout? |
| Re-test | Corrected version and new evidence | Was the failure actually resolved? |
For a pilot, select at least 24 representative scenarios across three operational roles, including eight exception cases. Require 100% traceability for the tested transactions, zero duplicate business effects after replay and an assigned owner for every failed integration. These are proposed acceptance thresholds. The organisation must adapt them to its risk, volume and operating policy before contracting.
How should implementation and measurement work?
- Agree the rule before the screen. Have operations and finance approve the state model and definitions.
- Assign ownership. Identify the authoritative system for every shared record and who resolves a mismatch.
- Reconcile migration. Count imported records and validate identifiers, balances and statuses against signed-off source data.
- Test recovery. Simulate missing, duplicated and out-of-order events, then prove safe replay.
- Pilot a complete journey. Include the downstream financial or enrolment outcome rather than stopping at data capture.
- Expand after evidence review. Close critical failures, train the affected roles and retain a rollback and reconciliation plan.
Measure exception age, manual touches, correction reasons and transaction reconciliation before and after rollout. Use your own measured baseline; do not treat proposed thresholds as proven gains. A useful business case separates software investment, integration work, migration, training, ongoing support and the cost of the current manual process.
For broader context, read Dork Industry’s school fee reconciliation tests, and customer follow-up workflow guide. This article focuses on a narrower buying decision, while the industry software overview connects that decision to wider operational requirements.
Frequently asked questions
Is one enquiry the same as one application?
No. A person can enquire through several channels and apply to several programmes or campuses. The CRM should retain the relationship between those records and use a declared denominator when calculating conversion.
Should matching phone numbers be merged automatically?
Not always. Parents or guardians may share a number across multiple children. Matching rules should consider institution-approved identifiers and route ambiguous cases to review rather than deleting distinct student identities.
What should happen when a student changes campus?
The receiving campus should acknowledge ownership and apply its programme rules. The application history, source attribution and relevant permissions should remain traceable, and the previous campus should not continue conflicting follow-ups.
Can admissions CRM replace a school ERP?
Usually it covers a different part of the journey. CRM manages enquiries and applications; the student or ERP system manages enrolled students and ongoing operations. Buyers should test the handoff instead of assuming either product automatically covers both.
