Guide to IPAWS

Guide to IPAWS

When disaster strikes, the Federal Emergency Management Agency is ready to help. FEMA has developed IPAWS (aka Integrated Public Alert & Warning System) – the powerful way for emergency managers and public officials to alert the public quickly when emergencies arise within their jurisdictions. IPAWS helps local, state, tribal and federal agencies quickly communicate lifesaving information to the public.

IPAWS is especially valuable in the 21st century, when connected devices are all around us. Let’s take a closer look at IPAWS and how it works.

What Is IPAWS Emergency Alert?

IPAWS is a system provided by FEMA for agencies to use to inform the public of emergencies, such as dangerous weather and AMBER Alerts. These notifications go out through various platforms, including cellphones, radio, TV and internet service. Strict system maintenance includes regular weekly tests to ensure operation and reliability.

A critical component of IPAWS is ensuring access to the entire public. The system has technologies to reach people in rural locations, people who lack access to newer electronics, non-English speakers and those with disabilities. For instance, IPAWS can deliver messages through sirens, text-to-Braille translators and sign language interpretation.

Language options can vary based on the delivery media, but they often will include English and Spanish alerts and may include others depending on the primary language spoken by the area’s population. The Department of Homeland Security also uses a collection of international symbols.

The communication channels that can broadcast IPAWS messages include:

  • Radio, TV and landline phones.
  • NOAA Radio, RSS.
  • Mobile devices: Although limited to only the most urgent alerts, Wireless Emergency Alerts are an excellent resource for sending information. Mobile phones can be an ideal way to reach some disabled populations, too, as many smartphones have built-in disability access features. For instance, a visually impaired person might have text-to-speech enabled and would receive a spoken alert through their mobile phone without needing a separate communication platform.
  • Browser push notifications.
  • Unique systems and assistive and emerging technologies: There are a wide range of other technologies compatible with IPAWS protocols, including digital road signs, wall beacons, sirens, remote video interpretation and others that can meet the needs of people with disabilities, limited technology access and non-English speakers.

Adding IPAWS to your emergency communication toolkit can provide real value. For instance, through WEA, IPAWS can send messages to almost all mobile phones, without any need for registration and provide access to many other message delivery mechanisms. In addition, FEMA is constantly updating IPAWS. The latest updates render IPAWS WEA an even more sophisticated communication tool:

  • IPAWS WEA messages now contain up to 360 characters.
  • You can include hyper-links. This means you can send a bulletin with lots of information to the public.
  • IPAWS WEA now supports alerts in Spanish.
  • The geographic accuracy of WEA alerts has also greatly improved.

What Does IPAWS Do?

IPAWS delivers public alerts during various incidents, including anything officials deem a threat to public safety.

  • Weather: Tornadoes, flash flooding, heat and snowstorms
  • Natural disasters: Earthquakes, volcano eruptions and wildfires
  • Infrastructure: Dam breaks, road closures, gridlock, power outages, disaster resources and water and relief supply distribution
  • Law enforcement: AMBER Alerts and active shooters
  • Public health: Illness outbreak, water contamination and chemical spills
  • Other issues: Presidential alerts and shelter-in-place commands

An IPAWS alert could mean many different things and might instruct people to take shelter, evacuate an area, watch for suspects, use bottled water or take other precautions required for safety.

How Does IPAWS Work?

IPAWS relies on the Common Alerting Protocol, which provides technical specifications for compatibility, consistency and access while allowing the alerting authority to add their messages appropriate to the situation. Creating a message with CAP is as easy as using a CAP-compliant piece of software.

These messages then go to the IPAWS Open Platform for Emergency Networks (IPAWS OPEN). This aggregator validates technical requirements and permissions before pushing the message through to the appropriate pathways.

After going through IPAWS OPEN, the message gets distributed to the many dissemination channels mentioned earlier, like the EAS, WEA, NOAA and internet services.

From a technical standpoint, CAP helps IPAWS support multiple media formats while meeting consistent tech demands for the broadest implementation and functionality. It can significantly improve the likelihood that a person will receive the alert.

CAP allows for:

  • Rich multimedia, including streaming video, audio, maps and photos.
  • Geographical targeting to specific areas.
  • Meeting the needs of people with visual or auditory impairments and non-English speakers.

