Skip to content

gig-management

4 posts with the tag “gig-management”

Take Booking Requests From Your Own Website

Most bands take booking requests through a form tool bolted onto the website — Tally, a Google Form, whatever was quickest. It collects the enquiry and emails it to someone. Then the work starts: copy the date into the calendar, dig out the promoter’s address, write back, hope nobody else in the band already replied.

The form is doing half a job. The request arrives, but nothing is booked and nobody has answered. Here is how to close that gap by taking booking requests straight into the tool the band already runs on.

A standalone form tool ends at the notification. It has no idea the band has a calendar, an inbox, or four people who might each answer a promoter separately.

So the same three things happen every time a request comes in:

  • Nothing is on the calendar. The date lives in an email until someone types it into the band’s calendar by hand — and until they do, another gig can get booked on top of it.
  • The reply is manual and slow. The promoter hears nothing back until a band member happens to see the email and write one. A day of silence loses gigs that a same-day acknowledgment keeps.
  • The band answers over each other. Two members see the enquiry, two members reply, and the promoter gets a muddled picture of who runs the band.

None of that is the promoter’s problem to solve. It is the cost of a form that talks to an inbox instead of to the band’s own tools.

A booking form built into the band tool treats a request as the start of a gig, not the end of a form. One submission does two things at once.

It books a tentative date. The request becomes a gig on the band calendar, marked as an option so it reads as “asked, not confirmed” — visible to the whole band the moment it lands, so nobody double-books the night.

It starts a conversation. The requester gets an acknowledgment straight away, and — with a shared mailbox connected — a thread opens in the band inbox, linked to that gig. The band replies from there, and the promoter’s replies come back to the same thread. One place, one conversation, the whole band reading it.

The request stops being a notification to act on later and becomes a gig already sitting where the band works.

The booking form lives in Settings > Booking Form, next to the shared mailbox and rider pack settings. Setting it up takes calendar-edit rights, so owners, managers, and members can do it.

1. Choose the fields. Toggle what to collect — name, email, phone, event date, event type, location, and a message — and add custom fields for anything specific to the work you take. Keep it short: the fewer boxes a promoter faces, the more of them finish the form.

2. Set the language. Pick the form’s language and both the public page and the acknowledgment email follow it, so a promoter who writes in French reads the form and the reply in French.

3. Share it. Copy the hosted link for a Book Us button, or the one-line embed snippet to render the form inside a page on your site. Turn the form on and it is live.

Both are copyable from the settings panel; use whichever fits the site.

The hosted link opens the form as its own page and needs no website at all — it works from a link-in-bio, a social profile, or a message. Point a Book Us button at it and you are done.

The embed snippet is a single line of HTML that renders the form in-page, inside your own layout. Use it for a dedicated booking page on a site you control.

If a link ever needs pulling — it went to the wrong place, or you want a clean URL — rotate it from the settings panel. The old link stops working, any embed pointing at it goes dark, and you drop the new one onto your site.

The point of taking requests into the band tool is that nothing has to move by hand afterwards.

A booking-request gig lands on the calendar as an option. Confirm it, decline it, or firm up the date as the conversation goes — the same controls as any other gig. When it firms up, run a Gig Advance on it to collect load-in times, PA responsibility, parking, and contacts back from the organiser.

With a shared mailbox, the whole exchange sits in the inbox, linked to the gig, so anyone in the band can pick it up and nobody replies twice. Without one, the acknowledgment still goes out and the band’s notification recipients get an email they can answer directly — the promoter always hears back either way.

Why use a booking form instead of a generic form tool? A generic form drops an email in an inbox and stops there — someone still has to copy the details into a calendar and write back. A booking form built into the band tool turns each request into a tentative gig and starts the reply automatically, so the booking is already where the band works it.

Do I need my own website to use a booking form? No. The form has a hosted link that works on its own, so you can share it from a link-in-bio, a social profile, or a message. If you do have a site, an embed snippet renders the form in-page inside your own layout.

