Emergency response system: from the first call to close-out

Three in the morning. The on-call phone rings: a product leak at an industrial site. The coordinator writes down what he can in a notebook and calls the base supervisor, who calls the technicians, who post in a group chat to find out who is taking the truck. Two hours later, the command center has photos scattered across three different chats, a gas reading passed on by phone and no certainty about who signed the safety analysis before entering the area. The client calls asking for a situation report.

This article shows what an emergency response system needs to record, from the first call to close-out, so that a night like this ends with a complete history instead of a puzzle. You will find what Brazilian law requires for oil incidents, the difference between coordinating by phone and through a system, a checklist for each stage and a rollout plan. If your operation also controls hazardous work outside emergencies, the article on the digital permit to work covers the day-to-day routine.

What is an emergency response system?

An emergency response system is the software where the command center records the incident, dispatches crews and resources, assigns tasks and receives what is happening in the field in real time, until close-out. Everything is tied to the incident, with time and author, in a timeline any authorized person can check.

The idea of organizing the response around a shared structure comes from incident command systems. Brazil's Decree 10.950/2022, which sets out the National Contingency Plan for oil pollution incidents, defines the Incident Command System as a standardized management tool that lets the user adopt an integrated organizational structure for single or multiple incidents, wherever they happen.

The software does not replace that method or the company's emergency plan. It gives both a place to happen: the plan defines who does what, and the system records whether it was done, when and by whom.

Why does the first hour of an emergency get lost in messages?

The first hour gets lost because the call, the dispatch and the news from the field run through different channels, and nobody pulls them together while the operation is going on. Phone, radio and group chats are fast for warning people, but they don't store information in a way you can query later.

This matters more because the law expects fast reporting and records. Brazil's Law 9.966/2000, known locally as the Oil Law, requires in article 7 that organized ports, port facilities and platforms keep individual emergency plans for fighting pollution by oil and harmful substances. Article 22 requires any incident that could pollute national waters to be reported immediately to the environmental agency, the Harbor Master's office and the petroleum regulator, regardless of the measures taken to control it.

After the first notice, article 15 of Decree 10.950/2022 requires the polluter to send situation reports to the authorities. The content list is concrete: current status of the incident, volume discharged and what may still leak, product characteristics, affected areas, measures taken and planned, date and time of the observation, location of the slick, resources mobilized and need for more resources. When that information is spread across chats, every report becomes a reconstruction job done under pressure.

The same applies to teams that handle emergencies away from the water, at industrial plants and on highways. The client, the insurer and the inspectors will ask who arrived, when, what they measured and what they did. In the command center for environmental emergency response we built, that was exactly the starting point: the call came in by phone, dispatch was arranged by message and what happened on site reached the command center as loose photos.

What changes between coordinating by phone and through a system?

What changes is where the information lives. The table sums up the differences we saw when digitizing incident coordination.

Radio still has its place, especially in areas with no cell signal. The difference is that a decision made over the radio gets logged on the incident by someone in the command center, instead of living only in the memory of whoever heard it.

A first scope usually leaves out the map with dispersion modeling, integration with government systems and a portal for the client to follow the incident. These are useful steps, and they make more sense once the team already records the basics in the system during a real incident.

What does the system need to record at each stage of an incident?

The system needs to record, as it happens, everything someone will ask about later: who reported it, who was dispatched, what was measured, what was done, under what safety controls and with what resources. The list below follows the stages of an incident, from the call to close-out.

To use the list, take the last incident your team handled and try to answer each item with a record, without relying on anyone's memory. Wherever the answer is "it's in the group chat" or "so-and-so knows", there is a field that needs to go into the system.

International practice helps calibrate what to record. The FEMA Emergency Management Institute, part of the US federal emergency agency, publishes the standard Incident Command System forms. They include ICS 201 for the incident briefing, ICS 209 for the incident status summary and ICS 214, a time-stamped activity log. They are not mandatory in Brazil, but they show that an incident log with the time of each action is part of the method.

Two items make a difference from the first incident. Template tasks per incident type keep the crew from starting at a blank screen at three in the morning. In the command center we built, each incident type comes with its stages and tasks, and the command center can add specific tasks during the operation. The second item is the safety analysis signed before work starts. In the same system, the technician fills in the analysis on the phone, step by step, and the crew signs on the screen before entering the area.

How do you roll out an emergency response system?

The rollout works best when it starts from the emergency plan the company already has and is tested in a drill before it counts in a real incident.

1. Gather the emergency plan, the procedures for each incident type and the records of recent incidents. They show the real stages and where information got lost.
2. Define the incident types and the template tasks for each one with the people who coordinate the response. The setup has to reflect the plan, and not the other way around.
3. Register bases, crews, responders, vehicles and equipment. Without that, dispatch stays on paper.
4. Set up the job safety analysis and the monitoring readings each incident type requires.
5. Install the system on the crews' phones and test the notifications. Also check what happens when the phone is on silent.
6. Run a full drill, from the call to close-out, and produce the situation report from what was recorded.
7. Fix what got stuck in the drill and start using the system on real incidents, with the phone still as a backup at first.

The field side has to work on a phone, with gloves on, in a hurry and with little attention to spare. That is why we build the technician's view as a mobile app for field crews, and the command center's view as a monitor screen with the timeline and task progress. In the command center we built, the system is installed from the browser and receives push notifications like a regular app. The choice between that format and an app store app is covered in the article on PWA vs native app.

What if the crew has no signal or speaks another language?

When there is no signal, recording needs an alternative path agreed in advance. In remote areas and in part of offshore operations, the crew passes information by radio and someone in the command center logs it on the incident, noting the source. If the project includes offline recording, photos and records made on the device upload when the signal returns and go into the timeline with the time they were made. What has to work offline is a decision for each project, based on where the company operates.

Crews from other countries and partner companies are common in large incidents. In the command center we built, the whole interface and the technical library exist in Portuguese, English and Spanish, and each user picks a language. Incident content stays in the language it was recorded in.

There is also the case where the client already has a field project management platform. Instead of asking the crew to record everything twice, the response system can integrate with it. In our project, crew working hours, with check-in and check-out, are tracked in the command center system, which connects to the client's field project management platform.

And there are incidents that start small and grow. The system has to allow changing the incident classification, calling in more resources and adding tasks without opening a new record, so the timeline stays a single one.

When is a response system not enough?

The system organizes and records the response, but the response strategy and crew training stay outside it, as does the approved emergency plan. If the plan has gaps, the system will expose them sooner, which already helps, but fixing them is the job of whoever is technically responsible for the plan.

Legal obligations also stay with the company. Which agencies to notify, by when and in what format depend on the incident type, the location and the environmental license. The system can remind people and record each notification, but the rules come from your legal and HSE teams.

The emergency record connects to other safety routines. Releasing hazardous work in day-to-day operations is the subject of the digital permit to work, and the delivery document for the client after a job is the subject of the automatic service report. At a port support base, for example, permit to work, gatehouse and non-conformities live on the same platform.

If your command center still coordinates incidents by phone and group chats, boosting.tech is a custom software company that builds this kind of system from the plan and routine your team already has. We can look at your case in a free diagnostic conversation. The details are in custom web systems.