Language School Software: Placement, Cohorts and Recurring Enrollment

Why cohort and enrollment software makes or breaks a language school operator

Strip a language school back and what is left is a sorting machine. It takes a stranger who speaks some amount of a language, measures them, drops them into a group of 8 to 14 people at the same level who are available at the same hours, keeps that group intact for 8 or 10 or 12 weeks, then moves the survivors up one level and does it again. Every piece of software sold to you assumes the easy version of this: fixed terms, fixed start dates, students who enroll once. Your reality is continuous intake, rolling starts, A2 students who should be B1, and a Tuesday evening class that dropped from 11 to 6 because half of it was corporate students whose employer stopped paying.

So you run the machine on tools that each do one third of it. Classe365 or Teachworks or Arbeit or Schoolmint holds the student records. Google Calendar or a whiteboard holds the room and teacher grid. Then the actual intelligence lives in a Google Sheet called something like "Q3 PLACEMENT MASTER v7 FINAL" that your Director of Studies maintains by hand, where each row is a student and the columns are placement score, preferred days, preferred time band, start date, level, and a color fill that means something only she knows. Stripe or GoCardless takes the money, but the mapping of which payment belongs to which cohort seat lives in a second sheet. Mailchimp sends the re-enrollment nudges, on a list someone exports every Friday.

Here is the scene that costs you real money. It is week 9 of a 10 week cycle. Your DoS has 214 continuing students who need to be placed into next cycle's cohorts, 60 new leads who took the online placement test, and 19 teachers with availability windows that changed since last cycle because two of them started a master's program. She blocks three days. She builds the grid by hand. On day two she discovers that B1 Evening Tuesday/Thursday has 17 people wanting it and B1 Evening Monday/Wednesday has 4, so she has to call people and move them, which means some of them do not re-enroll at all because the friction gave them a reason to think about it. At a school running 1,200 students at an average of $1,400 per cycle, a 6 point drop in re-enrollment between cycles is roughly $100k of revenue a year, and it recurs every single cycle. That is the number that decides whether you build.

Problem 1: placement is a judgment call your software refuses to model

A student takes your online test, scores 62, and your tool says "B1." Except your B1 is not a score. Your B1 is a score, plus a speaking assessment your teacher did on Zoom, plus the fact that this student is a Brazilian engineer who reads well and speaks badly, plus the fact that the actual B1 Evening cohort starting on the 14th already has four people who read well and speak badly and adding a fifth makes it a bad class. Your DoS knows all of this. Your software knows one number.

Classe365 and Teachworks cannot close that gap, because they model a student's level as a field on a record. A field cannot carry a placement history, a per-skill breakdown, a teacher's override with a reason attached, or a rule that says "a student who has repeated a level once gets manual review before auto-placement." So your DoS overrides the field and records the real reason in a spreadsheet comment, and now the spreadsheet is the system of record and the software is a filing cabinet.

In a custom build, placement becomes a first-class object rather than a field. Every student carries a placement record with sub-scores for reading, listening, speaking, writing, the assessor, the date, and the instrument used. Level assignment is a rule engine you own: score bands, plus skill-gap flags, plus prior-cycle teacher recommendation, plus a manual override that requires a reason code and stamps who did it. When a teacher marks a student as misplaced in week 2, the system logs it against the placement record, which means after four cycles you can query which placement instrument produces the most week 2 misplacements. That is a data flow no off-the-shelf tool gives you, and it is the thing that lets you fix placement instead of just arguing about it.

The AI worth buying here runs the after-hours placement conversation. A prospect lands on your site at 11pm, and instead of a 40 question multiple choice test, they have a five minute spoken or written exchange with a model that probes vocabulary range, tense control, and error patterns, and produces a draft CEFR sub-score breakdown plus a transcript your DoS reviews in 90 seconds. We build these to draft, never to decide. The model produces the assessment, the human approves it, and the approval is what writes to the placement record.

Problem 2: cohort building is a constraint solve, and your tool is a calendar

Building next cycle's grid means satisfying, at once: minimum viable class size (say 6) and maximum (say 14), level match, student day/time preference, teacher qualification for that level, teacher availability, teacher contracted hours, room capacity, room availability, and the rule that your best B2 teacher does not get three B2 sections in a row because she will quit. Doing this by hand for 40 sections takes three days and produces a grid that is feasible but not good.

Teachworks and Google Calendar both let you place a class at a time. Neither knows that placing it there stranded 11 students. There is no notion of an unplaced student pool, no objective function, no "what happens if I move this section to Wednesday." You are the solver, and you are solving it with sticky notes.

A custom build models the cycle as a scheduling problem and lets a solver propose. Inputs are the unplaced student pool with their preference windows, the teacher roster with qualifications and availability, and the room inventory. Output is a proposed grid with an explicit score: students placed in first-choice window, students placed in second choice, students unplaced, sections below minimum, teacher hours utilization, room utilization. Your DoS does not accept the output blindly. She gets three proposals, drags two sections, and the system re-solves the affected students in under a second and tells her exactly who she just displaced. Three days becomes an afternoon, and the grid is better, because a solver will happily discover that opening one extra A2 Saturday morning section rescues 9 students who would otherwise have gone unplaced and churned.

Problem 3: recurring enrollment is not a subscription, and Stripe treats it like one

Your revenue is cycle-based, not monthly. A student pays $1,400 for a 10 week cycle, or pays it in four installments, or their employer pays for six of the twelve people on a corporate contract while the other six pay themselves, or they have a 20 lesson credit pack that carries across cycles, or they froze their enrollment for a cycle because of a work trip and you owe them a credit. Off-the-shelf billing gives you subscriptions and one-time payments. Nothing in between.

Stripe Billing models a subscription against a customer, not a seat in a cohort. When a student drops out in week 3 and you move them to a later cohort, the subscription does not know a seat freed up, your school tool does not know a payment moved, and your DoS reconciles it by hand. Every school we have built for has a person whose real job title should be "spreadsheet reconciler."

In a custom build the seat is the unit. A seat in a cohort has a price, a payer (which may not be the student), a payment plan, and a state: held, confirmed, active, frozen, transferred, refunded. Payments attach to seats, not to people, and a transfer moves the paid balance with the seat. Corporate contracts get their own object: a company, a pool of funded seats, a PO number, an invoicing cadence, and a named HR (Human Resources) contact who gets the attendance report that justifies renewal. When your corporate account manager asks "how many of Siemens' 24 seats are actually being attended," that is a query, not a two hour reconstruction.

The second place a model pays is at-risk forecasting on real signals. Attendance in weeks 1 to 3, homework submission, and time-since-last-login predict non-renewal reasonably well, and the useful output is not a dashboard. It is a Monday morning list for your student success coordinator: eleven names, why each one flagged, and a drafted message referencing the specific class they missed. In our experience the win comes from the list being short and specific enough that someone actually calls, not from the model's accuracy.

Problem 4: multi-location teacher allocation, where hours become a legal problem

Three locations. Teachers who work across two of them. Contracted hour minimums that trigger benefits at a threshold. Travel time between sites that no calendar accounts for. Substitutions that happen at 7am by WhatsApp and get recorded nowhere, so payroll is a monthly argument.

Your school tool has one calendar per location because it was built for a single site. Teacher hours live in the payroll system, which learns about them 30 days late. Nobody can answer "is Marta going to cross 30 hours this month" until she has already crossed it.

A custom build makes teachers a global resource with a per-location availability calendar, travel buffers as hard constraints, and a running hour ledger that updates on the substitution, not on the payroll run. The substitution flow moves to the teacher app: teacher taps unavailable, system proposes qualified and available subs ranked by hour headroom, coordinator taps approve, ledger updates, payroll export at month end has no surprises. The compliance rule (your hour thresholds, your contract types, your jurisdiction) is a rule you own and can change when the law does, which is precisely the thing a vendor will not ship for you.

Problem 5: reporting that has consequences, not reporting that makes charts

If you take international students, you have reporting obligations with teeth. Attendance thresholds tied to visa status, enrollment confirmations, hour verification for accreditation bodies. Miss a report and you do not get a nasty email, you get a status problem for a student and a compliance problem for the school. Meanwhile your attendance data is teachers marking a paper roll and someone typing it in on Fridays.

Generic tools give you attendance percentage. They do not give you attendance against the specific rule your accreditor or immigration authority applies, they do not compute it in the reporting period the authority uses, and they do not tell you on day 12 that a student is trending toward a breach. So you find out in the audit.

In a custom build, attendance is captured at the source, in a teacher app, in the room, in under ten seconds, with an offline queue because your basement classroom has no signal. The compliance rule is codified with its exact definition and period. The system runs it nightly and raises a flag while there is still time to intervene, with an audit trail showing who was notified and when. Document handling is the third place a model earns its cost: passports, visas, and prior certificates get uploaded by students, extracted automatically into structured fields, and queued for a human to confirm. Your admissions coordinator stops typing passport numbers and starts checking them, which is a different job that takes a fifth of the time.