Other IPAWS FAQs

  • How long has IPAWS been around? FEMA established the IPAWS program in 2006 by Presidential Executive Order 13407. Today there are more than 1,500 federal, state, local, tribal and territorial alerting authorities that use IPAWS to send critical public alerts and warnings in their jurisdictions.
  • Who can get IPAWS alerts? By design, IPAWS reaches as many people as possible within a specific geographic area. Unless you’re entirely off the grid and far from civilization, there’s a good chance you’ll receive an alert, whether through a cellphone, siren, radio, nearby television or the internet.
  • How do you set up IPAWS alerts? If your work involves public safety, consider implementing an emergency alert system that integrates with IPAWS. It can help you reach almost everyone you need to with timely information and warnings. Setup is straightforward, and you can learn more about implementing our system, Hyper-Reach, by speaking to a team member.

Partner With the Right Emergency Alert Technology

Hyper-Reach is seamlessly integrated with FEMA’s IPAWS technology, allowing authorized clients to use IPAWS WEA messages to fill in the gaps so they can reach just about all the residents and visitors in an affected area, even if they haven’t registered for emergency alerts or are just passing through the affected community. And Hyper-Reach enables messages through all the IPAWS channels, including EAS and COG-to-COG.

Now we’ve made it even better by adding the ability to send IPAWS messages from the app. This means you can send IPAWS messages right from a mobile device. It’s so capable and easy to use that some customers prefer to use it, even when they’re in the office. And because our IPAWS software is completely up to date with the latest FEMA requirements, you can send longer WEA messages, messages in Spanish, include hyper-links in your WEA messages and more. Leverage IPAWS’ power today. Request our demo or contact us to learn more!

How to Reduce Problem Resolution Time

When you work in an industry or government sector where you need to handle customers’ or constituencies’ non-emergencies or emergencies fast, your problem resolution time is crucial. The amount of time it takes for your representatives to solve problems plays a critical role in a customer’s satisfaction and, at times, safety. Once you know how to reduce problem resolution time, you can take steps to deliver more effective services and improve your customer’s satisfaction.

Find out more about what problem resolution time is, why it matters, how it’s measured and how you can reduce it. You might also want to know more about how you can reduce your incident response time.

What Is Problem Resolution Time?

Problem resolution time refers to the amount of time it takes for a company to resolve a customer service ticket or case after it’s opened. Problem resolution time is often measured from the moment a customer reports a problem to a company and to whenever the company solves the issue. Generally, the time is measured in business hours instead of clock hours to account for the staff’s downtime. 

Why Does Problem Resolution Time Matter?

Since shorter problem resolution times often lead to higher client or customer satisfaction rates, many organizations put a lot of effort into reducing it. When a customer contacts your company about an issue, they want to have it handled as fast as possible so they can get on with their day. Additionally, when emergencies occur at your company’s facilities or in your area, problem resolution time is even more critical, as quick incident resolutions can save property and lives.

Knowing your problem resolution time can also help you keep track of inefficiencies. For example, you may have an underperforming staff member who needs extra training or incident categories that tend to take more time to solve. By having in-depth information about problem resolution time, you can be more aware of what you need to take action on to solve inefficiencies. 

What Is ITIL Response Time?

IT Infrastructure Library (ITIL) refers to a best practice framework used by organizations and individuals looking to align their business’s needs with their IT services. You’ll often see ITIL referenced when discussing incident management and response time, as unexpected interruptions caused by incidents can harm your IT department’s service quality. ITIL response time refers to the time it takes your IT services to process an incident and solve it.

How Is Problem Resolution Time Measured?

Companies often measure their problem resolution time with the mean time to resolve (MTTR). This metric calculates the average time it takes a company to solve a customer’s problem. When a company tracks its MTTR, it can set goals for reducing its average problem resolution time and spot trends, such as longer problem resolution times during parts of the year. Companies often also calculate MTTR for specific incident categories or employees to see they need to pursue extra training or specific actions.

While MTTR is an excellent metric to understand how well your company is performing overall, it can often leave out some essential details and information you’ll need. Since MTTR lumps all of your numbers into one giant pool, you can miss some critical information about particular incident classes or staff members. When you use more metrics than MTTR, you can better measure your problem resolution time and have more data to use when you attempt to reduce incident resolution time.

Check out some of the other primary metrics you can use to measure your problem resolution time:

  • Percentage resolved: With percentage resolved metrics, you can see how many problems are resolved within a specific time limit and what incidents exceed the time limit. By having this metric in your corner, you can more easily measure your goals against your resolution times. With this information, you can change your incident-management practices to help your team achieve your goals.
  • Cumulative incident time and total number of incidents: When you’re trying to get a full picture of your problem response time and the factors affecting it, you’ll want to also gather metrics on your total number of incidents and cumulative incident time for a particular period. These numbers can give you greater context about different departments and how they’re performing.
  • Individual MTTRs for different incident classes: If you can define your company’s specific incident classes, you can utilize MTTRs for them. These separate MTTRs for each class can help you determine if particular incidents tend to take more or less time. You can use these numbers to focus your efforts on reducing MTTR for incident classes that take longer.

How Do You Reduce Incident Resolution Time?

With the information you gather from various metrics, the next question you’ll probably have is, “how do I reduce resolution time?” Keeping track of your resolution time is crucial to faster resolutions, but you also need to pair them with some best practices to reduce incident response times.

1. Automate Repetitive Processes

Whenever incidents occur, your team likely has to repeat a few basic processes. For example, customer representatives often have to handle tasks like escalation, due date changes, ticket assignments and priority adjustments. These tasks are usually simple, but they can take up lots of time and be fairly tedious for employees. Having to handle these tasks manually can increase your incident response times, as representatives have to handle busywork instead of providing solutions.

When you want to reduce incident response time, one great strategy is automating many repetitive processes. You can often find automated software designed to take repetitive processes out of your team’s hands and handle them without needing any human input. By automating many processes concerning incoming tickets, you free up your staff to work on more important issues and reduce the overall time it takes for them to handle new incidents.

2. Categorize Tickets to Improve Organization

Since different ticket classes often have varying resolution times, you may want to categorize them. When you categorize your tickets, you can set more realistic expectations for particular types of incidents. For example, employees might need to handle a more crucial issue faster than a standard issue. Additionally, you might want to set longer target times for more complex problems than simple ones. By categorizing your tickets, you can set target times and evaluate how your team is performing. 

Besides arranging classes of tickets, you can also increase organization by giving custom statuses to your tickets. These statuses increase transparency across your whole team, as your staff can immediately know what’s going on with a ticket. For example, your IT team might place an “on hold” ticket status for a ticket waiting on another action. These tickets can assist your team, as they’ll know what action they need to take to handle an incident.

When you combine ticket status with improved ticket classifications, you can reduce incident resolution time. These organizational tools help your team prepare to handle a particular ticket’s needs quickly. They also help you set more realistic incident response time expectations for your team.

3. Track Performance With Reports and Analytics

One of the first steps to reducing response time is accurately tracking your team’s performance. If you don’t have the correct data, you’ll be taking shots in the dark whenever you attempt to streamline your operations. As a result, it’s crucial to use a system that can provide you with analytics and reports.

With reports and analytics, you can get a complete view of your team’s incident response times and areas needing improvement. For example, you can utilize a multi-channel report describing the nature of incoming requests and support performance to better understand your response time. With information like this in your corner, you can keep track of an individual’s performance and common problems. After receiving this information, you can craft a solution to the problem.

4. Utilize Canned Actions for Common Replies

Anyone who’s had to respond to customers’ queries and issues knows you often have to write out very similar responses. Sometimes, there’s a simple solution to a common problem or a need to request more information from the customer. Without canned actions, your staff will have to manually write out very similar emails every day. These manual responses can be very time-consuming, which effectively reduces response time.

With canned actions, you can create a few email templates designed to answer common queries or issues. When a representative receives an email fitting a templated response, they can select the email from a dropdown menu, populating the template into their reply. As a result, the representative doesn’t have to spend time writing a response. Instead, they just click the template and send the email, closing out the ticket fast.

By giving your staff access to canned actions, you can significantly reduce your incident resolution time. Because canned actions help team members automate their responses, they can resolve tickets faster. Even if they need to slightly reword a template email to meet a customer’s unique needs, it can cut down on the busywork associated with representatives having to write the more standard language used in the rest of an email.

5. Provide Self-Service Options

