How to Run a Product Demo for Teachers and School Leaders

A good school product demo should help teachers and leaders decide whether the product fits their needs, staff, pupils, systems and budget.

It should not simply prove that the supplier knows how to operate its own software, equipment or service.

Many school demos fail because they are organised around the product rather than the buyer. The supplier begins with the homepage, opens each menu in order and explains every available feature. Teachers wait to see what the product would change in their classroom. Senior leaders wait for evidence, implementation and cost. IT staff wait for security and integration information. The school business manager waits to understand the commercial commitment.

By the end, everyone has seen a great deal, but no one is certain whether the offer solves the school’s actual problem.

A useful demo begins much earlier than screen sharing.

The supplier needs to understand:

why the school agreed to the demonstration;
who will attend;
which problems and workflows matter;
what the school has already seen;
which questions each participant needs answered;
what decision should follow the session.

The product should then be shown through a small number of realistic school scenarios.

For example, instead of demonstrating every reporting option, show how an attendance lead would identify a pattern, record an action and produce the report needed by senior leadership. Instead of displaying every furniture range, show how the supplier would plan one representative classroom around pupil numbers, teaching use, durability and budget.

This guide explains how to run a product demo for teachers and school leaders, how to prepare for mixed audiences, which features to show, how to handle questions and how to finish with a clear next step.

Decide what the demonstration is meant to achieve

A demonstration should have a defined purpose.

Possible purposes include:

helping a teacher decide whether the product fits classroom practice;
showing senior leaders how a whole-school process would change;
confirming that required functionality exists;
allowing IT staff to review technical suitability;
helping a MAT compare school-level and central controls;
demonstrating a physical product before a quotation;
supporting a formal procurement evaluation;
preparing the school to decide whether to run a pilot.

These are different demonstrations.

A teacher-focused introductory demo may need practical workflows, classroom examples and honest discussion of preparation time.

A trust procurement demonstration may need to follow a written specification, show mandatory requirements consistently and allow several evaluators to score the product.

Before the session, ask:

What prompted the request for a demo?
What would the school like to understand by the end?
Is this an early exploration or part of an active buying process?
Has the school already reviewed other products?
Is there a written list of requirements?
What decision should follow the demonstration?

The final question is especially important.

If the school says:

“After the demo, we want to decide whether to involve our IT manager and request a formal quotation.”

you know what the session must achieve.

If the answer is:

“We are simply looking at what is available for next year.”

the session should remain proportionate. A broad overview may be more appropriate than a highly tailored technical demonstration.

Distinguish a discovery meeting from a demo

A discovery meeting helps the supplier understand the school. A demo shows how the product may address what has been learned.

They can happen in the same session, but discovery should come first.

The previous guide to discovery questions to ask a school explains how to understand the current process, problem, desired outcome, budget, stakeholders and procurement route.

Without that information, the supplier can only deliver a generic product tour.

Define the decision you are not asking for

Do not imply that attending a demo commits the school to buy.

A suitable opening might say:

“The purpose today is to show how the product would handle the three workflows you identified and to decide whether it is worth progressing to technical and commercial review.”

This gives the meeting a clear outcome without creating artificial pressure.

Understand the audience before choosing what to show

Teachers and school leaders may attend the same demonstration but evaluate the product from different perspectives.

The supplier should know who is attending and what each person needs from the session.

Teachers and end users

Teachers are likely to ask:

Will this work during a normal lesson or school day?
How much preparation is required?
Will pupils understand how to use it?
Does it reduce work or create another task?
Can it be adapted for different pupils?
What happens when something goes wrong?
Will training and support be available?

They usually need to see the ordinary workflow rather than an idealised administrator view.

Subject and curriculum leaders

They may consider:

curriculum fit;
consistency across classes;
quality and progression;
department-level reporting;
staff adoption;
resource and training requirements;
evidence of educational usefulness.

Senior leaders

Headteachers, deputy headteachers and other senior leaders are more likely to ask:

Which school priority does this support?
What will change across the organisation?
How will implementation be led?
How much staff capacity is required?
What evidence supports the claims?
How will success be measured?
What are the principal risks?

