One of my projects at the moment is to look at our options for building SMS enabled web applications (specifically for us around our Zend Framework based apps). Both for data capture (Inbound) and as an alerting / notification system (Outbound).
Thought I’d pull together some of my thoughts and reference material [not exhaustive or complete yet] in case its of use to anyone else in a similar situation. But first I’d like to thank my good friend Jem who helped identify some different angles on this…
LinkedIn Q&A is a great reference – here are a few relevant threads that I came across (you’ll probably need a Linkedin.com account to get to these) there are lots more if you search around with SMS related keywords.
There are 2 main options – and as always its the struggle between D.I.Y and DRY (Don’t Repeat Yourself – or my version DRY-OFF – DRY or others [for f sake? I just wanted it to be OFF as it sounded better; anyway I’ll shut up now!])
- roll your own SMS Gateway (with something like Kannel)
- make use of an outsourced SMS gateway / broker such as bulksms (disclaimer:Â I am not recommending bulksms – I haven’t used them – linked as an example of the kind of provider)
Roll your own
pros – complete control over messaging and ability to iron out any kinks in connectivity etc, potentially cheaper to run / only costs you what you use (rather than having to buy credits)
cons – more complex to setup in the first place, need to buy & setup some hardware somewhere etc
Pros – ease of getting it up and running if the integration API (eg HTTP, XML/E-mail based) is easy to pick up
ConsÂ – my concern around these guys is how do you how good they are – will they disappear tomorrow? What gateways are they using, how reliable are their channels etc.
Guide to Gateways (US focused) but has some nice general considerations) http://www.developershome.com/sms/howToChooseSMSGateway.asp This site also has a really nice comparison table – which you could also use as a template for doing your own matrix/scoring comparisions of these services.
We will probably go with a combination of the 2 options – using our own system for the development of services (as we have greater control) and then making use of a partner once the message volumes go above what is finanically viable/scalable in house…
Once the technical bit is out of the way you then need to consider the usability and process flow around the app – eg if users are sending in data, queuing, acknowledging their submissions, correcting mistakes etc…
Hope to post more on this topic if I get the opportunity! If anyone has any insights or good resources on this topic then by all means please comment on this post!