What this actually costs and how long it takes

These are Digital Heroes delivery bands, drawn from our experience across 2,000+ projects, not vendor quotes or industry surveys.

A focused first release runs $60k to $130k over 12 to 16 weeks. That is: placement records with a rule engine and manual override, cohort building with a solver and a DoS review screen, seat-based enrollment with payment plans, teacher assignment with hour tracking, and a teacher attendance app. It replaces the master spreadsheet and the reconciliation spreadsheet. It does not replace everything.

A full platform runs $150k to $400k phased over 6 to 12 months: student portal with self-service transfers and freezes, corporate contract management with client-facing reporting, multi-location scheduling with travel constraints, compliance reporting, AI placement drafting, document extraction, at-risk forecasting, and integrations into whatever you keep.

What pushes price up in this category specifically. First, the solver: if your constraints are simple, it is a week of work. If you have teacher seniority rules, room equipment requirements, split-level classes, and a rule that Saturday intensive students get priority on room 4, it is a month and it needs real tuning against real cycles. Second, legacy data: five years of student history in a tool with a weak export, where "level" was a free-text field and someone typed "B1/B2ish" 340 times. In our builds, data migration here is routinely 15 to 25 percent of a first release and it is always underestimated. Third, compliance surface: if you report to an immigration authority or an accreditor, that is not a report, it is a rule you must be able to defend, and it needs its own build and test cycle. Fourth, multi-currency and multi-country if your locations cross borders, which turns billing from a component into a workstream.

Build versus buy: an honest line

Buy, and stop reading, if you are a single location under roughly 400 active students with fixed term starts. Teachworks or Classe365 will hold your records, your DoS can build 12 sections by hand in a morning, and $80k of software would buy you a marginally nicer version of a problem you do not have. Spend the money on teachers.

Build when three of these are true. Your Director of Studies spends more than two full days per cycle building the grid by hand. You run continuous or rolling intake, so there is no quiet week where everything resets. You operate two or more locations with teachers shared across them. Your re-enrollment rate between cycles is a number you cannot explain, because the data lives in three systems. You have corporate contracts where the payer is not the student. You have a person whose main function is reconciling the school tool against Stripe.

Where I land: the trigger is not student count, it is whether your operating logic has left the software. The moment your real placement and cohort rules live in a spreadsheet and a person's head, your school tool has stopped being a system and become a filing cabinet, and every additional student makes that worse rather than better. At that point you are already paying for custom software. You are just paying for it in your DoS's salary, in reconciliation hours, and in the re-enrollments that leak out every time you have to phone someone and move their class.

How to choose a developer for language school software

Make them model the domain on a whiteboard before you sign anything. Ask them to sketch the relationship between student, placement record, cohort, seat, session, enrollment, and payment. If they draw student to course to payment, they are building you a course marketplace and you will discover it in month four. The tell is whether they treat the seat as an object with a lifecycle, because seats transfer and freeze and refund independently of students, and a developer who has not lived this will model it as a join table and hit a wall.

Ask what happens when your DoS overrides the solver. Anyone can build a solver. The question is whether the human stays in control. A team that has shipped this will immediately talk about proposal-and-approve flows, re-solving only affected students, showing who got displaced, and keeping an override log. A team that has not will tell you the algorithm will handle it, which means your DoS will refuse to use it and you will be back in the spreadsheet by cycle two.

Interrogate the integrations by name, and ask what breaks. Stripe or GoCardless for payment plans and installment failures, your accounting system for revenue recognition across cycle boundaries, your existing school tool if you are keeping it for records, SSO if you have corporate clients. Ask specifically what they do when a payment fails in week 6 of a 10 week cycle: does the seat stay active, is the student told, is the teacher told, who decides. A vague answer here means you inherit that decision as a support ticket every week forever.

Test their compliance instinct. Ask how they would handle an attendance rule tied to student visa status. The right answer starts with questions: which authority, what exact definition of attendance, what reporting period, what is the intervention window, who is legally accountable. The wrong answer starts with "we will add an attendance percentage." Compliance in this category is not a feature, it is a rule you must be able to defend to someone with authority over your students' status, and the build has to produce evidence, not just numbers.