KaleChips is an online ordering and order tracking system built for City Fresh, a non-profit Community-Supported Agriculture group (CSA) in Northeast Ohio. The initial version of KaleChips was written to replace the paper and electronic spreadsheets which staff and volunteers had been using to track orders at the stops and to place future orders.
City Fresh runs several pickup locations (“stops” or “fresh stops” in the CSA’s parlance) in the greater Cleveland area; the specific stops, and their number, vary year to year. The program is organized around “seasons” of approximately 24 weeks. Each week, customers (“shareholders”) show up at a pre-determined stop to pick up whatever share(s) they have ordered, and potentially order for the future.
Unlike most CSAs, in service of the accessibility portion of its mission, City Fresh allows for week-at-a-time, sporadic, and mix-and-match ordering. Approximately 50% of their shareholders order a week at a time. This is partly driven by City Fresh accepting Ohio Direction, the state SNAP/EBT program, as well as their participation in several other county or regional benefit programs. Many other customers order every other week, alternate share sizes, or skip weeks while on vacation. While it adds operational complexity compared to the more common season-at-a-time (or half-season) model used by most CSAs, it makes the program more accessible to folks who would otherwise not be able to participate.
City Fresh had tried once before to move to an electronic ordering and order tracking system built for CSAs, but the unusual characteristics driven by the non-profit mission made it a bad fit; accuracy of orders, charges, and deliveries went down rather than up.
After a successful year focused on the interface for the volunteers and staff, KaleChips added customer functionality, first in the form or order tracking and modification, then online ordering by credit card.
In addition to the day-to-day operations, KaleChips has grown to include custom reports requested by the staff to support capacity planning, growth tracking, the requirements of specific subsidy programs, and grant applications.
KaleChips has three distinct sets of functionality: one for staff, one for volunteers, and one for shareholders. The staff and volunteer functionality overlaps quite a bit, with some functionality included in both sets, and much of the volunteer’s functionality being reports for staff constrained to a single stop. The shareholder functionality is almost entirely distinct. A brief overview of some of this functionality follows.
Volunteers run most of the individual stops, checking in shareholders, possibly ordering for the next week, doing cash-out at the end of the night, and answering miscellaneous questions. Each stop gets its own “front page”, with links to various per-stop reports; we’ll use City Fresh’s largest stop, coventry, as an example.
Each stop begins by unpacking their shares from the truck. Vegetables arrive in bulk, not sorted into shares; volunteers set them on tables and shareholders collect their individual produce. Volunteers use the Share Contents Report to determine how many of each item to pull off the truck (since the truck typically serves multiple stops in a day) and to write out a sign informing shareholders of the contents of that day’s share.
Most of the stop is run by the Front Table Report. This report shows each shareholder who has ordered any time this season, with all future orders, for the remainder of the season. The most common action for volunteers is to indicate a shareholder has picked up their order, by clicking/tapping the word “pickup”, and potentially ordering future shares for them. The most common versions of this are a shareholder with existing future orders, in which case typically no further action is needed by the volunteer and the shareholder collects their food, or the shareholder wants to place new orders, in which case the volunteer is given a link to start that process. Unlike shareholders ordering their own shares, when volunteers are ordering shares for shareholders they payment flow is not included. This allows volunteers at the stop to handle payments in a wider variety of ways (checks, Ohio Direction, vouchers, and so on), to process credit cards using a dedicated card reader (and thus to get better “card present” rates), and to employ some discretion around letting established shareholders run a tab for a week.
The per-stop front page also provides shortcuts for adding a new person, most commonly used if a passer-by sees the stop running and is interested in signing up, and making a new order for an existing shareholder, most commonly used if a shareholder without a share this week wants to order for the future.
And the end of the night, volunteers go through a “cash out” process, to ensure receipts and orders match up. To facilitate this process, a built a cash out aid.
Originally, not all stops had a reliable way of running their stop “live” using KaleChips. An important design consideration was that volunteers be able to run their stops offline, using a paper printout, and enter what happened at their stop after the fact. This influenced the design of the front table report, but also led to the creation of the bulk order modification page, which allows volunteers to report on the disposition of all shares at once.
Staff get their own dashboard, containing links to various common functions, less-frequent reports, and a collection of search functions. In addition to sometimes filling all the roles volunteers fill, on a weekly basis staff is responsible for creating the week’s shares by listing their contents and picking up food from the farmers.
The farmers need to know how many shares will be ordered for the week. Staff discusses likely share counts over the course of the season with the farmers before the season begins, but they need specific numbers each week. Before the week’s pickups begin, the Farm Liaison prints the Farm Report and takes it to the farmers to discuss what they have available in the required quantities, and at what costs. Note that this is another instance where the system is required to handle offline use, as City Fresh deals with several Amish farmers, who will not use the system directly. The Farm Liaison then takes the farmers statements about availability and unit cost to create the week’s shares. There are two different sizes of share supported, and each needs to be set up separately. KaleChips tracks the cost of each item to help the Farm Liaison meet cost targets for each share type, and to facilitate broader cost reporting. On the moring of each pickup, the Farm Liaison will go back to the farmers contributing to that day’s shares and collect the food in quantities matching the Farm Report.
KaleChips also offers staff reports of various types. Some, like the list of possibly-duplicated people or orders, allow for checking likely errors by volunteers or shareholders. Some are used for managing the program overall, including supporting outreach efforts, such as the report of past shareholders with no future orders. And a few, like the “pseudo-demographic report”, offer an overview of the program’s overall state, for purposes of capacity planning and grant application.
Shareholders start on a landing page designed for them. Once logged in, it offers four functions.
By far the most common is the New Order functionality. From here, shareholders are taken through a linear flow to pick their stop, indicate whether they qualify for limited-income pricing, select share types for each remaining week, optionally add a donation, and pay their balance. All payments are handled by Stripe, which allows us to process credit cards without holding any credit card information ourselves, and (optionally) let shareholders store their payment information so they don’t have to enter it with each order.
KaleChips allows shareholders to view their existing orders. To facilitate City Fresh’s permissive ordering policy, if the orders are more than a week out shareholders can modify their pickup date. It is common for shareholders to order for a month or two out, then modify orders when they find they’ll be out of town on a given pickup week.
KaleChips also allows shareholders to view their past orders and change their account information.
The design of the Staff and Volunteer portions of the user interface are intentionally minimal. Most of it is designed to work well on a variety of devices down to phones, so volunteers can use whatever they have on hand, although larger reports like the Front Table Report can get unavoidably unwieldy. This also makes it easier to run stops over mediocre internet connections. Some of the volunteer reports, particularly the Front Table and Share Contents reports, were also designed to work printed to paper for offline stops. The shareholder portion of the interface also aims to be simple, but balances that against fitting in with the pre-chosen WordPress theme used for the non-KaleChips portion of the City Fresh web site.
The initial version of KaleChips was launched for City Fresh’s 2015 season, and shareholder functionality was launched in 2016. Development is ongoing, mostly in the form of new reports as requested and minor per-season updates. We’ve just completed a significant redesign of the process of creating each week’s shares. There is work planned for the near future to allow KaleChips to handle orders of “extras” (add-on items shareholders can purchase each week in addition to their shares) and wholesale orders for local businesses.
KaleChips is mostly written in Python 2 and relies heavily on the Django framework. It uses the PostgreSQL database. Various background tasks are written in a combination of python, rc, and C, and make heavy use of the plan9ports tools. Off-site backups are done using venti and related tools. It runs on a single virtual FreeBSD server provided by Digital Ocean. Shareholder payments are securely processed by Stripe.