Sarim Naeem
A super platform for gig management, custom-built for Sol & The Gang. Enquiries, bookings, WhatsApp artist confirmations, two-way email, setlists, itineraries, payments and analytics, all in one place. I owned it end to end, from the first brief to the live product.
Figures from the live system’s Bookings and Analytics views, October 2026.
Sol & The Gang is a live music act playing weddings, birthdays, corporate parties and tours, from London to Bodrum to Monaco. Each show needs anything from 4 to 14 performers, a contract, a deposit, a setlist, travel and a plan. And every week, more enquiries arrive than one manager can comfortably hold in their head.
They didn’t need another generic CRM. They needed a system shaped exactly around how a band gets booked, prepared and paid. So we built one from scratch.
The design questionHow might a manager move from a single enquiry to a performance-ready gig, without ever losing the context of the booking?
Before designing anything, I sat with how the band actually worked day to day. These are the problems that kept coming up, and how the platform solves each one.
Artists don’t log into apps. Gig confirmations got lost in WhatsApp threads, and nobody knew who was actually coming.
Gig requests go out on WhatsApp. The artist taps Yes or No and the lineup updates itself. No reply? The request expires. Stuck artist? The manager confirms or declines from the system.
The lineup is always current, and the manager stops chasing people. Silence is flagged automatically instead of discovered on the day.
Client emails lived in personal inboxes. If the manager was away, nobody could see what had been promised.
Two-way email through Mailgun. Reply from Gig Assist or straight from Gmail, and every message lands in the event’s mailbox.
The full client history sits on the booking, so anyone on the team can pick it up. The manager still replies from wherever they are.
The same Saturday got requested twice, and nobody noticed until a quote had already gone out.
A double-booking indicator flags every enquiry that lands on a date that’s already requested or booked.
Clashes are visible before anyone says yes, not after two clients have paid deposits.
Once a gig was booked, managers still had to dig through hundreds of enquiries to find it.
A separate Bookings view with only confirmed gigs, upcoming and past totals, and a Quick View for conversation, documents, payments and key notes.
149 confirmed gigs (53 upcoming, 96 past) and £2.16M in bookings, visible on one screen.
Setlists were retyped for every show: the same songs, the same medleys, the same artists.
A setlist that remembers. Songs and medleys are saved with their artist and come back as you type.
Building a set becomes picking, not typing, and the band gets consistent song details every time.
Itineraries were Word documents that took an evening, and every artist got a slightly different version.
A structured itinerary template: fill it in, preview the PDF, email it to the client and every confirmed artist.
One itinerary, one format, sent to everyone at once.
Balances, artist call times and feedback depended on the manager remembering to send a message.
Configurable reminders: balance reminders to clients before the gig, gig reminders to artists, meeting reminders, and feedback after the show.
The follow-ups happen on time, every time, without anyone keeping a list.
Nobody knew which channels actually brought in work, or how much money was still to come.
Analytics for leads by source, monthly conversions, and revenue received versus outstanding.
4,630 enquiries tracked by source. The band can see the website brings in 99% of them, and exactly what’s still to be paid.
This wasn’t a hand-off project. I took Gig Assist from a client brief to a live product, and the role grew with it: designer first, then product manager, then the person who decided how the whole system fits together.
Sharjeel built it. I designed what to build and how it should behave; he turned it into a working platform, module by module.
Credit where it’s due 🙌I designed the product around the life of a single gig. Scroll through it.
Enquiries arrive from the website, Instagram, TikTok and referrals. Each one becomes a card with date, venue, budget, band size and status (new, no reply yet, negotiation), with a double-booking indicator before anyone says yes.
Enquiry pipeline · source tracking · double-booking indicatorOpen an enquiry and the client’s email thread sits next to an Actions to Take panel: send a gig template (auto-sent on new enquiries), set up a meeting, prepare documents, track payments or manage the gig.
Event workspace · two-way email · templates · meetingsInvoices are built from the booking, then split into instalments with due dates. Contracts and tech riders come from templates, and every document stays attached to the gig.
Invoices · instalments · contracts · tech riderPick the lineup from artist cards showing role and availability. Artists confirm on WhatsApp. Then the setlist, itinerary and tasks like “learn this song” are all prepared against the same event.
Lineup · WhatsApp confirmation · setlist · itinerary · tasksClient and artist payments are tracked separately. After the gig the client is asked for feedback, and analytics show where leads come from, how many convert, and revenue received versus still to come.
Payments · feedback · analytics
These are the flows I spent the most thought on. Each one is a small working model of how the real system behaves.
The manager sends a gig request. The artist answers Yes or No on WhatsApp, and the lineup updates itself. If they don’t answer in time, the request expires and the manager knows to look elsewhere. And if an artist is stuck on a plane, the manager can confirm or decline for them from the system.
Pick the lineup: every artist shows role and availability before you choose.
Each artist shows Pending, Confirmed or Not available, updated from their WhatsApp reply. “Mark as confirmed” is the manager’s manual override.
Managers live in their inbox, and they’re not always logged in. So email runs through Mailgun: the manager can reply to a client from Gig Assist or straight from their own Gmail, and every message, sent or received, shows up in the event’s mailbox. Nothing gets lost in someone’s personal inbox.
I separated confirmed gigs from enquiries. Bookings shows only what’s happening, upcoming or past, with revenue totals at the top. A Quick View opens the conversation, documents, payments and the manager’s key notes, like “bride wants an acoustic first dance”, without leaving the list.
Bookings shows only confirmed gigs, upcoming or past, with totals at the top.
Quick View · Conversation: the full client thread, without leaving the list.
Quick View · Invoice: status, amounts and the latest update.
Quick View · Assignees: who’s playing and who has confirmed.
Quick View · Key notes: the manager’s notes, like a client’s special request.
Every song and medley the manager adds is saved with its artist. Next time, start typing and the old entry comes back, ready to drop in.
Live: songs and medleys are saved with their artist, so they come back when you start typing.
When a new enquiry lands on a date that’s already requested or booked, both cards are flagged, so the manager decides before promising anything.
Look for the red “Double booking” tag on each enquiry card.
Itineraries used to be Word files that took an evening. I designed a structured template: flights, hotel, transfers, dress code, green room, catering, set times. The manager just fills it in and hits share; a clean PDF goes to the client and to every confirmed artist.
The itinerary template I designed: set list, client, lineup, transport, segments and more.
Live: fill in the template, then Download PDF, Preview, or email it to all confirmed artists.
Live: the generated itinerary, ready to share.
Reminders are settings the business controls, not hard-coded rules. Before the event, clients are reminded about remaining payments and artists get a heads-up that the gig is coming. After it, the client is asked for feedback. Drag the sliders.
Artists have a separate dashboard for their gigs, tasks and payments. But most of the time they’re travelling or rehearsing, so the same updates reach them on WhatsApp: a new task, a gig coming up, a payment marked as paid.
The key decision sat underneath the UI. Every enquiry, email, invoice, setlist, task and payment belongs to an event, so the manager never has to remember where something lives. Tap a module to see how it connects.
Each one reads from and writes to the same event, so information entered once is reused everywhere.
Gig Assist is 100% custom development, shaped around how Sol & The Gang works. But I kept the brand layer (logo, colours, sender name) separate from the system underneath, so it runs under their identity today and could run under another tomorrow.
As development moved, requirements changed, and I kept the product and the design moving together. Drag the slider to compare my design with the live system.
The foundation is a clean record of every enquiry, conversation, booking and payment. That’s exactly what AI needs. These are on the roadmap.
Draft replies to enquiries in the band’s tone, using the package, date and what the client already asked.
Which enquiries are likely to convert, which months will be busy, and how much revenue is coming.
The best available lineup for a date, the right package to quote, and who to chase first.
Deciding that everything belongs to an event solved more UX problems than any single screen did.
WhatsApp for artists and Gmail for managers did more for adoption than any onboarding screen could.
Reminders and templates save hours, but the manager still decides what to send and when. That trust matters.
I didn’t just design a booking tool. I designed the backstage of a band, and made sure it shipped.
