Please do not try to build your own Lead Routing Solution in Salesforce

I beg of you. Don’t do it.

One might assume that an organization that provides high end resources to enterprises would want to build big complex things. And in some cases that is true – myself and our team overall enjoy solving very complex problems. But we have also been working in the Salesforce ecosystem long enough to understand that some problems should not be solved with custom solutions – someone has already done a better job building a solution and made it available via the AppExchange.

Two of the things we are most commonly asked to create are Attribution and Lead Routing. I’ll address Lead Routing in this post and Attribution in a future one.

Lead Routing

Salesforce’s Lead Routing (and other object routing, with the exception of certain areas around Service Cloud, Cases and FSL) is not robust. Even a company of a moderate size very quickly hits the limits of what it can do, and the work to configure that declarative feature and maintain it is immense, especially when considering staff turnover.

Organizations quickly become aware that they need a better solution. In researching those solutions they generally come across LeanData and Distribution Engine very quickly. However, thinking what they need is simple or that their needs are so specialized that nothing off-the-shelf can do it, they ask if we can build something for them. And we decline every single time.

This is the explanation we provide (and with this education, people come round pretty quickly):

Routing, by definition, is complex and also fluid.

Complexity

Complexity in a custom solution is the enemy (in most cases the death knell) of a declarative solution. The more complex something is, the less likely you can solve the issue without code in Salesforce. Things like Flows have come a long way, but building something that can handle all the if/and statements involved in routing decision-making for even one object is a nightmare.

Think your needs aren’t that complex? Here are a few decisions a custom routing engine might have to handle:

• Route Leads that are at this stage, but only if they are owned by these roles and profiles and queues and not these ones
• Then check if that Lead has another Lead for the same company that already has an owner. But what is a match? Is it by company name? What if more than one company has that name? And what if the name isn’t an exact match like Microsoft, Microsoft Inc, Microsoft North America. What if the trunk of the domain is the same, but it is a .ca and there is an owner for the .com? What if a Lead has the same email, but a different domain? There are endless scenarios.
• No owner of a similar lead? Better check Contacts and then Accounts. Cross-object matching – that’s not going to be easy.
• So we have some kind of match – now should this Lead be assigned to the owner of the match? What if the Owner is a Customer Success Manager, should the Lead be assigned to the Sales person for their territory instead? What if all leads are supposed to be worked by the SDR team? What if the Lead is from a country where they likely speak a different language, but the owner of the Account is based in North America and so is the parent company? The list of considerations is endless
• Once you have gone through all those scenarios – maybe you want to round-robin it to your SDR team. But what if the next person in the queue is on vacation? Or what if they are East Coast and this lead has come in during the afternoon on the West Coast and they are done work for the day? What if that really, really matters because the lead is from a click-to-chat submission.

So, in short – it can be complicated. And if you don’t have this complexity in the back of your mind, you might be building something that’s too simple and won’t scale at all.

Fluidity

Staff leave, new team members join, people get promotions, territories change, new markets open up, Go-to-Market shifts, new acquisitions mean account management starts to be a blend of people split by product. A healthy, growing company might be experiencing three or four of these changes in any given month. There are 2 major factors to consider here:

1. 1. When you develop code to solve problems, you want to be solving a somewhat static problem – that is, you want to have requirements that at least won’t change while you are still building the thing to get it live.
   2. Imagine you do build something that takes all those scenarios into account, what happens when the rules start changing every month? What happens when three new SDRs are added? What happens when the company decides that new leads owned by an Account will go to BDRs instead of SDRs? How much very expensive Salesforce Developer time is it going to take to make that change? (The cost is easily going to be in the thousands of dollars.) And how long is it going to take to rebuild to solve the new requirements, QA and deploy? What about maintenance? The cost can spiral quickly.

Now, compare that against the cost of a solution like LeanData. For clarity, CloudKettle isn’t a LeanData Partner, nor do we get any sort of commission (for recommending any software to clients – that is a company policy). What we do get, is a stable, well-built, easy to maintain and update solution that “just works”. What is important to note is that, with few exceptions, our clients are on long-term annual retainers with us. Whatever is built in their instances of Marketing Cloud, Sales Cloud, Service Cloud – we own. We have to babysit and feed and care for all the customization for years. For that reason we are very proactive in educating clients on the Long Term Cost of Ownership (LTCO) of anything we build. We know, from the many client orgs we have inherited, custom routing solutions are the absolute most painful, least rewarding things to maintain. So do yourself a favor and don’t build one.

Instead, make the investment in a solution like LeanData. It will save your money in the long run, but also you will benefit from being able to operationalize changes in the business immediately. The interface is easy for almost anyone to figure out quickly and once you familiarize yourself with even a complex routing map, making changes can be done in minutes.

• Moreover, LeanData comes with off-the-shelf bonus features that would be expensive and difficult to build in house:
• Multiple types of matching rules
• Integrations with things like Slack
• Notifications of failed routed records
• People on vacation can be automatically skipped in routing queues
• Routing can take time zones and work hours into consideration
• Routing can take roles in ownership into account – for example, if a matched account is owned by Sales person X, don’t assign it to any SDR, assign it to SDR that is tied to them
• If a rep is new, you can weight routing so they get fewer records. For example, as new SDRs are onboarded you may choose for them to only get half as many records routed in the queue as the fully onboarded ones. You can also choose not to route records to people with too many unworked ones, even track SLAs

Across the dozens and dozens of orgs we keep improving for our clients, LeanData is by far the most common routing solution and also the best in terms of features and usability. Distribution Engine from NC Squared is also a common solution if you are interested in price and feature comparison.

But please, whatever you do, don’t try to build one yourself.

 

Have questions about Lead Routing? Get in Touch! Or you can also sign up for our newsletter! We send out a monthly recap of our latest content, including articles on Revenue Operations best practices, actionable insight on Salesforce optimization for enterprises, and more.