Festival Operations Management Software Problems: The 6 That Cost Real Money, and How to Avoid Them

Why does supplier compliance get built as an approved flag?

Because that is what the process looks like from the outside. A trader applies, someone reviews the documents, someone ticks approved. So the data model gets a supplier table with a status column, and the whole system is built on top of it. Everything downstream inherits the assumption: the gate list reads the status, the reporting counts approved suppliers, the dashboard is green.

The problem is that approval is a moment and compliance is a duration. Public liability insurance expires. Gas safety certification expires. Electrical testing on a trader's equipment expires. Plant certification expires. The date that matters is the date they are on site, which is often three or four months after the date they applied. A status column cannot express that, so by build week the register is quietly wrong and nobody knows which entries.

The fix is a modelling decision made before estimation. A supplier has a requirement set generated from what they actually do and where they are placed, each requirement is satisfied by a document with an issue date and an expiry, and access status is computed at read time against the date being asked about. A trader whose certificate lapses two days before gates goes amber automatically, and their site manager is told while there is still time to act. Ask any prospective developer what happens to a supplier whose insurance expires between application and build week. If the answer is that someone re-reviews them, you are buying your current problem in a nicer interface.

What goes wrong when the supplier register is assembled for the first time?

Most organisers have never had a single register. They have a trader spreadsheet maintained by the trader manager, a contractor folder on a shared drive organised by whoever uploaded, an artist advance running through a production manager's inbox, and a site plan revised four times as a PDF. Building the register for the first time is the real project, and it is not a software task.

Two specific traps. The first is supplier identity across events and years. The same catering company trades at three of your festivals under two slightly different trading names, and one of them is the limited company on the insurance certificate while the other is what everyone calls them. If you do not resolve identity before loading, you get three records, three sets of documents, and a register that cannot answer whether that company has ever been a problem.

The second is requirement sets. A food trader, a bar operator, a fairground ride operator and a scaffolding contractor need completely different documents, and the differences usually exist as knowledge in four different people. Write them down before migration, not during, and accept that this takes weeks of somebody senior's time rather than an afternoon. The organisers who move fastest are the ones who arrived with a written requirement matrix. The ones who slip are the ones who assumed the developer would derive it.

Why do offline mobile and accreditation integrations break after launch?

Offline is where most festival builds fail, and it fails late, which is the worst timing. On day one of build the site has whatever network you brought with you, and that network is not up yet. Compliance sign offs, incident reports and photographs all get captured in exactly those conditions.

The failure mode is subtle. A team builds a responsive web application that caches pages, tests it on a stable connection, and calls it offline capable. Then a site manager takes eight photographs at a stage build, walks into a marquee, and the browser evicts the cache. The photographs are the problem specifically: they are large, they are the actual evidence, and syncing them is a different engineering problem from syncing a form. Treat any developer who calls offline a later phase as a serious risk, and test with real photographs on a real device with the connection off before you accept the work.

Accreditation breaks for a different reason. It sits between your system, whatever pass printing hardware you use, and often a separate ticketing platform, and the volume arrives in a two week spike immediately before gates. Integrations that behave fine at ten records an hour behave differently at two thousand. Load test accreditation against your actual peak, using last year's numbers, before build week rather than during it.

What happens when the incident and noise record is not covered properly?

Everything in the operational build gets attention because it is visible. The incident record gets less, because it feels like paperwork, and it is the part the licensing authority actually reads afterwards.

Welfare cases, medical calls, ejections, lost children, weather decisions and noise readings are all reviewed after the event, sometimes by the police and always by your insurer. Two categories attract the most scrutiny. Noise readings against the permitted limit for each period, because that is the condition most commonly breached and most commonly disputed by residents. And weather decisions, because a wind related show stop is the single decision an organiser is most likely to be asked to justify in detail.

The design requirement is that the timestamp is fixed at the moment the event happens, with detail added later. Control room operators are busy exactly when the incidents are worst, so a system that demands a complete form up front produces sparse records for the periods that matter most. Capture time, type, location and reporter in two taps, then let someone complete the narrative when the radio goes quiet.

Noise readings should be logged against the license limit for that time period rather than as a raw number, so a breach is visible as it happens rather than discovered in a debrief. And weather decisions should record the reading, the threshold and the named person who made the call, because that is the specific evidence that will be asked for.

Should you build custom or configure what you already own?

For a lot of organisers, configure. If you run a single day event in a park with twenty traders and one stage, FestivalPro will cover a large share of what you need and the effort of building would exceed the value. It is one of very few products built specifically for festival organisers rather than adapted from conference software, and that shows. We would tell you to buy it before quoting a build.

If your primary problem is artist logistics rather than site compliance, Master Tour handles the touring side well and you can run the rest on documents for longer than you might expect. Keep it either way. A build in this category should own the supplier register, the compliance status and the incident record, and hand off to whatever already does advancing well.

The build case starts when compliance is the binding constraint. That means a license with specific numeric conditions on capacity, welfare, medical provision or noise that you must evidence, several hundred suppliers with expiring documentation, a build programme where inspections gate other work, or a portfolio of events that should share one supplier register and one operating standard. Our position is that the supplier compliance module alone justifies most builds here, because it converts the riskiest recurring decision on a festival site into a lookup.

How do hidden costs get into the quote?

Offline first mobile is the largest, and it is often quoted as though it were a setting. It is not. Local storage, conflict handling, photograph sync and a tested recovery path after an app restart are real engineering, and pricing them properly at the start is cheaper than discovering them in week ten.

The number of distinct supplier types is the second. Each requirement set is configuration plus a conversation with the person who owns that category, and organisers routinely count four types and find nine. Multi event portfolios are the third: a shared register across festivals is enormously valuable and genuinely more complex, because the same supplier can be compliant at one event and not at another.

The cost nobody quotes is your own team's time during the busiest quarter of your year. Onboarding several hundred suppliers into a new register happens while those people are also delivering an event. Assume it competes with the event rather than fitting around it, and start onboarding before development finishes so the two loads do not land in the same fortnight.

What separates a build that works from one that fails here?

Three things.

First, ship deliberately narrow in cycle one. Your deadline is a gates date that cannot move, which is a discipline most software projects never face. Supplier compliance and incident capture in year one, build programme and advancing in year two. Organisers who attempt the full platform before their first gates date arrive at build week with a half finished system and revert to spreadsheets, which then costs them the following year as well.

Second, keep the build programme small. Model only tasks that carry a sign off or a compliance consequence, and make signing off a two tap action with a photograph. A full construction schedule will be abandoned by day two of build. A short list of gated sign offs will actually get used, and it is the list the safety advisory group cares about anyway.

Third, settle ownership before kickoff. You should own the repository, the infrastructure accounts and all supplier, compliance and incident data. That evidence is what you produce at the next license hearing and what your insurer asks for after an incident, and it needs to remain under your control for your full retention period rather than for as long as a supplier relationship lasts.