B2B2C licensing to schools: how the model really works

Most software has one customer. The person who pays is the person who uses it, or at least works in the same team. B2B2C licensing to schools breaks that. A school or school group signs the contract. A teacher or administrator sets it up. Students use it every day. Parents and guardians want to know what it does with their children's data. Each of those people has different needs, and a product that serves only one of them rarely lasts past the first renewal.

EduRelia is Oryvelon's AI learning company for students, families and schools, and school licensing is one of its routes to market. This article explains how we think about the model: who the parties are, how procurement and onboarding work, how data roles are set, and what makes a school renew. Most of it applies to any edtech product selling into schools.

Who pays, who decides, who uses

The first step is to name the parties clearly, because a sales process that treats "the school" as one person will stall.

A product can win leadership with outcome claims, lose IT on a missing data processing agreement, and then fail in the classroom because teachers found it added work. Each group has a veto, whether formal or informal. We design the sales materials, the onboarding and the product itself with all five in mind.

Why schools buy differently

Schools are not slow for no reason. They hold data about children, spend public or tuition money, and answer to parents, inspectors and regulators. Procurement reflects that.

Common features of school buying:

• Budget cycles. Many schools plan spending around an academic or financial year. A product that is perfect in October may have to wait until the next budget.
• Documentation before demos. Security questionnaires, data protection impact assessments and accessibility statements often come before anyone sees the product in depth.
• Pilots. Schools frequently want a trial with one year group or one subject before committing.
• Group decisions. In school groups and trusts, a central team may approve a product once for many schools, or leave it to each school.
• Low tolerance for surprises. A product that changes behaviour mid-year, or introduces a new data use without notice, can lose trust quickly.

The practical response is to prepare the documentation before it is asked for. EduRelia keeps a standing pack: a plain description of what the product does and does not do, a list of the data it processes and why, security controls, data retention periods, subprocessor categories, accessibility information and pricing. When a school asks, we can answer in days rather than weeks. That preparation starts in the company's source-of-truth document, which defines the data rules before any feature is built.

Settling data roles before anything else

In a school licence, it has to be clear who is responsible for what data, and on what basis. Getting this wrong is a legal problem and, more immediately, a trust problem.

In many arrangements under data protection laws such as GDPR and KVKK, the school decides why student data is processed and the provider processes it on the school's instructions. In GDPR terms that usually makes the school the controller and the provider the processor for that data. Other laws, such as COPPA in the United States, have their own rules for children's data and school consent. The exact roles depend on the arrangement and the jurisdiction, and schools and providers should take proper advice; this article describes how we approach it, not what the law requires in any specific case.

What that means for EduRelia in practice:

• A written data processing agreement that states what data is processed, for what purpose, for how long, and what happens at the end of the contract.
• Processing only on the school's instructions. Student data from a school licence is used to provide the service to that school. It is not used to build a consumer marketing list, train a general model or feed another Oryvelon product.
• No cross-product use. The group's rule that user data never crosses between companies applies with extra force here. See Shared infrastructure, separate data.
• Minimal data by default. We collect what the learning experience needs and nothing else. Often that means a pseudonymous student identifier, a class, and learning activity, not full names, dates of birth or home addresses. We explain the reasoning in Child data minimisation in edtech.

This is also why a school-licensed student account and a family's direct relationship with EduRelia are kept separate. If a family later chooses to use EduRelia at home under their own account, that is a new relationship with its own consent. It does not inherit the school's data, and the school's data does not become marketing material. The distinction between the two kinds of consent is covered in Marketing consent vs product consent.

Tenancy: each school is its own space

A school licence implies a boundary. One school's students, teachers and data must never be visible to another school, even within the same trust unless the trust has explicitly asked for shared visibility and is entitled to it.

EduRelia treats each licensed school (or trust, where appropriate) as a tenant. Every record carries a tenant identifier, every query is scoped by it, and access checks happen on the server, not just in the interface. Teachers see their own classes. School administrators see their school. Nobody at a school sees anything from another school. We describe the pattern in more depth in Tenant isolation explained.

