Processing Leads

This chapter covers the following topics:

Leads Processing Engine Overview

The Leads Processing engine comprises the qualification engine, the rating engine, and the channel selection engine.

The engines are based on a generic rules model, which consists of Guards, Rules, and Precedence.

Rule Set Details

Guards are used to group rule sets into domain-specific buckets. They parse rule sets into groups based on business-specific practices. Each rule set defines the set of leads to which it applies such as product-specific, campaign-specific, and country-specific lead processing for each stage of lead evaluation.

Guards can have multiple conditions. There is an implicit AND across conditions and an implicit OR within conditions. For example, if the Guard is defined as Country = France, Germany, UK; Product Category = Printers, Desktops, then this is interpreted as evaluate all leads that originate from countries France or Germany or UK for product lines Printer or Desktops.

After the rule sets are bucketed into different groups, the Precedence of each rule set is used to determine the order of evaluation. For example, if the attributes of a lead are matched with a Country-specific and a Campaign-specific rule set, by assigning the Country-specific rule set a higher precedence, this rule set is evaluated before the Campaign-specific rule set.

For precedence, 100 is higher than 1.

Reports

The Leads Processing History and Rule Performance Reports help you analyze the effectiveness of the rule sets in an engine. To troubleshoot rule set issues, see the Rule Diagnostics Report.

Rule

Using the guards, after the correct rule sets are selected, the rules of each rule set determine the conditions and action to be performed on the lead. For example, if certain conditions are true at the time of evaluation, the lead is set to qualified, or rated A, or channelized to Direct Sales.

Rules are evaluated in precedences from 1-n, where 1 is evaluated first. On evaluation, the winning rule set with the highest precedence is used to select the rule set result. If more than one winning rule set has equal precedence, the best or the highest ranked result, wins.

Attributes

Add attributes to the rule set.

The Qualification Engine

When a lead is run through the Leads Processing Engine, it is processed by the Qualification Engine (QE) first. In this release, the QE has two primary functions:

At the end of the qualification process, a lead may be qualified or disqualified. All qualified leads are routed to the Rating engine. All disqualified leads are routed to the Channel Selection engine.

How Does the Qualification Engine Work?

Each rule set is a grouping of rules. The rule set is defined by its Guard. The rules with a guard define the criteria and outcome.

The QE identifies the rule sets that can evaluate the lead by comparing the guard values in the rule set with the attributes of the lead being processed. For example, if the lead has Campaign A as an attribute, the QE searches for a rule set with Campaign A as a guard value.

After the matching qualification rule sets are identified, the engine starts evaluating the rules of each rule set, starting with the rule set of the highest precedence.

When a rule set wins, i.e., all the qualification rules of the rule set are met for the lead, the engine stops evaluation. Depending on the outcome, the lead is then qualified or disqualified, and the winning rule set is logged into a history table for analysis.

If no rule sets win, the lead is set to the value specified in the OS: Default Qualified Flag for Lead Qualification Engine profile. The default value for this profile is No.

In the case where two rule sets win, and one rule set qualifies the lead, and the other disqualifies, the lead is qualified by the QE.

The Rating Engine

After a lead is qualified by the Qualification Engine, it is processed by the Rating Engine (RE). The RE prioritizes the leads based on their attributes, and assigns them ratings. The rating helps the sales representative decide the importance of a lead, and accordingly follow up with the lead.

How Does the Rating Engine Work?

When a lead is run through the RE, the engine first identifies the correct Rating rule set to evaluate. This process finds all matching rule sets by applying the lead attribute values against each rule set's guard values. For example, if the lead has Campaign A as an attribute, the RE looks for rule sets with Campaign A as a guard value.

After a matching Rating rule set is identified, the engine starts evaluating the rules for each rule set, starting with the rule set of the highest precedence. The RE evaluates the rules in the order of evaluation assigned and stops when it finds a rule that matches the lead.

When a rule wins, that is, all the criteria are met for the lead, the RE stops evaluation. The lead is then assigned a rating, and the winning rule set is logged into a history table for analysis.

If more than one rule set with equal precedence win, the highest rating is selected.

If no rule sets win, the rating set in the OS: Default Rating for Lead Rating Engine profile is used. The default value for this profile is Cold Lead. This profile value must not be set to blank.

Setting Up Ratings

Ratings must be set up before rating rule sets are defined. Use this procedure to set up ratings.

Navigation: Log in with the Oracle Marketing Superuser responsibility, and navigate to Administration > Leads > Setup > Rating.

