Campus One blog

Where AI belongs in a school office, and where it does not

2026-10-05T00:00:00Z

The pitch every school now hears

Many software pitches to schools now include AI: AI that writes the notice, AI that predicts which family will pay late, AI that answers parents at midnight. Some of it is genuinely useful. Some of it puts a machine where a school needs a fact.

Plausible is not the same as correct

A school office deals in facts that people act on: a fee balance, a mark, an attendance percentage, whether a parent received a notice. Language models are very good at producing text that sounds right. In a school office, sounding right is not enough. A balance that is almost right, or a question that is nearly on the syllabus, does more harm than no help at all, because it looks finished and nobody checks it.

The rule Campus One is built on

In the Campus One modules described on this site, the work is split in two:

Facts of record come from arithmetic over the school's own records, with tests: balances, receipt numbers, attendance percentages, mark totals.
Where AI is used, it may help a person choose among things the school already has, and the person decides. The work must still get done without it: in the exam paper generator, for example, the standard method runs when no AI is available, and the screen says so.

The sections below show where that rule is enforced in the product.

Where the rule is enforced

Money

In the fee ledger, balances, ageing, receipt numbers and how a payment is split across instalments are all worked out by arithmetic over the ledger. No AI and no estimate ever writes a balance. Receipts are numbered without gaps for each campus and financial year. Our guide to fee management explains why that matters at the counter.

Question papers

The exam paper generator does not need AI to make a paper: its standard method, which uses no AI, builds a paper from questions already approved in the school's own bank, to a blueprint whose marks must add up. Where an AI model is set up, it may help choose questions from that bank, and its choice is checked against the same blueprint. It can only point to questions that exist; it never writes question text. If no model is set up, or the AI budget is used up, the standard method runs and the screen says so. Our guide to question paper blueprints shows the checks.

Parent messages

Notices are written from the school's own templates; the messaging module has no AI drafting. No message is shown as delivered unless a messaging provider confirms it. In the demo no provider is connected, so every notice is marked simulated, and the screen says so.

Records and decisions

When a new enquiry's phone number matches a family already in the school, Campus One shows the match as evidence and stops there. The family record is reused only when a person admits the child. In the store, the run-out forecast is plain arithmetic rather than AI, and it still only produces a draft recommendation with the evidence behind it; it never orders anything.

The product's engineering rules require every number on a dashboard to open the records behind it, and say plainly: no fabricated numbers. The record history is designed to include actions taken by an automation or an AI, written like any other entry.

What is not built

The Complete plan on the price list names an AI office assistant. It is not built, and the pricing page marks it as not built. We would rather show that gap than describe a feature that does not exist.

Questions to ask any vendor about AI

Which features use AI, by name?
Can AI change a balance, a mark or an attendance record? It should not be able to.
Does each AI feature still work, in a standard way, with AI switched off?
Does AI write anything that goes to parents or students, and who approves it first?
Is every AI action recorded on the record it touched?
Which of our data is sent to an AI model, and where does that model run?

Ask for the answers in writing. Our article on where school data should be stored has the questions to ask about the data itself.

Who builds by these rules

Campus One is built by AskShiva Private Limited, whose leadership team is Divya Prakash Jha (Chief Executive Officer), Vaibhav Jain (Chief Operating Officer) and Zeeshan Khan (Chief Marketing Officer). The rules in this article are written into the product's engineering notes and its code. They are the company's position, set out here in the company's voice; nothing in this article is a quotation from any one person.

This describes how the product is built. It is not a certification or a compliance claim.

The outcome: every number has an explanation

When facts come from records and AI only helps people choose, a school can explain every number it gives a parent: where it came from, who entered it and when. That is a better foundation for using AI than any feature list.

The takeaway

Use AI to help people choose and to save typing, never to produce a fact of record, and ask every vendor the six questions above. The exam paper generator page shows how AI help with question choice works in Campus One, and our checklist for choosing school software covers the rest of the decision. To see the standard method and its checks on the demo school, ask us for a walkthrough.

Attendance registers in schools: counting working days right

2026-10-05T00:00:00Z

The situation: the end-of-month count

On the last working day of the month, class teachers in many schools add up their registers. Each student's present days are counted by hand, the month's school days are counted from the calendar, and the percentage goes into a summary sheet for the principal. It is slow, but the bigger problem is that two teachers rarely count the same way.

The tension: what is a school day?

The disagreements are always the same:

Does a Sunday count? A second Saturday? A declared holiday?
Is a student who came late present?
Is a half day half a day, or a full one?
Does approved leave count as present?
What happens on the day the register was not taken because the teacher was out?

Each answer moves the percentage, and when the school uses an attendance threshold to decide who needs a conversation with parents, those small differences matter.

The insight: decide the rules once, then let arithmetic apply them

An attendance percentage is only as good as its denominator. The fairest rule is to divide by working days: the days the school was actually open, with weekly offs and the school's holiday list taken out. Then decide, once, how each mark counts. After that, the percentage is arithmetic, and every class gets the same treatment.

The decision: the rules Campus One uses

Campus One marks attendance with five codes, and each has a fixed weight:

Code	Meaning	Counts as
P	Present	1
L	Late	1
H	Half day	0.5
A	Absent	0
CL	Approved leave	0

The monthly register divides the total by working days only. Two more rules keep it honest:

A register that was not taken still counts as a working day. The percentage falls, and the register shows that the day was not marked. It is better for the principal to see a gap than for the gap to be quietly skipped.
A correction after a register is locked needs a reason, and the reason stays on record with the change.

The evidence: try the arithmetic yourself

The attendance register on our home page is a small simulation of one made-up student's month using exactly these rules. Change a mark from present to absent, or a day to approved leave, and the working days, the present-equivalent days and the percentage update. The threshold there is an example: in the product, the threshold is a setting each school chooses.

In the Campus One demo, teachers mark a whole class in one pass, the monthly register applies these rules, and the principal sees the classes that fall below the school's threshold.

Mistakes that skew the percentage

Most disagreements about attendance come from a handful of habits:

Counting calendar days instead of working days. Sundays, second Saturdays and declared holidays in the denominator make every student look worse than they are.
Leaving a day blank. A blank cell can mean "absent", "not marked" or "holiday", depending on who reads it. Each needs its own mark.
Different rules in different classes. If one teacher counts approved leave as present and another does not, the school's threshold list is unfair before anyone looks at it.
Silent corrections. Changing a mark weeks later without a note leaves the school unable to explain the change when a parent asks.

Questions to ask about any attendance register

Does the monthly percentage divide by working days, with weekly offs and the holiday list taken out?
Where is the holiday list kept, and who can change it?
What happens to a day when the register was not taken?
Can a locked register be corrected, and is the reason kept?
Can the principal see today which classes and students are below the school's threshold?

In Campus One, the answers are the ones above: working days only, a register not taken still counts as a working day, a correction after lock needs a reason that stays on record, and the threshold is a school setting with a list of the students below it.

The outcome: one number everybody agrees on

With the rules fixed, the end-of-month count disappears. The percentage is the same whoever opens the register, the principal's list of students below the threshold is current every day, and a question from a parent can be answered from the register itself.

What Campus One does not do yet

Absence messages to parents are not sent: messages are simulated in the demo and WhatsApp delivery is not connected. Payroll is planned. Campus One runs in the browser; an Android app is planned.

The takeaway

Write down your school's attendance rules: what is a working day, and how each mark counts. Then make sure your register, paper or software, applies them the same way every time. The Campus One attendance page shows how the product does it.

