Skip to content

Complete merchant feature catalog

Every current store-scoped merchant page is documented here. Each entry explains what the page does, when to use it, a synthetic example, its limits, and the evidence to check before calling the task complete. Open its detailed guide for interface steps and prerequisites.

Start with the task you need to finish

New Shopify connections are coming soon; Shopify setup references apply to existing connections. A documented route does not establish that its provider is connected or that your user can perform its actions.

Documented does not mean automatically ready

Role and plan access, source data, connection state, credentials, channel approval, consent, external delivery, and storefront behavior can still block a real workflow. Use the verification line for each feature and the end-to-end tutorials.

Coverage summary

  • 97 / 97 store-scoped merchant page routes represented.
  • 8 operating areas with task-oriented tutorials.
  • Access labels come from the same capability mapper used by the application.
  • Route and guide coverage is enforced by tests.
  • Examples illustrate a test procedure; they are not customer results or production verification.

Feature index

Overview and readiness

Typical access: All members with store access

Store home

/ · All store members

Redirects the store root to its Overview page.

  • Why and when: Start here when deciding whether the store is ready for shoppers or which operational problem needs attention first.
  • Merchant workflow: Use the store URL as the stable entry point; Zubby opens Overview.
  • Verify: The browser lands on /overview for the same store ID.
  • Synthetic example: A test store has products but no completed search indexing. Follow its readiness action into Imports before interpreting a zero-conversation week.
  • Limits / when not to use: Influenced revenue and revenue-to-plan-price are directional reporting measures, not causal lift, profit, or a guarantee of return.
  • If it does not work: Check Store Details, the selected period, currency and completed sync before treating a zero as missing tracking. Open the source workspace behind a warning.
  • Detailed guide: /docs/overview

Overview

/overview · All store members

Shows directional AI-attributed revenue, conversations, rescue and recovery signals, sync state, readiness, predictions when entitled, and the next suggested action.

  • Why and when: Start here when deciding whether the store is ready for shoppers or which operational problem needs attention first.
  • Merchant workflow: Check sync and readiness first, then follow the highest-priority action into its owning workspace.
  • Verify: Compare the selected period, currency, sync timestamp, and source workspace before acting on a KPI.
  • Synthetic example: A test store has products but no completed search indexing. Follow its readiness action into Imports before interpreting a zero-conversation week.
  • Limits / when not to use: Influenced revenue and revenue-to-plan-price are directional reporting measures, not causal lift, profit, or a guarantee of return.
  • If it does not work: Check Store Details, the selected period, currency and completed sync before treating a zero as missing tracking. Open the source workspace behind a warning.
  • Detailed guide: /docs/overview

Inbox, conversations, and tickets

Typical access: Inbox capability; owner and full-access store members have all capabilities

Conversations

/conversations · Inbox & conversations

Searches and filters shopper transcripts, outcomes, feedback, tags, and handoff state.

  • Why and when: Find the evidence behind a support complaint, answer-quality signal, or apparent shopper conversion.
  • Merchant workflow: Find a thread by shopper, channel, tag, or outcome and open it for evidence.
  • Verify: Confirm the transcript belongs to this store and that filters and result counts match the intended scope.
  • Synthetic example: Filter for an incomplete answer, open the thread, and compare the shopper question with the cited return policy before giving feedback.
  • Limits / when not to use: A transcript can contain personal data. A linked order does not prove the conversation caused the purchase.
  • If it does not work: Clear channel, outcome and tag filters; verify the store ID and date. If a source message is missing, check the connector rather than creating duplicate conversations.
  • Detailed guide: /docs/conversations

Conversation detail

/conversations/:conversationId · Inbox & conversations

Shows one transcript with message context, citations, tool activity, shopper memory, internal notes, feedback, assignment, and reply controls.

  • Why and when: Use the full thread to respond accurately, leave an internal note, assign ownership, or correct one specific AI answer.
  • Merchant workflow: Review the complete thread before rating a reply, adding a note, assigning, or responding.
  • Verify: Reload after an action and confirm the feedback, note, assignment, or reply is persisted on the same conversation.
  • Synthetic example: A shopper asks whether a jacket can be returned. Read the policy citation, add an internal clarification for a teammate, then rate the unsupported answer as wrong.
  • Limits / when not to use: Internal notes are not shopper replies. A typed email or remembered shopper identity alone is not verified authority to reveal an order.
  • If it does not work: Reload the same thread after a mutation. If an external reply fails, inspect its channel connection and provider result before sending it again.
  • Detailed guide: /docs/conversations

Comments

/comments · Inbox & conversations

Lists supported social comments and their classification, suggested reply, moderation, and workflow state.

  • Why and when: Review supported Facebook or Instagram comments before replying, moderating or escalating them.
  • Merchant workflow: Review the source comment and edit any suggested reply before publishing or escalating.
  • Verify: Confirm the provider accepted the action and the local status changed; a local draft is not proof of external publication.
  • Synthetic example: A product comment asks about compatibility. Compare the proposed reply with the exact model specification, edit it, and confirm the reply on the source post.
  • Limits / when not to use: Channel entitlement, provider permissions and account approval must be in place; classification is an AI suggestion, not a moderation verdict.
  • If it does not work: Verify the selected Page/account, connector permissions and provider-side comment. Do not repeatedly publish when the external result is uncertain.
  • Detailed guide: /docs/social

Unified inbox

/inbox · Inbox & conversations

Combines active channel threads and the support-ticket triage queue in two views, above a 30-day handoff panel reporting requested, human-answered, average first human reply, and abandoned counts.

  • Why and when: Use Conversations for channel work and the Tickets view for durable cases with status, priority and assignment.
  • Merchant workflow: Filter to the work queue you own in the Conversations view, or switch to the Tickets view to triage status, priority, and assignment in bulk.
  • Verify: Check needs-reply state, assignment, priority, and the most recent message before closing work; the handoff panel counts tickets, so zeros mean no handoffs, not missing data.
  • Synthetic example: Open Inbox, choose Tickets, assign a return request to the responsible teammate, then open the case rather than closing it from a summary alone.
  • Limits / when not to use: First-response targets are internal staffing targets. The handoff summary counts tickets; it is not a promise that a shopper received a reply.
  • If it does not work: Check the active view, status and assignment filters. Legacy /tickets links redirect to /inbox?view=tickets and preserve supported query parameters.
  • Detailed guide: /docs/conversations/inbox

Ticket detail

/inbox/t/:ticketId · Inbox & conversations

Displays one support case, linked conversation context, status, priority, assignment, SLA timing, notes, and reply actions.

  • Why and when: Keep an unresolved refund, delivery or human-handoff request owned until the actual operation and reply are complete.
  • Merchant workflow: Read the case timeline, assign an owner, respond through the supported channel, and update status.
  • Verify: Confirm the reply/provider result and saved ticket state; do not treat a queued send as delivered.
  • Synthetic example: For a WooCommerce refund request, review the linked conversation, perform the approved refund in the store, record the result and send the shopper a factual update.
  • Limits / when not to use: Creating or resolving a ticket does not itself issue a refund. A sent or queued status does not establish inbox delivery.
  • If it does not work: Compare ticket status, assignee and the latest reply with the conversation. Check the sending channel and safe error details if the shopper did not receive the update.
  • Detailed guide: /docs/tickets

Support tickets (redirect)

/tickets · Inbox & conversations

Legacy route kept only as a redirect: the ticket queue is now the Tickets view of the unified inbox at /inbox?view=tickets, with the same status tabs, bulk status change, and per-row triage.

  • Why and when: Use Conversations for channel work and the Tickets view for durable cases with status, priority and assignment.
  • Merchant workflow: Open /inbox and switch to the Tickets view; existing links carrying status or ticket query params are forwarded unchanged.
  • Verify: Confirm the browser lands on /inbox?view=tickets for the same store and that the highlighted ticket, if any, is the one the link referenced.
  • Synthetic example: Open Inbox, choose Tickets, assign a return request to the responsible teammate, then open the case rather than closing it from a summary alone.
  • Limits / when not to use: First-response targets are internal staffing targets. The handoff summary counts tickets; it is not a promise that a shopper received a reply.
  • If it does not work: Check the active view, status and assignment filters. Legacy /tickets links redirect to /inbox?view=tickets and preserve supported query parameters.
  • Detailed guide: /docs/tickets

Catalog, knowledge, and imports

Typical access: Catalog capability; owner and full-access store members have all capabilities

Products

/catalog · Catalog, products & knowledge

Lists synchronized products, variants, inventory context, descriptions, search readiness, and sync controls, plus the cost coverage and payment fee cards that feed profit reporting and the margin guard.

  • Why and when: Establish the product facts, variants and costs the assistant can use before changing prompts or merchandising.
  • Merchant workflow: Filter the catalog, inspect failures or missing content, and open a sample product.
  • Verify: Compare representative products, variants, prices, availability, and sync time with the commerce platform.
  • Synthetic example: Compare a test jacket's size variants, stock, currency and cost with the commerce platform, then ask for an in-stock medium and an unavailable size.
  • Limits / when not to use: Managed imports and custom API pushes have different freshness paths. Missing costs prevent complete margin or profit conclusions.
  • If it does not work: Inspect last completed sync and product status. Correct platform-owned data at its source; check indexing separately when the record is correct but search cannot find it.
  • Detailed guide: /docs/catalog

Product detail

/catalog/:productId · Catalog, products & knowledge

Shows one synchronized product, variants, source fields, recommendation context, and AI tuning controls.

  • Why and when: Establish the product facts, variants and costs the assistant can use before changing prompts or merchandising.
  • Merchant workflow: Review source data before changing product-specific AI guidance or visibility.
  • Verify: Confirm saved tuning is store-scoped and test a shopper query that should exercise it.
  • Synthetic example: Compare a test jacket's size variants, stock, currency and cost with the commerce platform, then ask for an in-stock medium and an unavailable size.
  • Limits / when not to use: Managed imports and custom API pushes have different freshness paths. Missing costs prevent complete margin or profit conclusions.
  • If it does not work: Inspect last completed sync and product status. Correct platform-owned data at its source; check indexing separately when the record is correct but search cannot find it.
  • Detailed guide: /docs/catalog

Catalog SEO health

/catalog/seo · Catalog, products & knowledge

Lists stored catalog records missing metadata, structured data or descriptive detail under the product's internal checks.

  • Why and when: Find stored catalog fields that need review and prioritize inaccurate or missing product information.
  • Merchant workflow: Open an affected product, correct its source fields and sync; separately inspect the rendered storefront when public markup is the goal.
  • Verify: Confirm corrected stored fields and sample public markup independently. Internal completeness checks are not Google ranking rules or rich-result eligibility.
  • Synthetic example: Open one missing-description item, add factual copy at the owning source, sync, and compare the saved field before reviewing the public product page separately.
  • Limits / when not to use: Stored catalog structured data is not proof of rendered storefront markup, rich-result eligibility, search ranking or a Google-required word count.
  • If it does not work: Check whether the sync imported the corrected field. Inspect the public page source and relevant platform integration separately if markup is absent.
  • Detailed guide: /docs/catalog

Categories

/catalog/categories · Catalog, products & knowledge

Shows read-only collections and product types synchronized from the commerce platform.

  • Why and when: Check the collections and product types used to scope catalog searches and merchandising.
  • Merchant workflow: Use a collection or product type to open the matching product list; edit taxonomy at the source platform.
  • Verify: Confirm category counts against the source platform after the next completed sync.
  • Synthetic example: Open the Outdoor collection and compare its product list with the source store after a completed sync.
  • Limits / when not to use: This is a read-only view; editing a category name here is not a supported taxonomy workflow.
  • If it does not work: Update the source collection or product type and wait for sync. Check whether the source uses collections, product types or both before comparing counts.
  • Detailed guide: /docs/catalog

Knowledge

/knowledge · Catalog, products & knowledge

Manages merchant documents and approved AI-suggested articles used for policy and factual retrieval.

  • Why and when: Give the assistant approved shipping, returns and other policy evidence that does not belong in product fields.
  • Merchant workflow: Add or review source material, approve only grounded suggestions, and wait for embedding work to finish.
  • Verify: Test a relevant question and inspect its cited source; saved text alone does not prove retrieval readiness.
  • Synthetic example: Add a question about returns with the exact approved window and exclusions, wait for indexing, then ask the question and a paraphrase and inspect citations.
  • Limits / when not to use: Saving text is not embedding completion. An AI draft or an old imported policy must not be accepted as authoritative just to increase coverage.
  • If it does not work: Check document/indexing state and conflicting sources. If deleted material reappears, inspect the importing source and its refresh path rather than repeatedly deleting the local copy.
  • Detailed guide: /docs/ai-agent/knowledge-base