Notes

Note: When you create a rule set, the grades that you just set up may not appear in the drop-down lists. You must restart the apache to reload data from the database.

The Channel Selection Engine

The Channel Selection Engine (CSE) is responsible for distributing leads to the appropriate teams for further follow up and action. Based on channel selection rules and the lead attributes, a lead is assigned to a channel.

Examples of channels are Inside Sales, Direct Sales, Indirect Sales, and Partner.

How Does the Channel Selection Engine Work?

The CSE is similar to the Qualification and Rating engines. When a lead is run through the CSE, the engine first identifies the correct Channel Selection rule set to evaluate. This process finds all matching rule sets by applying the lead attribute values against each rule set's guard values. For example, if the lead has United States as its Country attribute, the CSE looks for rule sets with United States as a guard value for Country.

After the matching channel selection rule sets are identified, the engine starts evaluating the rules, starting with the rule with the highest precedence. Each rule has an order of evaluation associated with it. The Channel Selection Engine evaluates the rules in that order and stops when it finds a rule that matches the lead.

When a rule wins, i.e., all the criteria are met for the lead, the engine stops evaluating channel rule sets. The lead is then assigned to the selected channel and the winning rule set is logged into a history table for analysis.

If more than one rule set with equal precedence win, the highest ranked channel is selected.

Setting Up Channels

Channels must be set up before channel selection rule sets are defined. Use this procedure to set up channels.

Navigation: Log in with the Oracle Marketing Superuser responsibility, and navigate to Administration > Leads > Setup > Channel.

Notes

Note: When you create a rule set, the channels that you just set up may not appear in the drop-down lists. You must restart the apache to reload data from the database.

Best Practices

Some best practices that you can use when you are working with the Leads Processing Engines are listed below:

For example, you want to track leads for campaign VisionVideos. When you create your rule sets, use Campaign as a guard and select this campaign. Hence, all leads that result from the VisionVideos campaign are processed by this rule set.

Rule Flows

This Rule Flows report allows you to query across the Qualification, Rating, and Channel Selection engines for rule sets based on certain guard values.

This report supports multiple rule set groupings in the Rules Engine setup to track rule sets across processing flows. The rule sets are grouped based on the engine type. For example, Qualification rule sets are displayed first, then Rating, followed by the Channel Selection rule sets.

Search By

Purging Unqualified Leads

You can remove unqualified leads from the AS_SALES_LEADS table by running a concurrent program. Based on the following conditions, leads are deleted:

Unqualified leads that have been converted to opportunity will not be deleted by this program.

Note: After leads are purged from the system, any Trend reports set up in Oracle Daily Business Intelligence (DBI) or a custom application will be affected.

Use the following details to run the Purge Unqualified Sales Leads concurrent program.

Responsibility: Oracle Sales Administrator

Parameters:

Schedule: Once

See Section Running Concurrent Programs for the steps to run the concurrent program.

Setting Up Lead Assignments

Various system profiles can be set up to assign resources to leads based on the Leads Processing Engine results. Depending on the requirements in your organization, you can also define custom functions to route leads to appropriate resources.

Setting Up Automatic Lead Assignment

You can set up the application to automatically assign resources to a lead whenever an agent or salesperson creates or updates the lead. This is achieved by assigning values to selected profiles.

To enable automatic lead assignment, set the value of this profile to N. This is the default value. When this profile is set to N, a call to the Territory Manager API automatically assigns resources to the lead using the territories defined in Territory Manager. The first person the program assigns becomes the lead owner. The rest of the resources in the territory become sales team members on the lead.

If the lead creator is a valid sales agent or salesperson, the lead creator is added to the lead sales team when the lead is created.

If this profile is set to Y, an opportunity is created for all qualified indirect leads, and the partner matching workflow is launched.

All immature leads are assigned to a particular channel. The channel is decided by the value in this profile. The lead owner of an immature lead is determined by immature lead assignment.

Set this profile to a resource who will handle any lead that is not matched with any territory. If this profile is not set, the lead is assigned to the agent or salesperson who created or updated the lead.

Note: If both the resource in OS: Default Resource ID Used for Sales Lead Assignment and the user who created or updated the lead do not have a valid sales role assigned to them, then the leads you import will not be accessible from either Oracle Sales Online or Oracle TeleSales.

Set this profile to Yes if the territories in your organization use agent availability as one of the criteria for assigning agents. This enables the automatic assignment of lead owners based on availability. This profile is set to No by default.

