How we saved the People’s Summit nearly $10,000

This is the story of free and open source solutions that made an event more inclusive and less costly.

On the weekend of June 9th, 2017, thousands of progressive americans came together in Chicago for the 2nd annual People’s Summit. There were inspiring speakers, such as Nina Turner, as well as  brilliant panels that enlightened, informed, and educated the throngs of activists who had gathered from around the nation. The keynote speaker was Bernie Sanders, who asked the assembled crowd of over 4,000 attendees, “How many of you have run for office, or are actively involved in local campaigns? Stand up.” Half the audience stood. It was truly inspiring.

A few months earlier, in April, organizers came to us, looking for a solution to sell tickets more profitably. Last year, Eventbrite had cost them an exorbitant sum of money in fees. Fees that could have been spent on stipends to help people attend—one of The People’s Summit’s main goals. So, this time around, they wanted to deploy their own ticket sales system.

In the end, we delivered a unique solution that not only helped them achieve their goals, but also saved them ~ $10,00 in fees.

The First Problem: High Eventbrite costs

Eventbrite charges a fee per ticket ($0.99) and takes a percentage of the ticket (2.5%). We created a spreadsheet where we did the math, taking the tickets sold through our system and applying the eventbrite cost to them.

ticket type cost approx ticket sales eventbrite fee per ticket total fees
Scholarship Ticket $0.00 474 $0.99 $469.26
Low income/Student $45.00 1042 $2.12 $2,203.83
Regular $115.00 1283 $3.87 $4,958.80
Solidarity $225.00 230 $6.62 $1,521.45
Institutional $350.00 68 $9.74 $662.32
eventbrite total $9,815.66

This spreadsheet doesn’t include the one-time fee paid to Good Good Work for creating the new ticketing system or payment processing fees—which can’t be avoided. In the long run, however, this sum will be the total savings for each of The People’s Summit’s events.

The spreadsheet takes the fee from Eventbrite and sticks it into our formula with the ratio of attendees based on a past event.  Because there are always additional fees when credit cards are a payment option, the Stripe fee is an unavoidable expense, even in a new system.

By setting up our own ticket shopping cart with the WordPress plugin Tickera, we were able to provide the same functionalities that Eventbrite has:

Example of the PDF ticket generated by Tickera
  • Online cart, sales page, etc.
  • Multiple tickets with different prices
  • Payment processor (using Stripe)
  • Paper ticket generation with Tickera via PDF download
  • Day of event check-in via Tickera phone apps that could scan printed QR codes

The major feature that Eventbrite has and that a WordPress plugin can’t provide is exposure. People go there to find tickets! For many events that might be an issue, but The People’s Summit had enough exposure on their own. They knew that they would sell out before even making an announcement, so they didn’t need Eventbrite to make them more visible than they already were.

Because we were able to handle all the other features through Tickera—which had a $99 price tag—we could avoid paying third-party fees.

Some key points here include:

  1. The power of open systems like WordPress.
    Because WordPress is a free and open system designed to be extended with plugins, there’s a whole ecosystem and user-base available to developers who wish to solve problems, such as ticket sales and event registration. This ecosystem can provide inexpensive solutions to millions of people in a decentralized way. Where Eventbrite has to maintain many servers and staff to keep everything running, that overhead is distributed among the WordPress community of users and developers. It is all-around more economic.
  2. An investment that gets less expensive with age.
    With a one time investment in hiring Good Good Work, The People’s Summit now has a system that will save them money over and over in the next few years. While they saved ~50% of $10,000 this year, next year they will save 100%. And as Eventbrite fees increase, they will continue to save more and more. A little investment of resources now will net a huge win in the future. Ultimately, profits will go exactly where they’re meant to go rather than into the pockets of third-party websites like Eventbrite.

The Second Problem: Making a more inclusive summit

Summit organizers knew they were in the unique situation of having more people who wanted to attend the summit than what the space allowed. The event was going to sell out, which would skew the attendee profile towards people who could afford to purchase tickets fast. This wasn’t what organizers wanted.

The People’s Summit wanted their own, personalized ticketing system that could circumvent the need for a website such as Eventbrite. They also wanted a more open application process that could empower partner organizations to select attendees from their diverse crowd of applicants. They wanted the conference to be a true representation of the American people; diversity in age, race, location, identity as well as individuals with a different mental or physical stance, outside of the usual binaries. Its final goal was really to make the event all-around inclusive while saving them as many third-party ticketing fees as possible.

Our solution had to be flexible, fast, and easy enough for organizers to use. We immediately began researching the problem. There were three main systems to consider:

  • Applications system – We needed to create a step in the application process that would involve partner organizations first, before moving accepted applications on to the registration process, starting with the gateway.
  • Registration Gateway – Once an applicant was selected, the website needed a way to verify the acceptance before letting them buy a ticket. We also needed to be sure that the applicant’s data – such as a registration code – hadn’t already been used to buy a ticket before.
  • Sales system – Once an accepted applicant was through the gateway, we needed a way for them to purchase their ticket—minus the Eventbrite fees.

Once we fully understood the problem and the requirements, the solution and its design quickly became clear.

Here’s the chart mapping the review system we created. Click here to find out more about the process.

The Good Good Work team always aims to empower our clients to use and adapt the systems we create for them. That’s why we live by the principle of meeting people where they’re at technologically. In the case of The People’s Summit, we opted to use Google Spreadsheets because that’s where the organizers were doing their work. We didn’t introduce any new or hard-to-grasp tools because we felt it was better to follow our stakeholders, even if there might in fact be more effective tools out there.

As we were working closely with organizers and talking to them about the system in a holistic way, we were able to develop systems that saved countless staff and volunteer hours in addition to the final ~$10,000. I’ve created a more detailed technical overview. Go check it out!

The Final Product consists of…

  • An application and registration process that allowed partner organizations to accept the right applicants and automatically grant them access to buy tickets.
  • A ticket sales platform that we integrated into the existing summit website which could handle the sale, distribution, printing, and collection of tickets for the event.

In the end, we were able to solve some complex problems with elegant solutions in a matter of weeks. We hit a constantly moving target, for which we’re all very proud. By stepping back from the problem and taking our time to thoroughly examine the solutions, we were able to save The People’s Summit many hours of labor as well as thousands of dollars. We managed to automate a system that our client didn’t even imagine could be.

This years registration was pretty smooth, in large part to the staff and volunteers and the system we put in place.

The People’s Summit can now do all their own ticket sales, no longer reliant on Eventbrite. They’re mostly self- sufficient; they might now be dealing with more overhead, but it comes with more control.

In fact, with a little more investment, the system we built for The People’s Summit could be generalized and used by the smaller partner organizations who don’t have the resources to hire the developers to do this.

Each time organizations use open systems like WordPress, they support all the little organizations who don’t have the resources. We built something that could be used and re-used and we supported a group who has already built a successful ticketing system (Tickera), which then helps them continue to make their product better.

If you’re organizing an event and think that a system like this might be helpful – or you’re into saving thousands of dollars, give us a holler.

The post How we saved the People’s Summit nearly $10,000 appeared first on Good Good Work.

Hacking Tanzanian Water Systems with Taarifia

I had the pleasure of working on a very excellent project this week. A little over a year ago, I was introduced to Taarifa, a Tanzanian project which aims to make potable water available to all.

I met Taarifa at the Hackathon for Disaster Response 2.0 in Birmingham, UK. When last we left Taarifa, it was moving from a service called Ushahidi to a custom built API. To this task, I suggested a distributed method of hosting and data sharing with custom APIs built in Python+Flask called Data Anywhere. It appears that Taarifa has gone that route, and created their own API in Python+Flask! See the code on GitHub.

(Read more about why this is a good idea on my post about Data Anywhere, or check out the Data Anywhere Website.)

Over the three day hackathon, I created a mock-up for the Taarifa system’s potential front-end. This was based off of the field reports gathered by the awesome Willow (@willowbl00) and discussions from other folks who worked on this project for over the past few years. So now, let’s talk a bit about what Taarifa is and what its use cases are. 

Check out this video to get a better understanding of the situation in Tanzania:

In the most general sense, Taarifa stores and updates data about water points in and around Tanzania. It serves the Tanzanian Water Ministry by allowing people to submit reports of broken water points and give the Ministry a birds-eye view of the situation on the ground (when cell and data service are minimal). There are water points (wells or large tanks on stilts) spread across the country. Water Ministry Officers manage all the water points  by sending Engineers out to install or maintain them. The Water Minister oversees all of this while normal people use the points to gather their water. Informal maintainers make money by filling up the tanks with either fresh water or, in some cases, salt water.

I’m told that people who can afford it will purchase fresh water for drinking, and use salt water for cleaning (gray water). While those who can’t afford fresh water will drink the salt water. I am truly privileged to live in a society that has such an abundance of cheap, fresh water that we can shit in it.

White board sketch of user roles

I drew this whiteboard sketch to outline the different user roles that would use the Taarifa system, either through a web application, a mobile app, submitting text messages to the app, or by simply telling someone else who can.

The Water Engineer

whiteboard_user_engineerA water engineer drives around installing and repairing water points. They tend to have GPS units and smart phones.

They want to submit reports that water points are broken (or fixed) and they want to know which water points need attention.

The Water Officer

whiteboard_user_officerWater Officers manage the engineers from their desks in the Water Ministry. Currently these officers update a CSV file which they download and then re-upload. (I know, it’s terrifying).

Officers want to be able to update water point data, see up-to-date info on what is broken and where. They also need tools to make “punch lists” (to-do lists) for the engineers.

