SeeTickets

The performance is postponed. Who tells the eight hundred people?

A date changes. A performance is cancelled, moved, the hall is swapped. In the ticketing system that is a status change, done in ten seconds.

The manual work starts afterwards. Somebody pulls a list, wonders whether it is the right one, pastes it into the mail tool and writes a message nobody prepared. That evening the first calls come in from people who received nothing.

The SeeTickets interface to Caymland M4 removes that routine. It notices that the status or the date of a performance has changed and can start a journey from it – to exactly the people holding a ticket for it.

What the interface gives you

• Changes are noticed, not reported. If a date moves or a performance changes status, that is a trigger and not a task on someone's list.
• Orders with every line. Not merely that somebody bought, but what: performance, category, quantity, price, payment and delivery method.
• Customer details come along. Address data from the ticketing system lands on the contact instead of staying locked inside the box office.
• Content that differs per recipient. A section of a mailing can be tied to a condition drawn from that contact's own orders.
• Five triggers for campaigns. From a new order through to a postponed date.

Five triggers

The last two are why this interface is different from a plain sales import for a house with a programme. They watch the performance itself, not only the purchase.

What comes in

Out of this the contact gains a view of their own orders – and the basis for segments such as "booked this production".

Content that differs per recipient

A mailing does not have to look the same for everyone. A section can be tied to a condition drawn from the recipient's orders: it appears only for those it applies to and disappears completely for everyone else.

That turns a send to the whole audience into an email that shows one person the note about their performance and the other nothing of it. It stays one mailing, not a dozen variants.

How the data arrives

Direction: from SeeTickets to Caymland M4. Nothing is written back. Your sales and your programme are untouched.

Connection: through the SeeTickets interface, with credentials and a sales channel. No file exchange, no drop location for anyone to maintain.

Job-based. Caymland asks SeeTickets to prepare the data for a period – events, customers, orders and line items. SeeTickets works through the request in its own time. The next run asks for the state, collects the finished package and reads it in.

What that means: the data is as current as the last completed job, not accurate to the second. For confirmations, cancellations and postponements that is fast enough. For a display updating by the second it is the wrong technology, and we would rather say so up front.

Nothing is lost if a run misses. Every job is held with its state. A job that was not finished on one pass is collected on the next.

Changes are detected, not assumed. On reading in, what has changed against the stored state is compared. Only an actual change to date or status triggers anything. A package delivered again unchanged triggers nothing.

What you need

On the SeeTickets side:

• Access to the interface with address, username and password
• The identifier of your sales channel
• The address of the event listing

On the Caymland M4 side:

• Activate the SeeTickets integration and store the credentials
• Set the schedule for collection
• Build the journeys that hang off the triggers

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

What this looks like day to day

The postponement. A performance date changes in the ticketing system. The next comparison spots it, the journey starts, and everyone holding a ticket has the new time in their inbox. Nobody pulled a list.

The confirmation with substance. After the order, it is not the ticketing system's standard mail that goes out but yours – with directions, catering and a note about what fits the performance booked.

The look back after the season. Someone who attended several times gets a different mailing from someone who came once. Both sit in the same list, and the difference comes out of their orders.