Product guides
What a weekly review of school management, ERP, and SIS
A weekly school software review should focus on exceptions, ownership, data quality, permissions, support questions, and the next safe decision.
Review the exceptions first
A weekly review should not become a tour of dashboards. Start with unresolved exceptions that affect identity, access, fees, attendance, assessment, reports, or family communication. Ask what happened, who owns the correction, and what decision is needed.
A practical weekly agenda
Keep the meeting short and evidence-led. Bring the people who can resolve the work rather than every stakeholder for every item.
Begin with the oldest unresolved item and end with the item that can affect the next school deadline. This keeps the review connected to decisions and gives owners a reason to bring usable evidence rather than general status updates.
- Data quality: duplicates, missing values, stale contacts, and reconciliation issues.
- Permissions: new staff, leavers, role changes, and temporary access.
- Workflow: blocked handoffs, failed approvals, and repeated manual work.
- Support: recurring questions that indicate training or product gaps.
- Change: configuration requests, tests, owners, and hold decisions.
Use a decision log
Record the issue, evidence, owner, decision, due date, and review date. Do not allow a meeting note to say only “follow up.” A named next action makes the review useful when the original participants are unavailable.
Keep unresolved product, privacy, or security questions visible. Do not turn an unknown into an accepted risk without an owner and an explicit approval.
End with one improvement
Choose one small process or training improvement to test during the next week. Review its result at the next meeting. A weekly rhythm works when it closes loops instead of creating another recurring list of concerns.
Carry unresolved items forward with their owner and decision date. Close an item only when the person responsible confirms the result, not when the meeting has moved to the next agenda line.
If an exception repeats, assign a root-cause action rather than asking support to resolve it forever.
If an exception repeats, assign a root-cause action rather than asking support to resolve it forever.
