Boo.com Goes Bust

The original address for this post is Boo.com Goes Bust. If you're reading it on another site, please stop by and visit.

As many of you may have heard already, Boo, the company for which I used to work, has closed its doors.

I’ve been looking at the press coverage and it seems that some of the coverage does not work out. For starters, Boo.com’s failure is not an example of why B2C E-commerce will fail, it’s an example of why Boo failed itself. Nor is it a failure of E-commerce in Europe.

Now that the company is buried, I’d like to take a look at what went right and what went wrong with the company and go into more details as to what we should learn from that failure. I will try to summarize what I learned over the 6 months I spent there but I may be off a little here and there since it’s been a while since I’ve left the company.

Boo was the first company to launch from the ground up in multiple countries from day one. This represented a set of challenges that were previously unadressed, ranging from technology challenges to more traditional issues in generating a global brand. While I was working for Boo, I was in charge of developing the back-end fulfillment system, a platform that allowed us to handle multiple currencies, multiple languages, on the fly tax calculation, and integration with multiple fulfillment partners. Let me go into more details on what this means.

Multiple currencies

If you want to trade globally, you can’t only offer US dollars. As a result, you need to figure out a way to handle multiple currencies ranging from dollars to pounds to liras to francs, to deutshmarks, to kroners, etc… If you are planning on doing this well, you have to peg your prices to a particular value. However, you have to realize that prices are not the same in every country and what may seem expensive in the US can be seen as cheap in other countries. This is where you have to make a decision as to whether you want to set a fixed price in the local currency or set a more dynamic price that is affected by currency exchanges and other fluctuations. It’s a fascinating problem in and of itself but it’s one that we discovered to be a big pain to deal with.

In the end, Boo built a system which allowed us to set a different price for each country or set a single price for all countries and have that price be translated in the proper currency based on a set exchange rate. It was a bit of a kludge but it worked and, to this day, I haven’t seen an Ecommerce shop with a similar system.

LESSON:

When dealing across multiple countries, decide early on how you want to set up your pricing scheme, it will save you headaches down the road.

Multiple languages

First of all, forget translation software packages. They are still relatively immature and there is (at this point anyway) little hope that they will mature much beyond their current point in the near future. If you’ve taken any linguistics course, you know that grammatical rules can hardly be standardized for several languages. For example, something as simple as a verb can become a whole new set of problems. In English, there is a relatively small set of basic rules. The verb “to want” breaks down into “I want, you want, he wants, we want, you want, they want”. Notice that there are only two basic variations here. In French, the same verb “vouloir” breaks down as follows: “Je veux, tu veux, il veut, nous voulons, vous voulez, ils veulent.” In this case, there are 5 different variations. In spanish, it’s six… and so on. Take that problem and try to automate it and you are building a system that is bound to fail. The way we worked around it at Boo was to create a system where the copy was translated by hand by people who were fluent in the language.

Unfortunately, another problem cropped up: British English and American English are EXTREMELY different. Considering that the assumption was that one version of each language was sufficient, problems cropped up and some of the perfectly normal British english stuff ended up being very offensive in the US. THAT was a major problem.

LESSON:

One language per country can be a dangerous road, check with the locals before making anything available to the general public.

On the fly tax calculation

This one almost killed me. In the US, it’s relatively easy to deal with taxation. For the most part, the only taxes you have to pay are for states in which you have a physical presence. Where it gets tricky is when your servers are located in one area and your offices are in another. Technically, that is two locations.

In the case of Boo, it got worse. For example, a sale to France was taxed three ways. Why? Quite simply because the company had offices in Paris, its servers were located in London, UK and its distribution center was in Cologne, Germany. However, the interesting part of the problem was that we were making a sale but not delivering a good in the UK, delivering a good but not making a sale in Germany, and making a sale and delivering a good in France. This was just one example. Multiply that by the number of countries the company was doing business in and it soon got VERY complicated. Add to that the fact that certain goods were coming from China or Taiwan and the picture got so clouded that we had to bring in tax attorneys to help us on the details.

LESSON:

Hard to believe, but accountants and tax attorneys should be part of your development cycle if you are developing global Ecommerce apps.

Integration with multiple fulfillment partners

The main issue here was dealing with different file formats for DeutschePost (the European fulfillment company) and UPS (the company that did fulfillment for the US). What we ended up doing was create an EDI link to those guys (DeutschePost was not web-enabled yet) and create a set of filters for each of them. A simple answer to a simple problem but this little answer cost about 150 man months of work as the content had to be migrated from the old (untagged) setup to the new one. Because the original database was originally set up wrong, we had to totally reorganize the schema and refit the content into it.

LESSON:

Plan early, think of all that can go wrong, and then plan it again. Usually, spending more time on specs saves you from many headaches down the road.

Returns

One of the biggest challenge to the company was the ability to handle returns in a cost efficient way. We had set out to offer free returns to any customers as a major differentiator. Since no one else in the industry was doing so, we saw this breakthrough as something that would clearly separate us from the fold. The challenge was that we were charged by our integration partners so such returns were actually pulling money out of the company’s pocket. Considered a necessary loss leader, we didn’t worry much about it… until we started getting flooded with returns. Fashion is this weird use case where people may want to try on a few different sizes so it became customary for customers to get two or three sizes of a particular SKU and return the ones that didn’t fit. We ended up being deluged with return and hadn’t worked out the details at scale. Returns hadn’t been a huge area of focus pre-launch but became the focus of our days afterwards.

Where’s the plan?

When I joined the company in August, the launch was behind schedule by three months and we had ten weeks to the Christmas season. The first thing I asked to see what the project plan. It didn’t exist. People were working on bits and pieces of the project without communicating with other people they were affecting. Within a week, we put together a MS-project chart and things started to move properly.

LESSON:

An e-commerce project without a development plan will always be “this close” to launch but will never launch.

Front end is technology

One of the biggest failures at Boo was to assume that the front end was not a technology issue. Up through launch and beyond, the front end team was first reporting to business development and then to marketing. This was a capital mistake that I kept fighting over. A web site front-end is interface design, it’s not a marketing exercise. It should include people who are versed in this and not just people who know about pretty colors. Ultimately, I think this was one of the big failure factor in the company.

LESSON:

No matter how good your backend systems are, the users will only remember your front end. Fail there and you will fail, period.

There are many other reasons for which Boo failed (I’d rather not go into them but I can say that the press is on the mark on a lot of their accusations) but ultimately, there were a lot of really smart and really good people there who worked very hard to put together what, to my mind, was an amazing back-end operation. Lack of communications to and from the top was definitely a problem as well as a lack of understanding of Internet time (the redesign of the site I heard about on the day after launch has not yet happened and probably never will now). In the end, though, Boo’s failure was not that unexpected to anyone who had worked for or with the company. Boo.com did not fail as an Ecommerce company, it failed as a company, period. The thing that took it down were not Ecommerce related as much as they were just plain business. Yes, I’m a bit saddened by the fact the company went downhill but I already knew this was going to be the outcome back in January when I left.

Ultimately, Boo is a typical example of a lesson that many VCs are pushing these days: Management makes or break a company.

Let’s hope we all take that lesson, remember it, and let Boo stand as old mistakes we will never make either again (for those of us who made them) or at all (for those who haven’t).

Tristan Louis, a serial entrepreneur most often found at tnl.net, where this was initially posted under the title Boo.com Goes Bust. You can follow Tristan on Twitter at @TNLNYC