Business processes are intertwined with the workflow rules discussed in detail in Chapter 9. In this chapter, we discuss some of the basic principles involved in designing your processes and how you can implement those design principles in Microsoft CRM.
In the almost 20 years that we've been designing and implementing CRM systems (not always Microsoft CRM, of course), it has been made clear again and again that two basic features allow CRM to earn its keep. The first is its ability to consolidate an entire organization's data into one useful, shareable place. Don't underestimate this.
The second is its ability to automate business processes. The implementation of workflow not only forces you to think about — and then continuously rethink — your business processes but also allows you to replace notoriously inconsistent human activity with automation that always follows the rules.
Sadly, more than 90 percent of CRM implementations never achieve that automation. That initial goal seems to get lost in the effort to get the system up and running and the staff using the software. Too often, we're out of energy and money to invest further in developing the workflow that really makes the investment in CRM pay for itself. If you want to maximize the value of your system, however, don't allow yourself to run out of resources before you finish the entire job.
A good process guides your people through a series of well-documented steps for almost every type of situation. For example, although you can do a quote before properly qualifying an account, any well-thought-out system discourages this. Or you may remember to call a prospect back after sending a quote, but a good workflow-based process won't let you forget.
Earlier in the book, we discuss in detail how to implement one of your well-thought-out processes in the Workflow Manager. (Actually, it may not be one of your well-thought-out processes, but it might be similar to one of yours.) Please refer to Chapter 9 for a refresher on workflows.
In this chapter, you find out how to plan your sales stages and how to relate these sales stages and other processes to your CRM system. You also discover the basic principles of process design and how these affect the design of your overall CRM system.
A good business process includes the concepts of alerts, escalation, feedback, and analysis. We describe each of these principles in this section.
An alert, which is often an e-mail notice or some kind of screen pop-up, is called for when an activity should've been completed but for some reason wasn't. For example, if you've obtained verbal approval and the prospect promises a written purchase order within a week, the system should alert the account manager 10 days later if that purchase order hasn't arrived. (If you're a Type A personality, you may want to adjust your waiting period to 10 minutes.) Please refer to Chapter 9, "Managing Workflows," for an example of setting up a workflow rule.
Alerts are appropriate also as a warning that an upcoming activity is almost due. For example, you might want a polite warning 30 days before a client's annual contract needs renewal.
Depending on the number of alerts you anticipate, you may decide on individual e-mail notices for each alert, or you may want a single e-mail or report that contains all the alerts. For example, you may set up a Workflow which e-mails you a list of overdue purchase orders at the end of the day. A typical sales alert might be to let a manager know on the 18th of the month that a forecasted sale that was slated to close on the 15th hasn't closed yet. If you expect more than two or three of these alerts, you'll be better off planning to put them in a consolidated report that the manager receives. Otherwise, you risk clogging up your manager's in-box with dozens of these warnings, which he or she will soon learn to ignore. KnowledgeSync, discussed in Chapter 27, is a third-party alert messaging application. This is one tool you could use to display on-screen pop-up alerts.
When something doesn't get done on time, someone needs to know. Now, you can do this properly, or you can do this in a way that gets everyone upset. Escalations are typically done by e-mail notices, by automatically scheduling activities, or by some combination of the two.
Typical activities that deserve escalation are sales that haven't closed when predicted or customer support issues that haven't been resolved in a timely way.
To be fair, the first step in escalating any issue is to notify the person to whom the issue was originally assigned. There might be a perfectly valid reason why the issue hasn't been resolved, and you should allow the original person to resolve it.
An administrator could set up a Workflow rule which automatically schedules an activity or sends an e-mail when a scheduled activity is overdue. Please refer to Chapter 9 on setting up a Workflow rule.
If the task or issue still hasn't been resolved within a few days, a notice should go to the original person's manager.
Note
CRM can't send a notice to the manager unless it knows who the manager is. Each user's record has a field for the user's manager's name. Escalating issues is probably the best use of this field. To see users' managers, simply click on Settings on the main navigation pane, click on Administration and then click on users. You will be presented with a list of all configured users. Simply double-click on any user to see his or her Manager.
The typical steps of an escalation plan are as follows:
Test to see whether an alert is required. You could do this by setting up a Workflow rule scan for any incomplete assigned tasks. (Refer to Chapter 9 on how to set up Workflow rules.)
Send an initial alert to the primary user. You could do this by setting up a Workflow rule to send an e-mail to the primary user.
Wait a reasonable period (one to seven days, for example) and test again. If the issue still isn't resolved, escalate to the primary user's manager.
Test again a reasonable time later. If the issue still isn't resolved, notify the manager's manager. Continue this notification until you run out of management levels. Adjust the waiting period between notifications as appropriate. You could do this by setting up a Workflow rule to send an e-mail to the manager's manager if the incomplete task has not been completed after so many days. In this example, you waited up to seven days to notify the primary manager (step 3), you could wait an additional seven days to notify the manager's manager.
Each time a manager is notified, all users who received prior notifications should be copied.
It isn't a good process unless you can measure it. Losing weight is a process. Before you start that process, you undoubtedly weigh yourself and continue to do so as you work toward your desired weight. Without measuring, you don't know how well you're doing, and you can't make midcourse corrections. Business processes are the same.
If you're implementing a sales process with a focus to move each sale from one stage to the next, you want to measure a number of factors. You probably want to know:
Where and when the lead originated. The purpose of tracking the source of each new record is to be able to better allocate your marketing dollars by determining which lead sources are best.
Who is working on the lead. Aside from wanting to give credit where credit is due — that is, commissions, bonuses, or a pat on the back — you also want to identify salespeople who may be having problems with particular types or stages of sales so you can correct these problems.
How long it takes to get from each stage to the next. If your sales are bogged down at a particular stage, you want to know that and make corrections to your process or workflow.
Microsoft Corporation and Microsoft CRM both follow the sales process called Solution Selling, which was originated by Sales Performance International. If you haven't taken one of the classes, read one of the books that provides an overview of this sales philosophy. We're partial to Solution Selling: Creating Buyers in Difficult Selling Markets, by Michael T. Bosworth (McGraw-Hill).
If your company already has a sales process other than Solution Selling in place, that's okay. Microsoft CRM has enough flexibility to allow you to configure almost any kind of process.
Your organization undoubtedly needs more than one process. For example, if you sell software and technical support, the associated sales cycles and techniques are different, and you'll want a process for each type of sale. Also, you may need a different sales strategy just based on the size of the potential deal or even the size of the prospect. For example, you would sell 2 pounds of nails to a homeowner in a different manner than you would sell 200 tons of nails to a home improvement store.
In CRM, sales processes are associated with opportunity records. Although you may consider the sales process to begin when you enter a lead, this isn't the case. The process can't begin until you convert a lead to an opportunity, which we tell you how to do in Chapter 12. We distinguish a lead from an opportunity the same way we distinguish a suspect from a prospect. It isn't an opportunity or a prospect until this potential customer expresses some interest in your products or services. After that happens, you may have an opportunity, and it's time for the sales process to begin.
No immutable laws govern the development of a sales process. The sales process police won't be knocking at your door if you have too few or too many stages, but sales processes do have a few guidelines.
The more complex or the longer your sales cycle is, the more stages you'll need to describe where each deal is in your pipeline. However, the more stages you program into the cycle, the more likely your salespeople will object to being forced to enter unnecessary data or take unnecessary steps. So, the simpler, the better — with an eye toward gathering good information about where sales bog down or at what point a particular salesperson begins to struggle.
In Table 18-1, we present a typical sales cycle. Before you can begin to implement CRM's workflow rules, you must define your process. Start with the table and compare it with your own existing sales steps. Chances are, you don't even have a well-documented set of steps. Now's the time to begin creating that system.
Table 18.1. Typical Sales Cycle
Stage | Description | Probability | Comments |
|---|---|---|---|
1 | Prequalify | 10 | Make sure it's the right kind of client. |
2 | Initial meeting | 20 | This can be a phone call or a physical appointment; probability increases to 25 if the prospect comes to your office. |
3 | Qualified | 30 | Not only are they interested, but their timeframe and financials make a deal possible. |
4 | Demonstration | 40 | This is show and tell at their place or, even better, at yours. |
5 | Quotation or proposal presented | 60 | There may be several of these, and you may go back and forth from stage 6 to 5 more than once. |
6 | Negotiating | 75 | Always be ready for some give and take. |
7 | Verbal approval obtained | 85 | This isn't as good as a written purchase order or a signed check. |
8 | Purchase order received | 99 | It isn't a done deal until the money arrives. |
Select your simplest product or service and compare the steps you use to the steps in Table 18-1. Then create a table that best follows either the steps you're taking today or, better yet, the steps you think you should be taking.
Before you just jump in and begin programming the workflow rules described in Chapter 9, you need to organize your thoughts. Convene a brainstorming session with the users who are involved on a day-by-day basis with each process you want to automate.
The result of that brainstorming session should be a detailed outline or diagram of the process. Each outline needs to include, for each step:
The action that will be taken
Who will be responsible for that action
What will trigger the action (for example, a change in the data or a missed appointment)
How to escalate if the action isn't completed
After you set this up for each step of the process, it's time to go to Chapter 9 and begin making your new process happen.