Dispatch Operator Manual

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

1. Purpose

This manual is for dispatch and control-room operators. It explains:

1. how to use Secure Radio as a command-and-control surface
2. how to work with channels, private traffic, and talkgroups
3. how to manage dispatch-requested field video
4. how to monitor operational health
5. how to respond when service quality or operator behavior is not normal

2. The Dispatch Role In The Platform

Dispatch is not just another endpoint. Dispatch is the coordinating surface for:

1. shared operational traffic
2. selective and subgroup routing
3. unit awareness
4. escalation and emergency handling
5. first-line visibility into runtime state

Because of this, dispatch should operate with more discipline and visibility than a standard field client.

2.1 First-Time Setup

For free-trial Day 0 setup, use Day 0 Free Trial Quickstart. For managed rollout or free-trial onboarding, dispatch setup can be completed from the login screen:

1. open the dispatch console
2. choose SCAN SETUP QR or open a setup link
3. scan the dispatch setup QR from the onboarding page/email, not the Android setup QR
4. choose and confirm the dispatch operator PIN when prompted
5. return to the login form
6. enter the operator PIN to authenticate and connect

The setup QR is short-lived and single-use. Operator PINs are not sent by email and are not prefilled after setup.

The free trial is intended for low-friction self-evaluation. Treat live operational validation as part of Guided Evaluation or a managed rollout with defined customer SOPs, support ownership, and success criteria.

2.2 Console Surfaces

The dispatch console includes:

1. roster and unit status
2. map and geofence tools
3. channel/private/talkgroup transmit controls
4. talkgroup monitoring and TX selection
5. dispatch-requested video controls
6. settings and diagnostics
7. provisioning and device-key controls for authorized setup workflows

Operator identity management is provider-admin controlled. If the console exposes legacy operator-management labels, treat them as non-authoritative unless provider support confirms they are enabled for the tenant.

3. Before Going Operational

Before the session starts, dispatch should confirm:

1. the correct tenant is active
2. the expected units are connecting
3. channels and talkgroups needed for the shift or operation are available
4. the communications plan is understood
5. a support or escalation path is known if quality degrades

4. Main Dispatch Workflows

4.1 Shared Channel Coordination

Use shared channel traffic for:

1. instructions to the wider team
2. status calls
3. main operational coordination

Best practice:

1. keep language concise and structured
2. reduce unnecessary traffic
3. move narrower conversations off the main channel when appropriate

4.2 Selective Or Private Communications

Use selective or private traffic when:

1. one unit or subgroup needs direct instruction
2. the message does not belong on the main net
3. operational clarity would improve by reducing wider channel interruption

Current selective-call behavior is:

1. dispatch can page one or more units
2. a page creates a temporary reply hold back to dispatch for about 10 seconds
3. if the private exchange continues, that hold refreshes automatically
4. if the exchange goes idle, clients revert to the open channel automatically
5. dispatch can drop the private session authoritatively to force all participants back to the open net

4.3 Talkgroup Coordination

Talkgroups are useful when dispatch needs to:

1. coordinate sub-teams
2. isolate a functional workflow
3. preserve main-net clarity while still controlling a subgroup

Tenant admins configure talkgroups and operator access ahead of use. Dispatch should use assigned talkgroups intentionally and avoid creating confusion by switching users between groups without clear direction.

In the current operating model:

1. dispatch can monitor assigned talkgroups
2. dispatch can choose the current talkgroup TX target
3. some talkgroups can be attached to RF/DMR gateway routes for controlled radio interoperability
4. dispatch cannot create, delete, or re-scope talkgroups from the dispatch surface

For an RF-backed talkgroup, dispatch must treat the on-screen cue as part of the operating procedure. After pressing PTT, the console may show REQUESTING, then RF KEYING, then TALK NOW. Speak only after TALK NOW and the permit cue. This prevents clipped first words while the DMR side keys and subscribes to the sender audio.

4.4 Dispatch-Requested Field Video

If tenant video is enabled, dispatch can request a one-way live video uplink from a specific room participant.

Current operating model:

1. dispatch selects the unit and sends a video request
2. the field participant accepts or declines
3. acceptance only arms the session; it does not start the camera
4. the field operator must manually switch video on
5. only one active video uplink is allowed per room at a time
6. when the uplink goes live, everyone in that room can choose whether to watch it
7. room audio and PTT continue to operate normally during the video session
8. dispatch can record the incoming browser video as a local evidence clip and download it for case handling

Dispatch best practice:

1. request video only when it adds clear operational value
2. tell the unit why video is being requested before or during the request when practical
3. stop the video session promptly when it is no longer needed
4. avoid requesting video from multiple units in the same room at once because only one uplink is supported
5. record only when local policy permits it, and save clips into the approved evidence store immediately after download

5. Unit Awareness And Roster Discipline

Dispatch should maintain awareness of:

1. who is connected
2. which users or units are on which communication scope
3. whether a user appears unavailable or degraded
4. whether a user is repeatedly missing or clipping traffic
5. whether a room already has an active video uplink before requesting another one

