Custom CRM & business systems
Your company already has a process. We build the system that understands it.
A custom CRM is a system designed around the way your company works, instead of adapting the company to a standard CRM. We design CRM, internal platforms and management systems around how each company really works: its data, states, people, rules, operations, documents, automation and integrations.
When a generic tool forces the team to change the way it works, to keep parallel spreadsheets or to solve by hand what the software doesn't cover, the problem is probably no longer the process. It's the system.
- No approved document, no progress
- Only the owner can close
- Deadline passed → alert
When software stops fitting
When the business starts working around the software.
Generic software isn't bad. The problem appears when the software's model and the business's model stop matching. Then the team makes up the difference, and that compensation has recognisable signs.
The same information is entered in several places.
The customer exists in the CRM, in a spreadsheet and in the invoicing tool, and none of the versions is the complete one.
CRMNorthline Ltd.SheetNorthline Ltd.InvoicingNorthline Ltd.A spreadsheet exists because the CRM cannot represent part of the process.
It's usually called “Tracking”, it's on version three and one person maintains it.
ABCDTracking_v3PendingCopy of PendingImportant follow-ups depend on someone remembering.
There's no deadline in the system: there's a note, a phone reminder or memory.
Call on ThursdayCheck the contractWas it sent?Two systems need a person in the middle.
Someone copies data from one tool to another every week. That person is the integration.
System AA personSystem BThe team uses WhatsApp or email to complete what the CRM doesn't cover.
The process happens in conversations the system never sees.
Is this approved yet?
I think so, check the Drive
A simple status change requires several manual actions.
Change the status, notify someone, create a task, update a sheet and move a document: five steps for a single fact.
- 1 · Change status
- 2 · Notify
- 3 · Create task
- 4 · Update sheet
- 5 · Move document
Reports are assembled by hand from several sources.
Every month someone exports, cross-checks and corrects. The figure arrives late and with doubts.
- CRM export
- Sheet
If several of these scenes look familiar, the team is already doing the work the system should be doing.
What we mean by a business system
Before choosing what to call the system, we define what it has to understand.
CRM, ERP, internal platform, management software: the label comes later. Any system that supports an operation is made of the same nine pieces. Select one to see what it adds to the model.
The pieces of the model
- Type
- Account
- Channel
- Web
- Owner
- L. Vidal
- Deadline
- 12 days
- Requirement
- Mandatory
- Valid until
- 2027
- Due
- Thursday
- Priority
- High
What does the company manage?
Customers, cases, orders, projects, assets, documents: the real objects the team works with, with the data they need and not the data the software ships by default.
We don't design screens first. We design what exists, how it relates, what can happen, who can do it and what should happen on its own. The screens are the consequence.
The model at work
The same approach can model very different businesses.
A fictional case travels through the system: a customer opens a case, the case needs a document, the document creates a task, the task requires an approval and the approval produces a result. Switch lenses to see what the system understands at each moment.
System lenses
Who the customer is, where they came from, what the case is worth and who owns it.
- 01Customer
- Account · web channel
- Estimated value €18,000
- 02Case
- Open opportunity
- Sales: L. Vidal
- 03Document
- Proposal sent
- 04Task
- Follow-up in 3 days
- 05Approval
- Customer acceptance
- 06Result
- Active customer
Fictional scenario. Entities, states and rules are designed with each company.
What changes between companies is the entities, the states and the rules. What doesn't change is that they can be modelled.
CRM
A custom CRM understands the customer's real lifecycle, not just the contact list.
Storing customers and opportunities is the minimum. A CRM designed around the business knows where each customer came from, which phase they're in, who owns them, what they've been told, which document is missing and what should happen next.
- 03
- Opportunity
- What it needs
- Owner assigned
- What happens next
- Prepare the proposal
This cycle is an example. The stages, their requirements and their deadlines are configured around how each company really sells.
What a custom CRM can understand
- 01Customer types
- 02Acquisition channels
- 03Commercial states
- 04Owner and team
- 05Full history
- 06Communication
- 07Tasks and deadlines
- 08Related operations
- 09Documents
- 10Custom rules
Northline Ltd.
- Opportunities
- 2 open
- Last communication
- Yesterday · email
- Task
- Send proposal · Thursday
- Operations
- 1 in progress
- Documents
- Master agreement · in review
The commercial cycle stops being a generic funnel and becomes the company's own.
Operations
The customer is only one part of the system.
Many companies don't just manage relationships: they manage cases, orders, projects, files, installations, contracts or requests. That operational object is the real centre of the work, and the system has to connect it to the customer and to everything that happens to it.
Change the name. The model holds.
Case#2041
In progress- Owner
- L. Vidal
- Tasks
- 3 pending
- Documents
- 2 of 3 approved
- Deadlines
- Delivery in 12 days
- Communication
- Last message yesterday
- Rules
- Can't close without documentation
An object with a life of its own
The operation has its own states, deadlines and owners, separate from the customer's.
Everything that happens to it, in its record
Tasks, documents, messages, decisions and changes stay on the operation, not scattered across tools.
Relationship and delivery, without mixing
The commercial side and the operational side live in the same system, each with its own logic.
Several operations per customer
A customer can have many operations over time, each with its own history.
When the system understands the operational object, it stops being a CRM with extra fields and starts being the company's system.
States and workflows
The system knows where each thing is and what should happen next.
Almost every process has phases. A state change isn't a colour in a column: it can require information, restrict who acts, create tasks, notify someone, ask for a document or trigger an automation. Select a state to see what it controls.
- In review
- In review
- Required information
- Documentation attached
- Who can act
- Reviewers and owner
- What happens on entry
- The reviewer is notified; nobody else edits meanwhile
- Automatic
- Review deadline in 2 days → reminder
- Can move to
Example states. Every company has its own, and that is precisely what gets modelled.
A well-modelled workflow turns “where is this?” into a question nobody needs to ask.
Automation
If a rule is known and a task repeats, the system should be able to execute part of it.
Automation doesn't replace the team's judgement: it removes the mechanical work around each decision. These are examples of the kind of rules that can be designed; the actual rules are defined with each company.
New entry
- EventA lead arrives
- ConditionIt has the minimum data
- RuleDistribution by area or workload
- ActionAn owner is assigned and the first task is created
- ResultNobody is left unattended
Deadline approaching
- EventA deadline gets close
- ConditionFewer than N days left
- RuleStaged alert
- ActionAlert to the owner; if it passes, to their manager
- ResultDeadlines aren't missed
Document approved
- EventA document becomes approved
- ConditionIt was a process requirement
- RuleProgress gate
- ActionThe case moves to the next state and people are notified
- ResultThe file moves forward on its own
Record change
- EventA relevant field changes
- ConditionThe data exists in another system
- RuleSynchronisation
- ActionThe external system is updated
- ResultOne version of the truth
Inactivity
- EventA case doesn't change
- ConditionIt has had no activity for N days
- RuleStall detection
- ActionIt surfaces in its owner's follow-up list
- ResultNothing is forgotten
Form received
- EventA form is submitted
- ConditionThe fields are valid
- RuleStructuring
- ActionThe record is created with its data and its owner
- ResultNo copying by hand
Thresholds (days, amounts, workloads) are company parameters: they are configured, not programmed. In the system we have already built, dozens of rules of this kind run every day.
Documents
A document shouldn't end up as an attachment without context.
In many operations the document is the process: contracts, certificates, authorisations, reports, invoices. A custom system can treat them as what they are: pieces with a type, a state, an owner, requirements and consequences.
- Type
- Contract
- Belongs to
- Operation #2041
- State
- In review
- Owner
- Administration
- Requirement
- Mandatory to start
- Validation
- Pending review
- Approval
- Management
- Signature
- Required
- Valid until
- 31/12/2027
Lifecycle of a document
Requirements that block
A process can require specific documents before moving forward. Without them, the system doesn't allow the step and explains what's missing.
- Agreement approved
- Identity verified
- Certificate valid
Start blocked · 1 document missing
Approving unlocks
When a document is approved, the process it belongs to can move forward without anyone pushing it.
Expiring warns
Documents with a validity period raise alerts before they expire, not after.
Rejecting returns
A rejection sends the document back to its owner with the reason and creates the task to fix it.
Signing leaves a record
The signature, digital or recorded, keeps who, when and on which version.
Which documents, which requirements and which signatures are needed depends on each company.
The file stops being a folder and becomes a state of the process.
Communication in context
A message is almost never just a message. It belongs to something.
Emails, calls, messages and notes usually refer to a customer, a case, an operation or a task. When the system keeps that relationship, whoever opens the record knows what was said, when, and what needs doing.
- 01
Message
An email, a call or a message arrives.
- 02
Contact
The system identifies who it belongs to.
- 03
Operation
It links it to the case, order or project in progress.
- 04
Next action
Reply, create a task, change a state or notify someone.
Depending on the tools the company uses, communication channels can be integrated into the operational context: email, telephony, messaging or forms.
- Attached is the signed agreement. When do we start?
- Email linked to Northline · Case #2041
- Document “Master agreement” → Signed
- Task created: plan the kick-off · L. Vidal
Email
Threads are attached to the right record and available to the whole authorised team.
Calls
Every call can be logged with an outcome and a next step, and schedule the callback.
Messaging
Conversations stop living on one person's phone.
No important conversation should depend on who had it.
Permissions and responsibility
Each person works with the information and the actions that belong to their role.
An internal system needs to know who can view, edit, approve, assign, close, export or configure. Not as a restriction, but as the way for each person to have exactly their work in front of them.
| Scope | View | Edit | Approve | Assign | Close | Export | Configure |
|---|---|---|---|---|---|---|---|
| ✓ | ✓ | — | — | — | — | — | |
| ✓ | ✓ | ✓ | ✓ | ✓ | — | — | |
| ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
Visibility by scope
Their own, their team's or the whole, depending on the role.
Actions with an owner
Approving, closing or reassigning stay reserved to the right people, and the system enforces it even if someone tries another way in.
Traceability
Who did what and when is recorded with no extra effort.
Responsibility stops being a convention and lives in the system.
Integrations
The system shouldn't live in isolation.
The company already uses other tools: invoicing, website, email, calendar, payments or an old system that can't be switched off. The custom system connects to them so information moves on its own instead of being copied by hand. Select an example connection.
ERP / invoicing
- SourceCustom system
- DataClosed operation, customer and line items
- RuleWhen an operation is completed
- DestinationERP
What stops being done by hand
Creating the invoice or the order by copying data.
Possible integrations depend on each tool and on what its access allows. They are studied in the project; not all of them are always available.
With the connections in place, nobody has to be the integration.
Visibility
When the operation is structured, seeing it is a consequence.
A management system shouldn't just collect data. With the model in place, it can answer at any moment the question that matters: what is happening in the operation right now?
Cases by state
- New 9
- In review 11
- Approved 6
- In progress 17
- Blocked 3
- Completed 42
Pending work by owner
- L. Vidal7
- M. Serra5
- A. Roig4
- Unassigned2
Where it waits longest
- In review4.2 days
- Blocked3.5 days
- Approved1.1 days
Activity · last 14 days
Commercial pipeline
- Lead24
- Qualified15
- Proposal8
- Customer5
Fictional values. The real indicators are defined from what each company needs to decide.
What it answers
- How much is in each state
- What work is pending and whose
- Where the process gets stuck
- What activity there has been
- How the commercial side is going
- Which deadlines fall this week
Reports stop being assembled by hand because the data is born structured.
AI
AI makes sense when it can understand information or remove a repetitive decision.
Not as a wrapper around the product: as a concrete function inside the process, working on the system's data and with a person in charge of the decision. Some possibilities:
- Unstructured textStructured fieldsAn email or a free-text form becomes a record with its data in the right place.
- DocumentExtracted dataAmounts, dates, parties or conditions move from the PDF to the record, for review.
- ConversationQualificationA call or a chat is summarised and classified: what they want, how urgent, who it belongs to.
- Internal dataAssisted answerThe team asks the system about the operation and gets an answer based on its own data.
- ClassificationNext workflowAn entry is classified and routed to the right process, with the final decision recorded.
Hi, this is Northline. We need to renew the maintenance contract before 30 October, for both sites. Could you send us a proposal this week?
- Customer
- Northline
- Type
- Contract renewal
- Deadline
- 30 October
- Scope
- 2 sites
- Next action
- Send proposal · this week
AI works inside the process, on the system's data and rules. It doesn't make business decisions without control.
In a system we have already built, AI answers calls, completes requests over messaging and drafts documents, always with human review. Which functions make sense for each company is decided in the project.
CRM, system or platform
Maybe you need a CRM. Maybe you need something more.
These aren't packages or price tiers: they're three conceptual scopes. They help you understand which part of the company is going to live in the system.
02
Business system
Models the company's operational process: what happens after the sale, with its objects, states, documents, rules and automation.
- Everything above
- Operations, cases or orders
- States and workflows
- Documents and permissions
- Automation
Many projects start at the first scope and grow into the second when the process asks for it.
What matters isn't the name. It's how much of the company the system has to understand.
Generic versus custom
Generic software is useful when the business fits its model.
This isn't about attacking anyone. A standard CRM or ERP solves well what it was designed to solve. The question is whether your operation is what that software expected.
Generic system
You configure the business around the available structures.
It fits when
- The process looks like most others
- Complexity is low and stable
- Integrations aren't critical
- Adjustments fit in fields and views
Generic system · Custom system
Custom system
The structures are designed around the business.
It makes sense when
- The process is differentiating and part of the advantage
- Complexity is high or growing
- Workarounds multiply and already have an owner
- Integrations matter for day-to-day operation
- Manual operation costs more than the system
- The company needs its own logic
When the software's model and the business's model drift apart, every workaround is a symptom. A custom system removes the cause.
Technology
The architecture is decided after understanding the business.
Depending on the project, the system can be built on Odoo, on a custom web architecture or by combining both. The choice isn't a preference: it comes from concrete criteria.
How we decide
- 01Existing ecosystemWhich tools the company already uses and which must stay.
- 02Process complexityHow many entities, states and rules need modelling.
- 03IntegrationsWhich systems it must talk to and how often.
- 04ScaleExpected volume of data, users and operations.
- 05OwnershipWho controls the code, the data and the infrastructure.
- 06MaintenanceWho sustains it and with how much effort.
- 07EvolutionHow the system will change when the company changes.
What we build with
Odoo
A solid base when the company benefits from its ecosystem: users, permissions, activities, documents and custom modules on top. An important capability, not the mandatory answer.
Custom web architecture
A purpose-built application with React on the interface and Node.js or Python on the server, when the process, the scale or the experience call for it.
A database designed for the operation
PostgreSQL as the norm, with the data model as the first design decision.
APIs and integrations
Connections to external services and existing systems, with their synchronisation rules.
The right infrastructure
Whatever the project calls for: deployment, backups, environments and observability.
The business decides the architecture.Not the other way round.
Real experience
We have already turned a complex operation into a system.
This isn't theory. A complete real-estate operation was modelled into custom software that connects:
- Properties
- Clients
- Demand
- Matching
- Visits
- Operations
- Documentation
- Communication
- Automation
- Integrations
40K+
Properties managed
20+
Custom Odoo modules
70
Custom data models
45
Scheduled automatic processes
It's one real implementation, in one specific sector, and it demonstrates the engineering approach: understand the operation, model it and build the system around it. It isn't proof of every sector. It's proof that we know how to do it.
Names, business figures and client data are kept confidential.
When does it make sense?
When does building a custom system make sense?
- 01
The CRM no longer represents how the business operates.
- 02
Critical processes live in spreadsheets.
- 03
The same information is maintained in several tools.
- 04
The team repeatedly copies or reconciles data.
- 05
Important workflows depend on someone's memory.
- 06
The company has states or rules the current software cannot model.
- 07
Integrations have become important for day-to-day operation.
- 08
Management lacks a reliable view of what is happening.
- 09
You need software around a process unique to the company.
There's no headcount or revenue figure above which this makes sense. It makes sense when the process is worth more than the tool that holds it.
What we take responsibility for
You don't need to arrive with a technical specification.
You can arrive with “this is how our company works”. From there, the project can cover the system's full lifecycle:
01
Understand
- Process discovery
- Functional modelling
02
Design
- Data model
- Architecture
- Experience and interface
03
Build
- Interface
- Server and business logic
- Automation
- AI where it helps
04
Connect
- Integrations
- Data migration
- Testing
05
Operate
- Deployment
- Documentation
- Maintenance and evolution
The scope is defined with each company. What doesn't change is that the system has one responsible party from beginning to end.
The starting point
You don't need to know what the tool should be called.
Tell us what happens from the moment something enters your company until the process ends. These are the questions we start with, and what each answer becomes inside the system.
Select a question
What enters the process?
Requests, leads, orders, incidents: the starting point defines the entry entities and their channels.
Becomes
Entities and channels
How we approach the project
A project that starts with the company, not with the tool.
- 01
Understand
We study the real operation: people, information, tools and timing.
Diagnosis
- 02
Model
Entities, relationships, states and business rules.
Functional model
- 03
Architect
System, data, integrations and permissions.
Architecture
- 04
Build
Interface, logic and automation, in blocks reviewed with the team.
System
- 05
Connect
External tools and data migration.
Ecosystem
- 06
Operate
Deployment, measurement and evolution when the company changes.
Operation
Your system
Tell us how your company works today.
You don't need to arrive with a technical specification. Tell us what you manage, who is involved, which tools you use and where time gets lost. From there we can design the system that makes sense.