Who owns CRM data at your company?

In most enterprise applications, ownership of an individual record just isn’t that important. Yes, you want to make sure that you keep confidential information away from prying eyes, but the information is usually dealt with as an entire class of data such as “all salaries” or “this group’s charge numbers.” Meanwhile, the handling of access privileges is often just a matter of following user-group-world hierarchies.

Some data in a CRM system follows this pattern. For example, the access privileges for data about your users (such as “name” or “phone”) can be handled in a simplistic way. When it comes to the meat of CRM data, though—contacts, relationships, accounts, deals, cases and so on—access privileges for those records have to be handled on a highly individualized basis. And when you get the privileges wrong, you’ll know about it in seconds via a high-volume phone conversation. This is definitely not mañana territory.

The main reason for this is the sales staff. They have families to feed, and if your company uses a highly leveraged compensation plan, the only way they have a nice vacation is by winning deals. Depending on your industry and your company’s sales culture, the salespeople can be almost maniacally territorial. Taking away any increment of visibility or control over their client and prospect relationships is akin to stealing. There’s no blaming them, as they’re simply playing by the rules management has given them.

CRM data ownership gets complicated

In most CRM systems, the first control point for visibility is the record owner. This can be set only to a single user, so the “owner” may be supplemented by “sales team” and “support team” abstractions that provide shared access. In addition, your system may have conditional ownership privileges for global accounts; you see this in follow-the-sun customer support models and sometimes for local account managers. Just to keep things interesting, there can be multiple levels of overlay.

These mechanisms can get complicated. Unfortunately, with the really fancy ownership models, there’s only two ways to see what’s going on: Top-down, by inspecting all the rules and code in the abstract, and bottom-up, by working with specially-crafted test cases. You won’t find any pretty graphics here—at best, it’s a series of spreadsheets—and troubleshooting often involves white-boards and conference calls. That’s right, Star Trek fans, stone knives and bear skins.

There’s yet another layer of complexity, too. In most cases, ownership of each object is almost totally independent, unless you have set up a strict master-detail relationship. (Really.) This means that ownership of an Account is more or less independent of the ownership of Contacts or Cases at that Account. The specific rules used to determine the privileges are typically independent, and the record updates are independent unless you’ve written some of your own code to update child records to “follow the parent.” (Really.)

This means there are tons of opportunities for erroneous ownership. For example, the GM account may have moved to a new sales team. That doesn’t mean the leads, contacts, cases, opportunities and ancillary records have been moved—or that they should have been moved. That’s all a matter of internal policies, and the CRM system won’t enforce any of those policies unless, of course, you have written an application or magical query to do so. Since the owner field is used in all kinds of internal CRM computations—determining when and why a lead should be transferred from inside sales to an outside representative, for example—erroneous record ownership can have some surprising ramifications.

Solve the CRM data conundrum with governance

Since you can’t depend on the CRM system to automatically keep all this up to date, you need to set up governance system to manage it over time, even in the smallest CRM instances. In most cases, it doesn’t need to be a big committee. Typically, this can be handled by one or two people.

The issue, then, is who. It should be someone with system administrator privileges and skills. This is almost purely a data issue, so a bunch of spreadsheets or a smallish database will be the tools of choice. But there are different flavors of SysAdmin, so keep that in mind.

In my experience, this is not something that should be handled by marketing or finance. Even if they have the skills and information, they just aren’t part of the team that has skin in the game.

Typically, sales operations is the right department to handle this. It’s constantly interacting with the Folks Who Really Care, and it has access to the Folks Who Make the Rules. If your organization puts support and professional services at the top of the power structure, then this task should be owned by the SysAdmin closest to the support team.

When outside systems inject new CRM data, they may need to set or manipulate ownership values. Generally speaking, we recommend that all that assignment, ownership and routing logic be in one place: either entirely in the CRM system, or entirely outside of it. Having that logic straddle system boundaries is almost always a recipe for trouble. Even if you happen to get it right now, it’s almost impossible to maintain over time.

Instead, use Web services or other remote procedure call mechanisms to make sure the decision of who owns what record and why is always made in the same place.