This is a revision of an old article, from the old website, describing some things I learned about collecting names.
Several years ago, for the Obama elections, I had to manage a bunch of sign-in sheet info. To perform the data entry, I did a few things to make life easier (for me).
We made a web app with the intent that multiple people could enter data into it. That didn’t happen because there wasn’t sufficient time to finish the application and then train everyone. Offices were far apart, the volunteers changed, and that made the logistics of training difficult to impossible.
Additionally, the main way to gain time savings and fix errors was to have a fast typist who knows how to read scrawl and turn it into a name. We had mostly “ethnic” names – non-English, Spanish, Irish, Anglo, Eastern European / Slavic, African and Asian. It turns out that people have a hard time with these names, and, basically, the ideal data entry person has a college education in the humanities and knows a few languages, and also types > 50 wpm. (Just kidding.) Indeed, we are a nation of immigrants. The person reading names must love the world in its diversity.
As an assist, I found that our existing contact databases were a GREAT help. So I compiled all our contact lists into a big database, and made a web service to perform auto-completion based on the database.
So, the most important thing you can do is start compiling data BEFORE the event. Collect names, emails, phone numbers, and addresses etc. Make Google forms for everything. And dump it into a central repository for autocompletion.
Collect data for everyone, not just people going to the event. Get everyone. Get everyone to export their contact lists. (Use iCloud, Google Contacts, etc. to get them off the phones, and a data wrangler person to build the big list.)
Then, during the event, make sure the sign-in sheets and computerized sign-in forms have fields for email, phone, and address. This helps you identify your volunteers.
In the autocompletion feature, don’t bother to make it a little dropdown — show a big list of all the reasonable matches along with email, phone, and address. You’ll usually see the correct person within three keystrokes.
Autocompletion also prevents duplicate entries because you are picking a pre-existing record from the database.
I don’t recall exactly how many names I entered, but it was over a thousand, and it took around two weeks, which included not only entering the data, but writing the software, and also doing some database cleanup so the new data could be merged with existing data to perform some updates (and enrich our main contact database).
It probably took a lot longer than just entering the data, but the quality of the data was considerably better, and the actual data entry was more pleasant because there was less typing. We also used this a few more times, so, it wasn’t that expensive.
If you have electronic forms to do sign-in, you can use that as a data source to pre-fill the actual data entry form. This is a suboptimal way to avoid duplicates and to make sure the row IDs are correct, but it works.
Why not use computers from end to end?
This was, basically, a one-time event (over a few months) as far as we knew. Prior campaigns were smaller. So it made little sense to make something that is world-facing and may fail, causing chaos.
Paper is more reliable, and its easy to replicate, and the people know how to use paper. (This was 2008, and we didn’t know if volunteers would be older folks.)
Today, I’d use web apps, mobile apps, and the CRMs as much as possible, but would not expect to do more than 50% of the sign-in via computers.
Also, sites like Eventbrite offer a mobile app to do registration. You need a person to operate the tablet-based application and perform registration. So, their service design also involves assigning someone to the task of checking people in.
The code belongs to my past employer, so I can’t publish it, unfortunately.