Key Takeaways
- A CRM database is a shape, not a storage box. The useful part is not that the data sits in one place. It is that a person points at a company, both point at a deal, and every call points back at all three.
- Four record types cover almost every small team. People, companies, deals and activities. Teams that start with more usually end up maintaining none of them properly.
- Pick the matching key before you pick the fields. Email address for people, root domain for companies. Without a key you get three records for the same buyer within a quarter, and no field design survives that.
- Interaction history has to write itself. A history that depends on someone remembering to log a call has holes in it, and the holes land where the busy weeks were.
- Every record needs an owner and a retention date. Ownership decides who fixes a wrong value. Retention decides when the record leaves, which matters for data protection and because a database nobody prunes stops being searchable.
Most explanations of a CRM database call it a central place for customer information, then list what you can put in it. That framing is why so many of these databases become expensive address books. What separates a CRM database from a large spreadsheet is relational structure: each record links to the records it belongs with, so you can ask what has happened with this account and get an answer instead of a search result.
Get the relationships and the matching key right and a short field list still works. Get them wrong and fifty custom fields will not answer that question. Here is what sits inside a CRM database, the joins that hold it together, and how a team of three to fifteen people should structure one so it survives year two.
What a CRM database actually stores
Strip away vendor terminology and four record types do the work. Each answers a different question, and each is its own table rather than a column on the others.
| Record type | One row is | The question it answers |
|---|---|---|
Contact (person) | One human being | Who do we talk to, and how do we reach them? |
Record typeContact (person) One row isOne human being The question it answersWho do we talk to, and how do we reach them? | ||
Company (account) | One organisation | Who do we sell to, and who else works there? |
Record typeCompany (account) One row isOne organisation The question it answersWho do we sell to, and who else works there? | ||
Deal (opportunity) | One potential piece of business | What is open now, worth what, at what stage? |
Record typeDeal (opportunity) One row isOne potential piece of business The question it answersWhat is open now, worth what, at what stage? | ||
Activity | One interaction | What happened, when, and who was in the room? |
Record typeActivity One row isOne interaction The question it answersWhat happened, when, and who was in the room? | ||
The split between contact and company is the one teams skip, and the one that costs most later. If the company only exists as a text field on the person, two buyers at the same client are unrelated records and nobody can see the account already has an open deal. A discussion in r/hubspot about managing CRM custom fields makes the structural point in passing: properties belong to a specific object, so you choose the object first and the fields second.
Activities are the other neglected half. They are the cheapest records to create and the most valuable to read, because they record what happened rather than what someone intended.
The three joins that turn records into a history
Four tables on their own are four lists. Three links make them a database.
Contact to company. One company, many contacts. Keep the relationship on the contact record, pointing up, so adding a fifth person at a client never touches the company record.
Contact and company to deal. A deal belongs to a company and names one primary contact. Teams selling to committees want five contacts on a deal at once, which most tools allow through a secondary role field. Resist it until you need it: a deal with five equal owners has no owner.
Activity to everything. An activity stamps itself onto the contact it involved, and through that contact onto the company and any open deal. This is the join that produces the timeline you read before a call.
All three depend on a matching key, the most consequential decision here. For people, use the email address: unique, typed consistently most of the time, and present on almost every inbound enquiry. For companies, use the root domain from that email rather than the company name. Names arrive as "Nordlicht GmbH", "Nordlicht" and "nordlicht gmbh" inside a week. The domain nordlicht.de arrives as itself.
That choice is also what makes deduplication finite. A thread in r/CRM on choosing a CRM for an eleven-person business, which drew over 150 comments, keeps circling the same point: the tool matters less than whether the team keeps the data clean, and clean is a habit the structure either supports or fights.
How to structure a CRM database for a small team
Five steps, in this order. The order is the method, because each step assumes the previous one is settled.
Step 1: Define the matching key and write it down
Before creating a single field, decide what makes two records the same record. Email for people, root domain for companies, plus a documented rule for the awkward cases: personal Gmail addresses from a consultant at a client, shared inboxes like info@, and freelancers who are their own company. Write that rule where the team can see it, because a key living in one person's head is not a key. Then set the tool to flag duplicate emails on create.
Step 2: Keep the contact record to fields someone will maintain
A contact needs identity, reachability, source, owner and next action: roughly eight fields. Anything beyond that earns its place by being read in a real decision, not by looking useful at setup time.
The failure mode is specific. A thread in r/Netsuite about excessive custom fields describes a schema with the same date field duplicated across subsidiaries, and the reply is blunt about it being a data design problem rather than a configuration one. One global field beats twenty near-identical ones. The small-team version is six boolean fields named after marketing channels where one source picklist would do, and free-text fields are where reporting dies: a source field with six options can be counted, a source text box cannot.
Step 3: Put the company record above the contact, not beside it
Create the company record when a new domain appears, then attach people to it. Company-level fields describe the organisation rather than the relationship: industry, size band, address, account owner.
Enrichment belongs here, with a guardrail. Pulled data is useful right up to the moment it overwrites something a human verified. meetergo's CRM pulls company industry, address, phone and description from the company's own website, records the source per value, and never overwrites hand-typed values (checked 2026-10-26). Check that precedence in your own tool before switching enrichment on: human-entered has to beat machine-entered, or your cleanest records degrade first.
Step 4: Make interaction history write itself
A history that depends on discipline runs about 40% complete, and the missing part is the calls that went badly. Build it from sources that fire whether anyone remembers or not.
- Booking forms. An enquiry arriving through a routing form creates the contact and its qualification answers in one action, so the record exists before the first conversation rather than after it.
- Calendar. Connected calendars should write meetings onto the contact automatically, including ones booked outside the CRM.
- Email. Forwarding a mail to a CRM address, or Bcc'ing it, turns the thread into a note on the right contact and creates that contact if it is new. Signature parsing then fills job title, company, phone and address from incoming mail on Suite plans and above.
- Meeting output. Summaries and follow-up tasks on the contact are what make a timeline readable six months later, when "had a call" tells you nothing.
The teams in a 60-comment r/CRM thread on finding a CRM for a small team name lead tracking and follow-up reminders as their must-haves, which is a fair description of an activity table that maintains itself.
Step 5: Give every record an owner and a retention date
Ownership is an accountability field, not a reporting field. If a value is wrong, the owner fixes it. Assign it at creation by territory, round robin or whatever rule fits, and automate it so no unassigned pile forms. Round-robin assignment covers inbound, and permissions should match: limit members to their own and their team's records, reserve deletion for admins and the owner.
Retention is the step almost everyone skips. GDPR needs a defensible answer to how long you keep contact data and why, plus the ability to export or delete one person's records on request. Both get easier when every record carries a last-activity date and a retention rule, so a contact untouched for three years gets reviewed rather than discovered. There is more in meetergo's guide to data sovereignty and its security practices page.
A worked example: one inbound lead through the database
A prospect at Nordlicht GmbH fills in a booking form on a Tuesday, picks a 30-minute discovery call and answers three qualification questions. The form writes a contact keyed on her email, creates a company keyed on nordlicht.de, and links the two. Her answers land as fields on the contact rather than as a message in someone's inbox.
The domain is new, so the company record is created rather than matched, and enrichment fills industry and address with the source noted. Assignment fires: her territory routes her to one owner, and a deal opens in that owner's pipeline at the first stage with the form's answers attached. The meeting becomes an activity on all three records.
After the call, the summary and two follow-up tasks attach to her contact, and a workflow moves the deal forward. Three weeks later a colleague emails. His signature supplies job title and phone, his domain matches nordlicht.de, and he joins the existing company with the open deal already visible. Nobody typed a company name twice, and nobody had to ask whether the account was in play.
Each step was cheap because the step before it had a key to match on.
Where meetergo fits
meetergo is a scheduling and revenue pipeline tool used across sales, consulting, recruiting and professional services, and its CRM app holds the records those bookings create. It belongs in a discussion about structure rather than features because the appointment is usually the moment a record should be created or updated, and that moment is where most stacks lose the data.
Contact profiles carry company linking, custom fields and full meeting history. Deals sit on drag-and-drop Kanban boards with customisable stages and win probabilities. Forms create deals in the right pipeline from the answers given, workflows move them before and after the meeting, and files, notes, tags and tasks attach to the contact, with a mobile CRM view of the same records (checked 2026-10-26).
Two caveats. The product page documents capture through forms, email forwarding, signatures and calendars, but no bulk spreadsheet import path, so confirm that route before migrating several thousand contacts. And if you already run a full CRM, sync beats replacement: meetergo's CRM integrations cover HubSpot, Pipedrive and Zoho CRM among others.
On jurisdiction, meetergo is 100% GDPR compliant with servers in Europe and made in Europe, run from Cologne with no US corporate parent, which removes the CLOUD Act question from a database holding EU customer records. That weighs more here than for a calendar, because this is the system with the personal data in it.
Build the structure on ten real records before you build it on a thousand. Open a free meetergo account and run a week of real enquiries through it. The free plan is free forever and needs no credit card, and ten records is enough to find out whether your matching key holds.
Common mistakes
Designing fields before deciding the key. An afternoon on custom fields and no time on what makes two records identical. Three months on, duplicates have undermined the field work and the cleanup costs more than the setup did.
Using company name as the company identifier. Names are typed by humans and arrive in variants. Domains come from the email address and do not vary. This one swap removes most duplicate accounts.
Treating enrichment as authoritative. Automatic data is a starting value, not a verified one. If machine-pulled values can overwrite human-entered ones, your best-maintained records degrade first.
Logging activities by hand. Manual logging holds for about six weeks. After that the timeline has gaps exactly where the busy periods were, which are the ones you most want to review.
Keeping everything forever. With no retention rule the database grows past the point of being searchable, and you inherit a data-protection problem with it. A last-activity date and a review cadence settle both.
When you don't need a CRM database yet
Under roughly 80 contacts, one person selling, no handovers: a spreadsheet with a clean schema and a single owner beats a CRM nobody maintains. The threshold is not contact count, it is handover count. The moment a second person needs to know what happened with an account without asking the first, you need the relational structure. A 40-comment thread in r/CRMSoftware on simple CRMs for small sales teams is full of teams finding that line after crossing it. If you are near it, the free tiers in free CRM software test the structure more cheaply than a paid trial.
Stop juggling tools. Scheduling meets sales pipeline.
Stop juggling tools. Scheduling meets sales pipeline.
FAQs
Is a CRM database the same thing as a CRM?
No. The CRM is the application: screens, automation, reports. The database is the data layer underneath, and its structure decides which reports are possible at all. Two tools with similar feature lists behave differently if one links contacts to companies properly and the other does not. For the category, see what a CRM is.
What type of database do CRMs use?
Almost all are relational, which is why the joins above work. Most hosted CRMs run on a managed SQL engine, and the engine is rarely something you choose or need to know. Where the data physically sits does matter, and that is a jurisdiction question rather than an engine one. Cloud-based CRM hosting models covers the trade-off.
How many fields should a contact record have?
Around eight for a small team: name, email, phone, company link, source, stage, owner, next action. Add a ninth when you can name the decision it informs. The test is whether anyone has read it in the last quarter.
How do I clean up a database that is already a mess?
Deduplicate before restructuring, because reorganising duplicates multiplies the work. Match on email for people and domain for companies, merge rather than delete so activity history survives, then apply the new schema to the merged set. The step-by-step version is in how to organise contacts.
What should trigger an update to a customer record?
Every interaction, ideally without anyone deciding to. Bookings, calendar meetings, forwarded emails and form submissions should write to the record on their own. Reserve manual updates for judgement: stage changes, qualification notes, next actions. The ongoing routine is in CRM customer management.
Does a CRM database need to be hosted in the EU?
GDPR does not require EU hosting outright, but it does require a lawful basis for any transfer out of the EU, which is where the paperwork and the Schrems II exposure sit. A provider storing data in Europe with no US corporate parent removes that question instead of documenting it. In regulated sectors it is usually the deciding factor, and GDPR-compliant software covers what to check.