Imports and sync

/imports · Catalog, products & knowledge

Starts and monitors commerce imports, manual syncs, migration previews, and recent job state.

  • Why and when: Follow catalog and knowledge background work to completion and investigate differences between connected and searchable data.
  • Merchant workflow: Choose the correct source, run a controlled import, and inspect counts and errors before relying on the data.
  • Verify: Require a completed status plus sample-level comparison; check the connection, Notifications, Store Details, and contact support when processing stalls.
  • Synthetic example: Run one controlled sync, record its job ID and counts, then compare a simple product, a multi-variant product and a policy source.
  • Limits / when not to use: Queued, running and completed are different states. A worker and reachable services are required; a connection badge alone does not establish readiness.
  • If it does not work: Check Store Details and Notifications. Avoid repeated overlapping imports; collect the job ID, time and safe error before asking support about a stalled job.
  • Detailed guide: /docs/imports

Competitor migration preview

/imports/from-competitor · Store settings & security

Parses supported Tidio, Gorgias, or Klaviyo exports into a preview before applying supported records.

  • Why and when: Preview supported records from an existing helpdesk or marketing export before applying a migration.
  • Merchant workflow: Upload a supported export, inspect translated counts and warnings, then explicitly apply the preview.
  • Verify: Compare the applied record counts and samples; unsupported source fields remain a manual migration task.
  • Synthetic example: Upload a synthetic supported export, compare preview counts and warnings with the source file, and apply only after inspecting the translated fields.
  • Limits / when not to use: This is not full-fidelity migration of every vendor feature. Unsupported fields, history and archived macros require separate review.
  • If it does not work: Check the selected source format and parser warning. Keep the source export and compare applied counts before repeating an import that might already have completed.
  • Detailed guide: /docs/imports

Shopify import

/imports/shopify · Catalog, products & knowledge

Explains and surfaces Shopify-specific connection and catalog import state.

  • Why and when: Inspect sync for an existing authorized Shopify connection; new connections are coming soon.
  • Merchant workflow: For an existing authorized Shopify connection, verify required scopes and monitor its import. New Shopify connections are coming soon.
  • Verify: Confirm webhook health, sample catalog data, and a completed merchant-visible import status rather than relying on connection status alone.
  • Synthetic example: On an existing connection, inspect granted scopes and the last completed import, then compare a sample product and order with Shopify. This is an illustrative check, not an install test.
  • Limits / when not to use: A connected badge does not establish fresh catalog indexing or permission for every order action.
  • If it does not work: Check authorization, source timestamps and job errors before repeating a sync.
  • Detailed guide: /docs/integrations/shopify

WooCommerce import

/imports/woocommerce · Catalog, products & knowledge

Explains and surfaces WooCommerce plugin pairing and import state.

  • Why and when: Complete the managed platform connection and verify the first usable catalog and operational events.
  • Merchant workflow: Install and pair the plugin, verify the API base URL, then run or inspect synchronization.
  • Verify: Confirm plugin health, sample products and orders, and a completed merchant-visible import status.
  • Synthetic example: On WooCommerce, install and pair the plugin, confirm its reported API base URL, wait for sync, then compare a product and historical order with the store.
  • Limits / when not to use: New Shopify connections are coming soon; existing authorized stores may use supported sync paths and required scopes. WooCommerce requires its plugin and pairing. Custom stores use the Pro public ingestion API instead of these managed import routes.
  • If it does not work: Check authorization, plugin health or required scopes before re-running sync. A blocked connection and a failed embedding job have different owners.
  • Detailed guide: /docs/integrations/woocommerce

Recovery and campaigns

Typical access: Recovery capability; owner and full-access store members have all capabilities

Journeys

/journeys · Recovery & campaigns · Growth

Lists lifecycle automations, triggers, status, run volume, and measured outcomes.

  • Why and when: Automate a supported lifecycle event when a one-off campaign cannot express the entry, delay and exit rules.
  • Merchant workflow: Start with one narrow audience and review the journey before activation.
  • Verify: Use a controlled eligible profile to confirm entry, step timing, exits, suppression, provider delivery, and attribution.
  • Synthetic example: Create one narrow cart-abandonment journey in draft, inspect its email step and delay, activate in a test store, and verify a purchase exits the controlled enrolment.
  • Limits / when not to use: Growth is required; SMS and WhatsApp need Pro and configured approved channels. Available events depend on source data, consent and worker execution.
  • If it does not work: Trace entry eligibility, the next due step, quiet hours, suppression and provider state in order. Pausing a journey does not recall a message already accepted by a provider.
  • Detailed guide: /docs/recovery/journeys

New journey

/journeys/new · Recovery & campaigns · Growth

Builds a triggered multi-step journey with delays, messages, branches, and exit rules.

  • Why and when: Automate a supported lifecycle event when a one-off campaign cannot express the entry, delay and exit rules.
  • Merchant workflow: Define the trigger, eligibility, steps, delays, exits, and content; save as a draft first.
  • Verify: Preview every branch and activate only after provider, consent, and suppression checks pass.
  • Synthetic example: Create one narrow cart-abandonment journey in draft, inspect its email step and delay, activate in a test store, and verify a purchase exits the controlled enrolment.
  • Limits / when not to use: Growth is required; SMS and WhatsApp need Pro and configured approved channels. Available events depend on source data, consent and worker execution.
  • If it does not work: Trace entry eligibility, the next due step, quiet hours, suppression and provider state in order. Pausing a journey does not recall a message already accepted by a provider.
  • Detailed guide: /docs/recovery/journeys

Journey detail

/journeys/:journeyId · Recovery & campaigns · Growth

Edits, activates, pauses, and reports on one lifecycle journey.

  • Why and when: Automate a supported lifecycle event when a one-off campaign cannot express the entry, delay and exit rules.
  • Merchant workflow: Review the current version and recent runs before changing or activating it.
  • Verify: Confirm status and version after saving, then inspect a fresh controlled run rather than historical results.
  • Synthetic example: Create one narrow cart-abandonment journey in draft, inspect its email step and delay, activate in a test store, and verify a purchase exits the controlled enrolment.
  • Limits / when not to use: Growth is required; SMS and WhatsApp need Pro and configured approved channels. Available events depend on source data, consent and worker execution.
  • If it does not work: Trace entry eligibility, the next due step, quiet hours, suppression and provider state in order. Pausing a journey does not recall a message already accepted by a provider.
  • Detailed guide: /docs/recovery/journeys

Cart Rescue

/rescue · Recovery & campaigns

Configures in-session hesitation detection, risk thresholds, audience rules, playbooks, and rescue outcomes.

  • Why and when: Test an intervention while an eligible shopper is still on the storefront with a cart.
  • Merchant workflow: Tune one rule at a time and test it in a clean storefront session with a qualifying cart.
  • Verify: Confirm the trigger, shopper experience, event record, suppression, and eventual order outcome.
  • Synthetic example: Use a clean test session with a qualifying cart, trigger the configured hesitation condition, and confirm a non-qualifying session sees no offer.
  • Limits / when not to use: Live rescue differs from post-abandonment email. An offer must fit approved limits; missing product costs do not establish profit protection.
  • If it does not work: Check widget audience rules, enablement, cart context and frequency suppression before changing the risk threshold. Test the actual storefront, not only preview.
  • Detailed guide: /docs/rescue

Recovery

/recovery · Recovery & campaigns

Reports cart and browse abandonment, queued or delivered recovery messages, suppression, clicks, conversions, and failures.

  • Why and when: Investigate a cart or browse follow-up from eligibility through suppression, send and associated order.
  • Merchant workflow: Inspect eligibility and provider state before treating a missed recovery as an AI problem.
  • Verify: Trace one cart from abandonment through queue, send result, click, order, and the documented attribution window.
  • Synthetic example: Trace one consented test shopper who abandons a cart and another who purchases before the queued send; the purchased case should be suppressed.
  • Limits / when not to use: An associated order is not measured incremental email lift. A chat-only holdout does not isolate the effect of recovery messages.
  • If it does not work: Check the shopper identity, consent, unsubscribe and purchase state, sender configuration, queue and provider error before retrying a send.
  • Detailed guide: /docs/recovery

Promo bars

/promo-bars · Recovery & campaigns

Creates and schedules storefront announcement bars with targeting and display state.

  • Why and when: Show a concise announcement to a defined storefront audience during a real schedule or promotion.
  • Merchant workflow: Draft the message, audience, schedule, and destination, then preview before enabling.
  • Verify: Open a qualifying storefront session and a non-qualifying session to verify both display and suppression.
  • Synthetic example: Draft a shipping announcement with the actual policy link, preview it, then check one qualifying page and an excluded page at mobile width.
  • Limits / when not to use: Display state does not reserve stock or hold a price. Dates and offer claims must reflect a real promotion.
  • If it does not work: Check enabled state, schedule timezone, audience and page exclusions. Verify the store's loader is present before editing the message again.
  • Detailed guide: /docs/promo-bars

Broadcasts

/broadcasts · Recovery & campaigns · Growth; SMS and WhatsApp require Pro

Queues one-off campaigns from a brief to supported built-in or saved custom segments, and explicitly launches Campaign Composer drafts.

  • Why and when: Send a one-off campaign from a reviewed brief to a supported audience when immediate sending is intended.
  • Merchant workflow: Review Segment, Channel and Brief or the existing draft before Queue broadcast or Launch draft; email/SMS text is generated afterward and WhatsApp uses an approved template.
  • Verify: Confirm recipient eligibility, suppression, provider acceptance, failures, and received examples; completion does not mean inbox placement.
  • Synthetic example: Choose a built-in or supported saved custom segment, channel and factual restock brief. Check audience and consent first; queued email/SMS copy is generated per recipient from that brief.
  • Limits / when not to use: Queue broadcast starts processing; it is not per-recipient copy approval or a scheduler. Campaign Composer drafts require Launch draft. Growth is required, with Pro for SMS/WhatsApp.
  • If it does not work: Check entitlement, segment ownership and criteria, connected sender, opt-outs and recipient eligibility. Inspect campaign and provider state before repeating a request.
  • Detailed guide: /docs/broadcasts

Social posts

/social · Recovery & campaigns · Some connected social channels require Pro multi-channel entitlement

Generates, edits, schedules, publishes, and deletes social drafts. AI post and image generation are on by default and can be paused platform-wide by an operator, in which case the page says so and manual editing continues to work.

  • Why and when: Prepare or edit a post, then explicitly schedule or publish it to a connected supported account.
  • Merchant workflow: Connect the provider, review or generate a draft, edit it, optionally attach a public HTTPS image URL, then explicitly publish or schedule.
  • Verify: Verify the provider-side post or schedule; local saved state is not external publication proof.
  • Synthetic example: Draft a factual new-product post, replace an unsupported claim, attach a public HTTPS image when appropriate, and confirm the final post on the selected account.
  • Limits / when not to use: AI generation can be paused for the service. Manual editing remains separate from generation, and provider approval/permissions can prevent publishing.
  • If it does not work: Read the page's current generation notice, check the selected network and permissions, and inspect provider output before resubmitting an uncertain publish.
  • Detailed guide: /docs/social

Analytics, orders, shoppers, and reports

Typical access: Analytics capability; owner and full-access store members have all capabilities

Analytics

/analytics · Analytics, orders & customers

Shows tracked funnels, attributed events, trends, and date-range comparisons, plus the Profit section (profit by product, daily trend, CSV export) on plans with profit analytics.

  • Why and when: Compare tracked behavior across a defined period and reconcile attributed revenue with underlying orders.
  • Merchant workflow: Select a stable date range and drill from aggregate metrics into source records where available.
  • Verify: Reconcile definitions, timezone, currency, exclusions, and a sample of orders before reporting a number.
  • Synthetic example: Record a complete week's timezone and currency, compare one attributed order with its qualifying recommendation and line item, and separate profit from gross order value.
  • Limits / when not to use: Attribution is not causal lift. Profit reporting depends on costs and fees; cross-store benchmarks need cohort and coverage context.
  • If it does not work: Compare raw order IDs, status, amount, currency and timing before interpreting attribution differences. Check source-event coverage when the funnel unexpectedly falls to zero.
  • Detailed guide: /docs/analytics