Another key way to decrease incident response time is to reduce the number of tickets your team has to handle on any given day. When representatives get tied up managing tons of incidents, wait times tend to increase and the representative can feel overwhelmed, leading to lost productivity. If you want to know how to reduce the number of incidents your team has to handle daily, you can start by providing self-service options to your customers.

Essentially, a self-service option gives your customers the information they need to handle issues by themselves. While customers can’t often handle complex issues independently, they’re usually able to address simple issues if you give them easy-to-follow instructions. You can find self-service options taking the form of FAQs, how-to-articles for fixing common incidents and intuitive search functions to help customers solve incidents.

Many customers enjoy self-service options, as these selections take away the need to spend time speaking with someone. Self-service options can also reduce response times as your team won’t have to deal with as many incidents. Additionally, minimizing your representatives’ incidents helps them stay more focused and stress-free when handling a customer’s ticket.

6. Use Mass Notifications to Help Cover Shifts

When your support team is understaffed, they’ll likely struggle to handle incidents quickly. As a result, the work can pile up and potentially overwhelm them, leading to longer response times. Additionally, when you’re short-staffed, your team could have to put certain incidents on hold until a qualified staff member arrives, causing your response times to increase significantly.

With a mass notification system, your incident managers can quickly contact relevant staff members if you end up short-staffed. Instead of calling or messaging staff members individually to check their availability, a manager can use a mass notification system or an on-call communication system to alert employees about availabilities. By notifying team members in this manner, your managers save time and can often quickly get someone to cover a short-staffed shift, helping your team reduce their response times.

Mass notification systems can also help keep managers more focused on crucial tasks, like providing their expertise to support staff. Alongside a mass notification system’s ability to help managers quickly find coverage, managers can also use it to inform staff as soon as the shift is filled. This feature prevents them from having to spend time on the phone explaining to employees they’re no longer needed. Because fully staffed shifts and more focused managers often lead to reduced response time, mass notification systems are essential.

7. Reduce Waiting Time

When a customer has to wait for a long time on hold before a representative speaks to them and solves their problem, they can become frustrated and bring that frustration to the conversation with the representative. This waiting time can reduce the customer’s opinion of your company, and their feelings can make it more difficult for the representative to solve the customer’s issue. Additionally, in an emergency situation, the waiting time can affect the amount of damage or injuries.

If you want to improve your customers’ experiences, minimize wait times with these best practices:

  • Improve internal communication: At times, a representative may not have the expertise to handle a ticket. With greater internal communication, your team can better collaborate to solve a ticket and reduce wait times.
  • Greater data centralization: When a customer reaches out to your company, greater data centralization can help your team quickly know who the customer is and any relevant information they need about them. Data centralization also helps the representative access relevant information about a customer’s problem faster. By centralizing your data, you can reduce wait times and deliver a more personalized experience to customers.
  • Assign new tickets immediately: When a ticket comes through your system, your team should immediately assign it to the relevant representative. This fast assignment prevents tickets from becoming lost and gets customers to a representative fast.

Learn More About How Hyper-Reach Can Help

At Hyper-Reach, we can help you reduce problem resolution time. We offer a critical management system designed to help you send non-emergency and emergency mass alerts and notifications to your team. With our non-emergency communication solutions, you can speak with customers, send updates and manage special events and staff. Additionally, we know the importance of incident response, so we made our system to help you quickly eliminate rumors, put the right staff in action and distribute critical information.

Check out our solutions today to learn more about how we can reduce your incident resolution time. If you’re ready to try out our solutions or have any questions, please feel free to request a demo or contact us.

Let’s re-write another NWS alert

This recent alert was screaming “re-write” when it came in last night.   So here goes:

The Original

HEADLINE: Heat Advisory issued June 17 at 10:38PM EDT until June 18 at 8:00PM EDT by NWS Buffalo

DESCRIPTION: …HEAT ADVISORY REMAINS IN EFFECT FROM 10 AM TO 8 PM EDT
MONDAY
* LOCATIONS…Niagara, Orleans, Monroe, Wayne, Northern Cayuga,
Oswego, Genesee, Livingston, and Ontario counties.
* TIMING…From late Monday morning through early Monday evening.
* HEAT INDEX VALUES…In the upper 90s.
* IMPACTS…The combination of hot temperatures and high
humidity levels will result in a potential for heat-related
illnesses if proper precautions are not taken.

