More than anything else, this exercise reinforced my understanding of how hard it is to answer a seemly simple question about a software product’s capabilities. My original approach in the Guide had simply been to ask vendors whether they had a separate company table in their system. In theory, this would imply that company data is stored once and applied to all the associated individuals, and that the demand generation system could aggregate data by company, use that data to calculate company-level lead scores, and change which company an individual is linked to. This turns out not to be the case. So I had to specifically ask about each of those capabilities, and even those questions don’t necessarily have simple answers.
This type of complexity is why I’ve always avoided simple summary grids that hide all the gory details. I’m perfectly aware – and people remind me quite often, should I forget – that most people find the details overwhelming and really just want a simple way to sekect a few systems to consider.
But it just doesn’t work that way. Yes, you can screen on non-functional criteria like cost, technical skills required, and vendor stability (not that those are exactly simple, either). But let’s say that leaves you with a dozen vendors, and you use some gross criteria to select the top three. If it turns out once you drill into details that two are missing some small-but-critical feature, you have to either go with the one remaining or start the process again with another set of candidates.
Starting again would be fine if you had the time, but let's face it: here in the real world you'll be under pressure to make a choice and will probably just choose whichever vendor remains standing. This isn’t necessarily so terrible, although your negotiating position will be weak and you might have missed another, better product.
But what if all three vendors fail on one detail or another? Now you’re really in trouble.
The only way to avoid these scenarios is to review the details up front. Thankfully, you don’t have to review all the details, but can limit yourself to the details that matter. Of course, this means you have to know what those details are, which in turn requires still more preliminary work. I was going to (and still may) write a separate post about this, but basically that means you have to lay out the details of the marketing programs you expect to execute with the system, and then identify the features needed to support those programs.
The good news here is you’ll need to lay out those programs anyway once you start using the system, so this is just a matter of time-shifting the work rather than adding it. Of course, doing more work now isn't easy, since you probably don't have a lot of free time. But knowing what you need will actually make the project go faster as well, so the payback will come fairly quickly.
So, the bottom line is that you really do need to look at product details early in the selection process. That said, I do think it’s possible to produce summaries that are linked to details, so people can more easily screen vendors against the summary criteria and then only look at the details of the most promising. I’m working on incorporating something along those lines into the Raab Guide.
Ok, now for the company-level data itself. Here are the questions I asked, with summaries of answers from the five vendors in the current Raab Guide (Eloqua, Manticore Technology, Market2Lead, Marketo, Vtrenz) plus two I’ll be adding shortly (Marketbright and Neolane.) As usual, even though I’ve looked at these products in detail, I’m ultimately reporting what the vendors told me. ("SFDC" stands for Salesforce.com.)
Question | Eloqua | Manticore | Market2 | Marketo | Vtrenz | Market | Neolane |
Is there a distinct company table linked in a one-to-many relationship with individual records? | yes, link set by Eloqua | no | yes, link set by SFDC | yes, link set by SFDC | no | yes, link set by SFDC | yes; typically use SFDC link but client could set own |
Are changes in company-level data copied to CRM company (account) records? | yes, if client chooses | no | no | not now; next release will allow client to choose | no | yes, if client chooses | yes, if client chooses |
Can the demand generation system establish or modify company-to-individual relationships, and have these changes apply to CRM records? | yes | no | no | not now; | no | no | yes, if client chooses |
Do demand generation reports give a consolidated company-wide view of activities (i.e., combined activities for all individuals associated with a company) | no; available in SFDC | no; available in SFDC | yes | no; available in SFDC | possible with special effort | yes for Web activities | yes |
Can demand generation lead scores be based on company-wide data (i.e., create a company-level score in addition to individual level scores)? | yes for attributes, no for behaviors | no | yes | yes | no | yes | yes |
If company-level scores are possible, can they be created within the normal score-building interface? | yes | n/a | yes | yes | n/a | yes | yes |
As you see, the answers even at this level of detail are more than simple yes or no. In the case of the first question, which is a restatement of the original question about whether a separate company table exists, “yes” answers must be extended to clarify whether the link between that table and the individual records is imported from Salesforce.com or can be set within the demand generation system. I explored this in most depth with Marketo, who clarified that any individual NOT linked to a company by Salesforce.com will be given its own company record (a one-to-one relationship), even if the database contains several individuals from the same organization. Users can edit that company data, but not the company data imported from Salesforce.
Market2Lead and Marketbright also use the company data and links imported from Salesforce.com. But while Market2Lead matches Marketo's policy of not changing company data in Salesforce.com, Marketbright lets clients determine what do to a field-by-field basis and actually have rules for different cases for the same field. (For example, you might want to let a demand generation user add data to a blank field, but not overwrite data where it exists.)
Just to add a bit more confusion: Marketo itself is changing its system to let clients decide during implementation whether to let users to override the Salesforce links and company data. Apparently some Marketo clients really wanted to do this, while others were firmly opposed.
The other especially knotty question is the one about company-level lead scores. All vendors with company tables can generate scores based on the data attributes in the company records. But I had also intended that question to include aggregate behavior of all individuals associated with a company – such as total emails opened or the date of the most recent Web site visit by anyone in the group.
Eloqua volunteered that they couldn’t do this, which I appreciated. The only other vendor I explored this with in detail was Marketo. They can in fact use behaviors in company scores, but only for individuals linked in Salesforce.com and only by using separate rules to assign points to individuals and to companies. That is, a Web download would have one rule to assign points to individual-level scores and another to assign points to the company score. This isn’t quite the same as building the company calculation by examining each individual independently . For example, Marketo's method can't limit the impact of a single hyperactive individual on the company score.
This is pretty picky stuff, but that’s exactly the point: people who really care about these things tend to be pretty picky about the details. They should make sure they understand them before they buy a product, rather than risk unpleasant surprises after the fact.
0 comments:
Post a Comment