CRM 2016 Sales Module Overview

The Dynamics CRM 2016 sales module

Dynamics CRM is split into several different predefined modules. The modules were represented as a vertical navigation area in CRM 2011 and was reworked into a horizontal, partly collapsible navigation bar in CRM 2013. Starting with CRM 2015 SP1, which was only available online, and now in CRM 2016 the horizontal navigation bar now expands to reveal both areas as well as related entities.

Today I'll go through the sales module and what's included out-of-the-box. I won't be doing a thorough walk through of each entity and all it's possibilities, but I'll touch on what I find the most useful features and how they are intended to use.

Dashboards, dashboards, dashboards

I've always been a big fan of dashboards, and like previous versions MSCRM comes with a bunch of them available straight out of the box. The predefined dashboards are based on common use patterns and include several useful views and charts. In fact, many users find that these dashboards fits to their established work pattern and don't even bother to customize them. Though I find that thought alluring, I think most will gain from looking into views and filtering to make it a perfect fit for them. After all, customizing CRM when you get used to it is both easy and fun, because it shows you the results right away and has snap-to styling which alleviates the need for design.

Now I'm an idealist, so I believe that users will find the best way for them to work with a system given time and familiarity with the applications, but MSCRM is huge so it's important to give them the best possible baseline to work from. Having the same baseline also helps when another user has to step in when someone is on sick leave or taking a holiday, as well as designing help and training materials for new employees.

That's why I like dashboards, because it enables you to design a work space for your users that will give them immediate access to the items they work on, whether they're looking into leads, opportunities or sales orders, with the tedious searching and sorting already taken care of. This puts responsibility on the stake holders to invest the time and resources needed to find out how the users of your company works, and analyzing those behaviors and habits to design a system which helps them be more effective, without having to force everyone to do everything the same way.

I recommend that you take some time to check out the dashboards that exist, and maybe write down which parts of the dashboards catches your eye the most. By analyzing which views and charts gives you actual insight and which ones that are more "eye candy-ish" you'll be well on your way to start designing your own. I will be doing a whole blog post, or maybe even a series of blog posts, on designing dashboards and defining use cases.

What's new

What's new is a list of the most recent posts. Posts are wall entities that are connected to activity records, and can be manually or automatically created. Automatic creation happens through autopost rules which can be configured. I will be going through this in my customization posts in the (hopefully) new features.

It can be embedded both into entity forms through the social pane and directly in dashboards, so if this is something which is relevant to your company you might want to consider integrating it.

Account and contact

 

This is usually the basis for all of your CRM content. In most cases all parts of CRM is either supposed to be connected directly to one of these, or designed to support the use of them. Whether it's sales orders, support cases or SLA's it's all based around a customer base consisting of accounts and contacts.

Many retail customers decide to use only contacts or only accounts, deciding either to connect everything to contacts or customizing the account entity to support retail customer information. I usually recommend persons are created as contacts, and if you're retailing then create a retail account for your contact and add a custom option set to the account which indicates whether it's a company or a person. This is simply because personal details are "flimsy". People change their name, phone number(s), address, email, etc. Using accounts for orders and cases and so on allows you to check if a seemingly new customer might have existing orders, cases or whichever other entities you use. Contacts often get duplicated, and you'll often get new leads based on email addresses they haven't used before or missing middle names etc. Not to mention, people have the same names, so using this technique allows you to have similar names for contacts, which most likely is the field you'll be using in your views/lists, but with unique account names.

I just want to underline that this in no way is a de facto standard, and there are probably many who will disagree with this design, but I'm sticking to "my beliefs" until someone convinces me otherwise. I'd also like to point out that in CRM, both Account and Contacts will be available in the "Customer" lookup, but that's also the reason for my recommendation.

Many retail customers decide to use only contacts or only accounts, deciding either to connect everything to contacts or customizing the account entity to support retail customer information.
I strongly advice to use accounts and contacts as intended, which is exactly as they are described. If you're retailing and customers need to open an account, and they can add several members to that account (for example family members), then you add both contacts and accounts. You could add a option set to the account to specify whether it's a "company" or an account for a customer.
This is particularly true for Dynamics365, which is right around the corner (at the time of writing).

Lead

Here is one of the first steps where implementations starts to deviate from the proposed and even advised usage. A lead is an unqualified opportunity. That's all there is to it. No ifs or buts, it's just a potential, but you haven't qualified the potential at all. It could be someone who's registered on your homepage or a tip from another customer, but it's nothing more than an unqualified opportunity. You can create a new contact and/or account from a lead, and then you can either qualify or disqualify it for an opportunity. There could be a question about what qualifies a lead, you might not want to add a person who has subscribed to your company blog as a lead, but if someone contacts your company and says "I want to buy product X" then that's already past a lead, that's already at the opportunity stage or even order stage in the case of many retail customers.

You might wonder why that's important, and that's simply because Microsoft is designing a lot of functionality around the in-built entities, so if you start using leads, opportunities or anything else for things they weren't designed for then you might miss out on cool new features when the next update comes around.

Opportunity

