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.
Friday, 17 November 2017
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?
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?
Subscribe to:
Posts (Atom)