A concert announcement should not be copied five times

Adding a concert sounds like a small administrative task. In practice it used to mean opening Bandsintown, checking the Virya website, preparing a Facebook post, deciding whether the mailing list should hear about it, reminding the team and then remembering to do the same thing again closer to the date.

This is exactly the kind of work that looks harmless because every individual step takes only a few minutes. The cost appears later, when one place has the new date, another has the old venue and the reminder exists only in somebody's head.

One event, one source of truth

I made Bandsintown the starting signal, not the owner of the complete process. A new or updated event enters one workflow, is normalised into our own event shape and receives a stable identity. The workflow can then decide what actually changed: a new show, a changed time, a new ticket link or a cancellation. “The API returned an event” is not yet a reason to announce anything.

That distinction matters because synchronisation retries. APIs repeat records, schedules overlap and a provider may return the same event in a slightly different order. Without a stable event key, one concert quickly becomes three posts and two contradictory reminders. Every external action therefore has its own idempotency key and status.

Prepare first, publish later

The next step is preparation, not blind publication. The workflow builds a factual social draft from the city, venue, date and verified ticket link. It prepares an email for the relevant fan segment and can include a Bandsintown follow link, because following the artist there makes future concert discovery easier for both sides. Discord receives a compact preview showing what changed and what needs approval.

I deliberately kept cold social messages out of this flow. Facebook and Instagram permissions are complicated, APIs do not always allow a conversation to be initiated and “technically possible” is not the same as “good idea”. A public announcement and an email to somebody who explicitly subscribed are useful. Automatically bothering every profile in the CRM is not.

Make the message less stupid

The city data from CrowdRelay makes the email less stupid too. A show in Wrocław does not need to be presented with the same urgency to every person in Poland. The system can prioritise people who selected the city, showed interest in nearby concerts or asked for reminders. It is still one mailing list, but the message finally has some context.

Changes are events too

Cancellations and major changes use the same event identity. They do not create a second fictional concert. The workflow marks the existing record, prepares the correction and prevents scheduled reminders from confidently promoting something that no longer exists.

The human checkpoint stays

There is still a human checkpoint before public communication. The machine is good at copying verified facts into several formats and remembering the next date. A person should still notice that the venue asked us to wait until Monday or that the ticket link currently points to last year's event.

The result is not a magical social-media agent. It is one clean path:

One concert now becomes one operational record instead of five loosely related chores. That is the kind of automation I trust: not because it talks loudly about AI, but because it quietly stops us from forgetting the boring part.