School business managers and finance staff

They may need:

the complete price;
the contract period;
setup, training and support costs;
purchase-order and invoicing arrangements;
implementation requirements;
whole-life value;
supplier-assurance information.

IT and data staff

They are likely to focus on:

technical requirements;
integrations;
user provisioning;
authentication;
data processing;
security;
accessibility;
support and service levels;
data export and contract exit.

MAT central teams

They may need to understand:

central and academy-level permissions;
trust-wide reporting;
how local differences are handled;
multi-school implementation;
central pricing;
support across several academies;
how additional schools can be added.

Ask for attendee names and roles before the meeting.

You might say:

“To make the session relevant, could you let me know who will attend and which aspects each person is most interested in?”

If a mixed group attends, do not attempt to satisfy everyone by showing everything.

Create a shared central story, then include short sections for specialist concerns.

For example:

Teacher workflow
Senior-leadership visibility
Trust or school administration
Implementation, security and commercial overview

Build the demonstration around real school scenarios

The strongest demonstration is normally organised around tasks the school recognises.

Do not begin with the product menu.

Begin with the user and the situation.

For example:

“A Year 5 teacher wants to identify which pupils struggled with today’s fractions activity, set follow-up work and share a summary with the maths lead.”

Or:

“An attendance officer needs to review persistent absence across year groups and prepare a concise report for the deputy headteacher.”

Or:

“A trust estates director needs to see which statutory actions remain outstanding across eight academies while each school manages its own local records.”

Each scenario should show:

who is using the product;
what they are trying to achieve;
the steps they take;
what information or output is produced;
what happens next.

Choose three to five core workflows

Most demonstrations do not need more.

Possible workflows for software include:

setting up a user or class;
completing the main daily task;
reviewing information;
producing a report;
handling an exception;
administering several schools.

Possible scenarios for a physical product include:

how it is used in a normal lesson;
how it supports different ages or needs;
how it is stored and maintained;
how it fits the available space;
how staff are trained;
what happens if a part is damaged.

Possible scenarios for a service include:

how a referral or request begins;
what the supplier does first;
how school staff are involved;
what reporting is provided;
how concerns or changes are handled;
how the service is reviewed.

Show the ordinary case before advanced features

A supplier may be proud of automation, artificial intelligence, advanced analytics or unusual customisation.

These features matter only after the school understands whether the basic workflow works well.

Begin with:

the most common user;
the most frequent task;
the standard process;
the normal output.

Then show advanced functionality where it relates to a stated requirement.

Demonstrate the problem, not only the feature

Instead of saying:

“The product includes automatic notifications.”

say:

“You explained that staff currently check the spreadsheet manually each morning. Here is how the attendance lead creates a threshold and how the relevant colleague receives an alert when it is reached.”

The feature is now connected to the school’s process.

Use the school’s language

If the school refers to academies, year groups, interventions, business managers or trust directors, use those terms in the demonstration.

Do not force the school to translate generic corporate terminology such as:

business units;
customers;
sales representatives;
enterprise accounts;
consumer journeys.

A product that still displays inappropriate terminology throughout may need genuine adaptation for education rather than a school-themed presentation.

Prepare realistic demonstration data, examples and materials

The quality of the demonstration depends on the environment used to show the product.

A nearly empty trial account can make a useful product look unfinished. An account filled with irrelevant corporate data can make it appear unsuitable for schools.

Prepare realistic but fictional content.

For software, this might include:

fictional schools and academies;
fictional pupils and staff;
representative year groups;
sample attendance or assessment records;
realistic reports;
different user permission levels;
an example of incomplete or problematic data.

Do not use real pupil, parent or staff data without a lawful, necessary and appropriately controlled reason.

A demo environment should normally contain no identifiable customer information.

Show realistic complexity

A product can appear effortless when the demo contains only:

one user;
one class;
perfect data;
no access restrictions;
no errors;
no competing processes.

School use is rarely so clean.

Include examples such as:

