Why choosing event software is the easy part

Most event teams I meet work out pretty quickly whether a platform is right for them.

They know what is not working, they know what they need to improve and, after a few conversations and a demo, they can usually see whether the software will solve their problems.

That might take a few weeks, but actually buying it can take a year.

I see this all the time. In a bank, a year from the point it becomes a genuine opportunity to a signed order form is fairly normal. From the very first conversation, it almost always takes much longer. In law firms, professional services firms and other large enterprises, six to nine months is more typical.

Very little of that time is spent looking at the product. Most of it is spent working out how the organisation buys software in the first place.

For a lot of events leads, this is the first time they have bought something that brings together a meaningful budget, client data and cloud software. They know how to run complex events. That does not mean they know who owns the budget for technology, which teams need to approve it or how a project gets onto the firm's list of priorities. Most people would not know any of that until they had to do it.

And usually there is not one person who can just explain the whole process. The events lead speaks to someone in technology, who sends them to procurement, who sends them somewhere else. A form appears that nobody mentioned at the start. They gradually work out the route by going through it.

Where the year goes

Most of the elapsed time is spent waiting for technology to review the platform, security to understand how it handles data, legal to review the contract and someone to approve the budget. Everyone involved already has a full-time job and this is one project among many, often very low on their priority list.

Technical, security and legal reviews are very rarely completed in one go. There will be follow-up questions, points to clarify or wording that needs to change. None of that is unusual or unreasonable, but the problem is that every round takes time. If there is a week between each answer, and there are several people involved, a small number of perfectly sensible questions can add months to the process.

This is not the events team getting it wrong, and it is not the other teams being difficult. Banks and law firms are, rightly, careful about software that handles sensitive client data. The events lead is just trying to move at event speed inside an organisation that is deliberately built to spend money and approve technology much more slowly.

“Most of it is spent working out how the organisation buys software in the first place.

Why projects actually stall

It would be easy to assume that security or cost is what kills these projects. In my experience, that is rarely the case.

Security can slow a purchase down, sometimes significantly, but there is normally a route through it, and while price gets discussed and negotiated, the bigger problem is timing and priority.

By the time the events team has found the right platform and worked out what approvals are needed, the budget cycle may already have closed. Even if it hasn't, the project is probably competing against a CRM migration, a compliance system, a core platform upgrade and every other technology project the firm wants to deliver that year.

There are only so many projects an organisation can fund and manage at once. Without someone senior making the case for it, events software can very easily fall down the list.

The answer is not always “no”, and more often it is “not this year”. That sounds temporary, but it is often where the project starts to fall apart. By the time the next budget cycle opens, priorities have changed, the original case has lost momentum or the person who started it has moved on. Then the whole thing starts again.

The difference a mandate makes

The projects that move quickly tend to have one thing in common: somebody senior, outside the events team, has decided the change needs to happen.

The best example I have seen was a Head of Events at a bank. A senior stakeholder gave her a budget and a deadline, and she took responsibility for getting the purchase through. She managed the business case, procurement questionnaires, security reviews and all the internal chasing, while still running a full events calendar.

It was a huge amount of work, and she got it done.

The reviews did not disappear and nobody skipped procurement or ignored security, but the organisation had already decided the project mattered. People knew it was sponsored, they knew there was a deadline and the different parts of the process happened in the right order.

She did not suddenly become a procurement or security expert, but she did have a real mandate. There is a big difference between asking people to look at a project when they have time and being able to say, “We are doing this, it has senior backing and it needs to happen this quarter.”

Make the case to the person holding the money

Another change I am seeing is that the budget for event software does not necessarily sit with the events team anymore, and increasingly it sits with technology or another central business function.

That changes the case you need to make, because the events team might want to save time, improve the attendee experience, get rid of spreadsheets or make it easier to manage a busy programme. Those are all good reasons to change the platform, but the person holding the budget may be comparing it with completely different projects.

They will want to know how the software handles data, what systems it connects to, what risk it removes and whether it can replace other tools. The case needs to make sense to them, not only to the people running the events.

If you are an events lead looking at new software, I would work out two things early: who can give the project a proper mandate, and who actually controls the money.

Get the first person behind it and then build the case around what matters to the second. Ask for the mandate, not just the budget, because once the organisation has decided the project needs to happen, the budget conversation becomes much easier.

Finding the right platform matters, obviously, but months are often spent proving which product is right before anyone has worked out whether the organisation is actually in a position to buy it, and that is where these projects go wrong.