When to use support
Use the support lane when one of these is true:
A storefront cannot complete onboarding cleanly, a plugin handoff looks pending or conflicted, a scan result seems questionable, or your team needs help deciding whether an issue is real proof, noise, or rollout risk.
Fastest self-serve recovery surfaces
Before opening a human support conversation, check these first:
`Scans` for runtime and plugin alerts, `Settings` for connected storefront posture, `Website detail` for storefront continuity, and `Reports` when the question is really about proof packaging rather than scan execution.
Plugin continuity help
Shopify and WooCommerce handoffs are now supported as real MVP lanes, but support should still treat reconnect, conflict, and pending continuity as rollout-sensitive states. If a storefront looks uninstalled, disconnected, pending, or owned by the wrong workspace, route the team through the plugin connect lane and workspace connection review before treating it as a scan bug.
What to include in a support request
The most helpful requests include the storefront domain, workspace name, whether the issue came from manual onboarding or plugin flow, what page or scan was being viewed, and whether the problem looks like runtime failure, continuity mismatch, or proof disagreement.
Beta response expectations
During controlled beta, support is intentionally human and high-context. Expect guided resolution, not anonymous ticket deflection. That is a feature of the current rollout posture, not a missing piece of the product.
Next step if you are deciding whether to start
If your team is still evaluating PixelClear, the best route is to review pricing posture, then enter the app through sign-up or sign-in and test the first storefront path deliberately.