What happens to a booking request after it comes in? It creates a booking-request gig on the calendar, marked as an option so it reads as tentative, and it sends the requester an acknowledgment. With a shared mailbox connected, a thread appears in the inbox linked to that gig and the band replies from there; without one, the band’s notification recipients get an email they can reply to directly.

Can I revoke a booking form link? Yes. Rotate the link from the booking form settings and the old one stops working, along with any embed pointing at it. Update the button or snippet on your site with the new link afterwards.

How to Advance a Show: The Bandleader's Checklist

Most gigs that go wrong were losable weeks earlier. The PA turns out to be two powered tops on sticks, the load-in door is up a flight of stairs, the curfew is 22:30 rather than midnight, and nobody knew because nobody asked.

Advancing the show is the conversation that prevents all of it. Here is what to cover, when to do it, and what to send.

Advancing a show means contacting the venue or promoter ahead of the date to confirm every logistical detail in writing — times, sound, access, hospitality, and contacts.

It is not a formality reserved for touring acts. A function band playing a hotel ballroom benefits as much as a support act at a 500-capacity club, and the checklist is largely the same.

The important thing is that it runs in both directions. The band sends what the venue needs to plan the stage. The venue confirms what it is actually providing. Advances fail when only one half happens — a band that emails a rider and hears nothing back has not advanced the show.

Between two weeks and one week out for a normal club or function gig.

Earlier than a month and the details are still soft: engineers change, set times move, support acts get added. Later than a few days and there is no room left to fix whatever the advance uncovers. If the curfew is an hour earlier than assumed, a week is enough to cut two songs and a support slot; two days is not.

Festivals and support tours usually advance through a production manager on their own schedule. Follow theirs.

The two halves are worth keeping separate, because they have different owners.

What the band sends. The technical rider, the stage plan, the input list or patchlist, and the hospitality rider. This is the band’s own paperwork and it should not change gig to gig — write it once, keep it current, send the same pack every time. The venue cannot plan a stage without knowing how many inputs the band needs and who stands where. Soundcheck prep covers what belongs in that pack in detail.

What the band asks for. Everything below. These are the answers only the venue has.

Five sections. Get all of it in writing, and treat a verbal answer on the phone as something to confirm by email afterwards.

Field Why it matters
Load-in time When gear can come into the building — often earlier than the band expects, and sometimes the only slot
Soundcheck time Sound on stage before doors, if there is a soundcheck at all
Doors time When the audience is let in, which caps how long soundcheck can overrun
Set times Which act plays when, and for how long
Curfew The hard stop for live music

Curfew is the field most often left vague and the one most likely to cut a set short. A venue with a residential licence may stop music at 23:00 regardless of what the poster says. Confirm it as a time, not as “late”.

Field Why it matters
PA responsibility House, band, or hired — three genuinely different evenings
Backline provided Drum kit, bass and guitar amps, keyboards
Stage power How many outlets, and where they are
Tech rider received Confirmation the venue actually has the rider, not just that it was sent

“There is a PA” means nothing on its own. A house system with a resident engineer and a pair of powered speakers on sticks are both technically a PA. Ask which, and ask whether an engineer comes with it.

Backline matters most for fly dates and shared bills. If a drum kit is provided, find out whose it is and whether the drummer is expected to bring breakables.

Field Why it matters
Catering Meals, drinks, and dietary requirements
Green room Somewhere to put cases and get changed
Guest list spots How many, and who to send names to

Guest list is the one that causes friction on the night if it was never agreed. Get the number, and get the address to send the names to.

Field Why it matters
Parking Where, whether a permit is needed, and how long you can stay
Load-in access Nearest door, and any stairs, lift, or ramp
Address notes Anything awkward about finding or entering the building

Load-in access is worth a specific question rather than a general one. “Ground floor, double doors off the side alley” and “up two flights, no lift” produce very different call times, and the second one is a reason to bring another pair of hands.

Field Why it matters
On-site contact Who to reach on the day — name, phone, email
Sound engineer The venue’s engineer, if there is one

A mobile number that will be answered on the day is worth more than the booker’s office email. The person who signed the contract is frequently not the person holding the keys at 16:00.

An advance that lives in one person’s inbox has solved half the problem. The band still does not know what time to arrive.

The output of a good advance is a day sheet: one page with the address, the times, the parking, and the phone numbers, sent to everyone playing. It ends the ritual of four separate “what time are we on?” messages the morning of the gig.

In Gigmeister this is built in. Advance templates are reusable across gigs, the organiser fills in a shared link rather than a chain of emails, and the confirmed answers become a read-only day sheet you share as one link — the whole lineup, and the promoter, open it in a browser or print it, and the fee stays off it. The Backstage pillar covers how the calendar, shared inbox, and rider pack fit together, and function bands tend to lean on it hardest, since corporate and wedding work is almost entirely logistics.

The failures are consistent and all of them are cheap to prevent:

  • Arriving to a locked building because load-in was 15:00 and nobody confirmed it.
  • A set cut short because curfew was earlier than assumed.
  • Not enough inputs because the venue never received the patchlist and set up for a four-piece.
  • No parking at a city-centre venue, so the van does a lap while the drummer unloads onto the pavement.
  • Nobody to call when the side door is locked at 16:00 and the booker’s phone goes to voicemail.

None of these are unlucky. Each one is a question that was not asked.

What does it mean to advance a show? Contacting the venue or promoter before the date to confirm every logistical detail in writing — times, sound, access, hospitality, and contacts — while sending the band’s own technical requirements in return.

When should you advance a gig? Two weeks to one week out for a normal club or function gig. Festivals and support tours advance on the production manager’s schedule.

Who is responsible for advancing the show? Whoever booked it — bandleader, manager, or tour manager. One named person on each side, rather than four band members separately messaging the promoter.

What is the difference between a rider and an advance? The rider is the document the band sends describing what it needs. The advance is the conversation confirming the venue can meet it, and establishing what the venue provides in return.

Do small gigs need advancing? A pub gig for a familiar landlord needs a text message confirming times. A first-time venue needs the full list. The cost of asking is five minutes; the cost of not asking turns up at 19:00 on the night.

Soundcheck Prep: What to Send Your Engineer Before You Arrive

A soundcheck that runs 90 minutes instead of 45 is a soundcheck that eats into your set, strains the relationship with the venue, and leaves the band starting their first song already tired. Most of the delays are caused by information that could have been shared days in advance: what channels the engineer needs to build, what monitors each player requires, what the stage layout looks like.

None of this should be figured out in the venue. Here is what to prepare before you arrive, how to format it so the engineer can actually use it, and how to share it without four separate PDF attachments.

The house engineer at a Thursday night pub gig might have 30 minutes from the time you arrive to when doors open. A corporate event’s AV team might have two hours — but also three other acts on the same stage.

When you arrive with a patchlist in your head rather than on paper, the engineer is writing down what you tell them in real time, asking clarifying questions, and hoping they got it right. When you arrive with a patchlist sent 48 hours ago, they have already built the initial channel layout and spent those 30 minutes doing something useful.

The band that makes the engineer’s job easier gets better treatment — faster checks, more time dialling in the mix, a sound person who is already invested in making the show work.

The Patchlist: Your Engineer’s Most Important Document

Section titled “The Patchlist: Your Engineer’s Most Important Document”

The patchlist is a channel-by-channel breakdown of every input on stage. It tells the engineer what they are building before a single cable is plugged in.

A complete patchlist row includes:

Field Example
Channel 1
Source Kick drum (inside)
Mic / DI Shure Beta 52 / Beta 91A (if dual-mic)
Stand type Short boom on floor
Notes No phantom, low-cut at 80Hz

