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!)