Cohorts

/analytics/cohorts · Analytics, orders & customers

Compares shopper cohorts and retention or repeat behavior over time.

  • Why and when: Understand whether comparable first-order groups return to buy over later periods.
  • Merchant workflow: Choose the cohort basis and compare like-for-like windows.
  • Verify: Confirm cohort membership and incomplete-period handling before drawing conclusions.
  • Synthetic example: Compare two first-order months at the same number of elapsed months rather than comparing a mature cohort with the current partial month.
  • Limits / when not to use: Cohort differences can reflect acquisition mix, seasonality or incomplete observation. They do not establish that an automation caused retention.
  • If it does not work: Check cohort basis, order history coverage and incomplete periods. Reconcile a sample shopper's order dates before treating an empty cell as churn.
  • Detailed guide: /docs/analytics

Funnel

/analytics/funnel · Analytics, orders & customers

Shows conversion and drop-off across tracked shopper events.

  • Why and when: Locate a tracked drop-off worth investigating in actual shopper sessions.
  • Merchant workflow: Select the period and inspect the largest drop between defined steps.
  • Verify: Validate that each step has event coverage; missing tracking is not shopper abandonment.
  • Synthetic example: An add-to-cart step falls while conversations remain stable. Inspect matching sessions and event ingestion before changing the opening message.
  • Limits / when not to use: An event missing from the implementation or source platform looks like a drop-off. Funnel order is a measurement definition, not proof of shopper motivation.
  • If it does not work: Replay a controlled tracked session, compare event timestamps and identity, and check filters and integration health before drawing a conversion conclusion.
  • Detailed guide: /docs/analytics

Conversation Insights

/insights · Analytics, orders & customers · Growth

Shows product gaps, objections, competitor mentions and top questions mined weekly from shopper messages across web chat, email and messaging channels, with counts, trends and sample conversations.

  • Why and when: Turn recurring shopper questions, objections or product gaps into a reviewable catalog or knowledge task.
  • Merchant workflow: Review each theme's quotes and sample conversations, then act: check the catalog for a gap, add an objection response, or draft an FAQ into AI Improver.
  • Verify: Open a sample conversation for a theme and confirm the shopper actually raised it; counts are distinct conversations in the stated period.
  • Synthetic example: Open the sample conversations for a compatibility theme, confirm the shoppers asked it, then draft an FAQ only from an approved specification.
  • Limits / when not to use: Growth and analytics access apply. AI grouping can be wrong; minimum conversation volume, refresh limits and AI budget can leave no new analysis.
  • If it does not work: Read the analysis timestamp and eligibility/cap notice. Distinguish insufficient conversations from a failed generation and verify quotes against the original threads.
  • Detailed guide: /docs/insights

Weekly review

/analytics/weekly-review · Analytics, orders & customers

Shows a saved weekly operating snapshot, wins, risks, and suggested follow-up actions.

  • Why and when: Build a recurring operating worklist from the saved weekly snapshot and its source evidence.
  • Merchant workflow: Review source metrics and open the owning workspace for each proposed action.
  • Verify: Treat suggestions as a worklist; confirm impact in source data after the change.
  • Synthetic example: Take one suggested knowledge action, open its source conversations, apply an approved correction, and compare the next complete period without claiming causal lift.
  • Limits / when not to use: Suggestions are hypotheses, and a saved snapshot can lag the current store state.
  • If it does not work: Check snapshot date and source periods. If a recommendation is stale, inspect its owning workspace instead of repeatedly changing unrelated settings.
  • Detailed guide: /docs/analytics

Shoppers

/customers · Analytics, orders & customers

Searches shopper profiles with lifecycle, spend, identity, consent, segments, and activity context.

  • Why and when: Review a shopper's known activity, lifecycle and requested follow-up with the appropriate consent and identity context.
  • Merchant workflow: Find a profile and review consent and identity before taking customer-specific action.
  • Verify: Confirm orders and channel identities belong to the same shopper before relying on stitched data.
  • Synthetic example: Find a test shopper by email, compare orders and conversations, and distinguish a service follow-up request from optional marketing consent.
  • Limits / when not to use: Known identity is not always verified identity. Recorded spend is realized history, not a predictive lifetime value, and a lead is not blanket permission to message.
  • If it does not work: Compare store, source IDs and channel links before merging assumptions about the same person. Check source-order ingestion if activity or spend is missing.
  • Detailed guide: /docs/customers

Shopper detail

/customers/:shopperProfileId · Analytics, orders & customers

Shows one shopper's orders, conversations, lifecycle, segments, loyalty or credit context, and permitted actions.

  • Why and when: Review a shopper's known activity, lifecycle and requested follow-up with the appropriate consent and identity context.
  • Merchant workflow: Review the unified timeline and consent before support, marketing, credit, or segmentation changes.
  • Verify: Reload and verify the intended profile changed without affecting another store or shopper.
  • Synthetic example: Find a test shopper by email, compare orders and conversations, and distinguish a service follow-up request from optional marketing consent.
  • Limits / when not to use: Known identity is not always verified identity. Recorded spend is realized history, not a predictive lifetime value, and a lead is not blanket permission to message.
  • If it does not work: Compare store, source IDs and channel links before merging assumptions about the same person. Check source-order ingestion if activity or spend is missing.
  • Detailed guide: /docs/customers

Segments

/segments · Analytics, orders & customers

Builds and inspects live shopper audiences, including saved custom criteria supported by the broadcast and campaign-composer paths.

  • Why and when: Inspect built-in live audiences or save custom criteria for analysis and supported campaign targeting.
  • Merchant workflow: Define criteria, inspect members and boundary cases, then save; use a segment in another feature only when that destination supports it.
  • Verify: Confirm current membership and eligibility separately; a custom analysis segment does not imply universal journey or widget targeting support.
  • Synthetic example: Build a custom segment for a synthetic quiz-answer trait, inspect matching shoppers and a non-matching boundary case, then select the saved segment only in a destination that offers it.
  • Limits / when not to use: Broadcasts support store-owned custom segments; this does not establish universal support in journeys or widget rules. Membership is resolved from current profile data, not a frozen contact list.
  • If it does not work: Check field units and operators against actual shopper values, and confirm destination support and store ownership. A changed count can reflect changed profile data rather than a failed save.
  • Detailed guide: /docs/segments

Reports and exports

/reports · Analytics, orders & customers

Offers supported store-scoped prebuilt CSV downloads generated on demand.

  • Why and when: Download one of the supported store-scoped CSV datasets for a specific reconciliation or analysis task.
  • Merchant workflow: Choose the smallest required dataset and read its documented window, then download it from Reports.
  • Verify: Open the export, verify headers, row counts, timezone, and a sample; protect downloaded personal data.
  • Synthetic example: Download the Orders report, inspect headers, currency and a sample platform order ID, then store the file only where authorized.
  • Limits / when not to use: Prebuilt reports use their documented fixed window. Public API reads do not provide arbitrary historical orders, customers or revenue exports.
  • If it does not work: Check access, export type and the documented window; compare a known included record rather than relying on the card's approximate row count.
  • Detailed guide: /docs/reports

Orders

/orders · Analytics, orders & customers

Lists synchronized commerce orders, fulfillment context, and directional AI-attribution indicators.

  • Why and when: Investigate commerce state or inspect the exact evidence behind one AI-attribution label.
  • Merchant workflow: Filter and open an order to trace status and qualifying AI interactions.
  • Verify: Reconcile amount, currency, status, line items, and platform ID with the commerce source.
  • Synthetic example: Open a synthetic order, compare its source ID and purchased product with the last qualifying recommendation, and note the full-order credit rule.
  • Limits / when not to use: Full-order attribution can over-credit influence; it is not a floor or causal profit. WooCommerce cancel/edit/refund requests become tickets; address changes have a separate path.
  • If it does not work: Compare filters, dates, native platform statuses and sync timestamps. Use an unfiltered total when calculating attributed share; a filtered denominator can mislead.
  • Detailed guide: /docs/orders

Order detail

/orders/:orderId · Analytics, orders & customers

Shows one order's line items, shopper context, commerce state, and qualifying interaction evidence.

  • Why and when: Investigate commerce state or inspect the exact evidence behind one AI-attribution label.
  • Merchant workflow: Use the platform order ID and timeline to investigate fulfillment, support, or attribution.
  • Verify: Confirm the source-platform order before acting; a qualifying interaction is not proof of incremental lift.
  • Synthetic example: Open a synthetic order, compare its source ID and purchased product with the last qualifying recommendation, and note the full-order credit rule.
  • Limits / when not to use: Full-order attribution can over-credit influence; it is not a floor or causal profit. WooCommerce cancel/edit/refund requests become tickets; address changes have a separate path.
  • If it does not work: Compare filters, dates, native platform statuses and sync timestamps. Use an unfiltered total when calculating attributed share; a filtered denominator can mislead.
  • Detailed guide: /docs/orders

AI quality, feedback, and training

Typical access: Training capability; owner and full-access store members have all capabilities

AI Quality

/training · AI training & quality

Summarizes catalog, knowledge, feedback, gap, lead, and automation signals that need merchant attention.

  • Why and when: Choose the owning correction workflow rather than changing prompts for every answer-quality problem.
  • Merchant workflow: Use the highest-impact worklist card to open the owning training surface.
  • Verify: Return after changes and confirm the source metric changed; recommendations are not automatic fixes.
  • Synthetic example: A weak-answer signal points to an old return policy. Open its original thread, then correct Knowledge and test indexing rather than adjusting the widget theme.
  • Limits / when not to use: Quality signals and worklist counts do not certify answer correctness or make automatic corrections.
  • If it does not work: Follow the original evidence and classify the issue as knowledge, catalog, ranking, tone, tool or handoff. Return after the underlying change completes.
  • Detailed guide: /docs/ai-agent/training

Knowledge Gaps

/training/gaps · AI training & quality

Lists weak-answer shopper prompts and merchant feedback that may require knowledge, policy, catalog, or handoff changes.

  • Why and when: Turn an unsupported or incorrect response into an approved source-backed correction.
  • Merchant workflow: Open the original thread, then draft or write a grounded answer and review it before approval.
  • Verify: After approval and embedding completion, test retrieval and citations with a relevant question.
  • Synthetic example: Reject a suggested warranty duration that has no source. Write the verified policy instead, approve through the supported flow and test the original question after indexing.
  • Limits / when not to use: AI suggestions are drafts. Partial but speculative answers must not be published to improve a coverage score.
  • If it does not work: Check approval and embedding state, source conflicts and the original feedback. Do not interpret a saved draft as a live retrieval fix.
  • Detailed guide: /docs/ai-agent/training

Leads

/training/leads · AI training & quality

Lists shopper leads captured by supported AI and channel flows with their context.

  • Why and when: Review a shopper's known activity, lifecycle and requested follow-up with the appropriate consent and identity context.
  • Merchant workflow: Review identity, consent, source, and requested follow-up before exporting or contacting a lead.
  • Verify: Confirm downstream handling and avoid treating capture as consent for every channel.
  • Synthetic example: Find a test shopper by email, compare orders and conversations, and distinguish a service follow-up request from optional marketing consent.
  • Limits / when not to use: Known identity is not always verified identity. Recorded spend is realized history, not a predictive lifetime value, and a lead is not blanket permission to message.
  • If it does not work: Compare store, source IDs and channel links before merging assumptions about the same person. Check source-order ingestion if activity or spend is missing.
  • Detailed guide: /docs/customers

Locked Facts

/training/facts · AI training & quality

Maintains exact merchant-approved facts that should take precedence over generated inference.

  • Why and when: Keep short consequential facts explicit, such as exclusions or shipping cutoff conditions.
  • Merchant workflow: Add concise, current facts for high-risk policies, limits, and commitments.
  • Verify: Test exact and paraphrased questions, then inspect the response and source behavior.
  • Synthetic example: Add the approved weekday dispatch cutoff with timezone and exceptions, then ask about a normal weekday and a holiday.
  • Limits / when not to use: A locked fact is a grounding input, not a guarantee that an AI response can never be wrong. Keep detailed policies in their authoritative source.
  • If it does not work: Look for stale or contradictory facts, overly broad wording and missing exceptions. Re-test paraphrases and handoff rather than only the exact sentence.
  • Detailed guide: /docs/ai-agent/training