Internally, access follows the same logic. Staff who support schools get the minimum access they need, time-limited where possible, with two-factor authentication and logging. Support staff do not browse student data to answer a question about billing.

Pricing a school licence

School pricing has to fit how schools budget. Complicated usage-based pricing that produces a different invoice every month is hard for a school to approve, however fair it might be in theory.

The structures we consider:

• Per-student annual licence. Simple to understand and scales with school size. The difficulty is defining "student": enrolled, active, or invited.
• Tiered school licence. Price bands by school size. Easier to budget, less precise.
• Per-class or per-subject licence. Suits pilots and gradual rollouts.
• Group or trust licence. One agreement for many schools, often with a volume price and central administration.

Whatever the structure, we try to follow a few principles. The price should be known before the year starts. There should be a clear way to add students mid-year without renegotiation. AI costs should be managed by us, within reasonable fair-use limits, not passed through as unpredictable charges. The wider trade-offs between flat pricing and usage components are discussed in SaaS subscription plus usage.

A free pilot can be useful, but it should have a defined scope, a defined end date and agreed success criteria. An open-ended free trial in a school tends to become a permanent free product that nobody is accountable for.

Onboarding: where most licences are won or lost

A signed contract is not adoption. Plenty of school software is bought, rolled out to a few enthusiastic teachers and then forgotten. The first weeks decide which way it goes.

We think of onboarding in three layers.

School setup

Accounts, classes and rosters need to be created with as little manual work as possible. That might mean a simple upload of class lists, integration with the school's existing identity system, or class codes that teachers share. Whatever the method, the data collected at this stage should match the minimisation rules above: if the product does not need a date of birth, the upload template does not ask for one.

Teacher onboarding

Teachers need to see, quickly, how the product fits into lessons they already teach. A short guided setup, a handful of ready-made activities mapped to the curriculum, and clear controls over what students can see and do. Teachers also need to understand what the AI does and does not do, and how to report something that looks wrong. That transparency is part of building trust; see Onboarding and trust in AI products.

Student and family introduction

Students need a first session that works and makes sense without a manual. Families need a plain explanation, usually provided through the school, of what the product is, what data it uses and who to contact with questions. We provide schools with a template letter they can adapt, so the message families receive is accurate and consistent.

AI in the classroom: boundaries that schools can check

Schools are right to ask detailed questions about AI. Our answers are shaped by the group principle that AI explains, verified data decides.

For EduRelia that means:

• Curriculum content and assessment criteria come from verified sources, not from what a model happens to generate.
• The AI explains, guides and gives practice. It does not assign official grades or make decisions about a student's placement.
• Safety hooks run on inputs and outputs, checking for age-inappropriate content and signs that a student may need a human rather than a chatbot.
• Concerns route to people. If a student writes something that suggests they need help, the product does not try to handle it alone. The school's own safeguarding process is the path, and the product makes that route clear. The general pattern is in Human escalation in AI products.
• Prompts and student data stay inside EduRelia. The shared AI gateway provides routing, budgets and logging controls, but prompts, knowledge and user data are never merged with other products.

We would rather document these limits clearly and have a school ask sharp questions than have them discover something unexpected later.

Support that respects the school's time

In B2B2C, support requests come from several directions: a student who cannot log in, a teacher who cannot find a class, an IT lead with a security question, a parent with a privacy question. Each needs a clear path.

We route most student and teacher questions through the school, because the school knows its own accounts and has the relationship with families. EduRelia supports the school's administrators directly, with defined response times. Privacy and data requests are handled through a documented process that respects the school's role in deciding on them.

The metric we watch most closely is support burden per school. A product that generates a steady stream of tickets for the school's IT team is a product that will be questioned at renewal, however much students like it.

Renewal is earned during the year

Renewal conversations often happen in a few weeks before a contract ends. By then, the decision is mostly made. The school already knows whether teachers used the product, whether students engaged, whether IT had problems and whether any parent complained.

What we do throughout the year:

