The data you already have and are not using
Your data is scattered across ticketing, a spreadsheet and three forms. Having emails is not having a database, and the difference shows.
The week before your event, it’s always the same story. Message volume multiplies, it arrives from four different places at once, and the team that should be locking down production is instead explaining what time the doors open.
The strange part of that flood is that it almost never brings new questions. They’re the same ones from the last edition, and the one before that.
Do the count, even if it stings
Pull the conversations from the week before your last event — WhatsApp, email, social media DMs — and sort them by topic. It doesn’t need to be exhaustive: with two hundred conversations the pattern is already visible.
What comes up almost every time is this:
- Opening times and set times
- How to get there, where to park, transport back
- What you can and can’t bring in
- Whether tickets are personalised and how to change the name on one
- How to recover a ticket they can’t find
- Whether you can pay cash on site
- Minimum age and access for minors
- What happens if it rains
- Refunds and date changes
- Accessibility and companion tickets
Ten or fifteen categories already cover eighty to ninety percent of the volume. The rest are genuine edge cases that need a person.
That percentage is the important number in this article. Most of what your team handles during the highest-pressure week of the year is repeating information that’s already written down somewhere.
Why publishing an FAQ page isn’t enough
The obvious reaction is to put a frequently-asked-questions page on your website. Almost every promoter has one. And the questions keep coming anyway, for two reasons worth understanding before you try to fix this.
Nobody searches for information: they ask for it. When someone has a question at eleven at night with their ticket already bought, they don’t open your website and scroll to the footer. They message the channel they’re already in touch with you through — usually Instagram or WhatsApp. Asking is faster than searching, and that behaviour isn’t going to change.
The question is usually about their specific situation. It’s not “can I change the name on a ticket?” — it’s “I bought four tickets and a friend can’t come anymore, what do I do?” A static page doesn’t answer that. And that’s exactly the difference between published information and support.
The real cost isn’t the time
It’s easy to see this as a problem of work hours. It is one, but it’s not the most expensive part.
It interrupts you exactly when you can least afford it. Answers get typed while production is being locked down, suppliers are being coordinated, and last-minute problems are being solved. Every interruption costs far more than the two minutes it takes to write the reply.
Quality drops as the week goes on. Monday’s answers are thorough. Thursday’s, at midnight, are three words long. And whoever gets Thursday’s answer forms the same opinion of your event as whoever got Monday’s.
Messages get lost. When volume spikes and it’s split across several phones and several inboxes, some go unanswered. They tend to be exactly the ones that arrive latest — which means the people with the most urgent need.
And there’s a cost almost nobody counts: some of those questions are sales. Someone asking whether there are still tickets left for Saturday, or whether they can upgrade their pass, is one message away from buying. If that reply takes two days, they don’t.
What you can actually automate, and what you can’t
Automating support has a bad reputation in this industry, and fairly so: everyone has suffered through a bot that understands nothing and only delays the moment you finally get to talk to a person.
The difference between a useful one and an unbearable one comes down almost entirely to how much it knows about your specific event. An automated assistant that knows your schedule, your access rules, your change policy and the status of orders resolves most of the volume without friction. One that only has generic answers creates more work than it saves, because people write in again — and this time, annoyed.
Which points to a practical rule worth respecting: it’s better to have no automated assistant than a badly prepared one. And another: there always has to be a clear path to a human, without anyone having to fight for it.
What’s worth automating is stable information: schedules, access, rules, transport, change policy. What isn’t: complaints, issues with a specific order, anything that arrives from someone who’s upset.
Do the work now, not during event week
Preparing this takes an afternoon, and the trick is doing it in a gap between events, not the week before. If you leave it for then, you won’t do it: that’s exactly when you don’t have a spare minute.
Start with the cheapest step, which pays off whether or not you use any tool: bring every conversation into one place. Before automating anything, simply no longer having messages scattered across three phones and two inboxes already removes most of the chaos — and most of the lost messages.
Then write the answers to those fifteen questions once, properly, unhurried, with the real detail of your event. That document is useful for the automated assistant, for the website, for the box-office team, and for whoever joins the team next year.
Tools like Nevent bring every channel into a single inbox and let you set up an assistant that answers with the real context of your events and your orders. But the first step doesn’t need any tool at all: open the conversations from your last event and count how many times you answered the same thing.
Frequently Asked Questions
What if my event is small — is a chatbot worth it?
It depends on the volume of repeated questions, not on the size of the event. If you get dozens of identical messages the week before, the saving is there. If it is five a day, preparing it probably is not worth it.
Which questions should never be automated?
Complaints, issues with a specific order, and any conversation that starts with an upset customer. A bot adds friction there. Automate stable information instead: schedules, access, rules, transport and change policy.