INSTRUCTIONS: A Heat Advisory means that a period of hot temperatures is
expected. The combination of hot temperatures and high humidity
will combine to create a situation in which heat illnesses are
possible. Drink plenty of fluids…stay in an air-conditioned
room…stay out of the sun…and check in on relatives and
neighbors.
Take extra precautions if you work or spend time outside. when
possible…reschedule strenuous activities to early morning or
evening. Know the signs and symptoms of heat exhaustion and heat
stroke. Wear light weight and loose fitting clothing when
possible and drink plenty of water.
To reduce risk during outdoor work…the occupational safety and
health administration recommends scheduling frequent rest breaks
in shaded or air conditioned environments. anyone overcome by
heat should be moved to a cool and shaded location. Heat stroke
is an emergency – call 9 1 1.

———————————————————————————————————–

Our Re-write, based on the Mileti principles:

HEADLINE: NWS Buffalo: High Temperature Danger on Monday, June 18 from 10AM to 8:00PM EDT

* SOURCE: NWS Buffalo

* HAZARD: Heat index in the high 90s starting at 10AM Monday.  Hot weather and high humidity means a risk of heat illness, heat exhaustion or heat stroke.

* LOCATIONS…NY State: Niagara, Orleans, Monroe, Wayne, Northern Cayuga, Oswego, Genesee, Livingston, and Ontario counties. (a link to a map here would make so much sense.)

* GUIDANCE …From 10AM Monday, drink plenty of fluids…stay out of the sun and in air-conditioning where possible…and check in on relatives and neighbors.
If outside, do these things, if possible: limit high-effort activities to early morning or evening. Wear light weight and loose fitting clothing. Drink plenty of water.  Schedule rest breaks every hour in the shade or cooler area. Anyone overcome by heat should be moved to a cool and shaded location. Call 9 1 1 if heat stroke or exhaustion is suspected.

* EXPIRES… Early Monday evening (8PM).

———————————————————————————-

Not only does this reduce the number of words, but we cut the reading level required by 1-2 grades and went from “fairly difficult” to “fairly easy” to read. (Here’s the test we used.)

This could also be improved on.  For example, a link to a resource explaining the symptoms of heat exhaustion/stroke would be helpful.   And the words “overcome by heat” are ambiguous.  Listing some symptoms, such as “feeling faint, dizzy or weak” would be much more clear.

To make a template out of this, we could do it this way, making the assumption that there is a weather forecast that lets us choose a start time:

* SOURCE: {Source}

* HAZARD: Heat index in {Heat index} starting at {Start time}. Hot weather and high humidity means a risk of heat illness, heat exhaustion or heat stroke.

* LOCATION {Location}

* Guidance: From {Start}, drink plenty of fluids…stay out of the sun and in air-conditioning where possible…and check in on relatives and neighbors.
If outside, do these things, if possible: limit work or exercise to early morning or evening. Wear light weight and loose fitting clothing. Drink plenty of water.  Schedule rest breaks every hour in the shade or a cooler area. Anyone overcome by heat should be moved to a cool and shaded location. Call 9 1 1 if heat stroke or exhaustion is suspected.

* EXPIRES… {Expiration time}.

A lesson in rewriting emergency alerts

Since we just published our take on how to write emergency alerts, we thought we could use an alert we just got from NYAlerts to suggest ways to improve your alert writing skills.

Below are three versions of the alert: (1) the original text; (2) our re-write, using the format provided by the alert, since it appears to be pre-formatted to those 6 elements: headline, description, locations, timing, impacts and instructions, and (3) our re-write, using the guidelines from Professor Mileti.

The amount of detail you want to include and what description will be most helpful are obviously judgment calls and local knowledge is key.  But we like our versions better for a few reasons:

  1. Less ambiguity. What is “early this evening?”  If 8PM is clear, why not stick with that?  What’s the difference between a “dangerous area” and any other structure?  Isn’t the issue here that any structure is a risk because a wave can cause a swimmer to collide with it?
  2. Less formal language. Why a “Beach Hazards Statement” instead of just “Hazardous Beach Conditions?” In fact, with a little more time, we might try to simplify that phrase.  How about “Unsafe Beaches?”
  3. Active, rather than passive verbs.  You learned this in school.  “Remains in effect” is passive.  Actually, we just took out the verb in the 2nd re-write.
  4. Shorter. On a word count basis, we saved 10 words, which is more than 10%.  It’s just easier to read.

 