• Usage reporting to the school. Aggregate, privacy-respecting reports showing how the product is being used: active classes, activities completed, trends over the term. No individual student profiling beyond what the school's teachers need for teaching.
• Mid-year check-ins. A short review with the school's lead contact: what is working, what is not, what would help.
• Change notices. Any change that affects data processing, features teachers rely on or pricing is communicated in advance, with time for questions.
• Clean exit options. Schools should know exactly how to get their data out and how deletion works at contract end. Paradoxically, making exit easy makes renewal easier, because it removes a source of anxiety. See Data retention and deletion.

The recurring revenue in a school licence is real, but it is annual and it is earned.

What happens at the end of a contract

Every school licence ends eventually, whether through non-renewal, a change of provider or a school closing. The end of a contract is also a data event.

Our standard approach is written into the agreement:

1. The school is told, in advance, the date on which access will end.
2. The school can export its data in a usable format before that date.
3. After the agreed period, student data from that licence is deleted from active systems, and from backups on their normal rotation cycle.
4. The school receives confirmation that deletion has been carried out.

Nothing from a school's data survives in another form: no "anonymised" copy kept for product development unless the agreement explicitly provided for it and it is genuinely non-identifying.

A worked example: from pilot to licence

Imagine a secondary school that wants to try EduRelia with one year group in one subject for a single term. Here is how we would expect it to run.

Before the pilot starts, the school's data protection lead receives the documentation pack and signs a data processing agreement that covers the pilot as well as any later licence. The scope is written down: which classes, which teachers, which start and end dates, and three or four success criteria the school chose itself, such as the share of students completing weekly practice or teacher time saved on preparing revision material.

During the term, teachers get a short onboarding session and a named contact. Halfway through, we review usage with the school's lead and fix anything that is getting in the way. At the end, the school receives an aggregate report against its own criteria.

Then the school decides. If it continues, the pilot converts into a licence at the price agreed in advance, and the existing classes carry on without a reset. If it does not, the data is exported on request and deleted on the agreed schedule. Either outcome is a clean one.

Common mistakes in B2B2C school licensing

A few patterns we see often, and try to avoid:

• Selling to leadership and ignoring IT. The deal stalls at the data protection review.
• Treating students as the customer. Features built for engagement at any cost can conflict with what the school and families want.
• Collecting data "for later". Fields added to rosters or profiles without a current purpose become liabilities.
• Blurring school and home relationships. Using school-provided data to reach families commercially destroys trust fast.
• Unpredictable pricing. Schools cannot easily approve invoices that vary month to month.
• Neglecting teachers. If the product adds work to a teacher's week, adoption falls regardless of how good it is for students.

Measuring whether a licence is healthy

We keep the metrics simple and tied to the parties above:

These feed EduRelia's own continue, stop or scale checkpoints. If schools sign but classes do not use the product, that is a signal to fix onboarding before signing more schools.

Summary

B2B2C licensing to schools works when a product serves all its parties at once: leadership who pay, IT who approve, teachers who introduce it, students who use it and families who trust it. For EduRelia that means preparing procurement documentation early, setting data roles clearly in writing, minimising student data, isolating each school as its own tenant, pricing in ways schools can budget, investing heavily in onboarding, keeping AI within boundaries schools can check, and earning renewal through the year with honest reporting and easy exit. None of it is glamorous. All of it decides whether a school stays.

Questions and answers

What is B2B2C licensing in education?

It is a model where a school or school group pays for a licence and its students, teachers and sometimes families use the product. The school is the customer, but the end users are the people who decide whether it gets used.

Who controls student data in a school licensing model?

Typically the school decides the purposes of processing and the provider processes data on its behalf under a written agreement. The exact roles depend on the arrangement and local law, so they should be set out explicitly in the contract.

Can a school-licensed edtech product market to students or parents directly?

EduRelia does not use data obtained through a school licence to market consumer products to students or families. Any direct relationship with a family is separate, opt-in and governed by its own consent.

Published by Oryvelon, a digital company builder · About the group · Our companies · More in Commerce & SaaS

NextUnit economics per product: AI costs and shared cost allocation →