How bands stop double-booking themselves

A client asks for the fourteenth of June. The leader checks the diary, sees nothing, and says yes. Two weeks later the bass player mentions, in passing, that he is in Portugal that week — he told the band in March, in a message that is now four hundred messages back.

Nobody forgot anything, exactly. The information existed. It was just in a different place from the diary the leader looked at.

That is what a double booking almost always is. Not carelessness, but a band keeping more than one record of itself and asking the wrong one.

Why do bands double-book themselves?

Because every function band accidentally keeps three calendars, and no two of them agree.

The band's diary. The confirmed gigs, wherever they live — a spreadsheet, a shared calendar, a leader's notebook. This is the one people check before saying yes, and it is the one most likely to be right about gigs and completely blank about everything else.

The agency's sheet. If your work comes through agencies, they hold dates too: offers, pencils, enquiries that have not landed. Some of those never reach the band at all until they firm up, so a date can be genuinely spoken for without appearing anywhere the band can see.

Everybody's own calendar. Six players, six jobs, six families, six sets of other bands. Nobody sends the band a list of their holidays. They mention them.

A gig is lost between these three, not inside any one of them. The leader checks calendar one, which is accurate about calendar one, and answers a question that needed all three.

What actually holds a date?

Before you can fix it you need a rule about what counts as taken, and bands are surprisingly vague about this.

Three states are worth separating:

• Confirmed. The band is playing. Obviously taken.
• TBC. An agency has offered it or a client has asked, and you are holding it while the enquiry resolves. This is the one bands are careless about, and it is the most common source of a genuine double booking: two agencies asked about the same Saturday, both were told yes, both came good.
• Cancelled. The date is genuinely free again, and it needs to stop blocking enquiries the moment it is cancelled rather than lingering as a ghost in somebody's spreadsheet.

The practical rule is that a TBC date is unavailable for other work but is not yet money. It belongs in the diary and it stops you saying yes twice. It does not belong on a statement or in anybody's forecast.

Get this rule stated out loud and half the problem disappears. Most bands have never actually agreed whether a pencil blocks a date, which is why two people answer the same enquiry differently.

Days off: the part that is always missing

Gigs get recorded because somebody is being paid. Days off get mentioned, which is not the same thing.

The awkward bit is that a day off is a fact about a person, not about a band. If your drummer plays in three bands and tells one of them about a wedding anniversary, the other two are none the wiser — and at least one of them will offer that date to an agency.

So the record has to work like this:

• Per person, not per band. Each player enters their own, once.
• As a range, not a date. People are away for weeks, not days, and a range entered once is a range that stays right.
• Entered by the player. A leader relaying "I think Sarah said something about August" is how the information degrades.
• Visible to the bands that player is in. Not to the whole world, and the reason is nobody else's business — a leader planning around it benefits from knowing it is a honeymoon rather than a maybe, but a bandmate only needs the fact.

That is how days off work in Event Band Manager: a player enters their own, once, and every band they are in sees it before accepting a date rather than after. It is a free feature because it does not work at all unless everybody uses it, and everybody will not use something that asks them to pay first.

If you are building a band's admin from scratch, this belongs in the first week alongside the diary itself — the practical setup checklist has the rest of that list.

How do you answer "are you free?" in one go?

The three calendars problem is really a lookup problem. Somebody asks about a date, and answering properly means checking a diary, a sheet, and six people's private lives.

What you want is one place that already knows all three, so the answer takes seconds rather than a round of messages. That means:

1. Gigs, including TBC ones, in one diary.
2. Days off, per person, in the same diary.
3. One month view that shows both at once.

Once those three are true, "are we free on the fourteenth?" is a glance rather than a project, and the answer is the same whichever member of the band is asked. That last part matters more than it sounds: a band where three people can quote availability is a band that can take a booking on the phone.

There is a further step, which is letting the client ask directly. A public enquiry page can take the date somebody types and answer free or not free immediately, without revealing what is in the diary or why the date is gone. The band stops answering the same email a dozen times a month, and the enquiries that arrive are for dates it can actually play.

Does it need to be in everyone's own calendar?

Yes — because the calendar a player actually looks at is the one on their phone, and no amount of good band admin changes that.

But there are two ways to get gigs in there and only one of them survives contact with reality. Typing the dates across by hand works until the first time a call time moves or a venue changes, at which point the personal calendar is quietly wrong and nobody knows. Subscribing to a feed means the gigs arrive and then keep themselves right.

A feed should be read-only, should cover every band that player is in rather than one, and should touch nothing else in their calendar. Deps matter here too: somebody covering a gig needs that date in their own diary as much as a member does, and needs nothing else from the band's. How the personal feed works for a player is the same idea — one address, subscribed once, every gig they play or cover.

The point is not tidiness. It is that when the band's record changes, the player's record changes with it, so there is never a version of the truth walking around in somebody's pocket.

When two dates do collide

They will anyway. Availability admin does not stop clashes, it moves them earlier — and that is the whole value.

A clash spotted six weeks out is a phone call to a good player who is probably free. The same clash spotted on the Tuesday is a scramble through whoever picks up, and the band plays with somebody it has not rehearsed with and does not entirely trust. The gig is the same either way; the standard is not.

So when a clash appears:

• deal with it the day you see it, not the week of the gig;
• go to a known dep first, because a player the band has used before is worth more than a better player it has not;
• send the person covering the day sheet properly, rather than the bits somebody remembers;
• and record it, so next year's version of the same weekend is not a surprise.

A short checklist

Six things, and a band that can say yes to all six will not double-book itself twice:

1. There is one diary, and everybody knows which one it is.
2. TBC dates are in it, and the band has agreed out loud that a TBC blocks the date.
3. Cancelled dates come out of it straight away.
4. Every player enters their own days off, as ranges, without being chased.
5. One view shows gigs and days off together, so "are we free?" is a glance.
6. Gigs reach players' own calendars by subscription, not by typing.

None of that is sophisticated. It is just the difference between a band that answers an enquiry in a minute and a band that answers it in three days, having asked six people — and then says yes to the wrong Saturday anyway.