From marks grid to report card: how school results are made

2026-10-05T00:00:00Z

The situation: results week

In the week before results, the school office changes shape. Teachers hand in mark sheets, someone types them into a spreadsheet, a formula works out grades, and the office copies each student's marks into a report-card template. Then the report cards are printed, checked, signed and handed out.

The tension: one wrong cell, a whole class reprinted

Every copy is a chance for an error. A mark typed into the wrong row, a formula dragged one cell too far, an absent student given a zero instead of an absent code. The error is usually found after printing, by a parent, and fixing it means reprinting and explaining which copy is the right one.

The insight: enter once, freeze when published

Two habits remove most of these errors. First, enter each mark once, in one place that the report card reads directly. Second, treat a published result as a fixed record: if something must change, issue a new copy instead of editing the old one, so there is never a question about which version a family received.

The decision: how the work flows in Campus One

One marks grid

Teachers enter marks into a grid with a row for each student. A student who did not sit the paper gets a code rather than a number: AB for absent, ML for medical leave or EX for exempt. If two people change the same cell, the second save is refused instead of silently overwriting the first.

Grade scales as data

Grades are worked out from the school's grade scale. In Campus One a scale is stored as data with the year it takes effect. Boards revise their schemes from time to time; when that happens, the school adds the new scale for the new year, and last year's results stay exactly as they were.

Print, then publish

Report cards print from the grid. When the school publishes results, each published report card becomes a fixed copy. A correction later is issued again as a new copy.

The evidence: what is built today

In the Campus One demo, exams and report cards are built: the marks grid with grades, printable report cards and publishing all work on the made-up demo school. A school's own report-card layout is available as an add-on at ₹5,000 per template, on the price list.

Two things are not built yet: a moderation workflow for marks and a grid for co-scholastic areas. Which board format your school needs is a question to bring to a walkthrough: we answer for your case rather than list formats here.

A checklist for results week

Whatever system the school uses, these steps catch most errors before a parent does:

Agree the codes first. Decide how the school records a student who was absent, on medical leave or exempt, and use a code, never a zero.
Fix the grade scale for the year before the first mark is entered, and keep last year's scale for last year's results.
One owner per subject grid. The subject teacher enters the marks; the class teacher and the office read them.
Check totals per student in the grid before anything is printed.
Print one report card per class first and compare it with the grid line by line.
Publish only after review by the academic head or principal.
Never edit a published result in place. Issue a corrected copy and keep the original.

Questions to ask about any report-card software

Can absent, medical leave and exempt be recorded as codes rather than numbers?
What happens if two people edit the same mark at the same time?
Are grade scales stored with the year they apply to?
What happens to a report card after it is published, and how is a correction issued?
Can the school have its own report-card layout, and what does it cost?

Campus One's answers are in this article: codes AB, ML and EX; a second save on the same cell is refused; scales carry their effective year; a published report card is a fixed copy and a correction is a new one; a custom layout is an add-on at ₹5,000 per template.

The outcome: a calmer results week

When marks are entered once and the report card reads them directly, results week becomes a checking exercise rather than a copying exercise. The academic head reviews one grid, the office prints from it, and a later correction is a new copy with a clear history.

The takeaway

Whatever tools you use, enter marks in one place, keep codes for students who did not sit a paper, and never edit a published result in place. The Campus One exams page shows the same flow in the product, and the exam paper generator covers the papers that come first.

From registers and spreadsheets to one school system

2026-10-05T00:00:00Z

The situation: years of good records in the wrong shape

Most school offices are not short of records. They have admission registers going back years, a spreadsheet of students per class, fee ledgers, and a folder of report-card files. The records are usually good. They are just in the wrong shape: each one was built for a single job, so the same student appears in all of them with small differences in spelling, class or phone number.

The tension: double entry never stops by itself

As long as each job keeps its own list, every change has to be made several times. A student moves section, and the attendance register, the fee spreadsheet and the report-card file all need the same correction. Somebody misses one, and the office spends the next month reconciling.

The insight: one record per student, everything else hangs off it

The move to one system works when it is planned around a single idea: each student is entered once, and attendance, fees, marks and notices all read that same record. That changes the order of work. You do not start with fees or report cards; you start with the student list.

The decision: the order that works

1. Clean the student list first

Take your best list of current students and make it the master. Check, class by class:

one row per student, with the same spelling everywhere;
class and section as the school uses them today;
the parent or guardian contacts the office actually uses;
siblings marked, so a family is one family and not two.

2. Bring in staff and roles

List the people who will use the system and what each one does: principal, office, accounts, class teachers, academic head. In Campus One each person gets their own login, and each role sees only what it needs.

3. Import fees as a roster, payments as a statement

Fees are two different things: what each student should pay (the fee plan, with instalments and concessions) and what has been paid. Keep them apart. In Campus One, the fee roster and the payment statement each have an importer that checks every row and shows it to you before anything is saved; the rows that fail can be downloaded, fixed and imported again. The importers read CSV, so save Excel sheets as CSV first.

4. Start the day in the new system

Once the lists are in, the daily work moves: teachers mark attendance, accounts record payments and issue numbered receipts, the office works the admissions pipeline. Keep the old registers on the shelf for reference, but stop writing in them.

5. Check the first week

At the end of the first week, look at what needs attention: overdue fees, pending follow-ups, missing documents. If a number looks wrong, open it: in Campus One the dashboard numbers open the records behind them, so a wrong figure leads straight to the row that caused it.

The evidence: how Campus One sets up a school

Campus One's set-up has four steps, the same ones on our how it works page: the team imports students, staff and fees from your registers or spreadsheets; each person gets a login; the office runs the day from one place; dashboards show what needs attention. Set-up and data import are free with yearly prepayment, including configuration and online training.

Two honest limits apply today. Campus One runs with a made-up demo school, and real school data is loaded only after it moves to a server in India. An import wizard for merging old records is not built yet, so the first import is done with our team.

Common mistakes to avoid

Importing everything at once. Bring in the current students first; old years can follow once the current year runs well.
Importing before naming is agreed. Decide how classes and sections are written, for example "7" or "VII", "A" or "Section A", before the first import, or the system will hold both.
Forgetting siblings. Two children of one family entered as two families means two sets of contacts to keep up to date.
Running two systems for too long. Keep the paper registers for reference, but set a date after which nobody writes in them.

The outcome: fewer places to be wrong

The aim is not a perfect migration of every old page. It is a school office where a change is made once and seen everywhere, and where the record of who changed what is kept by the system rather than by memory.

The takeaway

Start with one clean student list, add people and roles, then fees, then the daily work. If you would like to see the order in practice, ask for a walkthrough of the Campus One demo school.

Parent notices: what to plan before using WhatsApp in school

2026-10-05T00:00:00Z

The situation: the circular and the class group

A school notice usually travels two ways at once. A printed circular goes home in school bags, and the same text is forwarded to class WhatsApp groups by teachers or parent representatives. Most families see it. Some do not, and nobody can say which.

The tension: messages without a record

Group forwards are quick, but they leave the school without answers to simple questions. Which families received the notice about the fee date? Did the parent who asked not to be messaged get it anyway? When a family says they never heard about the meeting, the school has no record to check.

The insight: plan the list before the message

Good parent communication starts with the recipient list, not the wording. If the list comes from the student records, if opt-outs are applied automatically and if every message has a delivery state, the school can answer every one of those questions.

The decision: what to plan

Templates