Apart from setting this profile, you must also make sure that each resource has a calendar set up for them.

For more details, see the Oracle CRM Application Foundation Implementation Guide.

See Setting System Profile Options to set values to these profiles.

Setting Up Immature Lead Assignment

An immature lead is a lead that is not yet ready for a sales representative to spend time on. It is a low quality and low grade lead that needs to be matured by the marketing team before it is assigned to a sales team.

The Channel Selection engine assigns all immature leads to a specific channel, such as an Immature channel. This channel is decided by the value in the OS: Incubation Channel profile. When a lead is assigned to the immature channel, the owner is decided by the value in the OS: Default Lead Marketing Owner profile.

If the OS: Default Lead Marketing Owner profile is not set, the Territory Assignment program assigns all immature leads to the resources identified to act on immature leads.

The Maturation Assignment page in the Administration > Leads tab can be used to provide information about the territory assignment setup.

Note: The Maturation Assignment page will be obsolete from the next release. Use the Sales Channel to group the immature leads, and the Territory Assignment program will assign them to an appropriate resource based on the Channel Qualifier.

Use this procedure to add one or more resources to manage immature leads.

Navigation: Log in with the Oracle Marketing Superuser responsibility, and navigate to Administration > Leads > Processing Rules > Maturation Assignment.

Notes

Routing Leads Using a User Hook

You can implement custom rules for lead assignment by implementing the Lead Routing Engine user hook.

Hook Name: AS_LEAD_ROUTING_WF

Package Name: AS_LEAD_ROUTING_WF_CUHK

Purpose

If you are implementing custom lead routing rules, then create a package body according to these specifications.

Note: Do not commit in this package body. After the transaction is complete, Oracle application code will issue a commit.

This user hook will be called when an agent or salesperson is creating and updating a lead in the Lead tab, and from the Import Sales Lead concurrent program whenever the routing engine is called.

The calling package is AS_LEAD_ROUTING_WF.GetOwner.

API name

Get_Owner_Pre

Procedure Specification

PROCEDURE Get_Owner_Pre(

    p_api_version_number    IN  NUMBER,

    p_init_msg_list         IN  VARCHAR2 := FND_API.G_FALSE,

    p_validation_level      IN  VARCHAR2 := FND_API.G_VALID_LEVEL_FULL,

    p_commit                IN  VARCHAR2 := FND_API.G_FALSE,

    p_resource_id_tbl       IN  AS_LEAD_ROUTING_WF.NUMBER_TABLE,

    p_group_id_tbl          IN  AS_LEAD_ROUTING_WF.NUMBER_TABLE,

    p_person_id_tbl         IN  AS_LEAD_ROUTING_WF.NUMBER_TABLE,

    p_resource_flag_tbl     IN  AS_LEAD_ROUTING_WF.FLAG_TABLE,

    p_sales_lead_rec        IN  AS_SALES_LEADS_PUB.SALES_LEAD_Rec_Type,

    x_resource_id           OUT NUMBER,

    x_group_id              OUT NUMBER,

    x_person_id             OUT NUMBER,

    x_return_status         OUT VARCHAR2,

    x_msg_count             OUT NUMBER,

    x_msg_data              OUT VARCHAR2

    )

 IS

    l_resource_count            NUMBER;

BEGIN

      -- Standard Start of API savepoint

      SAVEPOINT GET_OWNER_PRE_PVT;

      -- Standard call to check for call compatibility.

      IF NOT FND_API.Compatible_API_Call ( l_api_version_number,

                                           p_api_version_number,

                                           l_api_name,

                                           G_PKG_NAME)

      THEN

          RAISE FND_API.G_EXC_UNEXPECTED_ERROR;

      END IF;

      -- Initialize message list IF p_init_msg_list is set to TRUE.

      IF FND_API.to_Boolean( p_init_msg_list )

      THEN

          FND_MSG_PUB.initialize;

      END IF;

        -- Initialize API return status to SUCCESS

      x_return_status := FND_API.G_RET_STS_SUCCESS;

      -- Api body

 

      l_resource_count := p_resource_id_tbl.count;

      IF l_resource_count > 0

      THEN

          x_resource_id := p_resource_id_tbl(1);

          x_group_id := p_group_id_tbl(1);

          x_person_id := p_person_id_tbl(1);

      ELSE

          x_resource_id := NULL;

      END IF;

      -- END of API body

      -- Standard check for p_commit

      IF FND_API.to_Boolean( p_commit )

      THEN

          COMMIT WORK;

      END IF;

        -- Standard call to get message count and IF count is 1,get message info

      FND_MSG_PUB.Count_And_Get

      (  p_count          =>   x_msg_count,

         p_data           =>   x_msg_data );

 

