Feature Requests

Chilipiper is limited in what we're able to customize in web experiences currently. Given this is a major part of the higher chilipiper tier the expectations of customers/prospects is more flexibility. More visual customizations for web experiences (sizing, png/jpg, animations, audio in chat, chat icon).

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 buyer-facing AI experience renders as a small floating widget in the bottom-right corner, which reads to visitors as a traditional website chatbot. Customers who want the AI to feel like a live, capable assistant say the current form factor works against that before a single message is exchanged. Requested behavior, two parts that go together: Footprint: let the AI conversation render as a large, prominent surface, a full-height panel or a takeover of a meaningful portion of the page, rather than being limited to a small corner bubble. Admins should be able to choose the footprint per experience so they can decide how prominent the conversation is on a given page. Interface quality: the conversation surface itself should look and behave like a modern LLM assistant, visually polished and conversational, rather than a scripted bot UI. This is about the rendered experience, not the underlying model. Why it matters: the form factor sets the visitor's expectation. A corner bubble signals "canned bot, expect a deflection," so visitors either ignore it or engage shallowly. A prominent, well-designed conversational surface signals a real interaction and invites the kind of exchange the AI is actually capable of. Customers evaluating the AI experience raise this as a question about whether it will feel credible on their site, so it affects adoption of the AI agent itself, not just its styling.

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.