The notes column carries the information that causes surprises at soundcheck when it is missing:

  • Instruments that need phantom power (condenser mics, active DIs)
  • Sources where you want a pad engaged at the preamp
  • Stereo pairs that must go to adjacent channels
  • DI outs from keyboards that go to two channels
  • Click track or backing track outputs and which channel they are on

Keep it scannable. Engineers read patchlists on a phone in a noisy venue with one hand while doing something else with the other. Dense paragraphs do not get read. A clean table with one row per input does.

Building a Patchlist That Works for Any Venue

Section titled “Building a Patchlist That Works for Any Venue”

The house engineer at a bar does not have the same rig as the A1 at a theatre. Write the patchlist for the instrument and source, not for a specific mic model — the engineer may not have your preferred microphone, but they know how to mic a snare drum with what they have if they know it is a snare drum.

Specify: instrument type, source (DI vs. mic’d, overhead vs. clip), stand type, phantom and pad requirements, any stereo routing.

Leave optional: preferred mic models (note as a preference, not a requirement), EQ settings (the engineer has their own approach), effects (discuss at soundcheck).

A patchlist that works at every venue is one that describes what you have and what it needs — not one that prescribes what the engineer must provide.

Some songs have details the FOH engineer should know in advance: a long outro that fades to silence (they do not need to chase a fader), a song where the vocalist moves to a handheld mic mid-song, an intro where the band plays quietly before the first downbeat.

In Gigmeister, you can add per-song PA notes to each entry in your setlist. These notes appear in the Soundman View — the real-time read-only link you share with the FOH engineer. They see the notes for each song as it comes up in the set, before the song starts.

This is the difference between a reactive engineer (scrambling to adapt) and a prepared engineer (already set up for what is coming).

The Stage Plan: Getting Everyone in the Right Place

Section titled “The Stage Plan: Getting Everyone in the Right Place”

A stage plan is a visual diagram of who stands where — instrument positions, monitor wedge positions and assignments, amp placement, and cable runs. Its purpose is to get the physical stage set up before you arrive, so you are not spending the first 20 minutes moving amplifiers.

Most bands use the same stage layout for the majority of their gigs. The drummer is in the back centre, the bass amp is stage right, keyboards are stage left, the guitarist moves between centre and stage right depending on song. Build the plan once and reuse it.

  • Musician positions — labelled by name or instrument. If the vocalist and the guitarist share centre stage, show it.
  • Monitor wedge positions — which wedge faces which player, and which aux send it is on. “Monitor 1 faces vocals and keys, Monitor 2 faces drums” is enough.
  • Amp positions — with a note for whether each goes direct-in (DI) or mic’d.
  • Drum kit position and orientation — including whether the kit is elevated on a riser.
  • Keyboard and guitar riser positions — if applicable.
  • Cable run notes — anything that crosses a walkway or audience area that needs to be addressed before people are moving around.

The goal is for the venue’s crew to have the stage mostly right before you arrive. You will still adjust things — but “mostly right” is far faster than starting from scratch.

In Gigmeister’s Rider Pack, the stage plan editor is a visual canvas: drag positions, label them, save. The plan is part of your rider share link. Every venue that receives the link gets the current version.

When your guitarist moves from a combo amp to a Kemper and the input routing changes, update the plan once. Every venue with the link sees the new version immediately. There is no version to recall.

The tech rider describes what the venue needs to provide for your show to work. It covers PA system requirements, monitor setup, power, backline (if applicable), and any specialist equipment.

A practical tech rider for a working band without excessive demands:

PA system: full-range stereo system appropriate for the room size, with subwoofers. No specific brand required.

Monitor system: minimum two independent monitor mixes (wedges or IEMs compatible). For larger bands: four independent mixes.

Inputs: minimum 16-channel capability at FOH (more for larger bands — specify based on your channel count).

Power: clean power with a dedicated circuit for the backline if possible. Specify any high-draw requirements (Leslie cabinet, high-powered keyboard rig).

