Ask.School is an AI-powered parent communication platform for UK schools with multi-tenant architecture designed for multi-academy trusts. MAT communication tools are increasingly important as trusts grow in size and complexity, yet the communication infrastructure in many trusts has not kept pace. Individual schools within a trust often operate entirely separate communication systems, creating a fragmented experience for parents, duplicated workload for office staff and significant governance blind spots for trust leaders.

The challenge is not simply one of technology. It is structural. A multi-academy trust is, by design, a collection of individual schools operating under a shared governance framework. Each school retains its own identity, its own community and often its own way of doing things. Parents identify with their child’s school, not with the trust. Yet the trust has legal, financial and safeguarding responsibilities that span every school in the group.

This tension is felt most acutely in parent communications. When a parent contacts a school, they expect a consistent, professional and helpful response regardless of which school in the trust their child attends. When a trust leader needs to ensure that safeguarding standards are applied consistently across every school, they need visibility and control that fragmented systems cannot provide. The sections below examine the specific challenges MATs face with parent communications and how a trust-wide deployment model addresses them without sacrificing school-level autonomy.

What are the specific communication challenges facing multi-academy trusts?

Multi-academy trusts experience a distinct set of communication problems that do not affect standalone schools. These problems are not theoretical — they are practical, daily friction points that consume staff time, create inconsistencies for parents and introduce governance risks for trust boards.

Inconsistent parent experience across schools

When each school in a trust manages its own communication platform independently, parents at different schools receive fundamentally different experiences. One school might have a modern chatbot answering routine questions around the clock. Another might rely on a static website and phone calls during office hours. A third might use a parent app that was set up years ago and is no longer actively maintained.

For parents with children at more than one school in the trust — a situation that is increasingly common as trusts grow — this inconsistency is immediately noticeable. They might receive instant answers at one school and wait hours or days at another. The quality of information varies. The tone varies. The availability varies.

This inconsistency undermines the trust’s brand and reputation. It also creates practical problems. Parents who are accustomed to a high-quality communication experience at one school will naturally compare it unfavourably with a poorer experience at another. Complaints and frustrations that should be avoidable become routine.

Duplicated configuration and setup effort

Every school in a trust that operates its own communication system requires its own setup, configuration and ongoing maintenance. If the trust has eight schools and each one sets up its own chatbot, parent portal or communication platform, that is eight separate configuration processes. Eight sets of documents to upload. Eight calendars to connect. Eight sets of branding to configure. Eight sets of safeguarding rules to define.

This duplication is not just inefficient — it introduces risk. When configuration is done eight times independently, there are eight opportunities for error. One school might miss a safeguarding setting. Another might forget to update its term dates. A third might configure its chatbot with outdated policy documents.

The IT team, if the trust has a centralised one, either has to manage eight separate systems or leave each school to manage its own. Neither approach is satisfactory. Centralised IT teams are stretched thin enough without multiplying every configuration task by the number of schools. And leaving individual schools to manage their own systems means the trust has limited visibility into what is actually deployed and how well it is working.

Separate billing and procurement complexity

Financial management in a MAT is complex enough without each school managing its own subscriptions to communication tools. When schools procure independently, the trust loses the ability to negotiate volume pricing. Each school might be on a different pricing tier, a different contract term, or even a different platform entirely.

For school business managers and trust finance directors, this creates a reporting headache. How much is the trust spending in total on parent communication tools? Which schools are getting value for money? Which subscriptions are due for renewal? Are there duplicate costs for tools that overlap in functionality?

Centralised procurement is a well-established principle in MAT operations. Most trusts centralise their purchasing for supplies, insurance and major technology contracts. Yet communication tools often fall through the gaps, purchased school by school before the trust’s central team even knows about them.

Fragmented safeguarding oversight

This is arguably the most serious challenge. Trusts have a legal and moral obligation to ensure that safeguarding standards are consistent across every school. Keeping Children Safe in Education applies to every school in the trust, and the trust board bears ultimate responsibility for compliance.

