Distrakt
+44 (0) 121 212 9737 / team@substrakt.com
© 2017 Substrakt Registered in England. Company no. 5916054

My talk at Ticketing Professionals – APIs

March 17, 2017

I gave a talk at this year’s Ticketing Professionals conference – which advertises itself as “The Place Where Professionals Talk Ticketing”. It was rather vaguely titled ‘The API – what next for our 3 favourite letters?’ which gave me a pleasingly large target to aim at. This post is a write-up of that talk, it is not exactly the same as the talk (this approach is inspired, in part, by this GDS post).

This post is pretty long, so the tl;dr version is: APIs are how software applications talk to each other, they are pretty essential for how most things on the internet work. In relation to ticketing systems APIs have historically been used extensively (which is expensive and difficult) or not at all (which has resulted in a sub-par user experience). We (Substrakt) have seen success by adopting a ‘hybrid’ approach which utilises both API integrations and ticketing web products to deliver an improved user experience. You should expect your ticketing system to be a part of your digital makeup, it will never be the only part and in order to reap the benefits of joined-up thinking, some API work will be necessary. Ticketing APIs are imperfect because they are frequently inconsistent or undocumented which makes them difficult to utilise efficiently. Use the data in your ticketing system as the hub of your understanding of your audience(s) but look to augment and enhance that data with insights from other touchpoints, and also be looking to see how the data in your ticketing system can be used to drive other parts of your business, some API work may be needed in order to enable this. Cultural web experience should be better, they can be better, let’s make them better.


This talk (/post) is going to look at APIs, what they are, how they’re used and how – I think – cultural organisations could be making better use of them (and the challenges that this may present).

As user/customer expectations around their online experience continue to grow, and you all know more and more about your audiences and what those expectations are I believe that understanding the potential of APIs will allow you to keep up with your audiences’ needs and develop appropriate, sophisticated and meaningful web experiences. The days of developing entirely bespoke systems are over, however all modern software has (or should have – we’ll come onto that later) powerful and usable APIs that allow you to utilise, extend and enhance the data and functionality within them for your specific needs.

HOWEVER the systems that many organisations use, particularly within the cultural sector, don’t really seem to treat their APIs in the way that modern software companies should nor do many organisations seem particularly aware of or interested in the potential uses of APIs. And This Is A Problem.

OK, that all sounds great (or worrying), but, let’s start at the beginning….

API. WTF. LOL. (aka What is an API)

You may all already know what an API is – but for those who don’t; API stands for Application Programming Interface.

WTF, as Phil in Modern Family points out, stands for Why The Face. You’re welcome.

APIs are how software applications talk to each other. I’m not going to go into too much detail the ins and outs of how they work but they basically let software applications expose data and services in a structured way to other software applications.

There are loads of quite unhelpful comparisons that try to explain what an API is and how it works. I’ve seen them compared to menus, dictionaries and rulebooks. This, in part is because there are lots of different ways of delivering and consuming an API. I figured I’d add another one to the mix:

Think of an API as both a phone system and a set of rules on how to use the phone system. You want to call Jane to find out if she’s free on Saturday; you need to know what Jane’s phone-number is, how to dial that number into the phone and what to say when Jane answers. This is a rather tortured comparison, but APIs work in a similar way; if one application wants to get data or functionality into, or out of, another application this will typically be achieved via the relevant API.

This article tries to ‘explain it to you like you’re 5’ (and does a fairly terrible job of achieving that aim) but may be helpful in getting your head around some of the different levels of API (public, private, etc). It uses a full-on restaurant analogy.

It’s worth mentioning NOW (cue a rush to the exits) that everything I am going to cover from here on will be the use of APIs to deliver data/functionality via website(s). I am not going to be talking about the use of APIs to deliver functionality such as the agency mode in Spektrix or the stuff that Ingresso does or whatever (although they are all achieved via the same process, an API integration, and an API is like a phone system, or a menu, or a dictionary…ok? cool).

APIs in practice

OK, so, an API is how software applications talk to each other. But what does that mean? And why should you all care?

Most of the modern internet is powered by APIs.

APIs power every app on your phone, every programme on your computer.

They are “a big deal”.

If you have ever bought anything online, read an email, used social media, watched Netflix – you have benefited from an API.

In this section I could talk about almost any modern digital service and that would be an example of, often many, APIs at work.

