How to supercharge your event pages with strategy, automation, and a slightly terrifying spreadsheet

For example, when we built a new set of event pages for Saffron Hall in 2020, they were a huge improvement, in terms of visual design and buying tickets. But over time, it became clear that some of the secondary content on the page wasn’t working as well as it could. So when Saffron Hall approached us last year with a healthy, dedicated budget, just for improving their event pages, we jumped at the chance to correct some of the things we weren’t able to address the first time round.

Six months later, the fresh event pages have launched with intelligent new features for users, a whole lot of time-saving elements for Saffron Hall admins, and a novel integration with Spektrix for sending pre-show emails.

Along the way, we learned a lot about why it’s so easy for event pages to go wrong, and some of the steps you can take to avoid the most common pitfalls.

As with all our projects, our first step was research. Specifically, we audited all the different types of content that had appeared on Saffron Hall’s event pages since we launched them in 2020 — whether the pages had been specifically designed to accommodate this content or not.

A good example of what we found: sponsor credits. These weren’t part of the original event page designs, because the issue hadn’t come up until after the build was complete. So we’d shoehorned them into the sidebar later, recycling existing functionality to keep costs down. It was a decent bodge — decent enough that Saffron Hall were still including sponsor credits a lot — but it was a bodge nonetheless.

For the new event pages, we were careful to scope out sponsor credits as their own requirement, along with 45 (!) other types of content that had appeared on event pages over the past year. These ranged from the things you might expect, like Spotify embeds and image galleries, to more bespoke or idiosyncratic ones, like whether an event would have a pre-show reception for members, or which street food trucks would be working at the event.

We thought that was already a lot for one page, but then we held a day-long discovery workshop with Saffron Hall and they identified about 20 more (!!). This was because, unlike the initial discovery we did in 2020, the workshop included more than just the digital marketing team: it also included the programming and artistic teams, the executive director, front of house volunteers, and even technical staff. This wouldn’t have been feasible previously (especially not in 2020), but for the event page work we wanted to make sure anyone who had ever had to ask or answer a question about an event was represented.

We also had staff group content items into clusters, like “Artistic content” or “key event info”, and put those clusters in order of importance. Then we put all this insight into one, large, slightly terrifying spreadsheet, along with other key considerations for each piece of content. For example, whether something was relevant to all events or only some, if it was the same for most events or always different, and where the content ultimately came from.

Another important consideration: when was a piece of content typically available relative to the life-cycle of an event? If sponsors aren’t confirmed until weeks after an event has gone on sale, there’s no point designing the event page around their logos, because they won’t exist when we first need them.

Once we had all this information collected in one place, it was much easier to make decisions about design and functionality, because we knew exactly how all the pieces fit together.

Spreadsheet in hand, we finally started on design. This kicked off with some very rudimentary wireframes, dividing the page into logical sections catering to the various different use-cases we’d identified. We felt it was important to divide by use-case, rather than the content clusters staff had identified, because some content logically belonged in more than one place.

Take a relatively simple thing like running time. Ultimately, this comes from the artistic team, because it depends on decisions about what to include in the performance and how to stage it. So it could sit with other programme information.

But running time can also influence your buying decision, because a 3-hour show might mean missing the last train, for example. In that respect, running time needs to sit with other booking information, like price. Then again, the week before the performance, you might want to know the running time so that you can plan exactly which train to get home. Since this can influence your plans for the evening, running time also needs to sit with other visiting information, such as if there will be food available, or when the foyer opens. Finally, to make matters even more complicated, sometimes the running time at on-sale is only a guess (or isn’t known at all), and will change as the performance approaches.

In short, simply adding a line for “running time” to a wireframe would never be sufficient. We needed to acknowledge that running time might reasonably show up in three different places, at different times, for different purposes, and with different values — and we needed to account for that complex reality in the design. And that was only one of the 66 pieces of content the page potentially needed to accommodate!

Normally when we’re designing, we use real content from the current website to make sure the new designs will fit what a client will actually be including on their pages. In this case, we instead designed for a mostly hypothetical event that was as complicated as anything possibly could be — the so-called “edge case”. The resulting design had a scroll depth of almost 10,000 pixels, and helped us test many different combinations of content to ensure the page would work in all scenarios — even if, in most cases, an event page would only be half that long.

