The Top 4 CRM Design Pitfalls

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