The opportunity entity is used for working on a proposal for a customer. It could be a qualified lead or it could be a raw opportunity created from the overview. What's important to know about the opportunity is that it should be qualified, meaning that it could only be won or lost. That's the only status options available, and the only possible outcomes if you use the opportunity like it's designed. For example, "I have an opportunity to sell this company my products or services, either they'll buy from me or they won't. They might come back later or request multiple quotes, but it's either a sale or not." If you think about it this way then an opportunity can only be won or lost, and losing an opportunity does not necessarily have anything to do with the performance of the seller.

During the opportunity phase you present the customer with one or more quotes, and if the customer decides to buy then you convert the quote(s) to a sales order, and at that time you close the opportunity (when the last order is placed). When an order is placed you have won the opportunity, whether it's actually paid or not.

Please note that MSCRM is just that, a customer relations management system, it is not meant as an accounting system. There are other, great Dynamics products which can solve your accounting needs, as well as other providers that can be integrated with CRM.

When working on an opportunity it is often recommended to use a business process flow (BPF), a feature introduced in CRM 2013 (and largely improved since then). I will be doing a future blog post on best practices and possibilities for using BPFs in your CRM system. I will also be going more in-depth in regards to using opportunity, with focus on developing, proposing and identifying factors like competitors, stake holders, etc.

Competitor

Competitor is pretty self-explanatory. It's an entity used to create competitor records that can be used in opportunities to identify who you're competing with.

Quote

Quotes are used to present a customer with a solution. It is tightly integrated with both opportunities and order lines. You add a number of order lines, costs and description inside a quote, present it to a customer (for example through automated emails), and if the customer accepts that quote you can convert it directly into a sales order. When a quote is created you can add information like address, order lines, discount, etc. When the quote is finished and ready to be presented you click the button to activate it, and at this point you're not allowed to rework it. This is a way to make sure that a quote does not get worked on from the moment it is presented to the customer and until you either retract it or get a request for revision from the customer. At this point you can simply click the revise button to edit the quote details and/or order lines, and present it again.

Do note that closing a quote also allows you to create a new, revised quote.

If the customer accepts the quote you can create a sales order directly from the toolbar, which will include all the details that originally was in the quote.

Here's one of the points about what I mentioned earlier about what won means in Dynamics CRM. When you choose to convert the quote to a sales order you can set the opportunity to Won at the same time. This is because as far as CRM is concerned, a sales order means a sale has occurred, which also underlines how quotes and sales orders are supposed to be used. Do not create a sales order before the customer has confirmed that the quote will be purchased.

The quote has a lot of different features, and I highly recommend using it. I will be doing several posts on customizing the sales area to fit customer needs, where I'll go more in-depth into the quote and sales order entity.

Sales order (or just order) and invoice

You can think of the sales order as an extension of the quote, and invoice as an extension of a sales order. They both contain the same information as the quote, and has the same connections as the quote.

Remember not to fulfill an order before all the invoices have been paid. Even partial fulfillment will close the order, and at that time you can't go back to open (without cheating, but we're not gonna go into that in this post).

That's another reason for closing an opportunity when an order is created. Because the order should be active until all invoices are paid there's no need to keep the opportunity open, because it has been won and you're finished with it. For many companies there will even be different teams working on opportunities and sales orders, so just close that opportunity as soon as possible after the order is created and start working on your next prospect!

Also take note that you can, and should, lock the pricing. This is because as soon as an order is placed you've probably agreed to the price, and at that time you shouldn't allow the price to be changed through recalculation when the unit price changes or the currency conversion rate changes.

Product

The product entity has a lot of capabilities, and needs to be thoroughly thought through and planned before you start implementing any. There's a lot of possibilities, among them bundling products, product properties, price lists and on it goes. That's why I'm saving it for another post to keep the length of this one manageable. 

Sales literature

The sales literature is an entity for creating a wide range of different sales literature. It has many predefined types, like spreadsheets, general sales literature, price sheets and manuals. Sales literature should have attachments that could be used by your sales people to read up on, or product manuals that you can attach to emails and provide your customers with.

It's also connected with competitors and products, because sales literature will probably be directly relevant to either a single or a series of products, and you might have competitors who provide the same or similar product.

The usage of sales literature varies a lot from company to company, but it is a great way to gather information about your products and offer a way to give your sales people the newest presentations and general news for your products. Combine this with mobile clients and they'll be able to answer customer requests on the go, or even directly in meetings if the need arises.

You could also create sales literature for a campaign you're running, for example price sheets, or products you're only offering for a limited time, and specify an expiration date. You can also set an expiration date to products that for whichever reason aren't available anymore, in case you still want the literature available.

If you have literature for products that your own employees either have created or have the main responsibility for then you can set up an employee contact. This gives your users an easy way to find the correct contact person when they have a question about the manual or suggestions for revision.

The wrap-up

You made it to the end! The sales module is quite large, and we only covered the entities primarily used for sales in this post. There are several others, like goals, quick campaigns and alerts that are used across several of the modules in Dynamics CRM.

Using the sales module the way Microsoft has designed it allows you to work effectively with a work surface you're already familiar with. I think it's a great product, and hopefully this post has made you feel the same way if you didn't already.

Stay tuned for more posts on Dynamics CRM, in February I'll be doing several posts on configurations in CRM On-Premises and Online, and I'll finish strong with some posts on migrating from the former to the latter.

Until next time, happy CRM-ing!