Most notices repeat: holidays, meetings, fee dates, events. A template for each keeps the wording consistent and saves the office from rewriting the same notice every term.

Recipients from records

The recipient list should come from the student records: a class, a section, the families with a fee due. Look at the list before sending.

Opt-outs

Families who asked not to receive messages must be left out every time, without someone remembering to remove them.

Delivery states

Record what actually happened to each message. A message is delivered only when the messaging provider confirms it; until then it is pending, or failed, or, in a test system, simulated.

Costs

WhatsApp messages sent through a business provider cost money per message. Know your allowance and the price of extra messages before planning a weekly newsletter.

The evidence: what Campus One does today

Parent messages in Campus One are partly built. In the demo:

notices are written from templates;
the recipient list is built from student records and shown before sending;
families who opted out are left out automatically;
every notice is kept with its delivery state, and Campus One never claims a delivery a provider did not confirm.

Because no messaging provider is connected, every notice in the demo is marked simulated, and the screen says so. Real WhatsApp delivery is not connected yet, and the parent app is planned. On the price list, the Essentials plan includes 40 WhatsApp messages per student per year, with extra messages at ₹0.25 each; ask us how that applies while delivery is not connected.

A short notice policy for the office

Before the first message goes out from any system, it helps to agree a one-page policy:

Who may send to whom. For example, class teachers to their own class, the office to the whole school.
Which notices need a second look before they go out, such as fee reminders, exam dates and anything about a single child.
How opt-out requests are recorded. A family's request should be entered in the system the day it is made, not remembered by one teacher.
What still goes on paper. Some families do not read messages; decide which notices are also printed.
How long the record is kept. If a family says they never received a notice, the office should be able to check the record for that term.

Questions to ask about any notice system

Is the recipient list built from the student records, and can we see it before sending?
Are families who opted out left out automatically?
Is a message shown as delivered only when the provider confirms it?
What does each message cost, and how many are included?

Campus One's answers today: yes, yes, and yes, with every demo notice marked simulated because no provider is connected; and the price list's message allowance and extra-message price are in the section above.

The outcome: an answer to "did they get it?"

With templates, a recipient list from records, automatic opt-outs and honest delivery states, the office can answer every question about a notice: what was sent, to whom, and what happened to it.

The takeaway

Before you send notices on WhatsApp, decide where the recipient list comes from, how opt-outs are applied and how delivery is recorded. The Campus One parent notices page shows what the product does today, including what is simulated.

How to set a question paper from a blueprint that adds up

2026-10-05T00:00:00Z

Two days before the periodic test

In many schools, the paper for a periodic test is set by one teacher, late in the week, with last year's paper open on the desk. Questions are picked chapter by chapter, marks are written in the margin, and the paper goes to the academic head for a quick look before it is photocopied.

Most of the time this works. When it does not, the problem is rarely a bad question. It is arithmetic: a section meant to carry ten marks carries eight, the paper adds up to 38 instead of 40, or one chapter fills half the paper because it was the easiest place to find questions. Those mistakes tend to surface late, sometimes in the exam hall.

Why checking at the end is too late

The usual safeguard is a final check: someone adds up the marks before printing. A final check can find a wrong total, but it cannot easily fix one. By then the questions are chosen and the layout is done, and changing one section means re-balancing the others.

A blueprint moves the check to the start. Before a single question is chosen, the paper is written down as numbers, and the numbers either add up or they do not.

What a blueprint is

A blueprint is a short table that describes the paper without its questions:

the total marks and the time allowed;
the sections, and for each one the number of questions and the marks for each question;
any choice, such as "attempt any four of five";
the chapters the paper may draw from, and roughly how much weight each one carries;
the mix of easy, medium and hard questions.

Once the blueprint adds up, choosing questions becomes a matter of filling slots.

How to build one, step by step

1. Start from the total

Write the paper's total marks and the time allowed. Everything below must add up to this number.

2. Lay out the sections

For each section, write the number of questions and the marks for each. Multiply, then add the sections. If they do not reach the total, stop and fix it now, while it costs nothing.

3. Check every choice

"Attempt any four" only makes sense if at least four questions are printed in that section. Write down both numbers, the printed questions and the questions a student must attempt, and make sure the section's marks are counted on the attempted ones.

4. Choose the chapters and their weight

List the chapters in this test's syllabus and how much of the paper each should carry. A revision paper may lean on one chapter on purpose; a term paper usually should not.

5. Set the difficulty mix

Decide the share of easy, medium and hard questions. The three must add up to 100%.

6. Only then choose the questions

Fill each slot from your question bank, prefer questions the class has not seen recently, and write the answer key as you go.

What Campus One checks, and what it refuses

In the exam paper generator in Campus One, the blueprint is checked by the same rules twice: in the browser on every keystroke, and on the server before anything is saved. Because both checks come from the same file, the preview a teacher sees and the server's decision cannot disagree.

The rules fall into two groups. Errors block: the paper cannot be generated, submitted or approved while one stands. Warnings inform: the teacher sees them and may have a good reason to go ahead.

What the check finds	Result
The sections add up to a different total from the paper	Error
Easy, medium and hard do not add up to 100%	Error
"Attempt any" asks for more questions than the section prints	Error
A section has no questions, or two sections have the same name	Error
No chapters are selected, or a section asks for a chapter outside the paper's syllabus	Error
One chapter carries much more of the paper than the others	Warning
More sections than any board pattern uses	Warning

A mistake we found in our own templates

Campus One comes with ready-made blueprints, so a teacher does not have to start from an empty table. While the generator was being built, the team found that one of them, a template for a 40-mark periodic test, had sections that added up to 34 marks.

The fix was not only to correct that template. An automated test now checks that every ready-made blueprint adds up to the total it states, so the same mistake in any template is caught before it ships.

It is a small story, and it is the whole case for blueprints in one example: a six-mark gap is easy to miss by eye and trivial for a check to catch.

From a blueprint to a printed paper

Once the blueprint passes, the paper is assembled from questions already approved in the school's own bank. It fills each slot with a question not used recently; if the bank has no fresh question of the right kind, it reuses the least recently used one and says so, rather than leaving the paper short. AI can help choose among the bank's questions, but it never writes question text. If no AI model is set up, the standard method runs and the screen says so.

The paper then moves from draft to review to approved and locked. Teachers can view a paper under review; only approvers can approve it. Locking records a fingerprint of the paper's content and marks its questions as used, which is what the next paper's "not used recently" rule reads. The paper keeps its own copy of every question, so editing the bank later never changes a paper that has already been printed. The A4 export carries the school header, page numbers and properly laid-out maths, with the answer key and marking rubric.

What it does not do yet

Several versions of the same paper for different sections or rooms are planned, not built. The generator runs today inside the Campus One demo with demo questions: a CBSE bank (NCERT 2026-27) for Grades 6 to 10 and one Maharashtra State Board Grade 9 Mathematics set. On the price list it is part of the Complete plan.

Try the rule yourself

The Campus One home page has a simulation of the blueprint check for a 40-mark paper. Change the number of questions in a section and watch the total: Generate stays off until the marks match, as it does in the product.

The takeaway

Write the blueprint before the questions, make the arithmetic check automatic, and treat a wrong total as a reason to stop. The exam paper generator page describes each step in the product; from marks grid to report card picks up after the exam, and our checklist for choosing school software covers the rest of the office. If you would like to see a paper go from blueprint to print on the demo school, ask us for a walkthrough.

Who should see what? Role-based logins in a school office

