Five fields on every enquiry
- Course of interest
- Intake
- Parent / guardian
- Parent phone
- Previous qualification
The two parent fields are text on the enquiry rather than a second person record, which is worth knowing before you plan around it.
Every enquiry with a counsellor against it, every callback with a date, and the fees on a schedule that raises its own instalments. The admissions app renames the most of the four: your navigation reads Enquiries, Students and Fee receipts.
No per-counsellor fee, unlimited users, self-hosted. The app installs from Settings, Apps, in a click.
One record the whole way. The person who walked in is the student on the admission and the family on the fee receipt, rather than three rows in three registers.
A walk-in, a phone call, a referral, a campaign or the form on your own website lands as an enquiry with its source recorded against it, and the list filters by that source.
Assign it to a counsellor, who sees the enquiries assigned to them or that they created rather than the whole institute. The rule is enforced in the API.
Book the callback as a task with an owner and a due date, in a list, on a board or on a calendar. You go to it: nothing chases you.
Record what was discussed on the enquiry, capture the course of interest, the intake and the parent, and move its status along. In the hosted app a counselling session or demo class is its own record, on a board by status.
Convert the enquiry and it creates the institute record, the student as a contact and the admission itself in one action, with the enquiry marked converted. In the hosted app the application to a batch records the decision, and admitting the student takes a seat.
Raise the fee receipt, record part payments as they come in, and put the balance on a monthly or quarterly schedule that raises the next instalment overnight.
The admissions app is a file in the repository, so this list is exactly what you get. Every item is an ordinary record you can rename, reprice or delete afterwards.
The two parent fields are text on the enquiry rather than a second person record, which is worth knowing before you plan around it.
Enough to tell a walk-in from a referral and a scholarship case from a returning family, without inventing a taxonomy in week one.
Test prep, bootcamps, professional papers, a language batch and the registration fee, each with a code and a price. Change them to your prospectus before you quote one.
Optionally the app also seeds sample enquiries, students and fee receipts so you can see the shape of it. Every seeded row is tagged, so you can delete the lot in one action when you are done.
Each one is checked against the source rather than written from a feature list, and where a capability is on one client and not the other, it says so. The next section is the other half of that promise.
This app renames the most of the four, and your navigation reads your words rather than a vendor’s. The Enquiries pages carry the word throughout. Other page headings keep the stock label, and the phone app does not read the map, so it still says Leads.
Course of interest, intake, parent or guardian, parent phone and previous qualification, on every enquiry. They render on the web form and the phone form, filter in list views, and come back through the API.
Walk-in, referral, campaign or existing family, recorded against the enquiry and filterable on the list, so you can see where a season’s admissions actually came from.
Not the whole institute. A counsellor works the enquiries assigned to them or that they created, administrators see everything, and the rule lives in the API rather than in the interface.
An Outcomes page beside the enquiries counts, for each counsellor over the last 7, 30 or 90 days, the enquiries admitted and lost, the win rate, the median time from enquiry to admission and the new enquiries. A counsellor sees their own row; administrators see everyone and a total. It counts from the day your institute started recording outcomes, on the web app.
A follow-up is a task on the enquiry, in a list sorted by what is owed, on a board, or on a calendar. The same task in all three views.
In the hosted app, the admissions app adds a Course and a Batch record: dates, schedule, mode, location and seats, on a board by status. Admitting a student takes a seat, an open batch turns Full when none are left, and a freed seat tells the counsellors who have someone waitlisted. Free on every plan, and it uses none of your plan's custom objects.
In the hosted app each application is its own record against a batch: applied, documents pending, under review, offered, admitted or waitlisted, with the marksheets attached, the application fee ticked and the parent linked as a contact. A batch lists its applications on its own page.
Each course defined with a code and a fee, then dropped onto a quotation or a receipt rather than retyped. The app seeds eight to start you off.
An itemised quotation on a private tokenised link, accepted with no signup, and the acceptance records who accepted and when. Convert it and the fee receipt comes out with the same lines.
Record money against the same receipt as often as it arrives. Overdue is marked by a nightly check rather than by somebody going through the register.
A monthly or quarterly schedule with an end date, generating the next instalment on a nightly job. Switch the schedule off to stop it.
Files attach to the enquiry from the web app and the phone, and to the student contact from the web app, rather than sitting in an inbox nobody else can search.
A first-response target and a resolution target on each one, counted against your working week and your holidays, and paused while you are waiting on the family.
Admissions season doubles your counsellor count for two months. There is no seat cap and no per-user fee, so the peak costs you nothing extra.
This is an admissions CRM, not a school management system. If what you need is the classroom rather than the enquiry, that line is where it stops, and knowing it now beats finding out in the middle of a season.
On the enquiry the parent is two text fields, a name and a phone number. In the hosted app an application links the parent as a contact, but nothing links a parent to a student directly or gathers siblings into a family, and the self-hosted edition has the two fields only.
In the hosted app a batch has its dates, a schedule line and its seats, counted as students are admitted. Sessions, rooms and teachers are not modelled, and the self-hosted edition has no batch at all.
No per-session attendance against a batch, and no register. Once a student is admitted, what happens in the classroom is outside what this holds.
Outcomes per counsellor stop at admitted or lost. How long an enquiry sat in each stage is not recorded, and admissions are not reported by source or campaign. Deals carry stage aging; enquiries do not. The outcomes page is not on the phone app.
A callback has an owner and a due date and the list sorts by it. Nothing emails or notifies anyone when it falls due, and nothing repeats a follow-up on a schedule. You go to the list.
No messaging integration pulls enquiries in. A web form you build in Settings and embed on your site does bring them in without anyone retyping them, but a message thread is not a channel this reads.
The enquiry model, the visibility rules and the admissions app are all in the open repository.
Nothing per counsellor. BottleCRM has no per-user fee and no seat cap on any plan, hosted or self-hosted, which is the point in a trade where you take on counsellors for admission season and let them go afterwards.
Yes. It is a Django and PostgreSQL application you deploy yourself, so student and parent details stay on infrastructure you control. Tenant isolation is enforced by row-level security in the database.
Yes. A fee balance goes on a recurring schedule that raises the next instalment on a monthly or quarterly cycle, generated by a nightly job rather than by someone remembering. It stops on its end date or when you switch it off.
Yes, in the hosted app. Each batch counts its admitted and waitlisted applications and the seats left, in fields you can filter and export, and an open batch turns Full when none are left. Admitting past the seats is allowed, since refusing would stop a counsellor in the middle of a call. The self-hosted edition has no batch record.
No. A counsellor sees the enquiries assigned to them or that they created, and administrators see everything. The check is in the API, so it holds for the phone and for anything you build against the API too.
Yes. Save last season's list as a CSV and use Import on the leads list (Enquiries, once the app is installed on the web), on the web or the phone. You see every row it would create and every row error first, and nothing is written until you commit, which then writes the whole file or none of it. Up to 5,000 rows a file.
Yes. They are drawn as a board on the web app and the phone: a new enquiry starts in the No stage lane, and a counsellor drags it, or moves it from its menu, through the app's stages from New enquiry to Admitted. An admin can rename, add or remove stages in Settings. The enquiry status, the five fields the app adds and the tags all work alongside it.
Install the admissions app, put every counsellor on it, and pay nothing per head. Self-host it and student records never leave your server.