Sales Process Engineering

CRM 4.0 Workflow

Sales Pipeline Report

June 7, 2009 by Bill Bonofiglo, Dynamics MCT

Abstract

A defined Sales Process in a business can be mapped to and enforced using CRM workflow. It is also a requirement to make use of the Sales Pipeline report for the Opportunity record. The absence of a "published" working workflow using defined Stages renders the Sales Pipeline report rather benign.

Getting Started

This report is a fantastic tool and we want to take advantage of it. So, we will engineer a fully functional Sales Process workflow and I will let you download and use it to boot.

TIP: I developed this workflow in CRM Online; therefore, .NET development is not required. It is also an excellent starting place and I will even point out potential weak spots.

Requirements

1) You will need to add a custom pick list to the Opportunity form (see image below) and publish the changes.

NOTES: I added a new tab labeled "Sales Processes" (optional) and placed the "Manager Approval" pick list there (I also have a few other custom fields that work in conjunction with another more complex sales process workflow on this tab).

2) Import the workflow and publish it.

Scope

Drag you through an entire Blog of "the CRM world according to Bill" and then give you the code for free somewhere near the end. Actually, the scope is to build a Sales Process workflow and enable the Sales Pipeline Report.

What is a Sales Process?

It is simply an algorithm, or recipe, with defined Stages. Within each Stage, certain "tasks" or "events" must be completed before the process moves to the next Stage. Let’s engineer the simplest one for a starting example.

Stage 1) Shake someone’s hand and introduce yourself.

Stage 2) Ask them to buy your product.

Stage 3) Close the deal as a "win" or "loss" based on the answers "yes" or "no" respectively.

Sounds made up, doesn’t it? Think about a boy or girl Scout knocking on your door. You answer and they say "Hi, I am so and so." You say, "What can I do for you today?" That is Stage 1.

Then they say "Would you like to buy some cookies?" That is Stage 2.

You then answer "No thank you, not today." The Scout closes the deal as a "loss." That is Stage 3.

Simple, right? But it is a genuine Sales Process and the Scouts repeat it over and over again. The same principals apply to complex Sales Processes.

Keep in mind a Sales Process can have many Stages and be very complex. However, let’s not forget our goal to build a "real world" Sales Process, that will function and not be too restrictive so we can make use of the really cool Sales Pipeline report.

TIP: Engineering an effective Sales Process workflow is as much an art as a science. There is a balance between how rigid it is (so Users follow the rules) and how forgiving it is (sometimes rules need to be bent, or broken) (guess what movie that is from?) because Stages may need to be allowed to be skipped. Say what?

Sure. Why would you drag a Customer and their record, through an entire Sales Process, if, for example, you took them to lunch at the beginning of the process and they said "Yes, I will buy it and will pay cash." What then? Go back to the office and click 55 times to finish the Sales Process Workflow. NOT! The code needs to be flexible enough to handle these events.

Real World Sales Process

Our simple example did not have any "tasks" or "events" that needed to be completed or happen. So let’s fill in those areas with a more complex example. Let’s pretend we are selling large ticket items, such as boats. Remember, since we are pretending, there will be "more holes in our story than a horse traders mule" (guess what movie that is from?).

For our workflow, we will have three Stages:

1) No Revenue Yet

2) Awaiting Manager Approval

3) Opportunity Closed

TIP: The name of the Sales Process maps to pick lists in the Sales Pipeline report. If you have multiple Sales Process workflows (allowed) and multiple Stages (allowed), you can toggle the view in the report to reflect a specific workflow and the report will automatically show the Stages. So, choose your Stage names wisely young Skywalker.

Overview of the Three Stages

1) No Revenue Yet

There is no "Quan" (money). The Customer is considered a "qualified Lead" and the Opportunity record is created. However, we are not exactly sure what boat they want or their budget. Workflow sets the "Probability" to 10%. Confidence is low.

The sales person works with the Customer over a period of time to determine their budget and/or even what boat they want. Once determined, the amount is entered into the Estimated Revenue field, the records saved, and workflow sets the "Probability" to 50% (confidence is higher) AND sends an email to the Manager for approval (moves to Stage 2).