a new staff member joining;
a user with restricted access;
missing information;
a pupil moving class;
several academies using different local settings;
a report that requires filtering;
an item that needs approval or escalation.

You do not need to manufacture chaos. Show that the product can handle ordinary variation.

Prepare physical samples properly

For physical products, bring or provide:

a representative sample;
accurate dimensions;
materials and finish options;
age or setting suitability;
maintenance information;
warranty details;
delivery and installation information;
relevant safety or testing documentation.

Do not display a premium sample and then quote for a materially different lower-grade product without making the distinction clear.

Prepare supporting materials

Useful supporting material may include:

a one-page agenda;
the workflows to be demonstrated;
a relevant case study;
pricing guidance;
implementation outline;
technical summary;
accessibility information;
answers to questions raised during discovery.

A demonstration should not depend on the school taking screenshots or remembering everything said.

Provide a concise written summary afterwards.

Open the demo by confirming the problem and agenda

The first few minutes should establish that the supplier has listened.

Do not begin screen sharing immediately.

A useful opening is:

“Before I show the product, let me check that I have understood the requirement. You currently use separate spreadsheets across five academies, and the central team has no consistent view of outstanding actions. Each academy still needs to manage its own information. Today I will show the academy workflow, central reporting and implementation process. We will then leave time for technical and commercial questions.”

This allows the school to correct any misunderstanding.

Confirm the agenda

A 45-minute demo might use:

Introductions and recap — 5 minutes
Three core workflows — 20 minutes
Administration and reporting — 8 minutes
Implementation, pricing and assurance — 7 minutes
Questions and next step — 5 minutes

Adjust the timing to the audience.

For a teacher-focused demonstration, spend more time on practical use.

For senior leaders, implementation, evidence and reporting may need greater attention.

Tell the audience how to ask questions

You might say:

“Please interrupt with questions where they relate directly to the workflow. I will note broader technical and contractual questions so we can cover them in the final section.”

This keeps the meeting interactive without allowing one specialist topic to consume the whole session.

Establish what participants need from the session

Ask each key participant briefly:

What would you particularly like to see today?
Is there one question you need answered?
Have you used a similar product before?

This may reveal a requirement not mentioned during discovery.

If it is substantial, do not redesign the whole demo without discussion. Say:

“That is important, but it is not included in the environment prepared today. I can explain the approach now and arrange a short follow-up showing it properly rather than improvise an incomplete answer.”

Demonstrate clearly, slowly and interactively

A supplier uses its product every day. The school does not.

Actions that feel obvious to the presenter may be difficult for a first-time viewer to follow.

Explain where you are and why

Use a clear pattern:

State the user and objective.
Show the action.
Explain the result.
Connect it to the school’s need.
Pause for questions.

For example:

“We are now viewing the system as a class teacher. The teacher wants to record the result of today’s reading assessment. They select the class, enter the result and add a note. That information is immediately available to the literacy lead, but the teacher cannot access records for another class.”

Avoid rapid cursor movement

Do not race through menus while speaking.

Viewers need time to:

understand the screen;
find the control you are describing;
connect the step to the previous one;
form a question.

Use a readable zoom level. Hide unnecessary browser tabs, notifications and personal information.

Do not rely on unexplained jargon

Terms such as API, SSO, data warehouse, automation rule or role-based access may be familiar to some attendees and not others.

Explain the practical meaning:

“Single sign-on means staff can access the product using their existing school account rather than remembering another password.”

Ask for reactions during the demo

Useful questions include:

How does this compare with your current process?
Would this fit the way your staff work?
Which part would be useful?
What would still be missing?
Would teachers need a different view?
How would this work across your academies?

Do not wait until the final minute to discover that the school misunderstood the workflow.

Let the school direct part of the session

Once the core workflow has been shown, allow a relevant participant to choose a realistic example:

“Which report would you normally need after completing this process?”

Or:

“Would you like to see how this looks for a classroom teacher or the trust administrator next?”

This makes the session responsive without turning it into an uncontrolled tour.

Do not hide ordinary effort

If completing a task takes several steps, show them.

