Where client data lives isn’t a tool choice

Every team I’ve worked with has had the same argument, and it’s the wrong argument.

Should the client’s data live in the CRM or the project tool?

It sounds like a tool question. It isn’t. It’s a boundary question wearing a tool question’s clothes, and teams that treat it as “pick one” end up with the worst of both outcomes: the same data sitting in two places, quietly disagreeing with itself.

Sales and customer success want the account in the CRM, because that’s where they manage the relationship. Delivery wants it in the project tool, because that’s where the work actually happens. Both are right. That’s exactly why the argument never resolves.

So teams compromise, and the compromise is the real failure. They put the important fields in both tools. Now the renewal date is in the CRM and in the project workspace. The account owner is in both. The status is in both. Two writable copies of the same fact, maintained by different people, drifting a little further apart every week. Six weeks later nobody can tell you which one is right, so they stop trusting both and go ask a person.

The way out is to stop asking which tool the data belongs to, and start asking what job the data is doing.

A field isn’t CRM data or project data by nature. It becomes one or the other based on the question it answers and the person who asks it. The CRM’s job is the relationship and the commercial truth. The project tool’s job is the work you owe. Draw the border by the job, not by whoever happened to type the field first.

For most of your data, the border is obvious the moment you look for the job.

The CRM owns the relationship and its commercial state: who the client is, their firmographics, the deal, the contract value, the renewal date, the account owner, the commercial stage, the history of every touch. Anyone answering “what is our commercial relationship with this account?” is standing in the CRM.

The project tool owns the work: the deliverables, the tasks, who is doing what by when, the delivery status, the actual output. Anyone answering “what is the state of the work we owe this client?” is standing in the project tool.

That’s the clean test. If the field answers a question about the relationship, it’s CRM. If it answers a question about the work, it’s the project tool.

The obvious fields sort themselves. The trouble is the gray zone: onboarding status, account health, next steps, the notes from the last call, the general sense of “where are we with them.” These feel like they belong everywhere, so they get copied everywhere, and the gray zone is where almost all the drift is born.

Every one of those fields still has a single job. You just have to make yourself ask. Four questions settle any field that won’t sort itself.

1. What job is this data doing, managing the relationship or doing the work? Relationship goes to the CRM, work goes to the project tool. Most fields answer on the first question, and you never reach the other three.

2. Who reads it, and where are they already standing? The person deciding whether to renew or expand an account lives in the CRM all day. The person asking whether a deliverable is late lives in the project tool. Put the field where its reader already works, not where it was convenient to enter.

3. Which single system is allowed to change it? Every field gets exactly one owner that can write it. The other system is allowed to show it, read-only, kept in sync. Two writable copies is not a backup. It’s a promise that they will eventually disagree.

4. What does a wrong value cost, and on which side does the cost land? A wrong renewal date loses you a renewal, and that is commercial, so it belongs to the CRM. A wrong due date slips a deliverable, and that is delivery, so it belongs to the project tool. When a field is genuinely ambiguous, the cost of getting it wrong tells you who should own it.

Every one of those questions points at the same rule: one owner per field. One system writes it, everyone else reads a synced copy they are not allowed to edit.

That single constraint is what kills the drift. The renewal date lives in the CRM and shows up, read-only, in the project workspace, so delivery can see it without touching it. The delivery status lives in the project tool and shows up, read-only, on the CRM record, so the account owner can see it without touching it. Same facts, visible on both sides, each with exactly one place it can actually change.

The question was never CRM or project tool. It’s both, always, but never both for the same field.

Draw the border by the job the data does. Give every field one owner. Let the other side read a copy it isn’t allowed to argue with. Do that, and your two systems stop competing to be the source of truth. Each one becomes the source of truth for the questions it was built to answer, and the space between them stops being the place your data goes to get duplicated.

Talk soon,

Marco

Founder / CEO, Novrith