Dynamics CRM 2011: Diving into the sales pipeline – Part 1

No matter how orthodox and customisation-free you want your Dynamics CRM implementation to be, there is always one aspect of Dynamics CRM that must be customised: The Sales Pipeline. Such customisation is required if you want the default sales pipeline to work properly, as well the sales pipeline report.

The issue at hand is, how can we set-up a functional sales pipeline with charts and reports, yet keeping Dynamics CRM as close as possible to its out-of-the-box functionality? Which fields should we use and how should we design our workflows?

Because there’s so much to discuss here, I’m going to break this up into multiple parts. And in this first part of the series, I’d like to address the fundamental concepts of the sales pipeline and introduce some key points on how to conduct a requirement assessment.

What is a sales pipeline?

The first thing we must understand is what a sales pipeline is all about. According to Selden (1997) a sales pipeline, also known as a sales process, is a “systematic approach to selling a product or service”. Basically we map the sales process, spliting it into stages (or phases) from beginning to end, in order to enable careful analysis (such as risk management and revenue forecast) and continuous improvement. For instance, by defining the sales pipeline and identifying its stages in sales opportunities, we would be able to identify how many opportunities we have in each stage, which salesperson/salesteam is more efficient and so on.

For further information on sales pipeline see Wikipedia.

Defining the stages of our sales pipeline

After we understand what sales pipeline is all about, we must define the stages of our process. For example, this what we have initially identified in ACME:

Generally speaking there is no right or wrong answer. Every organisation has its own process. However, when implementing the sales process in Dynamics CRM, we might want to reconsider how these stages are going to be mapped in the application, in order to make most of its features.

Note: Some of you might be thinking “what if my organisation has different steps for different products/services being sold?” A fair question, but in this case you should always consider your sales pipeline from a macro perspective. No matter if you have a different sales process for apples and oranges, you should map all of your processes into punctual milestone stages (i.e.: your sales pipeline phases), in order to present a strategic “holistic” view of your sales pipeline. Considering the above example for ACME, regardless of the nuances between the sales of apples and oranges, the opportunity will always reach a stage where a proposal is sent, and if things go smoothly, it would eventually progress to the negotiation stage, and so on. Failing to create a holistic sales pipeline would not only be a failure from a management perspective, but your sales pipeline charts and reports within Dynamics CRM would make no sense.

Sales management in Dynamics CRM

In Dynamics CRM, a sale can start with the registration of a Lead. A Lead is a potential client that must be qualified or disqualified as sales opportunities. If a lead is qualified, then it can be converted to a sales opportunity and client record (an account and/or contact).

The following diagram represents the typical sales management process life-cycle within Dynamics CRM:

Considering this diagram, we can see how the natural progression of a qualified lead is to spawn new records. Looking back at our original sales pipeline, we can conclude that the first stage of our pipeline (Suspect) is handled by the Leads entity within Dynamics CRM.

At the core of our sales process we have the opportunity record, which represents the sales pipeline for the organisation. In other words, an opportunity represents potential revenue from a registered client (a client can be an account or contact). Opportunities can be linked to other types of records, such as:

  • Originating Lead: The lead record that originated the opportunity (if applicable)
  • Competitors: Who are we competing with in this sale
  • Products: What are we intending to sell
  • Potential Client: The account (organisation) or contact (person) to which we are trying to sell to

It is not a always that an opportunity is originated from a qualifying lead. For example, an existing client could issue a request for proposal or request a quote to purchase more goods. In which case, a salesperson might register an opportunity directly for the client without the need of first creating a lead.

It is important to understand that as soon as an opportunity is marked as won within Dynamics CRM, the opportunity is closed. That means that the opportunity is now outside of the scope of the sales management process and we are now dealing with after-sales activities. Opportunities closed as won don’t show on sales pipeline charts and reports.

Looking again at the at our original sales pipeline, we can identify that the Deal stage is when we close the opportunity as won. We can also conclude the the last two stages of our pipeline (Implement and Post Sales) relate to after-sales activities. Therefore from the moment we win a deal, it is beyond the scope of sales.

Considering how Dynamics CRM manages the sales process by default and that the opportunity is the record type that represents the sales pipeline, we can map our sales pipeline to the opportunity record as follows:

Remember that the Suspect stage is dealt through the Leads entity, and the Implement and Post Sales stages are beyond the scope of a sale. Therefore, in our revised sales pipeline we are left with Prospect, Proposal and Negotiation within the scope of opportunities. Deal is not necessarily a stage in the sales pipeline, but nonetheless it is a milestone. Reaching the Deal milestone means that the deal has been closed and therefore the opportunity is no longer comprising the sales pipeline, but archived as closed with the status reason of won.

So let’s now have a look at the at the opportunity entity within Dynamics CRM, which is the main record of our sales process.

The Opportunity entity

