Price Points and Bookstore Cards

Developing an analog (print!) delivery system for Eli Review subscription codes and the infrastructure to support them.

Client/Project: Eli Review
Timeline: July 2015
Objectives: Add multiple purchase options for students and create physical merchandise to sell in bookstores
Team:
  • Shekhar Patil, Developer, Venturit
  • Mike McLeod, Project Manager, Eli Review
My Role: Information architecture, user interface design, database design, graphic design
Categories: , , , , ,

Overview

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.

The earliest prototype of the commercial version of Eli didn't even have a way to pay for a subscription.

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.
Requirements for how the system will handle multiple price points

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.

What Changed

  • 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

Eli Review's account settings circa 2015, when only 1 price point was available - and there was a striped background, eesh.

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.

The Account Settings UI with the new subscription options available as prominent buttons, along with a cleaner organization of elements.

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 database schema for the new paypal_options table.

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 first batch of our new bookstore subscription cards.

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.