2026-10-05T00:00:00Z

One password on the office computer

In many school offices, the software, or the shared folder of spreadsheets, is opened with one login that everybody knows. The accountant uses it, the front desk uses it, and a teacher borrows it to look up a phone number. It is convenient until a fee balance changes and nobody can say who changed it, or a family's details are seen by someone who never needed them.

The real problem is responsibility, not secrecy

Roles are often discussed as a way to keep secrets. In a school office the bigger issue is responsibility. When five people share one login, every change belongs to nobody, and a record of "who changed what" is impossible. That record only exists when each person signs in as themselves.

Two more questions follow from that:

What does each person need to see and do for their job, and what do they not need?
Which decisions should need a second person: the ones that cost money, or change a published result?

Start from jobs, not people

Write down the jobs in your office before you write down names. The table below is a sensible starting point for most schools, and it mirrors the default role templates in Campus One.

Job	Sees and does	Does not need
Teacher	Marks attendance, enters marks, prepares question papers, reads student records	Fee accounts, purchase approvals
Accounts	Fee plans, payments, receipts, overdue lists, imports and exports	Marks entry, question papers
Admissions counsellor	Enquiries, follow-ups, campus visits, applications	Fee accounts, marks
Academic head	Question papers and their approval, marks, attendance summaries	Fee accounts
Store administrator	Receives, issues, returns, transfers and counts stock	Approving purchases
Principal	Academics, attendance and admissions; approves question papers; can read the rest	The most sensitive student-records settings
School owner	Everything

People can hold more than one job, and the roles are a starting point. Campus One gives each school its own editable copy of the role templates, so the office can adjust them to how it really works.

Keep asking and approving apart

The decisions that matter most should need two people: one who asks and one who approves. Campus One's defaults follow that rule in three places:

Fees. The accounts role records payments, but its default template cannot approve fee adjustments.
Purchases. The store administrator can request a purchase but cannot approve it. In the demo school, purchase requests are routed for approval by value, and the person who raised a request cannot approve it.
Question papers. Teachers can view a paper under review; only approvers can approve it.

Hiding a button is not a permission

Some software "removes" a feature by hiding its button. Anyone who finds the page's address, or reaches the function another way, can still use it. The safer rule is that every action checks permission on the server, every time.

In Campus One, every action passes the same checks, in order, before it runs: who you are; which school and campus you are working in; whether your role allows the action; whether the school has that product; and whether the input is valid. Only then does it run, and it is written to the audit record. Each login works inside an organisation, a campus and an academic year.

The same rule reaches the less obvious places:

Search. A member whose role cannot read student records gets no student results, even by typing an exact phone number, because the permission check is part of the search itself.
Recently viewed. Recent records are checked again when they are shown, so someone who loses access to fee records stops seeing them in their recent list.
Separation between schools. Each school's rows are kept apart in the database itself, by a rule on every table, which is designed so that one school cannot see another school's records.

The evidence: what the demo shows

The Campus One demo has a made-up school with a login for each role: school owner, principal, head of administration, academic head, teacher, accounts manager, operations manager and admissions counsellor. A walkthrough can show the same student from two logins, for example a teacher's and an accountant's, so you can see what each role sees and what it does not.

Both plans include unlimited staff logins, so nobody has to share a password to keep the bill down. The price is set per school by the number of students, as the pricing page shows.

This describes how the product is built. It is not a certification, a compliance claim or legal advice.

The outcome: every change has a name

When each person signs in as themselves, the question "who changed this?" has an answer, approvals sit with the people who should give them, and sensitive records stay with the people who need them. Our guide to audit trails in a school office shows what that history looks like for marks, receipts and stock.

The takeaway

List the jobs in your office, write down what each one needs, separate asking from approving, and ask every vendor whether permissions are checked on the server. The Campus One page for principals, the office and accounts teams shows how each desk uses its login, and our checklist for choosing school software covers the rest of the decision. To see two roles side by side on the demo school, ask us for a walkthrough.

School admissions pipeline: from first enquiry to admission

2026-10-05T00:00:00Z

The situation: admission season at the front desk

From the first week of admissions, the front desk takes enquiries from every direction: phone calls, walk-ins at the gate, referrals from current parents. Each is written in a notebook or a spreadsheet, a visit is promised, and a follow-up call is planned for "next week".

The tension: follow-ups that quietly disappear

The enquiries rarely go wrong at the start. They go wrong in the middle: a promised call is not made, a visit is booked but not recorded, an application waits for a document nobody asked for. By the time the school notices, the family has joined somewhere else. And when a child is finally admitted, the office types the family's details again into the student register.

The insight: admissions is a pipeline, and it ends in a record

The work becomes manageable when every enquiry is treated as one item in one pipeline, with a stage, an owner and a next step. The pipeline should also end where the rest of the school begins: admission should create the student record, so nothing is typed twice.

The decision: the stages, and what happens in each

Campus One uses the stages most schools already work with:

Enquiry. Capture who asked, for which class, and how they heard about the school. Qualify it and set the next follow-up.
Application. Start the application and check the documents as they arrive.
Visit and offer. Book the campus visit, record the decision and the offer.
Admission. Admit the child. This step is deliberate: on the pipeline board, enquiries can be dragged between stages, but admission is not a drag target.

Along the way, overdue follow-ups are flagged and the admissions view groups the enquiries at risk of being lost, so the team can act on them first.

The evidence: siblings, records and what happens next

When a new enquiry's phone number matches a family already in the school, Campus One shows that a sibling may already be enrolled. It does not merge anything on its own: the family record is reused only when a person admits the child. That keeps a shared phone number from joining two unrelated families.

Admission opens the student record: details, family, documents, attendance, academics, communication and admission history in one place. Missing or expiring documents appear as a list the office can work through. The admissions reports, including the funnel, the admissions register and lost-enquiry reasons, can be exported as CSV files.

All of this runs today in the Campus One demo with a made-up school. Two parts are not built yet: an import wizard for merging old records, and a one-step move of a whole class to the next academic year.

What to record at the first call

The first conversation sets up everything after it. A short, consistent record is enough:

the class the family is asking about;
how they heard about the school, so the school learns which sources bring families who join;
a contact number the family agrees to be called on;
the next step and its date, and who owns it.

Anything more can wait for the application. A shorter first record is more likely to be filled in on a busy morning.

Questions to ask about any admissions system

Does every enquiry have an owner and a next step with a date?
Are overdue follow-ups flagged without someone checking a notebook?
What happens when a new enquiry's phone number matches a family already in the school?
Does admission create the student record, or does someone type the details again?
Can the funnel and the reasons families did not join be exported?

Campus One's answers are in the sections above: owners and follow-ups in one pipeline, overdue follow-ups flagged, a sibling match shown as evidence and acted on only by a person, the student record created at admission, and the funnel and lost-enquiry reasons exportable as CSV.

The outcome: fewer lost families, no double entry

With every enquiry in one pipeline, the principal can see at a glance how many families are at each stage and which follow-ups are late. When a child is admitted, attendance, fees, marks and notices all start from the same record.

The takeaway

Write down your admission stages, give every enquiry an owner and a next date, and make admission the step that creates the student record. The Campus One admissions page shows how the product does it.

School fee management: instalments, receipts and follow-up

2026-10-05T00:00:00Z

The situation: the accounts counter in April

At the start of the year the accounts counter is the busiest desk in the school. Parents pay the first instalment, some ask about a sibling concession, and a few want to know why last year's balance is still showing. The accountant has a receipt book, a ledger and a spreadsheet of instalments, and each question means checking all three.

