Ticketing 2017: Two new projects take on complex challenges

Douglas Hegley, The Metropolitan Museum of Art, USA, Andrew Serong, Australian Centre for the Moving Image, Australia, Andrew David, Minneapolis Institute of Art, USA, Meaghan Tongen, Minneapolis Institute of Art, USA, Eric Bruce, Minneapolis Institute of Art, USA

Abstract

Keywords: ticketing, software development, e-commerce, web, open source, integration

Introduction

Museums and other cultural heritage organizations have wrestled with ticketing systems for years for a number of reasons, including inelegant user interfaces that are complex and expensive to modify; difficulty gaining direct access to customer data; the need to apply complicated (and sometimes changing) discounts to pricing; and the complex customizations needed to adapt third-party software for institution-specific needs and brand-aligned user experiences.

This paper will discuss two of the latest approaches to ticketing in our sector. In 2017, two cultural organizations took on innovative approaches to solving some of these problems. The Australian Centre for the Moving Image (ACMI) developed a new ticketing site internally—its key concept: a cart-less and login-free experience. Also in 2017, Minneapolis Institute of Art (Mia) launched a new ticketing and transaction platform which uses an open source Web-standard approach to run transactions and connects to customers’ membership records.

Both institutions recognized the complexity and potential stress of developing these systems. As Andy Serong from ACMI has stated, “… there’s a very good reason that most Arts organizations don’t try to develop their own ticketing sites internally …  it’s very time consuming and difficult!” And yet, both ACMI and Mia made the decision to go this route. This paper will explain the key details of each project, including:

• Why a ticketing project? What problems were we trying to solve?
• How did the projects unfold and how was each platform built?
• Similarities and differences between the organizations and their projects;
• The word that sends shivers down the spine of all technologists: integration.

The authors will present their respective use cases and decisions, and compare/contrast approaches in the spirit of learning from these difficult undertakings. One goal of this paper is to share information that is meaningful and useful for staff ranging from senior decision-makers through software developers and on to those who spend their days working directly with ticketing and transaction systems, so that all may gain practical, real-world information about the technology, functionality, technical details, and hurdles overcome by each system.

Two innovative ticketing projects: Overview

In September 2017, the Australian Centre for the Moving Image (ACMI) launched a new ticketing site developed internally, called Museum Nice and Simple Ticketing—or MNST for short. ACMI built MNST as a Web product, using the Application Programming Interfaces (APIs) supplied by Tessitura. MNST is loosely coupled to the main organizational website, to allow a softer transition from existing systems. The key: a cart-less and login-free experience—in ACMI’s view, the option to login/register or checkout as a guest may seem like a good thing, but actually creates yet another situation where a user needs to make a decision. From ACMI’s perspective, each time a user is forced to make a decision is another time that user may choose to end the transaction.

Also in September 2017, the Minneapolis Institute of Art (Mia) launched a new ticketing and transaction platform called Hive. The system uses an open source Web-standard approach that pairs products (such as tickets, events, donations, and memberships) with the complex rules that are applied to them for eligibility and pricing. Hive directly references transaction history that is stored on customers’ membership records in Salesforce. Hive was built primarily with in-house resources, and includes interfaces for onsite point of sale registers, call center functionality, and self-serve online Web sales. Also key: integration with Salesforce CRM via APIs for full-system access and control.

Why

ACMI

In 2016, ACMI embarked on a website redevelopment project, during which a key user journey was identified: the visitor who has heard about a particular event and wants to find out more and attend (Paterson, 2017). Due to budget and time constraints, optimizing the purchase path was out of scope, but from the CEO/Director downward, there was a strong desire to see the user journey through from beginning to end.

ACMI’s chosen ticketing and CRM system is Tessitura. Since November 2011 when ACMI switched to Tessitura, we have used the product TNEW (Tessitura Network Express Web) for all online ticketing. At the time of writing, TNEW allows Tessitura organizations to customize the look and feel of their site via a simple HTML template, where the site is injected at a desired place within the page. An organization can create their own header and footer, and add custom styling and JavaScript, but the logic behind the server-side rendered page is out of the developers’ hands.

From 2011 to 2016, ACMI invested a lot of time into customising the look and feel of TNEW, but aside from reordering and restyling elements within a page, there was no easy way to optimise the number of steps, or separate pages, required to complete a transaction. To gain more control over the purchase flow, we came to the conclusion that we needed to create our own product, targeting the needs of our particular institution, which is a unique mix of being both a museum and a cinema.

