The software supplier marketplace for ticketing, marketing and CRM solutions in the UK is over-crowded, too many suppliers chasing too few customers, and ‘entry-preneurs’ always wanting, they think, to make easy profits out of ticketing.

So it is not surprising that many ticketing system suppliers emphasise their differences and some claim they do business on a different basis. For example, Spektrix have made a virtue of their Cloud-based SaaS model and high levels of customer support; Tessitura champions its not-for-profit co-ownership network; AudienceView the first comprehensive browser-based solution; SROv4 with the first system centred on a powerful Rules Engine to enable huge configurable flexibility; and PatronBase with their unique “not just for profit” low cost but high spec. model. Ben Curthoys and Monad Ticketing is different from all these.

From Backstage to Front-of-House

I am intrigued that Ben Curthoys helps make an argument I feel strongly about: that backstage in venues high standards of systems and training are an absolute requirement of computerised systems, but F-o-H lower standards are allowed to apply, despite being the centre of inter-actions with audiences. Ben is the proprietor and developer of Monad and wants to deliver ticketing, marketing and CRM tools with a different design philosophy, focussed on helping people ‘work smarter’, evolving to meet future needs.

He started out as a backstage techie, doing lighting design for example at the National Student Drama Festival (NSDF) – a shared experience I have – and worked at the C Venue in the Edinburgh Festival Fringe in 1996 where he found the venue was struggling with a poor ticketing system. Of that geeky generation that had started programming as a teenager on a BBC Micro, Ben decided that the challenge of earning a living as a freelance lighting technician was too much (Michael Nabarro at Spektrix still freelances as a lighting designer) so he joined the Artifax development team in Epsom.

Ben clearly feels strongly about the commitment of suppliers to their customers, and praises Artifax for employing people with a practical operational background in the arts and entertainment industry and a “real world sense of urgency” about what people need and the fixes they require. Asked to work for a web-based recruitment company to re-write their technology and expand their team, Ben thought he had found the way to manage delivering success, but “job done” wanted to be back in ticketing. He decided to contact Richard Leggatt at Galathea STS, part of the Seatem Group, and with synchronicity Christian Terrill from them (another NSDF alumni) proposed he apply for their Director of System Development role. Ben was appointed, confident he could achieve a new standard of system.

He is reluctant to talk about his experience there, but he says he learned the hard way about people “over-selling” and the system being perceived as “under-delivering”, where internal conflicts between sales, support and development actually got to impact on customer relationships. The challenge was that the back end of the system at the time prevented it becoming the excellent system Ben believed was necessary.  And, “as someone who could read a balance sheet”, he was concerned about the company’s health, especially after staff were asked to take a 20% pay cut, with some redundancies. From that bad moment came the liberation of deciding to form Monad, using that balance sheet understanding and his development skills to take a different path:

Monad is the name of a hieroglyph

So first what about that name, eschewing anything to do with the usual ticketing or patron? Ben named the company after one of his tattoos (I have seen it in the flesh!) – a hieroglyph devised by Elizabethan alchemist John Dee, preferring a name that did not limit the company and its solutions to the core around ticketing. That certainly seems to be borne out by the ticketing system delivered so far.

So second, what about that ticketing system and its differences? Ben remembered one of the pitfalls they had found launching Artemis at Artifax – “they had made the system so flexible you needed to be a computer programmer to make it do anything useful” – and strove to balance abstract flexibility with concrete functionality, adhering to the principal “Simple things should be simple, complex things should be possible”. He was also aware of the surprising contrast between how people designed for the web and their end-users, and how they designed for the back-office system functions in a different way, with some systems offering “buttons everywhere’. He naturally wanted to do it differently.

The same ease of use for everyone

From his experience, he knew of the challenges users found in getting the best out of systems. He decided he wanted the staff on-the-phone, over-the-counter, in the marketing office, should have the same ease of use and logical process flow which helped ticket purchasing customers. “If you’ve gone to the trouble of making your website as easy to use as possible for your online customers, why are you giving your staff an interface which is harder to use?”. That has proved the core of his development philosophy and what Monad delivers to a small group of committed users. This runs from how you set up and configure performances and prices through to the ticket sales front end, customer data capture, and the marketing tools.

It took Ben on his own a year to deliver a competent system to sell tickets, and a second year to deliver a complete venue solution, with quick sign-ups once people saw what he was delivering. His chosen business model is the partnership, where venue and supplier work together to achieve success and therefore he decided on a ‘per-ticket charge’ for using the system, believing that both sides benefit. He doesn’t see that as a charge on the end ticket purchaser, but simply a way of counting up the cost for users using the system, and one related to their degree of success: the number of tickets they sell. His focus is on functionality to achieve larger audiences, with venues earning more, so marketing needs to drive sales, enable revenue management, and help venues be successful. All service and support is encompassed in that per ticket charge. He writes an unusually frank blog, which certainly is very honest about his experiences in developing Monad:

“Small is beautiful”

The software certainly delivers on his approach and there are about 20 satisfied users, and rising, from the Hazelmere Hall in Surrey, the Old Firestation in Windsor, and the Cockpit in London. Latest to join is the Broadway in Barking, where to re-develop their website as well they are using Monad as their Content Management System: Intriguingly, if you visit that website (February 2016) you’ll find it connects to two ticketing systems, since Monad is migrating their inventory, so events on the previous system are transferred steadily to Monad as the data is converted, taking some of the pain out of data migration.

Current USP is the way he developed dynamic pricing, with NESTA support via the Old Firestation, which helps venues maximise incomes in response to demand. Firestation MD Dan Eastmond has written an interesting blog about this:

The other part of Ben’s business model is “small is beautiful”, with Ben joined by Jo Scott and a distributed team of free-lancers, slowly expanding when they find the right people with practical experience.

Ben hopes that users are staying because they are on a journey to a better future together. That sounds like a different path and it will be interesting to see how the company grows and keeps close to its users.

Roger Tomlinson

February 2016