Thursday, January 08, 2009

Company-Level Data in Demand Generation Systems

I had an interesting email conversation last month with a Raab Guide buyer about the nuances of company-level data management in demand generation systems. He started from the perfectly reasonable premise that the demand generation system should give an overview of activity for all leads associated with a given company. This is a topic we do cover in the Guide, but not in the detail he needed. The conversation has sharpened my own thinking on the subject and prompted a couple of conversations with vendors. I think it’s worth discussing here in some detail.

There are really two separate issues at play. The first is how the demand generation system treats company-level data. This, to start at the very beginning, is data about the company associated with an individual. Typically this is the company they work for, although there might be another relationship such as consultant or services vendor. From a database design standpoint, having one company record that is linked to multiple individuals avoids redundant data and, therefore, potential inconsistencies between company data for different people. (The technical term for this is “normalization”, meaning that the database is designed so a given piece of information is stored only once.) Some of the demand generation systems do indeed have a separate company table: it is one of the marks of a sophisticated design.

But the wrinkle here is that most CRM systems in general, and in particular, also have separate company and individual levels. In fact, actually has two types of individuals: “leads” which are unattached individuals, and “contacts”, which are individuals associated with an “account” (typically a company, although it might a smaller entity such as a division or department). Most demand generation systems make little distinction between CRM “leads” and “contacts”, converting them both to the same record type when data is loaded or synchronized.

The common assumption among demand generation vendors is that the CRM system is the primary source of information for which individuals are associated with which companies and for the company information itself. This makes sense, given that the salespeople who manage the CRM data are much closer to the companies and individuals than the marketers who run the demand generation system. Demand generation systems therefore generally import the company / individual relationships as part of their synchronization process. Systems with a separate company table store the imported company data in it; those without a separate company table copy the (same) company data onto each individual record. So far so good.

However, this raises the question of whether the demand generation system should be permitted to override company / individual relationships defined in the CRM system or to edit the company (or, for that matter, individual) data itself. I have to get back to the vendors and ask the question, but I believe that most vendors do NOT let the demand generation system assign individuals to companies or change the imported relationships. (In at least some cases, users can choose whether or not to allow such changes.) Interestingly enough, these limits apply even to systems that infer a visitor’s company from their IP address and show it in reports. Whether demand generation can change company-level data and have those changes flow back into the CRM system is less clear: again, it may be matter of configuration in some products. The vendors who don’t provide this capability will argue, probably correctly, that few marketers really want to do this and or in fact should do it.

So what information DOES originate in the demand generation system? Basically, it is new individuals, which correspond to “lead” records in, and attributes for existing individuals, which may relate to either CRM “leads” or “contacts”. The demand generation system may also capture company information, but this is stored on the individual record and kept distinct from the company information in the CRM system. When a new individual is sent from demand generation to the CRM system, it is set up in CRM as a “lead” (that is, unattached to a company). The CRM user can later convert it to a contact within an account. But the demand generation system cannot generally set up accounts and contacts itself. (Again, let me stress that there may be some exceptions—I’ll let you know when I find out.)

Bottom line: leads, lead data and contact data may originate in either demand generation or CRM, and the synchronization is truly bi-directional in that changes made in either system will be copied to the other. But accounts and account / contact relationships are only maintained in the CRM system: most demand generation systems simply copy that data and don’t allow changes. Thus, it is essentially a unidirectional synchronization.

This leads us to the second issue, which is company-level reporting. It’s touted by most demand generation vendors, but a closer look reveals that some actually rely on the account-level reporting in to deliver it. This isn’t necessarily a problem, since the report can incorporate activities captured by the demand generation system. Per the earlier discussion, these activities will be linked to individuals (leads or contacts in terms). Of course, if the individuals have not been linked to a company in the CRM system, they cannot be included in company-level reports.

One problem with relying on CRM for company-level reporting is that the demand generation system may have some nice reporting capabilities that you’d want to use. So there is some advantage to capturing the company / individual links within the demand generation system, even if the links themselves are created in CRM. (Not to get too technical here, but those “links” could simply be a company ID on the individual record, even if there is no separate company-level table in the data model. So lacking a company table does not preclude company-level reporting.)

A second issue is that some marketers want to use company-level information in their lead scoring calculations. This is another question we ask explicitly in the Guide, and only some companies say they can do it. Whether they make it simple is another question—some products who claim the facility in fact require considerable effort to make it happen. Again, the vendors who don’t offer this would presumably say that it isn’t very important to their clients.

I hope this clarifies both the mechanics of handling company-level data and some of underlying business issues. It’s one of those aspects of demand generation systems where vendor differences are real but subtle, and where the true importance of those differences is clear only to experienced users. All I can do in the Guide and this blog is try to describe things as clearly and accurately as possible, and thereby help you to make sound judgments about your own business needs.

No comments: