Organising customer management in Notion: a method and its limits
Updated on
When I began working as a web consultant, it felt as though everything required attention at once. Customers, documents, content ideas and tasks lived in different places. Before looking for more ambitious software, I tried giving each tool a clear role in the way I worked.
In the video, I present the system I used at that time: Notion for organisation, Google Keep for capturing ideas and Google Docs for documents. It was not a custom-built ERP. It was a personal way of making existing applications work together, with a clearer place for information and the next action.
Contents
Give customers and actions a clear place
I had built a Notion workspace to follow my activity. The principle was to group comparable items and filter them by status. For content, that helped distinguish an early idea from a script ready to record. The structure reflected decisions I needed to make, rather than simply collecting information.
The same reasoning helps with customers: a record, useful context and a visible next action. Before adding many properties, decide which questions the view should answer. Who is waiting for a reply? Which project is active? What document is missing? Those questions give each field a purpose.
A very detailed record that nobody updates may be less useful than simple tracking that is actually maintained. Keep the system proportionate to the volume and working habits of the team. Its value depends on dependable use, not the number of columns it can display in a demonstration.
Separate quick capture from later organisation
I used Google Keep because I found it more convenient for taking notes on my phone in that context. I could record an idea quickly and return to it at my computer. That was a personal workflow preference, not a universal limitation of Notion or a claim that everyone should use the same tools.
The important point is when those captured notes are reviewed. If every application becomes another place where ideas accumulate, the system recreates the fragmentation it was meant to solve. Decide when notes are sorted, connected to a project or deliberately set aside because they no longer need action.
Apply the same reasoning to a customer request received while travelling. Capture it easily, then assign a responsible person and next step when returning to the usual workflow. Quick capture and structured follow-up can be complementary, provided the handover between them is explicit and regularly maintained.
Connect documents to their context
I used Google Docs to prepare documents and then connected them to the relevant workspace. The intended benefit was simple: finding the right document while handling the customer or project. A file’s usefulness increases when its relationship to the work is clear and easy to retrieve.
This requires shared conventions. Which file is the reference version? Who can edit it? Where is the authoritative link? Without common answers, people may work on different copies and believe they are using the current information. The problem then comes from the process as much as the software.
An editable document may suit certain tasks. It does not automatically replace specialised software for invoicing, approvals or operations. Evaluate those requirements separately. A practical collection of tools can be useful without pretending that every business function has already been addressed by the same workspace.
Build customer tracking the team can maintain
Start by separating the customer from their projects. One company can commission several assignments; copying its contact details into each project creates multiple places to correct. A reference record linked to projects preserves the context. Notion supports database relations for this purpose, as described in its documentation on relations.
Keep the first structure deliberately limited. A customer record might contain the name, contact, responsible person and useful links. A project might add its status, next action and date. These are suggested fields, not a universal template. Adapt them to the questions the team must answer rather than reproducing an elaborate example whose properties nobody uses.
Imagine an inquiry arriving on Monday. Someone finds or creates the customer, adds the project and records “request photographs” as the next action. By Friday, a view of outstanding actions should reveal that task without searching through notes. If it does not, clarify the entry and follow-up rules before adding new functions.
Schedule a short, regular review. A completed action should lead to the next step or an explicit closure. Abandoned projects should be distinguishable from active work. This updating cycle makes management useful; an attractive workspace alone cannot ensure that the information remains accurate or that the team knows what to do next.
Comparison: Notion, an existing CRM or a custom CRM
Compare everyday follow-up, handovers and maintenance effort. The number of customers is not a universal threshold that automatically requires moving from one tool to another. Look at the actual problems and the way the team needs to work together.
A Notion workspace for a straightforward organisation
Consider it for: bringing records, notes and projects into a space the team can maintain. Strength: the structure can evolve progressively. Watch for: data-entry and follow-up conventions still need defining. If only the person who created the workspace understands it, document the rules before adding more functions. A shared process should remain understandable when that person is unavailable.
An existing CRM for a shared sales process
Consider it for: managing sales stages, responsibilities and history in software designed around those uses. Strength: some required functions may already exist. Watch for: suitability for your journeys, permissions and the plan being evaluated. Try a representative record with a reminder and a handover between two people, rather than judging only the dashboard. Check what work still happens outside the tool.
A custom CRM for specific requirements
Consider it for: rules, documents or connections that evaluated products do not cover adequately. Strength: building around the defined process. Watch for: maintenance, documentation and future changes. Custom work deserves discussion when the gap is concrete, not merely because the business uses several applications. Define the functions that justify it and how the team will operate them after delivery.
A migration also needs preparation. Clean up duplicates, identify useful fields and test a small batch before transferring everything. Keep a reference copy so the results can be checked. Changing software without clarifying the information can simply move existing disorder into a newer interface.
Recognise when a CRM deserves consideration
The number of tools alone does not decide the question. Observe repeated problems: forgotten follow-ups, duplicate entry, incomplete customer history or difficult handovers. These are more useful signals than a general feeling that a growing company ought to own a more sophisticated platform.
If tracking works, keeping and improving it may be reasonable. If quality constantly depends on one person’s memory, define a more shared process. Before a custom CRM, compare existing options too. Custom work should address requirements that justify its design and ongoing maintenance, such as specific stages, permissions, documents or integrations.
Start with real work before choosing software
For a few days, record where information is received, copied, approved and used. Look for duplicate entry and waiting. This small process map helps distinguish an organisational issue from a development requirement. It also gives a provider concrete examples to investigate rather than a broad request for a better system.
A business that must connect projects, operations or documents may then consider software tailored to its processes. The starting point remains the same as in my initial system: knowing where information should live and what you want to be able to do with it.
FAQ: managing customer information in Notion
Can Notion be a first customer-tracking system?
It can fit if the chosen configuration covers your workflow and access needs. Begin with representative records and check everyday questions: next action, owner, documents and useful history. The important issue is less whether the application is called a CRM than whether people can find the information and reliably keep it up to date.
Should every application be replaced with one tool?
Not necessarily. A quick-capture tool, a tracking workspace and a document editor can have complementary roles. Know where the reference information lives and when a transfer occurs. If the same data is edited everywhere, coordination becomes difficult even with few applications. Clear ownership matters more than simply reducing the number of icons on a screen.
How can we avoid unnecessary properties?
For each field, ask which decision it supports and who will maintain it. If nobody can answer, leave it out of the initial trial. Add it when a real need appears. A mandatory field without a clear purpose creates work and often encourages approximate values, making the system look complete while reducing the reliability of its information.
When should we discuss a custom CRM with Umbeli?
When real records reveal specific limitations: frequent duplicates, unusual documents, inadequate permissions or missing integrations. Bring those examples to evaluate a custom CRM. Scoping should also test whether a clearer process or an existing product could meet the need with more proportionate effort. The project should respond to demonstrated requirements rather than an assumed need for custom software.