Before You Buy a Home Alarm in Sion: 14 Installer Acceptance Tests

A home alarm is worth considering when it closes a specific gap in a broader protection plan and someone has a clear, realistic job after an alert. It is a poor purchase when the offer stops at a sensor list, a phone notification, or a promise that a house will be “secure.” For a home in Sion, ask the installer to map the actual doors, windows, occupied rooms, daily routines, communication paths, service responsibilities, and privacy boundaries. Then test that design before signing the handover.

The practical deliverable below is a 14-case acceptance protocol. It is a buyer-run checklist for a site visit, written offer, commissioning, and first handover. It is not a tested alarm product, burglary-prevention experiment, installer ranking, or claim that a particular setup prevents crime. The local Sion home-alarm installation guide is a useful starting point for describing the building and the result you want. Use it to prepare a site brief, then make each provider respond to the same facts.

The decision in one paragraph

Start with the problem, not the product. Are you trying to notice an opened door while away, wake someone inside, receive a signal at a staffed alarm receiving centre, or simply add a visible deterrent? These are different outcomes and require different designs. Ask for a written system boundary: what is monitored, what is not, who receives each event, what they do next, and what happens when power or communications fail. If the proposed system depends on cameras, ask whether less intrusive measures could achieve the same goal and keep the recording area tightly limited. Do not infer that an alarm dispatches police, guarantees a response time, reduces insurance premiums, or prevents a loss unless the contract and the competent authority say so.

What the evidence says—and what it cannot say

The Federal Statistical Office’s 2024 chart publishes burglaries with intrusions in dwellings for selected Swiss cities and agglomerations. Its 2024 chart counts burglaries per 1,000 inhabitants and includes attempts as well as cellars, outside storage, and other ancillary rooms. That is useful context for comparing an area-level indicator; it is not a forecast for a particular address in Sion, a measure of an individual home’s vulnerability, or evidence that a specific alarm model works. The FSO methodology explains the denominator and included locations; both matter. Do not turn a city or agglomeration rate into a sales claim about one household.

Swiss Crime Prevention’s “Riegel vor” guidance presents security as a combination of behavioural and organisational measures, mechanical measures, and electronic measures. It says alarm systems can be a useful addition but are not necessary everywhere; a security concept should account for routines and false-alarm triggers such as pets, and should decide in advance what happens when an alarm occurs. Its brochure also warns that a police response to a false alarm may be chargeable. The useful buying implication is not “never install an alarm.” It is “do not accept a system without a realistic alarm plan, user training, and an agreed false-alarm procedure.” Local practices and charges can differ, so ask the relevant Valais police service or alarm receiving centre rather than assuming a national rule.

The research baseline is similarly more nuanced than a feature checklist. The 2025 University of St. Gallen Smart Products Report describes a representative Swiss study of smart-product use and perception, including home automation, and notes that connected products can raise privacy and loss-of-control concerns. A separate Swiss survey study of smart-home adoption used responses from people aged 45 and over and found that comfort, perceived usefulness, and prevention benefits relate to adoption intention. Those studies concern self-reported views and intentions across smart-home concepts; they do not test a burglary alarm, estimate its security effect, or prove that a respondent’s intended use became sustained use. Translate the evidence into questions about day-to-day usability, access, support, and continued maintenance—not into a claim that a particular system is effective.

A consultancy survey provides another caution, not a product verdict. EY’s 2024 “Decoding the Digital Home” coverage reported broad concern among Swiss respondents about managing personal data securely online. This is self-reported, general digital-home context. It does not establish that a security system is unsafe, nor that people will reject one. It does make cloud accounts, recordings, app permissions, and account recovery reasonable subjects for the offer and handover.

The unresolved buyer question

A Swiss homeowner discussion about alarm recommendations begins with a particularly practical problem: a relative had experienced repeated break-ins, a previous installed system had worked poorly, the household wanted something simple enough to operate at night, and the person asked how to avoid triggering it when an older occupant got up. One commenter described a former installer that had closed; another warned that false alarms are stressful. This is a small, self-selected forum conversation, not a survey and not independent technical testing. Its value is that it exposes questions a product comparison often misses: Can a resident move around at night? What happens if an installer disappears? Who can still maintain the system? What does “simple” mean for the actual people living there?

Those are acceptance questions. A brochure may list door contacts, motion detectors, sirens, a mobile app, and a backup link. It rarely demonstrates that a night setting fits a resident’s route to the bathroom, that an alert reaches a person who can act, or that the owner can recover access when a phone is replaced. The matrix below turns those missing details into observable evidence.