Do not prepare everything in advance and imply that the product produces a result automatically when staff must first configure, upload or review substantial information.

Explain:

what the supplier sets up;
what the school configures;
which tasks repeat;
which tasks happen only during implementation;
which parts can be automated.

Show implementation, accessibility and support—not only features

Teachers and leaders need to understand what happens between approving the product and using it successfully.

A demo that ends with the product interface leaves major buying questions unanswered.

Explain implementation

Cover:

typical implementation length;
supplier and school responsibilities;
data, site or equipment requirements;
project meetings;
staff training;
launch support;
common causes of delay;
how progress is reviewed.

For example:

“A single-school implementation normally takes four to six weeks after the purchase order and data review. The school nominates a project lead, provides the agreed data export and arranges two staff-training sessions. Our team configures the system, checks the import and supports launch.”

Show the training experience

Teachers may be less concerned about whether the product is easy for the salesperson than whether ordinary staff can learn it.

Explain:

who receives training;
session length;
whether training is onsite or online;
whether recordings or guides are included;
how new staff are trained later;
which support is available after launch.

Demonstrate accessibility where relevant

Do not treat accessibility as a slide containing a compliance claim.

For digital products, be ready to demonstrate relevant features such as:

keyboard navigation;
focus visibility;
screen-reader labelling;
text resizing;
colour contrast;
captions and transcripts;
alternative formats;
accessible error messages.

Explain known limitations honestly.

Department for Education digital standards advise schools and colleges to provide equitable access and to discuss specific accessibility requirements with digital and content suppliers. Suppliers should therefore be prepared to provide a current accessibility statement and evidence rather than relying on a general claim that the product is “fully accessible”.

For more information, see the government guidance on digital accessibility in schools and colleges.

Explain support through a realistic problem

Show what happens when:

a user cannot log in;
data fails to import;
equipment is damaged;
a session needs to be rearranged;
a report appears incorrect;
the school needs urgent assistance.

Explain:

support hours;
contact routes;
response priorities;
named account management;
escalation;
what is included in the price.

Show how the product ends as well as how it begins

For subscriptions and digital services, explain:

how the school exports its data;
what happens when the contract ends;
how user accounts are removed;
how long information is retained;
whether exit assistance is available.

A school is more likely to trust a supplier that makes leaving understandable.

Handle technical, educational and commercial questions honestly

A strong demo creates questions. The goal is not to have an immediate polished answer for everything.

The goal is to respond accurately and ensure unanswered questions are managed.

Separate answers from promises

When asked whether the product can do something, use one of four answers:

Yes: show it or explain the current function.
Partly: explain the limitation and workaround.
Not currently: say so clearly.
Needs confirmation: record the question and provide a date for the answer.

Do not say:

“That should be possible.”

when you do not know.

The school may later treat this as a product commitment.

Do not invent a roadmap commitment

A requested feature being “on the roadmap” is not the same as an agreed delivery date.

Explain:

whether the feature is formally planned;
whether a date exists;
whether it will be included in the quoted package;
what the school should assume if it is not delivered.

The school should evaluate the product it can contract for, not an optimistic future version.

Answer educational questions proportionately

Where teachers or leaders ask about impact, distinguish between:

product usage;
staff experience;
operational improvement;
changes in practice;
pupil outcomes;
independent evaluation.

A platform may help teachers identify gaps more efficiently. That does not mean it automatically raises attainment.

A workshop may receive strong participant feedback. That does not by itself prove long-term behaviour change.

Explain what the evidence supports.

Handle security and data questions carefully

Do not improvise technical-security answers when a specialist is required.

You can say:

“I can explain the user-permission model today. Our security lead should answer the detailed question about penetration testing, and I will provide that response by Friday.”

For EdTech products, suppliers remain responsible for their obligations under UK data-protection and electronic-privacy law. The Information Commissioner’s Office also notes that some EdTech services may fall within the Children’s Code, depending on how they are offered and used.

Relevant official guidance is available from the Information Commissioner’s Office.

Discuss pricing directly

