CRM & lead pipeline.

By the time a child appears in the student records module they are already enrolled — the decision is made, the student number issued, the family linked. The admissions CRM is everything that happens before that moment: the conversation, the application form, the documents chased, the entry exam sat, the interview held, the offer extended, the seat accepted.

In YESS that whole journey lives in one place — /dashboard/admissions — as a pipeline of admission_applications, each one sitting at exactly one stage. Move an application forward and the family advances through the funnel; a KPI strip at the top of the page always shows the live shape of the pipeline — total, active, conversion rate, rejected — regardless of how the table beneath it is filtered, and a second clickable strip breaks the pipeline down stage-by-stage so a tile becomes a filter.

An admission application carries the applicant's details, the parent or guardian who enquired, the programme, class and campus applied to, a target academic year, a source, an auto-numbered application_number, and a current stage. The stage is the heart of the record — it is what the funnel chart counts and what the pipeline board sorts by. The path runs through seven stages in order:

Two more values sit off the main path as honest off-ramps: rejected (the file did not pass) and waitlisted (a yes, but no seat yet) — so the current_stage column holds nine values in all. The two consequential moves are guarded: a move to rejected opens a confirmation that requires a written reason, and a move to enrolled never flips from a dropdown at all — it routes the registrar to the applicant's file to run the explicit Convert to Student action. Every other stage change flips immediately, and each one writes an audit row to application_stages.

The board can be filtered by stage and by source — a row of bulk checkboxes lets you advance several files at once (the bulk dialog still blocks enrolled and still asks for a rejection reason). The source filter is the first, simplest version of the marketing attribution the roadmap will deepen: it sorts the pipeline into self-applied families and ones an officer captured internally.

The source on every application is one of four values, and each is a real door into the pipeline: walk_in, online_self, batch_offline_synced, and imported.

The first door is the walk-in wizard at /dashboard/admissions/walk-in — a single-screen capture flow for the front-office officer when a parent walks through the gate. It discloses three sections in turn: a sibling lookup, the applicant and parent identity, then the placement (programme, class, and campus). Submitting creates one application stamped source = walk_in and drops it into the normal stage flow — the wizard never short-circuits review, interview, or offer.

The sibling lookup is the quiet win. Type a family name and matching active students surface (a live search across student first and last names); “adopt sibling” copies that student's surname and campus into the draft, so the officer attaches to a family the school already banks, bills, and messages instead of duplicating it.

The second door is online self-submission: a family who has never had a YESS account fills in the public application form at /sites/[school]/apply — also embeddable in the school's own website — and lands directly in the pipeline, stamped online_self, self-submitted, at the applied stage. The remaining two doors are operational: a mobile officer capturing enquiries with no signal, whose drafts upload later as batch_offline_synced, and a bulk imported intake. The general New Application dialog on the pipeline page is how an officer types an enquiry that arrived by phone or email — it has no separate source field, so it records under the default source.

Many schools assess before they admit. Entry exams live at /dashboard/admissions/entry-exams — a permission area of its own. You define an exam for a programme and intake year (with a pass threshold, a capacity, fee details, paper and/or online modes, and blind grading on by default), publish it, then register candidates — each optionally linked back to an application. Scores are recorded against the candidate, and the roster carries Admit / Waitlist / Reject outcome controls, so the committee weighs a number and a rank, not a hunch.

An individual applicant's full file opens at /dashboard/admissions/[id] — not a row of tabs but a set of rooms: Overview (applicant, parent, academic and registration-fee detail), Documents, Interviews, Offers, Entry exams (when a candidacy exists), Notes, Outbound messages, and a History timeline of every stage change. A stage pipeline and a “time in stage” chip sit across the top.

When the committee reaches a verdict, the application moves to decision, and the school extends an offer from the Offers room — full, conditional, or waitlist. From there the family resolves to one of three outcomes: enrolled, rejected, or waitlisted. Because a rejection ends the family's lifecycle, YESS gates it behind a confirmation that asks for a reason — so the audit trail explains not just what changed but why.

A strong applicant with no seat is not a no — it is a waitlist. Waitlisting is a stage plus an ordered waitlist_position: the Waitlist tab on the pipeline page holds these families in priority order, and the registrar reorders them — up, down, to the top, to the bottom — so that when a place opens the next candidate is already chosen, without re-reading the whole pipeline.

The funnel ends where the student journey begins. From the applicant's file, Convert to Student runs a single server-side transaction (convert_applicant_to_student): it creates the students row — its student number derived from the application number, with an admission_application_id back-reference to the file it came from — links the parent, opens an active enrolment, and stamps the application enrolled. If the school charges a registration fee and it is unpaid, the conversion is blocked until it is settled. Downstream of the conversion the student picks up a programme matricule and the first invoice follows from the assigned fee structure — no re-keying of anything the family already gave you.

The Analytics tab turns the pipeline into intelligence: an application funnel, a monthly-trend line, and a stage-distribution chart, over headline cards for total, enrolled, rejected, and conversion rate. It is the single most useful screen at the start of an intake season — and the clearest read on where families drop off between one stage and the next.

The features below are the classic-CRM layer that sits on top of a pipeline. They are planned, not shipped — listed here so you can plan around them honestly. The Notes and Outbound rooms on each applicant's file are the shipped building blocks the communication features will grow from.

The pipeline is the front door of the school. Everything it feeds downstream begins the moment an application is converted into an enrolment.