GenerateSaaSSupport chat
Render a live-chat widget via Crisp, gated by config.support and aware of the logged-in user.
config.support (in @repo/config) mounts a client-side live-chat widget. The only wired provider is Crisp via config.support.crisp.websiteId, a value you add - until you set it, no widget loads.
Configuration
| Key | Type | Default | Description |
|---|---|---|---|
support.crisp.websiteId | string | unset | Crisp Website ID from the Crisp dashboard. Presence of crisp enables the widget; it is the only provider switch. |
support.enableInDev | boolean | false | Load the widget during local development. When unset it falls back to false, so the widget would not load in dev. |
A configured SupportConfig:
support: {
enableInDev: true,
crisp: {
websiteId: "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
},
},Behavior behind the flag
| Scenario | Result |
|---|---|
| Configured | Bubble renders once crisp.websiteId is set. |
| Off | Remove the crisp sub-key (or unset config.support) to hide it entirely. |
| Dev | Loads when enableInDev is truthy; set it false to suppress it during development. |
| Logged-in user | Identified to Crisp on session change - email and name only, no user-id tag - so agents see who they are chatting with. Re-identified when the user changes. |
Consent
Crisp drops cookies, so under cookieBanner: "auto" its presence surfaces the consent banner. The widget itself is not blocked behind consent - it loads as soon as it is configured. See cookie consent for how "auto" decides when the banner appears.
Frequently asked questions
Which providers are supported besides Crisp?
Only Crisp is wired. config.support exposes a single crisp sub-key - there is no other provider option.
Does the chat wait for cookie consent like analytics do?
No. Crisp surfaces the banner under "auto", but the widget loads immediately once websiteId is set - it is not gated on the visitor's choice.
Is the user's chat history preserved across sessions?
Crisp ties conversations to the pushed email, so a returning logged-in user resumes the same thread once identified - no user-id tag is set.