Band coordination · Guide
How to keep a gigging band organized (without becoming a project manager)
Nobody starts a band to send reminder texts. But if you run one that plays paying gigs - covers, weddings, functions, whatever keeps the calendar full - you already know that the playing is the easy part. The hard part is everything around it: who is on the gig, what key are we doing that song in now, does the sub know the set, and which version of the song list is the real one.
That work lands on one person. Usually the bandleader, sometimes just whoever cared enough to keep the list. And most of the time that person is doing it with text threads, a shared spreadsheet they cannot trust, and their own memory filling the gaps.
This is how to take the admin weight off that one person without turning your band into a workplace with standups and a task board.
The coordination problems that actually kill gigs
Bad coordination does not usually blow up a gig in a dramatic way. It just makes the night harder than it should be, in small cuts.
The sub shows up having learned the original arrangement. Nobody told them the band does a different ending. Someone counts off a tune in the wrong key because the key changed after the singer got sick last year and the spreadsheet still says the old one. Two people are looking at different setlists because the one the bandleader texted got revised in a later message nobody read.
None of these are music problems. The band can play. The band just cannot keep its own information straight, because the information lives in too many places and nobody appointed themselves the librarian.
The text-thread-and-spreadsheet approach
Most bands end up here. It works for a while, and it is worth understanding why it eventually stops.
A shared spreadsheet holds the song list with keys and tempos. A group chat handles everything else: who is available, what the client asked for, what the set order is, last-minute changes. Sometimes a shared calendar for gig dates. Sometimes a Google Drive folder that three people have access to and one person updates.
This system runs on the diligence of the one person who maintains it. When that person is consistent, it holds. When they are busy, tired, or sick for a week, it drifts. And the drift is invisible until someone calls a tune in the wrong key or a sub walks in cold.
Where it breaks
It breaks in three places, reliably.
- The sub problem. A substitute player shows up for one gig. They need the set, the keys, the arrangements, and any quirks. In the text-and-spreadsheet model, that means the bandleader manually assembles all of it and sends it over, hoping nothing has changed since the last time they checked. If the sub plays with the band regularly, they end up keeping their own copy of the song list, which quietly diverges from the real one.
- The version problem. Any time two copies of the same information exist, they disagree. It is not a question of if, it is when. The spreadsheet says Ab, the bandleader’s phone says A, and the argument happens on stage in front of the room.
- The night-before scramble. Building a set the night before a gig means sitting down and trying to remember which songs the band still does, which ones got dropped, and which ones the client requested. If the repertoire is scattered, this takes longer than it should and the result is less reliable than it should be.
How Setlist handles it
Setlist is built around one idea: the band shares one library, and everything flows from it.
Every song sits in one place, with the key you play it in, the tempo, the structure, and who takes which solo. Everyone in the band sees the same library on their own phone. When something changes - a key moves, a song gets dropped, a new one gets added - it changes once and everyone has it. No second text, no "check the new version," no wondering which copy is current.
When a sub joins, you invite them and they have the book on their phone instantly, current as of right now. They walk into the gig knowing the set, the keys, and the arrangements without the bandleader having to assemble a care package from five sources.
Building a set is pulling songs from that library into an order. The running time adds up as you go. When the client changes the plan or the room needs something different, you reorder in seconds and the whole band’s screens update. For the full picture on running the set live, see how to run a setlist on stage.
The person who runs the band still runs the band. But they stop being the human sync engine between everyone’s outdated copies of the truth.
What it will not do
It will not schedule your rehearsals, negotiate your fee, or manage your calendar. It does not handle contracts, deposits, or client communication. Those are real needs, and there are tools for them, but Setlist is not trying to be your band’s ERP system.
It also will not fix a band that does not communicate. If nobody tells the sub that the third song has a different ending, no app saves that. What Setlist does is make sure the factual stuff - keys, tempos, arrangements, the set order - is settled and shared, so the communication that matters is about the music, not about which spreadsheet to trust.
One person, one library, one truth
If you run a band and you are tired of being the human backup drive for every key change, arrangement note, and set order, the fix is simpler than you think. Put the book in one place that everyone can see and nobody can accidentally fork.
Setlist is free on the web and in open beta on iPhone. Invite your band, build a set for your next gig, and see how fast the admin weight drops. Then reply and tell me what your band needs that it does not have yet.
Common questions
How do you keep a cover band organized?
Put the whole repertoire in one shared place with the keys, tempos, and arrangements, so it changes once and everyone has it. The chaos comes from many copies of the same information disagreeing.
What is the hardest part of running a gigging band?
Not the playing. It is the coordination: who is on the gig, what key a song is in now, whether the sub knows the set, and which version of the list is real.