I’m sharing my startup stories while building out my latest project – Calenzen – which seamlessly reformats meetings in your calendar so you can always instantly click to dial. No special apps, calendar programs, or software is ever needed. Learn more about Calenzen.
The Problem
Halfway though my first year of graduate school, I finally became fed up with textbook prices. Complaining about pricing is nothing new in this space. To make matters worse, the campus bookstore would often be sold out, something I’d learn only after taking time off work to trek across town.
With my frustration came the solution: International Student Edition (ISE) textbooks bought online and delivered to my doorstep. Same content, easier shopping, lighter weight (softcover vs. hard), and usually half price!
This was a very fractured marketplace at the time and it was ripe for disruption. Or more accurately – actually creating a consistent and trustworthy market. Books were available from every site that supported individual sellers at the time, like eBay, Amazon marketplace, and shopping aggregator sites like Google’s Froogle.
Finding just the right book was doable. When I was a customer trust was my biggest issue. Would the book I’m ordering arrive in time? Would it be the exact edition I requested (pictures were often wrong or even nonexistent)?
Haven’t I Already Done This Before?
I was already familiar with the textbook space. When I was undergrad, I created a service called Carlbooks (named after the college) to facilitate peer-to-peer textbook sales between semesters. Revenue came from banner advertisements and referral sales commissions from Amazon and Barnes and Noble.
My innovation was to add the trust factor into the equation. I ran a screen scraper that pulled the list of all classes and their books into a single searchable view for buyers visiting the site. Listing your book to sell based off the ISBN number was even easier.
I built a number of screen scrapers against Amazon, Barnes and Noble, and Varsity Books. With that data I was able to append additional information about the books, including cover photos, editions, and dates, all into the listing.
The small campus bookstore was none too happy with the competition, but within two years they had duplicated the effort for their own marketplace.
The Solution
I found a merchant in Malaysia who had a massive inventory of International Student Edition textbooks and was able to ship them via UPS two-day air for an excellent price. Unfortunately, his web site just wasn’t navigable to English speakers or anyone looking for a one-off purchase.
The solution can be easily split into two primary categories – front end and back end. Implementation for both was non-trivial, but required for a scalable enterprise. On our peak sale days, before the start of Fall and Spring semesters, we would process well over a hundred transactions per day.
Front End Technology Solution
The marketplace was fragmented, so success required a consistent and frictionless experience.
I made liberal use of all the data I was able to acquire about these books from their ISBN numbers, such as official title, edition, publication date, summary, and photos. What better way to start establishing trust with potential customers than by given them tons of information about the book they were looking at?
All books were posted on my e-commerce site. Of course, no one knew where or how to find my site – but in the time of new product aggregators, this wasn’t a problem at all.
Froogle, by Google, was the best known product aggregator at the time. As a site owner you could format a special file with your inventory for them to scan or even create a near real-time data feed. Either way, Froogle wanted nothing more than to make the textbooks as discoverable as possible.
Comparing my site with all other sites selling textbooks, it appeared I had different customer acquisition strategy. While others depended on direct traffic or perhaps organic traffic to their main page, my site had no brand nor expectation of repeat business. Therefore I focussed on showing books that matched buyer intent. All relevant Google searches highlighted matching product listings and there were almost no competing links.
Given the high buyer intent for all inbound clicks, our conversion rate was an astounding 65%. It was predictable enough to fund even the low-cost PPC ads during the 2005 time frame when this site was active. Given the prominent placement from Froogle, there was no need to even consider that.
Froogle eventually disappeared as a separate entity and current Google mechanisms for product data feeds aren’t as accessible as they once were. Thankfully these changes occurred long after this venture wrapped up.
I tried other outlets as well, including a few listings of the more popular titles on eBay. Sales followed the long tail model more than anything, which made it difficult to achieve critical sales thresholds on a listing site like eBay. In the end these markets were too soft and didn’t have the volume needed to support the automated processes I built in the backend.
Back End Technology Solution
The heart of the whole operation was the backend automation, without which the effort just couldn’t have scaled. This was a cyclic business with traffic at the start of the Fall and Spring semesters accounting for 80% of all yearly sales – all in just a one or two week period. During these biannual sales spikes, I easily managed product ordering, tracking, customer communication, and payment collection through completely automated systems.
As this was before the advent of more accessible SaaS offerings designed to be easily wired together, all this activity was built and maintained in-house. From start to finish, here were the major steps in the automated workflow.
1 – Inventory management
My distributor partner maintained a web site with cryptic and ill-defined product listings. I regularly pulled a current inventory listing from an XML source he maintained and used that to update the inventory products and quantities in my system of record.
2 – Data cleansing and appending
The only trustworthy data from that inventory feed were the product keys, which in the case of books are ISBN numbers. Given these numbers I was able to extract pictures, titles, descriptions, and pricing information from Amazon and a few other large e-commerce sites.
I had a few algorithms in place for automated pricing that factored in:
- Cost of new and used hardcover (non-International Student Editions) books from Amazon and a few other major e-commerce sites
- My cost to purchase the book, ship it, and cover payment card transaction fees
- A minimum 30% margin
- Listing price at least $40 (and often much more) below the lowest offered elsewhere
3 – Sharing product data feed
I generated my own product data feed, with more verbose output, for consumption by Froogle. Google prioritized then, just as it does now, wordier content with rich details. In the early days of product aggregators there was no pay for placement, therefore these listings were easily highlighted based on merit alone.
4 – Order placement
The goal was zero friction to place an order, therefore I broke with the entire concept of “create an account to make a new order” that was all too prevalent at the time. After all, what are the chances that someone would organically re-discover this same site during a subsequent textbook purchase?
When the order was placed I’d issue an auth against the buyer’s credit card. I never charged prior to shipping the book which decreased risk from chargebacks should there be any shipping delays. This also helped reduce payment card fees should the order fail to ship for any reason.
5 – Distributor order placement
New customer orders needed to be placed with my upstream distributor for direct shipping. This phase was one of the most complicated and aside from my front-end discovery solution, was most of the value I offered in the transaction.
The distributor’s ordering web site was a maze of inconsistent web pages, likely meant for navigation exclusively by an oracle. With sufficient screen scraping, I was able to complete the shopping card process for each order where I would select the product and submit the shipping details.
Payment was required at this time and could only be submitted via PayPal. A host of additional automation was required to complete this off-site portion of the transaction.
6 – Distributor shipping
Shipping times varied, ranging from hours to, on a few occasions, weeks. Excusing the extremes, a typical order would ship within two days. My tooling regularly polled the status of all orders to determine when they actually shipped.
Upon order shipment two things happened. First, I’d send a delivery confirmation and tracking email directly to the customer. After that, I’d capture the customer’s payment. The payment side is where this entire enterprise became tricky during the peak seasons.
The money flow worked something like this:
- New order – customer card auth. This is just a reservation for payment and more than anything else, it makes sure the customer card has sufficient credit for the charge.
- New distributor order – via PayPal instant transfer. However, I’d need to refill the funds in my PayPal account in advance which required at least a three business day bank transfer.
- Order shipment – capture customer payment. Customer payments would settle from their bank to my merchant account and be available for withdrawal after seven days.
The delays transferring money into the PayPal account, delays from shipping product, and finally the delays settling customer payment back into my account were incredibly challenging. During peak periods, I would regularly cover close $40k to $50k “stuck in the ether” while everything was in motion.
7 – Customer delivery
All orders were shipped via air and trackable so I knew as soon as delivery was successfully completed. If the delivery address was wrong or the package couldn’t be delivered, then this whole automated system would fall apart.
In those scenarios, I’d typically have the problem package redirected back to my office where it would sit in local inventory and become a near-guaranteed loss. As much as I loved all the back-end automation, there was no good way to insert an exception and ship out one of the few returns that were sitting around.
My loss on one of these sales gone wrong was too high. Paying for product from the distributor, shipping, and transaction fees for both the sale and the refund made me uncomfortable when there were so many sales in flight.
The Last Days
Our collaboration lasted over two years and only wound down as his inventory began to dry up. Unfortunately, I learned of inventory unavailability only when the distributor cancelled open orders that couldn’t be fulfilled. The money tied up on non-processable orders as well as the justifiably upset customers left me wanting to continue in the e-commerce space but to reduce the two areas I just couldn’t control with this partnership: high cost of goods sold and low control over executing on customer orders.
Lessons Learned
The first lesson is that automating everything is the only way to scale, although that may have been a self-fulfilling requirement given my background in tech rather than anything in the retail space.
Too much of the overall success was being in the right place at the right time and executing on the opportunity. Starting several years earlier would have meant failure due to customer acquisition costs – shopping aggregators like Froogle leveled the playing field.
Starting several years later would have also been fatal as the aggregators gave way to pay-to-play solutions. The marketplace became divided again, but this time between highly fractured services like eBay that allow strong seller control and focussed marketplaces like Amazon that limited seller flexibility.
Looking to improve prior to the next effort, there were those two things outside my control that I wanted to address. First, the cost of goods sold was too high. With average margins hovering at 30%, failure during a single sale could take three or four successful sales just to break even. With lower cost products, my ability to replace mis-delivered items or eat the loss from a customer complaint improved my options for increased customer satisfaction.
The second item to improve upon is gaining better control over all logistics surrounding the sales process. True, the automation gave better visibility to the process and allowed everyone to react to changes more quickly. The problem is that I was doing just that – reacting. With more distribution control, I could be confident of inventory counts, be able to stock up in advance of peak periods, and staff up as needed to deliver all queued orders.
As my textbook sales wound down, my next effort improved on both these goals.
