A photobooth doesn’t just show up at a wedding. Someone talked to the client three weeks earlier. Someone designed the custom backdrop graphic. Someone figured out which van is free on Saturday, which of the 7 staff members is working that shift, and which photobooth model is already booked for a corporate event on the same date. By the time the booth is set up at the venue, 10 small decisions have stacked on top of each other. In most rental companies, every one of those decisions lives in a different Excel sheet.
That was the reality for this team when they came to me. 7 employees, a growing fleet of photobooths, events happening across the country, and a planning system held together by spreadsheets and memory.
What Was Broken
The company had been running on Excel for years. One sheet for bookings. One for vehicles. One for staff schedules. Client details scattered across email threads and PDFs. Event location info rebuilt from scratch every time someone booked a venue they’d already worked at before.
The biggest issue wasn’t the spreadsheets themselves. It was that nothing talked to each other. An event in one sheet had no connection to the client record, the assigned photobooth, the vehicle delivering it, or the staff member setting it up. If something changed — a date shift, a staff swap — it had to be updated in 4 places. Sometimes it only got updated in 3.
The Build
The first decision I made was to make the Event the center of the entire workspace. Everything else — clients, locations, photobooths, vehicles, staff, graphics, shopping lists, finances — relates back to it. Open one event page and you see everything tied to that event in one view. No more jumping between tabs.
I organized the whole teamspace into 4 groups on the homepage. Core event entities (Events, Event Information, Photobooth Model, Event Location, Clients) hold the who, what, and where of every booking. Event assets (Guest Book, Backdrop, Props, Resources, Vehicle, Event Gallery) hold everything physical or visual tied to a specific event. Operations (Todo, Staff Vehicle Planning, Team Directory) run the day-to-day. Intake and finance (Requesting Information, Finance, Shopping Lists) handle what enters or leaves the business.
The real power sits inside each individual event page. When the team opens a booking, they see the event status (Lead, Confirmed, Delivered), the event type, the assigned client, the location, the backdrop, the photobooth model, and 11 other properties pulled in through relations. Below that, a Todo list filtered to just this event. A toggle-style panel switches between the Graphic Designer Checklist and the After Event Checklist, both pre-built as repeatable templates so every new event comes pre-loaded with the same structure. Then: the Brief Sheet, the Client record, the Photobooth Model gallery card, the Backdrop with a visual preview, the Client Form response, Event Location, Props, Event Gallery, Resources, Shopping List, Staff & Vehicle Planning, and Finance. Every section on that page is filtered to just this one event. Nothing from other bookings bleeds in.
For the photobooth fleet, the client told me pricing info wasn’t the priority. What they actually needed was conflict prevention by date. Two events on the same Saturday can’t use the same booth. The same applies to backdrops, vehicles, and props. So instead of a generic “Available / Not Available” flag, I built each asset database with date-aware availability logic. When a team member opens an event, the linked Photobooth Model and Backdrop cards show their availability status for that specific event date, pulled from every other event already booked on the system. For the Photobooth Model in the screenshot above, you can see the “Classic” card shows “Available, 2 Units Available” — because they have multiple units of the same model, the system tracks stock levels, not just yes/no. Double-bookings became visually impossible before they happen, not something caught after the fact when two clients call asking about the same booth.
For client intake, I replaced the old PDF form with a Tally form embedded directly into the workspace, written in German (the team’s native language and their clients’ too).
Tally handles the form UX and Notion handles the data. When a client submits, the response automatically creates a new entry in the Requesting Information database. No copy-pasting, no manual data entry, no exports. The form captures what actually matters operationally: client name, event location, contact person on site with phone, event date, start and end times, setup and pickup slots, access details (stairs, elevator, gravel path), parking, and additional notes.
Right above the fields, three warnings sit where clients can’t miss them: power access required within 5m, the booth isn’t weatherproof, and a table needs to be prepared for props if booked. From there, the team manually reviews each inquiry and assigns it to an event. I kept that assignment step manual on purpose: not every inquiry becomes a booking, and the team wanted a human checkpoint before anything hit the main calendar.
One detail I’m particularly proud of: the Event Gallery has two views, By Location and By Event. When the team lands a new booking at a venue they’ve worked before, they can pull up every past event at that location and see exactly how they set up, what worked, and what they photographed. Old events stop being archive dead-weight and start being reference material.
The Result
What I can say structurally: the team went from 6+ Excel sheets and scattered email threads to a single teamspace where every event is one click away from its client, location, booth, vehicle, staff, checklists, and finances.
Double-bookings became visually impossible instead of something caught by accident. The external form killed the manual re-entry of client details. And with the teamspace set up for 7 employees, each person sees what they need for the events they’re working. Graphic designers see briefs and checklists, staff see their assignments, the owners see the whole calendar.
What I Learned
When a business runs on “the event” as its core unit, the workspace has to be built around that unit. Not around departments, not around tools, not around people. Once I made the Event page the hub and wired every other database to relate and filter back to it, the whole system clicked.
Most rental, agency, and service businesses have this same shape: one central transaction that everything else orbits. Find that unit first, build the rest around it.
Book a free Notion strategy call
If your business runs on events, projects, bookings, or jobs, and your information is still scattered across spreadsheets and email threads, a call is the fastest way to see what’s fixable. We’ll talk through your workflow, your current pain points, and map out the Notion workspace that ties it all together.