Ticketcorner

A thousand tickets sold. And not one person met.

An organiser fills the house. The sale ran through Ticketcorner, the report lands in the inbox on Monday, and it says how many tickets went in which price category.

What it does not say: who these people are. Who came for the fourth time. Who came for the first. Who would come again next week if somebody told them about it.

The Ticketcorner interface to Caymland M4 turns those reports into an audience. Every ticket sold becomes a contact and a booking – with event, date, price category, seat and sales channel. From there you can work with it.

What Ticketcorner is

Ticketcorner is Switzerland’s largest ticketing provider: more than ten million tickets for around 15,000 events a year, owned by CTS Eventim and Ringier. For organisers, though, Ticketcorner is not one system but several: the sales platform ticketcorner.ch, Ticketcorner.Inhouse (Eventim Inhouse) for theatres, opera houses, concert halls and sports organisations with their own box office, and Ticketcorner.Tixx for sports clubs and festivals.

Ticketcorner sells your tickets. Who these people are, what else interests them and how you reach them again by email, SMS or on your website is up to you. That is what Caymland M4 is for.

Three systems, all connected

Caymland M4 is connected to all three systems. Which one you use, or whether several run side by side, makes no difference to the work that follows: all bookings land in the same profile and the same booking history, each with its source.

Ticketcorner. The sales report delivers every ticket as its own row: performance, venue, town, price category, seat, status (booking, reservation or cancellation) and even ticket insurance. Even an initial import of almost a million rows runs through.

Ticketcorner.Inhouse. Customers and orders arrive through Eventim’s interface, and only what has changed since the last run. Included are the customer’s language and salutation, block, row and seat, price and discount, sales type and sales route, event, venue, promoter and booking date. Buyers without an email address are recognised in three stages, by email, customer number, or first name, surname and town together, and on request your main contacts stay untouched.

Ticketcorner.Tixx. Tixx reports changes to orders and tickets to Caymland M4 itself; they are processed in the next run. Transferred are order, invoice and payment, every valid ticket with area, row, seat and price category, reductions and club sales, the match or event with competition and venue, and buyer data down to nationality and date of birth. You decide in the mapping what goes where.

What the interface gives you

• Rows become people. Every line in the export is matched to a contact, not merely counted.
• The attendance history builds itself. Who attended which event, how often and in which category is there after the first import.
• Segments instead of sorting. "Attended this production", "always books the top category", "not seen for two seasons" – these are conditions, not afternoons in a spreadsheet.
• Bookings trigger journeys. A new booking can start a campaign, award points or move a contact to another stage.
• Reporting stays in house. Ticket sales are available as their own reporting source, one row per line item, linked to the contact.

What comes in

Which of these actually arrive depends on the scope you agreed with Ticketcorner. Whatever is in the export comes through. Whatever is not in it, no interface can invent.

How the import runs

Direction: from Ticketcorner to Caymland M4. Nothing is written back. Your sales operation is untouched.

Where the files come from: either a directory on your own system or an SFTP drop location. Both are a setting, not a different procedure.

Timing: on a schedule, typically overnight. The data is as current as the last export – that is the honest frame of a file-based interface. It is not built to react within minutes; for everything else it is enough.

It survives interruption. Sales exports are large. If a run breaks off, the interface remembers the last line it processed and resumes at exactly that point. No duplicated bookings, none skipped.

Processed files move to an archive. Finished files are moved to an archive folder. Where the drop location is read-only – the normal case with ticketing drop zones – the interface keeps a record of name, size and timestamp instead. The same file is never read twice.

Different export formats. Semicolon-separated or comma-quoted, with leading notice lines or without: the format is detected. Placeholders such as "---" or "no data available" end up as an empty field rather than as text on the contact.

How contacts are recognised

This is where an import either becomes a clean database or a wreck.

Shared box-office addresses are not an identity. At the counter, buyers without their own email address are entered under a placeholder address – the same one for everybody. Matching on it would fuse hundreds of unrelated buyers into a single contact. These addresses are recognised and never used as an identifier. You can add the shared addresses your own house uses.

A second run does not create twins. A row that has already been read is recognised by its order and line identifiers and assigned to the existing contact – even when it carries no address at all.

Maintained data takes precedence. Checkout data is noisier than maintained records. On request the import fills gaps only and never replaces a maintained value. What the interface owns – the ticketing customer number and the company from the sale – is always refreshed.

No empty shells. If a row matches no field, because a foreign layout was sitting in the folder for instance, it does not produce a contact without content.

Column mapping is a setting, not programming. If your export deviates from the usual, the mapping is adjusted. That is an appointment, not a development project.

What you can do with it

Everything with the visitor. Each contact’s profile has its own tab with all bookings, topped by tiles showing tickets and revenue, in total and over the last twelve months. The same for companies. When two contacts are merged, the bookings go with them.

Audiences from ticket sales. Every booking field is a filter: performance, venue, price category, sales channel, status, source. Plus the weekday of the performance, the total number of tickets bought, for example ten or more, and group bookings with many tickets in one order. Several conditions refer to the same booking.

Reminders before the performance. Dates can be relative too, such as “performance in three days”. A campaign checks the bookings daily and writes to exactly those whose evening is coming up. The day after, it writes to those whose performance was yesterday.

The booking in the message. Title, date, start time, venue, seat: every booking field is available as a placeholder in email, SMS and WhatsApp, in the subject too and with your own date format. Whole sections appear only for a particular performance or start time. In the preview you choose a real booking and see the message exactly as that visitor will receive it.

Content per production. Caymland M4 creates an entry for every performance by itself. You maintain text and image once per production, and every email shows the content for the booked performance. Variants such as “Premiere” are assigned to the same production.

Points and stages. The point action “Booking made” awards points by source, product, price category, channel or minimum amount, once per order. Stages count bookings, upcoming and past events, distinct events and the months since the last booking.

Which email sold? Every new booking is attributed to the campaign email the visitor received in the seven days before, preferably one they opened. The “Transactions” report shows revenue by campaign, segment, performance and channel.

Ask the assistant. The AI assistant analyses the bookings, for one visitor or the whole house: by channel, production, category, month or buyer, for a single source if you wish.

What you need

On the Ticketcorner side:

• An agreed sales export containing the fields you need
• A location both sides can reach: a directory or an SFTP account
• A settled delivery rhythm

On the Caymland M4 side:

• Activate the Ticketcorner integration and configure how files are collected
• Define the column mapping once
• Set the schedule and decide whether maintained fields stay protected

Setting this up is a matter of one appointment, not a project.

For Ticketcorner.Inhouse and Ticketcorner.Tixx you need access to the respective interface instead of a drop location: Eventim’s credentials for Inhouse, a key for Tixx Connect for Tixx. Caymland M4 sets up the Tixx webhooks itself.

What this looks like day to day

The follow-up. Two days after the performance, an email goes to everyone who actually attended, pointing to the next production in the same genre. Not to the whole list.

The reactivation. Someone who booked nothing for two seasons but attended regularly before that gets an offer of their own. The segment maintains itself, because every import updates it.

The regulars. Anyone booking several times across the season collects points and moves into the stage where the subscription conversation lives – without anyone keeping a list.

The reminder before the evening. Three days before the performance, every buyer receives an email with the start time, venue and their seat, plus the production’s text and image. Nobody compiles a list for it.

The home match. A club sells through Tixx. Anyone who has bought ten tickets this season gets an offer of their own before the derby, and anyone who booked as a group gets a note on getting there.

The email that sold. After the season preview, the report shows how much revenue came from buyers who had received that email in the seven days before their booking.