Actual Alert

* HEADLINE: Beach Hazards Statement issued June 14 at 10:30AM EDT until June 14 at 8:00PM EDT by NWS Buffalo

* DESCRIPTION: …BEACH HAZARDS STATEMENT REMAINS IN EFFECT UNTIL 8 PM EDT THIS EVENING…

* LOCATIONS…Beaches of Niagara, Orleans, Monroe, and Wayne counties.

* TIMING…Through early this evening.

* IMPACTS…Strong currents and dangerous swimming conditions.

INSTRUCTIONS: A Beach Hazards Statement is issued when there is a high swim risk. This means life threatening waves and currents are expected. Stay out of the water and stay away from dangerous areas like piers and breakwalls.

1st Re-Write

* HEADLINE: NWS Buffalo: Hazardous Beach Conditions from June 14 at 10:30AM EDT until June 14 at 8:00PM EDT

* DESCRIPTION: …HAZARDOUS BEACH CONDITIONS ARE IN EFFECT UNTIL 8 PM EDT THIS EVENING…

* IMPACTS…High risk of drowning. Life threatening waves and currents expected.

* LOCATIONS…Lake Ontario Beaches of Niagara, Orleans, Monroe, and Wayne counties, NY. From Niagara-on-the-Lake to Fair Haven.

* INSTRUCTIONS: …Stay out of the water and away from piers, breakwalls and other structures near the water’s edge.

* TIMING…Through 8PM tonight.

 

2nd Re-Write

* HEADLINE: NWS Buffalo: Hazardous Beach Conditions, June 14 from 10:30AM until 8:00PM (EDT).

* SOURCE: NWS Buffalo

* HAZARD: …LIFE THREATENING BEACH CONDITIONS UNTIL 8 PM THIS EVENING…High risk of drowning. Life threatening waves and currents expected.

* LOCATIONS…The southern shore of Lake Ontario including Niagara, Orleans, Monroe, and Wayne counties, NY. From Niagara-on-the-Lake to Fair Haven.

* GUIDANCE: …Stay out of the water and away from piers, breakwalls and other structures near the water’s edge. Do not swim.

* EXPIRATION…Through 8PM tonight.

Don’t Overpay for Emergency Notification Services

We came across this announcement for the town of Smithers, British Columbia, in Canada, which honestly made our blood boil just a little.

Smithers is a small town of about 5,300 people. That means it has about 2,100 households and less than 1,700 of those households have a landline.  And the emergency notification provider they chose is charging them $7,500 per year.

We’re glad that the public safety folks in Smithers think that emergency notification services are worth more than $3 per household.  On that point, we agree.  But that’s a crazy high amount to be paying for such a small community.

In fact, we know of emergency notification companies that would charge between $2,000 – $3,000 per year for the same service.  And at least one of those companies would offer the same kinds of services, with messages delivered as voice messages to landline and cell phones, text messages, email, pager messages, Facebook and Twitter feeds, RSS feeds, and even Internet posts and more.  And that company would deliver those messages just as fast and possibly faster, just as reliably and possibly more reliably, thanks to their use of cloud-based computing services companies.  And – despite what the story says – the recipients of those messages would be able to respond to verify that they’d received the message.

Which makes us wonder what the citizens of Smithers are going to get for the extra $5,000 or so they’ll be paying each year for this service. And what they could do with that $5,000 if they’d found a less expensive service provider.

So, congratulations to the citizens of Smithers.  Emergency notification services are highly valuable.  And well worth the money you’ll be paying.  But when it comes time to renew your contract, shop around a bit.  We think you can get a much better deal.

 

 

Don’t be embarrassed by a bogus RFP

We’re working on some RFPs from a number of cities and counties and came across one that’s so heavily skewed toward a particular vendor, it inspired us to think about some principles that are worth considering if you work in procurement.  Although the examples are for mass emergency notification services, the lessons should apply to any RFP sent out by a government agency.  Because if you’re sending out an RFP the violates the guidelines below, I think you’re setting yourself up for trouble if other vendors complain to whoever you may be accountable to.

