Here at Omnilert, we often see schools, businesses, and other institutions seeking a better way to manage user information for their emergency notification systems.
Most see ENS data management as a choice between two options:
- Opt-In: Where all users self-subscribe and maintain their own contact data.
- Opt-Out: Where the institution collects and adds contact data into the ENS. (Users must unsubscribe to stop alerts.)
Choosing “Opt-In” can take time. Opt-In requires end-users to take action, supply their contact info and that can be hard to make happen. Some states (I’m looking at you, Texas) even mandate that schools load data into their ENS. So, a purely “opt-in” system might be off the table.
Choosing “Opt-Out” puts a lot of responsibility on your IT team to get it right. If you’re loading in contact info, it’s “garbage in, garbage out”. Bad phone numbers don’t do anyone any good. Someone’s going to have to make sure that data you’re loading is good and up-to-date. That task is what I like to call “herding cats”. (I believe that’s a technical term coined by EDS.)
This is where the roles of Emergency Managers and IT departments come into conflict.
The Emergency Managers out there will say “Let’s go with Opt-Out”. From their point of view, it’s a no-brainer. “Get everyone in on the alert system right away. What could be the problem with that? Let the IT guy figure out how to keep it updated.”
The IT Manager then looks at local systems and wants to go with “Opt-In”. Why the pushback? You see, in most cases, institutions don’t really have good, solid data. They have partial or what I call “sketchy” data. Most institutions also don’t have any ready-made processes in place to collect and update the data that’s there. So, the IT department see this as a big whopping project they didn’t ask for and, worse yet, didn’t budget for.
It’s no fun throwing your IT department on the fire. (That’s how they will see it. Trust me on that!) Still, the Emergency Manager wants an ENS loaded up. It’s important to get an ENS running quickly. So, how do we crack that nut?
Well, we have a solution and it’s pretty simple: we call it “The Hybrid Method”.
The Hybrid Method takes the best of both Opt-In and Opt-Out and combines them together.
You know that there’s some data, but it’s not perfect. It’s far from it, but it’s all you’ve got.
Why not take an upload of that existing contact data and then let your users log into the ENS and update their own information? Think of this as “crowdsourcing” a big data cleanup, courtesy of your ENS.
Here’s the process in seven easy steps that I call phases:
- Phase 1: Assemble Data from local systems
- Phase 2: Upload/Import Data
- Phase 3: Set up login system / process for users
- Phase 4: Notify end-users
- Phase 5: Production mode and Testing for your ENS
- Phase 6: Download user-supplied ENS data [Optional]
- Phase 7: Update Local databases with data from ENS [Optional]
Phase 1: Assemble Data from local systems
In this phase, you will assemble the contact data that you have in local systems. This is typically taken from your LDAP, Active Directory, ERP system, SIS, or another digital repository of user information, such as a payroll database, that might contain contact information that you can use for emergency notifications.
The goal here is to produce a simple table-style (CSV file or spreadsheet) “data dump” of usernames, first/last names, and contact info (email address, phone number, etc).
If you only have email addresses on file, then that’s where you start. (Remember, we’re going to be asking users to fill in the gaps.)
Phase 2: Import user data into ENS
Hopefully you have a good, responsive ENS vendor. (I recommend Omnilert for obvious reasons.) Your vendor should be able to help you get that data imported into your ENS quickly and give you a template for using down the road.
Phase 3: Setup and test user login / update process for ENS
Since you’re uploading info into your ENS, you can control the user’s login info and process by assigning usernames/password according to your needs.
Things to consider:
- Web placement: Make your ENS login easy to find on your website, student/staff portal, or wherever your users go to find info online. End-users are, by nature, lazy. They aren’t going to dig through your website, search for your sign-in page, or navigate multiple sub-menus. Make it easy to find. An icon/link on your homepage will work wonders.
- Ease of Access: Make the login as easy as possible (while still secure, of course!) Hopefully, your ENS supports some kind of Single Sign-On, like Shibboleth or has LDAP login support, using your local LDAP to allow users to log in easily.
Give this process a thorough testing to make sure your users will be able to sign in easily.
Phase 4: Notify your end-users of the process
Now that the data’s loaded and we have a process for your users to log in and update emergency contact info, it’s time to make some noise. If you don’t tell people that you have an ENS, they aren’t going to log in.
There’s lots of options here. You could send a form letter, mass email, post on web portal/news sites, and even post updates/instructions on your social media sites, such as Facebook and Twitter. A key to getting participation is making your system known and easy to find. A hard-to-find ENS is a sure-fire way to have low participation.
Your users should now log into your ENS and update their own contact records.
Phase 5: Production use and Testing
At this point, your ENS is populated with the best data you had available and your users can now log in to refine the system for you.
Some things to watch:
- Keep an eye on user activity. Check to see how much new info is being added. Also, see how it’s going by checking with some of your users. Make sure they are comfortable with logging in and can follow the process you’ve created.
- Tweak the login process as-needed. Don’t be afraid to change / update instructions or even the log in processes. If users don’t seem to be logging in, see whether they can’t, don’t know where, or just don’t know how to log in.
Give your community some time (a few weeks or even a month) and then run a system test. Testing your ENS is a great way to hone your emergency plan and also advertise your ENS.
You’ll see an increase in participation after any system test from all those who ignored you before and the results of a test will help you see where you have gaps in your plan.
Essentially, you’re done at this point. You have a system up and running with little effort.
Phase 6 & 7: Download and Update with User-supplied Data [OPTIONAL]
Ok, it’s been six months, or a semester, or maybe a year. Your ENS is running great. You could just let the process keep running and you’d be fine. Maybe you upload some new usernames now and then, or let new users just opt-in from now on. That’s really up to your local policy.
Hopefully, you’ve created a buzz that got lots of participation and have a pretty solid ENS database. That lots of good data. What can you do with that info?
Well, your ENS system should allow you to pull a report of the current user information.
If you can, then export that user data from your ENS. Your IT team can then use that data to update their local records, adding all of that missing contact info that you’ve collected.
Now, your local systems will have even better user records to load next cycle, and nobody is stuck herding cats.