When each school uses a different communication platform, or configures the same platform differently, the trust has limited visibility into safeguarding compliance. Are the safeguarding guardrails on each school’s chatbot configured correctly? Are conversation logs being monitored? Are the right escalation procedures in place? Is there a consistent approach to handling disclosures?

These questions are difficult to answer when each school operates independently. A trust safeguarding lead who wants to review how a particular situation was handled at one school might need to log into a completely different system than the one they are familiar with at another school. Audit trails are fragmented. Reporting is inconsistent.

For a detailed examination of how safeguarding requirements apply to AI tools, see our guide on how schools can meet KCSIE requirements when using AI tools.

Lack of shared knowledge and documents

Many trusts have policies, procedures and documents that apply across all schools. Safeguarding policies, complaints procedures, admissions criteria and data protection policies are often written at trust level. Yet when each school manages its own communication system, these trust-wide documents must be manually uploaded to each school’s platform separately.

This creates a version control problem. When a trust-wide policy is updated, someone needs to ensure the new version is uploaded to every school’s system and the old version is removed. With multiple systems to update manually, there is a real risk of parents receiving outdated information — which is at best confusing and at worst a compliance issue.

The same applies to knowledge. If one school discovers a particularly effective way of answering a common parent question, that knowledge stays within that school’s system. There is no mechanism for sharing it across the trust.

Why do per-school deployments fail at trust scale?

Many trusts start by allowing each school to manage its own communication tools, preserving school autonomy and avoiding the complexity of a trust-wide rollout. However, per-school deployments create more problems than they solve as a trust grows.

The autonomy illusion

School leaders understandably value their autonomy. They know their community and want to communicate with parents in a way that reflects their school’s character and values. A trust-wide communication platform can feel like it threatens that autonomy.

But the reality is that a well-designed trust-wide platform gives schools more autonomy, not less. When configuration, maintenance and compliance are handled centrally, school staff are freed to focus on what they actually want to control: the content and tone of their communications. They do not need to worry about whether their safeguarding settings are correct, whether their platform is up to date, or whether their subscription is about to expire.

True autonomy for a headteacher means having the time and tools to communicate effectively with their community. It does not mean spending hours configuring technology that someone else could manage more efficiently.

Scaling problems

A per-school model might work acceptably when a trust has two or three schools. The problems become acute as the trust grows. Each additional school adds another system to manage, another set of configurations to maintain, another subscription to track, another platform to audit for safeguarding compliance.

Most trusts plan to grow. The academisation programme continues, and successful trusts regularly take on new schools. A communication model that barely works at five schools will be unmanageable at fifteen.

The coordination tax

When each school operates independently, any trust-wide initiative requires coordination across every school. If the trust wants to ensure consistent messaging about a policy change, someone must contact each school, explain the change and verify that each school has updated its communication platform accordingly.

This coordination tax scales linearly with the number of schools. It consumes the time of trust central staff, who already have more than enough to do. And it is unreliable — there is always a school that does not get the message, does not make the change or makes it incorrectly.

Vendor management burden

Managing relationships with multiple vendors, or even the same vendor across multiple independent accounts, is time-consuming. Different schools might be on different versions of the same platform. They might have different levels of support. They might have negotiated different terms.

A single trust-wide account with one vendor means one relationship to manage, one contract to negotiate, one support channel to use and one set of terms to understand. This is more efficient for the trust and typically results in better service, since the vendor is managing one large account rather than many small ones.

How does a multi-tenant architecture solve these problems?

Multi-tenant architecture is a technical term that has significant practical implications for how a communication platform works at trust level. In a multi-tenant system, each school in the trust operates as a separate “tenant” within a shared platform. Each school has its own space, its own data, its own branding and its own content. But the underlying infrastructure, configuration framework and administrative tools are shared.

