How I Set Up the Fire Alarm Test Template with Customers in Pilla

I'm Liam Jones, NEBOSH-qualified health and safety consultant and founder of Pilla. This is how I set up weekly fire alarm testing with customers, based on close to twenty years in frontline operations and advising hundreds of businesses on compliance. You can email me directly; I read every email.

Fire alarm testing is one of those tasks that slips when things get busy. I've walked into sites where the last recorded test was six weeks ago, and when I asked why, the answer was the same every time: "We've been short-staffed." The fire authority won't accept that. Neither will your insurer if something goes wrong.

The fix is not more discipline. It's a better system. If the task lands in someone's list every week with the right fields to fill in, it gets done. That's what this article covers. I'll explain what the law requires, what BS 5839-1 recommends, and how I set up weekly fire alarm testing as a recurring work activity in Pilla so nothing falls through the gap.

Key Takeaways

  • What is a fire alarm test? A weekly check where you activate a manual call point, verify the alarm sounds throughout the building, confirm all sounders and beacons work, and reset the system. You rotate through different call points each week so every one gets tested over time
  • Why do you need weekly testing? The Regulatory Reform (Fire Safety) Order 2005 requires you to maintain fire safety measures in working order, and BS 5839-1 recommends weekly testing of the fire alarm system. Your insurer will want documented proof too
  • How do you set it up in Pilla? Use the work template below, set it as a recurring weekly activity, and assign it to the person responsible for fire safety at your premises
  • How do you automate the follow-up? Set up Poppi to chase staff who haven't completed the test and flag when something fails so you can act on it quickly

Article Content

Understanding What's Required of You

A fire alarm test is a weekly check of your fire detection and alarm system. You activate a manual call point, confirm the alarm sounds throughout the building, verify all sounders and beacons are working, and reset the system. Each week you rotate to a different call point so that over time, every one in the building gets tested.

The legal basis sits in the Regulatory Reform (Fire Safety) Order 2005. As the responsible person, you're required to ensure that fire safety measures, including your alarm system, are maintained in an efficient state, in efficient working order, and in good repair. BS 5839-1, the British Standard for fire detection and alarm systems, recommends weekly testing that includes activation of at least one manual call point. I did my NEBOSH Certificate years ago and this was drilled into us: the standard is weekly, no exceptions for quiet periods, holidays, or refurbishments.

The consequences of not testing are straightforward. Equipment fails silently. Sounders stop working, call points get stuck, wiring degrades, backup batteries die. Without testing, you won't know until there's a real fire. Your insurer will want documented evidence of regular testing too. If a fire occurs and you can't show your system was being maintained, your claim could be rejected.

Fire authority inspectors check testing records. Missing or incomplete records can result in enforcement notices, fines, or prohibition orders that close your premises. I've seen businesses receive improvement notices for gaps as short as three weeks in their testing log. The inspector's view is simple: if it's not recorded, it didn't happen.

There's also the false confidence problem. Staff and customers assume the alarm will warn them. A system that fails during a real emergency is worse than no alarm at all, because people have relied on it and lost evacuation time they could have used responding to other cues like smoke or shouting.

Testing should happen at the same time on the same day each week. This means building occupants expect it and won't panic when the alarm sounds. It also means they know that if the alarm goes off at any other time, it's real. Choose a quiet period: early morning before opening, or mid-afternoon during a lull. And rotate your call points systematically. Number them, create a schedule, and work through it. If you only test the one nearest the panel, you'll find faults in the others when it's too late.

Setting It Up as a Work Activity

I've built a fire alarm test template in Pilla covering call point identification, the testing checklist, the pass/fail result, and a notes field for recording faults and follow-up actions. It gives you a structured starting point that captures what a fire authority inspector wants to see.

In Pilla, create a new work activity using this template and tag it with "Health and Safety Checks". Set it as recurring weekly on your chosen day and time, and assign it to the person responsible for the test. The activity will land in their task list each week with the right fields to complete. Use the same tag across all of your health and safety checks so they're grouped together and Poppi can track them as a set.

1. Call point tested

Before you activate the alarm, record which manual call point you're testing this week. This creates a log showing that all call points are being covered over time.

Why it matters:

Manual call points can fail individually. A call point might become stuck, disconnected, or damaged without any visible sign of a problem. If you only ever test the same call point, you'll never discover faults with the others.

Rotating through all call points ensures full coverage. Over a few months, every call point in your building should be tested at least once. This catches location-specific problems like water damage, physical impact, or wiring faults.

What good answers look like:

Be specific about location. Anyone reading the record should be able to identify exactly which call point was tested.

  • "Main entrance, right side of front door"
  • "Kitchen corridor, by fire exit"
  • "First floor landing, top of stairs"
  • "Call point #7 (bar area, near cellar door)"

If your call points are numbered, use the numbers consistently. If they're not numbered, consider adding labels to make record-keeping easier.

How to answer this for yourself:

Before testing, identify the call point you'll use this week. Check your previous records to see which ones have been tested recently. Choose one that hasn't been tested for a while, or follow your rotation schedule.

