Choosing language school management software starts with a practical question: where does a booking stop moving unless someone copies data, checks an inbox or chases a colleague?
A school admin system might handle enrolments well while finance still matches deposits by hand. An agency might have a useful CRM but lose application updates between counsellors and partner schools. An edtech company might need to exchange records with each customer's existing tools.
Buying, building and connecting are all reasonable options. Choose by testing a complete workflow, including its exceptions, and identifying who will maintain it.
Map one workflow before comparing software
For example, imagine a school with three centres and an agent network. An agent requests a course place. Admissions checks availability and sends a quote. Finance records the deposit. Accommodation staff allocate a room. Someone then updates the agent.
Follow one booking through those steps. Record:
Who creates and changes each record.
Which system holds the agreed course, dates and price.
What moves the booking to its next status.
Where staff retype information or maintain a separate spreadsheet.
What happens when dates change, payment fails or the booking is cancelled.
Keep enquiry, booking and payment statuses distinct. A paid deposit does not automatically mean every condition for enrolment is complete.
For agencies, map the hand-off from counsellor to partner institution and back. For edtech teams, map the exchange between your product and one customer system. The same exercise can reveal whether you need a replacement, a missing module or a connection.
Use the workflows on the language schools page as prompts for your own process map.
Compare the three routes
| Route | A reason to choose it | What you must accept |
| Buy a ready-made system | Your essential workflows fit its demonstrated configuration | Subscription terms, product limits and the supplier's release priorities |
| Build a custom module or system | Important operating rules remain unsupported after configuration and integration checks | Responsibility and budget for development, hosting, maintenance and future changes |
| Connect existing tools | Individual tools work well, but hand-offs create repeated work | Dependence on their interfaces, data definitions and ongoing integration support |
You can combine these routes. Buy the core system, connect accounting and build one specialist approval screen. Define the boundary of each part before requesting estimates.
When buying makes sense
Buying is worth testing when your team can work within an existing product's rules. Configuration may cover the gap without bespoke development.
Give suppliers the same demonstration brief. Use invented student records and ask them to complete a booking, change its dates, transfer it between centres and process a partial refund. Include an agent commission adjustment if that is part of your operation.
Ask specific questions:
Can each centre control its availability while head office sees group totals?
Who can change prices, approve refunds and view partner records?
Can staff change forms and rules themselves? Which changes require paid supplier work?
What data and documents can you export when leaving?
Which required connections are included in the proposed subscription?
Mark each requirement as demonstrated, configurable, dependent on extra work or unsupported. Treat a roadmap item as a dependency until it is available and tested.
Buying becomes less attractive if a critical process still needs a parallel spreadsheet. Check whether that is a configuration issue before ruling the product out.
When building is justified
Consider a build when you can describe the rules that existing options cannot support adequately. “We need flexibility” is too vague to scope.
In the hypothetical three-centre school, a specific requirement might be: a transfer must recalculate course charges, preserve the original agent agreement and require approval before releasing accommodation. Write down which parts existing tools already handle and which are missing.
Start with the smallest complete workflow that resolves the gap. For an agency, that could be partner confirmation and commission approval. For an edtech company, it could be a customer-facing configuration screen around existing integrations.
A custom build also needs an internal owner. Someone must approve rules, resolve conflicting requests and accept the finished work. Budget for fixes, access reviews, backups, supplier changes and documentation after launch.
When reviewing case studies, look for a clearly described starting process, scope and constraints. Then ask prospective suppliers which evidence is relevant to your requirements. Similar screens alone are weak evidence of fit.
When connecting existing tools is enough
Integration deserves a close look when staff trust their individual tools but spend time moving information between them. Start by naming the authoritative system for each type of data.
| Data | Example ownership decision to agree |
| Enquiry and follow-up | CRM owns contact history and the assigned counsellor |
| Booking and availability | School system owns course dates, capacity and booking status |
| Payment transaction | Payment provider supplies transaction and refund references |
| Invoice and allocation | Accounting system owns the financial record and payment allocation |
These are example boundaries. Confirm them with admissions and finance before building the exchange.
Payments: follow the transaction through
Agree what counts as payment confirmation. Do not treat the student's return to a confirmation page as sufficient evidence that funds were received.
Ask the supplier to demonstrate a delayed confirmation, a repeated notification and a partial refund. The same transaction arriving twice should not create two receipts or two booking updates. Staff need a visible way to investigate unmatched payments.
CRM: preserve identity and responsibility
Decide how contacts, students and bookings relate. One parent may pay for several students. One student may make several bookings. Email address alone may therefore be an unsuitable matching rule.
Specify which changes move in each direction and who resolves conflicting edits. When a counsellor changes, the next task and its owner must remain visible.
Accounting: include corrections
Agree how invoices, deposits, refunds, credit notes and commissions link to the booking. Ask finance which references and approval steps it needs. Test a changed booking after an invoice has been issued, rather than stopping at initial invoice creation.
Before commissioning any connection, check access to the API, the interface used to exchange data. Ask about subscription restrictions, usage limits and a test environment. If access is inadequate, compare a controlled file exchange with replacement. Include its manual work in the decision.
Compare cost over the same period
A subscription and a development estimate cover different things. Ask for a breakdown over the same planning period, using your expected centres, staff, students and transaction volumes.
Include:
Setup, configuration, migration and data clean-up.
Training, staff cover during rollout and internal project ownership.
Subscriptions, hosting, transaction fees and integration access.
Maintenance, monitoring, support and changes to external systems.
Export, handover and eventual replacement costs.
Separate essential requirements from useful additions. Ask what changes the estimate: another centre, a different payment provider, historical documents or a new approval rule.
Measure the current workflow before assigning a benefit to the change. Count repeated entries, unresolved payment matches and bookings awaiting a hand-off. Use your own records to set a target, then review it after rollout.
Plan migration and support before switching
Nominate one person to accept the workflow and one to own operational support. They need a written definition of completion.
Run a pilot with a limited programme or centre. Test normal bookings alongside cancellations, duplicate contacts, failed payments and missing documents. Check that agents and centres see only the records their roles permit.
Decide what history to migrate and what to retain in an accessible archive. Reconcile booking and financial records before switching. Set a cut-off for updates in the old system and document how staff should work if the new process is unavailable.
For integrations, agree who receives failure alerts, how failed exchanges are retried and who checks unresolved items. A connection needs an operating routine as well as an initial release.
Where to start
Bring admissions, operations and finance together around one recent booking. Produce a one-page map, a list of exceptions and a shortlist of tools to keep. Ask suppliers to assess that same material.
If you need prompts, revisit bookings, agents and arrivals across language school centres. Choose one workflow with a clear owner and an observable result.
Softvery builds custom software for international education companies. Its short paid discovery sprint covers one scenario, key screens, assumptions and a next-step plan. The scoped discovery offer includes a process map and open questions; production code, live integrations and migration are excluded.
For background, read what a discovery sprint includes.
If you would like to discuss which route fits your workflow, Book a 30-min call.
