Trickle processing SMS for Collection Sheets

Processing 'perfect' collection sheets as they 'trickle in' via SMS

Introduction

While increasing throughput is one way to scale up, another strategy is 'demand management', i.e., making sure not all of the people need to use the system or service do so at about the same time, and not for everything they need at one go.

How it will work

1. Field officers step out most days of the week and complete 4 to 6 center meetings well before noon, and typically use one or more collection sheets for each center meeting.
2. In the overwhelming majority of instances, they return to the branch and report that all anticipated moneys were received/paid out.
3. For each collection sheet that is printed, we can also generate a suitably short (enough to type when needed) or long (enough to be unique over a few days) identifier printed on the collection sheet. The field officers also receive a single SMS on their cell phones with this identifier for each such collection sheet in their possession
4. As soon as they step out of a completed center meeting, field officers respond and send the SMS back as-is to a service for collection sheets where there are no surprises (all amounts received and paid in full, etc.)
5. At the Mifos end, we subscribe to these incoming SMS and as each genuine identifier comes in, we process the corresponding collection sheet

Benefits

As most center meetings follow similar schedules (fifteen minutes followed by half-an-hour for the field officer to leg it to the next one...), there will still be lumpy traffic with probably several smaller 'humps' through the morning instead of one large spike. Data will also come in earlier and more gradually instead of all at once...

About implementation

"Plumbing" into SMS service

• Incidentally, the infrastructure, services, and the software needed to send as well as to subscribe to SMS are now truly commodity.
• It literally takes just a couple of days to setup, integrate, and test either with a service provider or with independent infrastructure, to read outgoing SMS from, and persist incoming SMS to a database (i've done this and so have others...)
• All the necessary plumbing can be done with no change at all to the product codebase, and its best to persist all sent and received messages to a separate small database.
• The costs of sending and receiving SMS, especially in volumes are now absurdly low, especially in India (as low as few paise per SMS at most)

Product implementation

• Simple services are needed to publish SMS and to act on the received SMS to update the status of collection sheets.
• Also, to rectify any errors and to make changes to any collection sheets already 'processed'. This should be relatively easy, but perhaps there are some messy changes needed with the way collection sheets work today.
• In any case, we can provide a window where field officers return and quickly verify the processed collections, rectify any errors, any absentees are reported, submit the rest, etc.
• When adding field officers, we can capture cell phone numbers and alternatively, allow self-registration and maintenance. Again, SMS can be used too.

Volunteering

krishnan: Can sign up to do a POC/spike, have past experience with SMS campaigns