The context
A French employee-benefits operator sells tickets, admissions and discounted offers to employees, usually through their company’s works council. Seen from the beneficiary, the business looks simple: a page, a reduced price, a ticket in the inbox. Seen from the inside it is much less so, because nothing upstream is uniform.
Every supplier delivers tickets its own way. Some provide PDFs in advance, some want to approve each booking by hand, some expose a ticketing API with its own catalogue, availability and cancellation rules. Every works council, meanwhile, wants its own domain, colours, catalogue and subsidy rules. And a seat sold twice is not a display bug: it is a beneficiary turned away at the door.
What we did
We designed, built and now operate the whole thing: the public site, the works-council portals, the back office, and the services running behind them.
- A stock model that absorbs supplier heterogeneity. Pre-supplied tickets, generation on demand, partner approval, internal approval, or a synchronised third-party ticketing catalogue: four fulfilment modes and external inventories, behind a single buying journey. That is the opposite of the usual reflex, which is to let the buyer carry the supplier’s complexity.
- Transactional availability. Seats are held the moment they enter the basket and released if payment does not complete, with conditional writes so two simultaneous purchases of the last seat cannot both succeed. Fixed-date and flexible-period stock coexist, and recurring slots are generated from weekly templates rather than entered by hand.
- White-label multi-tenancy. Dozens of works councils get their own domain, theme, catalogue subset and content — news, media library, polls, banners. Their own administrators manage all of it, under fine-grained permissions, with no access to internal functions and without a single line of code being forked per client.
- The financial chain, which is the least glamorous part. Wholesale, public and negotiated prices coexist, with fees, add-on options, targeted discounts, flash sales and council subsidies. The hard part is VAT: ticket resale mixes margin-scheme and standard VAT, which forces a line-by-line breakdown that has to agree across the ticket, the invoice and the accounts.
- Ticket and document delivery. PDF generation with QR codes and barcodes, invoices, confirmation emails. We invested as much in deliverability — bounces, complaints, suppression list — as in the rest, because a ticket that does not arrive costs a support call and some trust.
- Activity search, as semantic search built on Amazon Bedrock embeddings and Amazon S3 Vectors, which avoids running and paying for a dedicated vector database at this scale.
- GDPR compliance, treated as an architecture question: analytics tracking removed from the public front end, emails with no open tracking, and data-subject rights tooled rather than handled by hand.
The outcome
The platform is in production and we operate it. Opening a new works council is configuration, not development. Connecting a new supplier means picking an existing fulfilment mode, without touching the buying journey.
The most useful lesson concerns VAT and discounts. We first treated the breakdown as an invoicing detail, and it became the area that needed the most rework: in ticket resale, price calculation is the product, not a display concern. The second lesson is more mundane and just as expensive to ignore: half the work of a ticketing platform happens after the payment.