Feature Requests

The chat can share a clickable link, but it can't natively redirect or navigate the visitor's page from within the conversation. Teams that want the bot to move a visitor straight into a self-serve flow (start a trial, sign up, purchase) have to rely on the visitor clicking a link. Let the chat trigger an in-page redirect to a specified URL as a journey action, so the bot can push a qualified visitor directly into a trial/sign-up flow.

The chat widget is the primary way Chili Piper surfaces buyer-facing interactions, but there's no support for proactive pop-ups, ribbon banners, or offer overlays. Teams that want to serve contextual CTAs or announcements to site visitors without requiring them to open the chat have no native way to do it. Requested behavior: Support configurable pop-up and ribbon-style offer placements on the website that can be triggered by visitor behavior, page context, or intent signals, independently of the chat widget. Why it matters: Not every visitor interaction starts with a chat. Pop-ups and banners allow teams to proactively surface relevant offers or CTAs at key moments in the browsing experience, expanding conversion opportunities beyond the chat entry point.

The Chat widget only supports a pop-up display. There's no option to present the chat experience as a slide-out panel from the side of the page, which some teams prefer as a less disruptive format that doesn't fully take over the screen. Admins should be able to choose between a pop-up and a slide-out panel as the display style for the Chat widget.

Give teams full control over how the Chat widget and its entry point look and where they sit. Today, customization is limited: teams can't fully control the launcher button (the chat bubble/icon), the widget's shape and size, its position on the page, colors, or the opening animation, and can't A/B test different configurations to see what drives engagement. Requested control includes: launcher button style, icon, size, shape, and color; widget position on the page (e.g. left vs. right, offset); popup/expanded widget appearance; colors and theming to match brand; opening animation; and the ability to test different entry-point designs against each other. A widget that doesn't match the site's visual language looks bolted-on and reduces engagement. Full styling control lets design teams ship a cohesive, on-brand experience and optimize which entry-point designs convert best.

When a visitor closes or minimizes the chat widget, it reopens automatically as they navigate to the next page. Visitors who have deliberately dismissed the chat are repeatedly interrupted by it reappearing. Requested behavior: Persist the minimized or closed state of the chat widget across page navigation during the same session, so that once a visitor dismisses it, it stays dismissed until they choose to re-open it. Why it matters: Repeatedly showing a chat a visitor has already closed is disruptive and degrades the browsing experience. Respecting the visitor's dismissal improves the overall site experience and reduces the chance of the chat being seen as intrusive.

Chili Piper's buyer-facing experiences are delivered as floating or pop-up elements with fixed placement - the scheduling calendar renders as a pop-up/modal, and the chat widget is locked to the bottom-right corner as a floating element. Teams whose design systems don't accommodate pop-ups, or who want booking and chat to feel like a native part of their page, have no way to embed or reposition these experiences. Requested behavior: give admins native control over how and where these experiences render: Scheduling calendar - inline embed: render the calendar directly within the page DOM as an inline element that can be placed and styled as part of the page layout, without triggering a pop-up or modal. Chat widget - inline iframe embed: embed the chat widget inline within a designated section of a page via an iframe, rather than only as a floating widget. Chat widget - configurable position: let admins set the widget's position on the page (including embedding it into the page wireframe) instead of being limited to the default bottom-right corner. Why it matters: Pop-up blockers, accessibility constraints, CMS/iframe architectures, and design-system requirements all push teams toward inline, natively placed experiences. Giving design teams full control over placement removes a real adoption barrier and makes booking and chat feel like part of the site rather than a bolted-on third-party widget.

The chat widget collects information through its own question flow, but there's no way to embed an existing external form, such as a HubSpot form, directly within the chat interface. Teams that have already built and optimized forms externally have to choose between their existing form and the chat widget rather than combining them. Requested behavior: Allow an external form to be embedded inside the chat widget at any point in the conversation flow, so visitors can complete a familiar form experience without leaving the chat. Why it matters: Many teams have existing forms already wired into their CRM and marketing automation. Embedding them inside the chat removes the need to rebuild that logic in Chili Piper and lets teams use the chat as a delivery mechanism for forms they've already invested in.

The chat widget auto-opens on every page visit by default. Teams that want to show the chat proactively on first visit but not on every return have no way to limit how often or under what conditions the widget opens automatically. Requested behavior: Allow admins to configure the conditions under which the chat widget auto-opens, including limiting it to a visitor's first session, specific pages, or specific visit counts, rather than always appearing on every page load. Why it matters: Auto-opening the chat on every return visit feels intrusive and degrades the site experience for returning visitors. Frequency controls let teams be deliberate about when they interrupt browsing with a chat prompt.

Chat's JS API now exposes host-facing event callbacks (onSuccess, onError, onTriggered, and a catch-all eventsHandler) plus a data-captured event — but the event payloads are incomplete for teams building custom tracking. Today data-captured returns only the current form block's values, hidden fields aren't included, and there's no access to conversation-level data or which journey path was taken. Requested behavior — extend the payloads to expose: Hidden fields – hidden journey fields (e.g. lead campaign, lead source) are set in the journey but absent from the data-captured payload. All submitted values aggregated – return the full set collected across every step in one payload, not per-block. Journey strategy / path chosen – surface which path the visitor took (only playbookId is exposed today, on widget open). Conversation data – access to conversation-level data / transcript, including AI chat messages. Why it matters: hidden fields carry attribution data, and teams A/B testing or measuring Chat need the full picture client-side.