Walk to the call point and note its location in clear terms. Think about how you'd direct someone to that exact spot if they needed to find it.

Common mistakes (and how to avoid them):

"Fire alarm call point" -- This is too vague. You might have a dozen call points. Which one?

"The usual one" -- Testing the same call point every week defeats the purpose of rotation. Force yourself to move around the building.

Forgetting to rotate -- Create a simple schedule or checklist showing all call points and when each was last tested. Follow it systematically.

Not recording the location -- If you don't write it down immediately, you'll forget which one you tested. Record it before you activate the alarm.

Best practices to follow:

  • Number or label all manual call points in your building
  • Create a rotation schedule showing which call point to test each week
  • Record the location before activating the alarm
  • Ensure every call point is tested at least once per quarter
  • Check the call point visually before testing: is it damaged, obstructed, or clearly marked?

2. Fire alarm test checks

This is the main testing procedure. Work through each item systematically to verify the system functions correctly from activation to reset.

Why it matters:

A fire alarm system has multiple components that must all work together. The call point must trigger the panel, the panel must activate all sounders and beacons, and the system must reset cleanly afterwards. Testing each step confirms the whole chain is working.

If you only check that the alarm sounds, you might miss a sounder that's failed in a distant part of the building, a beacon that doesn't flash, or a panel that doesn't communicate with your monitoring company. Systematic checking catches these problems.

What good answers look like:

Each checklist item should be physically verified, not assumed. Don't tick "alarm sounded correctly throughout building" while standing next to the panel. Walk the building and listen.

Detailed guidance for each check:

Notified all occupants before testing

Before activating the alarm, warn everyone in the building. This prevents panic, allows people to prepare (hearing protection, pausing phone calls), and ensures no one calls emergency services for a test.

Use whatever method works for your premises: verbal announcement, tannoy system, email, or text message. Make sure the notification reaches everyone, including those in back-of-house areas, offices, or outdoor spaces.

Activated call point

Break the glass or lift the cover on the manual call point to trigger the alarm. Use the test key if available, as this allows you to activate without breaking the glass element. If you must break the glass, have replacement glasses ready.

Note the time you activated the alarm. This helps verify prompt response from monitoring companies and confirms the system triggers immediately.

Alarm sounded correctly throughout building

Walk through the building while the alarm is sounding. Listen in every room, corridor, and outdoor area where people might be. The alarm should be clearly audible everywhere, not just loud, but unmistakably a fire alarm.

Pay attention to:

  • Areas with high ambient noise (kitchens, plant rooms, entertainment areas)
  • Enclosed spaces (toilets, storage rooms, offices)
  • Areas where people use hearing protection or headphones
  • Outdoor spaces like beer gardens or smoking areas

If you can't hear the alarm clearly in any area, that's a fault that needs addressing.

All sounders and beacons activated

As you walk the building, check that every sounder is making noise and every visual beacon is flashing. Sounders can fail individually. A building might have ten sounders with one silently failed.

Visual beacons are essential for people with hearing impairments. They must flash brightly and be visible from all areas they're meant to cover.

System reset successfully

After testing, reset the system using the control panel. The alarm should stop, the panel should return to normal status, and there should be no fault indicators. A system that won't reset cleanly may have an underlying problem.

Check the panel display carefully. Are there any fault codes, warning lights, or error messages? These indicate problems that need investigation even if the test otherwise passed.

Notified monitoring company (if applicable)

If your fire alarm is monitored by a third-party company (who alert the fire brigade when the alarm activates), you must tell them before and after testing. Otherwise, they might dispatch emergency services to a test, wasting resources and potentially incurring charges.

Follow your monitoring company's procedures. This usually means calling before you test to put the system "on test" and calling afterwards to confirm testing is complete.

Common mistakes (and how to avoid them):

Standing at the panel for the whole test -- You can't verify the alarm sounds throughout the building without walking the building. Delegate panel duties to someone else while you walk around.

Rushing through the checklist -- Each item requires actual verification, not a quick glance. The test takes a few minutes, not a few seconds.

Forgetting the monitoring company -- This can result in fire brigade call-outs, charges from your monitoring company, and embarrassment. Put "notify monitoring company" at the top and bottom of your procedure.

Ignoring minor issues -- A sounder that seems "a bit quiet" or a beacon that flickers might be about to fail completely. Report and investigate anything unusual.

Best practices to follow:

  • Use two people: one at the panel, one walking the building
  • Have a floor plan marked with sounder and beacon locations
  • Record the time taken for the alarm to activate after triggering the call point
  • Check all areas, including those not normally occupied during tests
  • Test during conditions similar to normal operation (music playing, kitchen equipment running)

3. Test result

After completing all checks, record whether the system passed or failed the test overall.

Why it matters:

The pass/fail result creates a clear record of system status. Over time, this shows whether your fire alarm is reliably working or developing problems. A pattern of failures indicates systemic issues that need addressing.

