One Gig, Five Email Versions: Keep Setlists and Client Changes Under Control

Why the problem gets worse as you get busier

Almost no band decides to run its gigs on contradictory emails. It happens gradually. The client sends a first dance song. A planner moves the speeches. The bandleader replies to one thread, the drummer forwards an older one, and the dep keyboard player only ever saw the first draft. The headline's five email versions is an illustration, not a measured figure. The pattern behind it is real. In one Reddit thread, a musician running a wedding band said logistics, setlists and timings were being handled through long email chains, and that shared notes holding client information went out of date as bookings increased [R1]. That is one person's account, not a survey, but plenty of working bands will recognize it.

The cost shows up on the day. A player arrives for a load-in time that changed two weeks ago. A song is rehearsed in the wrong key. A guest's special request gets missed because it was only in a reply sent to the bandleader. None of these failures needs a new app to fix. What fixes them is a clear rule about which document counts as the truth, and a clear person responsible for keeping it current.

Create a single gig record with an owner, status and last-updated time

Start with one record per gig. A shared document, a spreadsheet row or a page in a tool you already use will work. The format matters less than three fields at the top. The first is the owner: the one person allowed to change confirmed details. The second is the status, such as enquiry, contracted, details pending, final brief sent, performed or archived. The third is a last-updated date and time, so anyone opening the record can tell at a glance whether it is fresh.

This is where band setlist version control begins. If the record says it was last updated on September 12 and you are holding an email from September 20, you have found a gap and should ask the owner about it. Do not edit it yourself. Resist buying a project-management product until the band has run this manual process on a few gigs. The Reddit poster was asking about software [R1], which makes sense, but a tool cannot fix a workflow nobody has defined. It only stores the confusion more neatly.

• Owner: one named person, with a backup for illness or travel
• Status: a short list of agreed labels the whole band uses
• Last updated: date and time, changed with every edit to confirmed details

Separate confirmed client requirements from internal working notes

Most version confusion comes from mixing two kinds of information. Confirmed requirements are things the client has agreed to in writing: the date, venue, arrival time, performance windows, key songs and the approved lineup. Working notes are the band's internal discussion, such as whether to cut a medley, who might sub on bass, or a rough idea for the encore. When both live on the same page, players can't tell a decision from a suggestion.

Keep confirmed details in the top part of the record and put internal notes in a clearly labeled section below or in a separate document. A good test: if a dep read only the confirmed section, could they do the gig correctly? On the contract side, the UK Musicians' Union recommends that engagement terms be in writing and that the date, time and place be confirmed [S1]. That is a UK organization and not a source of US law, but it supports a practical baseline. The facts a player must act on should be written down and confirmed, not inferred from a conversation.

What the gig record must capture

Wedding band client changes usually affect a small number of fields, so make those fields mandatory. Arrival and load-in time, access notes, set times, the on-site contact for the day, cue points such as entrances, speeches and cake cutting, the setlist with keys and any edits, special requests, and the approved lineup are the core. Players can't find out any of this on their own, and every item can go wrong if a player only has an older version.

Keep the approved lineup as its own field rather than letting it be implied by who was copied on an email. If a dep replaces a regular member, the record should show it and the dep should receive the brief directly. Cue points deserve particular care, because they often change at the last minute and depend on someone other than the band, such as a planner, venue coordinator or officiant. Record who on site gives each cue, not just the planned time.

• Arrival, load-in, soundcheck and downbeat times
• Day-of contact, with a role-based label where possible
• Cue list showing who signals each moment
• Setlist with keys, edits and the first dance or processional version
• Requests and do-not-play songs
• Approved lineup, including any deps

Log changes and their cost or rehearsal implications

Every change request should get a dated line in a change log: what was asked, who asked, when, and the band's response. Before you say yes, write down what the change actually involves. A new first dance in an unusual key may need a rehearsal. An extra hour changes the fee and possibly travel. A later finish could affect dep availability. Recording the effect before agreeing stops the band from absorbing costs nobody discussed.

Once a change is accepted, the owner updates the confirmed section and the timestamp together. Anything still under discussion stays in the log marked pending, not in the brief. Whether a change needs a written contract amendment depends on your agreement and the law where you are working. The union's emphasis on written terms [S1] is a sensible habit to follow, but the US rules on amending a performance agreement are not something this guide can settle for you.

Red flags: how to verify a change is genuine

Too many inboxes create a practical risk as well as a scheduling one. A change request may come from an address you don't recognize, or may claim to be from the planner when you have never dealt with that person. A message about changing payment details, deposits or where to send money is the most serious version of this, because a fraudulent instruction can redirect funds. Treat any message that combines urgency with a new contact or new payment information as unverified until you have checked it.

To verify, contact the client or planner through details you already hold from the original booking, not through the details in the new message. Confirm the change in your own words and record the verification in the change log. Also watch for quieter warning signs inside the band. A player quoting times that match no version in the log usually means an old forward is still circulating. Track down where it came from rather than just correcting the player.

• New sender combined with an urgent request
• Any change to payment instructions
• A request to keep the change away from other parties
• Times that match no logged version

Distribute one final dated brief and get acknowledgements

At an agreed cutoff, such as one week out, the owner produces a final brief from the confirmed section only and labels it with the date and a version number. Send it to every player on the approved lineup in one message. Ask each player to reply with the version number to confirm they read that exact brief. A reply that just says thanks shows they received a message, not that they read the current version.

If something changes after the cutoff, issue a new numbered brief that says clearly what changed. Don't send a casual reply on an old thread. This one discipline would have prevented the problem the Reddit poster described, where important details were buried in long chains [R1]. It is the core of good musician gig logistics: one current document, one version number, and confirmation from every player.

Hypothetical worked example

Hypothetical: A five-piece band is booked for a Saturday wedding. Version 3 of the brief, sent the previous Saturday, lists load-in at 3:00 pm and a first dance in G. On Tuesday, the couple ask through their planner to move dinner earlier. The owner calls the planner on the number in the original booking file to confirm the request, then logs it. Load-in moves to 2:15 pm, which costs nothing extra. The owner issues version 4 with the change highlighted at the top.

Four players reply quoting version 4. The dep bassist does not reply. On Thursday, the owner calls him and finds he has only version 3 because it went to an old address. Without the acknowledgement step, he would have arrived 45 minutes late. With it, the problem was caught two days before the gig. The fix took five minutes and used no special software.

Protect client information, archive the performed version, and know when to escalate

Not every player needs the couple's personal phone numbers, home addresses or private family details. Put role-based day-of contacts in the player brief and keep personal client data in a restricted section that only the owner and the bandleader can see. Never post client contact details or private event information in public group chats or on social media. After the gig, save the version that was actually performed, including setlist edits made on the night, and add a short note on what to do differently next time.

Escalate when the issue is no longer about logistics. Seek advice from a lawyer licensed in the relevant state, or from a professional organization you belong to, if a client disputes the fee after a change, if changes amount to a different engagement from the one you contracted, or if you suspect payment fraud. In a fraud case, contact your bank promptly. A UK union's guidance [S1] is a useful starting point for a checklist, but it does not substitute for US legal advice.