Since the onset of the Orchestra Website Reviews, the issue of requiring users to register in order to explore ticket information and/or make a purchase has generated a great deal of heated debate. Unfortunately, most positions boiled down to hunch rather than anything supported by quantifiable data but an article by Jared M. Spool published on 1/14/2009 titled The $300 Million Button that was originally published as part of Luke Wroblewski’s book, Web Form Design: Filling in the Blanks, provides some invaluable resource material for this issue…
Back in 2004, the majority of orchestras from in the Orchestra Website Review that managed their own box office favored requiring users to register in order to explore ticket availability and pricing. Since that time, most of those groups have lifted this requirement with regard to browsing ticket availability but most continue to require users to create an account before they can actually purchase a ticket.
Supporters of required registration usually claim that it speeds up the purchase process for repeat buyers and provides useful data for marketing and development efforts. Spool begins his article stating just as much:
The team saw the form as enabling repeat customers to purchase faster. First-time purchasers wouldn’t mind the extra effort of registering because, after all, they will come back for more and they’ll appreciate the expediency in subsequent purchases. Everybody wins, right?
To test this theory, Spool’s firm conducted usability tests and uncovered some surprising results.
We asked [test subjects] to bring their shopping lists and we gave them the money to make the purchases. All they needed to do was complete the purchase. We were wrong about the first-time shoppers. They did mind registering. They resented having to register when they encountered the page. As one shopper told us, “I’m not here to enter into a relationship. I just want to buy something.”
…many vocalized how the retailer only wanted their information to pester them with marketing messages they didn’t want. Some imagined other nefarious purposes of the obvious attempt to invade privacy. (In reality, the site asked nothing during registration that it didn’t need to complete the purchase: name, shipping address, billing address, and payment information.)
When it came to testing whether or not requiring registration facilitated future purchases, Spool’s team uncovered more surprises.
Except for a very few who remembered their login information, most stumbled on the form. They couldn’t remember the email address or password they used.
This point should be particularly poignant for orchestras since the primary ticket buying demographic is one that does not have the same level of comfort with computers and online shopping as say, the current round of 20-somethings. Spool goes on to state that the memory issue had a strong negative impact on the retailer’s customer databases.
Later, we did an analysis of the retailer’s database, only to discover 45% of all customers had multiple registrations in the system, some as many as 10. We also analyzed how many people requested passwords, to find out it reached about 160,000 per day. 75% of these people never tried to complete the purchase once requested.
For orchestras, the dynamic impact of this outcome is horrific. Unless an organization checks their user database for multiple registrations from the same user on a monthly basis, they’ll end up completely blind to the fact that they are sending multiple marketing and donation requests to the same individual. Most orchestras are already experiencing a great deal of blowback from patron burn-out over the quantity and frequency of emails but according to Spool’s study, things could be worse than what most currently believe.
Fortunately, Spool’s work didn’t end with identifying problems and walking away. Instead, the project included designing solutions, and the primary offering was straightforward and effective: eliminate required registration.
The [registration] form, intended to make shopping easier, turned out to only help a small percentage of the customers who encountered it…The designers fixed the problem simply. They took away the Register button. In its place, they put a Continue button with a simple message: “You do not need to create an account to make purchases on our site. Simply click Continue to proceed to checkout. To make your future purchases even faster, you can create an account during checkout.”
The results: The number of customers purchasing went up by 45%. The extra purchases resulted in an extra $15 million the first month. For the first year, the site saw an additional $300,000,000.
Granted, the sales components in Spool’s project don’t apply to every aspect of orchestra websites. For instance, the retailer Spool was working with wasn’t selling a niche product to a niche market, like orchestras do. As a result, there are bound to be some differences in the characteristics of average website users that are interested in purchasing tickets online. But how much of a difference do you think can be? Enough that Spool’s findings are completely useless? Doubtful.
Furthermore, an option left unexplored by Spool (at least, in his article) was offering the user to create an account after they completed the purchase process. A simple “To make future purchases even easier, would you like to use the information you entered to create an account?” option might offer an elegant compromise that works well for orchestra websites.
Conclusions
As it stands, one of the best options to determine if Spool’s findings could benefit the orchestra field is to conduct more research. Furthermore, a project such as this is an enormously appealing vehicle to present to granting institutions and is something that could be designed, implemented and concluded well before the end of the season. Additionally, it could be expanded into two portions with the second covering the onset of 2010/11 subscription sales.
This is a fascinating project and one I am eager to explore on a professional level with an orchestra that is interested in discovering untapped revenue and audience development potential at a time when increases in both are needed more than ever. Consequently, if your institution is interested in exploring where this can lead, contact me via email or call my Chicago office.
This pre-registration bit is one of my pet peeves, and not only for orchestra websites.
The business model behind this notion seems to be: “Let’s see, how much can we hassle a potential customer before they buy something from us.”
The follow-up offer of registration for an unhassled customer seems to me a much more courteous approach…and probably more successful too.
Great article!
But what about those organizations that utilize Tessitura as the ticketing software? That software requires online users to enter their info, either as a registration, or at the time of purchase.
Has anybody out there found a way around that?
That is an excellent question Britt. anyone in the business knows that Tessi is one of (if not the) dominant player when it comes to self managed box office solutions. I did not contact anyone in advance of writing this article but I do recall from past conversations (and those with some current users) that there is the ability to modify when the registration process occurs. Whether or not Tessi can allow users to make a purchases without registration or put the registration process as an option after the purchase is something I don’t know.
( Full Disclosure: I’m one of the developers of Theatre Manager http://www.artsman.com )
This post is quite long, so for those reading this that are Theatre Manager customers, here is the readers digest version: These ideas have merit and we will be looking to implement them ourselves.
I think Drew has brought up some interesting points about registration and the general behavior of people on the internet with regards to giving out information. Privacy is, and should be, a large concern for many ticket buyers and that line of thinking tends to manifest itself in process changes like this. I thought I’d add a software developers position on the issue and some of the concerns this brings up.
I believe pre-registration is most definitely a bad way to go. There should be very little resistance for a person to see what the events are, what kind of availability an event has, and how much those tickets are going to cost them. To apply a metaphor; I believe that you should let the users into the store to see if there is something they want to buy, rather than make them stand outside and window shop until they show cash at the door.
When it comes to time of purchase there is a minimum set of information that needs to be collected depending on the processes implemented at a given theatre. At a minimum the theatre would require first name, last name and a credit card number to process the order. Without that bit of information the person could not be identified at the door and it wouldn’t be possible to give them their tickets.
In addition to the minimum set of information, theaters may also require an address for shipping the tickets to the patron or for saving some money on credit card processing fees. The phone number or email address may also be required to get in contact with a person in case a show is cancelled or changed and the phone number may, again, be required to save on credit card fees.
So, assuming that one wishes to save money on credit card processing fees and wishes to offer the option of shipping tickets to a patron, you end up with this minimum set of criteria:
Name
Credit Card
Also Possibly:
Phone
Address
The obvious exclusions here are e-mail and password, which, from the article, seem to be the pieces of information that people do not wish to enter or, in some cases, remember. So how does one go about handling this situation in a theatre? It’s all about duplicate management. The patron will trade his ability to log in quickly, with a unique identifier(e-mail), for the duplicate data entry of this minimum set of information. Put another way, every time a patron buys tickets they accept that they will have to enter this information.
The article has a quote, “Later, we did an analysis of the retailer’s database, only to discover 45% of all customers had multiple registrations in the system, some as many as 10.”. To accept this system of minimum data entry you have to accept that you are going to allow 100% duplicate registration for privacy concerned patrons. After all, any time a person with the concerns mentioned logs in, we are saying that they will not identify themselves in advance and will only enter this minimum set of data.
This system imposes a very real work-load on the theatre to manage the duplicates that are created so that they can have an accurate snapshot of who their customers are. Sadly, this is also a work-load that is difficult to do automatically for the minimum set of data. One could match a name, a phone number and an address, if all of those things were provided, and do an automatic account merge to help alleviate the problem, but that doesn’t work in the lowest common denominator where a person only enters a name and credit card. In these situations you could try and match on name and credit card, but privacy concerned theaters are increasingly purging credit card information from existing customers as well.
Now some of you reading will probably say, “Ya, but for 300 million dollars I can manage some duplicates”, and you’d be right, because, for some, this extra workload will be worth the price of admission. For others it may not be a concern for their demographic or they may not be able to justify the extra staffing costs for managing the duplicates.
I think as a developer in the industry it’s my job to listen, and that it is our venues that should get the final decision. So we will be looking into enabling our clients to do this kind of thing, but only if they want to.
I think your final paragraph offers a good overall approach: options to the client. Regardless of any particular study there will almost certainly be some organizations that will go for the minority option. Ultimately, the reason is immaterial but having the ability to go in either direction will be of real value.