Skip to Content.
Sympa Menu

msar-riders - Re: [MSAR] Brief mission yesterday

msar-riders@lists.ibiblio.org

Subject: Mounted search and rescue

List archive

Chronological Thread  
  • From: Una Smith <una.smith@att.net>
  • To: Mounted search and rescue <msar-riders@lists.ibiblio.org>
  • Subject: Re: [MSAR] Brief mission yesterday
  • Date: Tue, 27 Aug 2013 11:15:41 -0600

In New Mexico many of our SAR teams are using a wide range of tools
to automate sending bulk messages to their members. However, when I
am working logistics I generally do not want to contact all teams.
I want to alert only selected resources and not alert other resources.
This is important especially when ordering resources in the middle
of the night.

Why was I ordering resources in the middle of the night? Because the
Incident Commander already had called all the closest SAR teams and
none were able to send anyone. He needed to hand off logistics tasks
to me so that he could drive to the incident base. I was calling SAR
teams that would have a 2.5 to 3 hour drive just to reach incident
base and many of them would also lose a day at work unless I got them
going in the dark. As it happened, our middle of the night response
meant that we were done soon after dawn and were able to turn around
some responding resources early enough that they were able to report
to work.

Work day deployments often need to be arranged hours before the work
day starts. Early deployment saves hours of time, especially if the
responder is a commuter. Someone who gets to work by bus or carpool
cannot respond to a SAR mission from work unless another team member
works there too and can respond and has their vehicle at work. Then
they need to go home to change clothes and pick up gear and possibly
also change vehicles. Although New Mexico has a very low population
density, it is concentrated in one long river valley and there are
many commuter services. Carpools, local and regional bus networks,
train, even airplane commuter pools!

Automated bulk messaging, even if selective, would help me reach some
teams' dispatch person sooner---but consider what would happen next.
I would have multiple dispatch persons calling me for details while
I am already on the phone with someone else, distracting me. Or they
would be sitting by the phone awake and waiting for me to work down
the queue to them; it might have been better to let them spend that
time sleeping.

I am gradually getting acquainted with each team's dispatch people and
their procedures and capabilities. Some are up for texting or e-mail,
others not. At night, many will not pick up the phone during the call
itself but will wait to see if the caller leaves a voicemail. Only
then will they respond. For them a robot call that prompts for the
listener to press a key to respond does not work. Now that I think of
it, this behavior is very important to understand. This means that it
is not enough for me to try to call someone, only to hang up if I get
their voicemail. I need to leave a message!

Many teams don't get very many calls for SAR missions, so for them I
often need to help the dispatch person decide who on the team to call
first. Just working down a pre-printed list top to bottom is what I
know some teams do, modeled after social club calling procedures, but
that is not efficient when a specific response is wanted quickly. For
example, yesterday's mission was north of Santa Fe. I know that most
members of one Santa Fe team live about 20 minutes south of the city
but a few members live about an hour north of it. Also, the mission
called for trucks that have 4 wheel drive. Certain northern members
are the ones I wanted the dispatcher to call first.

Even a team dispatcher who handles lots of calls needs to discuss
with me what is needed, so they can order team resources effectively.

I am sure there is room for improvement. One way you all could help
is to describe not just what tools you use but, as I have done here,
go into extra detail about how you use them and why you use them the
way you do.

Una Smith
New Mexico




Archive powered by MHonArc 2.6.24.

Top of Page