What CRM Means Here
Most CRM systems give you Contacts, Companies and Deals, and you adapt to them. This platform does the opposite: you define the datastores, and the CRM capabilities attach to whatever you defined.
Where to find it
Architect Panel → Data:
- Datastores — where you define contacts, organisations and opportunities
Architect Panel → Commercial:
- Boards & Pipeline — pipelines over any datastore
- Campaign Manager — campaigns to any datastore
The capabilities
- Pipelines — a board over a datastore, with stages carrying win probability and forecast category.
- Campaigns — e-mail, SMS or WhatsApp to an audience selected from a datastore.
- Consent and preferences — topic-level opt-outs that hold across every channel.
- Duplicate detection and merging — weighted matching, with merges that can be reversed.
None of these assume a particular shape of record. A pipeline works over opportunities, job applications, grant bids or planning applications equally.
Why this is better than a fixed model
Because the fields a fixed CRM gives you are never quite the ones your business uses, and the gap is filled with custom fields, notes and conventions that nobody outside the team understands.
Defining the datastore yourself means the record holds what you actually track, the forms and API follow from it, and the CRM capabilities apply to that rather than to an approximation of it.
Why it is harder to start
Being honest about the trade-off: an off-the-shelf CRM works on day one and constrains you afterwards. This asks you to decide your model first.
That decision is the most consequential thing you will do here, and it is worth an afternoon rather than an hour.
The usual shape
Most implementations end up with something like:
- Organisations — the companies or bodies you deal with.
- People — individuals, usually linked to an organisation.
- Opportunities — the things you are pursuing, with a value, a close date and an owner.
Start there and add only what you will actually use. Fields nobody fills in make every record look incomplete and every report unreliable.
What you do not have to build
The surrounding machinery is already there: audit, retention, permissions to row and field level, activity timelines, document generation, e-mail and SMS, the API, and reporting. You are defining a data model, not building a system.
Worked example
A consultancy defines three datastores — Organisations, People and Opportunities — with an Opportunity holding a value, an expected close date, an owner and a stage. A pipeline is pointed at Opportunities, campaigns at People, and a match policy at Organisations. Nothing about the model was inherited from somebody else's idea of a sales process.
Recommendations
- Design the datastores before enabling anything else.
- Start with three and add on evidence, not anticipation.
- Do not copy a fixed CRM's field list — you are not obliged to.
- Model what you track, not what a template suggests.