Backline (if venue-supplied): specify exactly what you need. If you bring your own, say so clearly so the venue does not set up something that will not be used.

A venue reading a 12-page technical rider for a Thursday bar gig will ignore most of it. Match the detail level to the gig type and the venue’s capacity to respond.

For pub and club gigs: a one-page rider covering channel count, monitor sends, and power requirements is right.

For corporate and private events: two to three pages, covering everything above plus any AV integration (HDMI for visuals, walk-in/walk-out music from a laptop, wireless handheld mics for speeches).

For festivals and theatres: full technical specification with addenda for backline and power requirements.

Include a short “essentials” block at the top — three or four items that are genuinely non-negotiable — for venues that will not read beyond page one. Everything else is a preference.

The hospitality rider covers what the venue provides for the band off stage: catering, dressing room, parking, and load-in access. Keep it proportionate to the gig.

A sensible hospitality rider for a mid-tier function or event band:

  • Parking: clearly marked spaces close to the load-in entrance, held from arrival to departure
  • Dressing room: one clean room with chairs, a mirror, and a power outlet per device (or a power strip)
  • Water and refreshments: water on stage throughout the show; light snacks or a hot meal for multi-hour bookings
  • Meal allowance: a fixed amount per head if catering is not practical

Leave out demands that signal inexperience for your tier — a headlining stadium act’s hospitality requirements do not translate to a private birthday party booking. Unreasonable riders create friction with venues and do not get honoured anyway.

Four separate PDFs in an email — patchlist, stage plan, tech rider, hospitality rider — is how important documents get missed. One gets moved to a folder, one gets forwarded to the wrong person, one is the version from two years ago.

The Rider Pack share link in Gigmeister is a single URL that surfaces all four documents in one view. Send it once in the booking confirmation email. The venue coordinator, the stage manager, and the house engineer can all access the same link. Sending the pack is one half of the job — advancing the show is how you confirm the venue can actually meet it, and both live in Backstage.

When you update the patchlist before a run of gigs, everyone with the link sees the new version. No re-send required. No “which version is current?” question at soundcheck.

The link requires no login to view. It is printable. It works on any device. For venues that prefer a physical copy, the engineer can open it on their phone or print it from the URL.

The Soundman View: Setlist Mode for Front of House

Section titled “The Soundman View: Setlist Mode for Front of House”

During the show, the FOH engineer benefits from knowing what song is next — especially on variable-order setlists or gigs where the band calls songs from the stage. Gigmeister has a dedicated Soundman View mode built into the setlist page: a cleaner, read-optimised layout showing song titles, order, and per-song notes without the performance navigation controls.

  • The full setlist with song order
  • The currently playing song (highlighted)
  • Per-song notes (PA notes, stage banter cues, instrument changes)
  • Duration of each song

The view updates live as the band leader advances through songs.

The practical setup: a dedicated device (tablet or spare phone) at FOH, logged into the band’s Gigmeister account, open on the setlist in Soundman View mode. The engineer follows the set without a printed sheet, and per-song notes are visible before each song starts.

An engineer who can see “keys-led intro, vocal enters bar 5, big reverb tail on snare in second verse” before the song starts is set up rather than reacting. These notes live on the song in Gigmeister and are visible in the Soundman View alongside the setlist order.

Soundman View comes in two forms: an in-app mode for a logged-in FOH device, and a public read-only Front-of-House share link that needs no account. Tap Share in the setlist toolbar to get a no-login URL that surfaces the ordered set, per-song PA notes, and an optional link to the rider pack — ideal for handing to a house engineer you can’t add to the band.

A consolidated checklist for every gig:

  • Patchlist updated and included in rider share link
  • Stage plan current and in the rider share link
  • Tech rider accurate for tonight’s setup
  • Rider share link sent to the venue contact
  • Setlist locked for tonight (or finalised at soundcheck)
  • PA notes added for any songs with specific requirements
  • FOH device logged in and open on Soundman View mode
  • MIDI program changes tested against all devices
  • Backing tracks verified (levels, routing, trigger settings)
  • Calendar event updated with load-in and soundcheck times for all band members

