Routing & Orchestration

When scheduling from a Handoff Router in ChiliCal with multiple assignees, it would be helpful to manage the assignees directly from the scheduler before booking. Ideally, the booker would be able to: Keep an assignee as required Change an assignee to optional Remove an assignee from the meeting entirely This would help support joint-call scheduling scenarios where the router suggests multiple assignees, but the booker may need flexibility depending on availability or business context. For example, if a meeting is intended to include both an OM and AM, but the AM is unavailable or not needed for that specific call, the booker could remove the AM or make them optional without needing a separate meeting type/router path. This would reduce double-booking issues, prevent unnecessary calendar invites, and give teams more flexibility while still using the Handoff Router/ChiliCal scheduling experience.

The ability to define whether routing actions execute simultaneously (parallel) or in a specific order (sequential), with the flexibility to mix both approaches within the same workflow. Currently, workflows either force everything to run in strict order (slowing down processing when actions don't depend on each other) or run everything at once (causing errors when one action needs data from a previous step). This creates a tradeoff between speed and reliability. For example: when routing a hot inbound lead, the system needs to (1) assign it to the right owner, (2) create a follow-up task, (3) send a Slack notification, and (4) update the lead score. The assignment must complete first because the task needs to be assigned to that same owner (sequential), but the task creation, notification, and score update don't depend on each other and could run at the same time (parallel). Currently, there's no way to set this up, so everything runs sequentially even when it doesn't need to. Parallel paths would allow multiple independent actions to execute simultaneously for faster processing, while sequential paths would enforce specific execution order when actions have dependencies. Being able to combine both in one workflow would optimize for both speed and logical dependencies.

The ability to capture and store data at any point in a routing workflow, then reference those stored values later in the same flow without having to repeat lookups or calculations. Currently, if the same piece of information needs to be used multiple times in a workflow (like account owner, opportunity status, or a calculated score), the same lookup or calculation has to be performed over and over. This slows down processing, creates redundancy, and increases the chance of errors if lookups return different results at different points. Workflow-level variables would allow storing a value once (from a lookup, field value, or calculation) and then referencing it multiple times downstream for routing decisions, field updates, or conditional logic. This would make workflows more efficient, easier to maintain, and reduce processing time for complex routing scenarios.

The customer desires enhanced deduplication capabilities, allowing for more granular control over which fields are merged or retained, akin to the functionality provided by LeanData.

When double round robin is used in Chili Piper, the second participant pool is selected as a flat group with no conditional logic applied. Teams running paired AE/SE selling motions need the second slot to resolve dynamically based on deal attributes evaluated after the first slot (AE) is already matched. For example: route to the appropriate AE queue first, then evaluate device count and third-party product flags to determine which SE pool to draw from, or whether to include an SE at all. The requested behavior is a second assignment node that evaluates its own set of conditions independently after the first assignment resolves, selecting the appropriate pool (or no one) based on those conditions. Without this, admins have to duplicate routing rules for every AE segment times every SE scenario, which scales badly and creates maintenance overhead. This is specifically a gap from the AE's perspective as well: even when SE inclusion is objectively appropriate by deal size, the AE may decide not to bring one on the first call. So the feature also needs to support making the second-slot assignment optional or overridable by the assigned AE.

After an opportunity is created, Distro has no way to set the opportunity closed date using a relative date formula (e.g., today + 30 days). Customers are currently relying on tools like RingLead to handle this step after opportunity creation. Distro should support a field update action on opportunity records that can write a relative date value to the closed date field, using an offset from today or the meeting date. This is a blocker for teams trying to consolidate RingLead workflows into Chili Piper. Without it, opportunity hygiene steps that should happen at routing time have to live in a separate tool, which adds cost and operational complexity.

When creating a record in Chili-Cal it would be beneficial to have options to have more fields than just email, first name, last name.

I noticed we have spam checker filtering for Concierge; I would love to see this ability on Distro too!!!

We currently use Distro to distribute Closed Opportunities to our CX onboarding team at Close Date. However, onboarding workload is actually driven by Contract Start Date, not Close Date. Because these dates often do not align, distribution timing does not match when work begins. This creates uneven workload at the start of each month, where some CX team members are overloaded and others are light depending on when their distributed deals actually start. We would like the ability to distribute based on Contract Start Date, or another custom date field, rather than being tied only to Close Date. Aligning distribution fairness with the actual start of onboarding would help us balance capacity more effectively and reduce beginning of month volume spikes.

Concierge: offer multi round-robin assignment for users who don't schedule a meeting. This can automate the assignment to users on separate teams (ie: AM & CSM).