Resources
Make better school software decisions
Start with the format that matches your question: current operator thinking, detailed implementation guidance, product reference, or practical tools.
Choose your next step
Resources for every stage of a rollout
Use the blog for perspective, guides for decisions, docs for product detail, and tools for action.
Operator notes
Product blog
Current operator notes, product perspectives, and school software lessons.
Use it when: you want a point of view on a current problem and are still deciding whether it is worth a project.
Explore product blogEvergreen guides
Guides and playbooks
Evergreen buyer guides, checklists, and implementation frameworks.
Use it when: you have a decision to make and need the trade-offs, sequence, and questions laid out in full.
Explore guides and playbooksProduct reference
Documentation
Product reference for roles, workflows, configuration, and rollout.
Use it when: you are configuring Schoolyi, or verifying during evaluation exactly how a workflow behaves.
Explore documentationPlanning artefacts
Tools and checklists
Interactive helpers and practical checklists for school operations.
Use it when: you need to produce something a colleague or vendor can act on: a scope, a map, a plan.
Explore tools and checklistsDefinitions
Glossary
Plain-language definitions for school software and operational terms.
Use it when: a vendor, tender document, or colleague used a term and you want the meaning without the marketing.
Explore glossaryMarket reference
School reference directory
School profiles by country, curriculum, type, and enrolment band.
Use it when: you want market context on comparable schools, or are looking for a reference similar to your own.
Explore school reference directory
Selection guidance
Where you are in the decision changes what you should read
Reading in the wrong order is the most common reason a school ends up with a long requirements document and no clearer decision.
Stage 1 — Framing
Is this actually a software problem?
Plenty of school pain attributed to software is really a process or ownership problem that new software will preserve at higher cost. Before scoping a platform, it is worth naming the specific task that is expensive, who does it, how often, and what makes it slow.
Read for perspective at this stage rather than for requirements. The goal is to decide whether to open a project at all, and a blog post that describes your problem accurately is more useful than a feature comparison you are not ready to act on.
Start here
- Product blog — operator notes on where school workflows commonly break
- Workflow journeys — see the full chain your problem sits inside before scoping it
- Glossary — settle terminology before it enters a requirements document
Stage 2 — Scoping
What are we actually buying, and for whom?
This is where most evaluations go wrong, usually by producing a long feature list assembled from vendor websites. A list like that invites every vendor to answer yes, and it hides the differences that determine whether a rollout succeeds.
Scope by role and by workflow instead. Name the people whose daily work changes, the chains of work that must survive the handoff between them, and the exceptions your school actually encounters. Then read the guides that go deep on those specific decisions.
Start here
- Guidance by role — build an evaluation panel and a permission model at the same time
- Guides and playbooks — full treatment of the trade-offs behind each scoping decision
- Planning checklists — turn the reading into a scope document a vendor can answer honestly
Stage 3 — Comparing and verifying
Can this vendor do our awkward cases, and can we trust them with student data?
By this point the shortlist should be small and the questions should be specific: the mid-term transfer, the concession applied after invoicing, the corrected result on a published report card, the staff member holding two roles.
Verification runs alongside capability. Where is data hosted, who at the vendor can reach production, what is in the processing agreement, and what happens to your records if you leave. Ask for artefacts rather than assurances.
Start here
- Buyer comparisons — the questions that separate platforms once feature lists match
- Trust and procurement — convert security assurances into checkable, contractable specifics
- Evidence and references — read case studies for scope rather than for headline numbers
Stage 4 — Implementing and operating
How do we go live without losing a term?
Implementation is a data problem before it is a software problem, and a calendar problem before it is a training problem. Data readiness, a go-live date chosen from the academic year rather than the project plan, and named support through the first full cycle of each recurring task account for most of the difference between a smooth and a painful rollout.
Once live, documentation replaces guides as the primary reference, because the questions shift from what should we do to how is this configured.
Start here
- Implementation guides — data readiness, calendar windows, training, and support sequencing
- Documentation — exact configuration behaviour for the workflow you are setting up
- Academic calendar setup — the calendar drives working days, holidays, and attendance downstream
Resource library FAQ
How these libraries differ, how current they are, and what they deliberately avoid.
What is the difference between the Schoolyi blog and the guides?+
The blog carries current operator perspective and is written to be read once: a problem, a view, a recommendation. The guides are evergreen reference material, structured around a decision, and maintained as the product and the market change. If you are deciding whether something matters, read the blog. If you have decided it matters and need to act, read the guides.
Do I need a Schoolyi account to use these resources?+
No. The blog, guides, documentation, glossary, checklists, and reference directory are all public and require no account. The planning tools collect planning choices only and never ask for student or guardian data.
How current is this material?+
Guides and documentation carry a last-reviewed date and are revised when the product or the underlying regulation changes. Blog posts are dated and left as written rather than quietly edited, so a post from an earlier release stays honest about when it was true.
Are these resources only useful if we choose Schoolyi?+
The comparison, trust, and implementation material is written to be useful regardless of which platform you choose, including where it points out requirements Schoolyi does not meet. The documentation is Schoolyi-specific by nature.
Where should a school with no software at all start?+
Start with one workflow journey and one role page for the person who owns the most manual work, usually fees or admissions. Scoping a whole-school platform from nothing tends to stall; scoping one chain of work end to end produces a decision you can act on this term.
Can we reuse this material in our own tender documents?+
Yes. The checklists and question sets are written to be edited and reused in a procurement process, and a version adapted to your school’s constraints is more useful than one used as issued.
Prefer a conversation to a reading list?
Bring your current workflow, the term you want to go live, and the two tasks costing your team the most time.
Already using Schoolyi? Sign in