Cinema Management and Showtime Scheduling Software: Why the Weekly Grid Still Takes Two Days

Why the showtime grid decides everything else in a circuit

It is Tuesday afternoon and the programming manager for a nine site circuit has next Friday open in a spreadsheet. Sixty two screens, four premium format houses, one auditorium with its own booking commitment, and a distributor who confirmed a holdover an hour ago at a screen count nobody planned for. Every change ripples. Move the 7:15 in screen four and the cleaning crew loses its turnaround. The pre-show pack for that title runs three minutes longer than the last one, so the advertised start and the actual start drift apart. The late show now empties after the last bus. The concessions manager already built a rota against a footfall curve that no longer exists.

The stack around this is familiar. Vista Cinema at the larger sites or Veezi at the small ones, Retriever Solutions or a similar product on the concession till, a theatre management system per projection booth, and a spreadsheet holding the part that actually matters. That spreadsheet is the join. It is the only place where distributor commitments, turnaround times, staffing cost, premium format exclusivity, and projected admissions per slot exist in the same object. Every packaged system owns one slice. The programming manager owns the joins, by hand, twice a week.

This is not a tidiness problem. The grid is the revenue plan, and a cinema seat is the most perishable inventory in retail: at 7:16pm on Friday, an empty seat in screen four is worth nothing forever. Across circuit projects we have delivered, the recurring pattern is two full days a week of senior programming time and a settlement process where nobody can say with confidence whether a distributor invoice is correct. The second one is the expensive one, and almost nobody measures it.

Problem 1: packaged systems give you a calendar, not a solver

Vista and Veezi both let you place sessions on screens. That is a calendar. What a circuit actually has is a constraint problem: turnaround minutes that differ by auditorium size and whether the last show was a family title, pre-show and trailer pack length that varies per title and per format, distributor minimum screen counts and week commitments, format exclusivity where a title cannot sit in two premium houses at once, staggered starts so six hundred people do not hit the lobby in the same four minutes, cleaning headcount, and a last program out time that has to sit inside the staff rota you already published.

None of that is expressible in a calendar. So the manager holds it, and the grid gets rebuilt from scratch rather than adjusted, because adjusting requires knowing which of the invisible constraints you are about to break.

What a custom build does: state the constraints explicitly and solve against them. Each auditorium is a resource with a turnaround rule. Each title carries a runtime, a pre-show pack length, and its commitment terms. The solver places sessions to maximise projected admissions net of labour cost, then tells you what it could not satisfy and why. A constraint model over sixty screens and a week of slots solves in seconds, which changes the behaviour: instead of one painful rebuild, programming runs six scenarios on a Tuesday and picks one. The manager stops being a solver and becomes an editor, which is the job they were hired for.

Problem 2: film rental settlement is reconciled by hand, or not at all

Film rental terms are negotiated per title, sometimes per week, and they are not uniform across your sites. Sliding scales, house allowances, minimum week commitments, and the occasional four wall arrangement all coexist in the same month. The distributor sends a statement. Somebody in finance checks it against the box office report, mostly by eye, mostly on the big titles, and signs off on the rest because there are forty of them and the month has to close.

Vista has settlement functionality and larger circuits do use it. What we see repeatedly is that the deal terms live in email threads and the booking manager's memory rather than in the system, so the calculation is only as good as whatever got typed in. Veezi does not seriously attempt this. Below a certain circuit size, film rental is simply an unaudited line.

What a custom build does: model the deal itself as data. Term type, scale breakpoints, house allowance, commitment weeks, and which sites it applies to. Then the expected rental computes automatically off actual admissions per site per week, the distributor statement is imported and compared line by line, and variance over a threshold you set gets flagged before payment rather than after. Box office reporting to Comscore and to distributors runs from the same numbers, so your grosses, your settlement, and your public reporting cannot disagree with each other. The first time this catches a mis-scaled title across four sites, it has paid for the module.

Problem 3: subscription passes break the ticketing math underneath

A subscription pass is not a discount code, but that is exactly how packaged loyalty modules treat it. The pass changes seat inventory behaviour, because pass holders book earlier and no-show more. It changes revenue recognition, because you are recognising subscription income against admissions in a different period. It changes distributor reporting, because a pass admission still has to carry an attributed ticket value into film rental. And it changes concessions, because the pass holder walks in with the ticket already paid and a different spend pattern at the counter.

Circuits that launched a pass on top of a packaged system usually end up with a parallel spreadsheet reconciling pass admissions to attributed value each month. That spreadsheet is load bearing and one person maintains it.