Quick note: we’re not going to file a complaint about this RFP.  If we’ve decided you don’t want our services, we just go find customers who do.

  1. Don’t list requirements you don’t understand.  There’s a requirement here to get a certification related to the “Safety Act”.  One of the criteria for that certification is that the technology is not widely released.  Since what we sell is used by thousands of cities and counties around the US, it’s pretty obvious that the technology is widely released and we’re not going to get that certification.  I doubt the RFP writer had any idea what they were asking for.
  2. Don’t list requirements that are irrelevant.  The city that issued this RFP has fewer than 20,000 people, which means fewer than 10,000 callable phones.  But they want proof that an emergency notification provider has previously placed 3 million calls in a 24 hour period.  That’s more than 300 times the capacity they are ever likely to require.  Do they really want to eliminate vendors that can only document, say, 1,000,000 calls in 24 hours?
  3. Don’t list requirements that are archaic.  This RFP requires a smartphone app running on Windows phones.  Now, since Microsoft has pretty much abandoned all three Windows phone operating systems developed over the last 10 years, this requirement raises all kinds of questions.  An obvious one would be this: “assuming you actually have some Windows phone users, wouldn’t it be cheaper just to get them to switch phones than pay the premium it will cost to limit yourself to one possible vendor?”
  4. Don’t use the “inside baseball” language.  There’s a line in this RFP that says vendors aren’t supposed to use “cascading calling methodology.”  Since there’s no definition of what that means, this kind of question accomplishes nothing.  Every vendor will simply respond the way they expect the customer wants the answer and the customer – who probably has no idea what the term means – is unlikely to challenge those answers.
  5. Design your requirements to address your REAL needs. Instead of getting caught up in obscure technicalities, specify requirements based on your objectives.  This RFP is full of technical details about a system that provides for communication between government agencies. It happens that most government agencies don’t actually use the system discussed, so all the details about how it works are so many words about nothing of consequence. Meanwhile, the RFP asks comparatively little on how a vendor will effectively get an emergency message in front of the largest number of citizens in an effective way.

Of course, if you’re required to send out an RFP and you really know who you want to choose, maybe these questions serve a valuable purpose.  After all, we’re not going to use our valuable time to respond to an RFP that’s obviously skewed to a particular vendor.  And if you’re the buyer, you’re not wasting your time going through the motions pretending that you’re actually comparing vendors fairly.  In many ways, sending out an RFP that pretends to be fair is actually worse for all involved, since it usually takes a lot of time to answer one of these.

If you really want to have some viable options and get the best deal for your agency, consider an outcome-focused RFP that’s based on your actual objectives.  In our case, we think that most buyers should want to reach as many of their citizens – and often, staff members –  as they can, as easily, quickly, reliably and effectively as they can. Requirements that are built around these specific goals tell us that you’re a serious buyer, worthy of our attention.

Thanks for letting me rant.  Now I’ve got to get back to answering the other RFP I have on my desk.

Why Cloud Deployment Levels the Playing Field for Mass Emergency Notification

The days of paying too much for emergency notification are at an end.  And the reason is simple: the cloud.

Many emergency managers and others who buy emergency notification systems (ENS) are under the impression that the size of the ENS company is important.  There’s a logic to that position that seems to make sense.  After all, a bigger company can send out more messages in a shorter period of time, right?

Wrong.  While that logic may have worked 10 years ago, it’s way out of date today.  And the reason is simple: the cloud.

By “the cloud”, we mean cloud computing companies, such as Amazon, Google, Microsoft and others.  These companies are now providing massive computing power that is very inexpensive, highly reliable, easily scaled to near-infinite capacity, amazingly flexible and highly interconnected with telecom and internet service providers.

Consider this: the largest ENS provider has a total annual revenue of just over $100 million dollars, while Google alone invested over $30 billion dollars on cloud computing technology in just one year.  And Google is playing catch-up to Amazon.

And all that investment isn’t just for hardware.  Much of it goes to software that automates the failover, security and configuration processes that allow its customers to rely on its highly reliable services.  Amazon boasts over 30 security certifications and offers a super-secure version of its AWS services that’s good enough for the Pentagon.  And in this area, it’s probably playing catch-up to Microsoft.