Do not end a detailed demonstration without helping the school understand the likely cost.

Explain:

the relevant package;
first-year cost;
renewal cost;
contract duration;
setup and training;
support;
optional additions;
what changes the price.

If the scope remains unclear, provide a realistic range and state what is needed for a formal quotation.

Adapt the demo for formal evaluation and procurement

A demo that forms part of a competitive buying process must be handled differently from an informal sales presentation.

The school or trust may issue:

a written specification;
a demonstration script;
scored scenarios;
mandatory requirements;
time limits;
rules on questions;
instructions on who may attend;
requirements for written clarification.

Follow these instructions precisely.

Department for Education guidance advises schools to define what they need and write a specification that suppliers can respond to. Where the demo is part of a procurement, the supplier should show how the offer meets those stated requirements rather than substituting its preferred sales story.

See the official guidance on writing a school purchasing specification.

Map the demo to the evaluation criteria

Create an internal table:

Requirement	Where it is shown	Evidence
Teacher can create and assign an activity	Workflow 1	Live demonstration
Trust can view academy-level reporting	Workflow 3	Central dashboard and sample report
Keyboard accessibility	Accessibility section	Live keyboard walkthrough and statement
Data export at contract end	Exit section	Export demonstration and contract response

This reduces the risk of spending too long on attractive but unscored features.

Use the same environment promised in the bid

Do not demonstrate:

a premium version not included in the price;
custom functionality not yet built;
third-party integrations excluded from the offer;
features available only at additional cost;
a different service model from the written response.

Where an optional feature is shown, label it clearly.

Keep to the time limit

Formal evaluators may be unable to give additional time because each bidder must be treated consistently.

Rehearse:

the complete script;
transitions;
who answers each section;
time for questions;
what to omit if technical delays occur.

Do not seek private feedback during an active procurement

Use the clarification and communication route specified by the buyer.

Do not approach individual evaluators outside the process to ask how the bid is performing or to introduce additional claims.

Finish with a decision-focused summary and next step

Do not allow the demo to end immediately after the final screen.

Reserve time to establish what the school concluded.

Ask:

Which parts appeared most relevant?
Which requirements remain unmet or unclear?
How does this compare with the current process?
What concerns would need to be resolved?
Who else needs to review the product?
What decision will the school make next?

Summarise the fit honestly

You might say:

“The product appears to meet the requirements for academy-level records, central reporting and staff permissions. We still need to confirm the integration with your existing finance system and provide the accessibility documentation requested by IT.”

This is more useful than:

“It sounds like we are a perfect fit.”

Agree a specific next step

Possible next steps include:

a technical review;
a meeting with finance or senior leadership;
a site survey;
a formal proposal;
an itemised quotation;
reference conversations;
due-diligence documents;
a defined trial or pilot;
submission through the formal procurement route.

Give the action an owner and date.

Action	Owner	Date
Provide technical integration response	Supplier	Friday
Confirm required user numbers across academies	Trust contact	Monday
Issue formal quotation	Supplier	Wednesday
Review proposal with finance and IT	Trust	Following week

Do not assume that a successful demo means the school is ready to buy

The school may still need:

budget approval;
comparison quotations;
procurement;
IT and data review;
safeguarding checks;
contract negotiation;
implementation planning.

Ask:

“What needs to happen internally before a decision can be made?”

Send a concise follow-up

The follow-up should include:

thanks;
the workflows shown;
the school’s main requirements;
areas of fit;
limitations or unanswered questions;
pricing or quotation status;
agreed actions and dates;
relevant supporting documents.

Do not send a large generic folder after the meeting.

Send the information needed for the next decision.

Common school product demo mistakes

Showing every feature

The school loses sight of the workflows and outcomes that matter.

Using the same demo for every audience

Teachers, senior leaders, finance and IT evaluate different aspects of the offer.

Beginning without confirming the requirement

The supplier may spend most of the meeting demonstrating the wrong problem.

Using real customer or pupil data

Demo environments should normally contain realistic but fictional information.

Moving too quickly

The presenter knows the product; the audience does not.

