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 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 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.

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.