What a custom build does: an entitlement engine that owns pass rules directly. Visits per period, blackout titles or formats, booking window, guest allowances, and a no-show policy with real teeth such as a hold on the next booking after two unclaimed reservations. Attributed value per pass admission computes per title per site and flows into settlement automatically. Cohort reporting tells you what a pass holder is actually worth once you include their concession spend and the admissions they bring with them, which is the number that decides whether the pass is a growth engine or a discount you cannot switch off.

Problem 4: the schedule and the projection booth do not talk

The grid gets published, and then somebody at each site builds the playlists in the theatre management system by hand: feature, pre-show pack, advertising, the right audio format, the right automation cues for lights and masking. Then the show fails on a Friday night because the key for that print expired at midnight, or the content package never finished ingesting, and nobody checked because checking is a manual walk around the booth.

This is the gap that costs you refunds and reviews, and no scheduling tool closes it because scheduling tools stop at the ticket.

What a custom build does: generate playlists from the published schedule and push them to the theatre management system, then verify readiness ahead of time. Is the content package present at that site, is the key valid for the whole run and not just tonight, does the audio format match the auditorium, is there a pre-show pack assigned. A readiness board at the circuit level shows every session for the next seventy two hours in green or red, so the failure is caught on Wednesday by one person instead of at 7:15pm on Friday by four hundred. Booth integration work is genuinely fiddly and differs by server vendor, which is why it belongs in a later phase, but it is the phase site managers thank you for.

What this costs and how long it takes

Digital Heroes has delivered more than 2,000 projects, and for cinema circuits the honest shape is this. A first release covering constraint-aware scheduling, deal terms and settlement, and integration with your existing ticketing runs $70,000 to $150,000 over 12 to 18 weeks. That is a system your programming manager uses to build a real week, not a demo. A full platform adding ticketing and seat inventory, concessions and stock depletion, subscription passes and loyalty, theatre management system pushes, and circuit reporting runs $200,000 to $500,000 phased across 8 to 14 months.

What pushes the number up in cinema specifically: the number of distinct projection server vendors across your sites, because each one is its own integration. Payment terminal and EMV certification if you are replacing the till rather than integrating with it, which is weeks of certification you cannot compress. Online booking with seat maps for premium formats, where the seat map is not a grid. Multi currency and multi tax if you cross borders. And the quiet one, which is how many of your deal terms exist only as an understanding between your booker and a distributor sales rep. Writing those down is discovery work and it is not optional.

What holds the number down: keep your existing ticketing and till for phase one and integrate. Scheduling and settlement are where the money is. Replacing a working point of sale (POS) is the most expensive way to start and the least valuable.

Build versus buy, and when buying is clearly right

Buy, and do not call us, if you run one to three sites with conventional programming and no subscription pass. Veezi exists for exactly that operator, costs very little, and works. A custom build at that scale is a hobby. Vista Cinema is also a reasonable answer for a mid-size circuit whose programming is stable, whose formats are conventional, and whose commercial model is straightforward admissions plus concessions. If the packaged system fits, use it and spend the money on seats.

Our position on when to build: when two or more of these are true. You run roughly 40 screens or more, so the grid is a real optimisation problem rather than an arrangement. You sell a subscription pass, which no packaged loyalty module models correctly. You operate premium formats with their own distributor commitments and exclusivity terms. Food and beverage is a serious revenue line rather than a popcorn counter, so staffing and stock must be planned against the grid. Or you have expanded by acquisition and now run two or three different ticketing systems, which means the reporting layer has to be yours regardless.

The tipping point is the same one every operator hits: the coordination logic between programming, commitments, labour, and settlement becomes the actual business, and you cannot rent your actual business from a vendor whose product was shaped around a different circuit.

How to choose a developer for cinema circuit software

Ask them to model your scheduling constraints on a whiteboard before you sign. A developer who has done this will ask about turnaround by auditorium, pre-show pack variance, and commitment terms in the first ten minutes. A developer who talks about a drag and drop calendar has built an events booking app and is about to learn film exhibition on your budget.

Ask specifically how they will handle projection booth integration. The right answer names the server vendors at your sites, mentions key validity and content availability checks, and treats it as a later phase with real risk. A vague promise here means it will not get built.

Ask what they will do about settlement variance. If the answer is a report, push harder: you want deal terms modelled as data, expected rental computed automatically, and a variance flag before payment goes out. That is the difference between a dashboard and a control.

Ask who owns the code, the repository, and the cloud accounts, and get it in writing before kickoff. You should be free to hire anyone else to continue the work. At Digital Heroes the client owns everything from the first commit, and we would tell you to walk away from any developer who hesitates on that question.