Looking at the final designs, it was clear that many types of content would appear on every page, and usually wouldn’t change from event to event. For example, the auditorium at Saffron Hall almost always opens 30 minutes before the performance begins.

This is a potentially useful piece of content to a prospective audience member, but not so useful it would be worth Saffron Hall staff manually typing it in for every single event. Instead, using the information from our trusty spreadsheet, we coded in defaults for common fields like this. Now, staff only need to type something in for outlier events.

Where content only needs to change occasionally, we also hard-coded preset options if appropriate. For example, Saffron Hall’s free shuttle bus service is either running, not running, or replaced by taxis — so a dropdown field where staff can select from these options is far more helpful than a free text override that needs to be typed out each time.

As a result, the new event pages are automatically populated with a wealth of rich, accurate information for visitors, from the moment an event first goes on sale — and Saffron Hall staff don’t need to do anything to make it happen. But they can still easily override defaults or hide specific pieces of content altogether if necessary.

We also introduced smart automation in other ways, even where there aren’t default values to draw from. For example, although Saffron Hall need to manually set age guidance messaging for each show, we built these in the CMS as reusable categories that can be applied over and over again. In other words, once Saffron Hall staff have written their age guidance copy for one 7+ show, adding it to subsequent 7+ shows is a one-click job. The same system also works for many other pieces of content, such as accessibility accommodations (like relaxed performances). Better yet, using categories rather than text strings means that website visitors can also easily filter by these things, to find only the shows suitable for them.

Finally, we built the new event pages so that many of these items can be set not just at the event level, but per performance. This means, for example, that if one performance has the shuttle bus running and BSL interpretation, users can see this clearly by selecting the performance they’re interested in from a dropdown menu. The page then automatically fetches the correct information — no more long tables or paragraphs of text where users have to hunt for the information relevant to them.

Many pieces of event content were already stored in Spektrix, so as part of the event page work we also updated our integration to pull as much as we could from there. For example, we now look at additional custom fields in Spektrix, and use these to automatically set event location and seating style. These are also created in the CMS as categories, so are reusable and filterable in the same way as the other categories Saffron Hall create manually.

The much more important upgrade to our Spektrix integration, however, was around pre-show emails.

Saffron Hall were spending a great deal of time manually creating email templates for their pre-show emails, so that their customers would receive detailed performance-by-performance information about when to arrive, what to expect, and so forth. This was a great service for their customers, but setting up the unique emails took up a lot of staff time, and was largely duplicating information already available on the website.

The ideal solution would be a single pre-show template that included a link to the relevant event page. That way, staff would no longer need to manually create email templates, but customers would still be directed to the same detailed information for the performance they were attending.

However, Spektrix can only push a very limited number of fields into the pre-show emails, and a unique URL per performance was not one of them. Even if that was possible, Saffron Hall staff would still need to add the unique links to Spektrix manually. On the face of things, there was no way to reach their ideal solution.

To solve this problem, we looked at the fields Spektrix can push in: event name, event date, event time, and event day of the week. We realised that combining event date with event time would give us a unique identifier in a consistent format, which we could easily match up with data we already imported to the website. Using this unique identifier, Saffron Hall can create a dynamic link in a single pre-show event template. Our new “visiting soon” service then interprets that dynamic link and redirects users to the detailed visiting information for the correct performance of the correct event page.

Not only does this completely automate the pre-show email process, but it also provides a cleaner experience for users, who now will always be able to find the information they need in exactly the same format and in exactly the same place. Saffron Hall are also using our automated links as part of their separate integration with CrowdEngage, so that users receiving pre-show texts are also able to jump directly to the visiting information for their performance.

Obviously not everyone has the time or budget to pour into a detailed project like this one. But there are a few quick wins to be had for anyone looking to improve their event pages.

1. Remember that event pages are about more than buying tickets. If you have one question that you get asked every day about your events, this should probably be answered on your event pages, and not just in the FAQs.
2. Don’t be afraid to repeat information. Just because you have running time at the top of the page, doesn’t mean it might not be useful somewhere else as well.
   
3. Embrace the power of default values. If you find yourself constantly typing out the same thing on every event page, your web developers can probably just hard-code it for you and save you a lot of time.

And if all else fails, give us a call.