The tension: balances that depend on who you ask

When fee plans live in a spreadsheet and payments in a receipt book, the balance is whatever the last person to update the spreadsheet thought it was. A concession agreed in the principal's office may not reach the spreadsheet. A payment recorded on a busy day may be applied to the wrong instalment. The result is one of the most uncomfortable conversations a school has with a parent: a disputed balance with no clear record.

The insight: money should be arithmetic

The fix is not a smarter spreadsheet. It is a rule: balances are worked out from a ledger, never typed in. If the fee plan, every concession and every payment are recorded as entries, the balance, the ageing and the overdue list follow by arithmetic, and anyone can see how a figure was reached.

The decision: a fee process parents can follow

Set the plan once

For each student, set the fee plan: the instalments, their due dates and any concession. A concession becomes part of the plan, not a note in a margin.

Record payments against the plan

When a payment comes in, apply it to the oldest amount due first. That keeps the account easy to explain: what was paid, what it cleared, what remains.

Number every receipt

Every payment gets a receipt with a number from one sequence for the campus and the financial year, with no gaps. A missing number should be impossible, so it never needs explaining.

Follow up from the ledger

The overdue list should be generated from the same ledger, with how long each amount has been overdue. Follow-up is then fair: every family is chased by the same rule, and a payment promise is written down when it is made.

The evidence: what Campus One does today

Campus One's fee module is partly built. In the demo it does the following:

fee plans with instalments and concessions;
payments applied to the oldest amount due, with numbered receipts that run without gaps for each campus and financial year;
balances, ageing and the overdue list from the fee ledger, with no AI or estimate writing a balance;
follow-up and payment promises tracked for the accounts team;
importers for the fee roster and payment statements that check every row before saving.

What it does not do yet: online UPI payment is not connected, so payments are recorded by the office, and reminders are simulated, so nothing is sent to parents. When online payment is connected, the payment gateway's standard charges apply, as the price list says.

Questions to ask about any fee module

Are balances calculated from payments, or can someone type a balance?
Can a receipt number be skipped, repeated or reused?
Is a concession part of the student's fee plan, or a note somewhere else?
How is a payment split when several instalments are due?
Is online payment connected today, and what does it cost the school?
Are reminders actually sent to parents, or only planned?

Campus One's answers, in order: calculated from the ledger, never typed; receipt numbers run without gaps for each campus and financial year; concessions are part of the plan; payments go to the oldest amount due first; online UPI payment is not connected, and when it is, the payment gateway's standard charges apply; reminders are simulated, so nothing is sent.

A note on concessions

Concessions are a common source of disputes, because they are often agreed in conversation rather than on paper. Write down the concession types the school offers, who may approve each one, and record every concession in the student's plan on the day it is agreed. A concession that exists only in an email is a dispute waiting to happen.

The outcome: shorter conversations at the counter

With one ledger, the answer to "why is this balance showing" is on one screen: the plan, the concession, each payment and what it cleared. The accounts team spends less time reconciling and more time on the families who need a conversation.

The takeaway

Whatever system you use, make fees arithmetic: one plan per student, payments applied oldest first, gapless receipts and an overdue list from the ledger. You can read more on the Campus One fees page, including what is not connected yet.

School inventory and assets: stock, issue, return and audits

2026-10-05T00:00:00Z

The situation: the store room in June

Before a new term, the school store is busy: notebooks and uniforms are counted, lab glassware is checked, sports equipment comes back from the last term, and new purchases arrive. Meanwhile projectors, laptops and furniture have moved between rooms all year without much of a record.

The tension: the stock register says one thing, the shelf another

A stock register is accurate only if every movement is written in it. In practice, items are issued on a busy morning and noted later, a damaged item is thrown away without a note, and the "current stock" column is corrected by hand at the next count. When the yearly audit comes, the difference between the register and the shelf has no explanation.

The insight: stock is the sum of its movements

The reliable way to keep a store is to stop treating the stock figure as something you write down. Instead, record every movement: received, issued, returned, transferred, adjusted, damaged, lost. The current stock is then the sum of those movements, and any difference has a trail.

The decision: how a school store can run

Record movements, not totals

Every change to stock is a movement with a date, a quantity and a reason. Nobody edits the total.

Tag fixed assets

Projectors, computers and furniture each get a tag code. The code identifies the asset, never the person using it, so a label on a laptop does not carry a teacher's name. Assign the asset to a room or a person in the system, record its condition, and raise maintenance when needed.

Purchase in steps

A purchase moves through a request, a decision, a purchase order and the goods received note. When goods arrive, the receipt becomes a movement into stock.

Audit against the ledger

At audit time, count what is on the shelf and compare it with what the ledger expects. Each difference is recorded as an adjustment with a reason.

The evidence: what Campus One does

Inventory and assets are built in the Campus One demo:

current stock is worked out from recorded movements, with no field where someone types the stock figure, and stock is valued at its weighted average cost;
fixed assets can be registered, assigned, moved, given a condition, maintained and retired;
each asset tag is a code without a person's name, printed as a QR code and a barcode on a label from the browser;
purchases run from request and decision to purchase order and goods received note;
vendors, storage locations and audits have their own pages.

Two limits apply: labels print from the browser, so thermal label printers are not supported, and opening an asset by pointing a phone camera at its tag outside the app is not built yet. Inventory and assets are part of the Complete plan.

Loans: what is still out?

Schools lend as much as they consume: sports kit to a house team, lab equipment to a class, a laptop to a teacher for the term. The question at the end of term is always the same: what is still out, and with whom? Record every loan as an issue against the class, student or staff member, and every return against that issue, and the answer becomes a list rather than a search. In Campus One, issues are kept as records and taken back from a returns list, so what is still out is always visible.

Questions to ask about any inventory system

Is the current stock calculated from movements, or typed into a field?
Can you see what is still out on loan, and with whom?
Does an asset label carry any personal data?
Who approves a purchase, and can the person who requested it also approve it?
Does receiving goods update the stock by itself?

Campus One's answers: calculated, never typed; a returns list shows what is still out; tags carry a code, never a name; in the demo school the person who raised a purchase request cannot approve it; and receiving goods posts them into stock through the ledger with the goods received note.

The outcome: an audit with explanations

When every movement is recorded, the audit stops being a search. The difference between the shelf and the ledger is small, and each part of it has a date and a reason.

The takeaway

Record movements instead of totals, tag assets without names, run purchases in steps and audit against the ledger. The Campus One inventory page shows how the product does it.

School management software: a checklist for private schools

2026-10-05T00:00:00Z

The situation: one office, five kinds of paperwork

Walk into the office of a private school in March and you will see the whole year in one room. The admissions counsellor has a notebook of enquiries. The class teachers' attendance registers are stacked on a shelf. The accounts counter has a receipt book, a ledger and a spreadsheet of instalments. Report-card templates sit on one computer, and notices go out through printed circulars and a few WhatsApp groups.

Each of these works on its own. The trouble starts between them: the same student is written down in every book, a change in one is not seen in the others, and the owner who asks "how are we doing this term" gets five partial answers.

The tension: every vendor says "all-in-one"

Most school software is sold with a long list of modules. The list is rarely the problem. The problem is that a list does not tell you which parts work today, which are half built and which are a plan, and it does not tell you what happens to your data.

The insight: buy for the work, not the list

A useful way to choose is to start from the work your office does every day and check each part against it. The checklist below follows that order.

