Customer

Customer Overview

Overview of who Secure Radio is for, what it delivers, and how teams can approach rollout.

Document: Secure Radio Platform Last updated: 2026-05-11 Status: Current Audience: customers, prospective customers, operations leaders, implementation sponsors, customer success teams Portal view: Guides 9 min read

Brand: Secure Radio Communications Ltd, trading as Secure Radio Tagline: "Clear comms. Live control. One operation."

1. Purpose

This document is the customer-facing overview of Secure Radio. It explains:

  1. what the platform is
  2. who it is for
  3. which operational roles it supports
  4. what value it delivers
  5. how to approach rollout and adoption

For role-specific guidance, use the companion customer guides:

  1. Day 0 Free Trial Quickstart
  2. Field Operator Manual
  3. Dispatch Operator Manual
  4. Customer admin guidance provided during managed rollout

2. What Secure Radio Is

Secure Radio is a software-defined operational communications platform for teams that need radio-style workflows with modern identity, governance, and deployment flexibility.

At a practical level, the platform combines:

  1. push-to-talk voice
  2. dispatch visibility and coordination
  3. private and subgroup communications
  4. optional dispatch-requested one-way field video
  5. operator and device identity
  6. tenant-admin controls and live telemetry
  7. controlled RF/DMR interoperability for customers who need to include an existing radio talkgroup in the same operating model

It is designed for operational teams rather than casual collaboration.

3. Who It Is For

Secure Radio is best suited to organizations that:

  1. coordinate field teams in real time
  2. need command-and-control style communications
  3. want selective or subgroup communications as well as shared channels
  4. need stronger identity and governance than consumer communications apps provide
  5. prefer software-defined rollout over rigid hardware-defined systems

Typical customer environments include:

  1. security and patrol operations
  2. event and venue operations
  3. site and facilities operations
  4. infrastructure and utilities coordination
  5. private operational teams that need trusted voice and dispatch visibility

4. Core Roles Supported

The platform is designed around four main user types:

4.1 Field Users

Field users need:

  1. fast transmit and receive
  2. minimal UI complexity
  3. confidence that they are on the right net or talkgroup
  4. predictable behavior under operational stress

4.2 Dispatch Operators

Dispatch operators need:

  1. a command-and-control surface
  2. visibility into units and communications state
  3. fast routing into channels, private calls, and talkgroups
  4. clear cues when a situation needs escalation

4.3 Tenant Administrators

Tenant admins need:

  1. secure onboarding of devices and operators
  2. role and permission controls
  3. talkgroup and feature governance
  4. operational health visibility

4.4 Customer Stakeholders

Operations leaders and customer stakeholders need:

  1. confidence that the platform supports their operating model
  2. a clear deployment and governance story
  3. a path to phased rollout and training
  4. evidence that the system is diagnosable and supportable

5. What The Platform Does

5.1 Shared Operational Channels

Teams can operate on shared channels for broad coordination. This is the simplest operating mode and is often the starting point for rollout.

5.2 Private Or Selective Communications

Users can initiate more directed communications when a conversation should not go to the full channel audience.

5.3 Talkgroups

Talkgroups allow customers to define subgroup communications without needing separate products or fragmented workflows.

For customers who need radio interoperability, a talkgroup can also be attached to a controlled RF gateway route. In that model, selected Secure Radio operators and selected DMR gateway devices share a managed operating group. RF transmit is still governed by tenant policy, operator permission, and push-to-talk arbitration rather than by an open bridge.

5.4 Dispatch Coordination

Dispatch operators can manage operational traffic, monitor units, and coordinate more complex traffic patterns than field clients typically need to see.

5.5 Dispatch-Requested Field Video

Where licensed and operationally approved, dispatch can request a one-way live video uplink from a field unit. The current model is intentionally controlled:

  1. it is enabled per tenant rather than by default
  2. dispatch requests the feed from a named participant
  3. the field user accepts or declines
  4. the field user manually starts the camera after accepting
  5. one active uplink is supported per room at a time
  6. room participants can choose whether to watch while normal audio continues

5.6 Tenant Governance

Tenant admins can control device status, operator permissions, feature availability, and selected operational configuration.

6. Key Value To Customers

6.1 Operational Control

The platform is built for teams where communications are part of operations, not just conversation.

6.2 Identity And Trust

The platform supports device identity and optional operator identity, helping customers move beyond anonymous or weakly governed communications.

6.3 Flexible Rollout

Because the platform is software-defined, customers can phase rollout more easily than with traditional hardware-centric models.

6.4 Multi-Surface Experience

Customers can support field workflows, dispatch workflows, and tenant governance within one product family rather than assembling separate tools.

6.5 Commercial Feature Governance

Because advanced workflows can be enabled per tenant, customers can phase adoption and packaging more deliberately. This is especially relevant for features such as dispatch-requested field video, which may be rolled out only to customers who are ready to operate and govern it.

RF/DMR interoperability should be treated the same way: it is a managed integration surface for customers with a clear radio workflow, licensed RF environment, and agreed operating procedure. It is not required for the standard Secure Radio trial.

7. Typical Customer Rollout Model

The recommended rollout approach is staged rather than all-at-once.

7.1 Stage 1: Define The Operating Model

Before onboarding users, define:

  1. which teams are in scope
  2. which channels are required
  3. whether operator identity is required
  4. which talkgroups are needed at launch
  5. whether any RF/DMR interoperability is in scope
  6. who will act as tenant admins