Showing only perfect scenarios

Schools also need to understand permissions, exceptions, errors and ordinary operational complexity.

Hiding setup and administration

The product appears easier than it will be in practice.

Claiming every requested feature is possible

Unverified promises create contractual and implementation problems.

Ignoring accessibility

Digital accessibility should be demonstrated and documented, not treated as a generic compliance badge.

Avoiding pricing

The school may invest substantial time before discovering that the product is not affordable.

Leaving no time for questions

A demonstration is an evaluation conversation, not a performance.

Allowing one technical question to consume the session

Record specialist questions and arrange an appropriate follow-up where necessary.

Criticising competitors during the demo

Show the strengths and differences of your own offer without making unsupported claims about another supplier.

Using a premium environment that differs from the quotation

The school must know exactly which functionality is included.

Ending without confirming the decision process

A positive reaction does not automatically create a qualified opportunity.

Frequently asked questions

How long should a school product demo be?

Thirty to 45 minutes is often suitable for a focused demonstration. Complex trust-wide or technical sessions may require up to an hour or separate specialist meetings. Confirm the agenda and duration in advance.

Should discovery and demonstration happen in the same meeting?

They can, but discovery should come first. The supplier needs enough understanding of the school’s process, problem and users to make the demonstration relevant.

How many features should be shown?

Show only the features needed to demonstrate the school’s core workflows and important requirements. Three to five complete scenarios are often more useful than a rapid tour of every feature.

Should teachers and leaders attend the same demo?

They can, especially where both practical use and whole-school value matter. Structure the session around a shared workflow, then address teacher, leadership, finance and technical concerns separately.

Should the supplier customise the demo for every school?

The underlying demo environment can be reusable, but the scenarios, language, examples and evidence should reflect the school’s phase, size, structure and stated requirements.

Can real pupil data be used in a demo?

Normally, use realistic fictional data. Real personal data should be used only where there is a lawful, necessary and appropriately controlled reason, which is unlikely in an ordinary sales demonstration.

Should pricing be discussed during the demo?

Yes. Provide the relevant package price or a realistic range, including setup, training, support, contract term and renewal cost. The school should be able to judge whether further evaluation is worthwhile.

What should an EdTech supplier demonstrate?

Show the main teacher or staff workflow, administration, reporting, permissions, integrations, accessibility, implementation, support and exit arrangements. Technical and security details may require a separate specialist review.

What should a physical-product supplier demonstrate?

Show normal use, suitability, materials, dimensions, storage, maintenance, installation and warranties. Make clear whether the sample shown matches the product and specification being quoted.

Should a supplier provide a free trial after the demo?

Only where a trial will answer a specific decision question. Define users, duration, support, success criteria, data arrangements and the decision that follows. An open-ended trial may create work without producing useful evidence.

How should accessibility be demonstrated?

Show relevant functions such as keyboard navigation, screen-reader support, text resizing, contrast, captions or alternative formats. Provide a current accessibility statement and explain known limitations and remediation plans.

What if a requested feature does not exist?

Say so clearly. Explain any current workaround or confirmed development plan, but do not imply that an uncommitted future feature is available.

What if the demo fails technically?

Use a prepared backup such as screenshots or a short recorded workflow, explain the failure honestly and arrange a follow-up where necessary. Do not pretend that the missing function was shown successfully.

Should the meeting be recorded?

Only with appropriate agreement and after considering privacy and data-protection requirements. A recording may be useful for absent stakeholders, but a concise written summary is often sufficient.

How should suppliers handle formal procurement demos?

Follow the issued script, evaluation criteria, timings and communication rules. Demonstrate the version and services included in the bid, and clearly identify optional or additional-cost functionality.

What is the best final demo question?

Ask: “What needs to happen internally before the school can decide whether to proceed?” This reveals the remaining stakeholders, checks, procurement stages and timetable.

How do I know whether the demo was successful?

A successful demo gives the school a clear understanding of the relevant workflows, limitations, implementation and cost. It also produces an informed decision about the next step, even when that decision is not to proceed.