Super cool new SMS gateway: Twilio

[edited 10/5/2010 to add: People! We're glad you like the Twilio gateway, but do not rush off and create your own Twilio account. In order for it to work with libraryh3lp as a gateway, we (as in the libraryh3lp people) have to acquire the phone number for you. Full instructions below.]

We're excited to announce our newest SMS gateway. This one is backed by Twilio and by all indications is extremely robust. It features:

• A phone number for your patrons to text.
• Nearly instant message delivery. No polling interval.
• Automatic notification to the patron when the library is offline.
• Offline messages are delivered the next time your queue comes online.
• Not free, but very affordable.
• And of course, it integrates into LibraryH3lp like all our other gateways. Text messages can be transferred to other librarians, transcripts stored, statistics gathered, etc...

Specifics:

• Cost is $1/month per phone number.
• Messages are $0.03 each. 1,000 messages is $30.00
• This is at-cost and is exactly what Twilio charges; there is no LibraryH3lp markup.
• Currently, only US phone numbers are available via Twilio for SMS. However, international text messages can be sent and received.
• Voice phone calls can be redirected to your regular library phone number.

To be clear, each message (not conversation) is $0.03. So, the following is $0.06:

Patron: anyone there?

Librarian: Yes

If you want a Twilio SMS gateway, please write to Eric, and specify:

1. the queue you want it installed on,
2. your top-level admin name,
3. your desired area code for the phone number, and
4. the phone number you want voice calls to go to.

We will acquire your Twilio phone number. We cannot currently make the gateway work with a Twilio number you acquire on your own.

If you are currently a Google Voice SMS gateway user, and you want to have your Google Voice SMS's forwarded to Twilio, let Eric know and he can set that up as well. (Please specify your GVoice SMS gateway's queue.) This way, your patrons keep texting you at the same number, but their messages will come through instantly.

How do I pay for this?


Please do not pay Twilio directly!

Use this payment page.

Nothing expires at the end of a year; it's really just a lump of money used to fund both the phone number and the messages.

If you want some other amount, let us know and we can set up a payment page for it. You can purchase any arbitrary amount of messages.

What sets this one apart from our other two SMS gateways?

Unlike the Google Voice SMS gateway, Twilio has public APIs. It has been created specifically so that developers like Eric can use it within their own applications. This means it will be much more stable and have much faster message delivery than the Google Voice SMS gateway.

And unlike our Android phone SMS gateway, libraries do not need to purchase a phone and keep it connected to reliable network and power.

Why do we keep changing SMS solutions?

To be clear, neither of the other two SMS gateways are going away.

We want our SMS gateways to be affordable and to allow patrons to text a phone number. When we started, the Android gateway was the only way we could come up with to accomplish that. Developer solutions were quite expensive. Then, when Google Voice came along, we adopted that very quickly and have implemented that gateway as best we can, but since there is no public API, it's fragile when Google makes changes (we knew this going into it and were very open about this fact).

Now, Twilio is here and is a big leap forward. It is a great fit with LibraryH3lp. We hope you'll enjoy it!

(Twilio is also available for My Customer Cloud users.)

[original message edited 9/15 to clarify sign-up info and to add payment info]
[edited again 7/12/2011 to fix payment links]

Introducing My Customer Cloud

My Customer Cloud is another new product in the LibraryH3lp family. Because LibraryH3lp has gotten so popular over the last few years, I regularly get signups even from outside of the library/academic community. In order to better serve the non-library users, I've expanded the company and taken on a new programming partner. We've created this additional product with a new usage-based pricing model in order to best accommodate everyone.

Rather than paying an annual subscription fee based on FTE or service population, My Customer Cloud users can pay per-chat, only for what they use, and still have access to all the features and integrations that LibraryH3lp users have come to expect.

But it's not just for non-libraries. The annual LibraryH3lp subscription model exists primarily because of stodgy, antiquated library purchasing policies. (Sorry, but you know it's true.) Libraries that can be a little more flexible in their spending now have the opportunity to pay less by choosing My Customer Cloud. Low chat volume libraries may wind up paying even less using My Customer Cloud, while busier services will probably find it cheaper to go with LibraryH3lp.

So, please, check it out.

Widgets for Individuals vs. Queues: A Change

Since LibraryH3lp started, we've handled widget chats differently based on whether they were for an individual librarian or for a queue. Specifically, chats for queues had a number of special features:

1. they could be transferred;
2. files could be shared between librarians and patrons;
3. the patron's IP address and referring URL displayed to librarians in the webchat client;
4. queues could have profile pages viewable via the webchat client; and
5. transcripts could be stored in the admin site, with statistical reports also available.

Chats for widgets pointing to individual librarians lacked all of those features.

This often led admins designing chat services to create a queue for each of their librarians, with exactly one librarian assigned to each queue. This way, chats targeted to those librarians would have all the extra flexibility associated with queues.

This practice has become especially prevalent in service rollover models, where chats are routed to a subject expert, if available, but will fall over to a general reference service if the expert is not available. With their very own queue, the subject expert could transfer their patron to another librarian or to another queue as needed.

That workaround was fine, but it created extra work for the local admin, and it increased the overall confusion level.

Today, we rolled out a series of fundamental behind-the-scenes changes that blur the line between individuals and queues where widget chats are concerned. Now, widget chats for individuals:

1. can be transferred;
2. will display patron's IP and referring URL in the webchat client; and
3. allow file sharing between patrons and librarians.

There is still more work to do to further integrate this change into the admin site. Profile pages, transcript storage and statistics for individual widgets will become available in a later update.

A very important point: this change is only for chats using widgets. Direct IMs between librarians via the buddy list remain and will continue to remain private. They cannot be logged or transferred. Individuals should be buddied as user@libraryh3lp.com.

We'll be updating the docs to reflect this change. In the meantime, the preferred syntax for creating widgets for individuals AND queues is:

http://libraryh3lp.com/chat/whatever@chat.libraryh3lp.com

The old widget syntax for individuals (http://libraryh3lp.com/chat/user@libraryh3lp.com) will continue to work.

We know it can be confusing for our existing users when we change fundamental concepts, but LibraryH3lp continues to be an evolving system undergoing improvements. This change should make life easier overall, especially for new users. We do not think that the change will break any existing code, and we hope that most librarians will welcome the new functionality.