7.2 Stage 2: Admin Preparation

Tenant admins should:

  1. prepare devices
  2. define operator levels or permission groups
  3. verify which features will be enabled
  4. plan initial user training and support ownership

7.3 Stage 3: Guided Evaluation

For operational validation, use Guided Evaluation with agreed scope, success criteria, support ownership, and customer SOP review. Guided Evaluation typically costs £2,500-£5,000 ex VAT depending on location, team size, and assistance required. Hardware, accessories, and SIM cards are not included, although Secure Radio can help procure, supply, configure, and set up compatible PoC or rugged Android devices and connectivity at additional cost.

If RF/DMR interoperability is in scope, it should be treated as an additional guided module. The DMR gateway module is priced per configured gateway, typically from £250 per gateway per month, ex VAT, on annual terms after the evaluation scope is agreed. A second gateway for a second location or radio route normally means a second gateway module fee. The module includes Secure Radio provisioning and route configuration for each gateway; radios, RF licensing, site radio work, gateway hardware, SIMs, backhaul, and ongoing connectivity costs are separate unless agreed.

Start with a pilot group:

  1. a small field cohort
  2. at least one dispatch operator
  3. at least one tenant admin

This allows the customer to validate channels, private calls, talkgroups, and governance before wider rollout.

7.3.1 Free Trial Starter Flow

For early evaluation, Secure Radio can provision a small starter trial automatically after a verified trial request. This is a low-friction self-evaluation path, not a substitute for Guided Evaluation.

The default free trial is intentionally focused:

  1. one trial tenant
  2. one browser dispatch console identity
  3. one Android mobile radio identity
  4. mandatory operator authentication
  5. one OPS channel
  6. one OPS talkgroup
  7. time-limited access

The onboarding email and trial-ready page include:

  1. the dispatch console setup link and QR code
  2. the Android radio setup link and QR code
  3. the Secure Radio Android app download link
  4. Android app version and SHA-256 checksum
  5. basic activation instructions

Dispatch and Android activation use separate short-lived setup QR codes. Each client scans its own QR from the login screen, applies the correct device identity, and asks the operator to set a PIN during onboarding. Operator PINs are not sent by email.

For the user-facing Day 0 setup flow, see Day 0 Free Trial Quickstart.

7.4 Stage 4: Operational Adoption

Expand usage once:

  1. login and onboarding are smooth
  2. operator roles are understood
  3. dispatch workflows are clear
  4. support and escalation routes are in place

8. Customer Responsibilities During Rollout

To get strong results, customers should assign clear owners for:

  1. operational sponsor
  2. tenant administration
  3. dispatch process owner
  4. field-user training
  5. technical/customer-success coordination

Clear ownership reduces rollout drift and configuration ambiguity.

9. Prerequisites And Considerations

9.1 Connectivity

The platform depends on IP connectivity. Customers should plan around:

  1. Wi-Fi coverage quality
  2. cellular signal quality for mobile use
  3. how degraded connectivity should be handled operationally

9.2 Device Readiness

Customers should decide early:

  1. which users will use Android handhelds
  2. which users will use browser-based clients
  3. what support model exists for device replacement or reprovisioning

9.3 Governance

Customers should define:

  1. who can onboard or disable devices
  2. who can manage operators
  3. who can change talkgroups or permissions
  4. whether those changes are tenant-admin only, or require an approval workflow before admin action
  5. how operational changes are approved

Recommended operating model:

  1. tenant admins own talkgroup creation, active state, and operator permissions
  2. dispatch uses the configured talkgroups operationally but does not change policy live

10. Success Criteria For Customers

Customers should measure adoption and success through practical outcomes such as:

  1. faster operational coordination
  2. lower friction to reach the right team or subgroup
  3. stronger trust in who is communicating
  4. simpler administration than fragmented toolsets
  5. clearer visibility for dispatch and tenant admins

11. Customer Reading Paths

11.1 For Field Teams

Read:

  1. Field Operator Manual

11.2 For Dispatch Teams

Read:

  1. Dispatch Operator Manual
  2. Field Operator Manual for cross-role awareness

11.3 For Tenant Admins

Read:

  1. Customer admin guidance provided during managed rollout
  2. Dispatch Operator Manual if dispatch workflows are in scope

11.4 For Sponsors And Stakeholders

Read:

  1. Customer Overview
  2. Customer admin guidance provided during managed rollout

11.5 For Free Trial Users

Read:

  1. Day 0 Free Trial Quickstart
  2. Dispatch Operator Manual if you are setting up dispatch
  3. Field Operator Manual if you are setting up the Android radio

12. Known Boundaries

Customers should understand that the platform is optimized for operational voice and governance workflows. It is not intended to replace every collaboration, messaging, or enterprise workflow surface.

Customers should also treat network quality as part of operational readiness. Weak or unstable mobile conditions can materially affect voice experience, which is why rollout planning and support processes matter.

13. Support And Escalation Model

The healthiest customer model is:

  1. field users escalate to internal dispatch or tenant admin
  2. tenant admins handle device/operator/configuration issues
  3. customer success or platform support handles platform-level issues

This keeps day-to-day operational support simple for end users.

14. Bottom Line

Secure Radio is best understood as trusted operational communications infrastructure. It gives customers one software-defined platform for field users, dispatch operators, and tenant administrators, with clearer identity, governance, and operational control than ad hoc communications tools typically provide.