Feature Requests

Chili Piper only supports one-off meeting bookings, which means any team managing ongoing cadences, QBRs, weekly check-ins, or bi-weekly enablement sessions has to schedule those meetings outside the product entirely. This forces reps to use manual calendar invites, breaks data capture and reporting, and actively undermines adoption since reps can only route some of their meetings through Chili Piper.Allow users to create a recurring meeting series from a single booking, with configurable frequency (weekly, bi-weekly, monthly, quarterly) and an end date or occurrence count. Rescheduling individual instances should work the same way it does today for one-off meetings.

An enhancement to the LinkedIn integration to support additional data fields such as company size and state from LinkedIn Lead Gen Ads, which are currently not supported.

When a HubSpot contact has more than one deal, Chili Piper pulls the most-recently-updated deal into the meeting and only excludes closed deals by matching the stage name against the standard closedwon/closedlost values. Tenants using custom deal-stage names bypass that filter, so a recently-updated closed/lost deal can be selected over the open one, putting the wrong deal's data on the meeting and on any downstream automation keyed off the deal. Requested: recognise a deal's open/won/lost status independent of the stage label, and let admins control which deal-stage conditions determine which deal is selected, for standard and custom stage names alike.

Forms support translating a field's label into different languages, but not the picklist option values themselves. A dropdown's question can be localized while its selectable choices stay in the original language, which breaks the experience for international audiences. The only workaround today is CSS, which is fragile and unstable. Support per-language translations for picklist option values, so both the field label and its options render in the visitor's language. International teams need fully localized forms. Half-translated dropdowns (localized label, original-language options) look broken and force teams into brittle CSS hacks.

The current activation process for a brand new account requires the end user to log in with either Google or Outlook. In our company (and many others) we do not allow social sign in's to Microsoft for security reasons. With that our only option to activate our account is to sign in with Google. The initial sign in configures the entire account for Google integration and removes all references to Outlook. This process is not documented anywhere on your knowledge base nor is the process to resolve. This feature suggestion to enable a username and password sign up / activation and or the option of selecting which integration you'd like to use during initial setup.

Today, when multiple Handoff rules match a lead/booker, all matching rules are shown and the booker can select whichever one they want, with the top-most match set as the default selection. This differs from Concierge, and it's not the behavior most customers expect. Customers frequently build Handoff rules in a deliberate hierarchy/priority order (e.g., partner path before generic path), and assume — because that's how Concierge behaves, and because they've ordered their rules — that only the first matching rule will apply. In practice, all matches surface, and it's on the booker to pick correctly. This creates risk: e.g., a partner-owned account could get routed by the wrong rep if the booker doesn't select the right match, or if no disqualifiers were added to lower rules. Ask: Add a router-level setting (e.g., a checkbox in Handoff admin/router settings) — "If multiple rules match, only show the top-most matching rule" — so Handoff can optionally behave like a waterfall/Concierge-style priority match instead of surfacing every match. Why it matters: Reduces onboarding friction (no longer need to coach every customer on disqualifiers/rule ordering nuances) and reduces mis-routing risk on accounts with sensitive ownership rules (e.g., partner accounts).

Chat only pushes data to Marketo at fixed endpoints, primarily lead creation and booking. There's no way to capture how far a visitor progressed through a conversation, so a prospect who engaged with the AI, answered qualification questions, but didn't book looks identical in Marketo to one who never opened the widget. Requested behavior: Update a mapped Marketo field (e.g. an "AI engagement status" field) progressively as the conversation advances, at milestones like conversation started, actively engaged, qualification answered, booking initiated, meeting booked, or conversation abandoned. The status should reflect the furthest stage reached so Marketo always holds the current engagement state, not just the final outcome. Why it matters: Marketing teams score, segment, and trigger nurture programs off Marketo fields. When engagement data only lands at booking, everyone who engaged but didn't convert is invisible to those programs, which is exactly the audience mid-funnel nurture exists for. Progressive status updates let teams re-engage warm visitors, adjust lead scores based on real conversation depth, and measure where conversations stall.

Calendar buffers are calculated in calendar days, not business days. A buffer set to prevent Monday morning meetings isn't respected when a booking happens on a Friday or Saturday. Admins should be able to configure buffers that respect business days, so that scheduling constraints like minimum lead time are calculated based on working days rather than calendar days. Calendar-day buffers produce unexpected results for teams that only operate Monday through Friday. Business-day buffers ensure scheduling rules behave as intended without manual workarounds.

When a visitor submits a third-party form, any field that isn't mapped in the router's Trigger is silently dropped – the Concierge log shows only the mapped fields. Admins have no way to see what data actually arrived in the payload, which makes "why isn't this field being captured?" the hardest class of ticket to debug. The only workaround is inspecting the page's HTML source to discover field names. Concierge logs should show every field in the submission payload and label each one: mapped (to its Data Field) or Not mapped. Both the pre-submission and post-submission log views should be consistent. Field mapping is behind the large majority of Concierge capture issues. Proactively showing the unmapped fields turns a support-ticket-and-guesswork investigation into self-serve diagnosis.

It's coming up more and more with data providers being commoditized - customers have many sources of data that have slightly different values based on the provider. Customer doesn't want to have to map out all the possibilities of what they can be. AI could quickly and easily interpret any of the follow (hospital, company, clinic, eye care, +100's of others) to healthcare.