This post by Madison Schott—a data engineer and consultant—is here to help early-stage sales leaders and anyone building their first CRM.

A few years ago, I was hired by a small tech company as one of the first analytics engineers. Before I joined, the company had worked with data engineering consultants to build out their data pipelines, set up their data warehouse, and organize data within the CRM tool. It was a total mess: the data consultants–and the sales team–sent tons of data to their CRM without documenting anything. The sales team added endless amounts of data fields without documenting what the data meant. 

By the time I got in there, the CRM was a complete nightmare. While trying to untangle the messy data, I quickly learned how important it is for CRMs to be set up correctly from the start of the sales team, before they become a calamity of tech debt and low quality data. 

A seller can be a future data team’s best friend if they take the time to do things right. So here are some tips for how to set up and use your CRM with data quality in mind, and be a good steward for your future data team.

CRMs are not sources of truth, so don’t treat them as such

I’ll start with something that might go against what GTM teams think: CRMs like Hubspot are not a source of truth for data; they’re actually applications built on top of a real source of truth. The only source of truth for analytics is a data warehouse. And though it’s likely not realistic for your startup to set one up quite yet, this distinction is critical to understand.

CRMs are SaaS applications, designed for a specific purpose that doesn’t necessarily follow data best practices. They look like sources of truth because they have many different applications that connect to them, allowing you to import and export data from and to a wide variety of sources. While this can be helpful in the quick and dirty sense, it makes it hard to know where your data is coming from, especially when you continue adding data sources without developing a full understanding of them. The data cannot be tracked and lacks quality checks.

Here are a few simple things you can do to make sure your CRM doesn’t become a bottleneck down the road:

• Instead of connecting all available applications to your CRM, test out one at a time. For example, instead of adding different data enrichment tools like Gong and Stripe Data Sync at the same time, test one first and see how it goes. Do the data points add value? How are you using them? If you find they aren’t what you need, you most likely won’t need other data-enrichment applications.
  
• Document why you are adding applications to your CRM and the exact fields you are using from them and why. This will help you stay organized with your data over time, allowing you to re-evaluate what you truly need and don’t need in terms of data. 
  
• Try to limit the number of workflows you create and the amount of data from different applications they touch. This will help you better track how your data flows through your CRM. 

Down the road, you may end up with an analytics engineer who will ingest data from different sources into a data warehouse. Having this documentation will help them identify what data sources are crucial to your operations and allow them to better understand what’s happening in the CRM tool. 

Analytics engineers can also help you eventually utilize reverse ETL tools to send data reliably from your warehouse to CRM tools like Hubspot and Salesforce. This will enable you to consolidate your data and reliably calculate metrics using multiple different data sources in your warehouse. When using one tool to send data, you’ll have a consistent way to check for data quality errors and the expected freshness of your data. 

Define naming conventions

When I first started working with data in Hubspot, I noticed that data fields were both redundant and inconsistent. For example, two or more fields would store what seemed to be the same data value, but with slightly different names. Or, one would have a suffix to denote the object it was being used on, and another wouldn’t. Yet another field would have DO NOT USE in the name. No outsider could possibly create workflows or know which field to send data to without asking someone else for context (and what if the person who created the field left the company?). Sometimes the disparate naming conventions would even confuse our own team members. 

When building a CRM with reliable data, you need to have consistent naming conventions in place for your data fields. You should write up a basic style guide for all new data that enters the CRM, including how to name fields within different objects. Here are a few tips for your style guide: 

• If you have identical fields across objects, I recommend including the object type as a suffix. For example, “account_created_at” would be named “account_created_at__company” on the company object and “account_created_at__contact” on the contact object. This allows you to easily distinguish which field belongs to a company versus a contact.
• Prefixes and suffixes are powerful in indicating the data type of a field. This makes it so the user can easily filter the data within your CRM as needed. Date and timestamps are commonly named ending with “_at”. Account creation date would be named “account_created_at” following this convention.
• Booleans are commonly named as beginning with “is_” or “are_” to indicate a true or false value. With this standard, customer active status with the values of true or false would be named “is_active”. 

