College Football Dynamic Pricing Model

[Tatanka]

I agree but those additional virtual servers or SLA bump would be an expense with 0 ROI. Unless NDSU would lose money by people not buying tickets because of frustration over the ticket system they have no reason to increase that expense.

Isn't it all about customer experience? Let's face it: the ticketing business does not typically follow a level, steady demand model. There is a daily demand level, relatively low, with significant spikes for key events.

If I'm providing technology services for that type of model, I plan resources appropriately for the expected customer's customers' experience, and I need to fully understand the model of what my customer is trying to do. End customers don't give a non-street-legal helmet car full of shit if the site works perfectly 99.9 percent of the time, they care about what the system is like when they're trying to access it. At 8:00 this morning, or before every home playoff game, people are all trying to get tickets. They're having a shitty experience. That reflects poorly on my company because I'm providing the service, and on my customer because their name is on the site and they're the ones trying to sell something.

Tatanka's bottom line: it's not like someone is trying to implement a ticket sales mechanism on a server that serves up recipes to housewives that lack creativity, it's a system designed for ticket sales. It should be more responsive to the demand it is likely to get during peak ticket sales, and flexible enough to take advantage of resources when they're needed, especially if the hosting environment is responsible for serving several tenants. NDSU's peak ticket demand, although awesome, is very very small compared to what a decent ticketing system should be able to handle on a routine basis.

Flame away.

[IndyBison]

Client Satisfaction. All the seats may be sold but other contributions remain to be earned. I ran into a similar scenario when I ran a services business. Resources are constantly being reallocated with the dynamics of a server farm. My contract with the server folks stated both an average response and responsiveness at peak. Lets just say they only missed the SLA once.

Agreed. But the cost of maintaining the SLA for the spike in demand may not have been worth it to NDSU. They were going to sell the tickets regardless. I'm completely making up numbers here but let's say the normal cost for this service with standard SLAs is $5k/month. For this one day/4 hour spike, I'm going to charge you $15k. This includes increased server capacity, dedicated network, dedicated resource monitoring. If I'm NDSU I have to decide if that increased investment is worth it.

Isn't it all about customer experience? Let's face it: the ticketing business does not typically follow a level, steady demand model. There is a daily demand level, relatively low, with significant spikes for key events.

If I'm providing technology services for that type of model, I plan resources appropriately for the expected customer's customers' experience, and I need to fully understand the model of what my customer is trying to do. End customers don't give a non-street-legal helmet car full of shit if the site works perfectly 99.9 percent of the time, they care about what the system is like when they're trying to access it. At 8:00 this morning, or before every home playoff game, people are all trying to get tickets. They're having a shitty experience. That reflects poorly on my company because I'm providing the service, and on my customer because their name is on the site and they're the ones trying to sell something.

Tatanka's bottom line: it's not like someone is trying to implement a ticket sales mechanism on a server that serves up recipes to housewives that lack creativity, it's a system designed for ticket sales. It should be more responsive to the demand it is likely to get during peak ticket sales, and flexible enough to take advantage of resources when they're needed, especially if the hosting environment is responsible for serving several tenants. NDSU's peak ticket demand, although awesome, is very very small compared to what a decent ticketing system should be able to handle on a routine basis.

Flame away.

I would guess the service provider can provide the increase demand. But does the customer (NDSU athletic department in this case) want to pay for that increased demand. I would be very surprised if this was an issue with the ticketing system being able to handle the peaks demand. It's more likely the athletic departments willingness to pay for the peak. It will have NO impact on number of tickets sold and revenue from ticket sales. BBR has a point that it COULD impact future support of the program. A reduction in success of the program is more likely than the ticketing system to do that.

If you were to run into these issues on target.com you would just go to walmart.com or meijer.com or amazon.com to buy your items. The retailer has an incentive to make sure they are investing in the right technology and managing demand.

[BlueBisonRock]

I appreciate how you are thinking, but I will state that your estimates are 'just a bit outside' the actual cost to the client. Even with your estimates, the business would not be paying 15k for 4 hours of extreme performance. They are paying for the image that they want portrayed. A smart provider would handle this by taking on multiple clients wanting the flat performance curve. Then manage the risk by having the extra capacity to handle a small percentage of their clients hitting their respective peaks at the same time and day.

IMHO signing an SLA that does not address both the everyday average response / performance and the peak performance deserves a butt chewing. The same would hold for availability and we all know what happens when a URL is not available 24 hrs per day 7 days per week (x365). A business can not afford the perception of 'crap' with today's customer expectations and social media.

