Tuesday, 10 July 2018

Premium

In response to: http://davewakeman.com/2018/07/the-problem-with-premium-seating-pricing-etc/

Most of the time, my response to someone trying to up-sell me the "premium" version is:




Everyone wants to be a premium brand, because they've heard that brands are valuable, and they don't really understand how that works so it looks like it's a way of getting free money, and they try to position themselves as "premium" and are baffled when no one cares. Almost all the time, "ordinary powder" is good enough.

Maybe I'm unusual, but what I put a premium on is my time and my convenience - not your advertising spend and your brand positioning. Dave mentions the infamous $16 beer and so here's a little experiment I'd like to propose:

Instead of having a bar that charges $12 for Bud (seriously what the actual fuck?) and $16 for a premium Blue Point Toasted Lager, have a bar that is very clearly split into two, with servers working either one half or the other. On one half of the bar, you sell all your beer for $12, and you have a big signpost to that effect. On the other half, you sell the SAME EXACT BEER for $16, and you have a big sign up saying that, too. (If you're talking about $12 or $16 per can the costs of the actual beer is obviously such a tiny proportion of the amount the buyer pays it's frankly irrelevant whether the beers have slightly different cost prices).

Obviously, people will buy beer from the $12 half. The staff working the $16 half will have very little to do. But at some point, the $12 half is going to get really crowded. There's going to be a long queue. And then someone's going to say "It's worth $4 to me to get my beer NOW and not have to wait for 20 minutes. I want to get back to my seat!". And some people are going to self select to the expensive half, because they're happy to pay the premium to not have to wait.

Now, I like beer, and these numbers seem mental to me. There's no way that any can of beer ever would be worth $16 to me, and I'd rather drink a bottle of piss than a Budweiser. But paying an amount that is massively over the odds to get the beer that isn't horrible would stick in my throat. I wouldn't enjoy it, and I would have a lot of negative feelings towards the people who organised the event. If you give me a choice between $12 piss or $16 drinkable beer, then I will resent you. Whereas if my choice is $12 beer with a queue, or $16 beer without a queue, then I'll think about it. Some times I'll queue, and sometimes I'll value my time more, and if I choose to pay $16 then that's my business and I don't hate you for it any more.



So, tickets. What's this got to do with tickets?

We're all familiar with seating plans with multiple price bands, and in no way am I suggesting that that is a bad idea.

The mistake is to think that "having better sight lines" is the premium for which people are paying. I would suggest that the real value of the premium seat is that they're still available when all the other seats are sold out. There's less competition for them. They're likely to be less crowded. And most importantly - and this is purest snobbery and I'm not saying I agree with it, I just don't think it serves anyone to ignore it - the biggest premium is not having to sit next to a poor person. If you're in the most expensive seats in the house, the chances of having a teenager eating popcorn and physically incapable of turning off their phone as your next door neighbour are much lower.

Those premium benefits - real benefits that people are happy to pay for - are not because the seats are better. They're because the seats are more expensive. They're not in spite of the differential pricing: they are because of the differential pricing. If you have any customers you think are rich enough to value these benefits, you should probably take some of your existing seats and call them "premium". If they don't sell, put them back to normal, and if they do, it's free money.

Monday, 2 July 2018

Creating a culture of innovation

Incentives matter.


I'm not sure how this isn't obvious to everyone already, but one bumps into enough organisations that have got their incentives wrong that I guess it can't be.

Here's a random link that I just googled: Lesson 3: Incentives matter which is presumably from Econ101 somewhere. For now let's just note: "Incentives can be monetary or non-monetary". This applies to staff and to customers equally.

Suppose you want your customers to book tickets online, because it's cheaper for you that way. Don't, whatever you do, apply a booking fee that makes online purchases more expensive than telephone ones. Even if it's also more convenient for your customers, even if they would be prepared to pay for that convenience, don't send them the message "If you want to save money please do the thing that annoys me". Don't make them jump through hoops in some horrible checkout process that's more effort than speaking to a person. Don't make them answer onerous marketing questions online that they can avoid by picking up the phone.

