A great phone campaign thanks to CiviCRM and Webforms

Published
2011-12-23 20:08
Written by

This time of year I would normally be entring data from hundreds of sheets of paper, struggling to read people's sloppy handwriting and feeling like I was a slave to our database. But instead, I'm viewing reports on phone calls, pledges and donations, generating reminders and thank-yous -- with no data entry required!

The old way

For years our school has had the tradition of holding a "phonathon" to raise funds. We'd gather about 30 volunteers for a festive night of making calls, eating cookies, and coming together to support the important work we all do for peace, justice and sustainability education. This is how we used to do it:

  • The name, phone number, address and giving history for each donor were printed on call sheets - 1 per page. This was done by exporting a spreadsheet of contacts, then mail-merging it into a Word document.
  • Each volunteer would take a stack of these sheets to a phone and make calls. The call sheet included some boxes to check (left message, not home, made pledge, said no, etc) and a space to jot down notes about the call.
  • If a pledge was made, the volunteer would fill out a pledge form with the amount, and we would mail it to the donor along with a stamped envelope in which they could mail us a check.
  • If the donor wished to give over the phone, the volunteer would write their credit card info on yet another slip of paper.
  • Afterwards, I would spend the better part of a week clawing my way out from under the mountain of paper and getting all that data where it belongs - in the database.

A Better wayWebform Callsheet

Our old MS Access database left us little choice but to do everything on paper, but now that we've migrated to CiviCRM there is a lot more possibility for finding better ways to do things. I spent a while pondering how the Phonathon could be streamlined, looking at different options. CiviEngage is coming along nicely, but I decided against its "phone banking" feature because it seemed too hard to use for our volunteers, and would require granting them access to CiviCRM, which I prefered to avoid. I rejected the core Civi interface (activity and contribution pages) for the same reasons. What I wanted was a gentle transition away from paper forms for our volunteers, something that would be simple, user-friendly, and require little extra training. Here's what I came up with:

  • CiviReport: In the end I couldn't think of a way to avoid printing call sheets - it's just so darn fast, simple, and easy to administer. I could quickly hand out sheets to the volunteers, they could see all the info at a glance, and could easily drop the sheets back into "unreachable" "call again later" and "completed" piles. But this time I avoided the mail merge mess in creating the sheets by writing a custom CiviReport (thanks to help and encouragement from Eileen).
  • Webform CiviCRM: Back when I wrote webform civicrm earlier this year I never expected to use it for something like this, but that project has come a long way in a short time and is now capable of creating forms for just about any purpose. This form allowed the volunteer to update the contact's address, phone, and email, and also log their call as an activity. I created a custom activity field for "call results" with the familiar choices and it worked quite well. (by the way, the "inline" fields you see on that form are thanks to the new webform layout module, another side-project of mine - really helps a form to look sane).
  • A Litttle Custom Code: The "glue" between the webform and the paper sheet is a tiny module which prompts the volunteer for a contact id (printed on each sheet) and then redirects them to the webform, with cid and hash in the url. (the hash serves to grant the user temporary permission for the contact, and worked nicely to avoid giving our volunteers any special permissions to access civicrm). If they enter "Gave credit card by phone" as the call result, it then redirects them to our public contribution form, again with the cid and hash in the url, allowing them to take the credit card over the phone and enter it on behalf of the donor, still without needing to access CiviCRM. I also added some conveniences like generating a link to the spouse in case you find yourself talking to them instead.

Lessons Learned

All in all, the experience was a good one. The webform and module worked extremely well for logging the calls and collecting donations, both for the users and the admin (me). Data entry is such a pain that we've never actually logged the calls before, only the donations. So we're now collecting more information with less work.

After the phonathon I was able to easily search for all contacts who had pledged to donate, and send them a message through CiviMail with a personalized (hashed) link to our contribution page. A week later we sent a follow-up by mail for those who hadn't yet paid online or mailed a check.

For those who didn't want to donate, we now have that information logged and will know not to call them next time.

And that custom report keeps getting better. Next time we do the phonathon, I'll be able to include information about the last time they were called!

I can forsee eventually being able to go paperless with this, expanding that little custom module to manage a call queue, perhaps I'll release it to the public if others are interested. But for now I'm just happy to say "No more data entry! Hooray!"

Comments

Great to hear it worked out well. Did you wind up using my group_concat trick on the report?

I used it allright. The most awesome example is for relationships. I.E. the report could tell you that a person was the parent of Susie Brown, and that Susie was a student from 2005-06 and an intern from 2011-12.

Yes, that meant creating a temp relationships table to group concat, and then joining it onto itself with yet another group concat. Woa.

Cool!

 

BTW - for readers there group_concat trick I'm referring to is, for example, to get multiple phone numbers into one field on the report - there is code for how to do that on the wiki http://wiki.civicrm.org/confluence/pages/viewpage.action?pageId=48398378

 

(I also used it to get the person's last 5 pledges onto the report - code is ... somewhere on the forum)

We used it for phonebanks, had a few issues but worked mostly ok.

 

X+

 

A few comments:

 

1. Would be good to attach the code for developers to download and take a peek at

 

2. I used survey / civiengage for a "auction phonebank" at SFS. The BIG missing factor was the "did not answer/need to call back" scenario (which happens quite often) and survey does not handle that very well :( Would be good to add something like that to survey

 

3. Would be good to consolidate all work done and get all the pieces aligned nicely so we can have a nice clean open source phonebanking solution. All online too :)

 

lobo

 

Wow, this is amazing.

And . . . it is almost precisely a use case I was looking to solve.

Is there any chance you could share the bit of custom code that is the 'glue' in this?  That is exactly the problem I've been stuck on--that it's just not reasonable to make volunteers log in, etc, in order to enter their results.

Thanks!

If you are using Webform-CiviCRM-Integration version 3 or later then you really don't need the glue code anymore. You can use the autocomplete feature to allow volunteers to pull up records in real-time. Pretty slick :)