As I prepare for my Dynamics 365 certification in sales (MB2-717), I am creating blog posts based on my revision. I hope that collectively these posts may prove useful to anyone also preparing for the MB2-717 exam. This time I will look at the topics mentioned under the heading “Manage customer records”.
The skills measured statement I intend to cover in this post is highlighted below, as you see it mentions several core record types in Dynamics. So in this post I will review those record types and address the point about “organizational structure” by looking at how the various entities are related.
What is a customer?
Before we dig into the Dynamics 365 specific entities, it might be worth thinking about some of the business terms used in the skills measured statement. We all know (or think we know) what is meant by the terms “customer” and “customer base”. But ensuring our understanding is comprehensive is a good start for our revision!
I turned to Wikipedia for a little help, it described a customer as ….
From this definition of a customer we can learn several things, firstly that many organizations will use different terms for a customer. We should be mindful of this when considering terms like customer, account, contact and lead within Dynamics 365. From the point of view of our revision we need to be clear on Microsoft’s interpretation of these terms. But it will also be useful to appreciate that in many industries we may come across different terminology. For example, I’ve worked with some charitable organisations who steer away from the word customer their “customers” might be known as donors, members or something similar.
Next we learn the diversity of what a customer could mean to us! Customers may buy something you produce but the term “other valuable consideration” hints that this might not always be a straight forward financial transaction. Additionally purchasing can take many forms. A customer may purchase the widgets that you sell. But they could just as easily acquire a service or even simply share an idea. People who subscribe to my blog might be considered my “customers” but there is no purchase involved.
Next I would like us to consider the term “customer base”, again I turned to Wikipedia for a definition ….
In essence a customer base could be simply considered the definition of all of your customers. However the Wikipedia definition also points to a wider concept, as the term “target market” is used. This hints at how sometimes we need to think beyond our current customers and also consider potential ones. Additionally I hope you can see that understanding our customer base is going to need us to define and appreciate their organizational structures.
Dynamics 365 provides us a flexible framework to define our customers and their related structures. Plus the tools and capabilities needed to track and analyse any associated sales cycles. As this blog post progresses I will introduce some of the entities and terms used with Dynamics 365 to describe our current and potential customers.
I’d like to start by describing the lead entity. Later in my revision I’ll concentrate on the sales cycle and how leads are qualified to become opportunities, accounts and contacts. But initially I think it is important to consider what a lead is.
Leads represent “a potential”. This might be a potential sale with an existing customer or a completely new relationship. The lead may be short term, meaning that a sale could result quickly. Or the lead maybe a “place holder” for a potential far into the future.
There are many sources of leads, some common ones are listed below;
- Sales people might manually create leads, maybe based on their knowledge of the potential customer base.
- Companies may purchase and import lists of leads, possibly from market research companies etc.
- You may attend an event and collect business cards from attendees.
- Customers may fill out a form on your website.
- Microsoft Social Engagement maybe used to generate leads by “listening” to social activity.
- Microsoft Marketing may generate sales ready leads as a result of a nurture campaign.
- Etc etc.
Whatever the source(s) of your leads, the lead entity should ideally be considered temporary. (Although in my experience how temporary can vary from organisation to organisation!) A record should only exist as a lead until someone has reviewed / qualified it. Once qualified the lead would be determined to be viable or not. Often disqualification of unviable leads is an essential process to ensure your sales team concentrate their efforts on “real” opportunities.
An opportunity represents a potential sale. Opportunities may be manually entered but will often be created as part of the process of lead qualifications.
Opportunities will be attached to an account or contact record. In some cases the associated account and contact will be completely new but you should appreciate that it is just as common to have opportunities with existing customers.
Opportunities play an important role in the sales cycle (that I will cover in detail in a future post). Opportunities begin as open and can progress to being won or lost. Whilst open the opportunity would form part of your sales pipeline. The length of time a potential sales remains an open opportunity can differ greatly.
I have seen the opportunity entity can be used in a very simple way with it simply being a high level definition of the potential sale. However we can also associate a number of other entities to the opportunity. Including products, competitors and quotations. Additionally any interactions (activities) with the customer can be recorded against the opportunity.
I’ll cover some of the related transactional entities in future posts. As an opportunity can be associated with quotes, orders and invoices as the sale progresses.
Contacts and Accounts
Contacts represent individual people. In some sales situations it is possible to only deal with contacts. An organisation that targets consumers directly may only use the contact entity, meaning the contact can be your customer.
However organisations that engage with businesses may require an account entity. With each account having one or more contacts associated with it. Additionally we have a concept of each account having a primary contact. Often (but not always) the primary contact for an account will be the person who has purchasing authority. Meaning your primary contact might be the person who places orders with you but you may additionally need to hold details of a multitude of other people who work at that organisation.
So what is a customer in terms of Dynamics 365? As described the customer could be a contact or account. You will occasionally see an actual customer field in Dynamics 365. These are “special” lookup fields that can relate to either a contact or an account.
Meaning we don’t actually have an entity called “customer”, instead we have a relationship with either a contact or an account.
Accounts can be a single record but some organisations can be very complex. Maybe they have a head office, regional offices and branch offices. Or separate division that might be all part of the same group of companies but purchase or supply quite different products.
Below you can see how this hierarchy of accounts might be displayed within Dynamics 365. In my example you can see that A. datum and Fourth Coffee are both accounts that fall under Tailspin Toys. Also notice that the structure can have many levels, demonstrated by the fact that Litware and Fabrikam are linked to A.Datum.
This kind of organisational structure view can be displayed by clicking the hierarchy icon (shown below).
We link accounts in the hirarcy using the parent account field. So in my example above, A. Datum is the parent account of Fabrikam, And Tailspion Toys is the parent account for A. Datum.
Each account in the structure can have a different primary contact. And account can also have its own list of other related contacts. You should be aware that each contact can only be linked to one account but one contact can be the primary contact for multiple accounts.
When we create a new contact directly from the account form certain key fields such as the accounts address and telephone number will be used as defaults on the newly created contact.
At this point in your revision I suggest you create a few accounts and contacts, plus build an organisational structure by setting the parent account field. I hope you will quickly see that it is easy to define your customers and customer base.
3 thoughts on “MB2-717 Certification: (Microsoft Dynamics for Sales) – Customer Records”
Thank you Neil, another great post!
Can you comment on what to do when the customer is a person but an Account Entity is required in order to serve the customer through Dynamics 365 for Field Service?
LikeLiked by 1 person
I have known this question to up before! Unfortunately Field Service only has a concept of service account.
Meaning each person needing field service might need to have an account created.
Or enter the persons details directly onto the account entity. Meaning effectively that account is used as contact.
Either of these approaches could be considered a compromise but as Field Service only supports accounts the we have no vh
Thanks Neil…I have been puzzled about how to handle this one for a while!