Admissions and student records

Can an enquiry move through application, visit and admission in one place?
When a child is admitted, does the record start from the enquiry, or is it typed again?
How does it handle a family that already has a child in the school?

Attendance

Can a teacher mark a whole class in one pass?
Does the monthly percentage divide by working days, with holidays left out?
What happens when a register is not taken?

Fees and receipts

Fee plans with instalments and concessions.
Numbered receipts that cannot skip a number.
An overdue list that comes from the ledger, not from someone's spreadsheet.
Whether online payment is connected today, and what it costs.

Marks and report cards

A marks grid with codes for absent or exempt students.
Grades worked out from your school's scale.
What happens when a mark is corrected after results are published.

Notices to parents

Can you see the exact recipient list before sending?
Are families who opted out left out automatically?
Is delivery real, or simulated, today?

The decision: ask for states, not promises

For every module on the list, ask the vendor to write down one of three states: built, partly built or planned. Then ask to see the built ones on a walkthrough with demo data. A vendor who cannot separate the three will not be able to tell you later why something does not work.

Ask two more questions before you sign:

Where will our data live? A school holds children's records. Find out which country the server is in and what moves before real data is loaded.
Who builds it and who answers? You want a company and a person you can call, not only a support form.

The evidence: how Campus One answers the checklist

We publish the same states for Campus One that we ask you to demand from anyone. Today, in the demo with a made-up school:

Module	State
Admissions and student records	Built
Attendance	Built
Exams and report cards	Built
Inventory and assets	Built
Exam paper generator	Built
Fees and receipts	Partly built: online UPI payment is not connected
Parent messages	Partly built: sending is simulated
Payroll, transport tracking, parent app, school website	Planned

The demo runs on a server in the USA with made-up data only; before any real school data is loaded, Campus One moves to a server in India. It is built by AskShiva Private Limited, whose leadership team is Divya Prakash Jha (Chief Executive Officer), Vaibhav Jain (Chief Operating Officer) and Zeeshan Khan (Chief Marketing Officer), and the contact page lists the phone numbers and email of a person who answers.

The outcome: a shorter, honest shortlist

Using the checklist usually shortens the shortlist quickly. Software that cannot show its built parts on demo data, or cannot say where the data lives, drops out. What remains is a comparison you can defend to your trustees: the same work, checked the same way, with the gaps written down.

Go deeper: one guide for each step

Each part of the checklist has its own guide, written the same way: the problem in a real office, the rule that fixes it, and what Campus One does today.

Admissions: the admissions pipeline, from first enquiry to admission
Attendance: counting working days right in the attendance register
Fees: instalments, receipts and follow-up at the fee counter
Marks: from the marks grid to the printed report card
Question papers: setting a paper from a blueprint that adds up
Notices: what to plan before sending notices on WhatsApp
The store: stock, assets, purchases and audits
Logins: who should see what in a school office
History: audit trails for marks, receipts and stock
Data: where a school's data should be stored
AI: where AI belongs in a school office, and where it does not
Alternatives: spreadsheets, accounting software or a school system
Price: what school management software costs in India
Moving: from registers and spreadsheets to one system
Trying it: a 30-day pilot plan, week by week

The takeaway

Choose school software by walking through your own office's day and asking, for each step, "is this built today?" Then look at the Campus One product page, where every part carries its state, and ask us for a walkthrough on the demo school.

What school management software costs in India, explained

2026-10-05T00:00:00Z

The situation: a budget line nobody can compare

When a school owner asks three vendors for a price, the answers rarely line up. One quotes per student per month, one per login, one a lump sum with "implementation" on top. Add GST in one quote and not in another, and a sensible comparison becomes guesswork.

The tension: the cheapest quote is not the cheapest year

A low monthly figure can grow quickly once you count every teacher's login, the parent messages, the set-up fee and the report-card template your school actually uses. Equally, a plan that lists twelve modules is only worth what those modules do today.

The insight: price follows the size of the school

Most of the work in a school office grows with the number of students: more admissions, more fee accounts, more registers, more report cards. That is why a price per school, set by student count, is the easiest model to budget and to compare. It also means staff logins do not need to be rationed: both Campus One plans include unlimited staff logins.

The decision: how Campus One is priced

Campus One has one yearly price per school, by number of students, in two plans:

Essentials runs the office and parent communication.
Complete adds staff and payroll, inventory, transport, the exam paper generator and the AI office assistant.

These are the owner's prices, copied from the price list. All are per school per year, in Indian rupees, and exclude GST at 18%.

Students	Essentials	Complete
Up to 300	₹18,000	₹30,000
301 to 700	₹30,000	₹50,000
701 to 1,500	₹48,000	₹85,000
1,501 to 3,000	₹75,000	₹1,40,000
School groups and 3,000+	On request	On request

Three add-ons are listed:

Set-up and data import: free with yearly prepayment, covering import from registers or spreadsheets, configuration and online training.
Extra WhatsApp messages: ₹0.25 per message beyond the yearly allowance in the plan.
Custom report-card template: ₹5,000 per template. Bus GPS hardware is quoted separately.

The price list also says: 10% off for two years paid in advance; online fee payments carry the payment gateway's standard charges; prices are valid for agreements signed by 31 March 2027.

The evidence: what is built, next to what is priced

Here is the part most price lists leave out. Several modules named in these plans are not built yet. In Campus One today, online UPI payment is not connected, parent messages are simulated, and payroll, transport tracking, the parent app and the school website are planned. The AI office assistant named in the Complete plan is not built.

That is why the pricing page shows a state next to every module the plans name, and why founding schools pay only for modules that are ready to use. Founding schools also get 50% off the first year, today's price locked for three years and a 30-day free pilot before any payment.

Questions to ask before you sign

Whichever vendor you choose, ask these in writing:

Is the price per school, per student or per login, and what happens when the school grows past a band?
What exactly does set-up include, and is it charged?
Are the prices with or without GST?
What will the price be in years two and three?
Which of the modules in my plan are built today, and which are planned?
What do online fee payments cost the school, and who pays the charges?
Can we export our data as files if we leave?

For Campus One, most answers are on this page and the pricing page: one price per school by student band; set-up and data import free with yearly prepayment; GST at 18% extra; founding schools have today's price locked for three years; a state shown next to every module; the payment gateway's standard charges on online payments; and the standard reports export as CSV files.

The outcome: a comparison you can put in front of trustees

To compare any two quotes fairly, write each one as a yearly figure for your student count, add GST at 18%, add any set-up or template fees, and then cross out every module that is not built today. What remains is the price of the software you would actually use this year.

The takeaway

Ask every vendor for a yearly price for your number of students and a list of modules with their state. For Campus One, the bands are on the pricing page, and the founding schools programme explains the first-year terms.

Who changed this mark? Audit trails for a school office

2026-10-05T00:00:00Z

The question that arrives a week later

A parent says the mark on the report card is lower than the one the teacher read out in class. An accountant finds two receipts that seem to carry the same number. The store register says twelve projectors, and the yearly count finds eleven.

Each of these questions arrives days or weeks after the change that caused it, and each has the same first step: find out what happened, when, and who did it.

Why registers and spreadsheets lose the history

Paper keeps history in a rough way: a crossed-out mark is at least visible, even if nobody wrote down why. A spreadsheet passed around as a file usually keeps none: a corrected cell simply holds a new value, and the old one is gone. In both cases the reason for a change lives in someone's memory, and memory is exactly what is missing when the question arrives.

