Use Case

One workspace per client , one base per event, for 50+ events a year

A boutique event production and creative services agency built a scalable playbook in Airtable, giving each of its 12 clients a dedicated workspace, each event its own base, and every team a consistent structure for logistics, automations, and client-facing shared views.

The problem

Running 50+ corporate events for 12 clients in a single year creates a coordination problem. Each client needs its own event data kept separate from others, yet internal teams need consistent structure to operate efficiently across every account. Without a shared system, tool sprawl becomes a real risk, particularly when leadership considers adopting competing platforms.

External stakeholders, including clients and vendors, need visibility into event status and logistics without gaining access to internal records. Building that kind of selective access in a spreadsheet-based system requires constant manual exports and creates version-control risks across the team.

What they built

The agency structured Airtable around its clients and events. Each client gets a dedicated workspace that keeps all client-specific bases, automations, and interfaces isolated from other accounts. Within each workspace, every event gets its own base with tabs covering the logistics specific to that event type.

Automations handle event workflows inside each base, reducing the repetitive setup work for each new event. Interfaces give internal team members a structured view of their responsibilities. Shared views let external clients and vendors see exactly what they need without navigating the full base, giving the agency control over data exposure while maintaining client transparency.

The outcome

The agency now operates all client event work through a single platform, with each client's data cleanly separated in its own workspace. Internal teams follow a consistent playbook across every event, reducing the overhead of switching mental models between accounts and cutting setup time for new events.

The shared-view approach resolved the external stakeholder access problem without compromising internal data. The foundation also positions the agency to expand its use of automations and AI-assisted workflows as its event volume grows, without needing to migrate to a different tool.

Inside the solution

Client and event playbook system with workspace-per-client architecture

Events and Experience Management

Events and Live Operations

  • Workspace-per-client structure isolating each client's bases, automations, and interfaces
  • Base-per-event with logistics tabs tailored to each event type
  • Automations running event workflows within each client base
  • Shared views for external client and vendor visibility without full base access
  • Internal interfaces for team collaboration across event operations
  • Tool sprawl risk from leadership interest in competing platforms
  • Limited time to customize interfaces for each client
  • Need for consolidated event operations across multiple client accounts
  • External stakeholder access without exposing internal records
  • Single platform for all client event operations, replacing fragmented tools
  • Scalable structure supporting 50+ events per year without rebuilding each time
  • Client data isolation through dedicated workspaces prevents cross-account visibility issues
  • Shared views give clients and vendors controlled access without internal data exposure
  • Consistent internal playbook reduces setup overhead across all accounts
  • Foundation for expanding automations and AI usage as event volume grows
  • Event Operations
  • Operations
  • Airtable native automations
  • Shared views
  • Interfaces
Build out this use case

Client and event playbook system with workspace-per-client architecture

Run every client account and every event from one structure: a workspace record per client, an event base record per event, and the same standard playbook, run-of-show, vendor and contact tabs behind all of them. Automations apply the playbook to each new event and chase blocked steps weekly, while Airtable AI drafts the producer status recap, the blocker triage note, and the message that goes out with each external shared view link.

Client and event playbook system with workspace-per-client architecture - Overview dashboard
How it works

From tool sprawl to a scalable per-client playbook

Create a workspace for each client

Set up a dedicated Airtable workspace for each client account. This keeps all bases, automations, and interfaces for that client in one place and prevents data from one client appearing in another's views. Start with your highest-volume client and replicate the structure as you onboard others.

Build a base-per-event with logistics tabs

Inside each client workspace, create one base per event. Use the event planning and budgeting template as the starting point, then add tabs for the logistics specific to your event type, such as vendor tracking, run-of-show, or contacts. Standardize the tab structure so your team works the same way across every event.

Add automations and shared views for external access

Wire automations for the recurring event workflows inside each base. Then create shared views scoped to only the fields your clients and vendors need to see. Share the view link directly so external stakeholders have real-time access without logging into Airtable or seeing internal records.

FAQ

Frequently asked questions

A dedicated workspace for each client keeps all of that client's bases, interfaces, and automations isolated. There is no risk of one client's data appearing in another client's views, and permissions are managed at the workspace level rather than field by field. It also lets the team customize the structure for each client without affecting others.

Airtable shared views let the agency expose only the fields and records relevant to a specific stakeholder. A vendor might see a filtered view of the logistics base showing only their tasks and deadlines. The client might see a shared view of the event timeline. Neither sees the internal production notes or cost fields.

The base-per-event structure uses a consistent tab layout across every event. Internal teams follow the same playbook regardless of the client. Automations are standardized inside each base, so the setup steps are the same even when the event details differ.

Adding a new event means creating a new base from the standard template inside the relevant client workspace. Adding a new client means creating a new workspace and copying the base structure. The architecture scales without rebuilding the system, so the team can take on more events without proportional increases in setup time.

Yes. Because each client has its own workspace, the automations and interfaces in that workspace are completely independent. Changes made for one client do not affect any other client's workspace. The team can tailor the experience for each account while keeping the underlying playbook consistent.

Reading document head…