A CRM and a task system are not the same thing

A builder sets out to buy software and is shown two categories that look alike. Both have lists, owners, due dates, statuses and reminders. Both salesmen say their product does the other one as well.

They are not the same kind of thing, and the difference is not features. It is what the record is about.

A CRM is organised around a person outside the company#

Its unit is a relationship with somebody who does not work for you and may never transact at all.

• The subject is outside your authority. You cannot assign him anything. You can only ask, offer, remind and wait.
• The horizon is months. Sometimes years. A buyer who enquired at launch and books at possession is a normal outcome.
• The hardest problem is identity. The same man enquires on a portal, at a hoarding number and through a broker, and arrives in your database three times over. Duplication and attribution — who gets credit, and therefore commission — are what a CRM lives or dies on.
• Most records end in nothing. This confuses people coming from an operations background. A pipeline where most enquiries never book is a healthy pipeline.

That last property decides the design. Because most records end in nothing, closing one has to be cheap and blameless. A CRM that makes people feel bad about closing leads accumulates a graveyard, which is also how a spreadsheet pipeline fails — leads that die in Excel.

A task system is organised around work inside the company#

Its unit is an obligation: something that must be finished by somebody who works for you or under contract to you.

• The subject is inside your authority. You can assign it, escalate it and demand a date.
• The horizon is days. A task open for months is not patient, it is stuck.
• The hardest problem is handover. Work rarely fails while somebody is doing it; it fails between two people, when one believes he has passed it on and the other has not accepted it — why tasks stall between people.
• A record that ends in nothing is a failure. The opposite of the CRM. An obligation that quietly evaporated is what the system exists to prevent.

Two systems, two opposite definitions of a healthy record. That is why the merged process is worse than either.

What breaks when you force one to be the other#

Leads modelled as tasks. Every enquiry becomes an item that must be completed. Buyers do not complete. So the list fills with items overdue through nobody's fault, the overdue count climbs past what any human reads, and the team learns that red means nothing. Once red means nothing, genuinely late internal work is red too, and invisible.

Worse, the task frame makes closure feel like failure. Nobody wants a column of items marked not done, so leads get rescheduled instead of closed, and you lose the closing reasons — the most valuable data a sales process produces.

Internal work modelled as leads. A pipeline has stages, not completion. A snag sitting in "in progress" is fine by the model, because a pipeline record can legitimately sit anywhere for a long time. There is no notion of done, therefore none of late, therefore no accountability that survives a busy week. Ageing reports become stage counts, which tell you where things are and never that something is wrong.

The tell is the same in both directions. Look at a screen and ask what an untouched record means. In a CRM, the buyer went quiet. In a task system, somebody failed. If one screen must mean both, it means neither, and people stop reading it.

The events that cross the boundary#

Here is the honest part: a builder needs both, and pretending otherwise is how offices end up with a CRM accounts hates and a task tool sales never open.

They do not need to be one system. They need to meet at a small set of events where something outside the company creates work inside it, or the reverse.

1. A booking. A buyer says yes, and work begins for accounts, CRM documentation, the legal desk and inventory. One relationship event spawns several obligations, each with its own owner and date.
2. A construction stage completing. An internal, physical fact becomes a demand on many buyers at once — the only event in the business that crosses from site to money to relationship in a single step.
3. A payment received or missed. Money changes the buyer's standing and creates internal work: reconciliation, receipting, and sometimes a collections action. Money owed to you and money you owe run on separate rails — two payment ladders.
4. A snag raised by a buyer. A relationship event that becomes site work, and must come back with an answer the buyer can see.
5. A possession or handover date. The one date that must be identical on both sides. When sales quote a month and site are working to another, the discrepancy is discovered by a buyer.

Five events. A few more in a particular office — a cancellation, a transfer — but the list is short and fits on one page.

Integrate at the events, not by merging#

The temptation is a single system: one record type, one inbox, one report. It fails for the reason above — the two record types have contradictory definitions of health, so any shared screen must lie about one of them.

What works is narrower. For each crossing event, decide four things and write them down.

• Which system is the source of truth for the fact. A booking is a sales fact. A stage completion is a site fact. Only one side may create it.
• What it creates on the other side, precisely — which obligations, with which owners and which dates.
• What flows back, and to whom. A buyer whose demand is unpaid should be visible to whoever is about to call him about possession.
• What happens when it is reversed. Cancellations, unwound bookings and withdrawn demands are the cases nobody specifies, and the ones that leave orphan work in a queue for years.

Ask a vendor to demonstrate these crossings rather than the feature list, alongside the other questions in choosing construction software. A product with a handsome pipeline and a handsome task board that cannot show what a booking does to accounts is two products in one window.

Which one we built#

Ours is a task system. It holds obligations, owners, dates, money and approvals; it has no lead pipeline, no buyer database and no broker ledger. Saying that plainly is more useful than pretending otherwise.

The one thing we do at that edge is small on purpose: a WhatsApp line marked for sales is answered from a pitch an admin writes, and every conversation lands as a card in the approvals queue for a person to pick up. That is a doorway, not a CRM.

The work a booking creates runs for years and has its own staffing problem — after the booking comes the longer job.

The short version#

A CRM tracks a relationship with somebody outside the company, over months, where most records ending in nothing is normal. A task system tracks an obligation inside the company, over days, where a record ending in nothing is a failure.

Forcing either to be the other produces a list nobody reads. Buy both if you must, but spend the evaluation on the events that cross between them — booking, stage, payment, snag, possession — because that is where the money and the goodwill leak.