In a past post we spoke about the value of simplicity in the data structure. Because we see our AMG Alerts customers over-complicating their databases all the time, and it’s been a while, I will touch on this again.
When an organization considers how to split up the population for selective notification (assuming that it’s even necessary), we see evidence the the first question they ask is “How can I split everyone into hierarchies and groups?” There is further evidence that that organizations look to their HRIS database and see how it may be broken out there. But the HRIS is used for a different purpose, so that shouldn’t determine the setup of the notification system.
And unfortunately we also see customers making it as complicated as our system will allow, without regard to whether such minute groupings would ever be used as part of a “response” to a situation.
In mass notification, the “old saying” (the quotes are there because actually we just made this up ourselves) is: “It’s almost always better to inform too many people than too few.” That means that if you break up your database into tiny slivers, your maintenance requirements can grow exponentially. Try not to create a system where just because Joe Tucker is now Salaried instead of Hourly, or he moved from second shift to first shift, he now is not going to get the message because his profile within the notification system hasn’t been updated. Most of the time you can cover subgroups with the message text. Consider blowing away the “shift” subgroup and just send to all Plant employees, “second shift is cancelled tonight.” And there are very few emergencies where you’d send a message to only the people that are Salaried.
Yes, of course there are some good reasons to break up the database. You might need to send sensitive information to the Executive Team that need not be shared with everyone. You might have a very large population and want to minimize messaging costs. Or maybe you send messages so often that you’d get push-back from the “unaffected” portion of the population.
Erring on the side of simplicity, however, is a good policy. Consider REALISTIC scenarios about how you might want to selectively send, and then set up the system that way. Of you start with complexity, the person launching the notification might start using that complexity and you’ll ultimately end up in the “notified ‘too few'” category. If you start with simplicity, you won’t have the “too few” issue problem. You can always break up your database further as you run into realistic scenarios where that is needed.