Suppose you want customers to book in advance, so that you get your money earlier and they don't decide they can't be bothered at the last minute. Don't, whatever you do, apply any kind of booking fee or discount structure that means that the cheapest way to buy tickets is on the door, on the night. Don't make booking in advance - the thing you want them to do - more difficult or more irritating or more expensive.

Don't set up multi-buy offers that mean that if the customer splits their purchase into two separate transactions they save money. I keep having to stop people from doing this! I think it points to the problem: it's easy to think "I want to set up a offer to encourage people to book" and it's easy to think "Hang on, I don't want to give too much away, let's just limit it to at most 4 tickets (implicitly: per order)", and somehow it's hard to notice that someone booking 8 tickets is incentivised to book them in two lots of 4, which makes it cheaper for them (discounts on all the tickets) and more expensive for you (some of your transaction processing costs are per transaction, not per ticket). People just don't look for or think about unintended consequences of otherwise sensible seeming ideas. Perhaps I notice them because I've trained my brain to look for them over 20 years of writing code: most bugs that aren't simple mistakes are unintended consequences.

In short: don't punish people for doing what you want them to do, or reward them for doing what you don't want them to do. Debug your incentives.

So.

Suppose you want your staff to come up with new ideas. Ideas that you yourself in your fancy c-suite or your plush managers office can't have, because you're too removed from the daily grind to know where the inefficiencies are.

Then you need to get the incentives right, and in this case it's mostly about the non-monetary incentives. Actually, it's mostly about the non-monetary disincentives for someone to speak up with a new idea. If saying "hey, what if we do things differently?" gets someone punished by a manager yelling at them and calling them stupid, they're not going to do it, are they? If saying "hey, if we did this, we'd waste less paper" gets a response "true, but we can't because that's the procedure and i'm not authorised to think and head office wouldn't like it", then people will eventually give up having ideas.

You can't create innovation. All you need to do is stop suppressing it.
  • Don't make them have to fight to get you to listen.
  • If it isn't actually a good idea, don't punish them for having it, and don't punish them for suggesting it - by mocking or shouting or any other negative communication. Just gently explain why you think it's not a good idea.
  • Don't start by assuming that it won't work. Chesterton's fence is a useful heuristic, but sometimes the reason for the absence of a fence that would have been useful really is simply that no one had thought of it yet.
  • Whilst explaining why it won't work, see if instead of saying "that won't work because of X and Y and Z and all my years of experience", you can say "in order to make that work we'd have to solve these problems - X and Y and Z", and then you can talk about whether those problems are worth solving and if so how you would approach them.
  • If it really is a good idea, don't punish them for suggesting it by stealing it and claiming it as your own. 
  • Try it out. If it works, give them the credit. If it doesn't work, you take the blame. If that doesn't seem fair to you, then you are the wrong person to have a job that includes "creating a culture of innovation" as part of its description.
  • Don't hire insecure managers whose lack of confidence in their own abilities leads them to attempt to defend their own positions by suppressing the creativity of their subordinates.
  • Don't make it a zero sum game. If something nice happens to someone because they've had a good idea, don't take that out of any communal pot.
  • Don't insist on consistency and procedures in any areas where they are not important. If everyone is allowed to do things their own way, then someone's going to find the best way of doing it. Then they can share that. You can't share best practice if you can't find it because all practice is required to be identical.
  • If your lack of consistency and procedures occasionally causes problems, forgive them. You can either have a perfect process run by automata that never creates any innovation, or you can have process run by flawed people doing their best, and sometimes they'll drop the ball, and sometimes they'll spot something that a pre-defined process would never have done that saves the day.

Here's John Ruskin putting it a different way in Chapter 6 (The Nature of Gothic) of "The Stones of Venice":

