This is a case in which I had to design our monetization of Eli Review out of a corner. When we monetized, we only sold one piece of merchandise and so that’s how we modeled our information architecture. This is the story of how I changed the system to support multiple price points and launched a new piece of merchandise – printed merchandise.
Background: monetizing Eli Review
When Eli Review was first launched as a commercial product, it had a single price point – one year (365 days) for $40 USD. That what we thought was a reasonable price for the service, and that per-year price could be adjusted as needed.
As we began selling, it became clear that most instructors weren’t interested in having students buy the product for a full year, and certainly not at that price point. It became clear pretty quickly that another price point would be needed, but the system was not built to accommodate multiple price points.
Additionally, another use case we did not expect was that some students depended on scholarship or financial aid money could only use that money in their college bookstores. We did not have any physical merchandise. Finding a way to get a product to bookstores to support these students became a high priority.
User Stories and Project Scope
Knowing that we needed to support more pricing options, I developed a set of user stories:
- As an instructor, I want my students to have options for how long they subscribe to Eli so they only need to pay for what they need.
- As a student, I only want to buy an Eli subscription for the length of my class so that I don’t have to pay more than necessary.
- As a student, I want to buy an Eli subscription at a bookstore using my scholarship or financial aid money so that I don’t have to pay out of pocket.
- As a bookstore manager, I want a piece of physical merchandise to sell to my customers when they buy Eli Review so that there’s something to return, if necessary.
With those stories in mind, I was able to develop a complete set of requirements for the changes needed. These designs would not only add the means to support a new price point but also allow for a long-needed UI updated to the app’s “Account Settings” feature.
- PayPal updates: PayPal, being our online payment vendor, needed to be updated not only to include new “merchandise” that would could sell, but also a naming and organizational scheme to control how that process happened.
- Database updates: I designed a new database table – paypal_inventory – to manage how the system stores info about the various PayPal options users can select from. This table also controls the UI and specifies to the app how many days a purchase is worth.
- UI updates for students: the “Account Settings” interface was updated to give students the option to choose from amongst the different price points available.
- Print cards designed: using the existing infrastructure for generating subscription codes for our publishing partner, I designed a physical card on which those codes could be printed, acquired an ISBN number, and found a vendor to produce these cards in bulk.
Before & After
Before: when Eli only supported a single price point, the process for purchasing a subscription was pretty straightforward – there was only one “buy” button to click. In addition to the limited options, it’s important to note how poorly this information is organized. The UI elements for redeeming a subscription code come between the elements for purchasing a code via PayPal, making the UI difficult to understand.
After: With the new changes implemented, users had the option to buy at different price points for different lengths of time. The UI also became much cleaner and better organized, reducing confusion about what options users have and how to go about different actions.
The new price point method was driven by a new database table, paypal_options that stored each of the different PayPal items we made available. This table populated the UI with each of the different options, including the cost, duration, and microcopy for each item. Saving the options in this way also made it much easier to add additional price points in the future.
The other outcome of this process was our new method for selling subscriptions to students via bookstores. We were able to utilize the existing subscription code infrastructure we used for providing codes to our publishing partner, but now we had a unique piece of merchandise of our own with a distinct ISBN that stores could use to order from us.
Outcomes / Takeaways
Taking these development steps paid off in a number of ways. Specifically:
- New price points – we’ve been able to add new price points very easily, including a new 3-month subscription option for $12.50 in 2018.
- Subscription card sales – printed access cards now represent 40% of our yearly sales..
Since rolling out these new updates, we’ve learned quite a bit that we’ll carry forward into future development work:
- Dependency on PayPal – PayPal has posed problems for us in the past, particularly when it fails to support students with international credit cards. We need to be able to incorporate multiple vendors and payment methods to best meet customer needs.
- Managing subscription batches – it’s easy enough for us to generate a batch of subscription codes to send to the printer, but we have no way to monitor those codes, to know who received them, or what percentage of codes at what institutions get redeemed. We need to be able to track where those batches go and how they’re used.
- Storing and managing physical cards is a pain – this is a significant factor in having analog merchandise that we did not anticipate. A batch of 1,000 printed cards occupies a lot of space, as do the supplies necessary to pack and ship them.