FAQ

/training/faq · AI training & quality

Creates and manages merchant-approved question-and-answer knowledge.

  • Why and when: Give the assistant approved shipping, returns and other policy evidence that does not belong in product fields.
  • Merchant workflow: Write one clear question and grounded answer per intent, then save and index it.
  • Verify: Ask alternate phrasings after embedding completes and confirm the answer stays within the approved fact.
  • Synthetic example: Add a question about returns with the exact approved window and exclusions, wait for indexing, then ask the question and a paraphrase and inspect citations.
  • Limits / when not to use: Saving text is not embedding completion. An AI draft or an old imported policy must not be accepted as authoritative just to increase coverage.
  • If it does not work: Check document/indexing state and conflicting sources. If deleted material reappears, inspect the importing source and its refresh path rather than repeatedly deleting the local copy.
  • Detailed guide: /docs/ai-agent/knowledge-base

Enrichment

/training/enrichment · AI training & quality

Surfaces AI-suggested catalog or knowledge improvements for merchant review.

  • Why and when: Review proposed catalog or content improvements against the product's actual source fields.
  • Merchant workflow: Compare every suggestion with authoritative source data before applying it.
  • Verify: Confirm the applied field and test its downstream use; rejected suggestions should not affect live behavior.
  • Synthetic example: An enrichment suggests a material claim. Compare it with the manufacturer's specification; apply the supported wording and reject an unsupported certification.
  • Limits / when not to use: Generated enrichment must not invent compatibility, health benefits, certifications or customer proof. A local change is not always a platform write-back.
  • If it does not work: Check which field and source own the saved change, sync state and indexing. Inspect the source product when a later import overwrites an improvement.
  • Detailed guide: /docs/ai-catalog-improver

Product Tuning

/training/products · AI training & quality

Controls how individual products participate in AI discovery and recommendations.

  • Why and when: Tune product discovery after the catalog is accurate, using actual recommendation events and test queries.
  • Merchant workflow: Adjust a product's guidance or visibility only after checking its source data and merchandising policy.
  • Verify: Run targeted and counterexample shopper queries to verify the intended ranking or exclusion.
  • Synthetic example: Boost an appropriate rain jacket for a rainy-weather query, then test an unrelated gift query and an unavailable variant.
  • Limits / when not to use: A ranking multiplier changes a score, not a calibrated exposure probability. Product-match attribution is directional and ranking confidence is not measured answer accuracy.
  • If it does not work: Check rule scope, product status, stock, relevance, costs and competing rules before increasing weight again.
  • Detailed guide: /docs/recommendations

AI Improver

/ai-improver · AI training & quality

Turns negative message feedback into merchant-reviewable correction work and measured learning signals.

  • Why and when: Turn an unsupported or incorrect response into an approved source-backed correction.
  • Merchant workflow: Review the original response, apply the appropriate correction path, and avoid approving unsupported content.
  • Verify: Verify the resulting knowledge, prompt, or ranking input exists and test the affected scenario.
  • Synthetic example: Reject a suggested warranty duration that has no source. Write the verified policy instead, approve through the supported flow and test the original question after indexing.
  • Limits / when not to use: AI suggestions are drafts. Partial but speculative answers must not be published to improve a coverage score.
  • If it does not work: Check approval and embedding state, source conflicts and the original feedback. Do not interpret a saved draft as a live retrieval fix.
  • Detailed guide: /docs/ai-agent/training

Reviews hub

/reviews · AI training & quality

One route with three tabs: AI feedback (per-message good, incomplete, wrong, needs-handoff ratings and negative themes), Product reviews (ingested review corpus and Voice-of-Customer), and Moderation queue (flagged conversations plus PDP Q&A drafts).

  • Why and when: Choose AI feedback, Product reviews or Moderation queue according to whether you are assessing an answer, product evidence or flagged content.
  • Merchant workflow: Pick the tab that owns the problem, then fix the underlying knowledge, rule, catalog, or handoff configuration; tabs you lack the capability for are not shown.
  • Verify: Confirm the feedback or review is attached to the intended message or product, and re-test the corrected scenario; AI feedback needs Training permission; Product reviews needs Growth tools role access plus the reviews plan entitlement; Moderation queue needs both Training and Catalog permissions.
  • Synthetic example: Open Reviews, choose Moderation queue, inspect a flagged conversation and its source before approving a PDP Q&A draft or correcting a policy.
  • Limits / when not to use: The three tabs have different capability and entitlement requirements. Review ingestion requires a supported adapter; a flag is not proof of a defect.
  • If it does not work: Check active tab, rating/source filters, ingestion adapter and role. Legacy review routes redirect with supported filters rather than exposing separate stores of reviews.
  • Detailed guide: /docs/reviews

Growth, merchandising, widget, and review tools

Typical access: Growth or widget capability as shown per route; owner and full-access store members have all capabilities

A/B Tests

/ab-tests · Growth tools (A/B, playbooks, loyalty, content)

Evaluates supported opening-message A/B/C tests, prompt variants and widget-theme A/B outcomes.

  • Why and when: Compare supported opening-message, prompt or widget-theme variants with a defined primary metric and rollout plan.
  • Merchant workflow: Change one controlled variable, define the primary metric and stopping plan, and review eligible traffic; opening-message automatic promotion applies only to two arms.
  • Verify: Check allocation, sample sizes, purchase guardrails and uncertainty before promotion; repeated inspection and optional C complicate confidence interpretation.
  • Synthetic example: Compare two grounded greetings on add-to-cart, keep other settings stable, record sample and horizon, and review purchases as a guardrail before promotion.
  • Limits / when not to use: Optional C is supported for greetings; automatic promotion is two-arm only. Repeated checks and multiple comparisons need care; minimum samples do not prove a winner.
  • If it does not work: Check assignment, persistence and event counts before interpreting lift. Do not end solely because a small early sample is negative.
  • Detailed guide: /docs/ab-testing

Recommendations

/recommendations · Growth tools (A/B, playbooks, loyalty, content)

Reports recommendation performance and manages boosts, blocks, and bundle candidates.

  • Why and when: Tune product discovery after the catalog is accurate, using actual recommendation events and test queries.
  • Merchant workflow: Review event evidence, then make one merchandising change at a time.
  • Verify: Test relevant shopper queries and confirm the rule affects only the intended products or audience.
  • Synthetic example: Boost an appropriate rain jacket for a rainy-weather query, then test an unrelated gift query and an unavailable variant.
  • Limits / when not to use: A ranking multiplier changes a score, not a calibrated exposure probability. Product-match attribution is directional and ranking confidence is not measured answer accuracy.
  • If it does not work: Check rule scope, product status, stock, relevance, costs and competing rules before increasing weight again.
  • Detailed guide: /docs/recommendations

Playbooks

/playbooks · Growth tools (A/B, playbooks, loyalty, content)

Manages supported procedures and automation recipes for merchant and agent workflows.

  • Why and when: Reuse a supported automation recipe or define the agent's instructions for a repeatable conversational task.
  • Merchant workflow: Choose a playbook, review prerequisites and actions, then configure it for a narrow use case.
  • Verify: Run a controlled scenario and inspect each side effect before wider rollout.
  • Synthetic example: Install a suitable journey recipe, open the created journey and review delays and consent. For an agent playbook, test one matching request and one that should hand off.
  • Limits / when not to use: Journey templates and conversation playbooks have different execution paths. Installing a recipe does not establish provider readiness or permission for every side effect.
  • If it does not work: Check whether the problem is trigger matching, missing source event, a paused journey, disabled tool or unavailable provider. Inspect the installed instance rather than re-installing duplicates.
  • Detailed guide: /docs/playbooks

Agent Playbooks

/playbooks/agent · Growth tools (A/B, playbooks, loyalty, content)

Shows procedures specifically available to the AI agent during conversations.

  • Why and when: Reuse a supported automation recipe or define the agent's instructions for a repeatable conversational task.
  • Merchant workflow: Review triggers, instructions, tools, and escalation boundaries before enabling an agent playbook.
  • Verify: Test positive, negative, and handoff cases and inspect tool results.
  • Synthetic example: Install a suitable journey recipe, open the created journey and review delays and consent. For an agent playbook, test one matching request and one that should hand off.
  • Limits / when not to use: Journey templates and conversation playbooks have different execution paths. Installing a recipe does not establish provider readiness or permission for every side effect.
  • If it does not work: Check whether the problem is trigger matching, missing source event, a paused journey, disabled tool or unavailable provider. Inspect the installed instance rather than re-installing duplicates.
  • Detailed guide: /docs/playbooks

Product-Finder Quizzes

/quizzes · Growth tools (A/B, playbooks, loyalty, content) · Growth

Builds shareable guided-selling quizzes whose answers map to catalog filters, become zero-party shopper data, and feed segments and journeys.

  • Why and when: Ask structured preference questions when catalog filters can produce useful product recommendations.
  • Merchant workflow: Generate a draft from your catalog with AI or create one manually, review every question and its filter mappings, then publish and share the quiz URL.
  • Verify: Take the published quiz in a fresh browser session and confirm the recommendation grid, the recorded completion, and the quiz-answer trait on the shopper profile.
  • Synthetic example: Create a synthetic gift-finder question about intended activity, map answers to real product filters, publish, and take it in a fresh session including a no-match answer.
  • Limits / when not to use: Growth is required. Answers are zero-party data only for their stated purpose; a quiz completion does not create universal marketing consent.
  • If it does not work: Review filter mappings, product availability and publish state. Compare the result grid, recorded completion and shopper trait before activating downstream uses.
  • Detailed guide: /docs/playbooks

Loyalty

/loyalty · Growth tools (A/B, playbooks, loyalty, content) · Growth

Shows enrolled shoppers, points earned and redeemed, the reward catalog with how each reward is delivered and code-pool stock, redemption history, and earn-rate tiers. Signed-in shoppers redeem rewards in the chat widget or through the AI.

  • Why and when: Offer clear points rewards whose delivery method and checkout behavior your team can support.
  • Merchant workflow: Configure rewards with a delivery method (code pool, shared code, WooCommerce auto-generated coupon, or sent by your team), keep code pools stocked, then test earning and one redemption with a controlled account.
  • Verify: Confirm the controlled order credited points, then redeem a reward as that shopper and check the ledger shows the deduction, the issued code, and the Redeemed (7d) figure.
  • Synthetic example: Create a modest test reward, upload a real test code pool, earn points with a controlled order, redeem once and confirm the code applies and points are deducted once.
  • Limits / when not to use: Growth is required. Shopify uses code pools or a shared code; automatic coupon generation is WooCommerce only. Manual fulfillment requires a staffed team.
  • If it does not work: Check active reward, points, code stock and delivery method. A deducted balance is not proof the coupon worked at checkout; inspect the redemption record before repeating.
  • Detailed guide: /docs/loyalty

Redemption tiers

/loyalty/redemption-tiers · Growth tools (A/B, playbooks, loyalty, content) · Growth

Defines points thresholds and the reward each is worth. Shoppers can redeem an active tier; Zubby deducts the points and opens a ticket for your team to send the reward.

  • Why and when: Use points thresholds for rewards your team will fulfill manually, with clear terms and ownership.
  • Merchant workflow: Create clear thresholds, mark the ones shoppers should hear about as active, and agree how your team sends each reward. Use the reward catalog instead when shoppers should get a code instantly.
  • Verify: Redeem a tier as a test shopper and check the points were deducted once and a ticket reached your inbox.
  • Synthetic example: Create an active test tier, redeem it once as a controlled shopper, and confirm the points deduction and the fulfillment ticket.
  • Limits / when not to use: This route creates a ticket rather than an instant coupon. Use the reward catalog when immediate code delivery is required.
  • If it does not work: Check tier active state, threshold and shopper balance, then find the ticket in Inbox. Do not redeem again merely because manual fulfillment has not yet happened.
  • Detailed guide: /docs/loyalty

Referrals

/loyalty/referrals · Growth tools (A/B, playbooks, loyalty, content) · Growth

