Texting and PowerBase/CiviCRM

Texting - sending short messages via sms to cell phones is a powerful but untapped tool for community organizing. Recent Pew Internet studies have shown that young people of color use texting far more than other demographic groups, and increasingly access the internet and communicate solely through their mobile devices. Given this, texting has tremendous potential to help community organizing groups in the US communicate with their members. Attempts to incorporate SMS in the past have stagnated (http://wiki.civicrm.org/confluence/display/CRM/CiviSMS) A few important things have changed since then: the use of texting has gone up dramatically, particularly in the United States and the emergence of SMS application framework providers has made it easy and affordable to both send and receive sms messages. While there are still some cost and opt-in barriers that need to be addressed, PTP believes that part of challenge with texting for social change organizations in the US is that the infrastructure is somewhat costly, and more importantly, is complex enough to present a significant barrier to expanded use by the groups PTP works to support. We believe that by building a texting interface in PowerBase - PTP's version of CiviCRM, we can erase barriers to use of texting and make it very easy for community groups to gain first hand experience with this potentially powerful tool for communication and constituent engagement. How it would work: We think the existing CiviMail system for sending mass email is a good analogy for how we envision texting to work. In the mass email system, a user creates a mailing, optionally re-using components, defines a group to send the mailing to, schedules and sends the mailing, and finally is able to view statistics related to the email that was sent. A texting interface - CiviText, would work similarly, but would also provide for accepting information via text back into the database, ideally recorded as a response to the survey question in CiviCampaign. The general workflow would look something like this: 1) User defines a group to send a text to 2) User defines if the text will require capture of data sent back in reply to the text 3) User creates a corresponding survey and question set 4) User creates the text and includes the question and invitation to respond 5) User schedules the text for sending 6) Text is sent 7) Recipients reply to the text and their replies are added as responses in the corresponding survey answer field in their record 8) Users can view statistics on responses: # sent, # delivered, # of replies, and reply details - for free form text answers, the user would see a list of responses associated with the constituent who sent them; for binary responses (Y/N), users would see # of Y/N replies PTP believes that the easiest way to make this accessible to users is to create a mechanism to connect CiviCRM to a tool like RapidSMS which provides the framework for sending and receiving sms text messages via gsm modem/SIM card, or via a commercial texting provider. There is more work to do to fully explore the specifics of building this interface, but we wanted to post this blog and invite Civi community members to post thoughts, comments, and generally help us flesh out this concept so we can collectively move it forward.

Comments

Our organization is very interested in this, especially making it work in Canada.

Sounds like you're tackling a good problem, and steps 1-8 sound like a useful workflow for CiviCampaign users.

It looks like RapidSMS provides a framework and a collection of "apps" (bundled message flows, UIs, etc). If there's a generic way to integrate CiviCRM with RapidSMS that would let you use any of these apps with CiviCRM contacts or groups, then that could be a win.

If you're just looking for an SMS API to handle sending/receiving of messages, then RapidSMS seems like an expensive way to get that. It's a separate application based on a different programming language that will complicate deployment, make training more difficult, create UI inconsistency, etc. It would be easier to use Drupal SMS Framework or write something native to CiviCRM.

So the key question is: How much value would the RapidSMS apps provide?

that's a great comment re: RapidSMS. I think the key is that it provide people with a really easy way to plug into external SMS providers since in the little bit of research that we've done, that seems to be the most flexible way to do it - not unlike how you can use different payment processors with Civi.

From looking at the DrupalSMS framework, that seems to make a lot of sense. Would there be any downsides with using it?

In general, Drupal SMS framework should fine for sending and receiving messages.

A few notes/concerns:

1. Drupal SMS Framework obviously won't work with Joomla or WordPress. We'd want an equivalent, Civi-native API. But on Drupal, the Civi-native API would be a thin layer that just passes requests on to SMS Framework.

2. The Drupal SMS API allows gateway-providers to create their own forms. For example, they can use the Form API to create a 'send form' which is supposed to be embedded on the screen when the user is send a message. Embedding the 'send form' into a CiviCRM UI could be problematic. The issue could be ignored if no actually needs the 'send form', or we could look for a clever way to use drupal_get_form/drupal_render.

3. This has nothing to with Drupal, but there can be design challenges when you have one installation serving multiple users or multiple workflows. For example, if you're running two active surveys, and if you have all survey responses go to the same phone number, then it's tricky to figure out which incoming SMS messages correlate to which surveys. There may be some policies/compromises that are good enough, or perhaps RapidSMS has some design elements we could imitate. ;)

I wonder about the approach of creating a new component to handle a new medium.

I've been musing on the idea of a centralized communications system that can send messages in a variety of formats. For example, compose a single message and, based on each contact's communication prefs, it would either email them, print a pdf letter for them, facebook them, or text them.

That sounds like a really interesting idea. I had assumed SMS would 'plug' into CiviMail as another medium but your idea takes it much further.

The idea of building a a multi-channel communication infrastructure that let users define the best way to be reached is one of the main goals of the VoIP Drupal initiative (http://drupal.org/project/voipdrupal/). 

In fact, we're currently using VoIP Drupal to build a system that distributes information about local events via a combination of web, SMS, touch tone phones, low-cost digital signs, and automatically generated flyers (http://civic.mit.edu/whats-up).  It would be awesome to integrate those outreach capabilities with a powerful system such as CiviCRM!

 

1. Agree with Tim on RapidSMS. Can you expand a bit more on what features / functionality you want from RapidSMS. The protocol that the SMS providers use is fairly easy to abstract (and hence allow plug-n-play with various providers)

2. Tim has built a pretty good reply-to channel (for CiviCRM v2.2) where the civi-admin can reply to an SMS from within Civi. We should definitely plan on building that in

3. Personally asking more structured questions (and parsing the response) might be better for a phase 2 project

Would be great if we can get a few folks interested in this and help fund / develop this for v4.1 (time is running out!)

lobo