The goal was simple: create a login-less checkout for a user to buy tickets to a single event or exhibition, in no more than three steps. We would develop this as something that could run alongside TNEW, replacing only the main purchase path, so that we could safely experiment with a minimal product and easily rollback to our existing system should anything go wrong.

Aside from improving the user experience, a goal for our team was to move from waiting for new features to be released for a product maintained by others, to taking ownership over the iterative design and development of our ticketing site, while still getting the benefits of an underlying ticketing system we could depend on.

Mia

At the Minneapolis Institute of Art, taking an intensive look at the ticketing system was part of a broad, multi-year strategic initiative focused on engaging audiences and deepening relationships with all museum participants. One major tenet of the current strategic plan is to enable our customers to experience more-personalized interactions with the museum, not only in the traditional binary member/non-member fashion, but across a much wider set of museum touch points, from online to onsite. Because Mia visitor statistics trend heavily toward local and regional audiences, the museum thrives when its customers demonstrate loyalty by interacting with the institution repeatedly and at deeper levels of engagement. From those perspectives, ticketing had to be viewed from both the customer usability perspective and the full array of backend processes and data flows.

From the customer perspective, the experience of ticketing had to feel seamless, easy, on-brand and on par with (or ideally even better than) other transaction platforms those same customers use across the competitive leisure market. Goals of the ticketing project included reducing clicks and logins, and allowing the customer to access their purchase history and to see and update their own information and communication preferences.

The front-of-house sales teams needed a tool that both collected and presented customer data effectively, and allowed easy access to a wide variety of product offerings while minimizing clicking, searching, and transaction time.

The ticketing system also needed to respond to increasingly complex products, which required extensive pricing and capacity adjustments based on a variety of factors and varying tiers of customer data collection requirements—from a simple ticket purchase, to membership sales, to class reservations and summer-camp sign-ups that required the collection of additional information, such as emergency contacts and serious allergies.

A foundation of the strategy to engage and deepen relationships has been the implementation of a customer relationship management platform, or CRM. After evaluating a number of powerful options, Mia chose Salesforce—a cloud-based software-as-a-service (SaaS) platform that manages all constituent information and serves as an authoritative source for customer information and interactions. Salesforce provides strong and open APIs to integrate it with other applications and tools, such as Salesforce Marketing Cloud for conducting and tracking the effectiveness of segmented marketing campaigns. Mia sought to implement a ticketing platform that would fulfill these requirements while also integrating with Salesforce.

At Mia, we are currently on our second iteration of the vital CRM+Ticketing approach. Our first implementation included Siriusware (transaction system for ticketing, memberships and donations) and an enterprise constituent management system built with Salesforce.org and roundCorner NGOC. During the discovery phase for the first iteration, this combination held the promise of integration and adequate front-end customization, making it the best options then available. However, integration was never fully achieved with real-time data between the two systems. In fact, there were a number of issues that arose during the time span of the first iteration:

1. The data model for the ticketing system proved incompatible with the data model of the Salesforce CRM.
2. Tools needed to attempt data synchronization across disparate models only added to the complexity of the technology ecosystem.
3. While the CRM product was cloud-based, the ticketing system required seven on-premises servers, adding to the museum’s systems overhead.
4. Inaccurate data manipulations within the CRM system made it difficult to troubleshoot issues, which unfortunately had the largest impact on the records of the longest-tenured, highest-dollar donors.
5. The customer-facing online user interface was inelegant, and shopping cart abandon rates were unacceptably high.

After nearly three years of trying to work with the first iteration, Mia staff went back to the drawing board. We started by planning a move from NGOC to a new Salesforce instance using the Nonprofit Success Pack (NPSP), which allows nonprofits to better manage common business processes. Once that decision was made, Mia turned to a re-evaluation of  ticketing, prioritizing the integration with Salesforce. A cross-functional team was formed to research available products.

After researching and testing several available ticketing products, the evaluation team compared the time and complexity of (a) attempting to integrate third-party software, versus (b) building the ticketing transaction platform in-house, so that we could control more of the variables. A number of the important comparison points between these two approaches are listed in Table 1.

Table 1: buy versus build

Decision preface: Mia is not a permission-based, hierarchical workplace, so the recommendations of staff teams—as long as they are worked out professionally, based on research, and aligned with consideration of the strategic plan—are generally accepted and supported by the executive level.