Saves referral program settings. Not active: no referral codes are generated, referred orders are not recorded, and no rewards are paid.

  • Why and when: Keep proposed referral settings on file while evaluating a future program.
  • Merchant workflow: Only save a program if you want the settings on file; do not announce a referral offer to shoppers based on this page.
  • Verify: Counters and the recent-referrals table stay at zero because nothing records referrals; treat any program here as inactive.
  • Synthetic example: Save draft program terms for internal review and label the offer inactive in your planning notes.
  • Limits / when not to use: Referral codes, referred-order recording and reward payment are not active. Do not advertise a working referral program from this settings page.
  • If it does not work: Zero referral counters are expected in the current implementation; changing a threshold cannot enable the missing referral execution path.
  • Detailed guide: /docs/loyalty

VIP tiers

/loyalty/vip-tiers · Growth tools (A/B, playbooks, loyalty, content) · Growth

Defines spend-based standing graded on lifetime spend and order count, separate from points-based loyalty tiers, and shows how many shoppers hold each tier.

  • Why and when: Classify shopper standing from recorded lifetime spend and order count, separately from redeemable points.
  • Merchant workflow: Add tiers from lowest to highest rank, keeping thresholds far enough apart that a single order does not skip a level; the highest qualifying rank wins.
  • Verify: Membership is recalculated once a day, so confirm counts on the following day and check a known shopper's standing before relying on it in campaigns.
  • Synthetic example: Create two test tiers with explicit ranks and thresholds, then check a known shopper after the next daily recalculation.
  • Limits / when not to use: Membership refresh is daily and the highest qualifying rank wins. Lifetime spend is historical revenue, not predictive gross-profit CLV.
  • If it does not work: Check threshold units, rank ordering, synced order history and the last recalculation before treating a delayed tier change as a failed save.
  • Detailed guide: /docs/loyalty

Affiliates

/affiliates · Growth tools (A/B, playbooks, loyalty, content)

Manages partners, tracked links, clicks, and attributed commerce outcomes.

  • Why and when: Track an approved partner's referral link and reconcile attributed orders before a manual payout decision.
  • Merchant workflow: Create a partner and link, disclose terms, then test the complete click-to-order path.
  • Verify: Reconcile the click and order IDs and apply the documented attribution rules before payout.
  • Synthetic example: Create a test partner and link, follow it in a controlled session and compare the resulting click and order IDs under the documented window.
  • Limits / when not to use: Tracked attribution does not prove incremental sales or automatically settle a partner payment. Terms, fraud checks and payout ownership remain separate.
  • If it does not work: Check link destination, cookie/window behavior, order sync and identity continuity before changing commission or paying on a missing event.
  • Detailed guide: /docs/affiliates

Widget Designer

/widget-designer · Widget designer · Core designer is available; premium themes require Growth

Configures widget appearance, launcher, copy, placement, behavior, audience, and preview.

  • Why and when: Configure the assistant's appearance, copy and supported placement for the actual storefront layout.
  • Merchant workflow: Edit in preview, save, then test the deployed storefront on desktop and mobile.
  • Verify: Confirm the correct store key, audience behavior, accessibility, theme compatibility, and shopper flows.
  • Synthetic example: Preview a launcher and inline placement, save, then test mobile open/close, keyboard focus, a product question and an audience exclusion on the storefront.
  • Limits / when not to use: Preview is not theme compatibility proof. Launcher and inline are placements; proactive opens and popup offers are behaviors. Lazy loading does not guarantee zero performance impact.
  • If it does not work: Check the correct store key, installation path, audience rules, CSP and browser console. Confirm the saved designer version reaches a fresh storefront session.
  • Detailed guide: /docs/widget/designer

Content Studio

/content-studio · Growth tools (A/B, playbooks, loyalty, content) · Growth

Generates and stores merchant content drafts for review before supported publishing workflows.

  • Why and when: Generate editable email, SMS or push ideas from a factual brief before choosing a separate sending path.
  • Merchant workflow: Select the content type and source context, generate a draft, fact-check it, and edit before approval.
  • Verify: Confirm the final text and any external publish result; a generated draft is never publication proof.
  • Synthetic example: Draft a restock SMS, fact-check the product and link, and count the final encoding-aware segments including opt-out text.
  • Limits / when not to use: Growth drafting access differs from Pro sending-channel access. Sending as a broadcast regenerates recipient copy from the brief; it does not send the approved variant verbatim.
  • If it does not work: Check source context, generation availability and budget. Unicode or emoji can split SMS below 160 characters; inspect the provider's final segment count.
  • Detailed guide: /docs/content-studio

Product Reviews (redirect)

/product-reviews · Growth tools (A/B, playbooks, loyalty, content) · Growth

Legacy route kept only as a redirect: the ingested Yotpo, Judge.me, Stamped, and native review corpus is now the Product reviews tab of the Reviews hub; Loox and Okendo media are still handled separately as UGC.

  • Why and when: Inspect the ingested product-review evidence rather than conversation moderation.
  • Merchant workflow: Open /reviews and select Product reviews; rating and source query params on old links are forwarded to the tab unchanged.
  • Verify: Confirm the browser lands on /reviews?tab=products with the same filters applied; the shopper-facing review lookup still requires Growth.
  • Synthetic example: Open Product reviews, filter by source and rating, then compare a stable external review ID and product ID with the original source.
  • Limits / when not to use: Requires Growth tools role access and the reviews plan entitlement. Ingestion is insert-only; do not repost duplicate IDs to simulate updates.
  • If it does not work: Check product mapping, source, stable review ID and ingestion counts before assuming a missing review is a search defect.
  • Detailed guide: /docs/reviews

Review Queue (redirect)

/review-queue · Growth tools (A/B, playbooks, loyalty, content)

Legacy route kept only as a redirect: the conversation moderation queue and the PDP Q&A approval cards are now the Moderation queue tab of the Reviews hub, with the same CSAT, sentiment, confidence, and escalation filters.

  • Why and when: Choose AI feedback, Product reviews or Moderation queue according to whether you are assessing an answer, product evidence or flagged content.
  • Merchant workflow: Open /reviews and select Moderation queue; a filter query param on an old link is forwarded to the tab unchanged.
  • Verify: Confirm the browser lands on /reviews?tab=queue with the same filter chip active; a flag is still a signal, not an automatic fix.
  • Synthetic example: Open Reviews, choose Moderation queue, inspect a flagged conversation and its source before approving a PDP Q&A draft or correcting a policy.
  • Limits / when not to use: The three tabs have different capability and entitlement requirements. Review ingestion requires a supported adapter; a flag is not proof of a defect.
  • If it does not work: Check active tab, rating/source filters, ingestion adapter and role. Legacy review routes redirect with supported filters rather than exposing separate stores of reviews.
  • Detailed guide: /docs/review-queue

Rules & Voice

/rules · Growth tools (A/B, playbooks, loyalty, content)

Provides entry points and status for merchandising, objection, language, and policy controls.

  • Why and when: Make a narrow merchant-approved merchandising or objection-response decision explicit and testable.
  • Merchant workflow: Choose the rule type that owns the behavior and keep each rule narrow and testable.
  • Verify: Test matching and non-matching shopper prompts before enabling broadly.
  • Synthetic example: Create a factual response to a shipping-cost objection and test it with a matching request, a paraphrase and an unrelated refund question.
  • Limits / when not to use: Rules must not invent prices, policy exceptions or eligibility. A broad match or a boost can interact with relevance and other rules.
  • If it does not work: Inspect trigger scope, active state, rule ordering and product eligibility. Test one changed rule at a time and disable the recent rule if unrelated answers regress.
  • Detailed guide: /docs/rules

Rule effectiveness

/rules/effectiveness · Growth tools (A/B, playbooks, loyalty, content)

Reports eligible rule exposure and available outcome signals.

  • Why and when: Review available rule exposures and associated outcomes before deciding which rule deserves a controlled test.
  • Merchant workflow: Compare a stable period and inspect the underlying rule and sample conversations.
  • Verify: Treat observed outcomes as directional unless a controlled experiment supports causality.
  • Synthetic example: Inspect an objection rule's recent exposures, read representative conversations and compare the same period before changing its wording.
  • Limits / when not to use: Observed outcomes are not a randomized comparison. Exposure counts depend on rule matching and recorded events.
  • If it does not work: Verify the rule was active and matched eligible sessions. Check time range and source threads before concluding that a zero-outcome rule is ineffective.
  • Detailed guide: /docs/rules

Merchandising rules

/rules/merchandising · Growth tools (A/B, playbooks, loyalty, content)

Creates product boosts, buries, blocks, or pins under merchant control.

  • Why and when: Test a product pin or merchandising rule against a defined shopping intent.
  • Merchant workflow: Define the smallest matching audience or query and preview affected products.
  • Verify: Test match, near-match, and no-match queries plus out-of-stock behavior.
  • Synthetic example: Pin an eligible product for a matching query, then test an unrelated query and an out-of-stock variant before enabling broadly.
  • Limits / when not to use: A ranking change does not prove relevance, compatibility or sales lift.
  • If it does not work: Check trigger scope, active state, product eligibility and competing rules; test one change at a time.
  • Detailed guide: /docs/rules

Objection rules

/rules/objections · Growth tools (A/B, playbooks, loyalty, content)

Stores approved responses and escalation behavior for recurring shopper objections.

  • Why and when: Make a narrow merchant-approved merchandising or objection-response decision explicit and testable.
  • Merchant workflow: Write a grounded response with a clear trigger and human boundary.
  • Verify: Test paraphrases, unsupported requests, and escalation conditions.
  • Synthetic example: Create a factual response to a shipping-cost objection and test it with a matching request, a paraphrase and an unrelated refund question.
  • Limits / when not to use: Rules must not invent prices, policy exceptions or eligibility. A broad match or a boost can interact with relevance and other rules.
  • If it does not work: Inspect trigger scope, active state, rule ordering and product eligibility. Test one changed rule at a time and disable the recent rule if unrelated answers regress.
  • Detailed guide: /docs/rules

Settings, integrations, and store operations

Typical access: Settings, integrations, billing, or team capability as shown per route; profile and support are available to all store members

Settings

/settings · Store settings & security

Shows store health and links to store-specific behavior, brand, team, billing, security, and integration settings.

  • Why and when: Locate the owner of a configuration change and review store readiness without guessing which screen saves it.
  • Merchant workflow: Start with readiness warnings and open the specific settings owner for the change.
  • Verify: Return to the overview and confirm the warning or state changed after saving.
  • Synthetic example: Follow the AI Budget card to its owning page rather than changing Billing when provider spend needs a cap.
  • Limits / when not to use: Billing, team and API-key permissions are independently delegated; access to Settings does not grant every administrative action.
  • If it does not work: Check effective capability and route-specific plan gates when a card or action is absent. Ask an authorized store owner to review access rather than sharing credentials.
  • Detailed guide: /docs/settings

AI Setup

/settings/ai · Store settings & security

Configures supported agent behavior, model-facing controls, guided selling, handoff options, order actions, the attribution holdout, and the margin guard for AI discounts.

  • Why and when: Choose supported agent behaviors and consequential boundaries before a controlled storefront test.
  • Merchant workflow: Change one behavior at a time, save it, and test a realistic shopper scenario.
  • Verify: Verify normal, unsafe, low-confidence, and human-request cases.
  • Synthetic example: Keep money actions off, review address-change behavior separately, save the correct form and test a human request and an unverified order request.
  • Limits / when not to use: Cancel/edit/full-refund execution is Shopify-specific with identity, eligibility and confirmation checks; WooCommerce uses tickets. Holdout availability and effects differ by platform.
  • If it does not work: Confirm the appropriate Save button, saved toggle state and required tool/platform support. A permission switch does not override identity, eligibility or provider failure.
  • Detailed guide: /docs/settings/ai

AI Budget

/settings/ai-budget · Store settings & security

Shows model usage and configured budget or cost controls.

  • Why and when: Limit AI model spend and monitor the trade-off between cost control and assistant availability.
  • Merchant workflow: Review usage by capability and set limits consistent with expected traffic.
  • Verify: Confirm limit behavior in a controlled environment and monitor provider billing separately.
  • Synthetic example: Set Monthly cap (USD) and Warn at (% of cap), click Save cap, and monitor the status badge and capability usage using a controlled environment for cap behavior.
  • Limits / when not to use: Zero removes the merchant cap; a platform-set ceiling can still apply. The cap is separate from conversation allowance; in-flight calls can finish and estimated spend is not a provider invoice.
  • If it does not work: Check UTC calendar-month usage, permissions and the effective lower cap. If calls are unavailable below it, inspect provider availability rather than raising the cap blindly.
  • Detailed guide: /docs/settings/ai-budget

AI Shopping Feeds

/settings/agentic-feeds · Store settings & security · Pro

Publishes the active catalog as a Google Merchant Center RSS feed and an OpenAI product feed file for AI shopping surfaces, with build and fetch stats.

  • Why and when: Generate product feed files for a destination you are eligible and authorized to submit to.
  • Merchant workflow: Turn feeds on, add the Google URL to Merchant Center as a scheduled fetch, and use the OpenAI file as the source of your daily upload if OpenAI approved you.
  • Verify: Open each URL, confirm prices, stock and product links match the storefront, and check Merchant Center diagnostics after its first fetch.
  • Synthetic example: Enable feeds, open the generated Google URL, compare one variant's price and availability, submit through Merchant Center and inspect its diagnostics.
  • Limits / when not to use: Pro is required. File generation, submission, validation and destination approval are separate; listing, ranking and assistant citation are never guaranteed.
  • If it does not work: Check enablement, plan, source variant data and destination diagnostics. A successful fetch alone does not establish acceptance by an external shopping surface.
  • Detailed guide: /docs/settings/agentic-feeds

API Keys

/settings/api-keys · Integrations & webhooks · Pro

Creates and revokes store-scoped public API credentials.

  • Why and when: Authorize a custom integration with the minimum supported public API scope and a planned rotation path.
  • Merchant workflow: Create the minimum scope, copy the secret once, store it securely, and rotate or revoke when no longer needed.
  • Verify: Call one allowed and one disallowed endpoint, then verify revocation blocks the key.
  • Synthetic example: Create a read-only test key, confirm an allowed public read and a denied write, then revoke it and verify the former read is rejected.
  • Limits / when not to use: Pro is required. The key is store-scoped and shown once; it is separate from the widget key and custom identity-signing secret.
  • If it does not work: Check the exact API host/path, bearer header, scope, plan and revocation state. Never put a server key in browser code or a support screenshot.
  • Detailed guide: /docs/settings/api-keys

Billing settings

/settings/billing · Billing & plan

Shows plan, trial or subscription state, usage, packs, invoices, and supported billing actions.

  • Why and when: Review trial, plan, usage and the billing provider before an explicitly intended commercial change.
  • Merchant workflow: Confirm the store and commercial terms before changing a subscription or buying usage.
  • Verify: Verify provider confirmation, effective tier, next billing date, and invoice state.
  • Synthetic example: Read the 100-conversation total trial allowance, provider and renewal terms, then compare the workspace's effective plan with provider confirmation after an approved change.
  • Limits / when not to use: Shopify billing differs from Freemius checkout for eligible direct stores; legacy subscriptions can retain their provider. Calendar-month usage is separate from renewal date.
  • If it does not work: Check provider status, workspace identity, effective entitlement and billing history. Do not repeat a purchase whose outcome is uncertain; ask support with the safe transaction reference.
  • Detailed guide: /docs/billing

Brand Voice

/settings/brand-voice · Store settings & security

Configures tone, reading level, examples, forbidden language, and channel guidance.

  • Why and when: Make tone and wording expectations concrete without moving factual policies into style instructions.
  • Merchant workflow: Add concrete do and don't examples and keep legal or policy facts in authoritative knowledge.
  • Verify: Test the same intent across relevant channels and languages.
  • Synthetic example: Add a concise do/don't pair for apologizing about delays, save, and compare the same question across a web and supported messaging conversation.
  • Limits / when not to use: Brand voice changes expression; it must not override approved prices, safety boundaries or store policies.
  • If it does not work: Check the owning voice controls, save state and conflicting rules. Use the same grounded intent for before/after comparisons instead of unrelated prompts.
  • Detailed guide: /docs/settings/brand-voice

Canned Replies

/settings/canned · Store settings & security

Manages reusable, optionally localized shortcuts for human support replies.

  • Why and when: Help humans insert consistent editable replies for frequent, well-understood support tasks.
  • Merchant workflow: Create short approved replies for frequent support tasks and insert them from a real thread.
  • Verify: Confirm the correct locale and editability before sending.
  • Synthetic example: Create a shipping-status shortcut, insert it into a controlled thread, replace order-specific placeholders and verify the selected language before sending.
  • Limits / when not to use: A canned reply is not an automatically verified answer or a sent message. Static text can become stale when policies change.
  • If it does not work: Check shortcut spelling, locale and saved text. Read the inserted result before sending; do not assume an absent locale will select the intended translation.
  • Detailed guide: /docs/settings/canned-replies

Custom Tools

/settings/custom-tools · Store settings & security · Pro

Defines merchant HTTP tools the agent may call with server-side request validation and network safeguards.

  • Why and when: Let the agent call a narrowly scoped external business lookup that is not provided by built-in tools.
  • Merchant workflow: Use a narrowly scoped HTTPS endpoint, explicit schema, least-privilege credential, and safe timeout.
  • Verify: Test valid, invalid, timeout, authentication, private-network, and unexpected-response cases.
  • Synthetic example: Define a warranty lookup with a synthetic product identifier, a strict input schema and a shopper-safe response, then test success, invalid input and timeout.
  • Limits / when not to use: Pro and settings access apply. Network safeguards, endpoint credentials and the endpoint's own authorization remain necessary; a tool must not expose internal or unrestricted mutation APIs.
  • If it does not work: Check schema validation, public HTTPS reachability, authentication and timeout separately. Test non-secret failure responses and inspect safe logs before broad enablement.
  • Detailed guide: /docs/settings

Shipping zones

/settings/shipping · Store settings & security

Lists the delivery zones and rates the assistant may quote, marking which arrived from your platform and which you added by hand.

  • Why and when: Verify the zones, costs and timing the assistant may quote and add manual data for unsupported carriers.
  • Merchant workflow: Let Shopify or WooCommerce zones sync themselves and add manual zones only for carriers your platform does not expose; platform-synced zones must be edited in the store, not here.
  • Verify: Ask the assistant a delivery question for a country in the zone and confirm the quoted price and timing match your carrier's real rates.
  • Synthetic example: Compare a synced domestic zone with the store; add a manual carrier zone only when needed, then ask about one included and one excluded destination.
  • Limits / when not to use: Synced zones must be edited at the source platform. A shipping estimate is not a delivery guarantee or proof a checkout rate will match every cart.
  • If it does not work: Check origin, destination, currency, minimums and sync source. Remove conflicting manual assumptions rather than overwriting platform-owned rates.
  • Detailed guide: /docs/settings

Metafield access

/settings/metafields · Store settings & security

Controls which synced platform metafield namespaces and keys the AI is allowed to read when answering shoppers, and lists the namespaces found on your catalog.

  • Why and when: Expose only shopper-safe catalog metadata required for better product answers.
  • Merchant workflow: Start from the discovered list and allow only shopper-safe namespaces; narrow to specific keys whenever a namespace also carries cost, supplier, or internal values.
  • Verify: Ask the assistant a question that depends on an allowed field and confirm it answers, then confirm a non-allowlisted value never appears in a reply.
  • Synthetic example: Allow a public materials key while excluding a supplier-cost key in the same namespace; test a materials question and a request for the internal cost.
  • Limits / when not to use: Default deny protects non-allowlisted fields. Allowing an entire mixed namespace can expose internal information; prefer explicit safe keys.
  • If it does not work: Check discovered namespace/key names and the synced product values. Missing source metadata cannot be fixed by broadening the allowlist.
  • Detailed guide: /docs/settings

/settings/legal · Store settings & security

Surfaces store legal and compliance document configuration and downloads.

  • Why and when: Find legal document downloads and retention controls for review with the appropriate owner or counsel.
  • Merchant workflow: Review generated or provided documents with qualified counsel for the merchant's actual operations.
  • Verify: Confirm entity, regions, processors, retention, and contact details; templates are not legal advice.
  • Synthetic example: Download the DPA draft, compare parties and processing details with the actual agreement, and record questions for counsel before relying on it.
  • Limits / when not to use: A template, download or settings save is not a certification or an executed agreement. Retention changes can permanently remove eligible data.
  • If it does not work: Confirm entity, roles, contact details and affected data before a consequential change. Escalate legal ambiguity rather than improvising contractual commitments.
  • Detailed guide: /docs/settings/legal

Loyalty settings

/settings/loyalty · Store settings & security · Growth

Creates rewards, sets how each reward is delivered when redeemed (code pool, shared code, WooCommerce auto-generated coupon, or sent by your team), uploads code pools, and edits earn-rate tiers.

  • Why and when: Offer clear points rewards whose delivery method and checkout behavior your team can support.
  • Merchant workflow: Create the codes in your store first, then upload them as a pool or enter a shared code. On Shopify use a code pool or a shared code; automatic coupons are WooCommerce only.
  • Verify: Check the pool count after an upload, redeem once as a test shopper, and confirm the code applies at checkout.
  • Synthetic example: Create a modest test reward, upload a real test code pool, earn points with a controlled order, redeem once and confirm the code applies and points are deducted once.
  • Limits / when not to use: Growth is required. Shopify uses code pools or a shared code; automatic coupon generation is WooCommerce only. Manual fulfillment requires a staffed team.
  • If it does not work: Check active reward, points, code stock and delivery method. A deducted balance is not proof the coupon worked at checkout; inspect the redemption record before repeating.
  • Detailed guide: /docs/loyalty

Notification settings

/settings/notifications · Store settings & security

Configures supported merchant notification preferences.

  • Why and when: Choose the alerts and delivery paths a responsible teammate will actually monitor.
  • Merchant workflow: Enable only the events and delivery paths the responsible team will monitor.
  • Verify: Trigger a safe test event and confirm both in-app persistence and configured external delivery separately.
  • Synthetic example: Enable a relevant operational notification, trigger a safe test event and compare the persisted in-app alert with external delivery separately.
  • Limits / when not to use: Preferences do not resolve the underlying incident or guarantee email/provider delivery.
  • If it does not work: Check event enablement, destination, connector and suppression. Resolve the source fault before marking an alert as handled.
  • Detailed guide: /docs/notifications

Security settings

/settings/security · All store members

Shows store account-protection and credential controls.

  • Why and when: Review account protection and credential exposure after membership or integration changes.
  • Merchant workflow: Review membership, secrets, sessions, and connection credentials on a regular cadence.
  • Verify: Rotate a test credential or revoke a test member and verify access is removed.
  • Synthetic example: Revoke an unused test credential, verify the denied request and review the remaining least-privilege access.
  • Limits / when not to use: A security checklist is not a compliance certification or proof every connected provider is correctly configured.
  • If it does not work: Check whether the control is account-level, store-level or provider-owned. Use the relevant recovery procedure instead of sharing a teammate's account.
  • Detailed guide: /docs/security

SLA targets

/settings/sla · Store settings & security

Sets internal first-response and resolution targets that give each new support ticket a due time, counted in round-the-clock minutes.

  • Why and when: Set internal response and resolution targets that your team can staff around the clock.
  • Merchant workflow: Configure targets your team can staff, allowing for nights and weekends because the clock never pauses.
  • Verify: Create a controlled ticket and check its due times in the inbox Tickets view; these are not Zubby support guarantees.
  • Synthetic example: Set the documented target, create a controlled ticket and compare its due time with creation time in round-the-clock minutes.
  • Limits / when not to use: The clock does not pause for business hours. These are store ticket targets, not per-channel Zubby support guarantees.
  • If it does not work: Check saved minute values and ticket creation time. Historical tickets and missing staffing should not be mistaken for an automatic escalation or delivery guarantee.
  • Detailed guide: /docs/settings/sla

Help & Diagnostics

/settings/support · All store members

Reports live workspace health for the merchant team: team size, failed sync jobs, active campaigns, unread operator signals, widget flow coverage, and the recommended next support move.

  • Why and when: Investigate merchant workspace health and gather a minimal useful support report.
  • Merchant workflow: Start from the recommended move, open the owning workspace it links to, and escalate to Zubby with store ID, timestamp, route, request ID, and safe error text only when the workspace fix does not apply.
  • Verify: Confirm the source issue is resolved - the signal count drops on reload - not only that a support request was created. This is merchant self-help; shopper conversations live in the Inbox.
  • Synthetic example: Follow a failed-sync recommendation to Imports, record the job ID, route, timestamp and safe error, then contact support if the owning workflow cannot resolve it.
  • Limits / when not to use: Help & Diagnostics is merchant self-help. Shopper cases belong in Inbox, and creating a support request does not fix the source issue.
  • If it does not work: Recheck Store Details and Notifications after the correction. Include expected versus actual results without passwords, tokens or unnecessary shopper data.
  • Detailed guide: /docs/troubleshooting

Team settings

/settings/team · Team management

Invites, revokes, and assigns store membership roles and capability overrides.

  • Why and when: Give a teammate only the capabilities needed for their store responsibilities and remove access when it ends.
  • Merchant workflow: Grant the least privilege needed and review any explicit per-member overrides.
  • Verify: Sign in as a test member and verify allowed and denied routes and actions.
  • Synthetic example: Invite a support teammate, review capability overrides, then use that test account to confirm Inbox access and denied billing/team operations.
  • Limits / when not to use: Owners/admins have full capabilities; explicit overrides and role-assignment ceilings matter. A label alone does not describe effective access.
  • If it does not work: Check invitation state, intended email, store membership and overrides. Test the actor's effective permissions rather than repeatedly sending invitations.
  • Detailed guide: /docs/settings/team

Billing

/billing · Billing & plan

Provides the store billing workspace for plan, usage, packs, subscription, invoice, and provider state.

  • Why and when: Review trial, plan, usage and the billing provider before an explicitly intended commercial change.
  • Merchant workflow: Use it as the direct billing route; apply the same confirmation checks as Billing settings.
  • Verify: Verify the billing provider result and effective store entitlement.
  • Synthetic example: Read the 100-conversation total trial allowance, provider and renewal terms, then compare the workspace's effective plan with provider confirmation after an approved change.
  • Limits / when not to use: Shopify billing differs from Freemius checkout for eligible direct stores; legacy subscriptions can retain their provider. Calendar-month usage is separate from renewal date.
  • If it does not work: Check provider status, workspace identity, effective entitlement and billing history. Do not repeat a purchase whose outcome is uncertain; ask support with the safe transaction reference.
  • Detailed guide: /docs/billing

Integrations

/integrations · Integrations & webhooks

Lists store commerce, messaging, email, review, and other supported connectors with status.

  • Why and when: Connect a supported provider for one defined flow and verify the direction of data or messages it actually supports.
  • Merchant workflow: Open the required connector and review its exact credentials, permissions, webhook, and plan prerequisites.
  • Verify: Use provider-side evidence and a test event; a Connected badge alone is insufficient.
  • Synthetic example: Choose a connector-specific test: compare one synced WooCommerce product with its source; for a helpdesk inspect a controlled handoff; for messaging verify a permitted inbound question and reply; for analytics compare a supported emitted event. Do not apply the helpdesk test to every connector.
  • Limits / when not to use: Plan access, platform approval, permissions and production configuration vary by connector. Connected does not prove every advertised workflow works.
  • If it does not work: Separate authorization, inbound event reception, outbound sends and field mapping. Read the connector-specific guide and provider result before reconnecting or duplicating events.
  • Detailed guide: /docs/settings

Integration detail

/integrations/:connectorSlug · Integrations & webhooks · Varies; messaging channels require Pro, Zendesk and Gorgias require Growth

Configures one connector and shows provider-specific instructions and state; Zendesk and Gorgias also show the webhook URL and setup steps for two-way ticket sync.

  • Why and when: Connect a supported provider for one defined flow and verify the direction of data or messages it actually supports.
  • Merchant workflow: Follow the connector's displayed setup, store credentials securely, and complete its verification flow.
  • Verify: Test inbound and outbound behavior that applies to that connector and inspect provider logs.
  • Synthetic example: Choose a connector-specific test: compare one synced WooCommerce product with its source; for a helpdesk inspect a controlled handoff; for messaging verify a permitted inbound question and reply; for analytics compare a supported emitted event. Do not apply the helpdesk test to every connector.
  • Limits / when not to use: Plan access, platform approval, permissions and production configuration vary by connector. Connected does not prove every advertised workflow works.
  • If it does not work: Separate authorization, inbound event reception, outbound sends and field mapping. Read the connector-specific guide and provider result before reconnecting or duplicating events.
  • Detailed guide: /docs/settings

Commerce connector setup

/connect/:platform · All store members

Explains Shopify or WooCommerce connection steps and shows live store and sync state.

  • Why and when: Complete the managed platform connection and verify the first usable catalog and operational events.
  • Merchant workflow: For WooCommerce, complete plugin pairing and return to Imports and Store Details. Shopify references apply to existing authorized connections; new connections are coming soon.
  • Verify: Confirm sample catalog data, webhooks, sync completion, and storefront behavior.
  • Synthetic example: On WooCommerce, install and pair the plugin, confirm its reported API base URL, wait for sync, then compare a product and historical order with the store.
  • Limits / when not to use: New Shopify connections are coming soon; existing authorized stores may use supported sync paths and required scopes. WooCommerce requires its plugin and pairing. Custom stores use the Pro public ingestion API instead of these managed import routes.
  • If it does not work: Check authorization, plugin health or required scopes before re-running sync. A blocked connection and a failed embedding job have different owners.
  • Detailed guide: /docs/getting-started/first-store

Email integration

/integrations/email · Integrations & webhooks

Connects Microsoft 365, Google Workspace, or SMTP for supported merchant email sends.

  • Why and when: Connect an authorized sender for supported replies or campaigns and test actual delivery before enabling volume.
  • Merchant workflow: Authorize or configure the sending mailbox, then send a controlled message before enabling campaigns.
  • Verify: Confirm provider acceptance, inbox placement, sender identity, unsubscribe handling, and failure visibility.
  • Synthetic example: Authorize the intended mailbox, send a controlled message and verify sender, reply-to, unsubscribe behavior and provider acceptance.
  • Limits / when not to use: Provider acceptance is not inbox placement. A connected mailbox does not establish consent or permission for every recipient.
  • If it does not work: Check authorization, sender identity, DNS requirements where applicable and provider errors. Avoid resending when a send may already have been accepted.
  • Detailed guide: /docs/settings

Meta Page selection

/integrations/meta-connect · Integrations & webhooks · Pro multi-channel entitlement

Selects the Facebook Page whose Messenger, comments, and linked Instagram account should connect after Meta authorization.

  • Why and when: Choose the exact Facebook Page and associated Instagram account after provider authorization.
  • Merchant workflow: Choose the exact Page and review the linked Instagram account before connecting.
  • Verify: Send controlled messages and comments and confirm they arrive in the intended store inbox.
  • Synthetic example: Select an authorized test Page, verify the linked Instagram account and send one controlled question/comment to the intended destination.
  • Limits / when not to use: Pro entitlement and external approval/permissions are required. Selecting a similarly named Page can route messages to the wrong business.
  • If it does not work: Compare the provider account IDs and granted permissions with the selected Page. Stop and resolve mismatches before replying from the business account.
  • Detailed guide: /docs/social

WhatsApp Business signup

/integrations/whatsapp-signup · Integrations & webhooks · Pro multi-channel entitlement and Meta onboarding approval

Runs Meta's business-account and phone-number signup when onboarding is enabled for the workspace.

  • Why and when: Onboard an authorized WhatsApp Business account when the workspace's Meta signup flow is enabled.
  • Merchant workflow: Start from the WhatsApp connector, select your authorized business number in Meta, and finish every signup step.
  • Verify: Send a controlled shopper question and confirm the reply, product image and links arrive on the selected number.
  • Synthetic example: Choose the authorized business number in Meta's signup, finish verification, then test an inbound question and approved recovery-template behavior separately.
  • Limits / when not to use: Pro and provider onboarding approval apply. Session-window replies and pre-approved outbound templates follow different eligibility rules.
  • If it does not work: Check number/account selection, approval status, phone verification and template readiness. A completed local step is not proof Meta enabled production messaging.
  • Detailed guide: /docs/social

Outbound webhooks

/integrations/webhooks · Integrations & webhooks · Pro

Creates best-effort outbound subscriptions for supported events; generic JSON and automation destinations use signed payloads, while Slack has a destination-specific format.

  • Why and when: Deliver supported store events to a receiver that can authenticate, deduplicate and reconcile best-effort notifications.
  • Merchant workflow: Use HTTPS, follow the destination's signature contract on the raw body, durably accept quickly and process idempotently; design a reconciliation path for missed events.
  • Verify: Trigger a controlled event and inspect receiver logs, response, failure notification and endpoint state. There is a five-second timeout and no automatic delivery retry or missed-event replay.
  • Synthetic example: Subscribe a test receiver to lead.created, verify the raw-body signature, durably store the event ID and acknowledge quickly before asynchronous processing.
  • Limits / when not to use: Pro is required. Delivery has a five-second timeout and no automatic retry; alerts follow five consecutive failures and disabling follows twenty when failure tracking is available.
  • If it does not work: Inspect receiver logs, signature timestamp, response and endpoint active state. Reconcile missed records from the owning source; re-enabling does not replay missed events.
  • Detailed guide: /docs/webhooks

Team

/team · Team management

Provides a store-level shortcut to team membership management.

  • Why and when: Give a teammate only the capabilities needed for their store responsibilities and remove access when it ends.
  • Merchant workflow: Invite or manage members using the same least-privilege workflow as Team settings.
  • Verify: Verify the member's effective capabilities with a test session.
  • Synthetic example: Invite a support teammate, review capability overrides, then use that test account to confirm Inbox access and denied billing/team operations.
  • Limits / when not to use: Owners/admins have full capabilities; explicit overrides and role-assignment ceilings matter. A label alone does not describe effective access.
  • If it does not work: Check invitation state, intended email, store membership and overrides. Test the actor's effective permissions rather than repeatedly sending invitations.
  • Detailed guide: /docs/settings/team

Store Details

/store-details · Store settings & security

Shows read-only connection, usage, sync, and recent job health for the selected store.

  • Why and when: Establish connection, usage and job state before deciding whether a problem is data, indexing, widget or provider related.
  • Merchant workflow: Use it to establish current system state before troubleshooting.
  • Verify: Compare the latest completed status, counts, and timestamps with the source platform, Notifications, and a controlled storefront result.
  • Synthetic example: Record the last completed catalog sync and counts, compare a representative source product and then test the storefront query.
  • Limits / when not to use: Read-only status is diagnostic evidence, not a guarantee of source freshness or shopper-visible correctness.
  • If it does not work: Compare recent completed versus failed jobs, Notifications and source state. Provide a safe job ID and timestamp when escalating.
  • Detailed guide: /docs/store-details

Activity notifications (redirect)

/notifications · Store settings & security

Legacy route kept only as a redirect: the derived workspace activity feed, with its unread, failed-sync, and billing summaries and client-side filtering, is now the Workspace activity tab of the notifications inbox.

  • Why and when: Triage saved alerts and workspace activity with a clear owner for the underlying operation.
  • Merchant workflow: Open /notifications-inbox and select Workspace activity; the old route forwards there automatically.
  • Verify: Reload and confirm read state on the tab; resolve the source issue rather than only clearing the alert.
  • Synthetic example: Open Notifications, inspect an Alerts entry, follow its source link and verify the fix before marking it read; inspect Workspace activity for the related event.
  • Limits / when not to use: The tabs have separate read stores. Marking read acknowledges an item and does not repair a sync, billing or support problem.
  • If it does not work: Check active tab, filters and refreshed source state. A cleared alert count is not completion evidence for the underlying task.
  • Detailed guide: /docs/notifications

Notifications

/notifications-inbox · Store settings & security

