Choosing school safety software with a realistic demonstration

A polished demonstration can make every task appear straightforward. The supplier knows the example, the records are complete and the usual reviewer is always available. Schools need to see how the proposed system handles their less tidy working day: a teacher reports an unclear location, a document arrives with the wrong scope or the colleague responsible for review is absent. Those examples make a product discussion much more useful.

Begin with the school's approved responsibilities and information arrangements. For England, the Department for Education's school data protection guidance is a primary reference for information sharing. Use the applicable local framework and your responsible advisers for specific requirements. A demonstration can provide evidence about a product; it cannot independently establish that the school's use will meet every obligation.

Write down the work before the feature list

Choose several tasks that cause real friction. Trace each from the first report or request to the final review. Identify who acts, what information they need and where the handover currently fails. This gives the supplier a concrete process to demonstrate rather than a list of broad labels such as easy reporting or better visibility.

Include an ordinary task and an exception. For inspections, the ordinary task might be recording a finding and assigning follow-up. The exception could be an inaccessible area or a task requiring a different decision maker. A product that handles the happy path well may still leave the school relying on email for the difficult part.

Use fictional information and representative locations. Do not give the supplier real pupil case details simply to make the example realistic. You can reproduce the structure and access requirements of the work without exposing a child's information. Agree the test data and participant roles before the session.

Separate essential requirements from preferences

Identify what the school must be able to do under its approved arrangements, what would materially improve work and what is merely convenient. Explain the reason behind each important requirement. A supplier can give a clearer answer when it understands the task the feature is intended to support.

Keep requirements specific enough to test. Needs restricted access is too broad. Describe which fictional role should be able to submit, review, edit or see a particular type of record. Then ask the supplier to demonstrate those differences and explain any configuration required. Record unanswered questions instead of assuming a suitable arrangement exists.

Include usability for occasional users. A teacher who reports a concern once a month may have different needs from an administrator working in the system daily. Ask representative staff to observe or try the relevant task through an agreed evaluation process. Their hesitation can reveal terminology or navigation that a product specialist no longer notices.

A shared fictional scenario helps staff compare demonstrated behaviour with their actual requirements. Photo: Kampus Production / Pexels.

Follow the record through the whole process

Ask the supplier to begin with a new record rather than only showing a finished dashboard. Watch how the finding reaches an owner, how the owner adds progress and how the result is reviewed. Ask what happens when the owner changes or a deadline is missed. The handover often matters more than the appearance of the initial form.

Distinguish product behaviour from a presenter's manual workaround. If the supplier changes a configuration during the session, ask who would perform that task in ordinary use and what permissions or support would be needed. Configuration can be entirely reasonable, but the school should understand the effort and responsibility involved.

Ask how records remain connected after correction or reassignment. A readable history helps the next colleague understand what happened. Use a fictional duplicate report or a corrected time to explore the process. Avoid requesting a particular technical mechanism when a clearer explanation of the required outcome would allow a better discussion.

Explore information handling beyond the main screen

Ask about exports, attachments, notifications and reporting audiences. A restricted screen does not tell you what appears in an email or downloaded file. Have the supplier explain the relevant behaviour and identify anything that needs separate technical confirmation. Keep those answers linked to the requirement they address.

Discuss migration using a small, representative sample of fictional or appropriately prepared records. Consider old identifiers, incomplete dates and documents with unclear ownership. Ask how the supplier proposes to handle those conditions and what work remains the school's responsibility. A promise to import a spreadsheet does not answer every question about the resulting information.

Include the end of the relationship. Ask what data and documents the school can obtain, in what form and through which process. The relevant terms and technical details should be reviewed by the school's appropriate procurement and information leads. Do not leave this until the school needs to move systems.

Migration and retrieval questions should include imperfect records and supporting documents. Photo: João Jesus / Pexels.

Keep an evidence-based decision record

After the session, classify each requirement as demonstrated, explained but requiring confirmation, dependent on configuration or unanswered. These distinctions prevent enthusiasm from turning into an inaccurate statement of capability. Give the supplier a focused list of remaining questions and agree who will review the response.

Compare options against the same tasks and assumptions. If one demonstration used a prepared workflow and another began from an empty account, note the difference. Consider implementation effort, staff support and ongoing administration alongside the visible features. The right decision depends on whether the school can operate the arrangement consistently.

Plan an appropriate trial or further evaluation where needed. Give it clear tasks and a defined review point rather than asking staff whether they generally liked the software. Record what worked, what was confusing and what remains unverified. A modest pilot can produce better evidence than several additional presentation slides.

Ask for a clear answer to each remaining question

Keep follow-up questions tied to the scenario and requirement. A supplier's general security or reporting statement may be useful background, but it should not replace an answer about the specific behaviour the school needs. Ask for a demonstration, documentation or written clarification appropriate to the question, and have the responsible school lead assess the response.

Record assumptions about licences, configuration, support and the version demonstrated. If a capability depends on an additional arrangement, make that visible in the comparison. This prevents a later implementation team from discovering that a feature discussed during evaluation was outside the agreed scope.

Finish the evaluation with an honest list of confirmed capabilities and remaining uncertainties. The school can then decide whether further work is needed before purchase through its normal procurement process. A clear unanswered question is more useful than a favourable score that quietly assumes the answer will turn out as hoped.

Explore CerthixED using your own scenarios for Inspections, Incident Management and Safeguarding. Read Safeguarding record access for questions to resolve before assessing sensitive case workflows.