This is a guest post by Rinat Abdullin, technology leader at Lokad, a long-time customer and contributor of great ideas and inspiration. Lokad develops forecasting software and services that are delivered on pay-as-you-go basis. The company is a winner of the 2010 Windows Azure Partner Award by Microsoft.
A while ago I’ve mentioned My Dream City, a social project, which I’ve helped to start. In short, the project tries to raise social awareness about kids without parents and attract sponsors to the orphanages. A you would expect, even the smallest social project has to be involved in a lot of communications, including (but not limited to): direct email conversations with interested volunteers, outbound contacts, negotiations with other social organizations, follow-ups, activities in various social networks, etc.
While helping to establish core processes within the project, I’ve leveraged social communications experience of Lokad. Relenta, a simple web solution for managing emails and contacts, is used for both of these cases with great success.
The setup worked like this. We’ve established a single email address for the entire project (firstname.lastname@example.org, which is hosted on Google Mail). This email address is actually the inbox for the Relenta. Every message that gets through, is automatically associated with a contact (if there is a matching one already) or you can create one. Since My Dream City, as a social project, had to deal with quite a few people and organizations, there were quite a few contacts, as you could imagine.
Over the time, as the amount of inbound emails grew, answering them proved to be too time consuming for me. Besides, there had some follow-ups to be done along with contact initiations from our side. So I’ve just scaled out by adding a few volunteers as users to the same Relenta inbox. They were assigned responsibilities over managing contacts. Given the outlined process (explained in one or two wiki articles), it was easy for new users to log into Relenta and get started answering incoming emails and eventually doing more involved activities.
There were a couple of reasons for that:
- Whenever a new email from an existing contact comes, it is already associated with all the previous conversations. So it’s easy to continue from the point, where the conversation had previously stopped (even if the person to continue conversation is a different one).
- In case of doubt or a question, it is possible to look up how similar questions are handled for the other contacts by the other users; or just ask another more knowledgeable user to handle the reply.
- Whenever a user has to leave, his contacts can be reassigned to the other one transparently, without any interruption in the process.
- There is only a single contact email for the entire organization, which makes it simpler for the others to initiate the conversation.
- Since there is a single inbound email route, it’s possible to forward all incoming email messages to an email box or two, using them merely as notification stream and keeping an eye on really important messages that should be handled explicitly.
Another small detail. These ‘users‘ that are doing all the communications, are just kids barely out of the high school (and some – still in). This obviously implies that both the software and the process had to be quite simple and understandable, in order for everything to work out, while managing negotiations with serious companies. As it did work out – there were My Dream City events held for orphans in multiple cities in various countries around the world. And all this achieved with Relenta account, a WordPress installation, free Google Sites, and unlimited enthusiasm of FLEX alumni.
Now, this whole layout resembles something, does not it?
A single email inbox with Relenta CRM system that distributes the work-load in a simple way between multiple users with the ability to reassign work as users’ availability changes or load increases.
I find it curiously similar to a classical “incoming queue handled by a message router with N workers behind” layout of balancing a load in a distributed world. The latter, as we know, works quite well for scaling up/down as the load changes. Especially in the cloud computing environments.
Email communications (or usual paper mails) are the “real-world equivalent” of messaging middleware in the software world. This brings us all the way back to the Distributed Decide-Act-Report analogy for modeling distributed systems in a way similar to the real-world interactions.
In this analogy, Relenta (or any other similar email-based solution, if there is any) acts as an intelligent router and load-balancer. In on-premises environments ZeroMQ, Apache QPID and RabbitMQ are known to be used with success. In the cloud scenarios situation is less straightforward (i.e. glance through this discussion on working around Azure Queues throughput limitations), yet the analogy still holds.
The original post can be found here.