If the platform exposes presence or runtime status indicators, use them as operational aids, not as a substitute for good dispatch judgment.

6. Good Dispatch Operating Practice

Recommended practice:

1. define the active net clearly
2. use selective traffic for narrow instructions
3. keep emergency or priority traffic obvious
4. avoid avoidable overlap between talkgroups and shared channels
5. escalate communications quality problems early

6.1 Main Audio Cues

Dispatch now shares the same core cue vocabulary as the field clients.

Dispatch also retains a stronger sos emergency alert variant for workflows that need a more urgent audio signature than the normal page_alert.

7. Interpreting Service Quality

7.1 Healthy Behavior

Healthy dispatch behavior looks like:

1. units connect and respond normally
2. receive audio starts promptly
3. traffic is intelligible and consistent
4. users can move between the expected scopes without confusion

7.2 Warning Signs

Dispatch should notice and log patterns like:

1. units repeatedly reporting missed first words
2. audio arriving late or in bursts
3. repeated reconnects
4. one user repeatedly failing on transmit or receive
5. location- or network-specific patterns of degraded quality

8. Responding To Quality Problems

If a user reports poor audio or delayed receive:

1. identify whether the issue is one-way or two-way
2. identify whether it affects one user or multiple users
3. identify whether it is tied to a specific network or location
4. keep operational traffic flowing by simplifying the communication pattern if needed

Examples:

1. move non-critical traffic off the main net
2. direct a unit to relocate if connectivity is obviously poor
3. use a simpler communication scope temporarily if subgroup behavior is adding confusion

9. Emergency And Priority Handling

Every customer should align local SOPs, but dispatch should generally:

1. preserve channel clarity during emergencies
2. reduce non-essential traffic
3. use the narrowest effective communication path for supporting instructions
4. keep a clear record of who is responding and where coordination is happening

10. Working With Tenant Admins

Dispatch and tenant admins should coordinate on:

1. operator permissions
2. talkgroup structure
3. tenant video enablement
4. user onboarding problems
5. repeated service quality issues affecting operations
6. privacy and SOPs for requesting field video

Dispatch should not be expected to solve provisioning or policy problems alone.

11. Shift Start Checklist

At the beginning of a shift or event:

1. verify your own connection
2. verify the main channel structure
3. verify key units are visible and reachable
4. confirm any special talkgroups in use
5. confirm whether any active talkgroups are RF/DMR-backed and whether operators know the wait/talk cue
6. confirm whether tenant video is enabled if the operation expects it
7. confirm who the tenant admin or support escalation contact is

12. Shift-End Checklist

At the end of a shift or operation:

1. record any notable communications issues
2. record any users or devices with repeated trouble
3. note if problems appeared tied to a specific area or network
4. hand over any unresolved admin or support issues

13. Dispatch Troubleshooting

13.1 Units Cannot Hear Traffic

Check:

1. whether they are on the correct channel or talkgroup
2. whether multiple users are affected
3. whether the issue is isolated to one network or area

13.2 A Unit Cannot Transmit

Check:

1. whether the unit is authorized on the current scope
2. whether another user is already transmitting
3. whether the issue is device-specific

13.3 The Main Net Is Becoming Chaotic

Actions:

1. simplify traffic
2. move narrow conversations to private or talkgroup flows
3. restate the active operating pattern clearly

13.4 Video Request Or Field Camera Will Not Start

Check:

1. whether tenant video is enabled for the customer
2. whether another video uplink is already active in the same room
3. whether the target unit accepted the request
4. whether the field operator actually switched video on after accepting
5. whether the unit stayed in the same room long enough for the session to go live

13.5 Dispatch Setup QR Does Not Work

Check:

1. whether you are scanning the dispatch QR, not the Android/radio QR
2. whether the setup QR has expired or has already been redeemed
3. whether browser camera permission is enabled
4. whether the browser supports camera scanning
5. whether the current trial-ready page or onboarding email is being used

If browser scanning is unavailable, use the dispatch setup link from the trial-ready page or onboarding email if link activation is supported. If the QR is expired, already used, or redeemed on the wrong client, ask support or the trial owner for a fresh activation path. If regeneration is not available, a new trial or manual provisioning may be required.

13.6 Dispatch PIN Is Forgotten

The dispatch operator PIN is chosen during setup and is not sent by email. If it is forgotten, ask support or the trial owner to reset or reprovision the dispatch identity. The old PIN cannot be recovered from the console or onboarding email.

14. What Dispatch Should Report To Support

When escalating a platform issue, provide:

1. which users were affected
2. whether the issue was TX, RX, or both
3. whether it was the start of speech, mid-message quality, or full-session failure
4. whether the issue appeared tied to a location, carrier, or access method
5. approximate time of occurrence

15. Bottom Line

Dispatch is the operational anchor of the platform. The more clearly dispatch manages channels, selective traffic, assigned talkgroups, and escalation, the more value the platform delivers. Good dispatch practice turns the product from a voice tool into a true command-and-control surface.