The first time through this list takes a few minutes. After the first gig, it takes 90 seconds to confirm that nothing has changed.

Build your rider pack, share it with venues, and give your sound engineer real-time setlist visibility. Create a free Gigmeister account or read the Rider Pack documentation to set up your production documents.

How to Handle Gig Bookings Without the Email Chaos

Most bands run their bookings through someone’s personal Gmail. Which means missed messages. Which means the band leader leaves and takes every venue contact with them. Which means a dep asks “what time is load-in?” and the answer is buried somewhere in a thread that three people were CC’d on four months ago.

It does not have to work this way. Here is a practical workflow for managing gig bookings from first inquiry to confirmed gig — one that scales as your band gets busier and survives personnel changes.

The core issue is not email. Email is fine. The problem is personal email — an inbox only one person can see, with no shared history, no way to assign follow-ups, and no record that survives if that person steps back from the band.

Think about what gets lost:

  • A venue emailed six months ago about a recurring Friday slot. Nobody remembers what was agreed.
  • A promoter sent a follow-up that landed in someone’s spam.
  • The band manager who handled all the bookings left, and the history walked out the door with them.
  • Three people are now CC’d on every thread “just in case,” creating reply-all chaos every time someone responds.

The fix is a single shared inbox — one address, visible to everyone who needs to see it, with a thread history that lives with the band rather than any individual.

Get a proper band email address: bookings@[yourband].com, or at minimum a Gmail address that is not tied to anyone’s personal account. The domain address looks more professional to venues and promoters, but any dedicated address solves the ownership problem.

What matters most is that more than one person has access. Forward it to the band’s shared inbox in Gigmeister, or set up IMAP access for anyone who needs visibility. When the keyboard player joins or leaves, you update access — you do not lose the thread history.

Thread Management: From Inquiry to Confirmation

Section titled “Thread Management: From Inquiry to Confirmation”

Every booking starts as a thread — an email conversation with a venue, promoter, or event organiser. The goal is to move each thread from New → In Progress → Waiting → Closed without anything falling through the cracks.

New — unread inquiry, not yet assigned to anyone.
In Progress — someone is actively handling it.
Waiting — you have replied and are waiting for a response. Snooze the thread to resurface it in a week if nothing comes back.
Closed — gig confirmed (calendar event created), declined, or cancelled. The thread stays in the record; close it when no further action is needed.

Assigning a thread to the person who is handling it means everyone else knows not to reply independently. The thread has one owner. If the owner cannot be reached, anyone with access can pick it up — because the full history is right there.

The moment you assign a thread, the CC chain becomes unnecessary. The person assigned handles it. Everyone else can see the thread if they need to — but they are not getting pings every time someone responds.

This is a small cultural change for bands used to adding half the lineup to every booking email. It takes one gig cycle to appreciate how much quieter it makes the inbox.

A venue sends a booking inquiry. You need a professional response that covers your availability, your rate, your sound requirements, and next steps. You write a version of this email dozens of times a year.

Gigmeister’s AI draft replies read the incoming message, the thread context, any internal notes you have added, and the linked gig details — and generate a starting draft. The tone matches how a working band communicates with venues: direct, professional, not overly formal. You read it, adjust anything that needs adjusting, and send. The research and structure are done; you just review.

This earns its keep most on the variable emails — the ones where the inquiry is specific enough that a template would not fit, but common enough that you know roughly what needs to be said.

For the truly repetitive emails, templates beat AI drafts on speed. The six emails every busy band sends repeatedly:

  1. Availability check reply — confirming you are available and providing your quote
  2. Quote with rider — your fee, what is included, link to the tech rider
  3. Deposit confirmation — acknowledging receipt, confirming the date is now secured
  4. Show-day logistics — load-in time, soundcheck time, set times, parking details
  5. Cancellation — short, professional, no hedging
  6. Rebook follow-up — sent a month after a good gig, suggesting future dates