A 14-case buyer-run acceptance matrix

Run the cases against the written scope and the installed configuration. Mark each one pass, fail, or not tested. “Not tested” is a legitimate status; it is not a pass. For a test that could create a real alarm, schedule it with the installer and any receiving centre first. Never trigger an emergency dispatch or sounder without an agreed test window.

The matrix is deliberately about observable acceptance, not a weighted score. A critical fail should not be hidden by a high total. For example, a polished app does not compensate for an undefined alert recipient, and a camera image does not prove that an alarm signal reached anyone. Agree in advance which cases are mandatory for your household and what evidence closes each one.

How to run the acceptance visit

Before the visit: provide comparable facts

Give each installer the same short brief. Include the building type, number of floors, approximate age of the existing installation, the entrances and annexes you want considered, occupancy patterns, pets, any person who needs a simpler interface, and whether the property has recurring connectivity problems. State which outcomes matter: notification to a named person, staffed monitoring, local audible warning, or a combination. Avoid sending door codes, alarm credentials, holiday dates, or detailed photographs that reveal valuables in an initial enquiry.

Ask for a site visit whenever the design depends on actual layout, wiring, radio conditions, window construction, shared access, or camera angles. A remote quotation can help establish scope, but it cannot verify those site conditions. If the provider says a visit is unnecessary, ask which assumptions make that safe and which conditions would change the design. A good answer separates known facts, assumptions, and items that must be checked on site.

During the visit: map the system, not just the catalogue

Walk through the building in the same order every time. Start at the property boundary and move through each opening, room, floor, and annex. On the drawing, label the proposed detector, the event it detects, the alarm mode in which it is active, and any known blind spot or exclusion. Ask the installer to explain why a sensor belongs in that location and what expected household activity could trigger it. If the installer proposes a camera, ask whether a door contact, stronger lock, lighting, or another less intrusive measure would address the same goal.

Use plain questions. “What happens when the alarm goes off?” is better than accepting “the system is connected.” Ask whether the event produces a local sound, an app notification, a call to a named person, a transmission to a receiving centre, or several of these. Ask what the recipient is contractually permitted and expected to do. A receiving centre, a mobile notification, and police dispatch are not interchangeable services. Record the exact product and service names; do not infer one from another.

Before signing: make scope and omissions visible

A written offer should identify hardware, installation work, configuration, subscriptions, communication fees, maintenance, call-out terms, and who owns any cloud account. The supplier should mark excluded openings and functions as clearly as included ones. If some features depend on Wi-Fi or a third-party cloud, list those dependencies and identify who supports them. Ask what is retained if you cancel, who can export the settings, whether credentials can be reset, and what happens to devices when a service ends.

Compare offers by function and responsibility, not by sensor count. A two-system comparison is meaningful only if each quote covers the same openings, modes, alert path, maintenance boundary, and handover. If one proposal includes a staffed receiving service and another only sends a phone notification, they are not equivalent even if the equipment list looks similar. Do not assume a monitoring service is available or legally connected to police in Sion; ask the provider and relevant authorities for the specific arrangement.

At commissioning: test with permission and retain proof

Schedule any alarm test with the installer and receiving centre. Confirm who will be told that a test is underway, which signal will be generated, when the test begins and ends, and how it will be closed. A test that is not announced can be interpreted as a real event. Do not call an emergency line to test equipment. If the provider cannot explain a safe test window, mark the case “not tested” and request a written procedure.

For each tested case, record the date, person present, device or zone, expected result, observed result, and any issue. Use a simple result vocabulary: pass, fail, not tested, or not applicable. “It seemed fine” is not evidence. A panel message, supervised test receipt, signed installer checklist, or annotated plan is more useful because another person can review it later. Keep copies in a place the household can access if the app or installer account is unavailable.

Privacy is part of alarm acceptance

A security purchase can add cameras, microphones, cloud accounts, stored events, and third-party access. Under the FDPIC’s video-surveillance guidance, if people can be recognised in private camera footage, the Federal Act on Data Protection applies. The recording area should be limited to the owner’s property; neighbours and public space should not be captured. The purpose must be justified and proportionate, access should be limited, and storage should last only as long as needed. The FDPIC says recordings are usually deleted after 24 hours, but that wording is not a universal fixed deadline for every situation. Its guidance also says less intrusive measures—such as locks, reinforced entrance doors, or alarm systems—should be preferred to video surveillance where they can serve the purpose.

