# CRM database: what a small sales team should store, and what to leave out

https://salesbond.app/blog/crm-database-what-to-store-sales-team/
Published: 2026-10-16 · Updated: 2026-10-16

A CRM database is the central store of your contacts, companies, deals and activities, kept in one place so the whole team works from the same record. A small team needs four objects and a short list of fields, each with an owner who fills it and a report that reads it. Everything else is clutter: it costs the rep a minute per deal and tells the manager nothing.

## What a CRM database is, in two sentences

Salesforce defines it as “a single source of truth for information like customer contact details, purchase history, communication records, service requests, and preferences” ( [Salesforce: What is a CRM database?](https://www.salesforce.com/crm/database/)). Our shorter version: the database is the part of the CRM that remembers. The pipeline board, the reports and the automations are only ways of reading it, so if the database is thin or wrong, every screen built on top of it is wrong too.

A CRM database example: one record for a company called Acme. Attached to it, the three people you talk to there, each with a role. One open deal at the Proposal stage with a value, an expected close date and a date for the next call. Under that deal, the log of calls, emails and meetings that got it there, in order. That is the whole database for one account, and a new rep can read it in two minutes without asking anyone.

HubSpot’s help center splits the same idea into objects, records and properties ( [HubSpot: Manage your CRM database](https://knowledge.hubspot.com/get-started/manage-your-crm-database)). An object is a type of thing (a deal), a record is one of them (the Acme deal), a property or field is one attribute of it (the close date). Your CRM may use other words, but the three layers are the same everywhere, and the decisions below are about which objects and which fields.

You rarely build this database yourself. It comes inside the CRM system: Pipedrive, HubSpot, Salesforce and Zoho CRM each give you one, with the same contacts, companies and deals at its core, and the work is deciding what goes into it.

## The four objects a small team actually needs

Contact, organization, deal, activity. Four, and we would resist adding a fifth for a long time.

You may have seen CRMs sorted into types. Salesforce lists four: analytical, operational, collaborative and strategic ( [Salesforce: What is a CRM database?](https://www.salesforce.com/crm/database/)). A small sales team lives almost entirely in the operational part, the daily record of who said what and which deal moves next. The other three read from that record, so they are only as good as it is.

The contact is a person: the one who replies to your emails and picks up the phone. Keep one record per person even if they change jobs; the history goes with them.

The organization is the company the contact works for and the deal is sold to. It exists so that three contacts and two deals at Acme hang off one record instead of being five unrelated rows. Without it, your “how many customers do we have” question has no honest answer.

The deal is one sales opportunity with a stage, a value and a date. It is the object the manager actually manages. A contact never “closes”; a deal does.

The activity is a call, an email, a meeting or a task, attached to a deal and dated. This is the object teams skip when they come from a spreadsheet, and it is the one that answers “when did we last speak to them” without opening anyone’s inbox.

What we would not add yet: a separate lead object, products, quotes. A lead object makes sense when someone’s job is qualifying inbound before it becomes a deal. Until that person exists, an early stage on the deal pipeline does the same work with one less place to look.

![Entity diagram: contacts and deals link to organizations, activities log on deals; each object lists its fields](https://salesbond.app/wp-content/uploads/2026/10/crm-database-what-to-store-sales-team-2.png)

## Fields that earn their place, and the test for a new one

Here is the list we would start a new team with. It is deliberately short, because every field you add is a question the rep has to answer on every record, and reps answer questions they see the point of.

On the deal:

1. Owner, so one person is accountable for the next step.
2. Stage, so the pipeline report means something.
3. Value, in one currency, so the pipeline has a total.
4. Expected close date, so the forecast has a month.
5. Next activity date, because a deal with no next step is already stalled, whatever the stage says.
6. Source: where the deal came from, as a short dropdown, not free text.
7. Lost reason, filled only at the moment the deal is marked lost. A dropdown again, with “other” allowed and read once a quarter.

On the contact: name, email, phone, role. On the organization: name and website. That is thirteen fields across the four objects, and a team can run for a year on them.

The test for a new field is three questions, asked out loud before anyone opens the settings page. Who fills it, and at which step of the process? Which report, filter or automation reads it? What breaks if it stays empty? If the answer to the first is “the reps, whenever”, to the second “none yet”, or to the third “nothing”, the field is not created. A field without an owner and without a report is not data; it is a blank the team learns to ignore, and then they learn to ignore the fields next to it.

One exception we do make: fields the system can fill. Source from a web form, created date, last activity date, the owner set by a round-robin rule. Those cost teh rep nothing and they are the most reliable fields in the database, which is why we lean on them. We wrote up the pattern in [how to automate CRM data entry in Pipedrive](https://salesbond.app/blog/automate-crm-data-entry-pipedrive/); the idea carries to any CRM with workflow rules.

## What not to store

The failure mode of a small team’s CRM is rarely too little data. It is a deal form with thirty fields of which six are filled, a notes tab nobody reads and a contact record with the customer’s birthday on it.

Start with notes. A note should say what was agreed and what happens next. It should not be a pasted email thread, because the thread already lives in the mailbox and in the activity log if email sync is on. A note that duplicates another record is not a backup, it is a second version that will disagree with the first within a month.

Then the fields that duplicate a field. A free-text “Status” next to the stage. An “Industry” dropdown and a “Sector” text box added by two different managers in two different years. A “Last contacted” field someone updates by hand while the activity log holds the real date. Each pair is a small argument waiting to happen, and the the rep resolves it by filling in neither.

Then data that belongs to another system. Invoice totals, support tickets, product serial numbers. If accounting or support is the source of truth, copying it into the CRM by hand creates a stale copy and a job nobody owns. Link to the other system, or integrate it, but do not retype it.

And then personal details without a sales purpose. A B2B deal does not need the contact’s home address, their children’s names or their birthday. If you cannot say what the sales process does with a piece of personal data, do not hold it; you would not enjoy explaining it to the person if they asked what you keep about them.

Dead custom fields are the last category, and the one we run into most. Every field a former manager added for a project that ended is still on the form, still blank, still slowing down the rep who scrolls past it. We went through the cleanup, field by field, in [cleaning up custom fields in Pipedrive](https://salesbond.app/blog/pipedrive-custom-fields-cleanup-data-fields/); the audit is the same in any CRM, only the settings page differs.

## Is a spreadsheet a CRM database?

In the narrow sense, yes. A sheet with one row per contact and columns for company, phone and last call is a database of customer data, and for one person selling to a few dozen accounts it can be enough. We would not talk anyone out of it at that size.

It stops being enough at the point where the four objects need to be four. A sheet is one table. It cannot hold three contacts under one company without repeating the company three times, and it cannot hold a deal’s history of calls without a second sheet and a lot of discipline. The moment two people sell from the same sheet “who is working on Acme” becomes a question with two answers, and the “next step” column goes stale because nothing nags anyone about it.

If you are moving from a sheet, move less than you think. Take open deals with their stage, value, expected close date and next step. Take the contacts attached to those deals, with their company. Leave behind the color coding, the columns nobody has updated in a year, and the closed-lost rows from the early days with no reason recorded; they will not make a report better, they will make every list longer. Import the past as a one-line note on the organization if it matters, not as a thousand half-filled records. The full move, with the deal view that replaces the sheet in the Monday meeting, is in [CRM sales tracking: moving off a spreadsheet](https://salesbond.app/blog/crm-sales-tracking-from-spreadsheet/).

## Who owns the data

Three jobs need a name against them: the records, the field list and the weekly check. A database with thirteen fields and no owner degrades as fast as one with forty.

Reps own their own records: the next activity date is theirs to keep real, and the stage is theirs to move. One person, usually the manager or a senior rep, owns the field list: nobody else adds, renames or deletes a field, which is how the form stays at thirteen. And the manager owns the weekly check, the ten minutes on Monday when the filters below get run and the results get said out loud at the stand-up.

How a team with nobody in an ops role splits those three jobs, and what the Monday routine looks like in practice, is in [who owns CRM data quality when you have no ops person](https://salesbond.app/blog/crm-data-ownership-small-sales-team/). Read that before you assign the jobs. The trap it describes is three people with admin rights, each adding fields as they think of them, and that is exactly how a form gets to forty.

## A 15-minute health check

Run this once on the database you have, before changing anything. It tells you whether the problem is missing data, duplicated data or dead fields, and the fix is different for each. If you then want numbers to track week over week rather than a one-off look, the ones we use are in [CRM data quality metrics for a small sales team](https://salesbond.app/blog/crm-data-quality-metrics/).

- Filter open deals with no next activity date. Each one is a deal nobody plans to touch.
- Filter deals in Proposal or later with a blank value or a close date in the past. Those are the ones inflating, or deflating, your forecast right now.
- Filter contacts with no organization attached.
- Sort organizations by name and scan for the same company spelled two ways.
- Open the deal form and count the fields you have never filtered or reported on. Those are candidates for the cleanup in the section above.
- Open the last three deals marked lost and check the lost reason. If all three say “other” or are blank, the field exists but nobody owns it.
- Pick one deal at random and read its notes and activities top to bottom. If you cannot tell what was agreed and what happens next, the database has records but not memory.