Skip to Content
Workflow GuidesWorkspace Onboarding

Workspace Onboarding

console.sophosic.ai/workflows
WorkspaceActive
Tasks24
Revenue$8.2k
Review inboxOpen
Publish siteOpen
Workspace consoleWorkspace setup, daily operations, public-site controls, and launch decisions

This runbook takes a workspace from “operator has access” to “the business is configured enough to build and test the public site.”

Outcome

At the end of onboarding:

Correct workspace is selected

The console shell, workspace switcher, known records, and public links all point to the business being onboarded.

Business identity is accurate

Name, hours, timezone, currency, contact details, address, and service area match the site, receipts, bookings, and notifications.

Team access is current

Owners, managers, staff, and former users have roles that match their real responsibilities.

Domain and email are owned

DNS, sender identity, reply path, and production host setup have an owner even if provider propagation is still pending.

Durable settings are intentional

Privacy, legal, consent, checkout, feature flags, and intake choices are reviewed before they shape customer-facing workflows.

Public verification URL is known

Operators test the same slug or production domain customers will use, not an unrelated preview or stale host.

Step 1: Select The Workspace

Console surface: root workspace picker or workspace switcher.

Actions:

  1. Open the console.
  2. Choose the workspace you intend to manage.
  3. Confirm the shell, workspace badge, and public site links match the business.
  4. If you have access to multiple workspaces, switch before making changes.

Verify:

  • Admin paths such as /settings/general and /shop are acting on the expected workspace.
  • Public links point to the intended site slug or domain.

Failure checks:

  • Wrong data in console usually means the wrong workspace is selected.
  • A selected workspace cookie is not proof of authorization; membership still needs to be valid.

Step 2: Complete General Settings

Console surface: Settings > General.

Configure:

  • Business name.
  • Public phone and email.
  • Address and service area.
  • Timezone.
  • Currency.
  • Operating hours.
  • Site status.

Verify on sites:

  • Homepage and footer show the expected business identity.
  • Local business metadata is plausible.
  • Booking availability uses the correct timezone and hours.
  • Checkout displays the correct currency.

Failure checks:

  • Wrong timezone creates confusing appointment times.
  • Wrong currency creates checkout and invoice confusion.
  • Missing public contact details make notifications and support paths weak.

Step 3: Review Team Access

Console surface: Settings > Team.

Configure:

  • Owners.
  • Managers.
  • Staff.
  • Any specialist users who manage payments, bookings, content, or support.

Verify:

  • Every active operator can access the sections they need.
  • Former users are removed.
  • Staff access is not broader than required.

Failure checks:

  • If an operator cannot access a page, check role and feature flag before debugging the page.
  • If a user sees the wrong workspace, check membership and selected workspace.

Step 4: Configure Brand And Site Chrome

Console surfaces: Settings > Branding, Website.

Configure:

  • Logo.
  • Theme preset.
  • Accent palette.
  • Typography.
  • Header navigation.
  • Footer sections.
  • Legal links.
  • Social links.
  • Brand imagery.

Verify on sites:

  • Public header and footer reflect saved settings.
  • Mobile navigation works.
  • Footer links go to real destinations.
  • Brand colors are legible in both dense UI and marketing content.

Failure checks:

  • If the public site looks stale, verify cache invalidation or refresh.
  • If links point to old pages, check Website navigation and footer editors.

Step 5: Set Domain And Email Direction

Console surface: Settings > Domain and Email.

Configure or collect:

  • Production domain.
  • DNS provider.
  • Required DNS records.
  • Email sender identity.
  • Mailbox or forwarding requirements.
  • DNS export if another admin owns DNS.

Verify:

  • Domain verification state.
  • Final public URL.
  • Email sender path.
  • DNS records are not hidden behind a provider setting that breaks mail.

Failure checks:

  • A verified domain can still have broken email.
  • DNS propagation can make a change look broken for a short time.
  • If a payment wallet depends on domain verification, verify that separately.

Console surface: Settings > Privacy and Legal.

Configure:

  • Privacy policy.
  • Terms.
  • Refund and cancellation policies.
  • Shipping policy when commerce is enabled.
  • Cookie consent.
  • Communication disclosures.
  • Data retention or consent copy where required.

Verify on sites:

  • Policy pages are linked from the footer.
  • Cookie banner appears when needed.
  • Email preference and unsubscribe paths work.
  • Analytics and ads are not enabled before consent posture is ready.

Failure checks:

  • Google Ads and GA4 should be reviewed with consent settings.
  • Checkout should not launch without refund, cancellation, and policy links.

Step 7: Configure Checkout And Tax Baseline

Console surfaces: Payments, Settings > Checkout and Tax.

Configure:

  • Stripe connection plan.
  • Tax settings.
  • Invoice defaults.
  • Checkout behavior.
  • Deposit and balance behavior if bookings are paid.
  • Manual payment handling if supported.

Verify:

  • Payment collection is disabled or connected intentionally.
  • Financial owner understands account status and payout implications.
  • Public checkout paths are not exposed until payment setup is complete.

Step 8: Set Feature Flags

Console surface: Settings > Features.

Enable only the modules the workspace will use:

  • Shop.
  • Bookings.
  • Forms.
  • Intake.
  • Stories or help content.
  • Marketing.
  • Customer portal features.

Verify:

  • Console navigation reflects intended capabilities.
  • Public site does not expose disabled flows.

Step 9: Configure Intake

Console surface: Settings > Intake.

Configure:

  • Intake fields.
  • Routing expectations.
  • Form or booking relationship.
  • Customer follow-up owner.

Verify:

  • Public intake pages or forms collect useful information.

Intake should give the team enough context to act without creating unnecessary friction. Review the first submitted record with the operator who will use it; if they still need to ask basic follow-up questions, revise the fields or routing before launch.

  • Submissions appear in the expected console triage surface.

Onboarding Completion Checklist

Use this checklist as the readiness gate before switching from setup to launch testing. Every item should have either a completed configuration, an explicit owner, or a documented reason it is not needed for this workspace.

  • Workspace selected.
  • General settings complete.
  • Team current.
  • Branding started.
  • Domain and email path known.
  • Legal and consent path known.
  • Checkout baseline decided.
  • Feature flags intentional.
  • Intake configured.
  • Public site URL known.
Workspace Onboarding | Sophosic Platform