For an installer handover, translate those principles into a walk-through: stand where a visitor would stand; inspect the image; check if a pavement or neighbour’s window appears; verify privacy masks; ask whether microphones can be disabled; list every person who can view live or saved images; and set a retention period that has an explained purpose. If the camera is not necessary to meet the stated goal, remove it from the design. If it is necessary, document why and how the field of view is constrained. A camera being technically capable of recording does not establish that every recording is appropriate.

Connected alarms also raise lifecycle questions. CISA’s Secure by Design guidance is U.S. government guidance directed at technology providers, not a Swiss alarm-installation standard. It is still a useful procurement prompt for a connected product: who takes responsibility for customer security, how updates are delivered, and what the provider does when a weakness is reported? Ask for clear answers about update support, administrator access, account recovery, service dependency, and product end-of-life. If the installer says those are “the manufacturer’s issue,” ask for the manufacturer’s named channel and what local support remains after installation.

The University of St. Gallen report and EY survey provide context for why these questions matter to users, but they do not test alarm products or prove a particular privacy failure. One reports Swiss smart-product perceptions; the other reports broad self-reported digital-home concerns. They are not substitutes for a product security review. Keep the evidence boundary clear: survey concerns motivate questions; only a system-specific inspection or documented supplier answer can close those questions for your chosen installation.

What to do with contradictory advice

Search results and advice pages do not all promote the same balance of measures. Swiss Crime Prevention describes electronic alarms as one possible layer and stresses mechanical and behavioural measures as well. A German police-prevention article can be sceptical of a phone-only smart-home approach, especially where a notification reaches a resident too late to intervene. These positions are not necessarily contradictory: a phone alert alone may be a weak response plan, while a correctly designed alarm can still be useful as one element of a larger arrangement. Jurisdiction and service models also differ. Do not import a German police recommendation as a Swiss legal rule, and do not treat a provider’s sales promise as neutral evidence.

The canton police’s “Spuren” film is useful as a prevention and consequences resource: the Solothurn police page describes investigation, prevention, and the human effects of burglary. It is not an alarm performance test. A video can help a household discuss what matters, but it cannot determine sensor placement, service coverage, or whether a specific intervention works. Use audiovisual material for orientation, then rely on your own site plan, written scope, and supervised acceptance tests.

A second tension is between “more sensors” and “better household fit.” Adding contacts to every opening may increase coverage on paper; it may also add batteries, maintenance tasks, more states to explain, and additional opportunities for accidental triggering. The right design is the smallest one that covers the agreed risks and routines with a documented response path. This is a recommendation derived from the acceptance method, not a measured optimum. There is no universal sensor count that is right for all homes.

A small executable record checker

The following Python example checks whether a buyer’s CSV has one row for each required case and a valid result value. It does not test an alarm, certify an installer, judge whether a result should pass, or assess legal compliance. It only prevents an incomplete paperwork handover from looking complete. Save it as check_alarm_acceptance.py and run it with Python 3. It uses only the standard library.

import csv
import sys
from pathlib import Path

REQUIRED = {str(n) for n in range(1, 15)}
VALID = {"pass", "fail", "not_tested", "not_applicable"}
REQUIRED_COLUMNS = {"case_id", "result", "date", "evidence", "owner"}


def check(path: Path) -> list[str]:
    problems = []
    with path.open(newline="", encoding="utf-8-sig") as handle:
        reader = csv.DictReader(handle)
        columns = set(reader.fieldnames or [])
        missing_columns = REQUIRED_COLUMNS - columns
        if missing_columns:
            return [f"missing columns: {', '.join(sorted(missing_columns))}"]
        rows = list(reader)

    seen = set()
    for line, row in enumerate(rows, start=2):
        case_id = (row.get("case_id") or "").strip()
        result = (row.get("result") or "").strip().lower()
        if case_id not in REQUIRED:
            problems.append(f"line {line}: unknown case_id {case_id!r}")
        elif case_id in seen:
            problems.append(f"line {line}: duplicate case_id {case_id}")
        seen.add(case_id)
        if result not in VALID:
            problems.append(f"line {line}: invalid result {result!r}")
        for column in ("date", "evidence", "owner"):
            if not (row.get(column) or "").strip():
                problems.append(f"line {line}: empty {column}")

    missing = REQUIRED - seen
    if missing:
        problems.append("missing case_ids: " + ", ".join(sorted(missing, key=int)))
    return problems


if __name__ == "__main__":
    if len(sys.argv) != 2:
        raise SystemExit("usage: python check_alarm_acceptance.py acceptance.csv")
    errors = check(Path(sys.argv[1]))
    if errors:
        print("INCOMPLETE — do not treat this handover file as complete")
        for error in errors:
            print("-", error)
        raise SystemExit(1)
    print("STRUCTURE COMPLETE — review all failures and not-tested cases manually")

A header row might look like case_id,result,date,evidence,owner. A case marked fail does not make the CSV invalid; it makes the installation issue visible. A case marked not_tested also remains visible. The checker validates paperwork shape only. It deliberately does not turn a pass count into a safety score, because that would imply that unrelated cases compensate for a critical failure.

Failure modes the buyer should catch

The offer equates an app alert with a response service. Ask what happens when the alert arrives, who is on duty, whether that service is included, and which actions are actually promised. A notification is a message; it is not proof that someone saw it or that a responder was dispatched.

The design works only when nobody is home. Ask for a night mode and demonstrate the routes residents use. A household member should not have to choose between using the home normally and operating a system that was never designed around their movement.

The supplier treats false alarms as a user problem. Ask how settings are reviewed, how a repeated false alarm is diagnosed, who pays for a visit, and whether a receiving centre or police may charge. Obtain the exact contract terms and ask the relevant local authority about any public-service charge. The prevention brochure is a prompt to ask, not a substitute for the local tariff or contract.

The plan protects the wrong boundary. An alarm that ignores a cellar, garage, patio door, or shared entrance may be acceptable, but the omission must be visible. “Whole-house protection” is not a meaningful phrase without a list of included zones.

The owner does not control the account. The installer, previous owner, tenant, or former employee may remain an administrator. The handover should identify the account owner, remove stale users, and show how credentials are reset after a phone or household change.

Connectivity loss is hidden. If monitoring depends on Wi-Fi, mobile service, cloud access, or mains power, an outage changes the system’s behavior. The buyer should know which failure is detected, what the panel shows, what still functions locally, and what must be restored manually. Avoid vague claims such as “it has backup” without naming what is backed up and for how long.

A camera points beyond the protected object. The installer may optimize for a wide image rather than privacy. Test the actual framing, mask neighbouring areas, consider whether audio is needed, and minimize access. If the camera cannot be bounded to the justified purpose, remove it or change its position.

The product becomes unsupported. A device may keep powering on after its app or cloud service is no longer maintained. Ask for update responsibilities and end-of-support terms before committing to an account-dependent product. The Swiss guide does not provide a universal product lifespan; the warranty, software support, and maintenance terms are provider-specific.

There is no transferable record. If the installer closes, changes business, or stops servicing a product, missing zone names, reset instructions, and model numbers can make future maintenance harder. Keep the plan, manuals, serial numbers, configuration export if available, recipient list, and service contacts under the owner’s control.

How to compare two written offers

Create a side-by-side table with one row for each opening or room and columns for event detected, mode, alert destination, included installation work, recurring service, test evidence, and known limitation. Add a separate row for account ownership, data access, updates, maintenance, call-out price, and cancellation. A blank cell is not “included”; it is a question for the provider.

Compare the offers against the same acceptance cases. If one includes a receiving centre and the other sends a notification to the homeowner, keep those options separate. If one proposes cameras and the other proposes contacts and reinforced locks, ask which risk each choice addresses and whether the privacy impact is justified. If an installer recommends a different scope after seeing the site, ask for the reasons and update the brief so the next comparison remains fair.

Do not choose by initial price alone. A purchase may carry recurring monitoring, communication, maintenance, cloud access, battery replacement, and call-out costs. Ask for the total obligations over the period you expect to use the system, but do not invent a lifespan or assume future prices. Request the current amount for each recurring charge and the contractual cancellation mechanism in writing. If a quote omits a fee, ask whether it is zero, optional, or simply outside the offer.

Ask each supplier to state what result they cannot promise. A credible response should distinguish detecting an event, transmitting an event, receiving an event, verifying an event, and physically responding. Each is a separate stage. The installation can improve one stage while leaving another dependent on network availability, a service contract, a person’s availability, or police policy.

The role of local context in Sion

The GSC snapshot used to select this topic covers 1–8 November 2026. For the existing German-language Sion alarm page, it showed four narrowly phrased queries: “alarme maison sion,” “alarme sion,” “installateur alarme incendie sion,” and “installateur alarme sion.” Each had one impression and no clicks, with average positions between 8 and 12. This is a tiny, short-window search sample. It does not show search volume, user satisfaction, future traffic, or causal opportunity. It is enough to justify checking whether the page answers a precise local question; it is not evidence that a new article will rank.

