Chili Piper is Better In Fire

If you’re upgrading from Chili Piper Legacy to Fire, then you have questions. 

That’s why we put on a webinar to chat about all things new in Chili Piper Fire.

We discussed: 

• What to expect when upgrading to Fire
• Building Routers in Flow Builder
• Reusable Assets vs Queues
• Reporting/Troubleshooting
• Matching Hub

Check the full recording here: 

Or if you’re like me and prefer reading, check our recap article here: 

What to expect when upgrading to Fire

First, we will be doing most of the heavy lifting for you:

1. All your assets will be automatically migrated

This includes Meeting Types, Queues, Booking Links, etc. 
We will use your Chili Piper Legacy queues to automatically build out Routers in Flow Builder.As far as queue history (meetings booked, rescheduled, cancelled, etc.), we will copy the current distribution levels, but not the queue history itself.

2. Any Chili Piper links you have will be redirected to new links

This includes both Concierge Links and also individual booking links. It’s still best practice to update your Legacy links with Fire links — but if there are links on a random campaign that you forgot about, they’ll be redirected to your Fire links. 

3. Your users will need to reconnect their Outlook/Google Calendar

In order to use Fire, they’ll need to reconnect their calendar.

4. You’ll need to reconnect any integrations

Admins can do this in the backend. If you’re using any integrations with Chili Piper, you’ll need to reconnect them. 

Now, let’s get into everything that’s new and improved in Fire!

What's New in Fire: Flow Builder!

With our new interface, you can visually see how your Routers will work. Chili Piper reads everything down. Once it matches a rule, it will go across. 

This same Flow Builder interface is the same across all of our products — Form Concierge, Handoff, Distro, and Chat.

Reusable Assets

What used to be known as “Queues” have now been broken into separate assets that you can reuse across Routers: 

• Meeting Types
• Rules
• Teams
• Distributions

For example, if you have a rule to route Mid-Market companies to the Mid-Market team, you can reuse that rule across Form Concierge, Handoff, Chat, and Distro. Or if you have separate Form Concierge routers for bookings In-App, on your website, and at events — you can reuse the same rule twice, instead of building it out for each Router. 

Learn more about Reusable Assets here.‍

Easily Troubleshoot with Logs

Now you can easily see why an inbound was routed a certain way: 

Learn more about Concierge Logs here.And finally answer the question “Why does Sarah have more leads than me”.

You can find a complete distribution of scheduling meetings and Records among your team members.

‍Read the Help Center article to learn more about Distribution Reporting.Matching HubThe matching hub is one consolidated place for all of your matching rules.

The matching hub is extremely powerful. So powerful that we hosted an entire webinar talking just about matching.

‍Check out the recap article + webinar recording here.

‍FAQs

Now we had a LOT of questions on the webinar. So many we weren’t able to get all of them live during the full hour-long webinar. So we’re adding the questions to the end of this article: 

1. Will we use our historical data from meeting queues?

We will copy across the current level at the point of migration for continuity (can be manually calibrated for any discrepancies between migration and go-live) but not the queue history (meetings booked, rescheduled, cancelled, etc.)

2. Are individual workspace booking links/meeting types migrated automatically?

Yes! Booking links and meeting types will be migrated automatically.

3. If we got the notice our flip would be switched on X date, does that mean we are fully migrated or do we need to click something as Admin?

It means that all of your assets have been migrated to Fire. After that has been completed, you’ll need to log into your instance in Fire. You can access your new instance here. After logging in, you’ll want to reconnect integrations, reconnect end user calendars, install the new Chrome extension, and check user licenses.

4. Once we switch to the new platform, how long do we need to wait for the old one to completely go away so that it doesn't cause confusion with users?

After you switch to the new platform and reconnect all end user calendars, we recommend asking users to delete the old Chrome extension as well. Chili Piper Legacy will be fully deprecated after everyone has completed their upgrade to the new platform.

5. Can you check ownership and then have it select the meeting type based on contact/account fields?

Yes! You can first set up route to ownership paths. Then, you can route based on any field you’d like on the Contact/Account object (or any other standard/custom object). For example if you want to route based on company size, you can set up your rules like this: 

• If company size field on the Account object is <50 employees, route to SMB team
• If company size field on the Account object is 50-5000 employees, route to MM team
• If company size field on the Account object is >5,000 employees, route to Enterprise team

Chili Piper will read each rule one at a time until the lead matches.

6. Does getting rid of the default booker also mean we won’t be on the meeting if it’s rescheduled? :)