"And observe, you are put to stern choice in this matter. You must either made a tool of the creature, or a man of him. You cannot make both. Men were not intended to work with the accuracy of tools, to be precise and perfect in all their actions. If you will have that precision out of them, and make their fingers measure degrees like cog-wheels, and their arms strike curves like compasses, you must unhumanize them. All the energy of their spirits must be given to make cogs and compasses of themselves. All their attention and strength must go to the accomplishment of the mean act. The eye of the soul must be bent upon the finger-point, and the soul’s force must fill all the invisible nerves that guide it, ten hours a day, that it may not err from its steely precision, and so soul and sight be worn away, and the whole human being be lost at last—a heap of sawdust, so far as its intellectual work in this world is concerned; saved only by its Heart, which cannot go into the form of cogs and compasses, but expands, after the ten hours are over, into fireside humanity. On the other hand, if you will make a man of the working creature, you cannot make a tool. Let him but begin to imagine, to think, to try to do anything worth doing; and the engine-turned precision is lost at once. Out come all his roughness, all his dullness, all his incapability; shame upon shame, failure upon failure, pause after pause: but out comes the whole majesty of him also; and we know the height of it only, when we see the clouds settling upon him. And, whether the clouds be bright or dark, there will be transfiguration behind and within them."


Friday, 29 June 2018

Reading Reports: An analogy

I was trying to think of the right analogy for what finding and seeing patterns in data is like, and I think the closest I'm going to get is this:


The objects making up the logo are there all along, hanging in seemingly disconnected places in the air. But as the camera's point of view moves through the scene, suddenly we look at them from the right point of view, and then the 4 is clearly visible.

That's what finding something in the data is like: it's always there, but you need to be standing in the right place, thinking of the right questions, to see it.