The source page is in German, while the query list is largely French. That mismatch is itself a useful editorial question, but four impressions cannot establish the reason for the observed positions. The page has French, German, and English language variants in its alternate links, but the German URL is self-canonical and indexable. Any future change to language targeting should be assessed with the full page set and search data, not inferred from this small query slice.

Sion is in Valais, so ask for site-specific facts rather than copying an urban burglary rate from another city. The FSO chart is published for selected cities and agglomerations and its definitions include attempts and ancillary premises. If you need local context, use the latest official data at the right geographic level, read the methodology, and distinguish a resident-population rate from a home-level risk estimate. A local figure can describe recorded offences; it cannot inspect your doors, routines, lighting, or communications path.

For practical prevention advice, Swiss Crime Prevention’s “Riegel vor” brochure and the Valais police are more appropriate starting points than a retailer’s headline statistic. The brochure points readers toward their local police for security advice and says that alarm installations need a security concept and intervention plan. Ask whether a police consultation is available for your situation and whether it is informational only. Do not assume the police endorses a particular installer or device.

A compact evidence pack for the household

Keep one folder with the one-page scope, annotated plan, accepted offer, case matrix, commissioning record, product identifiers, account owner, privacy decisions, service contacts, and maintenance dates. Store a copy somewhere accessible to the people who will use the system—not solely in an installer portal or a single person’s phone. If the system is connected, record how to reach support without using the app that may be unavailable during an outage.

The scope sheet should state the purpose in household language. For example: “When we are away, detect opening of the ground-floor doors and send a signal to the contracted receiving centre. The system does not monitor the street, guarantee police attendance, or cover the detached shed.” That is a fictional example of explicit scope, not a recommended configuration for every home. The important structure is purpose, included area, excluded area, recipient, and limitation.

The plan should also name who maintains each part. A homeowner may replace a battery, an installer may service a detector, a manufacturer may maintain the cloud, and a monitoring provider may receive an event. These responsibilities can sit with different organisations. If the contract does not identify the owner of a task, treat it as unresolved. A system is not fully handed over merely because the siren sounds during a demonstration.

A measurement plan, if you want to review reliability later

Do not estimate alarm reliability from a few weeks of anecdote. If you want to assess the installation after handover, create a prospective log before starting. Record only the minimum operational data necessary: date and time, device or zone, event class, whether the event was a scheduled test, whether it was verified, alert route, communication outcome, cause if known, and corrective action. Avoid storing camera footage or personal details unless they are necessary and justified.

Set a review period with the provider, but do not use a short period to claim a burglary-reduction effect. A small home log can answer operational questions such as “Which zone produced repeated avoidable events?” or “Did the planned test reach the named recipient?” It cannot estimate rare-event effectiveness or compare installers without a suitable design, sample, and comparable properties. Separate scheduled tests from real alerts. Record unknown causes as unknown instead of guessing.

A useful report has a denominator. For each planned test, show how many were attempted, how many reached the intended endpoint, how many were blocked by an outage, and how many were not run. For ordinary alerts, distinguish all events from confirmed false alarms and unresolved events. Do not merge “no alarm occurred” with “the system worked”: absence of an event is not a test. The matrix gives you a handover baseline; the later log gives you a way to inspect changes without pretending it is a controlled experiment.

Conditions where this recommendation fails

A 14-case checklist is not a substitute for a qualified installer, building inspection, police advice, electrical work review, or contract review. It does not determine which devices a home needs, whether a system conforms to a technical standard, or whether a particular response service is appropriate. A household with a different risk, mobility requirement, tenancy arrangement, or shared building may need a different list and professional advice.

The privacy section is specifically about identifiable video surveillance by private people in Switzerland. It is not a general legal analysis of every sensor, audio system, workplace, apartment building, or service provider. The FDPIC notes that local authorities may advise or mediate in some disputes and that cases depend on the facts. Seek relevant legal or municipal advice where the proposed camera would capture shared or public areas, employees, tenants, or neighbours.

The statistics are recorded-offence context, not a promise about the future. The studies are about broad smart-product views and adoption intentions, not direct tests of anti-burglary outcomes. Forum posts are individual experience, not representative user research. The buyer-run matrix is authored as a reusable protocol; its 14 scenarios are designed cases, not 14 observed installations. No sample of homes, equipment, vendors, costs, police response, false-alarm rates, or prevented burglaries was measured for this article.

