Journal

The Bridge: pushing the boundaries

We work solely in the arts, culture and heritage sectors. Our clients include a number of theatres. Last year we were approached by the team behind The Bridge Theatre, the new theatre being set up by Nicholas Hytner and Nick Starr. This was very exciting (it still is).

When Andrew (General Manager) at The Bridge first approached us about the project it was obvious they already had very clear ideas around where they wanted to spend their time in terms of their website (indeed, I’ve just dug out his original email to us which said “having both time and the luxury of being able to start from scratch has meant that we’ve done a lot of thinking!” – and they definitely had).

The problem to solve

Individual productions at The Bridge may run for around 12 weeks, meaning potentially up to 100 performances of each being presented. Against that background, the team at The Bridge had identified that they wanted to make it easy for people to narrow down this long list of performance dates/times to identify specific performances that had availability matching the users’ criteria, whether that was around price, number of tickets, access needs, date or the type of performance (e.g. matinee).

The challenge was less around presenting a particularly large or diverse programme or representing lots of content related to outreach, fundraising or labyrinthine membership schemes, more around how to make it quick and easy for users to get straight to a performance that had the tickets they wanted.

Andrew Leveson, General Manager – The Bridge Theatre:

One of the most exciting aspects of shaping The Bridge has been the ability to step back and take a fresh look at the audience experience as a whole – from the relationship between stage and auditorium to the ease of getting a drink at the interval and the number of ladies’ loos.  The website was always critical to this – it’s most likely the first point of contact our customers will have with us and a vital opportunity to establish our brand.  How fantastic would it be, we thought, to aim for an easy, intuitive and (as much as possible) customer-joyful purchase experience?  Of course, there are always challenges and time and budget have meant we still have a long list of thoughts, instincts and ideas which we can develop as we launch, build and audience and see how customers respond to using the site – but we’re thrilled with where Substrakt’s resourcefulness and the great collaboration with Spektrix has led us.

If you look at the analytics of any ticket-selling site you will frequently see users bounce between lists of performance dates and select-your-own-seat screens in a vain attempt to find the tickets that match their criteria (whether that’s around number of seats, specific seats in the house or seats at a particular price) – if anyone reading this tried to book tickets for Hamilton recently (or indeed, any popular show) you’ll know how frustrating this can be.

We wanted to reduce this as much as possible so we put the user in a situation where they were always presented with relevant options and enough information so that they were moving forward through the purchase pathway as seamlessly as possible (rather than, for example, having to check the seatmaps of multiple performances before they found the seats they wanted).

Throughout the project, the team at The Bridge have been keen to make the most of their fairly unique position of starting a new theatre company from scratch. Their approach was free of assumptions which means we have had the freedom to achieve something unencumbered by the need to slot into pre-existing processes. They have also been constantly looking, with an enjoyably ruthless eye, at best practice across the board, not just within the arts sector. This has lead to more-or-less doing away with a traditional ‘what’s on’ feature and replacing it with what, for  want of a better name, we have been referring to as the ‘performance picker’.

‘The performance picker’

The approach we have taken to enabling the user to narrow down the extensive list of 300+ performances is inspired by, and applies to a theatre ticketing context, the approach of e-commerce sites such as ASOS and Virgin America (i.e. sites in which the user is confronted either with long product lists and numerous ways of filtering this down or forced to make a choice before they are shown any results).

Through audience research, user testing, sector research and the development of personae, we have identified that audience user needs typically begin from either date, price or programme (or a combination thereof).

We have aimed to make moving through the process as clear and unambiguous as possible. By stripping back the options available to the user at each stage and asking them to make their choices (related to those user needs outlined above) in what (we hope) is a logical order, we have simplified what can be quite an overwhelming number of options. We have aimed to strike a balance between the number of filter options available to be really specific with your requirements whilst not demanding the user makes 100 decisions before they’re shown any results.

Integrating with Spektrix

None of this would have been possible without a flexible and semantic API with which to integrate. Fortunately, v3 of Spektrix’s API is just that. As with all the sites we build, we have looked to reduce administrative effort wherever possible. What this means is data managed within Spektrix then automatically updates the site (changing event dates, times, prices, access performances, previews, etc).

When building the picker we have taken an approach of mixing regular API calls (around price, availability, start times etc) with less frequent calls (concerned with venue, seat positioning, contiguity of seats etc) to build an easily-queryable data structure in the website’s database. This approach means we can ensure the front-end performance of the picker is as swift as possible (without tying Spektrix up with tens of realtime API calls every time a user uses the picker) whilst ensuring the data being displayed to the user is always as up-to-date as possible.

Whilst v3 is still in beta we’ve been fortunate to be able to forge a strong collaborative relationship with the team at Spektrix from the outset. We have also enjoyed the benefit of input from Michael Nabarro, Spektrix’s CEO:

This has been a great opportunity for us all to put our heads together to figure out how the combination of an inspiring vision, a great web design team and a powerful backend system can all come together to deliver a really exciting online audience experience.

What’s next?

