These top-4 CRM defects are design-caused, not the fault of implementation. Each pitfall come from a myth, which is perpetuated by both consultants and IT professionals who often implement CRM without experience or skills in good application and database design. All too often the root cause is the hiring of a CRM mechanic to engineer the next generation CRM machine, or DIY, incremental design… failure at some level is baked in. Architecting is not about the CRM brand; these principles apply to SAP, Saleforce.com, Microsoft Dynamics, and all systems in the solution space. These principles are universal.
Warning: there is plenty here to offend all but the humblest IT or business professional. We mean no insult, but rather we want you to get real answers to real problems. If you are ready for a change, consider these pitfalls and how to correct them.
Myth 1 - Accounts: “CRM is not the system of record for customer account management. The controlling system is ERP. Therefore, CRM accounts are an appendage of ERP, where all accounts are managed (here we are referring to account as the definition of a business or organization, not as a profile set up in an application, like a “LinkedIn account” or “ecommerce account”).”
This is one of the most frequent fallacies I hear from sophomoric CRM consultants; and I hear it often. I also hear it repeated from corporate IT lieutenants. They will confidently indicate their belief that an ERP or billing system is the proper system of record (SOR) for the notion of a customer account. This is wrong.
The way to so solve this is to ask yourself a few simple questions. 1) what is the overall purpose of a CRM solution? i.e. what processes does CRM enable? What is its mission as a business application? 2) what is an “account”? how do you define it from the intent and capabilities of CRM vs. ERP?
Once you obtain answers to these questions, you will learn the answer for yourself.
To CRM in the B-B model, an “account” (or a group of accounts in a hierarchy) represents a real-world business or organizational unit that your sales team recognizes as a decision-making enterprise with its own value proposition, that could buy products and services from you.
To ERP in the B-B model, an “account” is a place to send an invoice or a source of payment, like a bank account. Sure, it wants the legal name…that’s for legal billing purposes, but the ERP/Billing/Accounts Receivable application (or applications) only needs to know how to recognize order, invoice and payment transactions. These accounts are not businesses; they are comprised of a combination of a legal name + a billing address + a shipping address + credit terms, and sometimes a bank account. This could just as easily be paper company that exists for tax purposes in Bermuda but has no employees other than a lawyer and an accountant. Or it could be a warehouse in some remote area as a shipping destination.
But this definition is a terrible way to manage sales and marketing processes, the efforts of which want to recognize organizational groups around brands, market categories and decision-making business units. One ERP account can serve many customer accounts. And one customer account in CRM can ship to and bill to many ERP accounts. To see revenue and margin attribution at the CRM account level, you will need to assign the CRM account ID to the sales transaction along with the ERP account. Assigning transaction based attribution can have tremendous implications to improved sales incentive attribution as well.
Moreover, CRM is obligated to contain the accounts that are not (yet if you are optimistic) customers. We call them prospects, and this pool of data is generally larger than your customer base. It is the unconverted marketplace. They are accounts because they are businesses, but ERP/billing has no business managing them. When a sales process reaches the point where a CRM prospect account needs to receive approval to extend credit or track invoices, then a billing or ERP account can be created and matched to CRM. And the CRM account can share data with the ERP account. For ecommerce, the process is initiated on the ecommerce system, where typically the ecommerce account is established first and the CRM reflects it. However, CRM then becomes the hob for omnichannel commerce and interaction.
So, how do you integrate these systems so each billing account in ERP can provide segmentation and meaningful weight and predictability to the CRM business account? Contact Ascendant Group to find out how to manage a blended data architecture. See also: https://www.ascendant-group.com/post/erp-vs-crm.
Myth #2 - Leads: “A Lead is a business that is not (yet) a customer. Leads are accounts and contacts that are separated from customer accounts and contacts.”
This definition is a big mistake, and again many small-time consultants will lead you astray. The problem is one of semantics and the resulting database design.
To many businesses, the word “lead” is used to describe any account not converted to a customer. But if this is the definition of “lead”, you will have no place to go with your inquiries, referrals, and marketing responses that allow you to track processes and conversions; no place to manage efforts to move from “potential” to final conversion – commerce. And you will be fragmenting your database “types” into different tables, violating the fundamental database concept of representing the same data species in the same table. This is just a mind trick because the root cause is semantical, and sadly most CRM consultants are easily tricked themselves.
Let me explain. As above, an account is a business or org unit. And as above, an account comes in two relationship “kinds”, 1) a "prospect" (which we will define as any org that is not recognized as “doing business” in any meaningful or recent manner), and 2) a "customer", which is an org that is currently engaged in commerce, or has a recency status and expectation of possible reselling likelihood or servicing obligations. We do not want to use the term "Lead" here, because a lead is a process record that can track a qualification progression on behalf of either a customer or a prospect.
If you are an effective marketer, your CRM should already contain as many prospective accounts (prospects) as you can possibly manage, and you would already be targeting them and tracking messages and interactions.
Okay so, accounts can be prospects, and prospects are always accounts (with contacts...see below). So, what’s a lead? Well, to the marketing team, prospects are non-customer targets of messaging, whether messages are digital impressions or print or broadcast or event or social or email…all prospects are message consumers. For new customer acquisition, this audience is prospects (accounts), whereas for retention, CSAT and cross-selling the audience is customers.
But what happens when a prospect pops its head up as an initial “conversion” in a marketing or sales process and as a potential buyer (the much valued MQL-- Marketing Qualified Lead")? This is is the time when you create a "lead" record, not as a substitute for a prospect (the prospect account should already be in your database), but as a process-tracking and conversion-measuring record. The lead begins life as an ambiguous referral, response or inquiry. Generally, the prospect of a lead process is aware they are “a lead” since they are exploring commerce. But the lead itself is just a process record, and that record is joined to the more stable prospect-account as a child record of the account (this is because any prospect can be a lead in the future if the current lead process fails).
Here is where some consultants will double down on failure and insist that a lead record is the separate and distinct holding place for a prospect (even though it shares all data attributes with an account record) and they will steer the business to use a record type called “opportunity” for the sales process. The big problem here is, an opportunity is a committed, forecastable sales process. But before that, the process is a Lead. What’s the reason for this distinction? To save precious sales resource time and to separate the signal from the noise.
A lead has a 3-part mission (and only these 3). 1) disambiguate/articulate (validate the lead is viable and identify the account that is the participant), 2) show attribution from marketing efforts to the converted event of a target responding or interacting, and 3) qualify the prospect as being the potential recipient of value. It is a canvass for early process of identifying and qualifying the target...that's all it is. After that, the lead can become (transition or convert to) a quote (quote is a fast track process) or an opportunity (opportunity is a longer-lived more complex sales process). Quotes and opportunities are forecastable. Leads are not. Leads are very short-lived (or certainly should be since they tend to get cold quickly). Quotes have short or intermediate lifespans. Opportunities can go on for weeks, months or years. In short, leads are initial process records that can convert to quotes or opportunities. They are not temporary independent holding places for accounts and contacts (they link to accounts and contacts, many leads to one account).
Notice, the lead is the beginning of a hoped-for quote or opportunity, but many wannabe deals fall away and do not convert because they are in some manner “unqualified”. We never recommend making every effort into an opportunity, or you will entrap your sellers with too much data entry and false forecasts. But beware of the consultant who leads you astray. They are legion.
Myth #3 Contacts: “B-C models do not need accounts, only contacts.”
This problem does not typically appear in the B-B space unless the business is not enforcing account to contact parent-child relationships (which would be a different kind of tragedy).
In fact, all contacts in all models can benefit from a relationship to an account data object. The account groups contacts into a decision-making, geo-locatable, or value-consuming unit.
What is this unit in the consumer world? It is the household, or residence. Some think it’s the family but that is not right. Family is a cluster of relationships. A household it a grouping of consumers who share consumables and demographics.
Often people who live together have a decision-making relationship or are affected by the buying transactions of each other. Families can life far apart and have no regular interaction. Often people who live together can be grouped into a single group purchase or cause the selection of the value proposition to include the presence of the others or can offer potential for a cross-sales type of sales-process.
Now to group all contacts into accounts for B-C can sometimes seem annoying since many consumers are solo, and it just seems odd to separate attributes into a household when you are only aware of and concerned with one member of the household. Wouldn’t it be easier to just show all attributes of the household on the consumer record?
Well, yes, until it starts to cause problems, since any model in which it makes sense to group other household members into one unit cannot be rationalized when residential data is fragmented across contacts. You will end up with overlapping and conflicting data for address, geo, household demographics, payment accounts, and decision-support relationships.
Ascendant Group’s recommendation is to improve the CRM user interface to join the data from account and contact so some account information can be managed from the contact or directly from the account. But organize household data in the account record and personal data in the contact record. This is not to say that contacts at different households don’t have relationships; they do. These can be managed with other connection-style (many to many) relationship management records (such as for 3rd party pay or POA).
Myth #4 Channels: "Ecommerce is the SOR for digital customers and CRM is the SOR for traditional customer channels"
This is common and unfortunately short-sighted design philosophy to espouse. It truly goes against everything we believe in as practitioners of omnichannel sales and marketing, and the mission of CRM as the SOR for all customer and revenue management.
This view typically holds to the best-of-breed notion that each business unit and sales channel can have their own customer base, and the only concern other than this is to join the data into a data warehouse, where some expensive data techs will rationalize the customer base and join the disparate data. This is suboptimal for many reasons.
First, the idea of synthesizing and tracking sales and marketing transactions to a single enterprise application supports the quest for omnichannel business processes where data is integrated and shared in a natural everyday business process time frame. Data can be presented when needed, as needed in a holistic manner between channels. So, if an ecommerce customer is the same business or household as a call center customer or a retail customer, there would be one master application sharing this data in near-real-time. That application is CRM. CRM would gather all transactions and channelized “accounts” to a single master “customer”. This way an abandoned cart can be treated with call center resources; a call center resource can recommend items for client’s shopping cart and be available to reinforce customer ecommerce decisions at a later time, placing notes into the customer’s ecommerce “account”, and the customer’s social profile and correspondence can be influenced by sales or marketing. You don’t want to depend on a data warehouse for this.
Bottom line: integrate all data sets for all channels related to prospects and customers into CRM. Let CRM synthesize, organize and use powerful AI tools to obtain a 360’ view of the customer. Use CRM to spin up campaigns, sales initiatives, pricing models, offers and segmentation. Then deliver the messaging across the integrated channels of ecommerce, ERP, marketing automation, digital and social media.
For our clients who are too invested in a landscape of “best of breed” applications where they cannot change the design easily but want the benefits of this holistic CRM-type approach, we strongly recommend a CDP, and not the use of a Data Warehouse to do the job of joining marketplace information and making it available on demand to all channels.
Summary: changing course will mean changing vocabulary and process and the user experience. Change is hard. We can apply a lot of best-practices to make it easier for your business to optimize, but there is a cost to change. Evaluate the benefits against the costs.
Contact us at info@ascendant-group.com to learn more ways to avoid pitfalls and optimize your CRM.