History of the Campaign Management System

12th November 2019 | Akshay Vikas

History of the Campaign Management System

After the 2015 Campaign where Indus Action filed more than 10,000 applications in Delhi managing data on Google Sheets, we felt the need to leverage technology more effectively to empower the Campaign Lead(admin) and Helpline team to scale the campaign by 10x in 2016. In doing so, we wanted to prepare the technology platform for replication in other cities across India.

2016-2017 Campaign (Initiation) (VMS 1.0)
2016 was the year of initiation of our software product. In 2016, the first version of Web Application for campaign management (VMS, short for Volunteer Management Software) was developed in-house. The VMS 1.0 version had ICT integration: the ability to send SMS, IVRS, audio messages and interact with campaign data using dynamic dashboards.

2017-2018 Campaign (Innovation) (VMS 2.0)
2017 was the year of innovation. Building on the success of VMS 1.0 and a 10x campaign in Delhi, VMS 2.0 was launched with additional modular functionalities for a Campaign Lead. The vision was to make the campaign management platform as modular as possible so that other non-profit campaigns could be serviced using the same platform in the future. The features aimed for were: Survey ability to create customized forms with validations Kibana dynamic integration to visualize all campaign data Filter, search and export of data through the application Complete control of ICT integration and responses to campaign admin Training kit integration into the campaign tasks User profiles management: allocation, upgradation, leaderboard, etc Feedback loops like beneficiary rating, identification of motivated families, etc. 2018-2019 Campaign (Expansion) (VMS 3.0) 2017 was the year of expansion, which occurred with the following changes: Deployment of the system in 10 locations across India Beginning of increase in volunteer (Shiksha Sahyogi) mobilization, by building a mobile application, on top of the VMS infrastructure.

2019-2020 Campaign (CMS 1.0) We started with the goal of building, over the next 3 years, a system that would persist as a one-stop Campaign Management Product and take care of all aspects of the Indus Action awareness campaigns. CMS 1.0 focused on building a mobile experience for Shiksha Sahyogis. A mobile app, built using the hybrid Ionic Framework, was set up with the support of WebAccess Global. The primary motivation was to set up a mechanism for allowing offline task management and form filling within the app, which would allow data collection to continue uninterrupted 2020-21 Campaign (CMS 2.0)
CMS 2.0 prioritized scale and efficiency across both the mobile and web platforms. It was also our first deliberate step to move towards developing a platform that would be completely open-source. Some of the most significant changes in this release include:

Updated Form Builder – We have switched to an open-source Form Builder (FormIO) which allows for a variety of new features – dependent forms, in-built validations and a host of new input types Single Instance for CMS – CMS for all states are now going to be run on a single AWS instance. This significantly reduces server costs and turnaround time for setting up a new site, which was one of the most significant maintenance challenges as we scaled up. Simplified offline sync – expected to minimize data loss and manual effort from callers Improved beneficiary data model – to minimize errors/duplications and manage escalations

Next Steps: Data Warehousing Solution The motivation for developing a data warehouse for beneficiary data came primarily from 2 sources: Given that data of close to 300,000 beneficiaries (collected across 5 years of campaigns) lies scattered in our databases CMS currently has a dual function of campaign reporting as well as housing beneficiary data. This means that data collected is linked to a particular workflow and there is a dependency on following that workflow if we want to integrate data.
Going forward, we hope to collect data (primarily at the level of the family/household) and use the same for campaigns that span across legislated rights along with the running of full-fledged campaigns for individual rights. Thus, the idea is to build a data warehouse of beneficiary data that sits on top of all our beneficiary-facing products (CMS & MIS will thus feed into the warehouse). CMS (with its workflows integrated with our M&E tool) will then be used as a one-stop-shop to track campaign progress.