How do you run a wedding band's admin online, not in a group chat?
Put every gig in one place the whole band can open: the date, venue, times, set, who is playing and each player's pay and travel. Here is how.
Put every gig in one place the whole band can open, with the date, venue, times, who is playing, the set, and each player's own pay and travel. Then the group chat goes back to being a chat, and nobody has to scroll to find out when they are due on site.
It is a quarter to eight on the morning of a wedding. The drummer is asking whether the call time is eleven or half past. The singer is asking which of three first-dance versions the couple finally chose. Somebody has found last week's message with the venue's postcode in it and is not sure it is the right one. The keys player, who has never been to the venue, is asking whether there is parking.
All of that was known. All of it was said, somewhere, to someone. The band does not have an information problem. It has a where-is-it problem, and a group chat is a poor answer to that.
The short answer to the title: put every gig in one place the whole band can open, with the date, venue, times, who is playing, the set, and each player's own pay and travel. Here is what that looks like for a wedding band's admin, in the order it comes up.
What does a wedding gig actually need the band to know?
More than a typical gig, because the day is built around somebody else's timetable. The day sheet covers it in detail, but the questions people actually ask boil down to these.
Where, exactly. The address and the postcode you should drive to, which for barns and estates is often not the postcode on the invitation. Where to unload and where to move the cars afterwards.
When. The call time (when to be there, which is often hours before you play), the sound check, each set's start and finish, and the time the music stops.
The first dance. The song, the artist, the version, and whether the band is playing it or it is going through the PA. This is the line that causes the most trouble on the day, because it cannot be fixed at eight o'clock.
What the couple asked for. Songs they want, songs they do not, anything about volume, and any moment (the meal, the speeches) when the band is asked to be quiet.
Who is who. A name and a mobile number for the venue's contact and for whoever runs the band's side.
If a wedding band has those on one page per gig, most of the morning's messages never get sent.
What does the group chat lose?
It loses things in three predictable ways.
Changes. The call time moves. The leader posts it. Half the band sees it. Nobody can tell, afterwards, which message was the latest, so some people act on the old one.
New people. A deputy or a new member joins and sees nothing before the day they arrived. Everything they need to know about a gig is in a conversation they cannot read.
Order. A question gets answered four messages later, after two other questions, and the answer is attached to the wrong one. Anyone coming back a week later has to read the whole thing to find out what was decided.
None of that is anyone's fault. A chat is an excellent way to talk and a poor way to hold facts. The sensible move is not to ban it. It is to give the facts their own home and let the chat do what it is good at.
The real test of a wedding gig's admin is the morning itself. If the band can arrive on time, at the right door, with the right song learned, and nobody had to ask the leader anything on the way, the admin worked. If the leader's phone was ringing from seven o'clock, it did not, however tidy the spreadsheet or the chat looked the week before.
What should every player be able to see without asking?
This is the test for whether the arrangement works. Write the list, and if any item needs a message to the leader, it is in the wrong place.
- Their next gig: date, venue, call time, and the line-up, on a phone, without logging in to anything complicated.
- The day sheet, readable at the venue, including when the signal is poor.
- The set, with the keys, so a player can look at it on the way.
- Their own pay and travel, worked out from their own postcode, and the statement that records it.
- Whether they are free, and the days they have said they are not, shown to the person who books.
What they should not see is anyone else's business: the manager's cut, other people's private days off, the band's other bands. A good arrangement shows each person their own line, and only the parts of the rest that they need to do the job.
What about deps, and the dep's setlist?
A wedding band loses a player more often than it expects. When a member is covered, the dep needs exactly what everyone else gets for that gig: the sheet, the times, the set and the first dance. Nothing more, and ideally two or three days early rather than the night before.
The practical way to do that is for the dep to be added to the gig itself, so they see that gig's page and not the band's diary. The set is the part that decides whether they arrive ready. A dep who has the keys, the order and the endings in advance plays the night properly. One who has a list of titles two hours before is guessing.
It also keeps the money simple. The band pays the member as though they had played, the member settles with the dep, and the dep's travel is worked from where they live, not where the member does.
How does the money work, in one line?
Travel comes off first, the rest is split equally, and each player gets a statement.
That is the common arrangement and the reason is fairness: the player who drives furthest is not quietly subsidising everyone else. The reasoning, and what to do when the arrangement is different, is in how function bands split gig money. The only thing that matters for the admin is that the arithmetic is done the same way every time, and that each player can check their own figures. The split calculator will show you what a given gig comes to before you agree anything.
How do you start, with the next gig?
Not by moving everything. Pick the next wedding in the diary and run that one properly.
- Create the band and say who runs it.
- Invite the players with one link each. The first thing they should see is their next gig.
- Add the gig: date, venue, times, the line-up, the set and the first dance.
- Attach the day sheet, whether the agency sent one or you wrote it.
- Tell the band the gig is there, and stop answering questions about it in the chat. Point at the page.
- After the night, look at the statement together and fix what was awkward.
One gig is enough to find out whether it works. If it does, add the next. If you want the bigger picture of what the site does for a musician's own diary across several bands, the musicians' page goes through it, and the features page lists each part.
The wedding itself will still be a long, tiring day. The point is that the band does not spend the morning of it trying to find out the call time.
See it in the app. Gigs, everyone's travel worked out from their own postcode, an equal split to the penny and a statement each at the end of the month: free for a band running itself.