If your master schedule lives in a workbook, you have already done the hardest part — you structured the data. nOS reads that workbook and takes it from there.
Conditional formatting will turn a cell red when a teacher is double-booked — that is validation, and Excel is good at it. But finding the arrangement that satisfies every constraint at once is a search problem, and a spreadsheet has no mechanism for searching. You do that by hand, one move at a time, and the workbook grades the move afterwards.
So the workbook never proposes anything. It can only check what you already thought of.
The workbook records the answer, not the argument. Six months later nobody can reconstruct why AP Chemistry ended up in fourth period, including whoever put it there. When that person changes roles, the method leaves with them.
Spreadsheet error rates are one of the better-studied topics in information systems, and the findings are consistent across decades. Ray Panko's summary of the field, presented at the European Spreadsheet Risks Interest Group conference, gathers them.
These studies examine spreadsheets across every field — financial models, budgets, operational workbooks. The finding that transfers is the mechanism: careful people produce errors at a low but non-zero per-cell rate, large workbooks therefore almost always contain at least one, and review catches roughly half of them.
A scheduling workbook is large, formula-heavy, and revised under deadline pressure. It sits squarely in that pattern.
| Excel or Google Sheets | nOS | |
|---|---|---|
| Holding your data | Excellent. Flexible, familiar, no vendor in the middle. | Imports the workbook you already have. You can keep using Excel to prepare data. |
| Finding a valid schedule | You do the searching by hand; the sheet validates afterwards. | A solver places thousands of course requests in minutes, conflict-free. |
| Trying a different approach | Duplicate the file and rebuild. Usually not worth it, so it does not happen. | Save runs as scenarios, compare them side by side, promote the winner. |
| Catching conflicts | Conditional formatting catches what you thought to write a rule for. | Double-booked teachers, room overlaps and constraint violations flag as they occur. |
| Explaining an unmet request | You work it out manually, if anyone asks. | Every unfilled request carries the specific reason it could not be placed. |
| Working with a colleague | Sheets is genuinely good at this. Emailed .xlsx files are genuinely not. | One shared school account — same schedules, same notes, same staged changes. |
| Getting it into your SIS | Manual re-entry, or an import file you format yourself. | Publishes back to the SIS on supported connectors. See the list. |
| Cost | Effectively free, if you do not count the weeks. | $8 per enrolled student per year. Pricing. |
Rows chosen because they decide the outcome of a build, not because of who wins them.
There is no rebuild step. You upload the workbook you already maintain.
nOS reads spreadsheet workbooks directly. You do not need to reshape your columns into someone else's template first.
Before anything is built, nOS surfaces the problems that live in every real workbook — duplicate course codes, requests referencing courses that no longer exist, teachers with impossible loads, blank fields where a value is required. You fix them in place, with undo.
Type "keep AP Bio in period 3" or "no more than two APs per student per day" and nOS compiles it into a solver constraint. There is no formula syntax to learn and no dictionary of codes.
Run it. Then run it again against a different optimization goal and put the two side by side before you commit to either.
Student schedules, section summaries, class rosters, teacher schedules, room schedules and unfulfilled requests all export as CSV, Excel or print-ready PDF. Your data does not become hostage to the tool.
Excel itself. Plenty of schools keep using a workbook for the things spreadsheets are best at — collecting course requests from department heads, sketching next year's course catalogue, budget modelling — and use nOS for the build. That is a perfectly good arrangement, not a transitional state.
The live demo runs the full product on sample data with no signup and nothing to install — useful for seeing the Data Cleaner and the results breakdown before you decide whether to send anything real.