Read a live incident properly, select only the missing capability and build response presets you can trust.
Read the mission in layers
Start with the exact mission variant and its published requirements. Then inspect units already responding, units on scene and the missing-requirement message. Finally check patients, prisoners and any recovery work. These layers answer different questions: the mission catalogue describes what can be required; the live incident describes what is still blocking this particular call.
Do not send another complete response simply because the scene is still open. A mission may already have enough engines and be waiting for command, a trained person, a transport decision or a specialist unit. Read the deficit first. This preserves the available fleet for other incidents and avoids turning one small shortage into several.
Use status numbers as a shared language
The official status list documents 1 as available by radio, 2 as available at station, 3 as travelling to an incident, 4 as on scene, 5 as requesting transport, 6 as unavailable, 7 as transporting a person, and 9 as awaiting a vehicle to tow. Status colour helps scanning, but the number and current task are the more reliable diagnosis.
A unit shown as available on the radio may be far from home. A unit on scene may still be essential to that incident. A unit requesting transport needs a destination decision, not another dispatch instruction. Check the vehicle's current position and task before assuming that a familiar station name means it is locally available.
Turn a response into a reusable rule
Alarm and Response Regulations select vehicle types according to a preset; vehicle groups refer to specific vehicles. Use an ARR for a repeatable capability package and a group when you deliberately want the same named units together. Neither removes the need to understand the mission.
Build small presets first. Make a basic pumping response, an aerial addition, a rescue addition and a command addition before constructing elaborate mission-specific buttons. This modular approach is a planning recommendation: it makes changes easier when your fleet or mission requirements evolve. Keep names short enough to distinguish on a phone.
Test rules against real shortages
After using a preset, inspect what it actually selected. A rule can be logically correct but still fail because the matching unit is busy, outside a display limit, unavailable or inadequately crewed. A green button is not evidence that the full required response has been sent.
Test a representative incident with the closest specialist already committed elsewhere. Does the rule find a suitable reserve? Does the resulting travel time remain acceptable? Keep a manual fallback for unusual variants, specialist personnel and conditional requirements. When a preset fails, change the smallest part necessary and test again.
Understand alternatives and probabilities
A requirement written as one unit of either type is an alternative, not a request for both. A probabilistic requirement is different from a permanent requirement. A personnel requirement may not be satisfied by an empty or partly crewed vehicle that looks appropriate. Read the wording closely, especially on large multi-service incidents.
For example, UK mission pages can specify ICCU or Ambulance Control Unit alternatives and armed personnel in armed vehicles. Copying only the vehicle names loses important meaning. Design response rules around the published capability and then verify the live incident rather than treating a screenshot from an older version as a permanent contract.
A useful stalled-call routine
When a scene stops progressing, work from the message outward. Check the missing resource, its responding ETA, the staff aboard the relevant vehicle and any outstanding transport request. If all visible requirements appear satisfied, capture the mission ID, exact variant and unit details before reporting the issue. That evidence is much more useful than a cropped progress bar.
- Read the missing requirement before adding vehicles.
- Check responding ETAs and staff qualifications.
- Resolve patient and prisoner destinations.
- Inspect availability, distance filters and towing dependencies.
- Record the exact mission when behaviour appears inconsistent.
Sources and further reading
Latest editorial change: Added an answer-first summary, action checklist and related planning/reference link. Detailed source dates remain independent.
Official sources establish game rules; practical build orders and planning examples are TKB recommendations. Follow the UK game’s current requirement panel where a later update differs.