School ERP buying guide

Most schools do not need every module on day one. Write down the five jobs that cost your office the most time today. For many schools these are fee collection and follow-up, attendance, report cards, admissions enquiries and communication with parents. Rank them. A system that handles your top five well is better than one that claims fifty features.

Also note who does the work. A fee clerk, a class teacher and a principal have very different needs, and software succeeds or fails on whether those people actually use it.

For each module you care about, ask to see the real screen, not a slide. Open the fee module and follow one student from fee structure to receipt. Open exams and follow one exam from creation to a published report card. If a vendor cannot show a feature working, treat it as not existing.

Be careful with long lists on websites. Ask whether each item is built, partly built or planned. A trustworthy vendor will tell you plainly what is not available yet.

A school has owners, principals, teachers, accountants, parents, students, drivers and others. Check that each role sees only what it should. An accountant should not edit marks; a parent should only see their own child; a teacher should see their own classes. Ask how roles are defined and whether you can restrict modules by plan or by user.

Ask about sign-in security too: two-factor sign-in, audit logs, and the ability to sign users out everywhere.

Moving in is the hardest part. Ask what can be imported from spreadsheets (students, staff, fee structures, opening balances), whether you can preview before committing and whether a bad import can be undone. Then ask the reverse question: can you export everything if you leave, and in what format?

Ask who owns the data, where it is stored and how it is protected. Read the privacy policy and data processing terms rather than the marketing page.

If the software collects fees online, find out whose payment account receives the money. The cleanest arrangement is that parents pay into the school’s own gateway account, so settlement never passes through the vendor. Check how refunds and voided receipts are handled so that corrections stay on record.

If you use Tally or another accounting tool, ask for a sample export.

Parents will judge your school partly by the app. Check which platforms are supported. Takshiva’s apps, for example, are Android only today. Ask whether teachers can mark attendance on a phone, and what happens with poor connectivity.

Ask how SMS, WhatsApp and email are sent. Often the vendor connects to a provider and you pay the provider for message credits. That is fine, but it should be clear in advance. See our integrations page for how Takshiva handles it.

Ask for a demo using a few of your real classes and fee heads. Have your fee clerk and one teacher try their daily tasks. Notice how many clicks common jobs take and whether the screens are in a language and style your staff are comfortable with.

Compare what is included, not only the headline price: number of students, modules, apps, support level, data import help and renewal terms. Our pricing guide lists the questions to ask.

• Top five jobs defined and ranked
• Each needed feature shown working
• Roles and permissions tested
• Import and export tested
• Payment flow understood
• Mobile apps tried by a teacher and a parent
• Message provider and costs clear
• Contract, renewal and exit terms read

The first mistake is buying on the basis of a single impressive demo. A presenter who knows the product will always find a smooth path through it. Ask to drive the screens yourself, with a task your own staff perform every week, such as collecting a part payment from a student who has a sibling, or correcting a wrongly entered mark after results are published.

The second mistake is ignoring the people who will use the system daily. The principal may sign the contract, but the fee clerk, the class teachers and the front-desk staff decide whether the software succeeds. Include them in the trial and ask what slowed them down.

The third mistake is treating implementation as an afterthought. Even good software fails if student records are imported badly or staff are not shown how to use it. Plan who enters data, who checks it and who trains whom, and set a date from which the old registers are no longer updated.

The fourth is expecting software to fix a broken process. If your fee policy changes every month or nobody owns the admission follow-up, software will record the confusion faster. Settle the process first, or at least in parallel.

Most schools do better with a phased rollout than with switching everything on in one week. A common order is student records first, then fees, then attendance, then exams and report cards, then communication and apps for parents. Each phase has a clear owner, a clear test (for example, one full month of fee receipts raised entirely in the system) and a clear review before the next phase begins.

Run the old and new method side by side for a short period for the process that carries the most risk, which is usually fees, and compare the totals at the end of each week. Do not run both for long; double entry tires staff and invites mistakes.

Choose a quiet period if you can. Starting at the beginning of an academic year is natural, but it is also when admissions and fee collection peak. Some schools prefer to start a new module at the beginning of a term, after the rush.

Ask the vendor to put you in touch with schools similar to yours in board, size and city. Do not rely only on the names the vendor volunteers. Ask those schools what went wrong during the first three months, how quickly problems were handled and whether they would choose the same product again. If a vendor is new and cannot offer references, ask for a longer pilot with your own data instead, and for clear exit terms.