(
Obviously there are more forced pespective sculptures in the world than just the Channel 4 logo, but that was the one that came most readily to mind. Here's one:

 
(

Wednesday, 27 June 2018

Reading Reports

One of the challenges we're working on at the moment is helping people read reports.

The funny thing is, writing reports is easy. (Easy, if your SQL and XSLT are up to scratch, but they aren't very hard skills to learn). When we started out, the system shipped with hardly any reports, and I said to people "I've got few reports here, but if there's a report that you need that we don't have, we'll write it for you. Writing reports is easy". So now, we have loads of reports. And it turns out that reading reports is hard.

Even reading report names is hard. Because we now have loads of reports, and because it's hard to describe what they do and how they work in a single sentence, our most common report related support question is "Which report contains the information I want?". Right now someone's going over all of them with a view to rationalising them and improving the clarity of the description. I don't know what the answer is going to be but I expect it will look like more tags and more filtering options.

The reason why it's hard to find the report you want is that there are lots of ways a report can do its calculations.

Suppose you sell a ticket on the 1st of the month for show A, and then you exchange it for a ticket for show B a week later.

Some reports are based on the transaction log, so if you ask for the sales for show A broken down by day for that month, you see a positive entry on the 1st, and a negative entry on the 8th. If you ran the report just for the first week of the month, you wouldn't know that anything had been cancelled at all. Reports based on these transaction logs are useful for payment reconciliations: if you're trying to reconcile what was in the bank at the end of the 1st with what the database says you've sold, then you absolutely need to know about that sale: from the point of view of the bank statement at the end of the day, the cancellation hasn't happened yet.

Some reports are based on the current status of the orders / tickets. If you run a report saying "how many seats have been sold for show A as of now" and then you cancel an order and then you run the report again, the cancelled order no longer shows up. We don't care that it had been sold in the past and then cancelled, we just want to know whether or not it is sold right now. And even these reports can be broken down by day: "of the tickets that are currently sold for this show, how many were sold per day over the last month" is a valid question. If you ran a report like that on our scenario above, the tickets that were sold and then cancelled wouldn't show up at all - even if you filtered the report down to "the first 7 days of the month".  Reports based on the current state of orders are useful for sales analysis and promoter returns: if you want to know whether an advert you bought on the 2nd performed well and you're looking at sales you made on the 3rd, you definitely want to ignore any sales that were made on the 3rd and subsequently cancelled: those don't count towards your ad performance.

So the second most common question is "Why do these two reports on the same date range return different numbers?". And the answer to that is usually this difference in the basis for calculation: both methods are "right" in different contexts, but they'll give you slightly different answers.

If it's not that, then it's either "One figure includes booking fees and transaction fees and delivery fees" (useful for payment reconciliation) and "One figure is just the ticket value net of fees" (useful for communicating with promoters: the fees you charge are none of their business), or sometimes even "One report's date range is filtering by performance date and the other is filtering by order date".

Given that people consuming reports don't much want to understand how they work, and that reports can work in different ways that it's hard to express without a couple of paragraphs of text, that makes reading reports hard.

What people say they want is "a sheet with all the data so that I can see the various combinations for myself". But although such reports exist, they're not much use. The raw data is just a list of ticket amounts with transaction dates - plus an awful lot of parameters that they have to be grouped by in order to mean anything much: show or performance or genre or order date or performance date or sales channel or ledger code... The best reports answer a specific question: generic lists of numbers to allow someone to figure it out themselves don't get used much. You can reconstruct a sales movement report over a month by giving someone the job of running the "payment reconciliation today" report every day of the month and coping the figures into a spreadsheet (I've seen it done in venues converting from another system to Monad), but really, your sales movement by day is one thing and your payment reconciliation another.

Because good reports can only answer one question at a time, if you're looking for strategic information on what you're doing well and what you could be doing better, don't go looking in your day-to-day operational reports. Your front of house report is designed to give the FOH manager everything they need to get the audience in and the show open: it will be hard work spotting long term sales trends in it. Your payment reconciliation reports are designed to make sure the numbers we calculate for sales today align with the numbers in the bank account - broken down by transaction date and payment type, but not by show or genre. Your promoter sales returns show the final destination of the show's sales performance, but not the route it took to get there.

Reading reports with an eye to identifying challenges and opportunities means reading reports to identify patterns, and those patterns won't be visible if you aren't asking the right questions. You might be interested in how far in advance of a show people book, and a report like "Chart: Advance Booking Trends" with parameters "All Films" / "Performance in the last week"


(scale obscured because this is from real data)

might make you think that most of your cinema sales are on the door and you shouldn't worry too much about advance booking... but drilling down into just a single PG rated film shows a different story:



People who've promised their children that they're going to see a film behave differently from the general public - who knew?! I didn't, until I looked.

And a music event tells a very different story:

With people either sure they're going well in advance (dedicated fans - but not enough to sell out) and people deciding on the night, but almost no sales in between.

Your ticketing system will be collecting an enormous amount of data for you, and that data is there to be analysed, but in order to do that you have to start with a question. You can't just stare at reports hoping that the answer will leap out at you like magic lawyer speed reading a telephone directory in a movie.

Let's suppose we want to sell more tickets, because who doesn't? Well, to sell more tickets, we need to know why people buy tickets, and what stops people from buying tickets. Making people want to buy tickets is someone else's job (and, the show has to be good), but it's easy to want to go to a show and not buy a ticket. There are loads of plays and films and gigs I want to see that I don't buy tickets for. So let's look at what stops people buying tickets. Is it money? Then let's look at sales by day of the month. If most people get paid at the start of the month we might expect to see on average more orders on the 5th than on the 25th. Is it the time it takes to make the booking? Then let's look at sales by time of day, and if people are too busy to research and book tickets at work we might see a spike at 7pm when they get home. Is our box office open to help with these calls, or do most staff go home at the same time as our customers do? Is it that they're too sober? Let's look as see if there's a spike at 11pm when the pubs kick out. Is it the time that it takes to attend the performance? Then let's get some hard numbers on how much Saturday tickets out sell Wednesday tickets, and use that to inform how much more we charge for a ticket on the weekend or during half term.

I don't even work at a venue, and there's a bunch of questions right there that I find interesting and that I wish that my customers asked more often. We don't currently have reports that break down sales by time of day or day of week, because literally no one has ever asked, but that's exactly the kind of report I would be delighted to write if I thought it would ever get used.

Friday, 17 November 2017

Things I hate it when people ask for them (2): A discount on the first 50 tickets sold

Now, we can do this. We can set up a package that applies the discount, and make the package use a promo code, and we use the special promo code "AUTOMATIC" which is always applied to the basket without someone needing to type it in, and then make the promo code so that it can only be activated 50 times and after that it stops working.

I just think that we shouldn't because it is basically a terrible idea. It leads to all sorts of weird behaviour when you get near the limit and it doesn't effectively motivate people to buy more tickets. 

Suppose 49 tickets have been sold, and I add 2 to my basket. One is at the full price, and one at the discount price. This looks odd and you get a call in the box office and you have to explain to me why the prices are weird.
Then someone else add a ticket to their basket. They see it at full price.
I decide I can't be bothered and remove the tickets from my basket. They look at their basket. Suddenly their ticket has gone down in price!

For general admission shows it's much clearer to have two separate products on sale: "Cheap tickets (Only 50 Available!)" and "Normal Tickets". When the Cheap Ticket have sold out it's clear that someone should manually add a normal ticket to their basket.

For allocated seating it makes more sense to use price bands. The cheap seats should be the bad seats at the back. Someone who will only go if they get the discount can do so, and they can sit at the back of the stalls, and someone who wants the front row can pay extra for it even if they're first in the queue.

If you want an early bird discount, make it time based, not quantity based. If someone sees an offer advertised and it expires tomorrow, it provokes them to buy today. If they see an offer advertised and it says "First 50 tickets cheap", and then they try to buy a ticket, they either find:
* The cheap tickets have been sold, and they're disappointed.
* The cheap tickets haven't been sold, and perhaps they can leave it until tomorrow, and they don't buy now.
neither of which causes immediate action.

A time based discount encourages people to book early, which you want. A  quantity based discount encourages people to book first, which they have no control over, because that's down to how many other people have booked already.

If the show flops, your quantity based discount still applies to those sad tickets being sold on the door. If the show sells well, you probably didn't need to give a discount. Either of these outcome is the opposite of revenue maximisation.

Rather than keeping a strict count of exactly how many discounted tickets have been sold, one alternative would be to use dynamic pricing to check every 30 minutes whether more than 50 tickets have been sold, and if they have been, puts the price up from your earlybird price of e.g. £20 to the full price of e.g. £25. This removes the problem with weird edge cases where a basket has a mixture of discount tickets and full price tickets. But it does mean that if 49 tickets have been sold, and then we do our check, and then in the next 30 minutes another 10 tickets are suddenly sold, and then we put the price up, the promoter looks at their sales return and says "I told you only to sell 50 tickets at the discount price and you sold 59! You owe me £45 you bastards", which also a pain, unless they understand and agree it might go over.




In short: there are loads of better ways of doing promotional discounts. Make it a 3 for 2 offer. Put a code on your Facebook page and make it give the discount "for a limited time" and keep an eye on it. Make an earlybird discount with a fixed end date. Use dynamic pricing to tweak the price for you. Wait to see how early sales go and THEN do a discount if the answer is "badly". Do flash sales and promote them on socal media.

Monday, 27 February 2017

Things I'm pretty certain aren't mathematically possible and I wish people would stop asking for (1)

1) A report linking payment types to shows.

Which boils down to: directly linking individual payments to individual tickets.

Oh, I understand why a finance dept might ask for it. Especially a finance dept that usually deals with invoices and BACS payments. This ticket has been bought, so it must have been paid for. Which payment paid for it?

But.

It is possible to have a mixed basket with split payments.

I know that it hardly ever happens, but it's designed into the system, and I can't take it out, and I can't do anything that's fundamentally incompatible with the fact that you can have tickets for Show A and Show B in an order, and pay for them with Payment 1 and Payment 2 of different payment types.

If I have an order with 2 tickets for Sooty in Space (£10 each) and 2 tickets for The Importance of Being Ernest (£15 each) totalling £50, and it's been paid for £5 gift voucher and the balance (£45) by card, there isn't an easy answer to the question "Which ticket was paid for by the gift voucher?".

The only sensible thing to do is split the gift voucher between the shows based on face value; £2 to Sooty and £3 to Importance. So the £45 of card payments is assigned £18 sooty and £27 Importance.

Suppose now we cancel the Sooty tickets and refund £20 back to the card.

Suddenly the proportions have changed. The £2 of gift voucher that was paying for Sooty is now paying for Importance tickets: our original assignment must have been incorrect, and we now need to go back and change it to £20 card against Sooty (so that we can refund it) and £25 card + £5 gift voucher against Importance.

The means that that amount of money in the "credit card income" column for Importance has gone DOWN, as the result of an unrelated cancellation. No Importance tickets have been cancelled, and the promoter of Importance might be very strict about not allowing refunds, and is going to need a lot of explanation as to why their numbers have retrospectively changed.

The only way I can see to actually make this work is to treat every single ticket like its own account ledger. There's a £10 debit on the Sooty ticket and then a £9 card credit and a £1 gift voucher credit, and then for the refund there's a £1 gift voucher debit and a £1 card credit (matching with the Importance ticket, so the first phase of doing a refund is doing an internal transfer between one ticket and another) and THEN a £10 card debit and a £10 cancellation credit, leaving the ticket's account balanced a £0. I've seen a bunch of ticketing system databases in the course of doing data conversions, and no one does anything as mental as this.


How does everyone else handle this? Should I just stop whinging and just split every payment down to every ticket?




Thursday, 5 November 2015

Ticket Ballot

Finally got to use the system to run a ticket ballot. Everything went according to plan!

It's a nice combination of lots of small bits of already existing functionality that come together to be more than the sum of their parts.

Firstly, we create a Marketing List signup, that allows people to join a specific marketing list. This functionality was motivated by Waiting Lists - and general enquiry forms - but also works for this, for no extra development effort.

So we make the signup available, and the (lots) of people sign up to the list, creating accounts with passwords, addresses, etc, and using the existing Custom Form functionality to supply additional details.

We give them time to sign up - and then we close the ballot.

Next, we dedupe the list of signups - by name, email address, postal address, and additional id info - using existing functionality, so people with multiple email accounts don't get multiple chances.

Then, we copy the signup list, and use the existing "Random Filter" marketing tool to draw N names from the signup. We then use the existing "Add User Status" marketing tool to give these people a "Ballot Winner" membership status for the next day... and then extract the names and send them an email informing them that they've won the chance to buy a ticket. The ticket product, of course, is on sale only to people with the "Ballot Winner" status, so those people can buy tickets and no one else can.

At the end of that period, if there are any unsold tickets, we draw more names, and repeat the process - copy the signup list, remove the people who won in round 1, and then filter down again.


What I've learned from this first go is:
1. The click through rate is surprisingly low, and if you have enough tickets for N orders, and you only draw N names, you'll need to do several rounds.

2. Rather than insisting that everyone who wins the ballot gets a chance to buy a ticket, it might be more efficient - especially if time is limited - to draw 2N names, and change the communication so that it's clear that they aren't *guaranteed* a ticket - there's still competition, it's just much more civilized, with 2N people after 2N tickets, rather than 1000N people after N ticket.

3. It's much, much calmer than throwing a few tickets on sale and hoping that the servers don't melt.