This is fundamentally different from giving each school its own separate installation of the same software. In a multi-tenant system, the trust has a single administrative view across all schools while each school retains full control over its own communications. Ask.School’s multiple schools documentation explains how trust administrators switch between schools and manage shared settings from a single account.

Centralised administration with school-level control

The trust’s central team — whether that is the IT director, the safeguarding lead or the trust executive — has a single dashboard showing all schools. From this dashboard, they can set trust-wide policies, review activity across schools, manage billing and ensure compliance.

At the same time, each school’s headteacher or office manager has their own view showing only their school. They manage their own documents, their own calendar, their own branding and their own content. They communicate with their own parent community in their own voice.

This model mirrors how trusts actually work in practice. Certain functions are centralised — governance, finance, compliance, HR. Others are devolved — teaching, day-to-day operations, community engagement. A multi-tenant communication platform reflects this natural division of responsibility.

Consistent safeguarding across every school

In a multi-tenant system, safeguarding settings can be defined at trust level and applied consistently to every school. If the trust requires specific safeguarding guardrails — such as automatic escalation of certain types of conversation, keyword monitoring or conversation logging — these can be configured once and deployed across every school in the trust.

Individual schools cannot accidentally disable or misconfigure safeguarding settings that the trust considers mandatory. This provides the trust board with confidence that safeguarding standards are being met consistently, regardless of which school a parent is interacting with.

This is particularly important given the requirements of KCSIE, which place ultimate responsibility on the governing body — in a MAT context, the trust board — for ensuring that safeguarding is effective. A multi-tenant platform gives the trust board the tools to exercise that responsibility effectively.

Shared documents and knowledge

Trust-wide documents can be uploaded once at trust level and automatically made available to every school’s chatbot. When a trust-wide policy is updated, it is updated once and the change propagates to all schools instantly. There is no version control problem, no manual distribution process and no risk of parents at different schools receiving outdated information.

Schools can also maintain their own school-specific documents alongside the trust-wide ones. A school’s own uniform policy, daily timetable and local procedures sit alongside the trust’s safeguarding policy, complaints procedure and admissions criteria.

This hybrid approach — shared trust documents supplemented by school-specific content — gives parents comprehensive, accurate information regardless of whether their question relates to a trust-wide or school-specific matter.

One invoice for the entire trust

Financial simplicity is a significant practical benefit of the multi-tenant model. The trust receives one invoice covering all schools. Pricing is typically based on the total number of students across the trust, which means the per-student cost decreases as the trust grows.

For trust finance directors and school business managers, this means no more tracking multiple subscriptions, no more reconciling separate invoices and no more uncertainty about total spending on communication tools. Budget planning is straightforward because the cost is predictable and directly linked to a metric the trust already tracks: total student numbers.

How does per-school deployment compare with trust-wide deployment?

The following table provides a direct comparison of the two models across the dimensions that matter most to trust leaders.

Dimension Per-School Deployment Trust-Wide Deployment
Setup Each school configured independently; setup time multiplied by number of schools Single trust-level setup with school-specific customisation; one configuration framework
Branding Each school manages its own branding separately Each school retains its own branding within the trust platform
Documents Documents uploaded to each school separately; version control managed per school Trust-wide documents shared automatically; school-specific documents added locally
Safeguarding Each school configures safeguarding settings independently; no central oversight Trust-level safeguarding policies applied consistently; schools cannot override mandatory settings
Billing Separate invoices per school; trust must reconcile and track individually One invoice for the trust; per-student pricing that scales with growth
User management Separate admin accounts per school; no cross-school visibility Trust-level admin dashboard with school-level views; single sign-on for trust staff
Content updates Trust-wide changes must be manually applied to each school Trust-wide changes applied once and propagated automatically
Safeguarding audits Auditor must review each school’s system separately Single audit view across the entire trust
Onboarding new schools Full setup process for each new school joining the trust New school added as a tenant; inherits trust-level settings immediately
Vendor relationship Multiple accounts or contracts; potentially different terms per school Single trust-level relationship; volume pricing; one point of contact
Data separation Naturally separate (different systems) but no central reporting Logically separate (each school’s data is isolated) with central reporting capability
Compliance reporting Reports compiled manually from each school’s system Trust-wide compliance reports generated from a single platform

The differences become more pronounced as the trust grows. A trust with three schools might find the per-school model manageable. A trust with ten or more schools will find it unsustainable.

What should a trust look for in MAT communication tools?

When evaluating communication platforms for trust-wide deployment, there are several criteria that matter specifically to multi-academy trusts. These go beyond the features that a standalone school would consider.

True multi-tenancy versus shared accounts

Not all platforms that claim to support multiple schools offer genuine multi-tenant architecture. Some simply allow multiple schools to share a single account with limited separation between them. Others offer separate accounts with a shared billing arrangement but no real integration.

True multi-tenancy means:

  • Each school has its own isolated data, branding and content
  • Trust-level settings can be applied across all schools without affecting school-level customisation
  • Trust administrators can view and manage all schools from a single interface
  • New schools can be added quickly without starting from scratch
  • Safeguarding settings can be enforced at trust level

Schools should ask vendors specifically about their multi-tenant architecture. How is data separated between schools? Can trust-level policies override school-level settings? Is there a trust-level admin dashboard?

Consistent safeguarding framework

The platform should allow the trust to define mandatory safeguarding settings that apply to every school and cannot be overridden at school level. This might include:

  • Automatic escalation procedures for conversations that suggest a safeguarding concern
  • Keyword and phrase monitoring that triggers alerts to designated safeguarding leads
  • Conversation logging requirements that cannot be disabled
  • Content guardrails that prevent the chatbot from discussing inappropriate topics
  • Regular safeguarding audit reports that cover the entire trust

The trust’s designated safeguarding lead should be able to review conversations and alerts across all schools from a single view, without needing separate logins for each school.

Scalable pricing

Pricing should reward the trust for scale, not penalise it. A pricing model based on per-student rates that decrease as the total number of students increases is standard for trust-wide deployments. The trust should receive a single invoice and should not pay more per student simply because the students are distributed across multiple schools.

Schools should also consider what happens when the trust grows. If a new school joins the trust, can it be added to the platform quickly and at the same per-student rate? Are there minimum contract sizes that might not suit the trust’s growth trajectory?

Efficient onboarding for new schools

Multi-academy trusts are, by nature, organisations that change. New schools join the trust. Occasionally schools leave. The communication platform must accommodate this reality.

Onboarding a new school should take hours, not weeks. The new school should automatically inherit trust-level safeguarding settings, shared documents and configuration standards. School-specific customisation — branding, local documents, calendar feeds — should be straightforward for the school’s own staff to manage.

Data separation and privacy

While the trust needs visibility across schools for governance purposes, each school’s data must be properly separated. A parent interacting with one school’s chatbot should never see information from another school. School staff should only have access to their own school’s conversations and documents unless they hold a trust-level role.

This data separation must extend to analytics and reporting. Trust-level reports should aggregate data across schools, but school-level reports should only include that school’s data.

For a broader discussion of data protection considerations when deploying AI tools, see our guide on how schools can use AI to manage documents and policies.

How does Ask.School work for multi-academy trusts?

Ask.School is built from the ground up with multi-tenant architecture specifically designed for the way multi-academy trusts operate. Each school in the trust gets its own chatbot with its own branding, knowledge base, calendar feed and conversation history. Parents interact with their school’s chatbot and receive answers specific to their child’s school.

Trust-level administration

