Most businesses run on a stack of tools that each own a copy of the same people. The accounting package has your customers. The email tool has them again. The booking system has a third list, and none of them agree.
Studio Manager is the console over a platform where that does not happen, because every surface is reading the same records.
What is in it
- App root — inbox, analytics, dashboards, domains, sites and dev environments
- Build Studio — pages, forms, presentations and templates
- DAM — content, categories, tags, documents and message templates
- Storefront — products, orders, carts and checkout
- CRM — leads, pipelines, tickets and campaigns
- Finance — invoices, payments and payouts
- Logistics — shipping and fulfilment
- Events — ticketing, check-in and attendee data
- Phone — numbers, call routing and SMS
- AI and automation — triggers, conditions and actions across all of it
Why one console matters
A customer who books a table, buys a gift card and raises a support ticket is one record, not three. That sounds obvious until you try to answer "what is this person worth to us" across three vendors and a spreadsheet.
Because the console sits on one data model, an automation can span what would otherwise be separate products: a missed call creates a lead, a paid invoice releases a fulfilment, a check-in updates the attendee record the marketing campaign is segmenting on.
It is a view, not a wall
Everything the console does is the API doing it. There is no admin-only path and no private endpoint behind the screens, which means anything you can do by clicking you can also do from a script, an integration, or an agent — against the same permissions.
Read next
- Studio Manager docs — every panel in detail
- Build Studio — pages, forms and templates
- CRM — leads and pipelines
- Studio Manager