The canonical notification surface the shell bell links to: an Alerts tab of persisted escalations, leads, sync issues, and billing events with per-item and mark-all-read actions, plus a Workspace activity tab carrying the derived audit, sync, revenue, knowledge, and handoff feed.

  • Why and when: Triage saved alerts and workspace activity with a clear owner for the underlying operation.
  • Merchant workflow: Open notification links in context, acknowledge only completed triage, and switch to Workspace activity for raw store events.
  • Verify: Reload to confirm read state and verify the underlying case, lead, sync, or billing issue separately; the two tabs use separate read stores.
  • Synthetic example: Open Notifications, inspect an Alerts entry, follow its source link and verify the fix before marking it read; inspect Workspace activity for the related event.
  • Limits / when not to use: The tabs have separate read stores. Marking read acknowledges an item and does not repair a sync, billing or support problem.
  • If it does not work: Check active tab, filters and refreshed source state. A cleared alert count is not completion evidence for the underlying task.
  • Detailed guide: /docs/notifications

Restricted audit records

/audit-log · Store settings & security

Detailed operational audit records and exports are restricted to authorized Zubby platform administrators; this route is unavailable to customer accounts.

  • Why and when: Use the guide to understand where merchant billing history ends and administrator investigation begins.
  • Merchant workflow: Use Settings → Billing for your plain-language billing history. Contact support with the store and time of a change that needs investigation.
  • Verify: Customer accounts must be denied access to detailed audit records and exports, even when they own the store; confirm relevant billing activity in Billing instead.
  • Synthetic example: For an unexplained plan change, review Settings → Billing and provide the store and approximate time to support if more detail is needed.
  • Limits / when not to use: Detailed audit records and exports are restricted to authorized platform administrators. Store ownership does not grant this route.
  • If it does not work: An access denial for a merchant is expected. Do not work around it with another person's account; use the billing history and support route.
  • Detailed guide: /docs/audit-log

Security

/security · Store settings & security

Summarizes store security posture and available account or credential controls.

  • Why and when: Review account protection and credential exposure after membership or integration changes.
  • Merchant workflow: Review findings, membership, keys, integrations, and recent sensitive actions.
  • Verify: Close findings with evidence and re-test access after every revocation or rotation.
  • Synthetic example: Revoke an unused test credential, verify the denied request and review the remaining least-privilege access.
  • Limits / when not to use: A security checklist is not a compliance certification or proof every connected provider is correctly configured.
  • If it does not work: Check whether the control is account-level, store-level or provider-owned. Use the relevant recovery procedure instead of sharing a teammate's account.
  • Detailed guide: /docs/security

Profile

/profile · All store members

Manages the signed-in user's account profile and personal preferences.

  • Why and when: Update the signed-in person's account details rather than a store-wide policy or team member's identity.
  • Merchant workflow: Update only the current user's information and save.
  • Verify: Reload and confirm the account-level change without assuming it changed store settings.
  • Synthetic example: Change a test user's profile name, save and reload; then confirm store contact and teammate profiles were not implicitly changed.
  • Limits / when not to use: Personal preferences and account protection can have a different scope from the selected store's settings.
  • If it does not work: Confirm the signed-in account and owning control. Use the documented account recovery flow if authentication prevents an update.
  • Detailed guide: /docs/settings

Store support (redirect)

/support · All store members

Legacy route kept only as a redirect: the merchant self-help and diagnostics view moved under Settings so its name no longer collides with the customer-support inbox.

  • Why and when: Investigate merchant workspace health and gather a minimal useful support report.
  • Merchant workflow: Open Settings then Help & Diagnostics; the old route forwards there automatically.
  • Verify: Confirm the browser lands on /settings/support for the same store before reporting the page as missing.
  • Synthetic example: Follow a failed-sync recommendation to Imports, record the job ID, route, timestamp and safe error, then contact support if the owning workflow cannot resolve it.
  • Limits / when not to use: Help & Diagnostics is merchant self-help. Shopper cases belong in Inbox, and creating a support request does not fix the source issue.
  • If it does not work: Recheck Store Details and Notifications after the correction. Include expected versus actual results without passwords, tokens or unnecessary shopper data.
  • Detailed guide: /docs/troubleshooting

Connector-specific verification examples

Use the matching provider test, after checking its displayed setup, plan and approval requirements. These are synthetic procedures, not completed external tests. Messaging requires Pro; Zendesk and Gorgias handoff require Growth. Provider charges and account approval are separate.

whatsapp
Use a permitted test number for an inbound question; test session replies separately from approved outbound templates and inspect the selected business number.
instagram
Send a controlled direct message to the connected Instagram account and inspect the intended inbox; provider permissions and approval still apply.
messenger
Send a controlled message to the exact connected Facebook Page and verify the reply on that Page, not a similarly named account.
twilio
Send one consented test SMS through a supported journey or recovery path; inspect provider acceptance, opt-out handling and actual receipt. This is not a universal inbound-chat test.
klaviyo
Trace one supported shopper event and identifier into the intended Klaviyo destination; list synchronization does not establish full Customer Agent parity.
slack
This connector redirects to Notification settings. Test an enabled notification on the intended workspace and channel; do not expect a helpdesk ticket or shopper reply sync.
ga4
Compare a supported conversion or recovery event and its identifiers with the configured GA4 destination; delivery does not guarantee matching attribution totals.
meta-capi
Trace a supported server-side conversion into the intended Meta destination and inspect provider diagnostics; attribution or deduplication needs its own check.
tiktok
Trace a supported purchase or lead event into the selected TikTok destination and inspect provider diagnostics; do not test this as a direct-message inbox.
hubspot
Compare a controlled supported shopper or transcript sync with the intended HubSpot record; inspect the implemented mapping instead of assuming every CRM field syncs.
zendesk
On Growth or above, inspect a controlled escalation ticket and transcript. Reply/status sync requires the configured webhook secret; without it, handoff is one-way.
gorgias
On Growth or above, inspect a controlled escalation ticket and transcript. Test the configured inbound webhook separately from outbound handoff; do not infer a provider subscription from Zubby entitlement.
intercom
Escalate a controlled contact with email, then inspect its Intercom conversation. Test missing-email and provider errors; human replies are not assumed to sync back.
mailchimp
Compare a consented test shopper email and supported tags with the intended Mailchimp audience, including suppression and duplicate handling.
segment
Compare one supported analytics event with the intended Segment source and downstream destination; do not treat event forwarding as a shopper-message channel.
recharge
Compare a supported subscription or lifecycle record with the source ReCharge record and inspect the configured sync direction.
loox
Availability is feature-flagged. If enabled, compare a supported ingested review with its source; do not claim every review or media adapter has the same ingestion path.
zapier
This connector redirects to Integrations, Webhooks. Use a supported controlled event, validate the destination payload, deduplicate accepted IDs and reconcile misses; outbound delivery has no automatic retry.

Capabilities that share a workspace

Some implemented features live inside another screen. This index maps every current paid capability to its guide and verification boundary. A plan unlocks the capability; role access, source data and provider setup still apply.

Capability / planScopeVerify
One-off broadcasts
Growth		Queue a brief-based campaign or explicitly launch a saved draft; SMS and WhatsApp also need Pro channel access.Check resolved audience, suppression and received examples; queueing is not approval of every generated recipient message.
Lifecycle journeys
Growth		Supported event triggers, audience scopes and channel steps; source-event availability varies by platform.Trace entry, delay, consent, purchase exits, provider result and pause behavior using controlled profiles.
Loyalty and rewards
Growth		Points, configured rewards, VIP standing and manual redemption tiers; referral execution is inactive.Test earning and one deduction, code delivery or fulfillment ticket, and actual checkout application separately.
Product review evidence
Growth		Supported review adapters supply product-review evidence; AI feedback and moderation are separate tabs.Compare an ingested review with its product and source; test an unsupported adapter or no-review case without invented evidence.
Content drafts
Growth		Editable email, SMS and push drafts; sending and channel eligibility are separate workflows.Review facts and encoding-aware SMS length; a broadcast handoff uses the brief to generate new recipient text.
Premium widget themes
Growth		Entitled designer presets and associated theme controls; core placement and styling remain distinct.Save and test the actual storefront in relevant modes, dates, audiences and screen sizes rather than relying on preview.
Proactive chat engagement
Growth		Behavior-triggered openings on the launcher, subject to enabled behavior and audience suppression.Test a matching event and an excluded or recently shown session; inspect the opener and approved offer limits.
Conversational storefront search
Growth		Supported storefront-search integration uses the store-scoped catalog; installation and theme compatibility vary.Test a real storefront search, no-match and out-of-stock cases, and confirm fallback navigation remains usable.
Product-Finder Quizzes
Growth		Published quiz questions map answers to catalog filters and recorded shopper traits.Take every answer path including no-match, then compare result products, recorded completion and intended downstream scope.
Product-page Q&A
Growth		Reviewed product questions and answers served through supported storefront surfaces; draft generation is not publication.Compare each answer with its source, approve only grounded copy and inspect the actual product-page rendering. Markup does not promise Google rich results.
Attributed gross profit
Growth		Cost coverage and AI-attributed gross-profit reporting from available order and product costs.Reconcile one order's line costs, quantity, discounts and refunds; missing cost coverage limits the conclusion.
Conversation Insights
Growth		Weekly AI-grouped questions, objections and product gaps, with sample conversations and minimum-data/budget conditions.Open source threads for a theme and check period, refresh state and distinct-conversation counts before acting.
Margin-aware ranking and category floors
Growth		Opt-in profit/stock ranking signals and category discount floors depend on known source costs and configured controls.Compare known-cost and missing-cost products, query relevance and allowed discounts; a score multiplier is not an exposure probability.
Zendesk and Gorgias handoff
Growth		Configured external helpdesk handoff and supported reply synchronization with provider permissions.Trace a controlled ticket, transcript and reply on both sides, including an authentication or failed-send case.
Cart and browse recovery emails
Growth		AI-written recovery emails for abandoned carts and browsing sessions, sent through the connected mailbox with unsubscribe handling.Trigger a controlled abandoned cart, confirm the send, the unsubscribe link and the skipped state on a Free store.
AI order actions
Growth		Per-store opt-in cancel, refund and modify tools plus address change, gated on verified identity, confirmation and unfulfilled status.Run each enabled action on a controlled unshipped order, then confirm a Free store hands the same request to a human ticket.
Messaging channels
Pro		Configured WhatsApp, Instagram, Messenger and SMS flows depend on provider approval, credentials, consent and current availability.Check the intended account/number, controlled inbound message, outbound reply and window/template/opt-out behavior for each enabled channel.
Forecast and risk signals
Pro		Inventory, churn and return-related signals use the data available to the store; these are decision aids.Inspect source history, coverage and the owning panel's assumptions. Do not present a prediction as an observed event or guaranteed outcome.
Public REST API and read-only MCP
Pro		Scoped catalog/order ingestion and documented read endpoints; MCP exposes only supported public-data tools and never places orders.Check allowed and denied scopes, tenant isolation, current OpenAPI contracts and plan/enablement behavior; general historical reports reads are not implied.
Outbound event notifications
Pro		Supported event notifications use destination-specific formats, a five-second timeout and best-effort delivery without automatic retries.Verify signatures where supplied, deduplicate accepted IDs, inspect receiver failures and document reconciliation for missed events.
Custom HTTP tools
Pro		Merchant-defined HTTPS tools with explicit schemas, server-held credentials and network safeguards.Test valid/invalid input, authorization, public reachability, timeout and unsafe responses before use with shopper data.
Contribution profit and lifetime contribution
Pro		Available fee and shipping data extends cost reporting; holdout comparisons and realized lifetime contribution have distinct assumptions.Reconcile quantities, product costs, fees, shipping and refunds; disclose missing coverage and do not equate attributed contribution with causal lift.
AI Shopping Feeds
Pro		Generated product feed files require merchant submission and destination-specific eligibility and approval.Validate variant facts and URLs, then inspect destination diagnostics. File generation does not guarantee listing, ranking or citation.
White-label configuration
Enterprise		Entitled brand overrides and removal of supported Zubby branding are distinct from provider billing and account tenancy.Test saved branding on each intended storefront and verify plan and store scope. SSO is roadmap and must not be inferred from white-label access.

Coverage and verification boundaries

Every current merchant page has a catalog entry, usage guidance, a synthetic example, limitations, troubleshooting, a verification check, a valid guide and a section tutorial. Route coverage includes redirects and restricted or inactive screens; it does not mean every route is an independently available feature. Source-backed behavior still requires environment-specific checks for credentials, provider delivery, platform approval, merchant data, legal review and production traffic.

Missing something, or found an error on this page?

Contact support and include the URL of this page (/docs/merchant-features).