Trust leaders access a single dashboard that shows all schools in the trust. From this dashboard, trust administrators can:

  • View conversation volumes and trends across all schools
  • Review safeguarding alerts from any school
  • Set trust-wide safeguarding policies that apply to every school
  • Upload trust-wide documents that are automatically available to all schools’ chatbots
  • Manage user permissions across the trust, with MIS integration through Wonde automating user creation and leaver deactivation at every school
  • View a single billing summary for the entire trust

This centralised view gives trust leaders the oversight they need without requiring them to log into each school’s system separately. For trusts with dedicated safeguarding or compliance roles, this is a significant time saving.

School-level autonomy

Each school in the trust retains full control over its own communications. The headteacher or designated staff member can:

  • Upload school-specific documents and policies
  • Configure the chatbot’s branding to match the school’s identity
  • Connect the school’s own calendar feed
  • Review conversations between parents and their school’s chatbot
  • Manage school-specific content and knowledge base entries

School staff see only their own school’s data unless they also hold a trust-level role. This ensures that schools feel ownership of their communication platform while benefiting from the trust’s centralised infrastructure.

Safeguarding consistency

Ask.School’s safeguarding framework operates at both trust and school level. The trust defines mandatory safeguarding settings — conversation monitoring, escalation procedures, content guardrails and alert thresholds — that apply to every school. Individual schools can add additional safeguarding measures on top of the trust’s baseline, but they cannot disable or weaken trust-level settings.

This means that every school in the trust meets the same minimum safeguarding standard, giving the trust board confidence that KCSIE requirements are being met consistently. The trust’s designated safeguarding lead can review alerts and conversations across all schools from a single interface.

All safeguarding settings align with the requirements of KCSIE 2025 and the Generative AI Product Safety Standards. For a detailed breakdown of how these standards apply to AI tools in schools, see our post on what KCSIE requires of AI communication tools.

Shared and school-specific documents

The document management model in Ask.School mirrors how trusts manage policies in practice:

  • Trust-wide documents (safeguarding policy, complaints procedure, admissions criteria, data protection policy) are uploaded once at trust level and made available to every school’s chatbot automatically
  • School-specific documents (uniform policy, daily timetable, breakfast club details, local procedures) are uploaded by each school and only appear in that school’s chatbot
  • Document updates at trust level propagate immediately to all schools — no manual distribution required

When a parent asks a question, the chatbot draws on both the trust-wide and school-specific knowledge bases. If a parent asks about the complaints procedure, they receive the trust’s complaints policy. If they ask about uniform, they receive their school’s specific uniform policy. The parent does not need to know whether a document is trust-wide or school-specific — they simply receive the correct answer.

Trust billing

Ask.School’s trust pricing — outlined in the billing and subscription guide — is based on the total number of students across the trust. The trust receives a single invoice. As the trust grows and takes on new schools, the per-student cost decreases, rewarding scale rather than penalising it.

There are no separate contracts per school, no individual subscriptions to track and no hidden costs for adding new schools. When a new school joins the trust, it is added to the platform and begins benefiting from the shared infrastructure immediately.

What does a trust-wide deployment look like in practice?

Rolling out a communication platform across a multi-academy trust is a different exercise from deploying one in a single school. It requires planning, stakeholder engagement and a phased approach. Here is what a typical trust-wide deployment looks like.

Phase 1: Trust-level setup

The trust’s central team — typically the IT director or a designated project lead — sets up the trust-level account. This involves:

  1. Defining the trust-wide safeguarding settings that will apply to all schools
  2. Uploading trust-wide documents (policies, procedures, key information)
  3. Configuring trust-level admin permissions
  4. Setting up the billing arrangement
  5. Defining the template configuration that each school will start from

This phase takes a few hours and establishes the foundation that every school in the trust will build on.

Phase 2: Pilot schools

Rather than deploying to all schools simultaneously, most trusts start with two or three pilot schools. These are typically schools with engaged office staff who are willing to provide feedback and help refine the approach.

The pilot schools configure their own branding, upload their school-specific documents, connect their calendar feeds and begin using the chatbot with parents. The pilot period typically lasts two to four weeks, during which the trust gathers feedback from both staff and parents.

Phase 3: Trust-wide rollout

Based on learning from the pilot, the trust deploys to all remaining schools. Because the trust-level settings, shared documents and configuration template are already in place, onboarding each additional school is significantly faster than the pilot schools.

Each school needs to:

  1. Configure its branding (logo, colours, school name) via the school profile settings
  2. Upload school-specific documents
  3. Connect its calendar feed
  4. Designate a staff member to manage the school’s chatbot
  5. Share the chatbot link with parents

For schools that already have well-organised digital documents, this process takes less than a day. For schools that need to digitise paper-based information, it may take longer — but this is time well spent regardless of the communication platform being used.

Phase 4: Ongoing management

Once deployed, the ongoing management burden is relatively light. Trust-level tasks include:

  • Reviewing safeguarding alerts and conversation trends
  • Updating trust-wide documents when policies change
  • Onboarding new schools as the trust grows
  • Reviewing usage reports and identifying schools that might need additional support

School-level tasks include:

  • Updating school-specific documents and calendar information
  • Reviewing conversations to identify common questions that could be better answered
  • Sharing the chatbot with new parents joining the school

How should trusts measure the success of their communication platform?

Deploying a trust-wide communication platform is an investment, and like any investment, it should be measured against clear outcomes. Here are the metrics that trust leaders should track.

Reduction in routine phone calls

The most immediately measurable benefit is a reduction in routine phone calls to school offices. Schools using AI-powered chatbots typically see a 40 to 60 per cent reduction in routine queries within the first few weeks. Across a trust of ten schools, this represents a substantial recovery of staff time.

To measure this effectively, trusts should establish a baseline call volume at each school before deployment and track it monthly afterwards. The reduction will not be uniform — schools with higher initial call volumes will typically see larger absolute reductions.

For more detail on how AI chatbots reduce phone calls, see our guide on how AI chatbots reduce school office phone calls.

Parent engagement rates

Track how many parents are using the chatbot at each school. High engagement rates indicate that parents find the service useful. Low engagement at a particular school might indicate that parents are not aware of the chatbot, that the school’s knowledge base needs improvement, or that the chatbot is not being actively promoted.

Trust-level reporting should compare engagement rates across schools, identifying both high performers (whose approaches can be shared) and schools that might need additional support.

Response accuracy

Monitor the quality of answers the chatbot provides. Most AI chatbot platforms, including Ask.School, log conversations that can be reviewed by staff. Regular review helps identify:

  • Questions the chatbot cannot answer (suggesting gaps in the knowledge base)
  • Questions the chatbot answers incorrectly (suggesting documents that need updating)
  • Questions that are asked frequently (suggesting information that should be more prominent on the school’s website or in communications)

Safeguarding compliance

Track safeguarding metrics across the trust:

  • Number of safeguarding alerts triggered at each school
  • Response times to safeguarding alerts
  • Consistency of safeguarding settings across schools
  • Compliance with trust-level safeguarding policies

These metrics give the trust board evidence that safeguarding standards are being maintained consistently.

Cost per school

Calculate the total cost of the communication platform divided by the number of schools and compare it with what individual schools were spending on separate tools previously. In most cases, a trust-wide deployment is significantly cheaper per school than individual subscriptions, even before accounting for the staff time saved on configuration and maintenance.

What about schools that are not yet part of a MAT?

The multi-tenant approach is not exclusively for existing MATs. Schools considering academisation or those exploring collaboration with neighbouring schools can also benefit from understanding how trust-wide communication platforms work.

Schools considering joining a MAT

For a school that is about to join a multi-academy trust, knowing that the trust uses a multi-tenant communication platform is reassuring. It means the school will not need to rip and replace its existing communication tools at the last minute. Instead, it will be added as a new tenant within the trust’s existing platform, inheriting trust-level safeguarding settings and shared documents immediately while retaining control over its own school-specific content.

Standalone schools planning for the future

Even for schools that are not currently part of a MAT, choosing a communication platform with multi-tenant capability is a sensible forward-looking decision. If the school does join a trust in the future, migration will be straightforward. If it does not, the school still benefits from the same platform features — it simply operates as a single-school deployment.

Collaborations and federations

Some schools collaborate formally or informally without being part of a MAT. Teaching school alliances, local authority partnerships and informal clusters of schools can also benefit from shared communication infrastructure. A multi-tenant platform allows these groups to share certain resources (such as common policy documents) while maintaining the independence of each school.

What regulatory frameworks should trusts consider?

Multi-academy trusts deploying communication tools across multiple schools must consider several regulatory frameworks that apply to the use of AI and digital tools in education.

Keeping Children Safe in Education (KCSIE)

KCSIE 2025 is the statutory guidance that governs safeguarding in schools and colleges. Part 2 of KCSIE covers the management of safeguarding and places responsibility on the governing body — in a MAT context, the trust board — for ensuring that safeguarding policies are in place and effective.

When deploying a communication platform across a trust, the trust board needs assurance that the platform meets KCSIE requirements. Specifically:

  • The platform includes appropriate filtering and monitoring
  • Safeguarding concerns are identified and escalated appropriately
  • Staff receive training on how the platform handles safeguarding
  • There is a clear process for reviewing and updating safeguarding settings

UK GDPR and the Data Protection Act 2018

Data protection obligations multiply in a MAT context because the trust is processing data across multiple schools. The trust, as the data controller, must ensure that any communication platform it deploys complies with UK GDPR requirements across every school.

Key considerations include:

  • Lawful basis for processing: The trust must identify a lawful basis for processing personal data through the communication platform
  • Data minimisation: The platform should collect only the data necessary for its purpose
  • Data separation: Each school’s data must be appropriately separated, even within a shared platform
  • International transfers: Data should be stored within the UK or in a jurisdiction with an adequacy decision
  • Data Protection Impact Assessment: A DPIA should be completed before deploying the platform across the trust

The ICO’s guidance on DPIAs provides a framework for this assessment.

Generative AI Product Safety Standards

The Generative AI Product Safety Standards published by the UK government set specific requirements for AI products used in education. Trusts should ensure that any AI-powered communication platform they deploy meets all 14 requirements.

These standards cover areas including safeguarding by design, transparency, accountability, content accuracy and data protection. For trusts deploying across multiple schools, the standards provide a useful baseline for evaluating whether a platform is fit for purpose.

DfE guidance on AI in education

The Department for Education’s guidance on generative AI in education provides additional context for how schools should approach AI tools. While not statutory, this guidance reflects the department’s expectations and is likely to inform future Ofsted inspection frameworks.

What are the common objections to trust-wide deployment?

Any trust-wide initiative will encounter resistance. Understanding and addressing common objections helps trust leaders make the case for a centralised communication platform.

“Our schools are too different for a single platform”

This objection confuses platform consistency with content consistency. A multi-tenant platform does not require schools to communicate the same things in the same way. Each school retains its own branding, its own content and its own voice. The platform is consistent; the communications are as individual as each school.

The analogy is useful: every school in a trust might use the same finance system, but each school has its own budget. The system is shared; the data and decisions are local.

“Our schools have already invested in their own tools”

Sunk cost should not dictate future strategy. If individual schools have existing communication tools, the trust should evaluate the total cost — including staff time for configuration, maintenance, separate billing and the lack of safeguarding oversight — against the cost of a trust-wide solution.

In most cases, the trust-wide solution is cheaper in both direct costs and staff time, even before accounting for the improved safeguarding oversight and consistency.

“It will take too long to roll out”

A phased rollout, starting with pilot schools and expanding progressively, is manageable within a single academic term. The initial trust-level setup takes hours. Each school’s configuration takes a day or less. Most trusts can complete a full rollout within four to six weeks.

“Schools will lose their autonomy”

As discussed above, a well-designed multi-tenant platform actually increases school autonomy by removing the burden of technology management. Schools gain time to focus on what matters: communicating effectively with their parent community. The trust handles the infrastructure; the school handles the content.

“We should wait until we have more schools”

There is no minimum trust size for a trust-wide communication platform. Even a trust with two schools benefits from shared safeguarding settings, shared documents and centralised billing. Starting early means the infrastructure is already in place when new schools join, making their onboarding faster and smoother.

What steps should a trust take to get started?

For trust leaders ready to evaluate a trust-wide communication platform, here is a practical starting point.

Step 1: Audit current communication tools

Survey every school in the trust to understand what communication tools are currently in use. For each school, document:

  • The platforms in use (website, parent app, chatbot, email, social media)
  • The annual cost of each platform
  • Who manages the platform (school office, IT team, external provider)
  • Whether safeguarding settings have been configured and reviewed
  • Parent satisfaction with current communication channels
  • Common parent queries that are not well served by current tools

This audit will provide the evidence base for the business case and help identify the specific problems a trust-wide solution needs to address.

Step 2: Define trust-level requirements

Before evaluating vendors, agree on the requirements that matter at trust level:

  • Mandatory safeguarding settings
  • Shared documents that should be available across all schools
  • Reporting and analytics requirements
  • Billing and procurement preferences
  • Data protection requirements
  • Integration with existing trust systems

Step 3: Evaluate platforms against MAT-specific criteria

Use the criteria outlined above to evaluate candidate platforms. Pay particular attention to genuine multi-tenancy, safeguarding consistency and scalable pricing. Ask vendors for references from other MATs of similar size.

Step 4: Pilot in two or three schools

Select pilot schools that represent the range of your trust (different sizes, different phases, different levels of digital maturity). Run the pilot for two to four weeks and gather structured feedback from staff and parents.

Step 5: Plan the trust-wide rollout

Based on pilot learning, plan the rollout schedule for remaining schools. Assign a project lead, set clear timelines and ensure each school has a designated person responsible for school-level configuration.

Step 6: Monitor and iterate

After deployment, use the metrics outlined above to monitor performance. Share best practice across schools. Review and update trust-level settings regularly. Treat the communication platform as a living system that improves over time, not a one-off project.

Where does this sit within a broader trust technology strategy?

Communication is just one part of a trust’s technology landscape, but it is an important one because it directly affects the experience of every parent who interacts with the trust. The principles that apply to trust-wide communication — centralised oversight, school-level autonomy, consistent safeguarding, shared resources and scalable pricing — apply equally to other technology decisions.

Trusts that get their communication infrastructure right often find that the model serves as a template for other technology deployments. The governance structure, the balance between central control and school autonomy, and the approach to vendor management can all be replicated across other systems.

For this earlier exploration of MAT communication challenges, see our post on managing parent communications across a multi-academy trust.

Summary

Multi-academy trusts face communication challenges that standalone schools do not. Inconsistent parent experience, duplicated configuration effort, fragmented safeguarding oversight and complex billing arrangements are the natural consequences of allowing each school to manage its own communication tools independently.

A multi-tenant communication platform addresses all of these challenges by providing a shared infrastructure that each school can customise for its own community. Trust leaders get the oversight and consistency they need. Schools get the autonomy and flexibility they want. Parents get a reliable, professional communication experience regardless of which school in the trust their child attends.

The choice between per-school and trust-wide deployment is not simply a technology decision. It is a governance decision that affects safeguarding, financial management and the quality of every parent interaction across the trust. For trusts that take their responsibilities seriously, a trust-wide approach is not just more efficient — it is more responsible.

See Ask.School’s trust pricing at ask.school/pricing.