If you have recently added LeanData to your tech stack to handle lead routing and account assignment, you may be wondering how you can get more out of the platform, and how best to set yourself up for scalable success in the future.

While LeanData’s ability to help automatically manage routing rules in a complex sales and territory ecosystem is the main reason companies invest in the platform, there are ways you can set the platform up for success that take into consideration all of its functionality.

Record Ownership

Most organizations purchase LeanData to make sense of complex routing and matching rules but fail to consider how the platform can help with their needs around record ownership and management of record assignments.

To create the desired efficiencies and reduce complexity around ownership and assignment, we recommend utilizing a short discovery process to outline challenges and requirements for lead routing. Use the questions to define your lead routing and matching rules in order to define your needs and requirements. These questions will also serve to outline the structure for solution implementation:

• What defines a record that should not be routed?
• Who should own partner leads?
• Who should own leads that are not matched to an account and are not ready for sales?
• Should leads that are matched to an account be converted into contacts?
• Who should own leads that are matched to an account but not converted?
• How should an account team member be notified when conversion takes place?
• How should sales be notified when a lead or contact becomes qualified and is ready for sales?
• Who should own a lead that is converted to an account and is qualified?
• Who should own a contact when engagement takes place or a new opportunity is created?
• If you have multiple data vendors, which data set is prioritized for matching?
• Who should own a lead if the matched account has an open opportunity?
• What is the best way to support regional or territory assignments when account teams exist?

With the answers to these questions in hand, you can design a solution using LeanData to aid with better management of record ownership.

Node Decision Priority

Based on the requirements defined during the record ownership project phase, we recommend companies prioritize these requirements into node priorities. Node prioritization defines the buildout of the flow builder. For efficiency, it is valuable to prioritize record management requirements to minimize the number of records passing through downstream nodes unnecessarily. For example: if a lead is created and marked ‘LeanData do not route = true’ then LeadData can remove those records at the top of the tree, reducing the number of legitimate records passing through the additional nodes.

Here is an example of how you might prioritize nodes within the flow builder:

• Priority Node 1: LeanData Do Not Route = TRUE
  By prioritizing this node first, you remove records from the tree that should not be routed, this helps answer the first question above
• Priority Node 2: Partner Records
  Partner records may need to be routed to a specific team to follow a defined process, by prioritizing this node at the top you can route Partner records early
• Priority Node 3: non Qualified Records and No Account Match
  You may have defined a process of record ownership for non-qualified records without a matched account. This may include assigning these records to a lead queue or specific user based on different attributes such as geography or custom field. By prioritizing this node at the top of the builder, you are able to remove these records from the flow builder.
• Priority Node 4: Matched Accounts
  Next up in priority may include a match node for existing accounts in your CRM based on certain data attributes as called out above in the questions. By matching accounts, leads can then flow through additional nodes based on data attributes to ensure ownership and conversion process is followed.

Setting up prioritization groupings in advance, based on routing and matching requirements allows for easy translation to LeanData’s drag and drop interface.

Naming Conventions within LeanData

Once requirements are defined and prioritized, we recommend creating a naming convention to be used across nodes. Implementing a strategic naming convention provides clarity to users on the purpose of the node and easy identification of nodes to update when needed. We recommend a naming convention with the following components:

• Object: Lead, Contact, Account, or Opportunity
• Number: start with 1 and add a ‘.’ as a separator
• Type of Node: Decision, Action, Matching, Time Based
• Node Details: Route, Create, Merge, etc
• Team: Marketing, Sales, Etc

Use abbreviations for each of the components and a “.” separator between each. We recommend a period as a separator primarily because the text space of each node is valuable real estate. The goal is to have a naming convention that allows nodes to be easily read when a user reviews the interface for each object versus having to click into individual nodes.

Naming convention example: L.1.A.U.M – Update Lead Status. This sequence would tell a user that this node is:

• On the lead object
• The first in the flowbuilder sequence
• An action node
• Used to update a field
• An update related to the marketing team
• Update Lead Status spells out the specific field being updated

To ensure consistency and reduce naming errors, create a shared document with this naming convention defined. The shared file should also include current nodes and their names. If a user makes an update to the flowbuilder, the node name can be updated as needed or noted that it was removed with the date and reason. This documentation will serve as a changelog so users can easily identify updates to nodes.

Custom Routing Fields

With your rules, priorities, and names in order, there is one more function to build in additional efficiencies. Custom routing fields provide these benefits. With custom routing fields, you can create a one-step process to handle common scenarios. Some examples of common custom routing fields are highlighted below.

• LeanData Do not Route: there may be a number of records that should immediately be excluded from the flowbuilder, this custom field can be leveraged in a true/false decision node.
• LeanData Force Update: this field can be used to force a record through the flowbuilder when needed, such as when a record was assigned incorrectly or you need to do a mass update and reassign records based on logic updates in the flowbuilder.
• Infraction SLA: if your company has defined SLAs for qualified record outreach, this field can be updated in an action node when a record processes through a time-based node but there hasn’t been any action taken and the status remains unchanged. We have seen customers use this field to pull reporting in Salesforce to report on the number of SLA infractions by object type.
• MQL Record Type: some customers have a need to route records based on MQL type, think hand raise versus score threshold By populating a type value in a custom field, you can use the decision node to decide how to route the record, either to a specific lead queue or to a user.

If you’re seeking to create more scalable lead routing and matching rules, or want to learn more about how Etumos can support LeanData strategic implementations, please let us know!