Microsoft CRM Best Practices

Simple Sales Process

crmbest — Thu, 23 Feb 2006 21:55:00 GMT

Scenarioà

Bikes Corp has implemented MSCRM 3.0 in order to ensure profitable customer relationships and happy customers. Bikes Corp. sells all kind of bikes to institutional buyers like government, schools etc. Charlie is the owner of the business. Kevin is the sales manager and Nancy is the super salesperson.

Business Process à

Bikes Corp has implemented the following sales process:

Step1 à Assign all bigger than 5 million dollars opportunities to Kevin and all remaining opportunities to Nancy.

Step2 à Automatically apply the following sales methodology to each new opportunity:

First Stage: The owner of the opportunity makes a phone call to the customer to gather requirements and buying intent. At this time probability of sale is expected to be 25%. All activities for first stage need to be completed within 2 days.

Middle Stage: The owner of the opportunity submits an RFP to the customer. At this time the probability of sales is expected to be 50%. All activities for middle stage need to be completed within 5 days.

Final Stage: The owner of the opportunity closes the deal. At this time the probability of sale is expected to be 75%. All activities for final stage need to be completed within 5 days.

Opportunity Closed: The owner of the opportunity logs the deal into the system. At this time the probability of sale is expected to be 100%. All activities for this stage need to be completed within 1 day.

It should be noted that the opportunity might be lost in middle of any of the sales stages specified above. In that case, the salesperson closes the opportunity as lost. That pushes the opportunity out of sales pipeline.

Step 3 à Notify the opportunity owner each time a new opportunity is assigned to them.

Step 4 à Notify the task owner each time a new task related to the opportunity is assigned to them.

Step 5 à Charlie wants to ensure that things happen on time and owner’s manager is notified each time an activity is not completed by due date.

Workflow Configuration à

Please download the salesprocess_v1.zip file. Unzip it on your machine and follow the instructions in readme.txt.

Ensure that the following workflows are activated:

Step 1 à Opportunity Assignment (opportunity entity, workflow rule)
Step 2 à Sales Methodology (opportunity entity, sales process)
Step 3 à Assignment Notification (opportunity entity, workflow rule)
Step 4 à Task Assignment Notification (task entity, workflow rule)
Step 5 à Incomplete Task Escalation (task entity, workflow rule)

Process Visibility à

MSCRM 3.0 UI makes the sales process related information available to people in the following manner:

Status of an opportunity à

Click “Sales” on main menu and select “Opportunities” in left navigation pane. A list of opportunities shows up in the right pane. Select the opportunity of interest and double click on it. The opportunity form opens up. Click on the “sales process” tab in left navigation bar. The sales process shows up as follows:

Sales Pipeline Report à

Click “Sales” on main menu and select “Opportunities” in left navigation pane. A list of opportunities shows up in the right pane. In the right pane click on reports icon and choose sales pipeline report. The sales pipeline report shows up as follows:

NOTE à

· The sales process described above is for illustrative purposes only. Sample rule example in the attached zip file can be extended to address more sophisticated business requirements using MSCRM 3.0 Workflow Manager.

· The rules related to notification/ assignment and escalation are shown for opportunities. Similar rules can be created for other entities (e.g. – leads, cases etc.) as well by following the examples in the attached zip file.

· It is recommended that you test the workflow rules in a test environment before you put it in production.

Updates to Workflow Best Practices Blog...

crmbest — Thu, 08 Dec 2005 02:45:00 GMT

I wanted to share my plans to update my workflow best practices posts on Microsoft CRM Best Practices blog and seek some early feedback. Instead of creating a new blog entry each time I want to add a new usage sceanrio, I shall simply append the information to the best practices page. I shall also create a hyperlink to newly added entry from the summary table bullet at the top of the page. It will help me keep all information in an organized manner on one page.

MSCRM 3.0 Workflow Best Practices

crmbest — Thu, 08 Dec 2005 02:13:00 GMT

Rule Type	Sales	Service
Trackers	Customer reward points Sales Revenue by Account/Salesperson Excess Discount	Satisfaction Level by Account/Service Rep Number of Escalations by Account/Service Rep
Escalation	Task escalation	Case Escalation
Object Creation	Lead - auto create from incoming e-mail	Case – auto create from incoming e-mail
Alerts	Opportunity Size Lead Assigned	Case Opened Case Assigned Service Scheduled
Time based Reminders	Tasks Approaching Escalation Birthday Reminders for Contacts Opportunity Aging	Cases Approaching Escalation SLAs Approaching Renewal Case Aging
Audit Trail	Changes to Opportunity Estimated Close Date

Setting a Tracker

A tracker is simply a number-based attribute on an entity that captures important information related to that entity. Trackers can be useful for tracking key number-based targets that are important to your business. After the trackers are defined, they can be compared to certain values in order to trigger a predefined business logic or to generate alerts. You can use existing attributes on an entity as trackers or you can create custom attributes to do that based on specific needs.

Example: Reward Point Balance for Account

A certain organization using Microsoft CRM 3.0 would like to reward their customers for large purchases and repeat purchases. One way to reward these customers is to accumulate all the purchases made by a certain customer as reward points. After the reward points exceed a certain threshold value, the customers can be sent a gift card equivalent to a certain dollar amount. The organization would also like to reduce the reward point balance by the same threshold value to compensate for the reward. The system would continue to monitor reward point balances. When the threshold value is exceeded again, the same process is repeated.

To set up the above scenario, you can do the following:

Create a custom attribute of type int on the Account entity, and call this attribute, for example, Reward Balance. Add this custom attribute to the main form under the Details tab and publish the customizations. Open an existing account record to ensure that the field shows up in the UI.
Open Workflow Manager and create a workflow rule on the Invoice entity with a trigger on a Change Status event. This trigger adds to the reward balance on a related account by total invoice amount each time the invoice status changes to paid. Save the workflow rule you created. The rule definition in Workflow Manager would look similar to the following:
Define one more workflow rule on the Account entity with a trigger on a Manual event such that it waits for the reward balance to exceed 10,000 points and creates a task to send the customer a gift card for $100 dollars. This rule waits for the task to get completed. After the task is completed, the rule reduces the reward point balance by 10,000 points. The rule definition in Workflow Manager would look similar to the following:
Open the rule again, and add a subprocess action at the end that calls the same rule again. This makes the rule recursive so that it never stops waiting for reward points to exceed the target. The rule definition in Workflow Manager would look similar to the following:
Define one more workflow rule on the Account entity with a trigger on a Create event such that it calls the “Evaluate Reward Balance” rule defined in step 4. This ensures that each account, at its creation and throughout its life cycle, has the reward balance tracking enabled.

Notes:

Note the use of dynamic text fields in step 4.
You can add escalation rules on the task created under step 3 so that, if the task is not completed within a specified time, for example, by the due date, an escalation mail is sent to the owner’s manager.
Similar trackers can be created on other entities within Microsoft CRM 3.0, including custom entities, based on business needs. An example would be to track the cumulative revenue won by a salesperson and reward him whenever the salesperson’s revenue exceeds a reference value, while updating the reference value upwards by a fixed amount in order to create perpetual tracking for each salesperson.

Setting up Escalations

Escalation is a way to enable pre-defined action if certain things are not completed within a pre-defined time.

Example: Case Escalation

A certain organization using Microsoft CRM 3.0 would like to ensure that all cases logged into the system are processed in a time bound manner. Each time a new case gets created, it gets assigned to a specific owner (using a workflow rule). The owner is expected to complete a set of actions. The owner is expected to update the status of the case to reflect level of completion. Case moves through multiple status codes till it is completed. The organization wants to enable a rule where if a case remains in the same status for more than 1day then it should be assigned to do a different person. The organization would further like to ensure that if case remains in the same status for more than 2 days than it should be re-assigned to a different person again (say Person Y).

To set up the above scenario, you can do the following:

Create a .NET assembly (workflowtestassembly.dll) with following echo function:
public int EchoPicklist( int value )

{

return value;

}

Add the following entry to workflow config file:

<method name="Echo Picklist"

assembly="workflowtestassembly.dll"

typename="workflowtestassembly.Test"

methodname="EchoPicklist"

group=" Utilities">

</method>

Open Workflow Manager and create a workflow rule on the Case entity on a Manual event. Create a condition to check if the case is already “closed”. In that case, no further processing is required. If the case is not closed then define an echo function (using “Call Assembly” action under “Insert Action” drop down) called “Pre-Update Status Reason” and set it equal to the “Status Reason” attribute on Case entity. This will capture the current value under status field. This value is saved in a temporary field allowing us to compare it with value in status field at a later point in time. The rule definition in Workflow Manager would look similar to the following:
Continue editing the rule. Add a wait condition for 1 day and compare the value in echo function with the current value in Status Reason. If value is same, that means that case status has not changed within last 1 day. Assign the case to person X.
Continue editing the rule and add another wait condition for 1 day and once again compare the value in echo function with the current value in Status Reason. If value is same, that means the status of the case has not changed within last 2 days. Assign the case to person Y. Save the rule.
Open the rule again, and add a subprocess action at the end that calls the same rule again. This makes the rule recursive. The value of echo function gets compared to the current value in Status Reason attribute of Case entity on a daily basis. The value in echo function gets replaced daily if the value has changed else it changes after 2 days.
Define one more workflow rule on Case entity with a trigger on a Create event such that it calls the “Escalation Rule” defined in step 6. This ensures that each case, at its creation and throughout its life cycle, has it’s status checked on periodic basis and is escalation to the right person, as and when required.

Notes:

The escalation interval enabled via this process is bucketed. That means that if the value changes within the wait interval the system does not count that time. If you need to be more precise about the wait interval, then the trick would be to define multiple wait conditions with smaller time intervals.
If you need guidance on creation of .NET assemblies, refer to SDK documentation.