OR, the Customer says "No thank you" and the Sales person closes the Opportunity as "Lost" and the workflow quits.

2) Awaiting Manager Approval

Manager receives the email notice. Opens and reviews the Opportunity and chooses either "Manager Approval" or "Not Approved" from the Manager Approval pick list from the custom attribute on the Opportunity form we created.

"Manager Approval" and an "Approved" email goes to the Sales person. "Not Approved" and a "Not Approved" email goes to the Sales person. In either event, the workflow moves to Stage 3.

OR, the Sales person closes the Opportunity as "Lost" or "Won" and the workflow quits.

TIP: Emails could be sent to the Manager if the Opportunity is "Lost" or "Won" here but I omitted them to keep the example easier to read and follow.

TIP: This is a good example of a Sales Process not being too rigid. As we know, EVERY deal is supposed to have "Manager Approval." It is Sales Process law at our marina. However, the Customer had a good day in Vegas shooting Craps and has decided to pay CASH and the Manager has not responded yet. The rules are now broken because "We don’t need no stinking approval for cash" (guess what movie that is from?).

Our logic will allow the Sales Person to close the deal as "Lost" or "Won" at this time and handle it. In this example, the code handles a lack of response from the Manager because one of the "Wait" conditions it was programmed to monitor was met. This is also a great example of a parallel Wait Branch.

A parallel Wait Branch waits until the first condition is true and then executes it. That’s right, it is waiting for ALL of them simultaneously. So, in our Sales Process in Stage 2, the code is waiting for ANY one of the four conditions to come true 1) Approved, 2) Not Approved OR 3) "Won" or "Lost." First one to come true gets executed and the workflow moves on.

3) Opportunity Closed

Scenario 1: We have the Quan (revenue), Manager Approval and the Customer buys it. We close the Opportunity as a "Win" and we get invited to the Customers parties. The workflow quits.

Scenario 2: We have the Quan (revenue), Manager Approval and the Customer buys it from the Competitor across the street. It appears the Competitor took the Customer golfing, bought lunch and bought a few beers afterwards. We close the Opportunity as "Lost" and we don’t get invited to the Customers parties.

However, the workflow creates a Task to send a "thank you" letter with a due date of 5 days. That’s a nice touch. Maybe the Sales person will get invited to the parties after all. Then, the workflow quits.

What Have We Learned?

So, after all this work, we have a bullet proof Monk…I mean workflow, right? NOT! Say what?

Trust me, I would like to stand up behind the podium and wave to the crowd smiling and nodding taking in all the accolades etc. Sure I would. But I cannot. Please view the context of this CRM article and Sales Process engineering more as an example, learning experience, head start with some free code and a dash of entertainment. I am confident, in the "real world," this workflow is not robust enough. It could use more sophisticated logic and help from its’ relative and buddy, Mr. Scripting.

TIP: It is very common when customizing CRM to use a combination of Workflow and scripting. Think of it as a ballet, or medley, of choreographed events from different disciplines working together with a common goal – Quan. Sometimes workflow needs some help from Mr. JavaScript.

For example, there is nothing preventing a User from deleting the Estimated Revenue amount or changing the Manager Approval choice. Scripting could work in conjunction with workflow and prevent events like this from happening and blowing up the Sales Process.

Don’t get hung up on this detail, it is out of the scope of this article. I am simply pointing out areas for you to concentrate on and get you pointed in the right direction.

Get Code Here

Conclusion

As you can see, Sales Process engineering is as much an art as science. It should be obvious that the benefits far outweigh the cost. Letting software automate and enforce business procedures so a sales staff "does it right" is extremely valuable. Dynamics CRM gives you the tools to make it happen.

Please click the image on the right...

Hire a Dynamics MCT

Developing the Workflow using Microsoft Visio and implementing to code into your Microsoft CRM deployment is part of our CRM Consulting Services. Please contact Bill today using the Contact web page (top right tab).

Thank You

Bill Bonofiglo
Dynamics MCT / MCP / CIS Instructor