Templates let you send a consistent, professional email in under a minute. The writing is done once and reused — edit the specific details (fee, date, venue name) before sending.

The AI draft and the template are not competitors — they serve different situations. Template for the predictable, AI for the specific.

Stop attaching PDFs to every booking email. Not because PDFs are bad, but because you update your rider and the venue is still looking at the version from 2023.

The rider share link is a single URL that always serves the current version of your production documents — tech rider, hospitality rider, stage plan, and patchlist. Send the link once. When you add a new channel to the patchlist, or update your monitor requirements, or change the stage plan because your guitarist switched to a Kemper, the link updates automatically. The venue coordinator can bookmark it and always have the right version for show day.

Drop the link into your quote email. It goes out with every booking confirmation. No more “which version is current?” questions at soundcheck.

The Patchlist: What Your Sound Engineer Actually Needs

Section titled “The Patchlist: What Your Sound Engineer Actually Needs”

The patchlist is the most practically important document you send a venue. It tells the FOH engineer — often someone who has never seen your band before — exactly what they are building before you arrive.

A good patchlist row per input:

  • Channel number
  • Instrument or source (kick drum, snare, bass DI, lead vocal, acoustic guitar)
  • Mic or DI type (or just “condenser mic” / “passive DI” if you are not specifying model)
  • Stand type (boom stand, short stand, clip)
  • Notes (phantom power required, pad, polarity flip, stereo pair)

The notes column matters. A drum overhead that needs phantom power, a guitar amp that goes DI rather than mic’d, a backing track output that comes in as stereo — these are the details that cause delays at soundcheck when they surface at the last minute.

Keep it in a simple format. Engineers read these on a phone in a noisy venue. Scannable beats comprehensive.

Confirmed gig, verbal agreement, no contract. Deposit sent, not received. Balance due on show day — but nobody wrote down the amount. These are not edge cases; they happen regularly in active bands.

For each gig, track:

  • Contract status — not sent, sent, signed
  • Deposit status — not requested, invoiced, received
  • Balance — amount, due date (usually show day)
  • Notes — anything the venue has agreed to that is not in the contract

This does not need to be a complex system. It needs to be visible to more than one person and linked to the gig event so the information is there when show day arrives.

When the band arrives at the venue and someone asks “what’s the balance?” — the answer should not require anyone to check their messages.

When a booking is confirmed, two things need to happen immediately:

  1. The date goes into the band calendar — with load-in time, soundcheck time, set time, venue address, and parking notes
  2. The setlist gets linked to the event (even if it is still a template — it can be finalised closer to the gig)

Every band member with access can see the calendar. They get the gig day details in the app alongside their chord sheets and setlists, not buried in a group message that will scroll away by show time.

When the venue sends an update — say, soundcheck has moved from 4pm to 5pm — update the calendar event once. Everyone sees the change. No group message needed.

A consolidated timeline for a typical gig, from inquiry to show day:

  1. Inquiry arrives — thread opens in the Shared Mailbox, status: New
  2. Assign thread — booking person picks it up, status: In Progress
  3. Reply with availability and quote — include the rider share link
  4. Venue confirms and requests deposit invoice — send invoice, status: Waiting
  5. Deposit received — update deposit status, create calendar event, close the thread
  6. Send show-day logistics email — load-in, soundcheck, parking, venue contact
  7. Show day — balance collected, show notes added to the thread for next time

From inquiry to confirmed gig, every step is tracked in one place. The next person who handles bookings — whether that is tomorrow or two years from now — walks into a complete history.

Manage your band’s bookings, rider pack, and gig calendar from one place. Create a free Gigmeister account or read the Shared Mailbox documentation to connect your band email.