END Get_Owner_Pre;

 

END AS_LEAD_ROUTING_WF_CUHK; 

In Parameters

The following table lists the standard input parameters.

Standard Input parameters
Parameter Description
p_api_version_number For the Oracle Sales 12 application, this is set to 2.0.
p_init_msg_list Should the message stack be initialized? By default, this is set to FND_API.G_FALSE.
p_validation_level The validation level of the pass-in value. By default, this is set to FND_API.G_VALID_LEVEL_FULL.
p_commit Should a commit be issued for the whole API at the end? By default, this is set to FND_API.G_FALSE.

The following three parameters store the available resources for this customized package to decide the owner of the sales lead. Their data type is TABLE of NUMBERs.

The following table lists other input parameters.

Other Input Parameters
Parameter Description
p_resource_flag_tbl This parameter specifies the source of the resource:
  • D: Default resource from the OS: Default Resource ID used for Sales Lead Assignment profile.

  • L: Login user.

  • T: Territory definition.

    If the sales lead matches any territory, the above parameters will include all the resources returned from the territory engine and the p_resource_flag_tbl will be all T.

  • If the sales lead does not match any territory, and the OS: Default Resource ID used for Sales Lead Assignment profile is set:

  • p_resource_id_tbl(1), p_group_id_tbl(1), p_person_id_tbl(1) is the default resource defined in this profile.

  • p_resource_flag_tbl(1)=D

  • p_resource_id_tbl(2), p_group_id_tbl(2), p_person_id_tbl(2)=L.

  • p_resource_flag_tbl(2)=L

  • If the sales lead does not match any territory, and the OS: Default Resource ID used for Sales Lead Assignment profile is not set:

  • p_resource_id_tbl(1), p_group_id_tbl(1)

  • p_person_id_tbl(1)=L

  • p_resource_flag_tbl(1)=L

p_sales_lead_rec This provides the whole definition of a sales lead. This record is provided to help decide the sales lead owner.

Out Parameters

The following three parameters store the result of this user hook:

Together, they set the sales lead owner.

If x_resource_id is NULL, the owner is decided based upon Oracle's logic.

For example, x_resource_id=1001, x_group_id=10, x_person_id=100. The resource with the resource ID 1001, group ID 10, and person ID 100 will be assigned as the owner of the sales lead.

The following table lists the standard output parameters.

Standard Output Parameters
Parameter Definition
x_return_status The return status.
If your code completes successfully, then FND_API.G_RET_STS_SUCCESS must be returned. If you get an expected error, then return FND_API.G_RET_STS_ERROR, otherwise return FND_API.G_RET_STS_UNEXP_ERROR.
x_msg_count The message count.
Call FND_MSG_PUB.Count_And_Get to get the message count and messages.
x_msg_data The messages.
Call FND_MSG_PUB.Count_And_Get to get the message count and messages.

Setting Up Lead Status

Some lead statuses are seeded in the application. They are New, In Progress, Converted to Opportunity, Dead Lead, and Loss.

Use the following procedure to define alternate statuses.

Navigation: Log in as an administrator, and navigate to Administration > Sales > Opportunity > Status Code.

Notes

Using Custom Attributes

Apart from the seeded attributes, you can add custom attributes to meet your specific requirements. For example, you may want to set up rule sets based on a complex business logic, and the seeded attributes do not meet the requirements completely. For seeded attributes in Oracle Leads Management, see Seeded Attributes.

To create custom attributes, log in with the Oracle Marketing Superuser responsibility, and navigate to Administration > Leads > Setup > Custom Attributes.

Setting Up Time Frames

Time frames determine the expiration date of a lead. The expiration date of a lead is the maximum length of time frame relative to the creation date. You can assign number of days to a time frame.

Some seeded examples:

Within 1 week : 7 days

1-3 months : 90 days

Customizing Time Frames

The time frame periods can be customized to suit your requirements. However, the time frame itself cannot be modified, and new ones cannot be created. You must enable the time frames that you want to use in your organization.

To create custom time frames, log in with the Oracle Marketing Superuser responsibility, and navigate to Administration > Leads > Setup > Timeframe.

Notes: