NZ School PA, Paging & Bell System Requirements

The short version: what a NZ school should specify

Start with the operational job, not a product name. A useful brief should tell every bidder who needs to hear what, where, from which control points, under normal conditions and during an emergency. It should also make clear what existing infrastructure may be reused and who owns the network, support and administration after handover.

If those eight items are written clearly, suppliers can propose different technical approaches while still solving the same problem. That is much easier to compare than asking several installers for a generic "school PA system" and receiving three completely different scopes.

What the Ministry guidance actually says

The Ministry of Education's current Designing Schools in Aotearoa New Zealand standards are mandatory for new builds and are to be applied where practicable to maintenance and refurbishment work. The Ministry's 2026 public-address and safety-warning section is unusually direct about the job a school PA system needs to support.

The guidance says public-address systems should have capacity for fire, lockdown and other safety-warning signals needed by the school, school bells, voiced announcements and paging. It also says speaker quality and placement need to support clear speech intelligibility in learning areas. For hearing-impaired learners, the guidance calls for strobe-light warning systems where required and says newly installed safety systems should support future addition of strobes.

That does not prescribe one brand or one architecture. It defines outcomes. This is why SmartComms recommends turning the outcomes into a site-specific brief before comparing platforms.

Read the Ministry's current school design standards on Designing standards for New Zealand schools.

Emergency planning comes first

The Ministry's emergency-planning guidance separately asks schools to have emergency warning systems that can alert staff and students when evacuation or lockdown or shelter-in-place is required, and to have a communication plan covering staff, students, whānau and external services. The practical implication is important: the technology supports the school's emergency-management plan. It should not invent the procedure on behalf of the school.

See the Ministry's emergency and traumatic incident planning guidance and SmartComms' school emergency communication guide.

Coverage, zones and intelligibility

A specification should describe where speech must be understood, not simply count speakers. A typical school can contain very different acoustic environments: carpeted classrooms, hard corridors, a reverberant hall, a gym, workshops, covered courts, fields and detached blocks. The system needs to be designed around those spaces.

Build a coverage map before asking for brands

• Mark every classroom, office, staff area, library, hall, gym and specialist room that needs routine announcements.
• Mark outdoor spaces including courts, fields, bus areas, gates, assembly areas and covered walkways.
• Identify high-noise areas such as technology workshops, kitchens and some sports spaces.
• Identify spaces where a hearing-impaired learner or staff member may need a visual warning pathway.
• Record areas where sound spilling into neighbours or nearby classrooms needs to be controlled.

Then define zones around how the school works

Zones should follow operational needs. A school may need a whole-site page, junior and senior blocks, indoor and outdoor groups, a hall-only zone and individual room addressing. A flexible IP system can make software zoning easy, but the specification still needs to say what staff actually need to select.

Published NZ projects illustrate why this matters. Edwards describes Three Kings Primary using classroom, common-area and four outdoor zones. The Thorndon Primary case study describes zone-specific announcements and individual speaker volume management. These are different technical implementations, but both start from the same question: which areas need to be controlled independently?

Bell schedules and daily announcements

Bell scheduling sounds simple until term dates, alternate timetables, assemblies, exams, teacher-only days, weather changes and one-off events are involved. The brief should establish who can edit the calendar, whether schedules can differ by zone, how a bell is paused or advanced, and what happens when the network or controller is unavailable.

There are several valid ways to modernise school bells

The NZ market demonstrates that a bell upgrade does not always require a complete PA replacement. SchoolBells.nz publishes a web-managed scheduler designed to work with existing class-change bell sounders. Edwards' Netbell material describes network scheduling that can automate an existing bell system or interface into PA equipment. At the other end of the spectrum, FrontRow, Axis and other network-audio platforms can make the bell schedule one function inside a wider paging and emergency-communication system.

That is why the specification should describe the outcome and existing equipment first. If the current sounders, amplifiers or speaker lines remain useful, the best-value answer may be a control upgrade or hybrid design. If coverage, zoning and emergency communication are all deficient, a broader replacement can make more sense.

For the upgrade choices in more detail, use the school bell and announcements guide.

Lockdown and emergency communication

Emergency functionality should be specified as a workflow, not as a checkbox that says "lockdown capable". Ask suppliers to demonstrate how an authorised staff member starts an alert, what is heard or seen, how normal bells and announcements are overridden, how the message is repeated, how the event is cancelled and how the all-clear is issued.

Write these questions into the brief

• What events are required? For example lockdown, evacuation, shelter in place, medical or another school-defined response.
• Who can trigger them? Reception, principal, selected offices, software users, physical buttons or another approved control point.
• How many trigger locations are needed? Avoid a design that depends on reaching one desk during an incident.
• What takes priority? Emergency audio should not be blocked by routine bells, music or a normal page.
• What is the cancellation and all-clear process? Staff should not need to improvise it under pressure.
• Which areas receive which message? Whole-site and zone-specific use cases may differ.
• What happens during a power, server or network fault? The required resilience should be agreed for the project rather than assumed from a product brochure.
• Are visual warnings required? Include accessibility and future strobe integration where the school's needs require it.

Three Kings Primary's published system used two paging stations for emergency activation and pre-recorded messages. Ormiston's published FrontRow project included lockdown triggers alongside paging and bells. Thorndon's published Axis project used the same network-audio environment for routine communication and lockdown support. The common lesson is not that one product is best. It is that emergency use has to be designed into the operating brief from the start.

Keep, hybrid or replace: three upgrade paths

One of the easiest ways to overspend on a school communication project is to assume every existing component must go. One of the easiest ways to under-specify it is to keep old infrastructure without testing whether it can deliver the required coverage and zones. A good supplier should be able to explain which of the following patterns fits the school and why.

A proposal should make the reuse decision explicit. Ask what was tested, what remains in scope, what becomes the school's future support responsibility and whether retaining old infrastructure limits any required zone, intelligibility or emergency function. SmartComms' traditional vs IP guide explains this trade-off in more detail.

Network, cabling and power

IP paging is not simply "plug it into the network". The school needs to know which switches will carry the endpoints, how much PoE power is available, whether VLAN or multicast configuration is required, where controllers or servers live, how devices are backed up and who supports the network configuration after handover.

Ministry ICT rules matter when the project touches school network infrastructure

The Ministry says data-cable installation, wireless integration and structured-cabling product supply in schools must use approved ICT contractors and approved products. It also publishes technical standards for school cabling, switching and wireless networks. If a paging project requires new structured cabling or changes to the school's ICT infrastructure, the communication-system installer and the approved ICT contractor may need clearly separated responsibilities.

The Ministry's school-led network-upgrade process also emphasises defining project outcomes, auditing the existing network, confirming a design, testing the finished network and retaining as-built and warranty documentation. Those are sensible disciplines for a network-audio project even where the paging work itself is not a complete network upgrade.

Read the Ministry's ICT contractor standards and processes and use SmartComms' IP paging network readiness checklist before the quote stage.

Ask for a written responsibility matrix

For a networked or hybrid design, the quote should identify who is responsible for data cabling, switch ports, PoE capacity, VLANs, multicast or QoS settings if used, UPS power, endpoint configuration, server or cloud administration, firmware, configuration backups and fault diagnosis. Without that matrix, a school can end up between an AV installer and an IT provider when a fault crosses both systems.

What published NZ school projects show

Public case studies are useful because they show how real schools have combined daily and emergency communication. They are still supplier-published accounts, not independent performance tests, and older projects may use products that have since changed or reached end of life. SmartComms uses them to identify design patterns, not to rank installers.

What the supplier market adds beyond those projects

Different NZ suppliers highlight different parts of the decision. SchoolBells.nz focuses on retaining existing class-change sounders while modernising scheduling. Edwards publishes both network bell controllers and integrated school paging examples. Pacific AV's FrontRow material shows server-managed bell, paging and lockdown workflows with interfaces for existing 100V audio. New Era emphasises using the school network for paging, bells and emergency announcements. Axis documents network speakers, software zones, scheduling and audio management. None of those perspectives is the whole specification by itself, but together they show the range of choices a school should make deliberately.

What to put in the supplier brief

The easiest way to get comparable proposals is to give every supplier the same operational brief and ask each one to state where it complies, where it differs and what is excluded. The table below is a useful starting point.

For a shorter version you can attach directly to a request for quotation, use the school PA specification checklist.

How to compare proposals like for like

Do not compare only the equipment total. Two bids can look similar while one includes outdoor coverage, emergency controls, switch upgrades, training and support and the other excludes them. Ask every supplier to respond to the same brief and separate the following costs where relevant.

• Head-end controllers, servers or cloud subscriptions
• Paging consoles, microphones, call stations or software clients
• Indoor speakers, outdoor horns and room interfaces
• Intercom or talkback endpoints where required
• Existing-equipment interfaces and amplifier work
• Structured cabling, patching, network switching or PoE changes
• UPS or other backup-power provision
• Programming, commissioning, coverage testing and staff training
• Software licences, subscriptions, remote support and ongoing maintenance
• As-built drawings, configuration backups and administrator credentials

Then compare the actual operating result. Can reception page one block without disturbing the rest of the school? Can a timetable change be made without a technician? Can the required emergency message be triggered from the agreed locations? Can the school's IT provider identify which network components it owns? A demonstration against the brief is more useful than a feature list.

A practical planning sequence

1. Document the problem. Record current coverage gaps, unreliable equipment, manual bell tasks, emergency-communication limitations and known support issues.
2. Map the site. Mark every area that needs speech, bells, emergency warnings or two-way communication.
3. Decide what might be retained. List current speakers, amplifiers, bell sounders, cabling and network switching without assuming they are either reusable or obsolete.
4. Write the operational brief. Use the requirements and quote table above, then attach the short specification checklist.
5. Get an indicative budget. Use the SmartComms Pricing Tool before formal design so the school has a planning range.
6. Check the funding path. For a state school, use the Funding Checker and then confirm the actual property route with the school's property advisor and current Ministry guidance.
7. Explore finance only if relevant. If spreading the project cost is useful, use the Finance Checker as an indicative starting point.
8. Send the same brief to suitable providers. Compare how each design meets the required outcomes rather than asking each supplier to define the scope for you.

Primary sources and market evidence

The page is built from official Ministry requirements plus public supplier and project material. Product and project examples are included to show design approaches, not as SmartComms endorsements or independent performance tests.

• Ministry of Education: Designing standards for New Zealand schools
• Ministry of Education: Prepare for an emergency or traumatic incident
• Ministry of Education: ICT contractor standards and processes
• Edwards Sound Systems: Three Kings Primary published project
• Pacific AV: Ormiston Junior College published project
• CIE Group: Thorndon Primary School published project
• SchoolBells.nz: existing-bell scheduling approach
• Pacific AV: FrontRow network and 100V integration examples
• New Era Technology: NZ school bell and paging overview

Last reviewed 20 October 2026. Independent synthesis of public Ministry, supplier and project sources. Always confirm current Ministry, building, fire, ICT and procurement requirements for the actual project.