Concept screen or real feature in a school demo?

What are the four states a demo screen can be in?

Treat every screen in a school platform demo as being in one of four states: released in this offer, configured for the demo, an illustrative concept, or planned with a date. The state describes what the school would receive if it accepted the offer on the table, not whether the vendor is honest. Only the first can be relied on without a written commitment, and only once its evidence is in hand.

Released in this offer

It exists today in the edition and package being quoted and is generally available (GA), meaning on general sale, so another school on that package would have it.

Configured for the demo

The function exists, but in a setup prepared for this meeting: records and settings the vendor arranged for this scenario, one role, a feature switched on for the demo account only, or settings from a higher tier than the one quoted. Ask what it takes to reach the same screen in the school's own setup, whether that work is inside the quoted price, and whether the answer is an upgrade.

Illustrative concept

A mockup or prototype of an intended experience. It shows how the vendor is thinking; it is not evidence that any working software does this. A plan with no date belongs here too until it has one.

Planned, with a date

Roadmap work not yet in the package being quoted, including a test (beta) or early-access version offered to a few customers. Useful only with a target release period in writing.

These are the same four labels that Easy Edu's guide to questions to ask in a school platform demo asks a presenter to put on every screen; this page is about how to tell which label is true. For a whole proposal, the school platform evaluation guide applies the same kind of check with its own labels: released, planned, illustrative and out of scope.

What are the signs that a demo screen is a mockup?

A demo screen is probably a mockup when it only works along the path the presenter prepared. Vendors often show mockups of a direction, and that is normal. What gives a mockup away is what happens off the script: it has nothing behind it, so detours, reloads and fresh data expose it.

One sign alone proves nothing; look for several together. Clickable is not the same as built. The UK government's Service Manual page on making prototypes, written for public service teams, says prototypes "can vary in style from a quick pen and paper sketch to a code prototype that works like a fully interactive website", and that code prototypes "look and behave almost exactly like the real thing". It adds that "The code in a prototype does not need to meet the same standards as production code", for example on security or heavy traffic. A coded prototype can pass most of these checks, so a working screen still needs dated release notes for the quoted edition, and a pilot for anything the decision rests on.

What evidence proves a demo feature is real?

The evidence that proves a demo feature is real depends on the state claimed and on how much the school will rely on it. Documents dated before the demo come first, then a repeat of the task on a record nobody prepared; for a feature the decision rests on, a pilot is the strongest evidence of all. A demo setup needs a written configuration list, and planned work a dated commitment.

• Released in this offer: release notes or a help-centre article for the quoted edition, dated before the demo; a second run of the same task on a record nobody prepared; a reference call with a school already using that function on the same package; trial access if the vendor offers it; or, strongest of all, a controlled pilot, with the scope and acceptance rules that the demo guide's pilot section sets out. Some vendors call a short, scoped test of one claim a proof of concept; it needs the same written scope and acceptance rules.
• Configured for the demo: a written list of what was configured, by whom, how long it took, whether it is inside the quoted price, and whether the school can change it afterwards without the vendor.
• Illustrative concept: nothing further, provided it is recorded as a concept and no line of the proposal depends on it.
• Planned, with a date: a target release period in writing, what the school does in the meantime, and what happens commercially if the date moves.

Date matters, because UNESCO's 2023 Global Education Monitoring Report notes that "Education technology products change every 36 months, on average", so a case study or reference about an older version may describe a different product.

Most of these documents come from the vendor, which is why the school's own test still matters. The same UNESCO report makes a related point about research on whether education technology works: "A lot of the evidence comes from those trying to sell it."

Where a claim touches personal data, ask for documents rather than a screen; the school data questions guide lists them.

How can a school test whether a demo feature is real during the meeting?

A school can test whether a demo feature is real during the meeting with three requests: let someone from the school drive the step, change a record on the spot, and save an entry, then reopen it. Send the scenario in advance, as Easy Edu's demo questions guide recommends, and improvise the variation in the room, using sample data rather than any real student's details.

1. Drive itLet someone from the school perform the step, not the presenter. If that is not possible, ask why: a shared demo setup or a permissions limit is a normal answer that can be checked afterwards.
2. Change itAsk the presenter to add a test student with a name the school invents on the spot, never a real student's; mark that student absent, correct it to late, and see what each role's own account now shows; a parent view that needs a guardian link or an administrator step first is a setup question to record, not a failed test. A notice sent on a schedule, such as a weekly summary, will not appear in the meeting; ask when it goes out and check it when the test is repeated before signing.
3. Reopen itSave an entry, then reload the page or open the record from a second account that is allowed to see it: working software shows it; a click-through mockup has lost it. A coded prototype may keep it too, which is why a "released" answer still needs dated release notes for the quoted edition. A record hidden by permissions or an approval step is working as designed, a delay the vendor names and explains is worth waiting for, and a half-typed entry that vanishes on reload proves nothing.

The role view matters because a platform can deliver the same information differently to each group, which the role information-flow guide traces from source record to recipient. Google Classroom's official page, for example, says parents and guardians can view assigned classwork through a link sent by educators or through weekly guardian email summaries. What a parent receives can look nothing like the teacher's screen, so ask to see each role's view as that role gets it.

What happens if a school buys on a concept screen?

A school that buys on a concept screen can find out months later that a feature it planned around is not in its package: the task stays manual or moves to a second app, and staff pay for the workaround in their own time. So before signing, write three things into the contract: the planned feature, its target date, and what happens if that date slips.

Buying is not the same as using, as the evaluation guide puts it. For the United States, UNESCO's technology-in-education page records an average of 67% of education software licences unused and 98% not used intensively. The same UNESCO page also cites the EdTech Genome Project's finding that 85% of some 7,000 pedagogical tools, which cost USD 13 billion, were "either a poor fit or implemented incorrectly".

The technology page gives no reason for the unused licences, the EdTech Genome finding is about fit and implementation, and none of these figures is about demos; together they show that buying software and using it well are not the same thing. A school that has already signed can still write each claim it relies on into the evidence register described below and ask the vendor for its state in writing.

What should a school record about each demo screen?

A school should record one line for each demo screen it may rely on, written during the meeting rather than afterwards: the claim, the state the vendor gave it, what the school saw with the evidence still owed, and the name of the vendor person who gave the answer. "Released in this offer", said by a named account manager, is a different record from "I think that's in there".

Keep these rows in one evidence register, the one the demo questions guide sets out field by field. Before signing, check that every row the decision rests on is confirmed as released, with its evidence received, or backed in writing: a configuration list inside the quoted price, or a dated commitment for planned work. Then attach the register to the contract, so the school's acceptance checks during rollout test the same claims.