Building an Open Source Campaign Management System

Over the past 6 years, Indus Action has been working to spread awareness about Section 12(1)(c) of the Right to Education Act amongst communities that stand to benefit from the provision. Our on-ground awareness campaigns involve volunteers, Shiksha Sahyogis and employees of our CSR partners – all of whom run ground surveys and missed call campaigns as a part of this process. The goal is to spread information about the potential benefits of the policy and provide process support to applicants through the application, admission and school-going process.

Our Campaign Model looks to provide a series of nudges to the beneficiary at different stages of the process – the objective is to take the beneficiary from a stage where they are possibly not even aware of the existence of the policy to one in which their child has been successfully enrolled in a private school of their choice and has then completed 6 months in said school. Our beneficiary data model visualizes this as a successive progression along with a series of stages – from determining basic eligibility to ensuring the right documents are in place, to ensuring the actual application is filled and so on. A detailed workflow of this progression for the RTE 12(1)(c) process is given below.

 
   

A successful campaign is one where the largest number of beneficiaries progress to the final stage of the workflow. In order to visualize this movement across stages and to monitor dropouts at each stage, we maintain what is called a campaign funnel, an example of which is detailed below.

 
         
Campaign Management System (CMS)

In order to keep track of the beneficiary data we manage and monitor the progress of tasks in the pipeline, we have evolved a software platform built exclusively on open source technologies. We call this platform the

Campaign Management System

or CMS. CMS is meant to act as a one-stop-shop for our campaigns and takes care of the following aspects of our workflow:

• Managing beneficiary leads from various sources, particularly ground surveys and missed calls

• Routing these leads to our callers deployed in various states 

• Managing callers’ tasks (now also possible) in an offline environment

• Storing beneficiary data in a set of

  configurable forms

• Monitoring campaign progress and

  visualizing

  the same on various dashboards

• Analyzing

  data for campaign decision making

Components

From a functional level, The Campaign Management System consists of two primary components:

1. Campaign Mobile Application

   – available on both Android & iOS platforms, this mobile app enables its users (which include volunteers/Shiksha Sahyogis/Government Officials) to contact beneficiaries and potential beneficiaries as they navigate through the RTE Section 12(1)(c) admissions process

2. Campaign Web Application

   – the web app is essentially the admin interface of the Campaign Management System. It enables Indus Action employees and campaign managers to manage users and user groups, view performance metrics and modify task flows (including modifying what data is to be collected)

The same version of the product is used in all locations in which Indus Action will be running campaigns.

Technology Stack (CMS 2.0)

The choice of architecture for CMS has prioritized both flexibility and scale – Our campaigns last year involved close to 400,000 transactions on the system over a period of 6 months across 10 states. Given that the RTE 12(1)(c) policies vary significantly from state to state and that we want to use the same product as we expand to other legislated rights, we wanted to build a product that would be able to support a flexible data collection format. Our current implementation allows full flexibility of configuration at the following levels:

1. Task Stages – The sequence and type of stages of progression of beneficiaries are defined here. In CMS, these can be configured at the level of states.
2. Task Statuses – These include the possible set of transitions between various stages. These can also be configured at the level of states.
3. Task Forms –  These include the beneficiary data that is to be collected within each stage of the process

With these goals in mind, the following choices were made with regards to the Tech Stack of CMS:

• • Backend:

    SailsJS

  • Front End:

    ReactJS

  • Database :

    PostgreSQL (for structured data)

  • Form Management:

    Form IO and MongoDB (for unstructured data)

  • Mobile App:

    Ionic Framework (Hybrid for Android & iOS)

  • Visualizations:

    Kibana

  • Data-Store:

    Elasticsearch