The principle: never overwrite, always add

A record you can trust is one where changes are added, not written over. A correction is a new entry with a name, a time and a reason. Totals, such as a balance, a stock figure or an attendance percentage, are worked out from the entries, so they can always be worked out again. And anything that has been handed to a family, such as a published report card, a receipt or a printed paper, stays exactly as it was handed over.

This is our guide to what that looks like in each corner of a school office, with the way Campus One does it. It follows on from our guide to role-based logins: an audit trail only works when each person signs in as themselves.

How Campus One keeps the history

Every record has a timeline

Actions in Campus One write entries on the record's timeline, with who did it and when, and the timeline is designed to include actions taken by an automation or by AI. Timeline entries are added, never edited.

Attendance

Once a register is locked, a correction needs a reason, and the reason stays on record with the change. A register that was never taken is not hidden: it still counts as a working day, and the register shows it was not marked.

Marks and report cards

Each cell in the marks grid carries a version. If two people change the same cell, the second save is refused instead of silently overwriting the first. When results are published, each report card becomes a fixed copy; a later correction is issued as a new copy.

Receipts

Receipt numbers come from one sequence for each campus and financial year, with no gaps. Two cashiers recording payments at the same moment queue for the next number instead of colliding, and a payment that is rolled back before it is saved gives its number back, so no gap appears. The product's own tests prove the rule under pressure: twelve payments posted at the same moment produce a continuous run of receipt numbers, with no holes and no duplicates.

Balances are worked out from the ledger rather than typed, and a payment is applied to the oldest amount due first, so any balance can be explained payment by payment.

Stock and assets

Current stock is the sum of recorded movements: received, issued, returned, transferred, adjusted, damaged or lost. The movement ledger only grows, and the database itself refuses to let the application edit or delete its rows. There is no field anywhere where someone can type the stock figure. Fixed assets keep their assignments, moves, condition and maintenance, so a missing projector has a last recorded movement.

Question papers

Locking a paper records a fingerprint of its content, so any later edit can be detected. The paper keeps its own copy of every question, so editing the question bank later never changes a paper that was printed, and each edit to a question is saved as a new version. Every print is recorded, and the printed copy carries a confidentiality line with the viewer's name and the time.

Admissions

Each change of stage is written to the enquiry's history. When a new enquiry's phone number matches an existing family, the match is shown as evidence; the family record is joined only when a person admits the child, and that step is recorded too.

A rule above the features

Two lines in Campus One's engineering rules sum up the approach: records are archived rather than deleted, and a closed academic year is never changed.

What an audit trail does not do

An audit trail does not decide who was right. It gives the principal the facts in order, so the conversation with a parent, an accountant or an auditor starts from the record rather than from memory. It is also not a certification. This describes how the product is built, not a compliance claim or legal advice.

The outcome: questions answered from the record

Go back to the three questions at the start. The disputed mark has a history in the grid and a fixed published copy. Two receipts cannot carry the same number. The missing projector has a last recorded movement and the name of the person who recorded it. None of the answers depends on anyone's memory.

The takeaway

Before you buy any school software, ask the vendor to show the history of one record: a mark corrected after publishing, a cancelled payment, a stock adjustment. If they cannot, the history is probably not there. Our article on where school data should be stored covers the other questions to ask, and the Campus One fees page shows the receipt and ledger rules in the product. To see a record's history on the demo school, ask us for a walkthrough.

How to run a 30-day pilot of school management software

2026-10-05T00:00:00Z

When the walkthrough is over

A good demo answers one question: could this software run our office? It cannot answer the next one: will our people actually use it on a busy Monday, with the phone ringing and a queue at the fee counter? That is what a pilot is for.

Why pilots drift

Many pilots end without a clear answer. The software is set up, a few people sign in during the first week, and then the old registers win, because nobody decided what the pilot was meant to prove or when the decision would be made. Thirty days pass and the honest verdict is "we did not really try it".

Often the software was never really the question: the pilot had no plan.

A pilot is a test plan with a date

Treat the pilot as a short test plan: a list of tasks each desk must do in the new system, a way to check the results against what you already know, and a decision meeting on a fixed date. Everything below follows from that.

Before day one

Decide the scope. Choose the modules, the classes and the desks. A pilot of two or three classes and one fee desk, done properly, teaches more than a half-hearted pilot of everything.
Name two owners. One person at the school decides; one person at the vendor answers.
Write a success test for each desk. For example: teachers mark attendance in the system on every working day; the accounts counter issues every receipt from the system; the front desk records every new enquiry.
Ask the data questions first. Where will the pilot data be stored, who can see it, and what happens to it if you decide not to continue?

Week 1: set-up and logins

Import the student list, staff and fee plans for the pilot classes, then check a sample of records against the registers.
Give each person their own login. No shared passwords, even for a pilot: our guide to role-based logins explains why.
Train each desk on its own work, not on every screen.

Check at the end of the week: can every person in the pilot sign in and find their own work without help?

Week 2: the daily work

Teachers of the pilot classes mark attendance in the system every working day.
The front desk records each new enquiry and its next follow-up.

Check: compare the system's monthly attendance for the pilot classes with the paper register. If they differ, find out why: it is often a rule, such as how a half day or a holiday counts, that the school had never written down.

Week 3: money and marks

The accounts counter records the week's payments and issues receipts from the system.
If a unit test falls inside the pilot, enter the marks in the grid and print a report card for checking.

Check: does the overdue list match what the accountant believes is owed? Can any balance be explained from the ledger, payment by payment?

Week 4: reports, exports and the decision

Run the reports the principal actually reads.
Export data as files, to prove you can get it out.
Ask each desk for three lists: what worked, what had to change, what is missing.

On day 30, decide: continue, extend with one named fix and a new date, or stop.

What to count

Count things you can check yourself: on how many working days attendance was marked in the system, how many receipts were issued from it, how many corrections had to be made, and how many questions each desk could not answer from it. Be wary of percentages supplied by anyone else, including us.

How a Campus One pilot works

These are the terms and steps from the Campus One price list and brochure:

A 30-day free pilot before any payment, for founding schools.
It starts with a walkthrough of about 45 minutes, followed by a written plan of the modules your school needs first.
Set-up: the team imports student, fee and staff lists from your registers or spreadsheets and trains the office and teachers. Set-up and data import are free with yearly prepayment.
Modules go live in phases, each one as it is ready.
After the pilot, founding schools pay only for modules that are ready to use, with 50% off the first year and today's price locked for three years. Prices are in Indian rupees and exclude GST at 18%.

What there is to test, honestly: admissions and records, attendance, exams and report cards, inventory and the exam paper generator are built; fees work without online UPI payment; parent messages are simulated, so nothing reaches parents; payroll, transport tracking, the parent app and the school website are planned. The admissions reports export as CSV files, and the fee importers let you download the rows that failed, fix them and import them again.

One more point matters before any pilot on real records. Campus One runs today with a made-up demo school, and real school data is loaded only after it moves to a server in India. The timing of a pilot on your own records depends on that move, so ask us about it for your school.

The takeaway

Agree the scope, the owners, a success test for each desk and the decision date before day one, and count only what you can check. The founding schools page sets out the Campus One terms, how it works shows the set-up steps, and our checklist for choosing school software helps you decide what to pilot in the first place. When you are ready, ask us for a walkthrough and a written plan.

Spreadsheets, accounting software or a school system?

2026-10-05T00:00:00Z

The question behind the question

