The lead waits while a human decides who owns it
A demo request arrives, then sits in a queue until someone triages it. By the time a rep reaches out, the buyer has moved on to whoever answered first.
Salesforce & HubSpot · Inbound Routing
Chili Piper is only as good as the routing model underneath it.
The booking widget is the easy part. What decides whether an inbound lead reaches the right rep is the ownership model, the lead-to-account match, the territory logic and the round-robin rules living in your CRM. Twopir Consulting implements Chili Piper, configures that routing against how your team is actually structured, and builds the custom work standard configuration cannot reach. Route, book, hand off and report on one model.
12+
500+
250+
15+
Trusted by 500+ organizations — revenue teams running their inbound motion on Salesforce and HubSpot with Twopir Consulting.
.png){kind=small}
-3.png){kind=small}
Built for Inbound Revenue Operations
- Salesforce Partner
- HubSpot Partner
- Chili Piper Implementation
- Lead Routing Architecture
- Lead-to-Account Matching
- Custom Development
- Marketing Operations
- Managed Support
Where inbound routing breaks down
Almost none of these are scheduling problems. They are ownership, matching and data problems that only become visible at the moment someone tries to book a meeting. The booking widget is where the symptom shows, not where the fault is.
Lead-to-account matching is wrong or missing
An inbound contact from an existing customer or open opportunity gets treated as net-new and routed to the wrong rep. Nothing downstream can recover from that first mistake.
Round-robin distributes volume, not fairness
Straight rotation ignores capacity, territory, language, segment and who is actually on shift — so a few reps carry the queue while others sit idle and the split looks fine on paper.
Meetings get booked and then quietly lost
No-shows, reschedules and cancellations happen outside the CRM, so pipeline reporting counts a meeting that never took place and nobody owns the follow-up.
The SDR-to-AE handoff loses the context
A qualified conversation is passed on as a calendar invite and a name. The AE reopens discovery from zero, and the buyer repeats themselves in the meeting they were promised would be different.
Nobody can prove where the routing went wrong
Without routing decisions written back to the CRM, "why did this lead go to that rep" is unanswerable — so the rules never get corrected and the same leak repeats every quarter.
What It Is
What Chili Piper is, and who it's actually for
Chili Piper is inbound revenue software that qualifies, routes and books inbound leads in real time. When someone submits a form, it checks them against the records already in your CRM, applies your routing rules to decide who should own the conversation, and puts a meeting on that person's calendar before the visitor leaves the page. It is made by Chili Piper, Inc. and integrates natively with both Salesforce and HubSpot.
It is built for teams with a real inbound motion — demo requests, contact-sales forms, content downloads and event follow-up arriving faster than a person can triage them, into a sales team with more than one owner. That profile is most common in SaaS and technology companies, though it applies to any business whose pipeline starts on a form. If a single rep handles every inbound lead, this is not a problem worth solving with software. The value starts at the point where "who gets this one" stops having an obvious answer.
What the product does not do is decide your rules for you. Chili Piper executes the routing logic it is given; the quality of that logic depends on the ownership model, territory definitions, account hierarchy and data hygiene inside Salesforce or HubSpot. That is the layer Twopir works on. We treat the product as one component of an inbound architecture rather than the architecture itself — which is why our engagements start with the CRM, not the booking form.
Implement, configure, or build on top of it
These are three separate pieces of work and they are usually bought by three different people. Knowing which one you actually need is most of the scoping conversation.
Implement
A first deployment. We stand Chili Piper up against your CRM, define the routing model, and get inbound booking live without disturbing the pipeline that is already running.
- CRM readiness review before install
- Ownership, territory and queue model design
- Salesforce or HubSpot connection and field mapping
- Form, calendar and meeting-type setup
- UAT, phased rollout and rep enablement
Configure
You already own it and it is not routing correctly. We audit the rules against how the team is actually structured, then rebuild the logic that is misfiring — usually without a reinstall.
- Routing rule audit against live lead data
- Lead-to-account matching correction
- Capacity, territory and working-hours weighting
- Handoff, reschedule and no-show handling
- Reporting and write-back field cleanup
Build on
The requirement has outrun the settings screen. We build the custom logic, objects and integrations around the product so it fits a routing model the standard configuration cannot express.
- Custom Apex, Flow and matching logic in Salesforce
- Middleware and API work for non-native systems
- Custom routing attributes and scoring inputs
- Bespoke reporting objects and dashboards
- Automated data-quality guards on inbound records
Where the boundary sits: if the rule can be expressed with the fields, queues and weightings the product already exposes, it is configuration and it belongs in the admin console — we will tell you so rather than bill for it. It becomes custom development when the routing decision depends on data the product cannot see, on logic it has no field for, or on a system it does not integrate with natively. Most engagements are mostly configuration with a small, well-defined build around the edges, and we scope those two separately so you can see which is which.
What we actually build on Chili Piper
Six workstreams. Most engagements need three or four of them — the audit decides which, before anything is quoted.
Routing Model Design
The rules themselves, written down before they are built: who owns what, under which conditions, and what happens when the first choice is unavailable.
- Segment, territory and vertical ownership maps
- Capacity, working-hours and time-zone weighting
- Fallback and escalation paths for every rule
- New-business versus existing-customer separation
- Documented rule set the team can maintain
Lead-to-Account Matching
The single highest-leverage fix on most inbound motions. An inbound contact has to resolve to the right account before any routing rule can be correct.
- Domain, subsidiary and alias matching logic
- Account hierarchy and parent-child handling
- Free-mail and personal-domain edge cases
- Duplicate prevention on inbound creation
- Match-failure queues instead of silent misroutes
Inbound Booking & Forms
The visitor-facing half: qualification on the form, real availability in the widget, and a confirmed meeting before the buyer's attention moves on.
- Qualification logic on marketing and demo forms
- Meeting types, durations and buffer rules
- Calendar connection and availability accuracy
- Confirmation, reminder and reschedule flows
- Routing that degrades gracefully, never to a dead end
Handoff & Qualification Flow
The SDR-to-AE transition, built so the context travels with the meeting instead of being re-collected in front of the buyer.
- Qualified-handoff booking on the AE's calendar
- Structured notes and disposition capture
- SLA clocks and stalled-handoff alerting
- No-show and reschedule ownership rules
- Slack or Teams notification routing
CRM Integration & Write-Back
Every routing decision, booking and meeting outcome recorded on the record it belongs to — so reporting reflects what happened rather than what was scheduled.
- Salesforce and HubSpot field mapping and objects
- Routing-decision audit trail on the lead record
- Meeting held, no-show and reschedule events
- Sync with sales engagement and marketing tools
- Custom API and middleware work where native falls short
Reporting & Ongoing Tuning
Routing is not a one-time build. Territories change, people leave, and the rules drift out of line with the team unless someone is watching.
- Speed-to-lead and time-to-meeting dashboards
- Distribution fairness and capacity reporting
- Match-failure and misroute monitoring
- Quarterly rule review as the team changes
- Retained support for admins and RevOps
Chili Piper and your CRM, on one routing model
Routing is a read-and-write relationship, not a one-way push. The product reads your ownership data to make a decision, then writes the decision and its outcome back so the CRM stays the system of record.
Salesforce
The usual system of record for ownership, accounts and territories — and where routing decisions are written back.
HubSpot
Forms, contacts and lifecycle stages feeding qualification, with meeting outcomes returned to the timeline.
Marketing Forms
Demo requests, content and event forms as the trigger point where qualification and routing begin.
Google & Microsoft Calendars
Live rep availability, so the slots a buyer is offered are ones that genuinely exist.
Sales Engagement
Sequence and cadence tools kept in step with routed ownership so outreach follows the assignment.
Slack & Teams
Assignment and no-show alerts delivered where reps already work, not buried in an inbox.
Enrichment Data
Firmographic data used as a routing input, so segment rules act on more than a form field.
Custom APIs
Middleware for the systems with no native connector — billing, product usage or an internal service.
| Data | Direction | Why it matters |
|---|---|---|
| Accounts, owners, territories | CRM → Chili Piper | Routing decisions read live ownership instead of a stale copy of the org chart. |
| Open opportunities and existing customers | CRM → Chili Piper | Inbound from a live account reaches the person who already owns the relationship. |
| Form submissions and enrichment attributes | Forms → Chili Piper | Qualification happens before routing, so the rule acts on a complete record. |
| Rep availability and working hours | Calendars → Chili Piper | Only genuinely bookable slots are offered, which is what stops same-day cancellations. |
| Assigned owner and routing decision | Chili Piper → CRM | Ownership is set on the record, with an audit trail explaining why it went that way. |
| Booked, held, no-show and reschedule events | Chili Piper → CRM | Pipeline reporting counts meetings that happened, not meetings that were scheduled. |
| Handoff context and qualification notes | Chili Piper ↔ CRM | The AE opens the call with what the SDR already learned, so the buyer is not re-interviewed. |
From routing audit to a system that holds
Five stages. A straightforward first deployment typically runs four to six weeks; a rebuild on a messy account model takes longer, and the audit is what tells us which one you have before either side commits to a date.
Routing Audit
We trace real inbound leads end to end, find where they stall or misroute, and test whether your account data can support the rules you want.
Model Design
We write the ownership and distribution rules down — segments, territories, capacity, fallbacks — and get them agreed before anything is configured.
Build & Integrate
We configure Chili Piper, correct the matching logic in the CRM, wire the write-back, and build any custom work the rules require.
Test & Roll Out
We replay real lead scenarios against the rules, fix what misroutes, then release by segment or region rather than switching everything at once.
Tune & Support
We watch distribution and match failures through the first cycles, correct the drift, and keep the rules current as the team and territories change.
What correct routing changes
Six things that are true of an inbound motion once the routing model underneath it is right. Ask any partner to show you these in your own data before and after.
Inbound is answered in the session, not the next day
The meeting is booked while the buyer is still on the page, which removes the window competitors use to get there first.
Leads land with the rep who should have them
Existing customers reach their owner, enterprise reaches enterprise, and the region rule works without a manual reassignment behind it.
Distribution reflects capacity, not just rotation
Volume is shared against who is available and how much they are already carrying, so the queue stops concentrating on whoever is fastest to click.
More booked meetings actually happen
Reminders, easy rescheduling and clear no-show ownership turn a calendar entry into a held conversation instead of a gap in the week.
Handoffs carry their context
The AE opens the meeting already knowing what the SDR qualified, so the buyer's second conversation moves forward rather than starting over.
You can answer why a lead went where it went
Routing decisions and meeting outcomes sit on the record, so rules get corrected from evidence instead of argued about from memory.
Related delivery work: sales operations and lead management on Salesforce and a Salesforce and HubSpot integration build. Neither is a Chili Piper engagement — they are the routing, ownership and integration work this page describes, on the same stack.
Who this is built for
Four teams buy this work, for four different reasons — and one situation where we will tell you not to buy it at all.
Revenue Operations
You own the routing rules and need them to survive a reorg, a new territory model and two more segments without a rebuild.
Demand Generation
You are paying for the traffic and want to prove that a form fill turns into a held meeting rather than a lead-status change.
Sales Leadership
You need distribution you can defend in a QBR — fair, explainable, and matched to how the team is actually covered.
Salesforce & CRM Admins
You inherited a routing setup nobody documented and need it audited, explained and made maintainable.
When we will say no: if inbound volume is low enough that one person can triage it by hand, or if account data is so incomplete that no matching rule can be trusted yet, the routing tool is not your constraint. In the second case the honest first project is the data model — and that is a conversation about your CRM architecture, not about scheduling software.
Not a reseller. An architecture partner.
Most routing projects fail in the CRM, not in the routing tool. That is the work we are set up to do.
We fix the CRM before we tune the tool
Matching, ownership and account hierarchy decide whether any routing rule can be right. We start there, which is why our fixes tend to hold after the first territory change.
We work on both sides of the integration
We are a Salesforce Gold Partner and HubSpot Gold Partner with our own development capability, so the CRM half of the problem does not get handed to a second vendor with a different timeline.
We separate configuration from custom development
You get told which parts are settings and which parts are a build, and priced accordingly. If a requirement is already in the admin console, we say so instead of quoting for it.
We build rules your team can maintain
The routing model is documented and explainable, not a stack of undocumented exceptions. Your admin should be able to add a territory without calling us.
We stay through the first cycles
Routing drifts the moment the team changes. We watch distribution and match failures after go-live and correct them, rather than closing the project at handover.
Answers before the first call
Less product setup than people expect, and more CRM work. Connecting the platform and building meeting types is straightforward. The real work is defining who owns which leads under which conditions, making sure your account and ownership data can support those rules, and wiring the routing decisions back into Salesforce or HubSpot so reporting stays accurate. A first deployment usually runs four to six weeks; a rebuild on a messy account model takes longer, and the audit tells us which one you have before either side commits to a date.
If the rule can be expressed with the fields, queues and weightings the product already exposes, it is configuration and it belongs in the admin console — we will tell you so rather than bill for it. It becomes custom development when the routing decision depends on data the product cannot see, on logic it has no field for, or on a system it does not integrate with natively. Most engagements are mostly configuration with a small, well-defined build around the edges, and we scope those two separately so you can see which is which.
Yes — it integrates natively with both, and we implement it on either. What changes is where the routing data lives and how it is structured. Salesforce engagements usually centre on account hierarchy, territory management and owner assignment; HubSpot engagements centre on forms, lifecycle stages and the association model. Teams running both platforms need one of them named as the system of record for ownership before any rule is written, otherwise the routing logic will contradict itself.
That is where a large share of our engagements start, and the cause is usually lead-to-account matching rather than the routing rules themselves. If an inbound contact from an existing customer resolves as net-new, every rule after that point is working correctly on the wrong input. We audit the matching logic against real lead data first, correct it, and only then revisit the distribution rules. A reinstall is rarely necessary.
Both Salesforce and HubSpot can assign a lead to an owner. What they do not do well is decide, qualify and put a meeting on the right calendar while the visitor is still on the page — that real-time booking step is what the product adds. If your inbound volume is low enough that one person can triage it by hand, or your buyers are content to wait for a callback, the honest answer is that you do not need it yet. We would rather say that during scoping than after an implementation.
It should not, because we do not switch everything at once. Rules are tested by replaying real lead scenarios before release, and rollout goes by segment, region or form so a misroute affects one slice rather than the whole motion. Existing assignment logic stays in place as a fallback until the new rules have run clean through a full cycle. Inbound leads keep arriving throughout; what changes is who they reach and how quickly.
No. You buy your licences from Chili Piper directly, and we implement and integrate the product for you. We are a Salesforce Gold Partner and HubSpot Gold Partner, which is the side of this problem our credentials are on and where most of the work sits. The practical benefit of that split is that we have no incentive to recommend more seats than your routing model needs.
Next Step
If inbound is arriving faster than your routing can handle it, this is the right conversation
Start with the routing audit. We trace your real inbound leads, show you where they stall or misroute, and tell you plainly which parts are configuration and which parts are a build — before anyone talks about scope.
Speak with a team that works on both sides of the integration
