Cinema Management Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does replacing the point of sale (POS) swallow the budget so often?

The pattern is almost universal. A circuit commissions a build to fix showtime scheduling and film rental settlement, both of which are genuinely broken. Somewhere in week three of discovery, someone says that while we are in there we may as well replace the till, because the concessions system is old and the reporting is poor. The scope doubles in a sentence, and the money moves from the part that was losing you cash to the part that was merely irritating.

Point of sale replacement in exhibition is uniquely expensive because it is not really a software problem. It is payment terminal certification, which runs on the acquirer's calendar and not yours, and cannot be compressed by adding developers. It is hardware at every counter across every site. It is retraining every casual staff member before a school holiday. And it is the one system where a bad day means a queue in the lobby at 7pm on a Friday, which is the single most visible failure mode your business has.

The fix is a scoping rule you enforce before signing: phase one integrates with the ticketing and till you already run, and replaces nothing. Vista Cinema and Veezi both expose enough for a scheduling and settlement layer to sit above them. Get the grid and the rental audit working against live trading, prove the numbers for a quarter, and only then have the conversation about the counter. Most circuits find they never want to have it.

What goes wrong when deal terms and box office history are migrated?

Every other industry calls this data migration and treats it as an export. In exhibition it is not a migration at all, because the data you most need has never been in a system. Film rental terms are negotiated per title, sometimes per week, and they live in email threads, in a booking manager's memory, and in the shape of a relationship with a distributor sales representative. There is nothing to export.

Builds fail here in a specific way. The engineering team asks for the deal terms, receives a spreadsheet with a percentage per title, builds against it, and discovers at user acceptance that the real terms include sliding scale breakpoints, a house allowance that differs by site, minimum week commitments, and the occasional four wall arrangement that does not fit the model at all. The rework lands late, when it is most expensive, and confidence in the settlement numbers never recovers.

Treat term abstraction as its own workstream, staffed by your booker, running in parallel from week one. Model the term as data: type, scale breakpoints, house allowance, commitment weeks, and which sites it applies to. Then validate against history rather than against opinion. Load six months of admissions per site per week per title that you have already settled and paid, run the engine over them, and reconcile. Where the engine and the statement disagree, one of them is wrong and you want to know which before you trust either. That backfill is also what keeps your grosses, your settlement and your Comscore reporting from disagreeing with each other later.

Why do ticketing and projection booth integrations break after launch?

Because they are not one integration, they are several, and the count is usually understated at quote time. A circuit that has grown by acquisition typically runs two or three ticketing systems and more than one projection server vendor across its estate. Each server vendor is its own protocol, its own quirks, and its own acceptance test. A quote that says projection integration as a single line item has not counted your sites.

The breakages after launch are consistent. A key expires partway through a run rather than on the night, so the readiness check that only looked at tonight passes and Friday fails. A content package finished ingesting at one site and stalled at another, and nobody walked that booth. An audio format was assigned that the auditorium cannot play. A pre-show pack was never attached, so the advertised start and the real start drift by three minutes and the whole staggered lobby plan falls apart.

The fix is a readiness board that looks forward seventy two hours, not at tonight, and checks the four things that actually fail: content present at that site, key valid for the whole remaining run, audio format matched to the auditorium, pre-show pack assigned. Sequence booth work as a later phase with named vendors and a per vendor acceptance test, and never cut over during a major release week. If a new server vendor arrives mid build because you bought two more sites, that is a change order and it should have been priced as one in the contract.

What happens when subscription pass entitlements are not properly covered?

A subscription pass is treated as a discount code by almost every packaged loyalty module, and by most first drafts of a custom build too. That single modelling shortcut breaks four things at once, and the breakages appear months apart, which is why nobody connects them.

