I've been hearing people asking for Loyalty schemes for ticketing systems for years. I'd never been able to work out what they'd do with one once they got one.
I think the problem was that I immediately translated loyalty schemes into the one I knew best - supermarket schemes. I'm still not really sure how they're supposed to do any good, given that there's nothing to stop you from entrolling into all the schemes collecting points for all the supermarkets at once, but that's not the point. The basic model I had in mind was "collect points; spend points", as if the loyalty point were some kind of second rate currency, and the chances are the shows you could buy tickets for for points would be the slow-selling Wednesday matinees, and not the in-demand Friday evenings.
Keeping a points balance total is a pain. You get all sorts of nasty edge-cases, what if someone buys a ticket, claims the points, spends the points on a different ticket, and then gets a refund on the first one? People love hacking special offers and finding the loopholes; the famous hoover flights fiasco a case in point.
And whilst this model clearly works for some industries, I couldn't work out how it would drive sales to theatres and venues and other live events. Why would you buy a ticket to something you didn't really care about seeing, in order to get points, to spend on something else that you do want to see? You'd buy the tickets for the things you wanted, and whilst points might be nice, they're not going to make you see an extra show, or choose to see a show you don't like so much at venue A over a show you prefer at venue B. Supermarket loyalty points work when you're selling commodities, and when it's just as easy to pop to the shop down the road instead; as with all commodities, all that matters is the price, and the points get factored into that.
I thought this was how Air Miles worked too - and to some extent they do - until Andrew mentioned to me why he cared about Air Miles. It's not because you might spend them on a free flight someday, it's because if you collect enough of them, you start to get "Silver"status and free upgrades and access to the lounge and the perks and so on. I guess I never took enough flights to find out =)
And suddenly this makes sense, in the context of selling tickets for live events. There's no need to keep a balance, and invent ways to "spend" points. We just need to run a calculation, say, every night, and look at your purchase history for, say, the last 6 months. And if you've done enough stuff with the venue in that time-frame, then we'll give you a membership level for free. It might be different to the normal membership that we sell; it might be the same (though I think it should be different, see below). It could give priority booking periods, or money off tickets. It might just come with a special hat. It doesn't matter; if you loyally attend lots of shows, you're given something... and if you stop going, it gets taken away again.
And that's where I can see it driving sales. You email someone and say "come and see one more show before the end of the month, and you'll get a free membership for 6 months", and what you're really saying is "you're the kind of person who goes to the theatre a lot and supports the arts, and that's a good thing". And I can totally imagine someone making the effort to see an extra show, because that's them making a statement about themselves and their values. You email someone and say "your free membership will lapse unless you see one more show before the end of the month", and you're really saying "You've stopped being the kind of person who goes to the theatre a lot. What happened?", and they'll come back to prove you wrong. Instead of the supplier trying to buy the customer's loyalty with nectar points, the perk becomes a status symbol that the customer can't directly buy at all - they have to PROVE your loyalty to the theatre before being allowed. And at that point it becomes something people take pride in and work for and keep up; the opposite of all those unclaimed air miles. And the threat of having that status taken away again should work brilliantly to motivate people to take a chance and see that extra show.
TLDR version:
All items purchased are assigned a loyalty value (configurable calculation based on ticket price)
Every night, the loyalty values of purchase for the last $daterange are added up.
Accounts "near" the threshold are emailed telling them they're nearly there.
Accounts over the threshold have a membership status automatically applied to their account for $daterange2
Accounts qualified once and remain below the threshold for $daterange2 lose the benefit, and will get the normal "your membership is about to expire" reminders.
Monday, 22 October 2012
Saturday, 7 April 2012
Limited Availability
Just talking to myself here, figuring out how this is going to work.
We need to be able to limit how many tickets someone can buy, because otherwise the touts buy up hundreds then try to resell them.
Fair enough.
But it breaks down into lots of different use cases, and I want to be clear I'm catching them all.
1. Limit number of tickets per order, for a given product.
You've got something that's going to sell fast, but you aren't too concerned about fraud. 6 tickets per order, nothing to stop anyone buying another order.
2. Limit number of tickets per account, for a given product.
You're a bit more worried about people coming back for another order, so you want the quantity limit to be per account.
3. Limit number of tickets per delivery address / billing credit card, for a given product.
You're even more worried that people will be buying as many tickets as they can for resale, so you want to limit the tickets per delivery address or credit card, across accounts.
4. Limit number of tickets for a given show
It's not just per product, you've got 5 performances to sell, and you want a maximum number of tickets sold across all the performances.
5. Limit number of tickets at a given discount
There's no limit in general, but a customer can use their "Membership" discount on at most 2 tickets - themselves and a guest - and the rest have to be full price.
6. Limit number of tickets at a given discount, AND the total number of tickets
A customer can have at most 5 tickets, of which at most 1 can be at the membership discount.
So the problems are:
Q. How to we define whether the limits are per product, or per group of products?
A. We could create a "ProductLimit" group thing, and all products that reference the same ProductLimit share a counter... but that means that if we have 50 performances and the limit is per performance, we have to create 50 product limits, that are identical in every respect.
We could give the ProductLimit a property "Per Product", so that all products reference the same ProductLimit, but that limit can be either global (5 tickets per show) or individual (5 tickets per performance). That doesn't help if the requirement is "at most 5 tickets per performance AND at most 15 tickets across all performances".
We could give the ProductLimit two properties: MaxQuantity and MaxQuantityPerProduct, either of which are nullable.
And then it gets 10x more complicated because of the membership discount issue. If we just store the MaxQuantity in the DiscountScheme, then we can say "At most 2 tickets at the membership price", but what does that apply to? The order and just that product? The account, and all the performances in the show?
Right.
Ok, so we're going to have to add ProductLimitRules
Each rule will state:
1. Applies to products individually, or all products that share this product limit. "ProductLimitRuleShared"
2. Applies per: order / accounts / address + cc. "ProductLimitRuleScopeId"
3. Applies to Discount (i.e. "Child", though I struggle to imagine a show where you're allowed to buy at most two Child tickets and at most two Adult tickets, and aren't allowed to buy 4 Adult tickets). "DiscountId"
4. Applies to User Status (i.e. Membership). "UserStatusTypeId"
5. Maximum Quantity. "MaxQuantity"
We need to be able to limit how many tickets someone can buy, because otherwise the touts buy up hundreds then try to resell them.
Fair enough.
But it breaks down into lots of different use cases, and I want to be clear I'm catching them all.
1. Limit number of tickets per order, for a given product.
You've got something that's going to sell fast, but you aren't too concerned about fraud. 6 tickets per order, nothing to stop anyone buying another order.
2. Limit number of tickets per account, for a given product.
You're a bit more worried about people coming back for another order, so you want the quantity limit to be per account.
3. Limit number of tickets per delivery address / billing credit card, for a given product.
You're even more worried that people will be buying as many tickets as they can for resale, so you want to limit the tickets per delivery address or credit card, across accounts.
4. Limit number of tickets for a given show
It's not just per product, you've got 5 performances to sell, and you want a maximum number of tickets sold across all the performances.
5. Limit number of tickets at a given discount
There's no limit in general, but a customer can use their "Membership" discount on at most 2 tickets - themselves and a guest - and the rest have to be full price.
6. Limit number of tickets at a given discount, AND the total number of tickets
A customer can have at most 5 tickets, of which at most 1 can be at the membership discount.
So the problems are:
Q. How to we define whether the limits are per product, or per group of products?
A. We could create a "ProductLimit" group thing, and all products that reference the same ProductLimit share a counter... but that means that if we have 50 performances and the limit is per performance, we have to create 50 product limits, that are identical in every respect.
We could give the ProductLimit a property "Per Product", so that all products reference the same ProductLimit, but that limit can be either global (5 tickets per show) or individual (5 tickets per performance). That doesn't help if the requirement is "at most 5 tickets per performance AND at most 15 tickets across all performances".
We could give the ProductLimit two properties: MaxQuantity and MaxQuantityPerProduct, either of which are nullable.
And then it gets 10x more complicated because of the membership discount issue. If we just store the MaxQuantity in the DiscountScheme, then we can say "At most 2 tickets at the membership price", but what does that apply to? The order and just that product? The account, and all the performances in the show?
Right.
Ok, so we're going to have to add ProductLimitRules
Each rule will state:
1. Applies to products individually, or all products that share this product limit. "ProductLimitRuleShared"
2. Applies per: order / accounts / address + cc. "ProductLimitRuleScopeId"
3. Applies to Discount (i.e. "Child", though I struggle to imagine a show where you're allowed to buy at most two Child tickets and at most two Adult tickets, and aren't allowed to buy 4 Adult tickets). "DiscountId"
4. Applies to User Status (i.e. Membership). "UserStatusTypeId"
5. Maximum Quantity. "MaxQuantity"
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.
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.
So.
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 http://www.securetrading.com/
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.
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.
So.
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 http://www.securetrading.com/
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.
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
Subscribe to:
Posts (Atom)