In fact, one of the great aspects of the cloud computing business for us, and many other IT companies, is the aggressive competition among them, because it means that their services are constantly improving while their prices actually go down.

The implications for emergency notification services are profound.  While Hyper-Reach is a relatively small provider of ENS services, we can actually scale to exactly the same capacity as our very largest competitors.  With the same, or better, reliability.  And the same, or better, security. (More on these points later.)

So before you agree to pay a premium of 30%, 40%, 50% or more for the supposed security of a larger company, look for ENS companies that leverage the power of cloud computing in delivering their services.  (The same logic, BTW, applies to other technologies.) We think you’ll be amazed at how much value you can get – not to mention personal service – while paying less for your ENS system.

Escape convict situation shows the power of integrated emergency notification services

On October 12, Phillip Roar, a 39-year old Kentucky state inmate decided to escape the work crew he was on.  He managed to get away, setting off an all night manhunt by Bath county Jailer Earl Willis and others.  Fortunately, he was captured the next day and returned to custody.

Key to his re-capture were the many tips provided by the community, tips that were solicited by Bath County Emergency Management, with the help of the Hyper-Reach system, which sent voi

ce and text messages to over 4,000 telephone numbers, email addresses and the county’s Emergency Management Facebook account.  The original message asking for help included both a physical description of Mr. Roar, as well as his picture, using Hyper-Reach’s ImageReach™ picture messaging system.  The Facebook post was shared more than 350 people, including the local newspaper Bath County News Outlook, resulting in more posts throughout Facebook and other social media.

This event is a great case study for the power of an integrated mass emergency notification system, such as Hyper-Reach.  The Emergency Management agency was able to send the message as a voice, text, email and social media post with a single set of actions and just clicking the different delivery methods they wanted to use.  Every recipient of the message was able to retrieve the image of the escapee, regardless of how they got the original message.  And the easy integration of Facebook made it simple for the message to appear on the county EM’s Facebook page, where it was shared by hundreds – and possibly thousands – of other people.

Emergency message sent by Bath County EM

 

 

Unfortunate Press about NWS Weather Predictions

We’re not taking a position on whether the NWS did the right or wrong thing in its weather forecasting for northeastern cities early this week.  But we are sad to see its credibility damaged.

Among others, the Drudge Report, NY Post and even CBS News are running a story that suggests that the NWS “knowingly misled the public” in forecasting more snow than both actually happened and – more importantly – their models showed as likely as the storm got closer.

As CBS News reported:  “But that day, some of the agency’s models were already changing. It appeared crippling amounts of snow could miss large cities like New York and Philadelphia. However, the weather service didn’t downgrade its forecasts until early Tuesday morning, when the storm was already underway.”

The attack on the NWS – and beyond – was swift.  The NY Post declared that “meteorologists don’t trust the public to decide for itself” and Drudge tweeted: “”Overreaction by govts, bad forecasting…very troubling trend!!”  And a news blog called the Gothamist wrote: “…the National Weather Service deliberately lied to you because they thought you were too stupid to deal with a slightly more reasonable forecast.”   Drudge reportedly also used the occasion to slam “climate hysterics”.  And even the Washington Post accused the weather service of making a bad judgment call.

Since we provide automated weather alerts to our emergency notification clients as part of our standard offering, it’s disheartening to see the NWS take a PR hit like this.  From experience, we know that automated alerts can help people protect themselves from tornadoes flash floods and other imminent disasters and we’d hate to see someone fail to act because the credibility of the NWS was in questions.

Oroville Dam Points to Much Bigger Problem

The recent evacuation of almost 200,000 folks in Butte, Yuba and Sutter Counties in California because of the risks to the Oroville Dam there highlights a huge potential problem in the US.

According to the National Inventory of Dams, there are over 27,000 dams in the US rated as having either high or significant damage potential.  And most dams are more than 50 years old.

In California, more than 100 dams are listed as being in fair or poor condition.  And according to the National Inventory of Dams, almost 100 dams in California have never been inspected.

In 2013, the American Society of Civil Engineers rated US dams with a grade of “D”.  A new report is due out in early March.  Will it show any better grade four years later?

Emergency notification systems are a critical tool in getting the word out on evacuation orders.  So if you live downstream from a dam – any dam – it’s time to sign up for emergency alerts!