We have a lot of fields we can use when registering opportunities such as Potential Client (lookup) and Est. Revenue (currency). I’d like to draw your attention to the following fields that comes with Dynamics CRM which we will be using for this tutorial:

  • Pipeline Phase
    [single line of text] : Current phase in the sales pipeline for the opportunity. Designed to be updated by using workflows.
  • Process Code [option set] :Customizable code that represents the current stage of an opportunity in a manual sales process. Designed to support manual sales processes upgraded from earlier versions of Microsoft Dynamics CRM.
  • Rating [option set] : Quality of the opportunity, such as hot, warm or cold.
  • Probability (%) [whole number, from 1 to 100] : Likelihood of closing the opportunity.

From the four fields mentioned above, two of them are noticed when you open the opportunity form: Rating and Probability (%). The Pipeline Phase field is at the footer of the form, and the Process Code will be manually added into the form in this tutorial.

Pipeline Phase

This field is where we store the value of in which stage of the sales pipeline the opportunity is at, which is used by charts and reports in Dynamics CRM. What we must decide now is how we are going to move through these stages. This could be done as follows:

  • Automated (set indirectly by the user): The opportunity will move forward in the sales pipeline exclusively through the use of workflows as certain criteria in the opportunity record is being met. For example, we could add a field in the opportunity entity where the user specifies a date for when the proposal has been sent. When this field is filled and the opportunity record is saved, the opportunity would automatically move to the Proposal stage.
  • Manual (set directly by the user): With this method, the user specifically sets in the opportunity record which stage of the sales pipeline the opportunity is at. For example, the user could select the stage from an option set.

Note: Regardless of the method we use to move through the stages, a workflow is required in order to support the existing sales pipeline report that comes with Dynamics CRM. More on this latter as we move forward.

In the case of ACME, they opted to allow users to manually set the stage the sale is at through the use of an option set. For that We will use the Process Code field of the Opportunity entity.

Process Code

In this option set field we will going to list the stages of the pipeline that are part of the opportunity life-cycle. Basically, the text of the option selected by the user will be copied into the Pipeline Phase field. Since we previously decided that SuspectDeal, Implement and Post Sales are outside the scope of opportunity we should set the values of the Process Code option set as follows:

  • 1 – Prospect
  • 2 – Proposal
  • 3 – Negotiation

A warning on naming the stages: As I mentioned previously, the text of the selected option will be copied within the Pipeline Phase field ( a text field) that is used to draw charts and reports. If you have a multilingual deployment of Dynamics CRM and you decide to translate these options, you might end up messing your pipeline, such as segregating opportunities thare are on the same stage based on the localisation used when editing the opportunity (e.g.: 2 – Proposal, 2 – Proposta, 2 – Предложение). If you have a multilingual environment then you have two options. The first is to ensure that you do not translate the value of the Process Code option set. The second is to make that the Pipeline Phase field is always populated with the text of the Process Code field in just one language. This can be easily done with Javascript.
A warning on numbering stages: The pipeline funnel chart in Dynamics CRM orders the sequence of stages within the funnel alphabetically. Therefore it is important that we number those in a way that those stages are sorted accordingly in the chart. Numbers (1, 2, 3, …) and letters (a, b, c, …) should be ok.

Rating

The rating field allow users to select from an option set a value that classifies the opportunity based on the “feeling” of the salesperson. By default, this field has the values of hotwarm and cold.

Probability (%)

Another important concept we must understand is the likelihood/probability of closing a deal. The further we move through the stages of the sales process the closer we are of a deal. By default, Dynamics CRM allows the use of the Probability (%) field by users where they can type in a percent value (whole numbers from 1 to 100) representing the likelihood of closing the deal.

Here is an example that outlines the probability along with our previously defined sales pipeline:

Let’s consider the following scenario, however: What if we want to consider other factors to define the probability? For example, an organisation could consider different probability scales between private sales and public bids, or in the case of ACME, based on the opportunity rating.

The Probability Matrix

By default, the Opportunity entity allow users to select a Rating (either hot, warm or cold), and also allow users to type the value of the Probability (%) field. ACME decided that it would be best for the Probability (%) field to be automatically calculated, based on a Pipeline Phase X Rating matrix. That is, the value of the probability is automatically calculated based on which stage of the sales pipeline the opportunity is at and which rating the user has established. After some consideration we have established the following matrix:

As an example, if an opportunity is at the stage “2 – Proposal” its rating is set as “warm”, the closing probability for the opportunity would be automatically set at 50%.

We now have all the details we need in order to customise Dynamics CRM to meet our requirements. So let’s move on to it.

Coming up next: Customising the Opportunity entity

In my next post we will be discussing how to customise the Opportunity entity in order to support the requirements discussed so far.

Tags: , ,

2 Comments

Blog Categories

Recent Posts