There has been a lot of fairly complex work to get to this point. The things we have been trying to achieve and the way in which we’ve been working with Spektrix are both totally new – we don’t think anyone has has attempted any of this in this way before. But we’re really proud with where we’ve reached and are excited about the possibility of developing the system further. Both Substrakt and the team at The Bridge see the initial go-live as v1 of this approach which we will be looking to develop and refine as people use it and we have insights into user behaviour that we can use to inform future iterations.

Pauline Fallowell, The Bridge’s Head of Sales and Audience Insight commented:

We know technology evolves constantly, as does the way people use it.  Therefore, we don’t want a site that is out of date as soon as it goes live, we want something that keeps developing in response to the people that use it, and is always looking to improve their experience.  Working on this project we are constantly learning and being inspired by opportunities that can enhance our site, however, we try to keep grounded by first and foremost making it be great at doing the most important thing it needs to do – sell tickets.

More and more of the organisations we work with are taking this longer-term, more considered and more strategic approach to their web projects. Rather than seeing the go-live date as the end of the project, we all now see it as the chance to begin tweaking the site based on real user feedback. Ultimately this informed, iterative approach means that your website is constantly evolving and responding based on your users’ needs which means it will be both more effective, and ‘last’ longer. We hope we are seeing the end of the ‘launch it then forget it for 3-5 years then start from scratch’ which dominated the sector for so many years.

This has been a brilliant project to work on. We work solely in the arts sector just because of projects like this. Interesting, ambitious work, with fantastic people. If you are interested in talking to us about a similar project, or simply to find out more about our approach to this project then drop us an email at team@substrakt.com.

My talk at Ticketing Professionals - APIs

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!

One month in...

Had you told me 3 months ago that I would be working for a digital agency, I would have laughed you all the way to the nearest cat cafe. Although, if you told me 6 years ago that I would spend the next 5 and a bit years working for a ticketing company, I would have laughed in your face then too.

I have only ever chosen to work at places where I feel a strong passion for the people and what they are striving to do. This was certainly true at Spektrix and one month in, I can say this is also true at Substrakt.

So why had I have never thought to work for a digital agency before and why Substrakt? If I’m honest, my own experiences of web projects and time spent supporting clients navigating often toxic agency relationships resulted in a wariness of digital agencies. Overly technical explanations, a level of “digital arrogance” and, in the male dominated world of tech, all too often a faint whiff of misogyny… (I won’t tell you how many times a developer had asked to be transferred to “one of your technical guys”, when they had failed to follow my instructions for filtering iframes).

Working with agencies was therefore never a favourite pastime…. Mistrust of web agencies seems a little endemic in the arts in my experience, it’s certainly something that featured high on the list of concerns for clients attending our first Digital Works sessions.

So why Substrakt? I certainly wasn’t job hunting at agencies, or seriously job hunting. The opportunity to work at Substrakt was a bit of a curveball and if I’m totally honest, I took a punt. In helping them spread the word of their new Head of Client Services role, I found myself drawing a number of parallels with the approach to client relationships at Spektrix. Both have a clear aim to do it differently. For Substrakt it is to work in a sector on projects they enjoy, to take away the shroud of mystery when it comes to pricing and to deliver work in agile sprints – involving the client at regular intervals in open and honest discussion, in plain English.

A move to Substrakt provided the perfect trade-off of; bringing a wealth of previous experience, of the sector itself, of ticketing technology and of developing meaningful, collaborative client relationships, whilst learning more about a hitherto unknown of digital and web development.

My career to date (minus facepainter, bouncy castle designer and cat sitter) has focused on data-driven marketing, audience development, segmentation and email strategy. In the broader sense of arts marketing; digital and web projects are something I have less experience of. However, I’m still occupying that space between the client and the technical team (henceforth affectionately known as The Nerds) –  translating PHP, Rails or C# into artspeak and vice versa. Whilst also still getting to keep a toe dipped into Spektrix developments via a number of shared clients. Triple win.

This first month has been spent meeting and getting to know our existing clients and their various projects. Feeding into pitches and new projects and sharing my knowledge of the sector with the rest of the team. Clients thus far have commented how much they enjoy the direct relationships they build with the developers working on their projects – I’m not there to replace that, but I am there to ensure that Substrakt remains empathetic to the sector that they have chosen to work with. Championing the voice of the client and providing a critical understanding of the challenges and idiosyncrasies that make the sector such an exciting one to support.

Substrakt’s firm belief that the working partnership should be just that, a partnership, is right up my street. It’s an opportunity to get to know the organisation inside and out, pulling in the right people at the right time to produce something we’re both really proud of. It’s exactly how I like to work. Rather than seeing website projects as a standalone piece of work we see them as a constantly evolving, developing piece that can respond and adapt not only to internal changes but to the rapidly changing pace of technology.

This is certainly an approach that will benefit the sector, and really what it’s crying out for. A lot has been written of late about the sector falling behind in the adoption of new technology. Due to a mixture of attitude, lack of funds and digital skill, specifically at senior or board level, it unsurprising that this is the result. However, working in partnership with digital agencies and experts, there’s no reason that digital expertise can’t become more widespread across the sector. It’s certainly happening in pockets, so I hope I can go some way in helping Substrakt, and our clients, to make it our norm.

1 2 3 4 5 18