Decision: The Mia ticketing system evaluation team worked through a spirited debate and reached consensus on a decision: Let’s build it!

What

ACMI

Museum Nice and Simple Ticketing (MNST) is a Web app designed as a simple-to-use online ticketing front end for Tessitura’s APIs. It is comprised of three main steps for the user:

1. A session page, where the user can select their ticket quantities, any add-on items and make an optional donation.
2. A confirm/pay page, where the user reviews their order, enters their details and payment information.
3. A receipt page.

The main features for a user include the following:

• Purchase tickets to general admission sessions (films, events, exhibitions);
• Purchase tickets to timed entry exhibitions;
• Purchase add on items such as exhibition catalogues or merchandise.

Figure 1: MNST

All user actions related to browsing or exploring events and content are delegated to the main website, with the ticketing site reserved for just the process of selecting tickets and completing a transaction.

There is no login functionality, no cart, no registration. The purchase path is built with as many assumptions made about the transaction as possible, in an effort to reduce friction in a similar way to e-commerce platforms like Shopify that have greatly simplified online retail (Hawlk, 2017).

In developing MNST, we were inspired by the Cooper Hewitt’s work on their ticketing site (Walter, 2014) which modelled the purchase path on the simple UX of self-service ticketing platforms such as EventBrite (https://www.eventbrite.com/).

For the front end, we liked the simplicity and elegance of MOMA’s ticketing site (https://www.moma.org/tickets/select), with big touch-friendly buttons for selecting ticket quantities and an in-page unobtrusive way of dealing with add-on items, without requiring pop-ups or additional checkout steps.

Instead of making a user choose whether or not to create an account, in MNST, all transactions are through a guest checkout. ACMI’s visitor services team received so many complaints from users having difficulty logging in, registering, or resetting passwords that we reasoned it would be better for a user to enter their details every transaction, than to risk them having to reset their password each time. Unlike social media services like Facebook and Twitter, ACMI’s users typically don’t log in every day or even every week to purchase tickets and are therefore quite likely to forget their passwords, which was confirmed by looking at the analytics for our password reset page. Also, the effort of having to enter details each time is mitigated by most current Web browsers respecting autocomplete HTML attributes that allow users to pre-fill their personal information (Green, 2015).

As a front end and middleware for Tessitura’s APIs, MNST is tightly coupled to the ticketing system. All transaction processing occurs via the APIs, however it is loosely coupled to an organization’s corporate website. The handoff between the main ACMI website and MNST is performed via simple anchor tags to URLs referencing Tessitura performance IDs. The result is that the ACMI website can be altered or rebuilt separately to the ticketing site, which allows the rhythm and schedule of the marketing and branding of the website to occur at a separate pace to work on the user experience of completing a transaction. This separation of concerns allows us to work on code changes in small, iterative cycles, reducing the defect cost increase associated with larger development feedback loops (Beck & Andres, 2004).

To limit the scope of building the ticketing site and reduce the technical debt of creating a new system, MNST is a stateless Web app, with all persistent data stored in Tessitura. Rules within MNST are triggered based on content fields set within Tessitura by the ticketing team during event builds, enabling ACMI to safely and gradually switch between using TNEW and MNST where appropriate. It also means that should ACMI ever decide to discontinue using MNST in favor of TNEW or another Tessitura-based Web app, there is no additional database used by the ticketing site to migrate or export.

Mia

Mia created a custom integrated ticketing and transaction solution which the cross-functional team called Hive. It is a Web-based application that is flexible enough to meet the front-of-house business needs and integrate with Salesforce. Hive was developed using JSON (data structure), React JS (front end), Stripe (payment processor), Apex (custom Salesforce development), and PHP (Hive API).

Minimum Viable Product (MVP) Requirements: In order to deliver Hive in just a few months time, the initial delivery was agreed to include the following:

• Sell event and/or exhibition tickets to members and non-members;
• Sell My Mia Memberships and My Mia Membership Renewals;
• Use constituent data from Salesforce to determine price and availability of items;
• Record all transactions in Salesforce, with transactions associated with a purchaser when applicable.

Figure 2: Hive flow diagram

Figure 3: Hive “select tickets”

Figure 4: Hive “My Mia Membership”

Figure 5: Hive “Shopping Cart”

Figure 6: Hive ticket receipt and QR Code

How

Mia

The decision to build Hive in-house was finalized in April 2017. The goal was to sell the tickets for the next special exhibition on the calendar, scheduled to open in September 2017 (five months!). In addition, Hive would need to handle all membership transactions, record its activity in Salesforce, and act upon existing customer data in order to offer accurate discounts and benefits in the shopping cart. Not surprisingly, this scope expanded significantly as the complexity and dependencies unfolded through the life of the project.

Hive was built by Mia’s team of three full-time software developers, working closely with internal stakeholders to understand requirements across departments—especially visitor experience, advancement (fund-raising), and finance.

Hive is built as a rich javascript Web app that communicates with an API written in PHP. The javascript app is what a user interacts with directly in a browser. It is written in React, which declaratively defines the user interface and its behavior. It then communicates with the API backend which handles verification and finalization of an order. The API processes credit card payments using Stripe and handles errors before sending a completed transaction through to Salesforce.

Alongside the development of Hive, a major data mapping effort was underway to migrate Salesforce and its plugins, from Salesforce NGOC to Salesforce NPSP. Mia also required custom Apex development to create the custom connection from Hive into Salesforce. This phase of the project started in early June 2017, when the Mia software development team worked with an Apex developer to agree on a JSON structure to integrate the Hive with Salesforce.

It was necessary for the data structure to encompass required information about each transaction and the related constituent information in order to be useful for both Salesforce and Hive. The customer data from Salesforce is used by Hive to determine which products (such as tickets, events, etc.) can be purchased and which discounts should apply to each product. Hive then stores the transaction information and passes completed transactions to Salesforce. Hive defines a transaction as the order/purchase of one or more products—a word chosen intentionally to express that more than just tickets are available for sale. Currently, Hive handles memberships, donations, and class/event registrations along with lectures, tours, and exhibition tickets. This leaves the door open for long-term expansion into other corners of the museum, essentially for any transaction that includes a product that can be loaded into inventory in the Hive system (e.g., store/retail items or café/restaurant sales).

Custom Salesforce business logic written in Apex adapts the payload sent by Hive for storage natively in Salesforce and updates anything that needs to be written to the purchaser’s Salesforce account to ensure that new or renewed membership will be accurately recorded.

Mia’s developers partnered closely with consultants brought in during the project, to build internal knowledge of the Salesforce platform along with the custom business logic being applied. Thus future changes and fixes are able to be accomplished in-house.

Mia’s software development team practices Scrum, an Agile framework for completing complex work by clearly defining product owners, empowering team members, and encouraging frequent and precise communication.  A committed Scrum team organizes their tasks into short, iterative cycles to deliver working solutions that can evolve over time. Self-organizing teams must work closely with stakeholders to understand what is being requested and to deliver effective solutions.

To be Agile, an organization puts four core values and principles into practice, which together enable high-performing teams: individuals and interactions over processes and tools; working product over comprehensive documentation; customer collaboration over contract negotiation; and responding to change over following a plan (Beck et al., 2001).

There are challenges to applying Scrum in a museum environment. For example, it can be difficult to align the core Agile values with traditional business processes that have long been accustomed to working only from extensive documentation and comprehensive plans that are set before a single line of code is written. Secondly, applying Agile principles to new teams without training or adequate resources also presents challenges. At Mia during the Hive project, it was difficult to manage the competing priorities of internal stakeholders without an experienced product owner, and attempts to split time between traditional project management and Agile methodology proved challenging.

It became difficult to maintain Scrum process and practice (daily standup, sprint plannings, Scrum wall, etc.) as the pace and demands of the project increased and the work expanded beyond the software development team—both internally and externally. This was an important lesson in product development and effective teams: everyone needs to be committed to (and have a shared understanding of) the process, or it will quickly fall to the wayside.

Despite some setbacks, we continued to focus on minimum viable product (MVP) as the goal for each iteration of Hive. An apt analogy might be that of building a boat, which is a good example of how you can find success in developing toward the MVP. The question is, is it better to start with a canoe (and know that you can at least get from point A to B) or to work for a much longer period of time toward a high-powered speed boat, which is unable to go anywhere until it’s fully completed? At Mia, we opted for the canoe, with an eye toward a speed boat sometime in the future.

ACMI

MNST was built on staff time by a single developer, with input from a small group of staff from the ticketing, marketing, memberships, and ICT teams to provide insight into user and business needs for the product.

It is written in Python using the popular open source micro-framework Flask, created by Armin Ronacher. Python was selected as the main programming language, to fit in with the technology used for the main website which is a Python/Django stack. We chose Flask, as it allows us to run without a database to limit the application’s complexity, and is ideally suited to writing middleware applications.

Flask, like many micro-frameworks, allows the structure of an application to be reduced to a set of simple steps (Ronacher, 2010):

1. Route an incoming Web request to a function
2. Perform tasks based on that request
3. Return a response (for MNST, either HTML or JSON, rendered using the Jinja2 template engine, bundled with Flask)

In the case of MNST, the task is to take a Web request or form submission and then perform a series of requests to the Tessitura APIs for all common ticketing actions including checking session availability, selecting tickets, and completing an order. All pricing rules, calculations, and core ticketing behavior is handled by Tessitura, allowing the ticketing site to focus on the user experience and purchase flow.

The challenge in designing MNST was to create a simple and intuitive user interface that could obfuscate the complexity of an advanced ticketing system. To keep the purchase path lean, at every point in the transaction process we asked ourselves whether we could assume a particular choice for all transactions. With Tessitura internally requiring that all transactions are recorded against a constituent record, to achieve a login-less checkout, MNST performs the following steps on a submitted and validated ticketing order:

1. Get a Tessitura API client and a validated form
2. Attempt to associate the order with an existing email address in the system
3. If not, create a new account and associate the order with that account
4. Add the submitted address details to that account
5. Update the e-news interest for that account if selected
6. Transfer the anonymous cart to the now logged in user
7. Set the shipping method to “E-mail my tickets to me” if available
8. Get the amount due for the order
9. Set the payment method based on the first two digits of the card entered
10. Checkout the order
11. Record a session variable with the server time that the transaction was processed

Our articulated user journey was simple: get a user to purchase a ticket in as few steps as possible. But the process of building a production-ready Web app, and decomposing user-focused features into granular tasks to perform against Tessitura’s detailed API was very new to me.

The redeveloped ACMI website launched in December of 2016, with the minimal version of MNST released nine months later. The first few months of the project were a struggle. Building a working prototype that could perform the API requests to complete a transaction was fairly straightforward. However, crafting those requests together into a Web application that was robust enough to deal with everything ACMI hosts was very difficult. After scratching beneath the surface, to build a stable product with good, user-friendly error handling, required 48 features, tracked across 95 issues in a private Github repository, and more than 200 code commits. The distance of working at a much lower level of abstraction from a user requirement was very challenging to reason with.

Failing to break features down from a higher level of abstraction into smaller tasks early on had an impact on estimation and communication between development and the rest of the organization. Management would have very reasonable questions, such as “do you think we can launch by the end of the month?”, and without breaking down the backlog of features into smaller units of work, I was unable to give a definitive answer. In March 2017, I decided to take the time to divide the remaining features into smaller tasks that could then be grouped into milestones. This allowed us to sort feature requests into phases, to give a clearer view of which features could make it into the initial release, and which ones would be delayed until after release. It also improved morale, as closing off individual small issues gave visibility to our progress on a week-to-week basis.

This process taught me about the difference between quickly giving a ballpark estimate of magnitude of effort, and the detailed steps of planning work into tasks and milestones, allowing enough contingency for APIs behaving in unexpected ways (Mantle & Lichty, 2012).

Work from March to September proceeded slowly but steadily, and on September 14, 2017 we launched a production-ready Web app crafted for the vast majority of the films and exhibitions that ACMI presents. We completed the first phase with only the costs of staff time and an external code review performed by NCC Group (https://www.nccgroup.trust/).

The MNST technology stack comprises the following:

• Flask Web application framework (http://flask.pocoo.org/);
• MNST codebase stored in a private Github repository;
• Issues tracked and grouped into milestones within Github (https://help.github.com/articles/about-milestones/);
• Builds conducted from version control using internally hosted TeamCity (https://www.jetbrains.com/teamcity/), with unit tests using Pytest (https://docs.pytest.org/en/latest/);
• Successful builds deployed to ACMI’s on-premises web servers using Octopus Deploy (https://octopus.com/);
• Production and staging web applications hosted on Windows Server / IIS using Microsoft’s WFastCgi script to enable Python Web applications to be hosted on IIS environments via a bridge between IIS and Python using WSGI and FastCGI (https://github.com/Microsoft/PTVS/tree/master/Python/Product/WFastCgi).

Compare and contrast

The two ticketing projects described in this paper have important similarities as well key strategic differences. Both organizations recognized a need to deliver better experiences for their customers, while taking advantage of the underlying capabilities of their backend data systems. Both organizations sought to create products based solidly on the specific requirements of each institution.

ACMI focused primarily on the user journey, with a keen eye toward making their ticketing experience as seamless, easy, and short in duration as possible. By reducing decision points, customers are more likely to complete transactions and then engage with the events and offerings of the organization.

Mia’s primary focus was to build a viable ticketing and transaction solution, including an effective customer user journey and addressing the workflows and data flows of the museum. By combining the defined data structure of an enterprise CRM system (Salesforce NPSP) with the planned user interface of Hive, the team was able to build out a functioning system. Admittedly, the current customer interface for Hive took a backseat to the complex integration challenges and requirements for the minimum viable product. That being said, because Hive is a Mia product, the user interface is ultimately flexible and can be re-designed as needs arise. In addition, Mia’s larger strategic goal of deepening individual relationships with its customers is now supported by a transaction system that can determine and apply complicated benefits and log interactions so that future communications can be personalized.

Both organizations are striving to make visitor and member interactions seamless when it comes to purchasing tickets. Both organizations have moved from depending on a third party to deliver on feature sets to a position of ownership, with the ability to determine priorities and deliver on the most important needs while at the same time fully understanding the road ahead.

Integration

Ideally, linked technology systems can be “integrated” so that they act as a coordinated whole, without need for manual intervention. The term integration is probably over-used in the software and systems arena, and technologist often joke that the work sends shivers down our spines. Products often claim to provide easy and wide integration across numerous disparate environments, then in practice achieve only a portion of that promise. In practice, many so-called integrations still involve a person (or team) running a set of commands or pre-designed scripts which synchronize data across systems or run calculations and updates between systems. With both of the projects described in this paper, every attempt was made to create true integrations, so that the systems would operate together without any extra “person behind the curtain” workflows.

Mia integrations

Hive utilizes a series of different integrations, all revolving around the central API and plugins developed to communicate to the other required systems. Hive contains its own database which records transactions sent to it from the React front-end, as well as store records that are formatted for accounting reports and other financial processing. Utilizing several well-known design patterns extending the Hive API provides the flexibility to integrate with any other systems which are data-driven in nature.

Mia staff have written custom plugins for communicating with Salesforce and Stripe. These plugins are integrated with and enable two-way communications with our business processes.

Custom views built within Salesforce are used by our call center and front desk staff. This integration allows them to search for and make use of information contained within Salesforce and to send relevant information directly to the Hive front-end, saving the step of searching for users in two different systems.

For the front of house staff, we also needed to make use of existing point-of-sale (POS) hardware, not only for cash drawer handling, but also for reading credit card information and maintaining PCI compliance while doing so. This was accomplished by creating a custom service on the POS desktop PC’s which communicate directly with Stripe for handling payments, then passing the required information back to Hive, and finally printing a ticket or receipt for the transaction.

The Hive infrastructure is maintained in the cloud using Amazon Web Services, including the Elastic Compute Cloud (EC2) server instance and storage, and also making use of Amazon SES (simple e-mail service) for handling the sending of our e-mails, which is simpler than a manual e-mail server and avoids Mia staff needing to deal with issues of scalability or Spam filters.

ACMI integrations

As a front end and middleware for Tessitura, MNST has very little direct integration of its own, as all ticket sales and financial reporting is conducted through Tessitura. The result is a Web application with strong encapsulation, its only interface with the main ACMI website via simple URLs.

We use Mailgun (https://www.mailgun.com/) for sending transactional e-mails for its ease-of-use and quick response time compared to SMTP, and Google Analytics e-commerce tracking on the receipt page. Outside of these features, we intend to keep MNST integration minimal to maintain its simplicity.

Roadmap and possible futures

ACMI

We designed MNST according to ACMI’s needs, but kept the generalised needs of museums in the back of our minds. While we are not yet able to share this product or its source code with other organizations, finding a way to do that in the longer term is important not just because open source is common sense (Maeda, 2018), but because our work is indebted to the open source libraries we used to build our software. In the shorter term, the road ahead involves building out the remaining purchase paths that are currently served by TNEW:

• Multiple event purchases, packages and passes;
• Workshops and conference registration;
• Education bookings;
• Memberships.

We achieved what we set out to do with the project, which was to develop a product we could iterate on over time, and a user experience resulting in less friction throughout the transaction process. By keeping software development in house, we leveraged our own ticketing experience and domain expertise, which meant a faster feedback loop of development could be achieved, removing the need for formal requirements documents. It was also a way of addressing the reality that development cycles are becoming shorter and shorter as cultural organizations need to work harder to keep their digital offerings relevant (Mann, 2017). By carving out the ticketing application from the rest of the website, we reduce the overall scope of any future work on our main website, and simplify the scale of integration with our ticketing system. And for our users, this way of working enables our organization to ship new features and user experience improvements quicker, allowing us to try out new ideas and quickly respond to feedback.

A potential downside is that we now take on responsibility for the product as a whole, which involves an increase in technical and organizational debt (ACMI must have staff with knowledge on how to maintain the software). We have partly mitigated these risks by limiting the scope of the product, and by depending on the Tessitura APIs for most ticketing logic.

Ticketing is complicated and difficult to work with, often requiring specialized skills and sometimes esoteric systems (Ravanas, 2007). Our hope is that we can encourage other organizations to try building things internally too, leveraging the skills and knowledge their staff already possess, so that as cultural organizations, we can take a more active role in the development and shaping of the ways in which people engage with us online.

Mia

Mia has achieved its MVP goals, and now turns its attention to strengthening integration points and planning for future feature sets. While there are any number of potential futures for Hive, the options we’ve considered most seriously include the following:

• Build a more complete content management system interface so that non-technical staff are able to create, modify and remove products, including custom discount rules for each product;
• Refactoring the Hive interface and making changes to the data that is being sent to Salesforce, based on what we’ve learned to-date;
• A stand alone Salesforce Application that could be packaged along with Hive as an offer to other institutions that are using Salesforce, or to integrate with their own API;
• Expansion of Hive as point of sale for retail, e-commerce, and food and beverage sales;
• Developing a version of Hive that is further abstracted from Salesforce CRM, and could be released as Open Source. Such a version might also include a more customizable front-end.

Conclusions

It comes as no surprise, but both ACMI and Mia have definitely confirmed that ticketing systems are hard!

Existing third-party ticketing systems work, but with numerous caveats; we recommend that you assess them carefully and make your decision based on a realistic view of what you require, what you can live with, and what headaches you will be dealing with along the way.

If you’ve got the necessary skills in-house, consider taking the risk of adopting Hive (or a similar approach) in order to maximize transparency, have full control over the ticketing transaction system, and be able to illuminate all system functions.

If your organization is adopting a third-party ticketing system, we recommend that you make use of system APIs in order to keep customer interfaces on-brand and easy to use, and to abstract functionality from any proprietary system. These approaches allow for brand-alignment and also help future-proof the organization’s technology (should any of the systems need to be swapped out in the future). We recognize that the skill set needed for APIs development work may not exist on every organization’s staff, which may limit the extent of this approach.

Finally, to the extent that you are able, avoid significant customizations that are built for you by vendors or consultants—these are notoriously hard to maintain over time, and carry a risk of additional expenses in the future (particularly when the software undergoes a version upgrade).

To learn more

The following online resources and repositories will assist the reader in learning more about both projects and accessing code bases and other technical information:

ACMI Labs:

• https://labs.acmi.net.au/
• https://github.com/acmilabs/
• https://twitter.com/acmilabs/

Mia shares open source code and data from a variety of projects:

• https://github.com/artsmia

To learn more about Mia’s adoption of Agile with Scrum:

• https://mw2016.museumsandtheweb.com/paper/the-agile-museum/

Acknowledgements

The authors from Mia would like to thank the following for their support and guidance throughout the development of Hive:

• The CRM Project Core Team: Meaghan Tongen, Dianne Kramer, Eric Bruce, Jamie Van Nostrand, Shonnah Hughes, Misty Havens, Stefni Bell
• The CRM Project Steering Committee: Juliane Amendola, Kris Davidson, Kristin Prestegaard, Douglas Hegley
• CRM data migration expertise provided by Steve Scidmore
• Membership and fund-raising detail experts: Ernesto De Quesada, Leanna Wiedman
• Visitor Experience expertise: Steven Lang, Jesús Aguilar, Shawna Lee, Sara Low
• Salesforce Customization and Development Support: Ashima Saigal, Bhanu Tanaka, and Gabriel Viera (Database Sherpa)
• Hive Development Support: Morgan Catlin, Justin Gamble, and Narsimha Aligireddy (Valtira)

The author from ACMI would like to thank Lucie Paterson, Seb Chan, and the ACMI executive team for their leadership and willingness to take the risk of experimenting with building software in house. Aaron Straup Cope provided invaluable advice on using Flask and micro-frameworks as middleware, and we are indebted to Micah Walter for sharing his code with the Tessitura community and demonstrating that a lean and simple transaction process would be possible. Finally, thank you to staff members from across the organization: Britt, Ronan, Jerry, Sujit, Paul and Ben, and former ticketing colleagues Prue and Nicholas for their insights into ticketing needs and idiosyncrasies.

References

Beck, K. & C. Andres. (2004). “Testing: Early, Often, and Automated.” In Extreme Programming Explained: Embrace Change, Second Edition. Addison-Wesley Professional.

Beck, K., et al. (2001). Manifesto For Agile Software Development. Consulted January 22, 2018. Available http://agilemanifesto.org/

Green, I. (2015) “Help users checkout faster with Autofill.” Published June, 2015. Consulted January 10, 2018. Available https://developers.google.com/web/updates/2015/06/checkout-faster-with-autofill

Hawlk, K. (2017). “Reduce Buying Friction With These Online Checkout Features.” Published April 19, 2017. Consulted January 10, 2018. Available https://www.shopify.com/retail/reduce-buying-friction-with-these-online-checkout-features

Maeda, J. (2018). “Open Source Is Commonsense.” Published January 14, 2018. Consulted January 15, 2018. Available https://maeda.pm/2018/01/14/open-source-is-commonsense/

Mann, A. (2017). “Cultural organisations: how much should you spend on your website? It depends, but probably more than you are.” Published October 11, 2017. Consulted, January 10, 2018. Available https://medium.com/@ashmann/cultural-organisations-how-much-should-you-spend-on-your-website-c0feb8076ae

Mantle, M. & R. Lichty. (2012). Managing the Unmanageable: Rules, Tools, and Insights for Managing Software People and Teams. Addison-Wesley Professional.

Pan, D. & M. Engineer. (2015). “The 360-Degree View: Why an Integrated CRM Platform Is Important in Growing a Museum’s Membership Program.” MWA2015: Museums and the Web Asia 2015. Published August 21, 2015. Consulted September 22, 2017. Available http://mwa2015.museumsandtheweb.com/paper/the-360-degree-view-why-an-integrated-crm-platform-is-important-in-growing-a-museums-membership-program/

Pan, D., M. Engineer & R. Cherry. “Enabling mobile point of sale for museum staff.” MW2016: Museums and the Web 2016. Published January 29, 2016. Consulted September 22, 2017. Available http://mw2016.museumsandtheweb.com/paper/enabling-mobile-point-of-sale-for-museum-staff/

Paterson, L. (2017) “Transforming a museum through product management.” MW17: MW 2017. Published February 1, 2017. Consulted January 10, 2018. Available https://mw17.mwconf.org/paper/transforming-a-museum-through-product-management/

Ravanas, P. (2007). “A quiet revolution: the Metropolitan Opera Reinvents Client Relations Management.” In International Journal of Arts Management. Vol 9. HEC – Montreal – Chair of Arts Management, 78-87. Available https://www.jstor.org/stable/41064943

Ronacher, A. “Opening The Flask.” Published June 14, 2010. Consulted January 10, 2018. Available http://lucumr.pocoo.org/2010/6/14/opening-the-flask/

Serong, A. “Museum Nice and Simple Ticketing — front-ending Tessitura.” Published September 21, 2017. Consulted September 26, 2017. Available https://labs.acmi.net.au/museum-nice-and-simple-ticketing-front-ending-tessitura-7fa491292eee

Walter, M. “Our new ticketing website.” Published December 16, 2014. Consulted September 27, 2017. Available https://labs.cooperhewitt.org/2014/our-new-ticketing-website/

Winesmith, K. (2013). “Open systems, loosely coupled: Creating an integrated museum eCommerce system for the MCA.” In Museums and the Web 2013, N. Proctor & R. Cherry (eds). Silver Spring, MD: Museums and the Web. Published January 31, 2013. Consulted September 22, 2017. Available http://mw2013.museumsandtheweb.com/paper/open-systems-loosely-coupled-creating-an-integrated-museum-ecommerce-system-for-the-mca/