This article will overview how Chili Piper works with an existing inbound tech stack, whether a lead distribution tool (LeanData, Distribution Engine, etc.), Salesforce queues, or even an automated email out of a Marketing Automation tool (Marketo, Hubspot, etc.).
Please note that this is not one size fits all, as there are many different ways to go about configuring an inbound tech stack, but this will overview from a high-level how Chili Piper works with other tools in a typical sales/marketing stack, as well as several different ways to handle use cases that we often encounter.
- What does the data flow look like?
- What do you need to change/adjust with your existing processes?
- Automated processes post-form submission
What does the data flow look like?
Essentially, the following is what occurs upon form submission:
- The prospect submits the form.
- Chili Piper does a real-time Salesforce lookup to check if the prospect is an existing record.
- If so, CP can route based on ownership or data already existent in SFDC
- If not, CP can route based on existing Account data if it matches via our Lead to Account matching (if enabled) or we can route based on data submitted at the time of form submission (standard or hidden fields).
- If the prospect matches any of the queues, they are presented with the appropriate method of communication (calendar, live call, and/or live video) based on the configuration.
- If the prospect doesn't match any queues, they are disqualified and can either be handled with existing processes or via CP's Queues for Prospects who didn't take action.
- Depending on the settings and the Marketing Automation tool, the record is pushed to SFDC either by CP or the MA tool.
- If the prospect converted, CP creates an event under the appropriate record (if the setting is enabled)
- If the prospect doesn't end up taking action (booking a meeting, launching a live call, etc.), then they can either be handled with existing processes or via CP's Queues for Prospects who didn't take action.
Important Note: Regardless of whether or not the prospect is qualified/disqualified or if they convert/don't take action, the form submission will go through. Chili Piper lives behind the form and does not hijack the form submission itself.
What do you need to change/adjust with your existing processes?
The answer is not much! There are several areas that you will need to take into consideration when using Chili Piper in your inbound processes. Still, our tool was built to complement existing processes rather than cause disruption.
The following sections in this article cover these considerations.
Automated processes post-form submission
Because prospects are now converting at the top of the funnel upon form submission by booking a meeting, it typically makes sense to treat them differently than a prospect who either is disqualified or didn't take action/didn't convert.
The most common way in which to identify that a prospect had converted by booking a meeting, launching a call, etc. is utilizing one of our custom fields - specifically "Booking Status" (Booking_Status_CP__c in SFDC), which is populated either by "Booked" or "Not Booked" depending on whether the meeting was successfully booked or not.
If a meeting is booked, this field will be populated as a source of truth that the prospect has converted.
In some systems, you'll want to map to this custom SFDC field to update it accordingly, but this field can be leveraged in "exclusion logic" to ensure that a record isn't redistributed, send an email meant for prospects who didn't book, etc. For example, setting up a handler to check if Booking_Status_CP = "Booked", then don't route through external systems, as it's already been routed by Chili Piper.
How to handle situations where a prospect is deemed qualified but doesn't take action/didn't convert will be covered shortly under "Routing."
See more about our custom Salesforce fields here.
- For existing records, you can either use an ownership queue or route with data already existent in SFDC.
- For teams with more robust SFDC databases and/or teams that have a majority of their inbound inquiries come from existing records, this means that ownership will be respected that has been done by other tools such as SFDC, Marketo, or LeanData.
- For net-new records, you can route based on existing Account data if it matches via our Lead to Account matching (if enabled) or you can route based on data submitted at the time of form submission (standard or hidden fields)
- Because we do need to route in real-time, we don't have time for another system to complete the routing, so routing rules do need to be created in Chili Piper, which will often mirror your routing rules from the other system.
Routing prospects that don't book/convert or are disqualified
You'll want to consider two scenarios when deciding how you would like to route. Being that Chili Piper allows form submissions to go through regardless of whether or not a prospect converts, you'll want to decide how to route prospects that are either "disqualified" and not given the option to schedule a meeting, launch a call, etc. as well as prospects who are deemed qualified, but for whatever reason don't convert.
There are two ways to handle these cases essentially:
Leverage your existing systems/processes
- This would require utilizing the "Meeting Type" field mentioned earlier in this article. You could then route or utilize your existing systems accordingly, being that they didn't end up converting.
Use Chili Piper's Queues for Prospects who don't Take Action
- You can also use CP to route these records - the way we handle it is by assigning the lead/contact to the appropriate rep (if they don't own the record already) and sending them an email with the form fill data and a notification that the prospect had just filled out a form so they should reach out.
It is truly up to personal preference how to handle it. We have many customers who do it both ways. The only real pro of using Chili Piper over another system is being able to manage routing through a singular source (the form) in a single tool rather than multiple. However, some teams have more advanced routing needs with complex flows. In which case, it may make more sense to leverage existing systems/processes