Notion for running a small business: one database per object, not one table per team

Notion promises to put everything in one place. Six months later, most company workspaces look like an attic: pages nobody opens, three customer tables that disagree, and a team back to chat messages. The problem is not the tool. It is the structure.

Why company Notion workspaces die

The story is always the same. Each team builds its own table, its own way. Sales has its customer list, operations has another, accounting a third. Information gets copied from one table to the next, then stops being copied. After a few months nobody knows which version is right, and everyone goes back to asking someone.

Notion is not to blame. We simply rebuilt, in a new tool, the silos we wanted to leave.

The principle: one database per object

The structure that lasts starts from the objects of your business, not your org chart. An object is something the company handles and needs to remember: a customer, a site, a job, a team member, an incident, an invoice.

Each object gets one database, and only one. Each customer exists once. Each job exists once. Teams stop creating tables: they look at the same databases from different angles.

Relations instead of copies

A job does not need to copy the customer's address: it is related to the customer, and the address shows up by itself. If the address changes, it changes everywhere. Notion relations do exactly that, and they are the most under-used feature of the tool.

In the system we install, five databases are enough to run a service business: sites, team, bookings or orders, jobs and incidents, all related to each other. Everything else is a view.

Views for each team

Operations wants tomorrow's jobs by person. The owner wants open incidents. Sales wants customers with no activity for three months. Those are three filtered views of the same databases, not three tables. Everyone sees what they need, and nobody maintains a copy.

Few properties, closed statuses

A database with forty columns gets filled in by nobody. Keep the properties a decision depends on and delete the rest. For statuses, use closed lists with values defined once and for all. A free-text status produces “done”, “Done”, “ok” and “finished (I think)”, and no filter ever recovers.

Who writes what

The rule that makes a Notion last: people type as little as possible. Bookings arrive on their own from the booking software, incoming requests arrive from the website form, jobs are created from bookings. People validate, complete and decide. A database that has to be filled in by hand to stay up to date will never be up to date.

That is the job of automations, built with n8n in our case: moving information between tools so that Notion reflects reality without anyone retyping it.

Notion limits to know

• It is not a transactional database. For thousands of writes per hour, accounting or real-time stock, you need proper business software or a real database.
• The API is rate-limited. Around three requests per second: a bulk sync must be designed to wait and resume.
• Permissions are fine-grained but easy to get wrong. A database shared too widely exposes everything in it, relations included.
• Offline support is imperfect. A field team without signal needs a dedicated interface, not Notion directly.

That last point is why our field teams never open Notion: they use a simple portal on their phone, which reads and writes the databases for them.

Where to start

List the objects of your business on one sheet. Pick the two that cause the most trouble today, usually customers and jobs. Create one database for each, relate them, import what exists, and delete the old tables. Not archived: deleted. As long as they exist, someone will keep filling them in.

Frequently asked questions

How should a company organise Notion?

With one database per business object (customers, sites, jobs, team, incidents) rather than one table per team. Databases are linked with relations, and each team works on filtered views of the same databases instead of maintaining its own copies.

Can Notion replace management software for a small business?

For organising work and tracking customers, jobs and incidents, yes, provided it is structured as related databases and fed automatically. For accounting, real-time stock or large write volumes, no: dedicated business software is still needed.

Why don't teams use Notion?

Because they are asked to retype, by hand, information that already exists elsewhere, in tables that contradict each other. A Notion that lasts is fed by automations, and field teams use a simple phone interface rather than Notion directly.

What are the limits of the Notion API?

It is limited to about three requests per second on average. A large sync therefore has to space out its calls and resume after hitting the limit.