E-mail
Project Description
This feature will add two way SMS integration to CiviCRM. SMS will have similar functionality to Email send. You can send SMS to a limited set of contacts or do an SMS blast to a larger set of contacts similar to CiviMail. We will also handle reply back and attach the replies to an activity and/or allow an admin to respond to the SMS.
Hours
- This MIH is currently spec-ed at 100 hours.
Background Information
- A Proto-CiviSMS
- Need to do research and see if we can integrate with RapidSMS
- See intersection with Ushahidi
- Fisheye: CRM_SMS (draft) (the rough CRM/SMS code from 2.2 was forked to create a working Drupal module, civicrm_sms; the hyperlinked code was an attempt to merge that fork back into 3.x; it includes two providers, "Twilio" and "Mock")
Requirements
- The site will need to have access to an SMS API as detailed in providers below.
- Email based SMS will not be supported
Features
- Send SMS to a set of contacts via the Actions task list
- Send SMS to one/more groups via an interface similar to CiviMail with restrictions on message size
- Create activities for both outbound and inbound SMS
- Allow the user to mark a phone number as the SMS number (similar to Bulk Email). If no such number exists, the SMS will be sent to the Mobile phone number if it exists. Multiple phone numbers for a contact can be marked as Bulk (similar to what we did for NYSS)
- Mark phone numbers on hold if a user has requested to STOP messages.
- ?? Implement provider API
- Token support (similar to CiviMail / Send Mail to Contacts)
- Track and create Activities for SMS replies. Create a contact if we cannot find a phone number associated with that inbound SMS.
- ?? do we get any data besides phone number? if not can we create a contact w/ just phone number ??
- Admin screens to manage and respond to SMS replies
- not sure what this means? Admin finds a reply activity in activities tab and sends a f/up SMS? Adv Search to find contacts who replied in a specific way to an SMS blast? or ??
Providers
For the first phase we'll provide and interface for any SMS provider. However we'll have an implementation only for Clickatell. Some other providers worth considering include:
Phase 2
- Allow questions to be asked via SMS. Collect responses in a specific custom field if it passes validation
- Add support for multiple providers
- Integrate with RapidSMS
Labels:
4 Comments
Hide/Show CommentsJan 16, 2012
Eliot Mason
Under features, I'd request:
1) an Opt-in field - or set the Opt-out field to TRUE as a default. These aren't the same as email, which are essentially free.
2) In addition to sending SMS to a set of contacts, this will allow an SMS to be sent to a single contact from the contact screen, right?
3) When logging the activity, please consider logging the subject or some other useful identifier of the SMS
Jan 31, 2012
Leo Burd
Have you already considered using VoIP Drupal (http://drupal.org/project/voipdrupal/) for the CiviSMS implementation? It already handles sms dialogs (via a platform-independent dialplan scripting language), multiple sms providers (including Tropo and Twilio) and makes it easier to integrate voice (as in making and receiving phone calls) and other text-based channels (such as IM and Twitter) into the user interaction.
Feb 01, 2012
Tim Otten
That sounds like a useful project with some good engineering.
How tightly is it coupled with Drupal? Most of those ideas -- a platform (Tropo,Twilio)-independent dialplan and an abstracted SMS provider -- would be useful for any PHP developer on any platform (Drupal, Joomla, WordPress, CiviCRM, custom). For example, voipcall/voipscript.inc doesn't appear to have any Drupal dependencies -- but voipcall/voipcall.module obviously does. Would it be useful or hard to segregate the Drupal-specific bits?
Feb 02, 2012
Leo Burd
The core VoIP Drupal modules (http://drupal.org/node/1078790) barely touch Drupal's API. It's relatively easy to port them to other systems; the only connection points have to do with database access, a few forms, and a few callback URLs. In fact, if you know folks who might be interested in porting VD to other platforms, please let me know. That's something that I'd love to explore more.
Several of the non-core modules (click2call, phonerecorderfield, etc.) are dependent on Drupal's CCK and node architecture. We might have to find the equivalent structures in the other platforms and figure out how much effort it would be involved in the conversion. Still, even in those situations, there are many lessons learned (and even code) that we might be able to borrow from Drupal.
What do you think?