Checklist before accepting the work

• [ ] The written goal describes a household outcome, not only a brand or app.
• [ ] Included and excluded doors, windows, rooms, cellar, garage, and annexes appear on a dated plan.
• [ ] Day, night, away, and authorised-user modes have been demonstrated with the people who will use them.
• [ ] Pets, resident movement, cleaning, and expected visitors are addressed in sensor placement.
• [ ] Each alert path names a recipient and explains the service boundary.
• [ ] Test windows and false-alarm cancellation are agreed before any live signal is generated.
• [ ] Power, internet, mobile, cloud, and support failures have documented behavior.
• [ ] Cameras have a reviewed field of view, justified purpose, limited access, and an explained retention setting.
• [ ] The owner controls account recovery and can remove old users or transfer the installation.
• [ ] Product support, maintenance, subscriptions, call-outs, cancellation, and end-of-support responsibilities are written down.
• [ ] Each of the 14 cases is marked pass, fail, not tested, or not applicable, with evidence and an owner.
• [ ] Every failed or untested critical case has a named next action and date.
• [ ] The household can find the plan, manuals, zone list, support contacts, and test record without relying on one phone.

The acceptance decision should be based on whether the system performs the agreed job for the actual household and whether the owner can maintain and understand it—not on the number of devices or the confidence of a sales presentation. If a critical case remains untested, record the limitation and decide whether to delay acceptance, obtain another visit, or accept the gap explicitly. That keeps the decision auditable and makes a later service call easier to explain.

Sources and method

Source register

• Federal Data Protection and Information Commissioner (FDPIC): video surveillance by private individuals. Official Swiss privacy guidance; read the proportionality, field-of-view, retention, and less-intrusive-measures qualifications.
• Federal Statistical Office: 2024 selected-city chart and indicator methodology. Context on recorded burglary rates and denominator/inclusion rules, not household prediction.
• Swiss Crime Prevention: Riegel vor. Prevention guidance on combining measures, household routines, alarm concepts, and false alarms.
• University of St. Gallen, Smart Products Report 2025. Research context on Swiss smart-product use and perception, not an alarm efficacy study.
• EY Switzerland: Decoding the Digital Home. Survey coverage about broader digital-home perceptions; not product testing.
• CISA: Secure by Design. U.S. provider-facing security principles used only as procurement questions about updates and responsibility, not Swiss standards.
• Solothurn Police: “Spuren” burglary film. Educational material about investigation and prevention, not an alarm trial.
• Home Forum Switzerland: alarm-system discussion. One self-selected user question and comments; treated as anecdotal problem discovery only.

The source review was conducted on 11 November 2026. It covered the Sion alarm-installation page and the four query rows from the Search Console snapshot for 1–8 November 2026; Swiss federal privacy guidance; Federal Statistical Office burglary definitions and the 2024 selected-city chart; Swiss Crime Prevention guidance; a Swiss university smart-products report; a Swiss smart-home adoption study; EY’s digital-home survey coverage; one homeowner forum thread; and a police educational film page. These sources answer different questions and should not be treated as interchangeable.

The original asset is the 14-case buyer-run acceptance matrix and the companion CSV structure checker. The cases were authored for this article by translating the documented failure questions—night-time use, false alarms, installer continuity, alert routing, and privacy—into observable handover checks. The scenario set contains 14 designed cases as of 11 November 2026. It excludes field interviews, real installations, vendor products, pricing, burglary observations, dispatch behavior, and effectiveness measurements. No performance percentage is reported because no such sample was collected.

Facts, inferences, and recommendations are separated throughout. Facts about privacy, statistical definitions, and public guidance are attributed near the relevant passages. The recommendation to compare providers using an identical acceptance matrix is an editorial inference from the differences between search-result summaries, official prevention guidance, research on adoption and comfort, and the forum’s practical user question. The GSC observations are reported as a small, date-bounded internal search sample; they do not establish ranking potential or reader demand.

graph TD
  A[Write down the household outcome] --> B[Map openings, routines and exclusions]
  B --> C[Compare written scope and service boundaries]
  C --> D[Agree safe commissioning tests]
  D --> E[Record pass, fail or not tested]
  E --> F{Critical failure unresolved?}
  F -->|Yes| G[Assign an owner and next action]
  F -->|No| H[Accept with a dated evidence pack]
  G --> D