Console Operations

The console is the operator workspace for running the business. It is organized around what the team does each day: setup, scheduling, sales, customers, content, growth, and configuration.

Get Started

Use Get Started for first-run setup and launch guidance. It is the best place to resume onboarding if a workspace is incomplete.

Common actions:

Treat Get Started as the workspace readiness queue. If a task is incomplete, follow it to the owning console surface, make the smallest necessary change, then return to confirm the checklist state instead of wandering through navigation.

Insights

Insights is the performance summary surface. It is the default landing area for many operators because it answers what happened recently before they choose a task.

Use it to watch:

• Revenue and booking trends.
• Top products or services.
• Recent customer activity.
• Operational signals that need follow-up.

Use Insights after launch and during daily operations. It should tell the team whether traffic, bookings, sales, customer activity, or operational volume changed enough to require action in a more specific console area.

Scheduling

Scheduling owns booking operations:

• Booking list and detail views.
• Service catalog, tiers, add-ons, waivers, deposits, and payment timing.
• Availability, overrides, staff, calendar connections, and sync status.
• Reschedule, amend, cancel, complete, no-show, and payment actions.

The public sites booking flow depends on the rules configured here.

When a customer cannot book, start here before editing public pages. Availability, staff/resource mapping, buffers, deposits, site status, and calendar sync can all make the public scheduler behave correctly even when the visible page copy looks unchanged.

Sales

Sales unifies order, transaction, invoice, and service revenue views. Operators use it to answer who paid, what they bought or booked, what status the work is in, and what still needs action.

Use Sales for:

• Product orders.
• Booking transactions.
• Invoices.
• Payment status.
• Revenue review.

Customers

Customers is the relationship record for a workspace. It brings together identity, bookings, orders, consent, communications, forms, payments, activity, and operator notes.

Use Customers when a team needs context before replying, rebooking, refunding, blocking, or manually creating work for a customer.

Customer records should remain the context layer, not a replacement for source records. Refunds belong to payment/order surfaces, booking changes belong to Scheduling, and communication preferences belong to the relevant notification or profile setting.

Inbox

Inbox is the operator triage stream. It collects customer events such as form submissions, messages, booking events, notifications, and references that need review.

Use Inbox as the first stop for “what came in?” and Customers as the deeper context view.

An inbox item is only useful when it has an owner and a next action. During launch, confirm that form submissions, support requests, booking events, and notification replies land where the team actually works.

Automations

Automations covers repeatable internal workflows. Use it for procedures that should run consistently, such as intake handling, follow-up preparation, or operator playbooks.

Automations should support the team. They should not hide the source of truth for bookings, orders, customers, or payments.

Before enabling an automation, identify its trigger, output, allowed writes, review owner, and pause path. If the workflow touches customers, payments, or booking status, keep a human approval step until the team has reviewed real operating examples.

Website

Website hands off to the site editing experience. Use it for page structure, content blocks, navigation, footer, brand assets, and public site composition.

Use Website when the customer-facing layout or message is wrong, and use Settings when the underlying business rule is wrong. That split keeps operators from masking a configuration issue with page copy or changing a durable business rule just to fix a single page.

Settings

Settings owns durable workspace configuration:

• General.
• Team.
• Domain and Email.
• Checkout and Tax.
• Privacy and Legal.
• Features.
• Intake flow.

Settings changes can affect multiple public and internal surfaces. Treat them as launch-impacting changes.

Before changing settings, name the public paths and operator workflows that depend on the value. A checkout setting can affect products, bookings, receipts, taxes, and refunds; a domain or sender setting can affect every customer link and notification.

Integrations

Integrations manages workspace-connected third-party services:

• Google Analytics.
• Google Ads.
• Google Business Profile.
• Calendar providers.
• Payment and shipping providers through their dedicated surfaces.

Each integration should have an owner, a success signal, and a rollback path. Operators should know whether the integration changes public behavior, internal reporting, customer communication, or all three before enabling it.

AI Assistance

AI assistance settings control drafting, summarization, recommendations, and related customer-experience support. Use them for capability posture, voice, vertical-specific guidance, and automation boundaries.

Keep AI assistance grounded in console records and operator review. It should help summarize, draft, route, or recommend; anything that contacts customers, changes records, or influences payments should be explicit, auditable, and easy to pause.

Operator Safety Rules

1. Confirm the selected workspace before changing settings.
2. Verify customer-facing changes on the public site.
3. Test payment, notification, and booking changes before launch.
4. Keep customer data and workspace data scoped to the active tenant.
5. Use the console as the source of truth; do not patch public-site behavior independently when a console setting owns it.