But simply waving my arms to encompass ‘all of the internet’ probably isn’t that helpful. So I’m going to look at a specific example:

  • Twitter

A quick search on the app store tells me that there are lots of (more than 140) Twitter apps, every single one of these makes use of Twitter’s API (and a bunch of others but we’re just looking at Twitter here).

Let’s consider a basic Twitter app. At a minimum it’ll want to allow you to login to your account, read tweets, compose tweets, send tweets, reply to tweets. It’ll probably also enable you to search Twitter (in a variety of ways), do things with DMs, Images, Video, Emojis and whatnot. But we’re just considering the absolute basic functionality.

This app only works because of the Twitter API. The Twitter API has a documented and defined way of enabling people to ask for the data and services you need to do things you want your app to do. It also has documented and defined ways for your app to instruct Twitter to perform certain actions (e.g. post a tweet, or whatever). A good API operates in a predictable, documented and consistent way.

OK, I’ve probably laboured this point enough. Are we all vaguely clear on what an API is, and roughly how they might be useful and used? Yes? Excellent.

Arts context

All well and good but WHY SHOULD WE CARE, ASH. WHY SHOULD WE CARE.

Good question.

You should care because, much like many digital things in the arts, the solutions that are available probably aren’t entirely appropriate for your particular needs.

I mean, sure, they’ll do 80% of what you need but in having to be all things to all (cultural) people it is inevitable that there will be features that don’t quite meet your requirements.

It is also the reality that the makeup of almost any organisation’s digital estate will involve multiple systems, the end user doesn’t know or care about this, and to present them with anything other than a seamless experience is going to result in a loss of effectiveness and, plainly, people getting annoyed. Whether that’s around seat maps, integration between ticketing and other e-commerce systems, personalisation of content, being able to upsell at various points in the user journey (not just within the purchase pathway) or whatever, you need to be able to build the ‘joins’ and, inevitably, this will require – you guessed it – APIs.

Sidenote: I’ll be focusing mostly on ‘commercial’ applications of APIs, there are numerous other things the can be used for but as this is a ticketing conference I thought I’d focus on ticketing and stuff. It seems museums have been having this conversation for longer than the performing arts and I think that’s mainly because collections are big catalogues that are relatively easy to make API-able – The Rijksmuseum have taken this approach which has allowed them, and other people to build products and experiences ‘on top’ of their APIs. The V&A also have an API which they’re apparently in the process of upgrading (I suspect as part of the wider web project).

In the recent past ticketing websites’ usage of APIs was usually either non-existent or very involved, in the absence of any particularly sophisticated web products organisations would look to a ‘fully integrated’ approach in which an entirely bespoke purchase pathway would be built drawing on the ticketing system’s API.

This was a complex, costly, high-maintenance and relatively ‘brittle’ approach although it did allow the organisations who followed this approach to be specific in how they built the user experience, however it also meant they had to do boring things like build their own payment processing gateways which is *difficult* and *boring*.

It also, in my observation didn’t necessarily result in a much better user experience, even though it frequently cost an order of magnitude more than the off-the-shelf product. But some people just seem to like spending lots of money on things. Maybe it’s ‘a brand thing’.

This, in my experience, is pretty representative of most people’s approach to their online user experience. You’ve got a website. You can sell tickets. You’re taking money. It’s fine, everything is fine.

Actually EVERYTHING IS PROBABLY NOT FINE

It is the reality that the makeup of almost any organisation’s digital estate will or SHOULD involve multiple systems, no one system can do everything and anyone that claims that isn’t the case is a liar. However the end user doesn’t know or care about this, and to present them with anything other than a seamless experience is going to result in a loss of effectiveness and, plainly, people getting annoyed.

Whether that’s around seat maps, integration between ticketing and other e-commerce, booking on their phone, personalisation of content, being able to upsell at various points in the user journey (not just within the purchase pathway) or whatever, you need to be able to build the ‘joins’ and, inevitably, this will require – you guessed it – APIs.

But didn’t I just say that bespoke API-based development was expensive and dumb? I did. And I’m not naive, I know the UK cultural sector is time, expertise and cash poor. You want solutions that are straightforward to implement, deliver and maintain. A first step will be a hybrid approach, let the various systems each do what they’re good at. Your ticketing system will (probably) be good at letting someone pick a ticket and taking their money. So let it do that and lean on something, or someTHINGS else to deliver the rest of the user experience.

