The move to mobile ticketing.

The story of our shift to mobile ticketing is an interesting one because it sits at the intersection of our visitor experience goals, our upcoming digital projects, and the need to lay a foundation strategically and with great flexibility. This is a fundamental shift with wide reaching implications for our present and our future.

On March 1, we flipped the switch from Siriusware to Acme Ticketing. We made the switch for number of reasons including the need for a fully mobile POS product, a cloud based solution for flexibility, the need to decouple systems internally for better manageability, a modern UX, and a system that could act as a CRM for future projects. Acme fit that bill in a number of ways and presented the best solution for us.

Front Line Activation

Upon my arrival at the Barnes the most pressing concern coming from front lines staff was the ticketing system. Onsite, they were dealing with an overly complicated POS that was significantly slowing down guest interaction onsite. Task number one was to find a new system that was easy to use, simple, efficient, and fast.

Arup’s recommendation — change the current ticketing desk (pictured right) so visitor services staff can make better eye contact with visitors; go from a hotel-like setup to one that is more active.

This was coupled with our wayfinding project and Arup making very clear recommendations about getting this team into a more active position. Our previous setup included a sit down desk. Visitors were often seen — with tickets in hand — coming up to the desk to give their name to “check in” and this would slow the ticketing process to a crawl. Simply put, the visual language of the lobby was articulating something more along the lines of a hotel where you register rather than a place where quick sale transactions happen. (As an aside, we’ve got an upcoming session at AAM to talk on these very issues.)

We’ve developed a few prototype desks — all on wheels for mobility — so we can test placement of front lines staff. Eventually, these desks will be manufactured with nice materials, but for now these help us learn lessons in the short term about desk footprint, height, and storage requirements before we build the final thing.

Additionally, we have Broad-like aspirations for this team; we want an active front lines staff and one that is not always behind a desk. Ticketing needs to be flexible enough so the staff can be mobile enabling us to provide the best ticketing experience based on time of day, type of event, and capacity. This means changing desk positions within the building and/or the team may not be behind desks at all preferring to greet incoming guests on the fly both inside and outside the building. The solution needed to give us this mobility and Acme was built as a mobile first environment.

Standing/perching plinth-style desks put less in between our front lines and visitors. Hardware is easy to unmount to help people in a variety of situations where desks may not be a good solution.

Mobile Ticketing

Mobile wasn’t just important to us for flexibility of point of sale, but it’s increasingly important for online transactions as 50% of our web traffic is coming from mobile devices. Online, the issues were similar to what we were seeing with the front of house; an overly complicated UX that made ticketing difficult to end users. The need for a mobile first product in all respects was very clear.

Backend Flexibility and Sustainability

We had a number of concerns on the back of house side and Acme proved to be the right choice here.

There was a need to decouple existing services. In our previous model we had a lot of integrated systems — ticketing was fully integrated online, in the shop, and across membership. Integrated systems are good in many ways, but when you need to change any one of the pieces, you run into a tangled web of dependencies. With so many technical changes coming up for the Barnes, there was a clear need to decouple systems so we could keep projects running on multiple tracks. Acme provides a white box ticketing site that we can run alongside both our current website and our redesign project.

There’s an API; critical to have as we think about future integration. Decoupling is the right move as we go through various projects, but integration may be a better answer later. Finding a product that had both options offered us considerable flexibility with room for later growth. If you are curious, MoMA is using the Acme API for all of their front end ticketing while the New Museum is using the white box site; both represented solid implementations.

Additionally, we needed to get up and running quickly. Moving to a cloud based system meant no hardware overhead costs — the pricing model is based on per transaction fees and all hardware is included with the contract. We didn’t need to sink money into infrastructure to get this up and running; we could do the move because the pricing model enabled us to do so.

Lastly, we are a small shop. Tessitura was much too large and complicated to deploy here and didn’t hit all the right notes. Altru wasn’t robust enough. Acme was that nice middle ground providing the flexibility and the mobility we needed. Interestingly, we wouldn’t have even had this option only a year ago; the mobile first products are just that new to market.

Future Roadmap

Ideally, engagement data should reside alongside ticketing data; we now have the system in place to build out the production wearable project. Acme is a ticketing/membership POS system that supports Salesforce for CRM integration; we see this as a critical in laying the foundation for future plans with the wearable.

Acme has a built in sync with Salesforce, and Raiser’s Edge via a JCA adapter. Similar to the whitebox/API thoughts outlined earlier, this means our Development team can continue to use RE while we do discovery on Salesforce as a future option for that team.

This product isn’t perfect by any means; there were plenty of gotchas in implementation — membership stakeholders not thrilled about features not ready by game day, questionable choices the online sales cart functionality — and I’m sure many to come as we move through production. All of these things we are happy to discuss more, but, overall, a lot of what we were looking for is in this package. It’s nice to finally put the client/server architecture to bed.

Many thanks to all the colleagues — including those at The Broad, MoMA, Bowers, MIA, EMP — who helped get us through this project. Not only were there plenty willing to talk about their current experiences, but so many willing to think about how we could work together to solve common problems. It was clear to me going through this process, that so many of us are dealing with ticketing and it was nice to have sounding boards as we went along.