Sunday, 26 February 2012

With Reservations

I've been having trouble working out how I want to model "reservations".

Part of the problem is, I couldn't really see the use case for it. If what you deal with are paper tickets and you don't have a website and you can't take credit cards, then I can see why you'd want to let someone phone up and make a reservation, and then swing by when convenient and hand over the cash and get the pieces of cardboard. But what are reservations for in a web based system?

The trouble is, the only time reservations matter is if you're going to sell out. If you aren't selling out, then reserving seats doesn't do anything. Well, I suppose that it might mean you get to sit closer to the exact seat that you want, but if you didn't bother making a reservation, then you'd still be able to buy a seat somewhere.

If you do sell out, and someone has an unpaid reservation, then you're probably turning people away. People who have real money that they're prepared to give you now, but which you won't take, because you're promised the seats to someone else who may or may not get round to collecting the reservation.

In some ways, I can look at reservations as being firm orders, that are easy to "refund" (as you've never taken any real money). So I could treat "reserved" seats as being paid for on account, like seats for an agency. You buy the seats on account, and then at some point before the start of the show you either settle the account, or you cancel the tickets and let them go back on sale.

In other ways, reservations are a bit like a really long lived basket. You put a pair of tickets in your shopping basket, so that no one else can get at them, but instead of either checking out there or then, or the basket expiring after the standard 20 minutes, you let the reservations sit there... and then you let someone reconnect to that basket and complete the transaction later on.

Both options seem like a lot of hassle, and I can't see what's in it for the venue to allow it. It's never going to increase sales or revenue, you're just giving the public one more way to annoy you.

But recently, I found the use case that makes sense to me. And it's all about where the seats are, and not getting seats at all. Suppose you're going to the show with your friends: you want a ticket for yourself, you don't want to pay for their tickets, but you do want to be sure that you'll be sitting next to each other. Being able to complete a transaction for yourself, and at the same time reserve the seats for your friends. Or, if it's a GA performance that's selling fast, being able to get your tickets and be sure that your friends will get theirs. And this REALLY adds value when combined with social networking. If the automated post to the Facebook wall doesn't just say "I'm going to see $show" but "I'm going to see $show, the 4 seats next to me are reserved for 12 hours, click here and enter $code to purchase these tickets" strikes me as an acutally useful way of integrating with Facebook and adding more value than timeline spam.

Friday, 24 February 2012

Going live

The two things I worry most about in an implementation are:
1. Payment Systems
2. Data

There are lots of other things that need to be done - branding the site, writing reports, setting up the database, etc. - but those are all
* More directly under our control
* Capable of temporary stop-gap solutions (if the site design isn't perfect, you can choose to go live with it slightly ugly and have it fixed the next day).

Payment systems are troublesome because some banks and payment gateways require long testing periods before they will activate an account, and there's almost no pressure that one can bring to bear on them that will speed things up at all. Starting the process of getting a Merchant ID from scratch can be slow, and getting the set up correct for Card Present, Mail Order / Telephone Order (MOTO), and eCommerce, all of which have different requirements, can be complicated .

Data is a worry because once you have some sales on the new system, you can't just switch it off and fall back to the old system if anything goes wrong. If the new system knows that seat A15 has been sold and the old one doesn't, and you don't want to do a reverse data conversion from the new system to the old one (which, trust me, you don't), then you're committed.

But there are effectively three states of data in the system. It's all the same data - who bought what - but some of it is "Sales for performances well in advance", where what's important about it is that you don't sell the same seat twice, some of it is "Sales that people are going to collect today", where what's important is that you need to be able to swipe a credit card and retrieve and print an order, and some of it is "Historical Sales", that you are going to use for marketing.

Doing a full overnight conversion means that the next days staff will come into the venue and
* Have to sell advance tickets off a new system - and trust that advance availability is correct
* Have to retrieve and print tickets that were sold on the old system, off the new system
* If anything goes slightly amiss, which it will, deal with customer service and refunds and cancellations on the new system
* Have to deal with all of this in a totally new user interface

which is a lot to deal with no matter how much training there has been, and if a data problem comes to light, say, in the evening whilst tickets are being collected, it's too late to redo the conversion, because the database has that day's sales in it.

Therefore, to mitigate all these risks, I'd prefer to run the two systems side by side, with a cut off date of N months ahread such that performances after that cut off date are in the new system, performances before that date are in the old system. I have seen on many occasions dataconversions that cause an ongoing series of bugs that are never fully resolved, but which eventually "go away" simply because all of the converted performances have happened; it would have been better not to have tried at all.

Running the systems side by side is more effort for staff, because they'll have to switch between systems whilst selling tickets. It's more effort for reporting, because sales will be recorded in two separate systems. It's more effort in the intim period for online sales, because we'll need to show two sets of content on the website.  But I think it gives a better result at a lower risk.


First we pick a "cut over date". No more performance get put on sale in the old system that are after the cut over date.

And start talking to the bank about getting an internet merchant id, and talking to payment gateway providers. I will happily integrate with any payment provider, but so far the ones I've found friendliest to deal with are

And we start the process of branding and skinning the software so that it fits in with the existing site.

Then we set up the new system with all the performances after the cutover date and test and make sure everything's happy. If this takes longer than expected, the cutover date can be slipped and more performances put on sale in the old system.

Once the internet payment solution is sorted, and the site skinning and branding done, we start selling performances that are after the cutover date on the new system. This should still be about 2 months distant, as you'll have needed to do advance sales on the old system. Therefore, there's plenty of time to sort out any problems with delivery and reporting, as there won't be the emergency of "someone's bought a ticket for a show tomorrow and the email hasn't arrived help!"

During this period, the marketing function in the old system won't have access to sales data for tickets sold in the new system. I hope that's not a showstopper; we can do incremental conversions of historical data for marketing and run marketing off of the new system if we have to.

Eventually, we reach the cut over date. The audience for the first show sold on the new system arrive, present their tickets, and are admitted. The old system can be switched off. The final historical marketing data from the old system can be converted. The new system is entirely live, with no scary crunch conversions and plenty of room for maneuver.

Wednesday, 22 February 2012

Software as a Service

There are two ways to sell box office ticketing software: you charge a license fee, usually based on the number of users or something similar, and then charge an annual support fee on top of that, or you sell it as a service.

I'm selling mine as a service, because I've seen what happens over the lifecycle of a business that sells this sort of enterprise software based on license fees, and I don't believe it's in anyone's interests.

This is largely based on my experience at Artifax Software, but I experienced the tail-end of the same process at Galathea.

You start off getting your first few customers, selling your first few licenses. You get a nice pile of money in the bank, and you start to think, "Hey, this is going to work!". Once your sales pipeline gets moving, you feel like you've got enough of an income stream to start hiring staff.

So you've got a couple of programmers and a few support staff, and you're selling enough licenses to pay the wage bill at the end of the month. The trouble is, the more licenses you sell, the more support staff you're going to need to cover that number of customers. Now, your 15% annual support fee should in theory cover the increase in support staff you need, and the development costs associated with making the next version, but one day you blink, and before you know it you're using your license revenue to keep on paying your support and development staff.

At this point, it's clear that you've got to keep on making more sales in order to support the staffing levels you need to provide your customers with the service they expect. And the more sales you make, the more staff you need. And the more staff you have, the more sales you need.

It gets worse, because the accelerating need for new license sales means you have to start branching out into new markets. Which means more functionality: more developers, more complexity in the code, more bugs, more support staff. Now, every new sale means adding features to the product, not just using the intellectual property you have developed. But you make the sale on a promise of functionality because you need the money, and then you hope to catch up with the development before the next new customer comes along... adding more developers as needed.

What you get at the end of cycle is software that has been stretched to work in too many different markets. Revenue is drying up because you are literally running out of new customers to sell new licenses to. Your reputation for quality is going down because you have half finished functionality left right and centre, and your reputation for support is going down because the software is now hugely complex and you can't pay the support staff you need on the support revenues you're getting.

When I was at Galathea, my 5 biggest problems were a racecourse, a football club, a stadium, a theatre group, and an cultural institution. They all sell tickets, but they all care about totally different things, and none of those things worked properly because they'd all been done in a rush. The racecourse cared about fraud, touts, and access control. The football club cared about season ticket renewals. The theatre group cared about selling huge volumes of seated tickets at a steady rate. The stadium cared about selling huge volumes of general admission tickets in 30 minutes flat. And the cultural institution cared about memberships and the way that membership perks interacted with every other aspect of the system.

Software as a Service may look more expensive in the long run: if you add up all those per ticket fees over 5 years, it might be less that some up-front-licenses, support fees, and a couple of servers. But the SaaS business model means that your supplier isn't going to be panicked into making unwise sales  and rushed development, and it means they're going to care as much about keeping you on board in 5 years time as they are the day you sign on the bottom line. Which is what everyone wants.

Thursday, 2 February 2012

The Restoration Levy

Copy & pasted from Facebook:

Why does every theatre now try and guilt trip me into giving over an extra £3 donation every time I buy a ticket? I do support theatre, THAT'S WHY I'M BUYING A FUCKING TICKET.
  •  likes this.
    • Ben Curthoys Because the ticket price, or a cut of it, goes to the promoter. The deal is based on the "face value" of the ticket. The venue adds on a donation or a restoration levy on top of the face value because that way they get to keep it all, and spend it on maintaining and upgrading the building.
      about a minute ago · 
    • Ben Curthoys I agree that it's a stupid way to do business, and the price advertised really ought to be what you pay and include the cost of sale (the booking fee) and the overhead of running the building (the restoration levy), but that's the answer to your question.