Getting Started with CRM

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.

Modelling Contacts and Organisations

Almost every CRM implementation has people and the organisations they belong to. How you relate them determines what you can ask later.

Where to find it

Architect Panel → Data:

• Datastores — where the model is defined
• Record Links — relationships that are events rather than structure
• Record Numbering — human references for both

Two datastores, not one

Resist holding organisations as a text field on a person. It looks simpler and it costs you everything interesting: you cannot list everybody at one organisation, cannot hold an address once, and cannot see that three enquiries came from the same company.

Two datastores with a relationship between them is barely more work and answers all of it.

People move between organisations

This is the modelling decision people regret. A person linked directly to one organisation cannot easily represent somebody who changes employer — and if you overwrite the link, the history of who they were when they dealt with you is lost.

Decide early whether you need that history. If you do, model the relationship as its own thing with dates on it rather than as a field on the person.

One person, one record

The commonest data quality failure is the same person existing several times because they came in through different routes. Set up a match policy on the people datastore before you start loading data, not after.

Duplicates are far cheaper to prevent than to merge, even with a merge feature that works well.

Hold contact details as fields, not free text

Campaigns need to know which field is the e-mail address and which is the phone number. Notes saying "best contacted on the mobile" are useful to a person and invisible to a segment.

Give both a reference

Set up record numbering on people and organisations. Quoting a database ID to a colleague is awkward, and a reference is what makes an import or an integration traceable later.

Use links for events

Structural relationships — this person belongs to that organisation — are fields. Things that happened — this enquiry was converted from that one, this organisation acquired that one — are record links, which carry who recorded them and when.

Plan for retention from the start

People records are personal data, and a CRM accumulates them faster than anything else in the business. Decide how long you keep a contact you have not spoken to, and configure it — otherwise the answer becomes "forever", and that is a decision you will have made by accident.

Worked example

An agency models Organisations and People separately, with employment held as a dated relationship so a contact who moves agency keeps their history at both. A match policy on People runs from day one. Three years later, "who have we ever dealt with at this company" is a query rather than an archaeology exercise.

Recommendations

• Separate people from organisations.
• Decide about job history early — it is expensive to retrofit.
• Set up matching before loading data.
• Configure retention on people at the start.

CRM and the Rest of the Platform

The CRM capabilities are not a separate product bolted on. They operate over the same datastores as everything else, which is where most of the value is.

Where to find it

Architect Panel → Commercial:

• Boards & Pipeline — pipelines
• Campaign Manager — campaigns

Architect Panel → Data:

• Datastores — the shared records
• Activity Stream — the timeline on each

Architect Panel → ERP - Setup:

• Documents — quotations and orders raised against the same records

One record, many views

An organisation in your CRM can be the same record that ERP raises invoices against, that case management logs complaints on, and that messaging sends letters to. There is no synchronisation, because there is no second copy.

That is the practical argument for doing CRM here rather than alongside: the integration problem that consumes most CRM projects does not exist.

The timeline is shared

Every record carries an activity stream. A sales call, a support case update, an invoice and a marketing e-mail can all appear on one organisation's timeline in order.

That is the view a salesperson actually wants before a meeting, and it is normally impossible without an integration project.

Pipelines are not only for sales

A board in pipeline mode works over any datastore with a stage field. Recruitment, grant applications, onboarding, planning consents, tender submissions — anything that moves through stages towards a won or lost outcome fits.

Do not assume the feature is only useful if you sell things.

Campaigns reach any datastore

A segment names a datastore, criteria, and which fields hold the contact details. So a campaign can go to customers, members, tenants, alumni or applicants — whatever you have modelled.

Permissions apply as normal

Row-level access, field security and classification all work on CRM records like any other. A salesperson can be restricted to their own accounts, and a commercially sensitive field hidden from everybody but the deal owner, without any CRM-specific mechanism.

So does the audit trail

Every change to a contact or opportunity is recorded with before-and-after values and a tamper-evident chain. That matters more than it sounds in a sales context — disputes about who changed a close date or a value are common, and here they are answerable.

Build the model once

The temptation, when a second team needs something similar, is to build them their own datastore. Resist it for the same reason as always: two models of the same thing diverge, and reporting has to reconcile them.

Worked example

An organisation's Organisations datastore serves sales, support and finance. A pipeline runs over Opportunities, complaints are cases against the same organisation, and ERP invoices reference it. Before a renewal meeting, the account manager reads one timeline containing the last campaign, two support cases and the outstanding invoice.

Recommendations

• Use one record per real-world thing, across every function.
• Consider pipeline mode for any staged process, not just sales.
• Apply the normal permission layers — there is nothing CRM-specific to learn.
• Never build a second contact datastore for a second team.