Yes, that’s correct! In Fire, only the meeting assignee plus any other invited attendees (specified in the Display Calendar node) will be included on the meeting. 

7. Does the Booking Status field as part of the SFDC integration still automatically update or is this something that we need to add to each flow? 

Yes it does! This is one thing that you don’t need to create a specific node for.

8. We have different meeting types based on whether a contact is a prospect/client and then additional industry related contact accounts. We want CP to first look for the AE owner of the contact but then have them routed to the correct meeting type based on if they're a prospect/client and their specific industry

Yes, this is totally possible. You would set up your workflow kind of like this:

• If the AE Owner of Lead/Contact is in AE team, then route to AE owner, using the Inbound Demo meeting type.
• If Matched Account of Lead/Contact is a current customer AND in XYZ industry, route them to the AM owner using the Cross-Sell Demo meeting type
• If you need to be more granular, you could have multiple paths that route to the same group of people but have different meetings types associated e.g. book with the AE owner and use meeting type for Financial Services if Account.Industry = Financial Services. You could also redirect to a thank you page with Financial Services specific use cases to further personalise the experience.

You can get as specific as you’d like in your bullet points.

9. Can you still hide some distributions from IB, like in the “handoff router” section in legacy?

Yes. You have to specify the rule and corresponding distribution you want to display in the Handoff router. The nature of the platform approach means you could have 20 distributions in a given workspace but only 5 are used in a Handoff Router.

‍

10. Where is the Cherry Picking feature in Fire? I don’t see it in my Fire settings

If you’re unable to change the algorithm, you’re viewing a Prospect/Record distribution instead of a Meeting distribution. Prospect/Records distributions are always strict as there’s no availability to consider as there is when distributing a meeting via Concierge, Handoff, or Chat.

Here's an article with more info about setting up "prevent cherry-picking" features..

11. Taking it back to teams and distributions - our assignments are based on territories, and they change relatively frequently (quarterly). Now, the previous queues we managed at the territory level are grouped by team (ie New England, New York are now one team since they were initially assigned to the same person, but separate distributions). Do I need to re-split all of my queues if now for instance New England and New York are assigned to different people under different “teams” now?

Yes. A Team and Distribution for New England and a Team and Distribution for New York.

12. We noticed that you can no longer set Caps on  Meeting Types, only individual users within specific distributions. If that's something we could put back on Product's radar that would be super helpful.

We have it! It’s underneath the Meeting Types asset.Whilst it’s not possible to set host limits on Meeting Types anymore, it is possible to set host limits on individual scheduling links still:

The Product team is aware but this was a conscious decision to maintain consistency across the platform with limits applied to both meeting AND record distributions (those that did not book via Concierge/Chat and Distro).

13. When will the reassign function be added back to salesforce like legacy?

It’s already available! Follow the steps in this Help Center article to get it setup. 

14. Are the SFDC/CRM sync retries still in place? I believe it was 10 times over 24 hours

Yes:

1 -> 10 seconds - first retry "Pending",2 -> 1 minute,3 -> 2 minutes,4 -> 3 minutes,5 -> 5 minutes,6 -> 10 minutes,7 -> 30 minutes,8 -> 1 hour,9 -> 2 hours,10 -> 6 hours,11 -> 12 hours,12 -> 24 hours,13 -> 24 hours - final retry, then "Error"

15. Is it possible to stamp the “source” as seen in logs on the meeting in the CRM (HubSpot for us). It would be helpful for users to see the source of the meeting.

It’s not possible to natively re-use the source URL as a variable but variables are being introduced later this year (starting with Distro). If you were to capture the URL as a hidden field on the form and add it to the form mapping, it could be stamped to a property on the Contact/Company objects in HubSpot but not the meeting. HubSpot does not allow custom properties on Engagements for us to use as we do on the Event object in SFDC.

16. It was mentioned earlier about a disqualified booking status, how is that automatically applied, is there a specific routing rule needed?

To disqualify people with specific criteria, you need to create a dedicated routing rule and redirect anyone who meets the criteria to a thank you page or leave them on the form, like this: 

Alternatively, you can add the ‘Redirect to’ node after the ‘Catch All’ node at the bottom of the router and any prospects who don’t meet any of the other scheduling paths will therefore be deemed ‘Disqualified’.

Note: this will update the custom Booking_Status_CP__c field/property in SFDC/HS to “Disqualified”. If you want to update another field e.g. Lead Status, you would do with with the Update Field node after the redirect: