1. Home
  2. Integrations
  3. RTS
Integration

Filmgrail + RTS

A strong point-of-sale system does not make a strong digital channel. They are different problems, and they are best solved by different software.

What running Filmgrail on RTS means

RTS is a point-of-sale and box office system for cinemas, and like most systems of its kind it is strongest at the counter. Ticketing, concessions, pricing and reporting are solid; the online surface is a module rather than a product.

Filmgrail reads programme, session, seating and pricing data from RTS and replaces that surface with a branded website, native iOS and Android apps, a CMS, loyalty, push and audience analytics, writing the completed sale back so your reporting stays whole.

What moves between the two systems

Nothing is re-keyed. The integration reads what your box office already knows and writes back what the moviegoer just did.

Films and metadata

Titles, synopses, running times, certificates, cast, genres and release dates, enriched with artwork and trailers so film pages are not a line of text and a poster.

Sessions and showtimes

Every performance with its screen, format, language, subtitle and accessibility attributes, updated as the schedule changes rather than overnight.

Seat maps and availability

Live hall layouts with holds, house seats, wheelchair spaces and companion seating rendered exactly as they exist in the box office.

Ticket types and pricing

Adult, child, concession, member and loyalty pricing, plus surcharges and booking fees, applied by your own rules rather than duplicated in a second price list.

The completed order

Seats, ticket types, amounts and payment reference written back so the sale appears in your daily reports alongside the counter.

Reconciliation

A matching report on both sides so finance can tie the digital channel to the box office totals without a spreadsheet.

What your moviegoers get

  • A website built to sell, not to inform. Programme, film pages, showtimes, seat selection and checkout on one fast, mobile-first site you control through a CMS rather than a ticket iframe bolted onto a brochure page.
  • Native iOS and Android apps. Not a wrapper around your booking page. Autoplaying trailers, stories, watchlists, personalised showtimes and push — the things that make somebody open the app in a week when they are not buying.
  • One CMS for both. Films, showtimes, articles, carousels, banners, gift cards, push campaigns and loyalty edited once and published to web and app together.
  • A checkout that finishes. Seat maps, ticket types, fees, gift cards, value cards and saved payment in a flow measured on completion rate rather than on feature count.
  • Moviegoer identity. Nine out of ten end users on the platform create a profile, which turns anonymous transactions into a customer base you can segment, target and measure.
  • Audience data you can act on. Demographics, engagement, watchlists, ratings, sessions and digital box office in one view, joined across site and app.

What stays in RTS

Point of sale, concessions, ticket types and pricing, cash management and the daily and periodic reporting your operation runs on.

Who owns what

The division of responsibility between RTS and Filmgrail, written out so nobody discovers it in month three.

AreaRTSFilmgrail
Programme and schedulingSource of truthReads and publishes
Seat maps and inventorySource of truthReads and renders
Ticket types and pricing rulesSource of truthApplies at checkout
Counter and kiosk salesOwnsNot involved
Website and native appsNot involvedOwns
Online checkout and payment flowReceives the completed saleOwns the experience
Content, campaigns and pushNot involvedOwns
Moviegoer profiles and loyaltyWhere the system provides itOwns the digital layer
Box office reporting and settlementSource of truthReconciles against it

The point of the split is that your finance and operations reporting never moves. Every online sale lands back in your box office as an ordinary transaction, against the same ticket types and the same price rules the counter uses.

How a project actually runs

First we look at what your deployment exposes. That is a short technical conversation, not a discovery workshop, and it ends with a straight answer about whether the integration is a week of work or a quarter of it.

Then the build: your branding, your content model, your seat maps, your ticket types, your checkout rules. You review it on a staging site against your real programme, not a demo dataset.

Then launch, with your old URLs redirected rather than dropped so the search visibility you have built comes with you. Apps follow the site, usually a few weeks behind, because the CMS and the content are shared and there is no point shipping an empty app.

Nothing in that sequence requires you to touch the box office, which is why the risk of trying it is so much lower than it feels.

Answers

Frequently asked questions

Is our POS affected at all?

No. The counter carries on in RTS. The integration reads programme and seating data and writes completed online orders back.

Do we need in-house developers?

No. The integration and the build are our work. Day-to-day running is a CMS, not a codebase.

How is this different from adding online sales to our POS vendor's web module?

A web module is a booking form. This is a branded site and a pair of native apps designed to be opened between visits, with content, push, watchlists, loyalty and a moviegoer profile behind them.

Can we keep our current domain and URLs?

Yes, and existing URLs are redirected rather than abandoned so the search rankings you already have are preserved.

What does it cost?

Pricing in this market is normally a platform fee plus a per-ticket or percentage transaction fee, and it moves with screen count and volume. Book a demo and you get a written cost assessment for your own cinema.