Running an event's inbox without a spreadsheet

Event email has a distinctive shape: almost nothing for weeks, then a wall in the final two days, all of it urgent to the sender and most of it answerable from a document nobody read. Somebody ends up answering four hundred variations of "what time does it start" while also trying to run the event.

3 August 2026 · 4 min read

The three phases, and what each needs#

Before. Registration confirmations, invoices, dietary and accessibility requirements, joining instructions, and a steady trickle of questions. An agent handles all of it from the event record, and the useful trick is that a confirmation with the real details attached prevents most of the later questions.

The last 48 hours. Where is it, what time, can I bring someone, I lost my ticket, my train is cancelled, is there parking. Volume multiplies and the questions get simpler, which is exactly the shape an agent is good at. This is also when a human is least available to answer, which is why the return here is unusually high.

During and after. Live changes, no-shows, feedback, and the certificate or recording people ask for. Live changes are the risky part and belong to a person; the rest is routine.

What it must not decide#

Accessibility is the row people get wrong. An agent can and should record the request and confirm receipt immediately, because a fast acknowledgement matters enormously to the person asking. What it must not do is answer whether the venue can accommodate something, since being wrong about that is the kind of failure people remember for years.

Allergies are the same shape: record precisely, confirm receipt, and route to whoever briefs catering. Never reassure.

The confirmation is the whole design#

Most later questions are caused by a thin confirmation email. A good one closes off the top ten questions before anyone asks them, and it is the one message everyone actually opens.

send_email {
  to: ["attendee@example.com"],
  subject: "You are registered: Agents Summit, 12 September",
  body: "Doors 09:00, first talk 09:30, ends 17:00.\n\nVenue: Kaapelitehdas, entrance C. Nearest metro Ruoholahti, 8 minutes on foot. No parking on site.\n\nYou told us: vegetarian, no accessibility needs. Reply to this message to change either.\n\nReply here for anything else, including transfers, which we can do until 5 September."
}

Two things happening. Everything reflected back is a chance for the attendee to correct it now instead of on the day. And the reply path is one thread, which the agent then owns for the whole lifecycle, so a question in September lands in the conversation that started in July.

Surviving the spike#

The last two days are a burst, and bursts need the mechanics rather than good intentions: per-thread serialisation, an idempotency check, and a cap on concurrent sends so a spike degrades into a queue rather than a wall of refusals. That is the same setup as what happens when forty messages arrive at once.

Two event-specific additions. Decide in advance what the agent says when it does not know, because "I will find out and come back to you" is a better answer at 22:00 the night before than a guess. And put a hard stop on the agent making commitments about the day itself, since a promise about a room, a slot, or a seat is a thing someone has to honour.

Transfers, cancellations, and the money boundary#

Transfers to another person are usually routine and safe to automate against your policy: check the deadline, update the record, confirm to both parties. Cancellations touch money and belong to a person unless your policy is genuinely mechanical, in which case the agent can apply it and say so plainly.

Where the agent must always stop is a request to bend the policy. "I know it says no refunds after the first, but" is a judgement call with a precedent attached, and the answer belongs to whoever owns the budget.

Afterwards#

The feedback request is worth sending from the same thread rather than a new campaign, because a reply to a conversation gets read where a broadcast does not. And the contact record is where the useful residue lives: what someone attended, their requirements, whether they showed up. Next year's registration then starts from something rather than nothing, per giving an email agent memory.

Questions#

What event email can an AI agent handle?

Registration confirmations, joining instructions, dietary and access details being recorded, transfers within policy, and the flood of simple questions in the final days.

What should never be automated?

Refunds and fee waivers, comped tickets, answers about whether the venue can meet an accessibility need, and any reassurance about allergy handling. Record and route those instead.

How do I reduce the last-minute flood?

Write a confirmation that answers the ten questions people ask later, and reflect back what you have on file so corrections happen early rather than on the day.

How does it cope with the spike?

The usual burst mechanics: serialise per thread, deduplicate on message id, and cap concurrent sends so a spike becomes a queue rather than a set of refusals.

Can it handle ticket transfers?

Yes, against a clear policy: check the deadline, update the record, confirm to both people. Requests to bend the policy go to a person.

What about the night before, when nobody is available?

That is when it is most valuable. Give it a clear "I do not know, a person will confirm in the morning" path rather than letting it guess about the day itself.