Seat inventory behaves differently, because pass holders book earlier and fail to show more often, so your projected admissions are wrong in both directions on the same night. Revenue recognition breaks, because subscription income arrives in one period and the admissions it covers land in others. Film rental breaks, because a pass admission still has to carry an attributed ticket value into settlement, and if it does not, you are either under reporting to a distributor or paying on a number you cannot defend. And concessions planning breaks, because a pass holder walks in with the ticket already paid and spends differently at the counter.

What you end up with is a monthly reconciliation spreadsheet that converts pass admissions into attributed value, maintained by one person, load bearing and undocumented. The fix is an entitlement engine that owns the rules directly: visits per period, blackout titles and formats, booking window, guest allowances, and a no-show policy with real consequences such as a hold on the next booking after two unclaimed reservations. Attributed value computes per title per site and flows into settlement automatically. Then add cohort reporting, because the number that decides whether the pass is worth running is the pass holder's total value including concessions and the admissions they bring with them.

Should you build custom or configure Vista or Veezi?

For a meaningful share of readers, configure. If you run one to three sites with conventional programming and no subscription pass, Veezi does the job, costs very little, and a custom build would be an expensive hobby. Put the money into seats, sound or projection, which your audience can actually perceive.

If you are a mid-size circuit with stable programming, conventional formats, and a straightforward admissions plus concessions model, Vista Cinema is a serious product and it can carry you. Before you commission anything, do the unglamorous thing first: get your actual deal terms into its settlement module instead of leaving them in email. A large fraction of the settlement pain we are asked to solve is not a missing capability, it is an incumbent system nobody finished configuring because the person who knew the terms never had a week free to enter them. That week is cheaper than any build.

Build when two or more of the following hold. You run roughly forty screens or more, so the weekly grid is a genuine constraint problem rather than an arrangement. You sell a subscription pass. You operate premium formats carrying their own distributor commitments and exclusivity terms. Food and beverage is a real revenue line that has to be staffed and stocked against the grid. Or acquisitions have left you running more than one ticketing system, in which case the reporting layer has to be yours regardless of what sits underneath it.

How do hidden costs get into the quote?

Five items account for most of the overrun in this category, and all five are visible in advance if you ask.

• Projection server vendor count. Priced as one integration, delivered as three. Ask for a line item per vendor and per site count, and ask what happens if another arrives mid build.
• Payment certification. Only applies if you replace the till rather than integrate, which is the argument for not replacing it. It runs on the acquirer's timetable and no amount of project management moves it.
• Premium format seat maps. A recliner house or a large format auditorium is not a grid, and online booking against a non-grid seat map is materially more work than the standard case.
• Deal term abstraction. Somebody has to sit with your booker and write down what has only ever been understood. This is your cost, not the developer's, and it is the item most often left out of both sides of the plan.
• Parallel running. A full quarter of comparing the computed rental and the published grid against the old process is not optional, and it consumes real hours from the two people who are already busiest.

Multi currency and multi tax handling belongs on the same list if you trade across borders. None of these are surprises to anyone who has delivered in exhibition, which is exactly why their absence from a quote tells you something.

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

The builds that work ship scheduling and settlement first, on top of the ticketing you already own, and get a programming manager using them to build a real week inside three months. They run parallel for a full quarter and reconcile computed film rental against statements already paid, so trust in the numbers is earned rather than asserted. They treat booth integration as a named, later phase with a vendor by vendor acceptance test. And they have one person on the client side who owns the constraint model and can answer what the turnaround rule is for a family title in a four hundred seat house without asking anyone.

The builds that fail start at the counter, promise projection integration in general terms, leave deal terms in email until user acceptance, and have no single owner of the scheduling rules, so every constraint arrives as a surprise in a demo.

Settle ownership before kickoff, in writing: the repository, the cloud accounts, and the unrestricted right to hire another firm to continue the work. At Digital Heroes the client owns all of it from the first commit. In exhibition that matters more than in most sectors, because the software sits directly on top of trading, and a supplier dependency at 7pm on a Friday is an operational risk rather than a commercial inconvenience.