Let’s reconsider the Twitter app I outlined earlier, it is not attempting to replicate Twitter, it’s not trying to build a social network, it’s probably trying to make it easier for the user to consume and engage with a social platform through the app.

Similarly I am not saying you want to try and build your own way of taking a customer’s payment but you might want to build your own way of them navigating your event listings, or performance dates, or managing their account, or sharing your event or whatever.

So how might you utilise your ticketing system’s API when you’ve finished reading this post?

  • Reduce/remove duplication of data-entry
  • Doing ‘stuff’ with performance-level attributes
  • Sitewide cross-/up-selling

I hate the phrase low-hanging fruit but THESE ARE ALL LOW-HANGING FRUIT.

Are you having to duplicate event setup? Setting up things in your ticketing system and then again in your website? Are you having to update the same thing in two separate places (like if a start time changes or your pricing changes). If so this is a terrible use of your time.

Do you have some performances which are signed, or audio described, or are previews, or a press night – would you like that to have some effect on how your website displays these particular performances?

Do you have specific cross or upsells set up within your ticketing system? Are you trying to achieve these elsewhere on your site?

All of these can be achieved by accessing your ticketing system’s API and using that data to manipulate the UX on your website.

Return to your constituencies and prepare for government, or ask your web agency to help you achieve all of these. They are all relatively straight-forward, we have achieved them with Tessitura, Spektrix and eSRO (TopTix).

You will notice that all of these things relate to a relatively simple reading-basic-data-out-of-a-system-and-affecting-the-ui-of-a-website, and you’re right, this is simple stuff.

What’s next?

OK, I’ve got about halfway through my talk (/post) and I’ve not really talked about what’s next, what’s exciting. What innovative-change-making-nonsense you could consider.

I’d say, broadly, the web products that are on offer are good enough for most organisations to consider. They offer enough flexibility and customisability (is this a word? probably not) that it probably isn’t a good use of anyone’s time and money to go ‘fully custom’ these days. They allow you to sell a ticket. Trouble is, they’re not brilliant at much beyond this. But maybe that’s fine, in fact, it probably is. We should maybe tell them to stop trying.

Having a single customer record is absolutely the best way to approach managing your customer data, but as a result of this your CRM needs to be actually able to M the C R (manage the customer relationship). Buying a ticket will not be your audience’s only touchpoint with your organisation and any insights you are looking to gain into your customer data are only going to be enhanced by building a more rounded picture of what’s going on. The best way to do this? Probably via an API. (I mean, in reality it’ll probably be with another solution that integrates with the CRM’s API but the point stands).

Your ticketing system should also play nicely with any other business tools you may be using which could include; dashboards, full-spectrum/multi-channel analytics, 3rd party segmentation tools, 3rd party ticketing platforms.

That all sounds very nice and neat and whatnot but it’s always helpful if there are real examples to point to. To this end it’s certainly worth looking at Salesforce – Salesforce, amongst other things, is a giant, enterprise-level CRM system. Their API (or rather, APIs) enable an entire ecosystem of apps and custom integrations to be created that utilise and extend the data and functionality available natively within Salesforce, this allows organisations to utilise Salesforce as the data engine that drives numerous other parts of their business. Ticketing systems try to achieve this too but often it is by trying to develop and offer functionality natively within the system rather than recognising that there’s probably something out there that does it better and enabling that other system (whatever it may be) to integrate in a straight-forward manner.

But what else might be worth considering? People have been talking about digital memberships for years (I seem to remember the Barbican either launched one or merely talked about launching one in a brief I saw from about 10 years ago). Kevin from Tessitura mentioned the work the Detroit Symphony does around engaging with new audiences and monetising their digital content. APIs are essential in building an engaging online platform through which people can consume whatever it is you’re going to sell them (content, experiences, whatever) and you can get the money and data and shove it back into your ticketing system. Does this mean your ticketing system should offer the ability to paywall content? ABSOLUTELY NOT, THAT IS MENTAL.

The future of the web is in massively scaleable and extensible systems talking to each other to deliver a consistent user experience across all devices. You are already seeing low-level automation with tools like IFTTT and Zapier which integrate with an ever-growing range of systems to automate tools, there’s no technical reason why this shouldn’t be possible with ticketing systems. The sheer volume of day-to-day work that could and should be automated is likely to be, if you think about it, staggering. How much more effective, strategic and measured could you be if you could automate all of those fiddly things that you have to do every day, week, or month. Whilst you’ll never be able to automate strategic thinking I’d urge you to consider how some level of automation may help you on an operational level. Automation saves me from becoming totally overwhelmed and going mad, I suggest you try it.

