Where do school admissions teams usually get stuck in a generic CRM?
A generic CRM pipeline assumes a buyer: a company, a deal size, a close date. Admissions has none of those. One application involves a child, one or two guardians, a year group with limited places, and a sequence of evidence — birth certificate, previous school report, interview notes — that arrives in no particular order. When teams force this into a standard sales pipeline, two things break. First, the stages lie: an application sits in “Documents” for weeks, but nobody can tell whether the school is waiting on the family or the family is waiting on the school. Second, the data sprawls: staff start pasting sensitive details about the child into free-text notes because the form has no proper place for them, and now personal data lives in a field nobody audits.
Our illustrative school is a mid-sized independent school running one intake a year, roughly a few hundred applications. The admissions team is small — an admissions officer, a registrar, and the head of school who approves offers. They want Odoo CRM to hold the pipeline, with the office team handling documents and the leadership team seeing status without touching individual records more than necessary.
Start with stages that describe decisions, not paperwork
Configure the CRM pipeline first, before any custom fields. A workable stage set for admissions looks like this: Enquiry → Application Started → Documents Pending → Documents Complete → Interview Scheduled → Interview Done → Offer Made → Enrolled (or Declined / Waitlisted). Each stage answers one question: what is the next decision, and who makes it? “Documents Pending” versus “Documents Complete” is the split that fixes the first problem above — it makes the waiting visible, because an application only moves forward when the documents checklist is complete.
Two configuration habits matter here. Use stage-specific requirements sparingly: Odoo lets a stage imply required information, and it is tempting to block movement until everything is filled in. In admissions, blocked stages create shadow spreadsheets. Prefer soft signals — a red/amber indicator on the kanban card when a document is missing — over hard blocks. And set up lost reasons that mean something in this context: “Family chose another school,” “Place not available in year group,” “Documents never completed.” Those reasons are your admissions analytics a year from now.
Which fields do you actually need for guardian contact and application status?
This is where Pilot Studio earns its place — a reviewed, limited set of fields on the lead, proposed as a change you can inspect before it lands. Keep the list short and justify every field by a decision it feeds:
- Guardian name, relationship, phone, email. The applicant is a child; the contact is the guardian. Model the guardian as the contact on the lead and keep a second-guardian block optional — not mandatory — because family shapes vary.
- Year group applied for and intake year. Two fields, enormous operational value: every capacity conversation depends on them, and they drive the waitlist logic.
- Document status. One field per required document (birth certificate, previous report, proof of address) with a simple status — not received, received, verified. Resist attaching the documents themselves to the lead at this stage; status is what the pipeline needs.
- Interview date and outcome. A date field and a small selection (proceed, hold, decline). Keep interview notes in the chatter/activity log, not in a giant text field.
- Application status summary. A computed or carefully maintained selection that mirrors the stage, used for reporting to leadership without opening individual records.
Notice what is absent: no field for medical details, no field for behavioural notes, no free-text “about the child” box. If the school genuinely needs safeguarding or learning-support information, it belongs in a separate, access-controlled process after an offer — designed with the school’s data-protection responsibilities in mind, not bolted onto a sales pipeline.
Before and after: what the admissions screen should look like
The before state is the default CRM form: company fields that make no sense for a family, a revenue field nobody uses, and the guardian’s phone number buried in a notes tab. Staff work around it, which is how data ends up in the wrong places. The after state, built from the fields above, is a form ordered the way an admissions officer actually works a case:
- Top block: applicant name, year group, intake year, stage — the identity of the case at a glance.
- Guardian block: primary guardian contact details, second guardian collapsed and optional.
- Documents block: the three document statuses as compact selections, so a missing item is visible without opening attachments.
- Interview block: date, interviewer, outcome.
- Collapsed by default: source of enquiry (open day, referral, website) for marketing reporting — useful monthly, noise daily.
Views deserve the same treatment as fields. The kanban card should show year group and document status, not an expected-revenue figure. The list view the registrar uses for the weekly documents chase is different from the pivot the head of school uses for intake numbers — build both, name them for their audience, and stop expecting one view to serve everyone.
Who should see what? A permissions matrix
Admissions data is personal data about minors, so “everyone in the CRM can see everything” is not an acceptable default. A sensible starting matrix, implemented with Odoo groups and record rules, looks like this:
| Role | Pipeline stages | Guardian contact details | Document status | Interview outcome | Reports |
|---|---|---|---|---|---|
| Admissions officer | Read / write | Read / write | Read / write | Read / write | Team pipeline |
| Registrar / office staff | Read | Read | Read / write | No access | Documents chase list |
| Head of school | Read | Read | Read | Read | Intake summary |
| Interviewer (teacher) | Own interviews only | Read (own interviews) | No access | Write (own) | None |
| Marketing user | Aggregated only | No access | No access | No access | Source-of-enquiry stats |
Two principles behind the matrix: interviewers see only the applications they interview, and marketing sees counts, never children. Test the matrix with real logins before go-live — permissions that are designed but never tested have a way of being wider than intended.
Where do approvals fit?
The one true approval in admissions is the offer. Model it as a stage transition with a rule attached: only the head of school (or a named delegate) can move an application into Offer Made, and the move requires the interview outcome to be recorded. In configuration terms that is an automated action plus a group restriction on the stage — Pilot Studio can propose the field and view changes, and the approval rule itself is a small, reviewable configuration step. The same pattern covers waitlist promotion: when a place frees up, the next waitlisted application in that year group gets flagged for the admissions officer rather than being promoted silently.
Frequently asked questions
Should the child be a contact in Odoo?
Generally no, not during admissions. The guardian is the contact you communicate with; the child’s details live on the application itself. Creating full contact records for every applicant child creates a database of minors that persists long after unsuccessful applications should have been cleared.
How long should we keep unsuccessful applications?
Decide a retention rule before go-live — for example, deleting or anonymising unsuccessful applications after the intake cycle closes — and assign an owner to it. This is a policy decision for the school, not a software default; the system should support the rule, not invent it.
Can siblings and repeat applications be handled?
Yes, at the guardian level: one guardian contact can carry several applications across years. That is another reason to model the guardian as the contact and the application as the lead, rather than duplicating everything per child.
Do we need a custom module for any of this?
For the design above, no. Stages, a limited field set, views, and group-based rules are configuration plus Studio-level changes. A module enters the picture only for genuinely bespoke logic, such as automated capacity checks across year groups — and even that deserves a scoping conversation first.
Next step
Start by previewing the change before it touches your live database: the fields, the form order, and the stage set can all be drafted and reviewed as one proposed customization. Preview your admissions-screen customization in Pilot Studio and argue about the field list while it is still cheap to change — that argument, held early, is what keeps children’s data minimal and the pipeline honest.