This field also triggers different follow-up actions. A pass means normal operation continues. A fail means immediate investigation and repair.

What good answers look like:

Pass, system working correctly: All components functioned as expected. The alarm activated promptly, sounded throughout the building, all sounders and beacons worked, and the system reset cleanly.

Fail, issue identified: Something didn't work correctly. This could be a call point that wouldn't activate, a sounder that didn't sound, a beacon that didn't flash, a panel error, or any other malfunction.

Be honest. If anything was wrong, even something minor, record it as a fail and document the issue in the notes. You can still operate while arranging repairs, but you need the failure on record.

How to answer this for yourself:

Ask yourself: "If there was a real fire right now, would this system reliably alert everyone in the building?"

If the answer is anything other than a confident "yes," that's a fail. Don't let small issues slide. They become big issues.

Common mistakes (and how to avoid them):

Recording "Pass" when there were minor issues -- Minor issues are still failures. A sounder that's "a bit quiet" in one room is still a sounder that might not wake someone in that room during a night-time fire.

Forgetting what happened during the test -- Fill in the result immediately after completing the test. Don't wait until the end of the day when details have faded.

Pressure to pass -- No one wants to report failures, but unreported failures become real emergencies. A documented fail that gets fixed is far better than an undocumented problem that persists.

Best practices to follow:

  • Record the result immediately after testing
  • Be conservative: when in doubt, record it as a fail and investigate
  • Use the notes field to explain any concerns, even for tests that pass
  • Track pass/fail rates over time to identify deteriorating equipment

4. Notes

Use this field to record any observations, issues, or actions taken during or after the test.

Why it matters:

The checklist and pass/fail result capture the basics, but the notes capture the detail. If something went wrong, this is where you explain what happened and what you did about it. If everything was fine, this confirms there were no concerns.

Notes are invaluable for:

  • Explaining failures to maintenance contractors
  • Demonstrating due diligence to fire authority inspectors
  • Tracking recurring issues over time
  • Reminding yourself what happened when reviewing old records

What good answers look like:

For a straightforward pass:

  • "All working correctly. No issues observed."
  • "Test completed successfully. Full building walk-through confirmed all sounders audible."

For a pass with minor observations:

  • "Pass. Noted that call point cover was stiff to lift, may need lubrication. Sounder in ladies' toilets seemed quieter than usual but still clearly audible."
  • "System working correctly. Panel showed low battery warning, scheduled battery replacement for next week."

For a fail:

  • "Sounder in first floor office did not activate. Alarm audible from corridor but not inside office with door closed. Reported to [maintenance company], engineer visiting tomorrow."
  • "Call point would not activate, button stuck. Used call point #4 instead for test (passed). Faulty call point reported and labelled out of order."
  • "Test failed, panel showed zone 2 fault after reset. Full system inspection booked for [date]. Building still protected by remaining zones."

How to answer this for yourself:

Immediately after the test, ask yourself:

  • Was there anything unusual or concerning?
  • Did any component behave differently from normal?
  • Are there any actions I need to take or arrange?
  • Is there anything the next person doing this test should know?

Write notes as if you're leaving a message for a colleague who wasn't present. Give them enough detail to understand what happened.

Common mistakes (and how to avoid them):

Leaving notes blank -- Even "No issues" is useful information. Blank notes suggest the test might not have been done properly.

Vague descriptions -- "Sounder not working" doesn't help the engineer. "Sounder in first floor office (above bar, near window) did not activate. Other sounders working normally" gives them what they need.

Not recording actions taken -- If you reported a fault, who did you report it to? When is it being fixed? This matters for demonstrating you acted on the problem.

Only noting failures -- Positive observations are valuable too. "New sounder in beer garden is very audible" helps when planning future improvements.

Best practices to follow:

  • Write something in this field for every test, even if just "All working correctly"
  • Be specific about locations and symptoms
  • Record any actions taken and when repairs are scheduled
  • Note anything you want to follow up on next week
  • Include names of people you reported issues to

Automate the Follow-Up with Poppi

Writing the policy is one thing. Making sure your team has actually read it is another. Poppi can handle the chasing so you don't have to.

If you mark the knowledge hub entry as mandatory, Poppi will track who's read it and who hasn't. You can set up automations to chase staff who are behind, notify managers when someone completes the policy, and get a regular report showing where the gaps are.

Here are three automations I'd set up for any knowledge hub policy:

Overdue training reminders

Automatically chase team members who have mandatory policies they haven't read yet. Poppi sends the reminder so you don't have to.

Poppi
Poppi

Tom, you have 2 overdue policies to read and acknowledge

Video completion alerts

Get notified when a team member finishes reading or watching a policy, so you can track progress without chasing.

Poppi
Poppi

Emma has completed a mandatory policy

Training gap analysis

Get a regular AI report showing which team members are behind on mandatory policies and where the gaps are across your team.

Poppi
Poppi

Training Report: 87% team completion. Tom and Sarah behind on 2 mandatory policies, due 3 days ago.