In Part 1 of our Understanding the Data Lifecycle series, we covered how to capture sales data based on data policies and controls. But what happens once you capture data? How do you store, secure, and maintain all of this data at scale? Better yet, how do you apply this data to the place you need it most — Salesforce? Today, we’re looking at data maintenance and storage, the second stage in the sales data lifecycle.
Understanding Data Storage vs. Data Governance
By 2025, 175 zettabytes of data will be generated. That’s over 5 trillion 4k movies worth of data. And a chunk of it is going to belong to you. Congrats! You’re inheriting hundreds of terabytes of data. So… what do you do with it? The easy answer is to shove it all in a public cloud and bust out the balloons and confetti. But the real answer is a little more complicated.
Chances are, your data is stashed away in data lakes, sitting comfortably in private and public clouds, being processed in S3 buckets, flowing through Salesforce, and hiding away on physical in-house servers. In other words, your data architecture likely looks less like a straight line and more like a giant Picasso painting. That’s ok! You’re not alone.
In fact, data processing and cleanup eat up half of IT’s time. And the average organization is losing 30% of its total productivity due to poor data quality and availability. Simply put, most organizations struggle to discover how to store and maintain data at the scale required for today’s hyper-intelligent AI workflows and sales systems.
But here’s the secret: storage isn’t the issue. It doesn’t particularly matter where data is stored in the context of the data lifecycle. As long as you’re using best-in-class security practices and following regulatory guidelines, the spot your data resides in has little to do with its effectiveness. Instead, the problem most businesses face is governance. How do you maintain that stored data in a way that’s consistent and standardized? And how are you mapping your sales solutions to your databases to garner actionable data-driven intelligence?
Yes! You need a data storage plan. And it’s absolutely a complicated and necessary part of your data lifecycle. You should touch base with stakeholders and discover what types of cloud solutions, on-premise servers, platforms, and data lakes you need to store and process data effectively. Chances are, you’ll move data according to set standards, dump unstructured data into lakes for data mining and BI, and host some data in various solutions in your stack.
In the context of this series (which is hyper-focused on sales data), we’re going to bypass these conversations. They need to happen. But they’re outside of the scope of this article. Instead, let’s discuss data governance, which McKinsey estimates to be the key differentiator between data-driven businesses and businesses that simply have data.
What is Data Governance, And Why Does it Matter?
There may be more definitions for data governance than there are stars in the sky or pebbles of sand on the beach. So, instead of giving a fancy, overly complex definition, let’s just say that data governance is the framework for your data. It’s all of the policies, roles, metrics, standards, processes, and strategies you use to ensure that high-quality sales data flows throughout every nook and cranny of your organization.
Let’s look at a very simple example of data governance: telephone numbers. Let’s say that you use an open field to capture telephone numbers from prospects. At first, you let your salespeople run wild with the field. Some salespeople enter numbers with digits only, others use hyphens, and a few use digits only with parentheses around the area codes. This is a huge problem. It’s nearly impossible to consistently search and pull those telephone numbers, and your sales solution gets jammed with inconsistent field entries. Data governance sets standards your salespeople follow to ensure all telephone numbers are entered uniformly.
Overall, data governance defines roles, responsibilities, actions, and standards. Every person in the organization should know which data they can use, how to enter that data, how to define that data, and which situations they can use that data. When you first approach data governance, it can seem daunting. We highly recommend creating a data governance process that combines the following:
- Policies and standards (see part 1 of this series to learn more)
- Training and playbooks
- Data architecture guidelines
- Definitions of data models, structures, and quality
- Data security guidelines based on regulatory requirements (e.g., GDPR, CCPA, etc.) and internal requirements
In the context of sales data, you need to define standards employees should follow when entering data, security guidelines for data in motion and at rest, and plenty of hands-on training to ensure employees understand data requirements.
Let’s touch on an incredibly important point: more data governance isn’t always better data governance. The more rules and regulations you create, the slower your sales workflows become. Data governance isn’t copy-and-paste. You need to create a unique governance structure that compliments your specific goals, ambitions, and workflows.
Mapping Data to Salesforce
Alright. You have this amazing data architecture and a data governance strategy. Now what? How do you actually maintain data in a way that makes sense for your sales team? Better yet, how do you connect that governance policy with Salesforce?
When we discuss the data lifecycle in the context of sales, a big portion of your data flow exists between lead capture/gen and lead conversion. In other words, how do you get data from a website touchpoint or external system into Salesforce to qualify leads? And then how do you follow that data as it goes from a lead to a contact, opportunity, and conversion? This process involves creating custom fields and data mapping.
When you first onboard Salesforce, it comes with plenty of canned fields. While these fields are almost all universally useful, you still need to go in and create custom fields to receive specific data from your databases. For example, you may want to have a field for a contact’s current position in a company. You can add this field to Salesforce, set up its relationships, and establish how it consumes data from your database. Creating custom fields in Salesforce is relatively easy. Not only does Salesforce have plenty of guides, but there are some tools that can help you semi-automate this process.
After you create custom fields, you need to map them to your organization. This helps keep data consistent between fields, even while a prospect is moving throughout your Salesforce environment. In addition, it helps any organizations, teams, or units you share Salesforce data with understand the data flow. Again, Salesforce has plenty of guides to help you map your data.
Data Storage, Governance, and Mapping Aren’t One-Size-Fits-All
Every company has unique data needs. The governance policies, processes, standards, and strategies you utilize will be unique to your organization. In fact, your entire data architecture is unique to your business, including your Salesforce instance. Unfortunately, you can’t simply copy-paste governance. There’s a reason we didn’t provide a step-by-step guide.
At Delegate, we understand that every business has different governance needs. Contact us today for help with a data governance plan that fits your needs.