The Water Minister

whiteboard_user_ministerThe Water Minister is the person at the top. They want the birds eye view of everything that is going on.

They have goals to meet and people to answer to.

The Informal Participants

whiteboard_users_informalThe people who use the water and those who fill the water are considered informal actors. They might have data enabled smart phones or, more likely, SMS enabled “dumb” phones. However, with data rates, they probably won’t be too inclined to use those systems to submit reports. Like most things, they will use word of mouth, sometimes marching into water ministry buildings to report broken points.

Someone shared with me their observation of the political will of the people. They said that the history of Tanzania is such that people’s attitude basically breaks down to “that’s the governments responsibility, but they don’t get anything done.” I wonder how true this is, as I have witnessed the same attitude in the US (“congress should solve ________, but they can’t get anything done.”)

This informs a desire (of a few of us) to use the Taarifa system to bootstrap a more autonomous means of solving the water problem. If anyone could report a problem with a water point, then potentially anyone could solve that problem. With public data it becomes possible for non-state actors to make a positive impact. This, however, brings up the political issues of open data.

If we open up the data, it might show that some people are doing a piss poor job. It might also eliminate other people’s usefulness. It’s easy for someone like me to rally for open data when I have no stake in the data remaining closed. The pressure to keep data closed doesn’t always come from those in the most powerful position, it also comes from those lower down the totem pole, but this is a tangent for another blog post.

Taarifa user interface mock up

I determined three main views that the API interface should have. The Dashboard, which shows an overview of data points, the Waterpoint (or item view) showing a single entry into a data point and a List view (or search view) which shows a list of data. I also had the idea of a Feed view which would show recent changes to the dataset, but didn’t get around to mocking that up.

Look and feel

I based my initial design on a mock-up another member of the Taarifa team had made, which featured a dark color scheme and small boxes of bold graphic information.

I kept the dark color scheme with neutral gray. The nav bar is the darkest gray, while the in-between space is a lighter gray. Lighter gray elements then pop out against the dark backdrops.

I wanted the design to feel like an application. It is full width and has simple bold elements. A persistent header acts as a way finder.


This header, I feel, is currently not well thought out and could use a lot more work.
Alas, one can only do so much in 2 days.

taarifa_web_mock_querycardThe “query card” is a small card that presents a single point of data in a bold manner. It could be a pie chart, a graph, or simply a number. I would like to see these as widgets that users create by adding simple query strings together.

The Dashboard


This view allows a user to see a broad overview of the data set. On the right, is a map with a key and messages that display on click or hover. Ideally, data could be filtered by way of drawing polygons on the map or adding specific filters using a stackable filter UI.

taarifa_web_mock_filterThe filter accepts strings, has drop down for common attributes (in this case district and status) as well as the ability to “stack” additional filters. I based this off the OS X finder search design:

screen grab of the Mac OS X search function
Click to learn more about Mac OS X search.

The ability to save searches can allow for detailed searches to be shared to other users.

The Search View

Using the same search filter as above a user should be able to view large lists of data:

taarifa_web_mock_searchThe map on the right can be toggled on/off and will zoom to fit the extent of the search data. Search data will be presented in list form, a bulk edit option should be available. The ability to drag and drop rows into custom data sets, like a work list for engineers, would be a great addition.

The Item View

The last two pages I was able to mock up, represent single items from the database. The Water Point and Report items are often linked but stand on their own.

taarifa_web_mock_waterpointThe Water Point above has some basic information as well as a few “Query Cards.” We were hacking on a few items that could provide real time data about flow and water levels in the Water Points, so I imagined what that might look like.

taarifa_web_mock_reportThe next data item I mocked up is a report. This is what an engineer or person would send in to the Water Ministry. I added a “confirm” button primary, so the Water Officers don’t get frightened that their job is at risk. Below are other related reports (perhaps reports that share the same Water Point or reporter.)

Query Cards

taarifa_web_mock_querycard_editI’ve already touched on the “Query Card“, here is my idea for building one. I imagine that the Query Card will take the current view’s data set and visualize a date range, data type, and particular column of data. Each Query Card is then saved and can be inserted into particular views. Perhaps users can customize their views with Query Cards that are best suited for them.

Next Steps

This is a very rough mock up with more emphasis on visual design than a real hard look at usability. I’m sure it can be much improved and I would be happy to hear about your ideas.

A key feature of Taarifa is that it is flexible. While it is being designed for Water Point management in Tanzania it could very well be used for Water Point management in India or canvasing data in Brooklyn. So the really important next steps for this part of the design process is to abstract the above designs into a one-size-fits-all mock up.

In my dream world you would deploy the Taarifa API on a server (or servers), deploy this front-end, and customize it to fit your needs before plugging it into the data source.

It should work just as well for any potential use case.


Here’s a day 2 check in with an overview of most of the folks who participated: