Notion as a CRM has a bad reputation among people who tried it once, gave up after a month, and went back to a spreadsheet or bought an off-the-shelf tool. In most cases the problem wasn't Notion — it was how the database was put together in the first place. We've seen the same set of mistakes in dozens of self-built rollouts before they landed on our desk for a fix. Here are the five that do the most damage.

1. The same client exists in three databases at once

The classic setup: a Contacts database, a separate Companies database, a separate Deals database — none of them linked to each other through a relation. The same client shows up as manually typed text in three places, so changing a phone number means three edits, and a typo in a company name effectively creates a second, "new" client.

The fix: one Contacts/Companies database as the single source of truth, with Deals, Tasks and Projects linked to it via a Relation property. You type the client's data (phone, email, tax ID) once — every other database references that record through a Rollup instead of copying it.

2. The sales pipeline is a text field instead of a status

A Text property with "in progress" typed manually in one record and "IN PROGRESS" in another is a pipeline you can't count or filter — because to Notion, those are two different values. Missing, clearly defined stages is the most common reason a business owner has no real idea how many open deals they actually have.

The fix: a Status property (not Select — Status has built-in "to-do / in progress / done" groups) with a short, closed list of stages agreed once at the start: e.g. Lead → Contact → Proposal → Negotiation → Won/Lost. A closed list forces consistency and lets you build views grouped by stage.

3. A database with 40 columns nobody uses

"Just in case" fields like "Lead source 2," "Extra note," "Priority B" — each added with good intentions, none filled in systematically. The result: the database looks comprehensive, but really only 8 of the 40 columns carry any information, and a new team member has no idea which is which.

The fix: add a field only when you have a specific business question it answers. For an existing, overgrown database, it's worth reviewing it once a quarter and hiding (not deleting — Hide property) fields that have sat empty on half the records for three months.

4. No automatic follow-up reminder

Notion won't call or email anyone on its own — but it also won't remind you that a client has been waiting ten days for a reply, unless you build a view for that. The most common cause of "cold" leads in a hand-built CRM is the absence of one simple view: "contacts with no activity for more than X days," sorted descending.

The fix: a Last contact date property, updated manually or automatically (e.g. via an email integration — something bāApps Relay does), plus a filtered view that shows every morning who's been waiting the longest. That's fifteen minutes of setup that saves real money.

5. Permissions and views not designed for the team

One shared database everyone can fully edit, with no distinction between "my view as a salesperson" and "the owner's view of the whole pipeline" is a direct path to accidentally deleted records and chaos in fields someone "fixed their own way." The lack of separate, filtered views also means everyone scrolls past records that aren't theirs.

The fix: separate views (not separate databases) filtered by the person responsible, with a clear rule for who can edit structural properties (stages, automations) versus who can only edit their own records.

Key takeaways
  • One client = one record, linked by relations, never copied across databases.
  • Pipeline stages as a closed list in a Status field, not free text.
  • Fewer columns, consistently filled in, beats a sprawling, dead database.
  • A single "who's been waiting longest" view saves more leads than any extra column.

None of these mistakes come from a limitation in Notion — they come from the fact that a self-built CRM rarely has someone behind it who's already gotten this wrong elsewhere and knows where the traps are. That's exactly the work we do on bāIMN deployments — we don't sell a template, we structure the database around your actual sales process before it has a chance to drift.