What else? The next way that users will want to interact with your digital presence is probably via chatbots, inevitably ticketing systems are going to be slow off the mark with presenting this functionality natively so I imagine ambitious organisations will want to experiment with some of the open chatbot libraries that are already available to help with the natural language processing (thanks Google and Amazon!) alongside an integration with their ticketing/CRM system’s API.

This is usually the point at which someone will say “what about an app?” and I will go “yes, like an app BUT DEFINITELY NOT AN APP LIKE YOU’RE IMAGINING IT”.

Why?

Silicon Valley analyst Andrew Chen attests that the average app loses 77 percent of its users in the three days after they install it. After a month, 90 percent of users eventually stop using the app, and by the 90-day mark, only 5 percent of users continue using a given app.

HOWEVER I do believe there is going to be a growth in ‘customer service-focused apps’ which will allow things like in-venue-patron-management e.g. your development team can see at a glance which patrons are in attendance alongside some sense of their customer history (I believe the Royal Danish Theatre have embarked on something along these lines, I saw a bit of a talk at last year’s Ticketing Professionals conference that showcased it) – this will also enable front-of-house staff the chance to offer a more personalised service, could enable you to give patrons with access needs a more tailored service, could allow the deployment of more appropriate/reactive/sensitive in-venue marketing (via screens and whatnot).

Basically if you want to make your theatre like the shopping mall in Minority Report (and why wouldn’t you!?), that will happen via an API (or APIs) – obviously you don’t want to do that, I’m being hyperbolic to make a point.

We hear a lot at these conferences that your business needs to be driven forwards by reacting to your audience needs/expectations/etc – the smartest, most measurable, most connected way of doing this is going to be in integrating disparate systems (through, you guessed it, an API) so that they deliver both a joined-up and meaningful customer experience but also an actionable and useful level of insight.

What are the issues?

So, if the future of the web is in massively scaleable and extensible systems talking to each other to deliver a consistent user experience across all platforms and devices. Are ticketing systems ready for this? Right now? Probably not.

I can sort of understand why this might be the case, at the moment there probably aren’t loads of customers clamouring for this.

Are web developers part of the conversation about how the APIs of the future will be built? They may be, but based on a small straw poll I ran last week these conversations doesn’t involve anyone I am aware of or in touch with. And I basically only hang out with web developers. Because I’m cool.

In relation to the actual APIs that are available in the sector: one word sums up the difficulties. Ok, actually, two words:

  • inconsistency
  • undocumented

A good API behaves, as I said earlier in a consistent, structured and documented way. The vast majority of the APIs available in the arts sector do some of these things but rarely do they do all of them. 

Some of this seems to be down to the way that the systems in question are set up – rarely are two ticketing systems ever implemented in the same way and this lack of consistency feeds through to the API. But beyond these explicable symptoms it seems there is a total lack of interest in and understanding of how anyone might ever use an API, more and more (all?) ticketing systems are selling themselves on the ‘single customer record’ thing and if you want to be the master record for customer data then you’re going to have to play nicely with other systems.

Ticketing systems are software products, most other software product have an extensively documented public API that will usually – by now – be a nice RESTful product for us to play with.

Most ticketing systems do not. Granted there are moves in that direction but these will mostly be incomplete until next year…or the year after.

Most ticketing system APIs are constructed in a slightly unhelpful way, there are essentially a bunch of endpoints that allow you to go into the system, as it is configured for the organisation, and request data that conforms to those structures. No thought seems to have been given to the structure of the API, what makes sense internally for an organisation will rarely make any sense to anyone else. An example:

To get the venue name in a system we work with regularly, we have to make three API calls (3!). One to get the production, here there is the seating plan ID. Using the seating plan ID, we make a call to the plan endpoint. This returns the venue ID, and then finally we can call the venue endpoint to get the name of the venue.

This will almost certainly have been constructed this way to deliver native functionality such as reporting or because of some other totally valid reason but you can see that it is not an efficient way to expose this data to any external developers wanting to make use of it. This is not the worst example in the world but gives you a sense of the spaghetti we’re frequently trying to untangle. Oh and most of the calls I mention there were undocumented.

As I said earlier, ticketing systems are usually good at enabling ticket purchasing, they are usually very very bad at the other things you might want to offer online.