When a school owner asks whether to buy school software, the real question is usually narrower: is what we use now good enough, and if not, what exactly is it failing at? Most school offices already run on a mix of tools. There are paper registers, a few spreadsheets, an accounting package for the school's own books, and chat groups for parents. Each was chosen for a reason, and each does its own job reasonably well.

This guide compares them honestly, including the cases where a school system is not the answer. It is part of our checklist for choosing school software.

What each tool does well, and where it struggles

The notes below are our editorial reading of how each kind of tool is usually used in a school office. They are not a test of any named product.

Paper registers

Good at: everyone knows how to use them, they need no power or login, and a bound register shows every crossing-out.

Struggles with: totals are added up by hand, there is one copy, and one student's history is spread across several books on several shelves.

Spreadsheets

Good at: flexible, cheap and familiar. A spreadsheet that one person owns, such as a class list or a list of enquiries, works well.

Struggles with: in an office, copies multiply. The accounts counter has one version and the front desk another, a typed number can replace a formula without anyone noticing, and a file passed around by email keeps no record of who changed which cell.

Accounting software

Good at: the school's own books: ledgers, vouchers, bank entries and tax. Many schools rightly keep it for that.

Struggles with: it is organised around accounts and vouchers rather than students, classes, registers and report cards, so the fee desk often keeps a separate list of which family owes what.

Chat groups

Good at: instant, free, and parents are usually already in the group.

Struggles with: there is no record of which family received a notice, no simple way to leave out a family who asked not to be messaged, and a notice depends on someone forwarding it.

A school management system

Good at: one record per student that admissions, attendance, fees, marks and notices all read; a login for each person; a history of changes kept by the system.

Struggles with: it costs money every year, setting it up takes effort, the school depends on a vendor, and the school has to find out where its children's records will be stored.

Side by side

What the office needs	Paper register	Spreadsheet	Accounting software	Chat group	School system
One student record every desk reads	No	Only if one shared file is kept	No	No	Yes, by design
Attendance percentage against working days	By hand	With formulas	Not its purpose	No	Should be built in
Fee balance worked out from payments	By hand	Only with care	For the school's books	No	Should be built in
Record of who changed what	Visible crossing-out	Limited	For vouchers	No	Should be built in
Notice recipients and opt-outs	No	By hand	No	No	Should be built in
Set-up effort	None	Low	Medium	None	Highest

"Should be built in" is deliberate: it is what you should ask any school system to show you on demo data, not a promise about all of them.

When a spreadsheet is enough

A small school where one person runs admissions and fees, attendance is kept on paper and the owner is in the office every day may be well served by a clean spreadsheet and a numbered receipt book. Software would add a yearly cost and a set-up project to solve a problem the school does not yet have.

The picture changes as more people need the same information. When the front desk, the accounts counter, the class teachers and the principal each keep their own version of the same student, every change has to be made several times, and the office spends part of every month reconciling copies.

Where a school system earns its place

The value of a school system is not any single module. It is that the desks stop keeping separate copies. Three things a shared system does that the other tools struggle with:

One student record that every desk reads, so a change is made once.
Arithmetic nobody types over: attendance percentages, fee balances and mark totals worked out from the entries.
A history kept by the system: who did what, and when, without relying on memory.

How Campus One fits, and where it does not

Here is how Campus One answers the rows above in its demo with a made-up school:

One record. Admission creates the student record, and attendance, fees, marks and notices start from it.
Attendance. The monthly register divides by working days, with fixed weights: present and late count as one day, a half day as half, absent and approved leave as zero.
Fees. Balances, ageing and the overdue list come from the fee ledger; payments are applied to the oldest amount due first, and receipts are numbered without gaps for each campus and financial year.
History. Each person has their own login, and actions are recorded with who made them and when.
Notices. The recipient list is built from student records and shown before sending, and families who opted out are left out automatically.

And where it does not fit today:

Campus One runs with a made-up demo school. Real school data is loaded only after it moves to a server in India.
Online UPI payment is not connected, and parent messages are simulated: nothing is sent to parents.
General accounting, meaning the school's own books, vouchers and tax returns, is not among its modules. Keep your accounting software for that.
It costs a yearly fee per school, set by the number of students; the bands are on the pricing page.

The takeaway

Before you compare vendors, write down which desks keep their own copy of the same student and how much time corrections take each month. If the answer is "hardly any", keep your spreadsheet and revisit the question next year. If it is "every desk", read how to move from registers and spreadsheets to one system and look at the Campus One product page, where every module carries its state. A walkthrough on the demo school is the quickest way to check the rows above for yourself.

Where should a school's data be stored? A guide for owners

2026-10-05T00:00:00Z

This article is general information, not legal advice. For your school's obligations, speak to a lawyer.

The situation: software that knows every child

A school's office software holds a great deal about its students: names, dates of birth, family contacts, documents, attendance, marks, fees and the notices sent home. Moving that from paper registers into software is useful, and it raises a question owners do not always ask early enough: where will all of it live?

The tension: convenience now, questions later

Many decisions about software are easy to change later: a report layout, a fee template, a role. The location of the data is not one of them. Once real records are loaded, moving them is a project. And when a parent, a trustee or an inspector asks where the school's data is kept and who can see it, "the vendor handles it" is not an answer.

The insight: location, access and records are three separate questions

It helps to split the subject into three questions and ask each one directly:

Location. Which country is the server in, today and when real data is loaded?
Access. Who at the school can see which records, and who at the vendor can see them? Are permissions checked on the server, or only by hiding buttons on the screen?
Records. Is there a record of who changed what, and when?

The decision: questions to ask any vendor

Where is the server, and does that change before real data is loaded?
Does each member of staff get their own login, and does each role see only what it needs?
Are permissions checked again on the server for every action?
Is one school's data kept apart from another's in the database itself?
Is there a history of changes with the person and the time?
Can we get our data out as files?
Does any part of the product send our data to an AI service, and if so, which part and why?

Ask for the answers in writing, and keep them with the agreement.

The evidence: how Campus One answers today

Location. Campus One runs today with a made-up demo school on a server in the USA, and holds no real school, student, parent or teacher data. Before any real data is loaded, Campus One moves to a server in India.
Access. Each member of staff has their own login, and each role sees only what it needs. Every action checks permission again on the server; hiding a button on the screen is never the only guard.
Separation. Each school's records are kept apart in the database itself, with a rule on every table.
Records. Admissions steps, register corrections and published report cards are recorded with who made them and when.
Export. The standard reports can be exported as CSV files.
AI. The exam paper generator may use AI to help choose questions from the school's own bank and never writes question text; the AI office assistant named in the Complete plan is not built.

This describes how the product is built. It is not a certification or a compliance claim. Campus One is built by AskShiva Private Limited.

What to keep on file at the school

Whatever the answers, keep a short record at the school, next to the agreement:

the vendor's written answers to the questions above, with the date;
the name of a person at the vendor who answers data questions;
the result of a test export: which files came out and whether they opened;
the date of any change the vendor announces, such as a move of server.

Review it once a year, or whenever the vendor changes something. When a trustee or a parent asks, the school can answer from its own file instead of waiting for the vendor.

The outcome: an answer you can give a parent

With the three questions answered, a school can explain its arrangements in plain words: where the records are, who can see them, and how changes are tracked. That is the conversation parents and trustees expect.

The takeaway

Ask every vendor about location, access and records before any real student data is loaded, and get legal advice on your own duties. The Campus One questions page repeats our answers in short.