How to run a successful 10-radio PTToC pilot in 30 days

A well-run 10-radio pilot answers three questions before you commit to a fleet-wide rollout: does coverage hold in your real operating environment, does the workflow beat what your teams use today, and can your operations and IT teams support it at scale? This playbook is written as an acceptance process: define what the pilot must prove, observe it under real conditions, log what happened, and make a documented decision at the end.

Use the printable checklist further down as the working document for the pilot itself. Everything below explains how to set it up and how to read the results honestly.

Set the objective before you order anything

Write the pilot objective as a single sentence, then convert it into three to five measurable success criteria with a recorded baseline from your current system. Without a baseline, a pilot produces opinions rather than a decision.

Define a fixed observation window before the pilot begins and publish its start and end dates to everyone taking part. A fixed window keeps the evaluation comparable and stops a pilot drifting into an indefinite trial. Choose the duration that matches your own shift patterns and seasonal conditions.

Choose representative locations, not convenient ones

Pick the sites, routes and structures the fleet actually works in — including the locations people already complain about. Test at the times of day the fleet operates, and repeat each problem location at least twice so a one-off result is visible as a one-off result. Log every location where audio was unusable or a call did not complete.

Scope users, roles and talk groups deliberately

Map each participating role to the talk groups it needs and nothing more, and document at least one cross-role scenario your teams run every day. Assign devices to named users rather than sharing them anonymously, so feedback and failure reports stay traceable. Record what you intentionally excluded from the pilot so the results are not over-read later.

Where a dispatch position takes part, capture dispatcher feedback separately from field-user feedback. The two groups usually fail in different ways.

Optional branch: bridging into an existing radio workflow

Some pilots include a bridge into an existing radio workflow. Treat this as an optional branch and evaluate it only at the workflow level: who talks to whom, in which direction, who owns the bridge, and whether the intended workflow is reproducible for the people who use it daily. Technical suitability for any specific existing radio system must be confirmed with ip³Things before the pilot is configured — it is not something this checklist establishes.

Emergency, audio, battery and network observation

If emergency or SOS handling is included in your pilot configuration, define who receives an alert and what they do next, then run scheduled test activations with participants informed in advance. If it is not included in your configuration, say so explicitly in the results rather than assuming it.

Audio checks belong in the loudest environment your teams really work in, with the accessories they really wear. Ask users to rate intelligibility, not volume. For batteries, record start-of-shift and end-of-shift levels every day alongside usage intensity, and treat the outcome as an observation about your duty cycle rather than a runtime figure. For networks, record what each device reported in each tested location and where users saw degraded service — as observations only, without inferring how selection or recovery behaves from a small sample.

Train, then log everything

Run a short training session for field users and a separate one for any dispatch participants, and record how long it took a new user to complete a first call unaided. Keep one shared log for every failure, exception and surprise, classified as device, configuration, network, process or training, and note whether each was reproducible. That log, not memory, is what the go / no-go review discusses.

After the pilot: expand, revise or stop

Close the window on the date you published and hold a documented decision review against your written criteria. There are three legitimate outcomes, and none of them is a formality.

• Expand — the criteria were met in the representative locations and roles. Move to a staged rollout plan with the same measurement approach applied to each stage.
• Revise and retest — the concept held but something specific did not: a device configuration, an accessory choice, a talk-group design, a location or a training gap. Change one variable set, define a new fixed window, and retest.
• Stop — the criteria were not met, or the operating cost of supporting the configuration is higher than the benefit it delivered. Record why, so the same evaluation does not restart from zero later.

What this checklist does not validate by itself

A pilot is an operational observation exercise. On its own it does not certify or establish any of the following, and results should never be presented as if it did.

• Regulatory compliance for your jurisdiction or sector.
• Interoperability with any radio or system that was not part of the tested configuration.
• Carrier or network behaviour beyond what was observed, in the locations and times observed.
• Security or compliance posture, which requires separate documentation review by your own authorized reviewers.
• Hazardous-location or environmental certification for any device or accessory.

Each of those needs its own evidence, supplied and reviewed separately from the pilot.

Where to go next

ip³Radio product family·ip³PTT platform·InteliGate LMR gateway