Fortunately there seems to be a move away from offering every service under the sun, a recognition that there are other specialist products out there that offer a better <insert service here> experience than a multi-functional ticketing/crm system ever could – this is a good thing . (I assume) Ticketing probably drives most of your revenue at the moment but with an ongoing squeeze on funding organisations are having to ever-increase their revenue from other sources, whether that’s through donations, memberships, shops, commercial hire or whatever – the systems that achieve these growing revenue streams need to be able to integrate with your ‘main’ crm system (cos otherwise you get yucky fragmentation that makes everyone sad). An example of the potential issues is that lots of e-commerce systems will also demand that they are the CRM. How do you solve this? Through an API integration. Will that be possible with every ticketing system’s API? Truth be told, I couldn’t tell you.

A conclusion

As is perhaps becoming clear, this topic is almost impossibly large to cover in one go (without this turning into the longest post/talk ever). So, what are my main conclusions (for today at least)?:

  • Ticketing system providers need to step up their efforts to get up to speed with what they offer when it comes to the web. Too often their approach will begin and end with their web product which, whilst perhaps understandable from a business point of view, also dangerously underestimates or misunderstands just how far the ticketing ecommerce experience is from the ‘best-in-class’ experiences out there. Through being able to offer proper APIs system providers make it possible for developers to build appropriate solutions for organisations.
  • I would encourage ticketing system suppliers to work WITH developers and agencies to identify where their strengths and weaknesses are and do more of the stuff they’re good at and less of the stuff they are frankly terrible at. The fact that it is 2017 and most of the major systems’ web products still haven’t really figured out how to deliver an optimal mobile experience is frankly ridiculous.
  • Your ticketing/CRM system is an important system, however I believe that it will not be the only important system. The broader trend is towards a proliferation of focused, specialist services (and microservices), rather than monoliths that try to do everything. In order to be able to make the most of this you need to be aware of the potential around integration and have at least a broad idea of how it might happen – which will be via an API.
  • Think about where you can improve the user experience, and understand where you can’t. Some things are just really really difficult. Seat maps are pretty hard. Taking payments is pretty hard. Multi-faceted search is quite tricky. We’ve heard a lot over the past two days about measuring things, gaining insights, and then actioning those insights. But the harsh reality is there will just be some things that you can’t change, your system provider is going to shrug and say not enough people are asking for that feature, or it’s coming in some mystical future release with a delivery date of the 40th of nevember (this joke works better written down). Work out where that’s a battle that you just need to give up on, and where there are opportunities for you to forge your own path. I’d love to see more partnership working between cultural organisations and agencies, or even better still between cultural organisations, ticketing systems and agencies, or even better still between groups of cultural organisations, ticketing systems and agencies. You get the point. We are luckily enough to be working on a couple of projects at the moment which are taking this approach and these are, undoubtedly, where we are doing our best work. The ticketing system freely admits there are areas in which they are lacking, and we are working with them and the client to deliver a vastly improved user experience. Sorry, I know that’s a bit vague but one of them is going live next month and involves Nick Starr so watch out for that.

So what do I hope you take away from this talk? I’d encourage you to think about how you can use the data in your ticketing system to drive other areas of your business. Don’t be constrained by the limitations or functionality inherent in your system, just think about what use you can put your data to. Then see if there are systems that can help achieve that end goal, then work backwards and see if the two systems can be knitted together – via their respective APIs – rather than through trying to go out and totally reinvent the wheel, ain’t nobody got time for that.

Secondly I would ask you to encourage the ticketing system providers to get a move on with modernising their APIs. And documenting them. That I can receive 3 different sets of  documentation from a supplier (incomplete in different ways) for apparently the same version of an API is stupid. Stop it.

Thirdly I would encourage you to take a long, hard look at the web products available to you from your supplier, compare them to other ecommerce experiences and work out where the flaws are. It may be that there gaps that some sensible custom work can fill. It’s almost certain that there are. I think the immediate future will be in these hybrid systems that use native functionality for the heavy lifting and deliver something bespoke to enhance the custom experience.

Fourthly, talk to your colleagues, lots of people struggle with the same issues and there may be benefits in a joined-up approach to solving some of these problems. A problem shared and all that…

Finally, and this may not relate to ticketing system APIs in any way, but give automating some of your workflow a go, it’s a godsend.

Thanks!

Ash Mann