Your style guide, which includes conventions such as these prefixes and suffixes, should then be referenced by every person who touches the CRM, making it clear what should be used and what shouldn’t be. It doesn’t have to be something crazy extensive; just write down how your team should name things.

And, of course, fields that are not needed should be deleted rather than kept around with DO NOT USE in their name. On that note… 

Clean your data 

It’s important to clean your data as it becomes unneeded in your CRM tool, or as data quality issues are found—not when you get around to it. Leaving all the data in your CRM and continually telling yourself you’ll delete it later is a recipe for tech debt and many months of frustration for a future data team member. 

Create a data cleaning strategy within your CRM to evaluate what fields are no longer being used, including those DO NOT USE ones I mentioned earlier. We are not talking a multi-hour team project here; something as simple as a recurring calendar reminder will do.

It’s also important to do this for workflows or sequences created by sellers within your CRM. When these things begin to pile up, they create more noise and confusion for everyone. I often see old workflows dependent on stale data fields, making it difficult to know what can be deleted and what can’t. Taking the time to remove objects will make it easier to keep a clean data environment. 

Only ingest qualified fields—and document their definitions

It’s really easy for tools like CRMs to become overloaded with data. For example, one person needs a piece of data to do one small niche thing. Another person thinks they need another piece of data to send an email, but they never end up using it. It’s when we allow all of these data fields to get created that we start to have issues: we end up with so much data that we forget what field means what, or why we ever needed it in the first place.

Take advantage of data-related features that CRMs offer, even if you don’t understand them at first. For example, Hubspot allows you to have a definition for a field when you first create it. Document the definitions here so they can live right next to your data, giving you one less thing to worry about in the future. 

Documenting the definition of a field allows its intended use case to be tracked over time, and for the field to be deleted when it is no longer valid. 

A good analytics engineer questions every field that is requested in a CRM, ensuring it can actually be used to solve real business problems and isn’t just a nice-to-have. Whether you have an analytics engineer on your team or not, you can also act as the gatekeeper of your CRM. Question every field that someone requests, making sure only the valuable data is added. 

Assign an owner to your CRM

Best practices are easier said than done. Sure, you can tell everyone who touches the CRM to follow these, but what if they forget? Work gets busy and best practices often fall wayside. This is why every CRM needs a clear owner, who should act as the creator and steward of best practices, ensuring accountability and compliance.

The CRM will point people to the style guide, run audits on the CRM tool, and check in with the data team on any data quality issues. If you’re the first seller, this is probably going to be you. 

Now, if your CRM owner has data experience, that’s even better. CRMs are largely data tools (with features that make it easy for everyone to use), but there are often quirks in how they handle data. For example, Hubspot-created fields will not ingest certain data values if they do not meet their standards, as Hubspot applies validation logic on the values, making it harder to track why data isn’t making it into the tool. 

If you learn some data quality basics, don’t push the CRM past what it’s meant to do, and document your work at a reasonable cadence, you can make life for your future data team a breeze, and make your own work more efficient too.

Building and iterating to scale 

When it comes to setting up a CRM tool, aim for simplicity. While all of the data capabilities may be exciting, it’s often the basics that are most needed. Syncing unnecessary data will only create more mess and confusion in the long run.

While it can be tempting to hit the ground running with your CRM, it pays to slow down and think about its use strategically. How can you avoid the most common mistakes and headaches? How can you make it an easy system for people to use? How can you increase your own trust in the tool? All of these questions can be easily answered by following best practices as soon as you go to market. 

Start small by adding one integration at a time, using each one as an opportunity to improve your best practices. Adjust your basic style guide and naming conventions as you go. If something isn’t working, identify that immediately and change it! Don’t let old conventions go uncleaned, but instead use them as an opportunity to put clean-up practices in place. 

When you are just starting with a CRM tool, you have room to experiment and iterate on what’s working and what’s not. The goal is to identify data issues early and improve them before bringing more data into the tool. Your CRM tool will only successfully scale once you learn to leverage and manage small amounts of data before adding more integrations.