What a pilot actually proves and how to measure it
A pilot that only tests the technology answers half the question. It tells you the sensor works in the given environment. It doesn't tell you whether the solution will deliver a safer workplace, six months from now, on an ordinary Tuesday afternoon when nobody's watching. That's the gap a well-designed pilot needs to close, and it's exactly what SonaSafe's implementation approach is built to prove.
3
Elements tested in every SonaSafe pilot — people, process and technology, together
4
Distinct stakeholder groups actively supported through every rollout
30 days
Length of Mainstream NZ's pilot before its results were fully proven
80%
Reduction in near-misses that pilot delivered, measured and documented
The Real Problem
A pilot that only proves the technology has already fallen short
Most safety technology pilots are built to answer one question: does the sensor detect reliably? It's an important question, and it deserves a proper answer. But it's only half the story. A pilot can prove the technology works perfectly and still leave an organisation with a rollout that quietly stalls, because nobody built the habits, the workflows or the trust needed to carry that result forward.
SonaSafe's pilots are deliberately built to close that gap. Rather than testing one thing, they test three, together, and they use a genuinely well-established framework to do it.
The Framework
The Golden Triangle, and why it works
People, Process and Technology — often called the Golden Triangle — is a framework with real pedigree. It traces back to Harold Leavitt's organisational research in the 1960s, and it's still cited today by Forbes, by Prosci, and by change-management practitioners across every industry that's ever tried to make a new system actually stick. The core idea is simple and durable: change one leg of the triangle without the other two, and the whole thing tips.
SonaSafe applies this directly, not as a slogan but as three concrete commitments within every pilot:
People
Worker engagement and genuine buy-in, hands-on training, and alignment to each person's actual role, so the right people are competent and confident before go-live.
Process
Alignment to your existing SOPs, ACOP guidance, HSWA and PCBU duties, hazards and risk identification — so SonaSafe fits the way your site already works, rather than sitting awkwardly on top of it.
Technology
SonaSafe's configurable, rules-based proximity alerts, tuned to the site's real conditions during the pilot itself, not left as a generic factory defa
The Deliverable
Pilot Acceptance Criteria: proof you can point to
Here's what makes this more than a good intention: SonaSafe's implementation approach produces a named, documented deliverable called Pilot Acceptance Criteria, agreed before the pilot even begins. It sits inside the Pilot & Solutioning phase, alongside the installation plan, the hardware configuration, and formal customer approval — not something assessed loosely after the fact, but a clear definition of success everyone has signed off on in advance.
That distinction matters more than it might first seem. A pilot with agreed criteria up front is a genuine decision-making tool. A pilot without one is really just an extended demonstration, however good it looks along the way.
The Human Side
Why confidence dips before it climbs — and why that's expected
Anyone who has led a technology rollout will recognise the shape of what happens next, even if they've never seen it drawn out on a curve. Early enthusiasm, once the risks are identified and the proposal is approved. A dip once installation begins and affected workers start adjusting to something new — the point where you'll hear "this is going to take longer" or "I wish we could go back to the old system." And then, given the right support, a genuine climb: "I've got this sussed," "incidents are trending down," "I feel safer at work."
That dip is simply human nature. A natural fear of the unknown, and an entirely ordinary resistance to change, shows up in almost every technology rollout, for entirely understandable reasons: people don't yet understand why the change is happening, communication has been too one-directional, or those affected haven't been genuinely involved in shaping how it works for them. None of that reflects badly on anyone. It's simply what change looks like when it isn't planned for.
SonaSafe's pilots plan for that dip directly, through a four-step adoption process: identify the stakeholder groups who'll be affected, understand their specific needs and concerns, agree the actions that address them, and then actually execute those actions through communication and training — rather than hoping enthusiasm alone carries everyone through.
The People
Four different people, four different bars to clear
One of the more useful things a properly run pilot reveals is that "success" doesn't mean the same thing to everyone watching it. Four groups typically need convincing, and each one is looking for something genuinely different.
The end user, on the ground
Wants to feel safe at work, and needs to see the system as protection, not surveillance. Clear, jargon-free training and honest answers to early scepticism matter far more here than a features list.
The supervisor, coaching the team through it
Needs confidence the system is genuinely tuned to their team's real workflow, with a low false-alert rate, so they're not fielding complaints about a system that cries wolf.
The internal safety champion, owning the rollout on site
Needs a clear, detailed understanding of how SonaSafe works end to end, and the confidence to handle objections from their own team as they come up.
The executive sponsor, backing the investment
Wants scalable, consistent safety practice across sites, minimal disruption to day-to-day operations, and a clear line from cost to benefit they can stand behind.
A pilot that satisfies only one of these groups hasn't really proven anything yet. A pilot built to satisfy all four is one an organisation can genuinely scale with confidence.
The Specialist Support
Why SonaSafe brought in a change management partner
Getting the People leg right takes real expertise, and SonaSafe treats it that way. SonaSafe has engaged SysDoc, a dedicated organisational change management consultancy, to research how adoption actually plays out on real sites and to develop change and communication material that can be tailored to each rollout. That's a deliberate choice, not a footnote: the people side of a pilot gets the same level of genuine attention as the technology side, rather than being left to work itself out after go-live.
THE PATTERN
What this means for how a pilot should be judged
Technology proof and adoption proof are different questions
A pilot that only answers the first one is incomplete, however impressive the detection numbers look on their own.
The dip is data, not a warning sign
Confidence naturally wobbles during any real change. What matters is whether the pilot was built to support people through it.
Agreed criteria turn a demo into a decision
Without Pilot Acceptance Criteria settled in advance, there's no objective way to say the pilot succeeded — only an impression that it seemed to.
What Gets Measured
Two sets of numbers, tracked side by side
Safety and technology
- Reduction in near-miss incidents and exclusion-zone breaches, measured against the pilot's baseline
- False-alert rate, tuned down as the system is configured to real site conditions
- Detection reliability, confirmed under the site's own layout, lighting and traffic patterns
People and adoption
- Correct use of and engagement with the deployed system, tracked from day one of training
- Engagement through feedback channels, and how quickly concerns raised are actually addressed
- Supervisor-led coaching activity, and whether safe habits are visibly forming, not just being tolerated
Both sets feed the same dashboard and executive reporting, which is the point: a pilot's success isn't one number. It's a documented picture of whether the technology worked and whether the organisation was ready for it, side by side.
Bringing It Together
Why the pilot is the rollout, in miniature
SonaSafe's Tagged deployment options are designed for: non-line-of-sight detection that works in all weather conditions. Where there is visual obstruction such as a container hold on a vessel, SonaSafe provides real-time alerts reaching both the worker and the equipment operator, regardless of if they can see each other. Because every terminal's crane operations differ, getting the configuration right is exactly what a properly run pilot is for — testing the zone against how loads actually move on that specific piece of equipment, before it's introduced as an additional safety layer for your port operations.
Take Slow the Vehicle as a concrete example of the Technology leg being proven properly during a pilot, rather than bolted on afterwards. It's configured through predefined business rules tied to the proximity zones already being tuned during the pilot itself, so by the time a business is deciding whether to scale up, that capability has already been tested in its own real conditions, not just described in a proposal.
That's really the whole point of running a pilot this way. Because People, Process and Technology are all tested together, what a business sees at the end of a SonaSafe pilot isn't a promising proof of concept that still needs a separate adoption project bolted on afterwards. It's a genuine, working preview of life at scale.
That's ultimately why SonaSafe's methodology is structured this way. A successful technology rollout isn't just about good sensors — it's about making sure people, process and technology needs are properly aligned from the very start, and a pilot built to prove all three together is what makes that alignment real, rather than simply a promise on a proposal slide.
Anyone who has led a technology rollout will recognise the shape of what happens next, even if they've never seen it drawn out on a curve. Early enthusiasm, once the risks are identified and the proposal is approved. A dip once installation begins and affected workers start adjusting to something new — the point where you'll hear "this is going to take longer" or "I wish we could go back to the old system." And then, given the right support, a genuine climb: "I've got this sussed," "incidents are trending down," "I feel safer at work."
That dip is simply human nature. A natural fear of the unknown, and an entirely ordinary resistance to change, shows up in almost every technology rollout, for entirely understandable reasons: people don't yet understand why the change is happening, communication has been too one-directional, or those affected haven't been genuinely involved in shaping how it works for them. None of that reflects badly on anyone. It's simply what change looks like when it isn't planned for.
SonaSafe's pilots plan for that dip directly, through a four-step adoption process: identify the stakeholder groups who'll be affected, understand their specific needs and concerns, agree the actions that address them, and then actually execute those actions through communication and training — rather than hoping enthusiasm alone carries everyone through.
Sources
- Harold Leavitt's organisational diamond model and its evolution into the People-Process-Technology "Golden Triangle" framework
- Forbes Technology Council — on the Golden Triangle in digital transformation and procurement
- Prosci — the People, Process, Technology framework in change management
- SonaSafe implementation methodology and organisational change management approach, developed with SysDoc
What would your pilot need to prove?
Every site has a different mix of people, process and technology already in place. A site assessment is the fastest way to work out what your own Pilot Acceptance Criteria should actually look like.
Talk to our team
