Sites and chat behavior
Site management
A Site is Stand’s installation and routing boundary for one named website context. It owns the stable embed snippet, normalized domain, enablement, Site instructions, fallback language, behavior rules, coverage diagnostics, and usage scope.
- Availability
- All plans
- Configured in
- Dashboard → Sites
- Category
- Sites and chat behavior
- Reference status
- Current
Before you begin
Plan availability: All plans; plan allowances can affect related knowledge and usage rather than the number of Site records.
Prerequisite: Any active member can add a Site; owner access is required to rename, configure, disable, or remove it.
Key boundary: A Site record alone does not make chat available. The snippet must be installed on a matching domain, the Site enabled, a responder eligible, and organization chat capacity available.
Add and identify a Site
- Open Sites, enter the website domain or URL, give the Site a customer-readable name, and add it to the organization.
- Stand normalizes the domain by removing protocol, path, and a leading
www.for matching. - Distinct Site names allow more than one Site entry to use the same normalized domain when the organization needs separate contexts or experiments.
- The created Site receives its own stable
data-stand-idand installation snippet; another Site’s identifier is not interchangeable.
Site-level controls
| Control | Effect |
|---|---|
| Enabled | Allows the Site to participate in public matching. Disabling removes its normal visitor availability without deleting configuration. |
| I chat here | Lets the current member personally receive human chats for the Site; each rep controls their own coverage. |
| Install snippet and status | Shows the Site-specific script and whether Stand has received a valid matching availability request. A custom API client can also produce that installation observation. |
| Site instructions | Adds owner-managed website context between Team and Stand-in instructions. |
| Chat language | Sets the fallback starting language used only when visitor and page signals are insufficient. |
| Chat widget behavior | Controls declarative path rules, reveal triggers, greetings, opening, and display modes. |
| Chat widget status | Shows Site-level responders and their probability split. It does not evaluate a particular visitor path; test that page separately. |
Member and owner permissions
- Any active member can add a Site and set their own I chat here coverage.
- Organization owners can rename, enable, disable, configure, and remove Sites and edit Site instructions and behavior.
- A non-owner can inspect shared Site context and their own coverage but cannot silently change organization-wide behavior.
- Removing or disabling a member affects that person’s human and Stand-in eligibility without deleting the Site itself.
Disabled, removed, and unmatched behavior
- A disabled Site is excluded from normal visitor matching even if its script remains present on the page.
- An unmatched domain cannot borrow responders from a different Site record merely because the script loaded.
- Conversation creation rechecks the Site identifier, matched domain, installed state, and current responder binding; a stale or copied identifier does not create a chat on another Site.
- Removing a Site is distinct from removing its script from the website and requires confirmation because it eliminates the organization configuration boundary.
- Existing completed conversations remain governed by History and retention rather than being rewritten by a later Site rename or removal.
Availability and boundaries
- Unlimited Sites are included in the current public plan presentation.
- Every Site needs its own stable snippet and matching published domain.
- Site name distinguishes records for customers; domain normalization determines the website match.
- Site configuration does not replace Stand-in specialization, rep I chat here coverage, or organization quota checks.