What each tenant can customise

A quick map before we go deeper

Booknetic SaaS gives each of your tenants their own Booknetic workspace. They can configure a surprisingly large surface inside it — services, staff, locations, the booking widget's look, their workflows, their payment gateways for appointment payments, even the labels on the booking panel. This page is the customer-facing tour of what each tenant can change in their own panel, menu by menu.

A couple of nearby pages on the same topic — make sure you're reading the right one:

• Tenant admin panel reference — what your tenants when they log in. The menu structure, the Dashboard, the Billing tab.
• This page — what your tenants change inside each of those menus. What's tenant-controlled vs owner-controlled. How tenants customise their booking widget, build workflows, and accept payments to their own bank account.
• Plans and plan capabilities — how you, the SaaS owner, decide which of the customisation surfaces below your tenants get at all.

You're in the right place if you're trying to answer questions like:

• "Can my tenant change their email templates?"
• "Can my tenant modify their booking widget?"
• "What's owner-controlled vs tenant-controlled?"
• "Can my tenant use their own Stripe so they get paid into their own bank account?"

Who controls what — the owner-vs-tenant boundary

Most "why can't my tenant do X?" and "why CAN my tenant do X?" questions trace back to this one boundary. Read it once, share it with your tenants on day one.

What gets configured	Who controls it	Where it lives
Which plans exist, what they cost, which features they include, and how much volume they allow	You, the SaaS owner.	WP Admin → Booknetic SaaS → Plans. See Plans and plan capabilities.
Global platform behaviour — signup flow, default trial plan, expired-plan behaviour, branding of the SaaS admin panel, social login, languages your tenants can pick from	You, the SaaS owner.	WP Admin → Booknetic SaaS → Settings. See SaaS Settings reference.
The payment gateway your tenants use to pay you for their plan (your platform's Stripe / PayPal / WooCommerce)	You, the SaaS owner.	WP Admin → Booknetic SaaS → Settings → Payment Settings.
The provider credentials for SMS, WhatsApp, Telegram (your Twilio account, your Telegram bot)	You, the SaaS owner.	WP Admin → Booknetic SaaS → Settings → Integrations. See Notification channels for your tenants.
Their own services, staff, locations, customers, appointments	The tenant, inside their own Booknetic panel.	Tenant → the matching menu.
Their own payment gateway for appointment payments — their own Stripe, PayPal, Square, Razorpay, Mollie, and so on — so money from customer bookings lands in the tenant's bank account, not yours	The tenant.	Tenant → Settings → Payment Settings → Payment Methods.
Their booking widget's look — colours, theme, logo, Custom CSS	The tenant.	Tenant → Appearance.
Their automations — booking confirmation emails, 24-hour reminders, status-change notifications, and so on	The tenant.	Tenant → Workflow.
Their business hours, holidays, currency for customer payments, time-slot length, booking-step order, panel labels	The tenant.	Tenant → Settings.
Their booking link / QR code / iframe embed code	The tenant.	Tenant → Billing → Share Page.
Their plan choice (subscribe, upgrade, downgrade, cancel)	The tenant picks; you set the menu of plans available.	Tenant → Billing → plan cards.

The headline: inside their plan, your tenants own their booking business end to end. You own the platform around them.

What each tenant menu lets them customise

The next section walks through the tenant menus in the order a tenant sees them, and explains what each one lets them change. Cross-references to the sister docs are inline.

Dashboard

The Dashboard is read-only — your tenant doesn't customise anything here. It shows their appointment activity, revenue, new-customer count, and a date-range picker.

There's still one indirect tenant choice worth knowing about: if your tenant's plan doesn't include the Dashboard capability, the Dashboard menu doesn't appear and Booknetic sends them straight to Billing on every load. That's a plan-level decision you make in the plan editor, not something the tenant changes.

Billing

Billing is the SaaS-specific tab added to the tenant panel. From here, your tenant manages their own subscription:

• Toggle Monthly / Annual cycle.
• Pick a plan card and check out (Stripe, PayPal, or WooCommerce balance, depending on what you've enabled).
• View their current plan and live usage against each limit — for example, Staff: 3 / 5, Services: 8 / 10.
• Cancel their subscription. (Cancelling doesn't immediately cut access — they keep using the plan until their expiry date passes, then your Expired plan takes over.)
• Top up a WooCommerce balance (if you've enabled it) and pay future invoices from that balance.
• Open the Share Page modal — see "Share Page" below.

For the full subscription-state walkthrough, see Subscription states and billing history.

Appointments

Your tenant manages their own bookings here — create, edit, reschedule, cancel, and mark statuses. They can also create appointments on behalf of their customers from this screen.

Calendar

Your tenant's visual schedule view. They switch between Month / Week / Day / List, drag-to-reschedule, and filter by staff, service, or location. The Calendar's colour basis (event colour by service vs by status) is a tenant choice in Settings → General → Calendar.

Customers

Your tenant's own customer database. They add, edit, group into categories, and track per-customer notes. One person who books with two tenants on your platform is two separate customer records — there's no shared "customer of the platform" notion.

Payments

Your tenant sees appointment payments here — what their customers paid them. This is not the same as Billing. Billing is what your tenant pays you for their plan. Payments is what their customers pay them for bookings.

Services

Your tenant builds their service catalogue here. Per service, they can customise:

• Name, category, description.
• Image and colour (used on the booking widget).
• Price, deposit, duration, time-slot length, buffers.
• Capacity (one-at-a-time or group).
• Service Extras (add-ons).
• A per-service timesheet (overrides the tenant's default business hours for this service).
• Per-service settings — for example, "only-visible-to-staff" (hide from the public booking widget), service-specific payment methods, minimum time before booking, maximum booking days, and minimum/maximum extras.

Staff

Your tenant manages their team here. Per staff member, they can set:

• Name, profession, email, phone, photo, internal note.
• Locations and services this staff member works.
• A weekly schedule, plus special days and holidays that override the schedule.
• "Allow to log in" — see below.

The "Allow to log in" toggle creates a WordPress user for that staff member. They can then sign in to your platform and see a limited Booknetic panel — Dashboard, Appointments, Calendar, Customers, Payments — scoped to their own bookings. If your tenant's plan includes the User Role Manager addon, your tenant can build custom staff roles to control what each staff user can see inside the tenant's account.

Locations

Your tenant manages their branches, offices, studios, or clinics here. Per location: name, category, image, address, phone, description.

Workflow

Your tenant builds their own automations here. A workflow has one event (the thing that triggers it — booking created, booking starts, status changed, customer birthday, payment received, and so on) plus one or more actions (what happens — send an email, send an SMS, change the booking status, send a Telegram message, fire a webhook).

A workflow is fully tenant-controlled inside the tenant's own panel:

• Your tenant writes the email subject and body, the SMS text, the WhatsApp template variables, the Telegram message — using Booknetic shortcodes like {customer_first_name}, {appointment_date_time}, {service_name}, {staff_name} to fill in dynamic data.
• Your tenant decides timing — "24 hours before booking starts", "immediately on creation", "1 hour after booking ends", and so on.
• Your tenant decides per-event filters — "only for service X", "only when status changes to Approved".

What your tenant doesn't control is the channel infrastructure underneath:

• Email — uses your WordPress mail setup (your SMTP, your transactional email provider).
• SMS, WhatsApp, Telegram — use the provider credentials you, the SaaS owner, configured platform-wide. Your tenants share one Twilio account, one Telegram bot. They never see your Account SID or your bot token.

The full per-channel reference (who configures what, what tenants see, what to do when a channel limit is hit, how per-channel suppression works) is on its own page: Notification channels for your tenants — Email, SMS, WhatsApp, Telegram.

Appearance

Appearance is where your tenant brands their booking widget. Booknetic ships with 7 default themes; your tenant can pick one, duplicate it, edit it, or build a brand-new theme.

Per theme, your tenant can adjust:

• Theme name and panel height.
• Font family.
• Panel background colour and primary colour.
• Active-step, completed-step, and other-step background and label colours.
• Title colour, border colour, price colour.
• Whether to hide specific booking steps from the widget view.
• A Custom CSS field for deeper styling that the toggles don't cover.

Each theme is published with a theme="<id>" parameter on the [booknetic] shortcode, so a tenant can run multiple themed booking pages on different WP pages of their site (one theme for their salon page, a different theme for their training page).

Two important details about Appearance:

• Appearance is per-tenant. Tenant A's colour change does not affect Tenant B's widget. Each tenant has their own themes.
• "Powered by Booknetic" in the booking-panel footer is controlled at the plan level. If you've turned on the Remove branding capability for the tenant's plan, the footer line is hidden. If you haven't, the footer line stays — no Appearance toggle removes it. That's a plan decision, not an Appearance decision.

For the plan-side capability that hides the footer, see Plans and plan capabilities.

Settings

Settings is the deepest customisation surface. It has four sub-tabs: General, Front-end Panels, Payment Settings, and Integration Settings. The next section walks each one.

Settings sub-tabs — walkthrough

General

General controls the tenant's basic booking and business configuration. The most common settings tenants change here:

• Company Details — company name, logo, address, phone, website, "display logo on booking panel" toggle. These values flow into every workflow shortcode ({company_name}, {company_address}, and so on), so getting them right early avoids editing every email template later.
• Business Hours — Mon–Sun open/close times, day-off toggle per weekday, multiple breaks per day. This is the tenant's default schedule — individual staff and services can override it.
• Holidays — per-tenant closure dates.
• Booking rules — time-slot length, minimum-time-before-booking, how far in advance customers can book, default appointment status, week-starts-on, date format, time format, whether to show time slots in the customer's timezone.
• Calendar — what colour scheme to use for events (by service colour vs by status colour) and a Custom HTML editor for the calendar event card.
• Google Maps API Key — tenant supplies their own key for location maps on their booking widget.
• Export & Import Data — exports the tenant's own Booknetic data. The export is scoped to that one tenant — it never includes other tenants' data.

Front-end Panels

Front-end Panels controls the customer-facing booking widget itself — the booking-flow shape and labels.

• Booking Steps — drag-and-drop to reorder steps (Location, Staff, Service, Service Extras, Date & Time, Information, Cart, Confirmation, Finish), enable/disable optional steps, and configure each step's per-step settings. Examples of per-step settings: "Collapse Locations under Category", "Footer text per staff", "Enable Any staff" (with a Least-assigned / Most-assigned / Most-expensive / Least-expensive algorithm).
• Labels — visual label editor. Your tenant hovers over any text on a live preview of the booking widget, clicks the pencil icon, and edits the label inline. The change is saved for the currently active language. If your tenant runs the widget in French and German, they edit the labels twice — once per language.
• Pages — your tenant assigns WordPress pages for the booking flow (the page that hosts the [booknetic] shortcode), the Change Appointment Status page (used by Booknetic's per-status shortcodes in emails), and the Sign In / Sign Up / Forgot Password pages (Customer Panel addon).

Two booking-step constraints to know about: the Service step must come before the Service Extras step (extras are per-service), and the Finish step must always be last. The drag-and-drop UI will reject a layout that breaks those rules.

Payment Settings

Payment Settings controls how the tenant accepts payments from their own appointment customers. This is the most-confused area of the tenant panel, so it's worth taking slowly.

There are two layers of payment gateways in a Booknetic SaaS install — they're separate, with different API keys, doing different jobs:

Layer	Who configures it	Who pays whom	Where it lives
SaaS billing gateways	You, the SaaS owner.	Your tenant pays you for their plan.	WP Admin → Booknetic SaaS → Settings → Payment Settings.
Tenant payment gateways	Each tenant, in their own panel.	The tenant's customer pays the tenant for an appointment.	Tenant → Settings → Payment Settings → Payment Methods.

Each tenant can plug in their own Stripe, PayPal, Square, Razorpay, Mollie, 2Checkout, MercadoPago, Netopia, Vipps, or local-payments gateway — whichever Booknetic addons you've installed on the platform. The tenant pastes their own Stripe Account ID, Publishable Key, Secret Key, and Webhook Secret. When a customer books and pays, the money lands in the tenant's own merchant account, not yours. You're not in the payment path.

This is the high-acquisition pitch for a Booknetic SaaS platform: "Sign up to my SaaS, plug in your own Stripe, get paid directly. I never touch your booking revenue."

Per-tenant Payment Settings also controls:

• The tenant's currency for customer payments (independent of the currency you charge them in for their plan — a tenant in Berlin can charge EUR while you charge them USD).
• Decimal format and currency symbol display.
• Payment-wait time (how long to hold a time slot while a customer is completing checkout).
• Whether customers can also choose "Pay full" when deposits are enabled.
• The appointment status to apply after a successful payment, and after a failed one.

Integration Settings

Integration Settings covers tenant-owned third-party integrations — for example, "Continue with Facebook" and "Continue with Google" social-login on the booking widget, plus calendar integrations (Google Calendar, Outlook Calendar), video-meeting integrations (Zoom, Google Meet, Vivomeetings), and others — whichever Booknetic integration addons are active on your platform AND included in the tenant's plan.

Each integration uses the tenant's own API credentials. For example, when your tenant enables Google Calendar two-way sync, they connect their own Google account; bookings sync into their own calendar, not yours.

If the tenant's plan doesn't include any integration addons, the Integration Settings sub-tab may not appear in their menu at all — the tenant just sees fewer Settings options, not a greyed-out tab.

Share Page — your tenant's booking link

The Share Page modal in Billing → Share Page is how your tenant publishes their public booking URL. The modal gives four ways to share:

• Copy URL — the tenant's public booking page link. The exact URL format depends on the routing mode you've configured for your platform — typically a directory-style URL like your-platform.com/aurora-wellness for directory routing. See Tenant URLs and routing.
• Send by email — your tenant types a recipient and a short body; Booknetic emails the booking link out.
• QR code — a downloadable PNG QR code your tenant prints on flyers, business cards, or stickers.
• Iframe embed — pre-formatted <iframe> snippet your tenant pastes into their own website (a WordPress page outside of your platform, a Squarespace site, a Webflow site, etc.) so the booking widget loads in-page on their own domain.

Heads-up on the iframe. If your tenant's site runs strict accessibility checks (or they're optimising for Lighthouse / Core Web Vitals), the iframe code Booknetic generates doesn't include a title attribute. Some accessibility tools flag that. The fix is for the tenant to paste the iframe code into their HTML editor and add title="<their business name>" before publishing.

What your tenants CANNOT customise — your control surface

This is the other half of the boundary table. Tenants do not see, edit, or override any of the following:

• The plan editor. Plan names, prices, capability toggles, and limits live in WP Admin → Booknetic SaaS → Plans. Tenants pick a plan from your menu; they don't author plans.
• Other tenants' accounts. Tenant A can't see Tenant B's services, staff, customers, appointments, payments, workflows, or settings. The data isolation is automatic — your tenants don't need to configure it.
• Global SaaS Settings. Your default trial plan, your expired-plan choice, your platform's email gateway, your social-login keys, your Twilio account, your Telegram bot — all owner-only. See SaaS Settings reference.
• Platform branding (whitelabel). The "rename Booknetic to your brand" surface — admin backend colours, login-page logos, the SaaS admin menu name — is whitelabel, owner-only. (Per-tenant tenant-facing booking-panel branding via Appearance is a separate, tenant-owned surface.)
• Tenant-signup custom fields. You decide what fields appear on the tenant signup form (industry, country, expected appointment volume, and so on). Your tenants fill those fields in once, at signup; they don't author them.
• The "Powered by Booknetic" footer line on the booking widget. Plan-level — controlled by the Remove branding capability on the tenant's plan.
• Their plan limits, mid-cycle. A tenant who hits the staff limit on their plan can't raise the limit themselves; they upgrade to a higher plan, or you raise the limit on their current plan from your side.
• The provider credentials behind SMS, WhatsApp, and Telegram. Your Twilio account, your Telegram bot. See Notification channels for your tenants.

Three customer archetypes — how SaaS owners actually configure the boundary

How much tenant customisation you allow is a product decision, not a fixed Booknetic behaviour. Here are three archetypes we see often. Each one is a workable starting point you can adapt for your own pricing.

Archetype 1 — Restrictive (tenants edit only their services and staff)

You're running a tightly curated marketplace where you want every tenant's booking widget to look and feel the same. Tenants pick from your service catalogue and staff your business onto your platform; everything else stays under your control.

What tenants can customise	What the SaaS owner controls
Services, Staff, Locations, Customers, Appointments.	Appearance (you set one theme, all tenants use it). Workflows (you set platform-wide workflows; the tenant Workflow capability is OFF on their plan). Payment Settings (you collect all payments centrally and pay tenants out of band). Front-end Panels (you set the booking-step order and labels).

How you implement it: in the plan editor, turn OFF Appearance, Workflow, and Integration Settings capabilities. Leave only the core booking modules ON.

This is the right shape if your value-add to tenants is uniformity (every booking widget looks like your brand) rather than tenant autonomy.

Archetype 2 — Standard (tenants run their own booking business inside your platform)

The most common shape. Tenants own their booking workflows, branding, and payment gateways; you own plan billing and the platform infrastructure.

What tenants can customise	What the SaaS owner controls
Services, Staff, Locations, Customers, Appointments. Appearance (their booking-widget theme — colours, fonts, logo, Custom CSS). Workflows (booking confirmation emails, reminders, status notifications). Payment Settings (their own Stripe / PayPal / etc. for customer payments). Front-end Panels (their booking-step order and labels).	Plans, plan capabilities, plan limits. Global SaaS Settings. Your SMS / WhatsApp / Telegram provider credentials. Your SMTP/transactional email provider for the platform.

How you implement it: in the plan editor, leave the core modules and most of the customisation capabilities ON (Appearance, Workflow, Payment Settings, Front-end Panels). Adjust per-channel limits (Email, SMS, WhatsApp, Telegram) per plan tier. Use the Remove branding capability on higher plans to remove the Booknetic footer.

This is the default shape recommended by most Booknetic SaaS positioning — tenants feel like they're running their own Booknetic, and you collect plan revenue.

Archetype 3 — Full self-service (tenants own everything except billing)

For platforms targeting power users — established small businesses who want maximum control. You sell the infrastructure; tenants build the experience.

What tenants can customise	What the SaaS owner controls
Everything in Archetype 2, plus: their own staff-role permissions (User Role Manager addon), per-tenant integrations (Google Calendar, Zoom, etc.), Booknetic Logs audit access, Custom Forms per-service, Tenant Directory listing (if enabled). Plus higher / unlimited limits.	Plan, billing, the plan menu the tenant chooses from.

How you implement it: turn ON every capability in the plan editor, including the addon-specific ones (User Role Manager, Logs, Custom Forms, Tenant Directory, Affiliate, Customer Panel). Set generous or unlimited limits.

This is the right shape if your platform's value is "we host and bill — you do everything else."

These three archetypes are starting points, not prescriptions. Most platforms end up somewhere between Standard and Full self-service, with different cuts at different plan tiers. See Plans and plan capabilities for the per-capability editor.

Common questions

"Can my tenant use their own SMTP for their booking emails?"

Today, the SMTP gateway is platform-wide. WordPress's mail (and any SMTP plugin you've installed on your platform — WP Mail SMTP, FluentSMTP, Post SMTP) sends all booking emails for every tenant. Your tenant can still customise the sender name and Reply-To address that their customers see, so the emails feel like they're coming from the tenant's business, but the underlying gateway is yours.

If your tenant absolutely needs their own SMTP — typically for compliance, deliverability ownership, or independent bounce/complaint handling — that's not supported out of the box. Reach out to support; we'd like to hear the use case so we can weigh it against the roadmap.

For the full email/SMS/WhatsApp/Telegram setup, see Notification channels for your tenants.

"Can my tenant change the language of their admin?"

The languages your tenants can pick from are controlled at the platform level by you, the SaaS owner. In WP Admin → Booknetic SaaS → Settings → General, the "Enable the language switcher for tenants" toggle lets you offer multiple languages, and the "Select languages" list controls which ones. Each tenant then picks from your list inside their own admin.

For the booking-widget customer-facing language, your tenant uses Settings → Front-end Panels → Labels to edit the labels in each language they want to translate.

For the full SaaS Settings walkthrough, see SaaS Settings reference.

"Can my tenant disable a workflow channel that I set up?"

Not directly — your tenant doesn't have a per-channel "off" switch in their panel. What your tenant can do is edit their workflow to remove the channel action they don't want. For example, if you set up a tenant on a plan that includes SMS and the tenant doesn't want to send SMS reminders, they open the relevant workflow, remove the Send SMS via Twilio action, and save. Email keeps firing; SMS stops.

What only you can do is gate the channel at the plan level. If you turn the SMS capability OFF for the tenant's plan, the Send SMS via Twilio action disappears from the tenant's workflow editor entirely, and any workflows that referenced it stop firing on SMS (other channels in the same workflow keep firing).

"Can my tenant accept appointment payments to their own bank account?"

Yes — that's the central design of Booknetic SaaS. Each tenant plugs their own payment gateway credentials into Settings → Payment Settings → Payment Methods inside their panel. When a customer books and pays, the money flows through the tenant's Stripe (or PayPal, Square, Razorpay, Mollie, etc.) account into the tenant's bank, with no detour through your platform. You're not in the payment path for appointment payments.

The only money that flows through your platform's gateway is what your tenants pay you for their plan.

"Can I hide 'Powered by Booknetic' from my tenants' booking panel?"

Yes — this is a plan capability called Remove branding. Turn it ON for the plans where you want the footer hidden, OFF for the plans where you want it shown. See Plans and plan capabilities.

"Can my tenant invite their staff to log in?"

Yes. When the tenant creates or edits a staff record, the Allow to log in toggle creates a WordPress user with limited Booknetic access (Dashboard, Appointments, Calendar, Customers, Payments — their own bookings only). Staff sign in at your regular login URL. If your tenant's plan includes the User Role Manager addon, your tenant can build custom staff roles to fine-tune what each staff user can see.

Gotchas to keep in mind

A few customer-confusion points that come up regularly. Worth sharing with your tenants on day one.

Settings changes by one tenant don't affect any other tenant

Each tenant's Settings, Appearance, Workflows, Payment Methods, and so on are stored separately and only ever affect that one tenant's booking business. There is no "platform-wide Settings" that one tenant can accidentally edit and break for everyone else.

Appearance changes affect THEIR booking widget only

When a tenant edits a theme — changes a colour, swaps a logo, adds Custom CSS — it changes their own widget. It does not change yours (the SaaS owner's admin chrome), and it does not change any other tenant's widget. Themes are tenant-scoped.

Tenant workflows don't affect your global workflows

You, the SaaS owner, have your own SaaS Workflows in WP Admin → Booknetic SaaS → Workflows. Those fire on tenant-lifecycle events ("a new tenant signed up", "a tenant paid", "a tenant's subscription is about to expire"). They send to you, with {tenant_*} shortcodes about the tenant.

Each tenant, separately, has their own Workflows inside their own panel. Those fire on appointment events ("a new booking was made", "a booking starts in 24 hours"). They send to the tenant's customer, with {customer_*} / {appointment_*} / {service_*} shortcodes.

They're two completely separate workflow surfaces. A tenant building workflows in their own panel will never see your {tenant_*} shortcodes, and you will never see appointment-event shortcodes in your SaaS Workflows.

Where to go next

• Tenant admin panel reference — the sister page to this one. Same menus, but from the "what tenants SEE" angle rather than "what tenants CHANGE".
• Plans and plan capabilities — the upstream control surface. Every customisation switch on this page is gated by a capability on the tenant's plan.
• Notification channels for your tenants — the deep dive on Workflow channels (Email / SMS / WhatsApp / Telegram), per-plan limits, who configures what.
• SaaS Settings reference — your owner-side global settings (default trial plan, expired-plan behaviour, signup pages, social login, languages, branding).
• Tenant URLs and routing — what the booking URL in the Share Page modal actually looks like, and the two routing modes (directory vs subdomain).
• Subscription states and billing history — the full lifecycle of the tenant's Billing tab — pending, active, cancelled, expired, paid, refunded.