The machine sells the ticket

Why a 2008 project is in a 2026 portfolio

Because it is the same problem I work on now.

A kiosk that sells a cinema ticket is an unattended system committing a real transaction, with a customer’s money, against someone else’s system of record, with nobody standing there to fix it when it goes wrong. That is precisely the description of an LLM agent booking a table over WhatsApp. The technology is unrecognisable; the discipline is identical.

I have been building that class of system for nearly twenty years. This is where it started.

Context

Cines Unidos, one of Venezuela’s largest cinema chains, ran on VISTA — the commercial ticketing platform that most of the world’s cinema industry runs on. Ticketing, seat inventory, pricing and reporting all lived there, and it was not going to be replaced.

I was the external contractor. I designed and built TickExpress Plus (TEP), a self-service ticketing kiosk platform that talked to VISTA over SOAP web services — roughly nine months of development, first deployment in mid-to-late 2008, and rollout across the rest of the chain through 2009.

The bet

The chain decided to open a cineplex at Centro Comercial Sambil, Barquisimeto, with no box office at all — every ticket sold by machine. In 2008, in Latin America, nobody had done that. Self-service checkout was barely present in supermarkets; the iPhone was a year old and rare.

That is not primarily a technical decision. It is a business betting its opening night on software that has no human fallback behind it. If the kiosks are down, the cinema is closed.

What that constraint actually demands

An attended system can be wrong, because a member of staff absorbs the error — they reprint the ticket, override the price, apologise. Remove the staff and every failure that used to be absorbed becomes visible to the customer, at the worst possible moment, in a queue.

The worst outcome available to a self-service cinema is a customer whose money is gone and whose ticket never printed. There is no counter to go to. So the transaction was ordered to make that outcome unreachable rather than rare.

VISTA reserved the seats first and waited for confirmation. Payment was the last step. If the confirmation never arrived, VISTA released the seats and rolled the transaction back on its own timer.

Two properties fall out of that ordering, and both of them are the reason it worked:

The irreversible step happens last. Taking money first and then trying to secure a seat puts the failure on the customer — they are out of pocket and holding nothing. Reserving first and paying last puts the failure on the cinema, which absorbs it as a seat that was briefly unavailable and then wasn’t. The cost of a failure lands on the party that can survive it.

The rollback lives in the system of record, not in the kiosk. The timeout was VISTA’s. That means a kiosk could lose power, lose network, or be walked away from mid-transaction, and the seats still came back — without the kiosk doing anything, or even existing any more. Correctness did not depend on the least reliable component in the system behaving well.

The iron

This was not a tablet on a stand. The kiosks were built by PERTO, the Brazilian manufacturer whose main business is ATMs and banking self-service terminals — heavy floor-standing machines designed to survive a public space and the people in it. The application was Java Swing on Windows XP Embedded, driving thermal printers for the tickets.

Which adds a failure mode software people are allowed to forget: the transaction ends in paper. A seat can be reserved, a payment authorised and VISTA confirmed, and the customer still walks away with nothing because a cutter jammed or a roll ran out. On an attended system somebody notices. On an unattended one, the machine is the only thing that can.

Where the humans went

Kiosks broadcast a printed-ticket count at intervals, so consumable levels were visible rather than discovered. It still wasn’t enough — rolls ran out, cutters jammed, and no amount of telemetry prevents paper from being paper.

The fix wasn’t more kiosk engineering. It was a designated recovery point: one of the IBM POS terminals at the sweets and popcorn counter — the same terminals McDonald’s and the fast-food chains ran — was given a connection to VISTA so staff could validate a transaction and reprint the tickets.

Three things make that the right answer rather than a workaround:

It’s where the customer was already going. Cinema audiences go to the concession stand. The recovery path added no journey, no separate queue, and no desk that had to be staffed for its own sake.

It reuses staff who were already there. The chain removed the box office; it did not remove the people selling popcorn. The recovery cost was close to zero because it borrowed capacity that existed.

It didn’t try to automate a physical failure. A jammed cutter is not a software problem, and building kiosk logic to handle it would have been expensive, fragile and still wrong sometimes. Routing to a human who could see the paper was cheaper and more reliable than any amount of code.

Alongside that, two or three staff floated the kiosk area — not one per machine, and not required for a sale. They existed for the tail: a jam, or an older customer who had never used a touchscreen and wasn’t going to learn under the pressure of a queue. The machines completed a purchase end to end with nobody touching them.

(The inaugural-day photographs show an attendant standing at every kiosk. That was for the cameras.)

So “100% self-service” was literally true in the happy path, and honest about its tail: a thin, roaming human layer for exceptions, plus one till that could reprint. The claim self-service projects get wrong is not “no box office” — it’s imagining the tail doesn’t exist, and then discovering it at the counter of a cinema that no longer has one.

Result

The first 100% self-service cineplex in Latin America — ten kiosks, no box office, at Centro Comercial Sambil, Barquisimeto.

Then the part that actually proves the design: after the pilot, the chain rolled TickExpress out to 17 cineplexes across the country, serving thousands of tickets a day.

A launch proves software runs. A national rollout across seventeen sites proves it holds up in places nobody designed it for, on networks nobody surveyed, in front of audiences nobody trained — and that the failure mode I’d designed for never became someone’s operational problem.

Alongside it I built TiendaCinesUnidos, the chain’s DVD e-commerce portal, when physical media was still the business.

The through-line

Three of the systems in this portfolio are the same system.

TickExpress (2009) — a kiosk commits a ticket sale to VISTA over SOAP. No staff. Solved by ordering: reserve first, pay last, and let the system of record time out and roll back on its own.

FotoSmart (2005) — photos arriving from mobile handsets, when that meant fighting each handset’s idea of what an upload was, into an order that ends in something physical being printed and shipped.

nsOmniStore’s booking agent (2026) — a language model gathers what the guest wants, and the confirmation commits to the booking system. The failure I removed was the model telling a guest their table was booked when nothing had been written.

In every one, an unattended machine takes an instruction from a person and turns it into an obligation a business must honour. The lesson has not moved in seventeen years: the interface can be forgiving, but the commit cannot.

And the fix has the same shape every time. It is never “be more careful” or “handle the error better” — it is a change to the ordering, so that the component you cannot trust is no longer standing between the customer and the obligation. In 2009 that untrustworthy component was a kiosk on a shopping-centre network, so the money moved last and the seats released themselves. In 2026 it is a language model, so the commit runs in code before the model is consulted at all.

The second half repeats too. Neither system pretends it can handle everything. TickExpress routed a jammed printer to a member of staff who was already standing there selling popcorn; the WhatsApp agent hands a conversation it can’t complete to a human operator, and when it can’t verify a booking it says so plainly instead of inventing a confirmation. Automate the happy path, and make the escape hatch cheap, obvious and close to where the customer already is. A system that will not admit failure is not more reliable — it just moves the failure somewhere nobody is watching.

The unreliable part changes every decade. Where you put it does not.