Agreed. But the cost of maintaining the SLA for the spike in demand may not have been worth it to NDSU. They were going to sell the tickets regardless. I'm completely making up numbers here but let's say the normal cost for this service with standard SLAs is $5k/month. For this one day/4 hour spike, I'm going to charge you $15k. This includes increased server capacity, dedicated network, dedicated resource monitoring. If I'm NDSU I have to decide if that increased investment is worth it.


I would guess the service provider can provide the increase demand. But does the customer (NDSU athletic department in this case) want to pay for that increased demand. I would be very surprised if this was an issue with the ticketing system being able to handle the peaks demand. It's more likely the athletic departments willingness to pay for the peak. It will have NO impact on number of tickets sold and revenue from ticket sales. BBR has a point that it COULD impact future support of the program. A reduction in success of the program is more likely than the ticketing system to do that.

If you were to run into these issues on target.com you would just go to walmart.com or meijer.com or amazon.com to buy your items. The retailer has an incentive to make sure they are investing in the right technology and managing demand.

[IndyBison]

I appreciate how you are thinking, but I will state that your estimates are 'just a bit outside' the actual cost to the client. Even with your estimates, the business would not be paying 15k for 4 hours of extreme performance. They are paying for the image that they want portrayed. A smart provider would handle this by taking on multiple clients wanting the flat performance curve. Then manage the risk by having the extra capacity to handle a small percentage of their clients hitting their respective peaks at the same time and day.

IMHO signing an SLA that does not address both the everyday average response / performance and the peak performance deserves a butt chewing. The same would hold for availability and we all know what happens when a URL is not available 24 hrs per day 7 days per week (x365). A business can not afford the perception of 'crap' with today's customer expectations and social media.

The costs were random but relative based on my experience. I used to manage several web sites/applications for a corporation that were hosted in a 3rd party datacenter and our hosting costs were over $100k/month. This stuff can get expensive, especially if you are looking at high volume sites or those with spikes. Even with that expense we had performance issues on sites when even a relatively few number of users were trying to access them at the same time. It was frustrating to me and to our customers but our SLA only allowed up to a certain amount of bandwidth to get the uptime we needed. We didn't have crazy spikes like this ticketing system. Our management wouldn't allow us to increase our budget to allow for extra capacity we needed to have the sites perform at the level we wanted. It's very possible the athletic department is in the same predicament. They still sold all their tickets in a 2-3 hour period so it worked.

Would you guess the number of transactions taking place on this day and the 3 playoff days is more than the other 361 days combined? I'm guessing NDSU has a pretty basic ticketing account based on the limited use outside of these 4 days. The upgrade needed to properly handle the volume they get on days like this could be high.

[Tatanka]

The costs were random but relative based on my experience. I used to manage several web sites/applications for a corporation that were hosted in a 3rd party datacenter and our hosting costs were over $100k/month. This stuff can get expensive, especially if you are looking at high volume sites or those with spikes. Even with that expense we had performance issues on sites when even a relatively few number of users were trying to access them at the same time. It was frustrating to me and to our customers but our SLA only allowed up to a certain amount of bandwidth to get the uptime we needed. We didn't have crazy spikes like this ticketing system. Our management wouldn't allow us to increase our budget to allow for extra capacity we needed to have the sites perform at the level we wanted. It's very possible the athletic department is in the same predicament. They still sold all their tickets in a 2-3 hour period so it worked.

Would you guess the number of transactions taking place on this day and the 3 playoff days is more than the other 361 days combined? I'm guessing NDSU has a pretty basic ticketing account based on the limited use outside of these 4 days. The upgrade needed to properly handle the volume they get on days like this could be high.

Believe it or not, I'm also not just talking out of my ass on this one. My whole point is that yes,I would believe the transaction pattern is as you mention in your last paragraph. Moreover, I would believe that it is that way for a vast majority of sporting event ticketing site customers. Which is why I as the provider, understanding that model, would ensure that I can support it with a proper hardware configuration and well written software. If not on my own accord, to live up to the sla that my customer should be holding me to. This is a relatively rare case where you should build your church for Easter Sunday.



And as a bonus, I'll grant that neulion's server is not a 386-33. It's at least a Windows XP machine with 512MB of RAM and a Pentium II processor. And before you say "that's not even server software" I will agree with that but say I've seen it when evaluating a business for acquisition, and it was hosting a business critical web application. Performance, by the way, similar to neulion yesterday morning albeit with fewer users.








Sent from somewhere using my Win8 phone or something.

[Gully]

You guys are way off base. I have it on good authority that the system is being run on a Commodore Vic20 that Craig Bohl had as a kid in Nebraska.

[Tatanka]

You guys are way off base. I have it on good authority that the system is being run on a Commodore Vic20 that Craig Bohl had as a kid in Nebraska.

I actually still have mine... It had a whopping 5k of RAM! LOL





Sent from somewhere using my Win8 phone or something.