Lead, contact, company, deal, project: the five records a CRM actually needs

Ask ten teams what a CRM is and you get ten answers: a contact list, a pipeline board, a place where the sales notes go. Then look at their data. The same customer sits there four times — once as a lead from a form, once as a contact typed in by hand, once as a line in a spreadsheet of deals, once as an email thread nobody linked to anything.

The tool is rarely the reason. The reason is that nobody decided what each record is for. This is the model we use in Nextora, and the questions each record answers.

Five records, five different questions

Every record type answers a different question. The temptation is to keep everything in one of them — a single "customer" object with fifty fields. Resist it: the split is exactly what later makes filtering, counting and automation possible.

A lead is not a bad contact. It is a different state of knowledge: someone raised a hand, and you do not yet know whether it is real. Keeping unqualified enquiries out of your contact list is what keeps the contact list worth trusting.

The path a customer takes

The order is not dogma — you can create a contact with no lead, or a deal with no project. But this is the standard path, and it is the one the reports count:

1. The enquiry lands as a lead, with a status and a source, so that later you can see which channel actually worked.
2. The lead checks out: you create a contact for the person and a company for the organisation.
3. There is something to sell — a deal is created and dropped into the right pipeline.
4. The deal moves along the stages on the board until it reaches Won or Lost.
5. You won — a project opens and the work moves there, with its tasks, milestones and dates.

A concrete run through it: Meridian Technologies fills in the website form and a lead appears — "Meridian Technologies, integration". A rep calls, creates a contact for Anna at Meridian and a company record for Meridian Technologies, then a 48,000 deal in the Sales pipeline. A month later the deal reaches Won and a project — "Meridian · rollout" — opens underneath it.

Nothing was retyped. Each step added the one thing that became true.

Links are the product

Records do not live alone. A lead has its deals and tasks, a company has its people, a deal has its contact and its company. In Nextora the arrow on the left of any list row opens the Relations panel, grouped by type; from there you link an existing record or create a new one already linked.

This is the part teams skip, and it is the part that pays. Conversations, calls and documents surface on a record through its links. Link things as you go and a customer's history assembles itself; link them "later" and you get a database of orphans.

One detail worth stealing regardless of the tool you use: when a linked record is deleted, the link should not vanish. In Nextora the row stays, dims and is marked deleted. A row that quietly disappears reads as "there never was a link" — which is a lie your future self will believe.

Where the model pays off

Reporting stops being an argument

"How many enquiries did we get last month?" is a question about leads. "What is in the pipeline?" is a question about deals. "Are we delivering what we sold?" is a question about projects. When those live in one object, every number needs a caveat, and reporting turns into a negotiation about what counts.

Automation gets something to hold on to

Automation is built on events that happen to records: a lead is created, a deal enters a stage, a deal sits in a stage too long, a field changes, nothing happens for N days. Those events only exist if the record types exist. A workflow like "when a lead is created with status Qualified, assign a task to the owner and send the welcome email" is one rule — but only in a model where "lead" and "status" mean one thing. We wrote about picking the right tool for that job in pipeline, workflow, form or template.

Operations inherit the same customers

The moment you invoice, ship or manufacture, you need the customer again. In Nextora the ERP contour is not a second database: the company you invoice is the same company record as in the CRM, and switching contours is just following a link. That is only possible because the customer was modelled once.

Four modelling mistakes worth avoiding

• Turning every enquiry into a contact. Your contact list becomes a list of strangers, and every count based on it is wrong.
• Tracking money on the contact. One person can be involved in five deals across two companies. A number on a person cannot answer "what is in the pipeline".
• Running delivery inside the deal. A deal is closed once; delivery has phases, owners and dates. Squeeze one into the other and you lose the ability to say what is late.
• Custom fields instead of records. If you find yourself adding "second contact person" and "third contact person", you are describing a company, not a field.

Start with the chain, not with the fields

When teams set up a CRM they usually start with fields — which columns, which statuses, which required values. Start one level up. Get the chain right: enquiry, person, organisation, money, work. Once it clicks, the product stops being a pile of separate tables and becomes one flow, and the fields sort themselves out.

You can see the model working end to end on the CRM workspace page, and how delivery picks it up on projects.