Two people open the same contact in the same CRM. One sees the last call date, the deal owner, and the renewal flag. The other sees none of those, because the columns were never added to the layout they happen to be looking at. They are not arguing about strategy. They are arguing about what the record says, and they are both right, because they are reading two different display surfaces over one set of data.
This is the quiet failure mode behind most “our numbers don’t match” conversations. It is rarely a reporting problem. It is almost always a question of who configured which layout, and how many of those layouts now exist.
The cost of disagreement used to be a few confused minutes on a call. Now it compounds. As GTM teams point AI agents at the CRM to draft follow-ups, score accounts, and update records, the system of record becomes the substrate everything reads from. Jason Lemkin’s argument in his 2026 piece on agentic CRM is that the CRM is becoming the central hub where multiple agents pull history and push signals back in. If your own reps cannot agree on what a record shows, the agents reading that same record inherit the confusion at machine speed.
So the discipline that used to be a nice-to-have is now load-bearing. A messy display layer was survivable when only humans read it. It is not survivable when software does.
The tell is simple. Ask two people on the same team to pull up the same account and describe what they see. If the answer is “well, in my view,” you have already found it. The data underneath is identical. The layouts on top of it are not.
Every modern CRM that ships saved views, whether HubSpot, Salesforce, or Pipedrive, treats a view as a saved configuration of filters, sorted columns, and visible properties. It is a convenience. The problem starts when convenience becomes private property: every rep, every manager, and every team builds their own saved views, and nobody deletes the old ones.
It is not negligence. It is the default behavior of a flexible tool. Someone needs a column for a campaign in March, so they add it to a personal view. A manager wants deals sorted by close date for one forecast call, so they save that. A new hire copies an existing view and tweaks it. None of these are wrong on their own. Six months later there are twenty saved views, half of them owned by people who have moved teams, and no two of them show the same fields.
The result is a display layer that drifts away from any shared definition of the record. When someone shares information with a teammate, the teammate does not find it, because it was added to one view and not the other. The data was there the whole time. It just was not visible from where they were standing.
Here is the reframe that fixes the thinking. A saved view is a display choice. It is not the data, and it is not the truth. Treating layouts as if they carry meaning is how teams end up trying to reconcile dashboards instead of fixing the thing underneath.
This is the same lesson Thomas Redman has been making about data quality for years: in his work for Harvard Business Review, the argument is that you control quality at the point where data is created, and that cleaning it up downstream is expensive and does not scale. View sprawl is a downstream symptom. Every extra layout is one more place where the picture can diverge from everyone else’s. You do not fix that by building a better dashboard on top. You fix it by reducing the number of surfaces in the first place.
The instinct when numbers do not match is to build a new “source of truth” dashboard that everyone is supposed to trust. That adds a surface. It does not remove the conflicting ones, so now you have one more thing to keep in sync.
Run the opposite play. Apply a keep, edit, delete pass to your saved views the same way you would to a bloated pipeline or an over-grown property list. Keep the small number of shared views that the whole team reads from. Edit the default record layout so it carries the fields people actually need, so nobody has to go build a private view to see them. Delete the rest. The goal is not the most powerful view. It is the fewest shared views that still do the job, owned by the team rather than by individuals.
Do not overcomplicate it. Most teams under a few hundred seats need a handful of shared views, not twenty private ones.
We recently worked with a Series B B2B SaaS team in the DACH region consolidating onto a single CRM. Partway through, two people on a working session opened what they each called “the contacts view” and started talking past each other, because the fields did not line up. We counted the saved views on the core objects. There were more than a dozen on contacts alone, several owned by people who had changed roles, each showing a slightly different slice.
The fix was not a migration project of its own. We made the default contact layout carry everything the service team’s custom view had, got agreement to delete the redundant ones, and set the expectation that the team works from shared views rather than personal ones. The reconciliation problem disappeared, because there was nothing left to reconcile. Everyone was finally looking at the same record the same way.
- Inventory every saved view on your core objects. List each one with its owner and the last time it was actually used. You cannot decide what to cut until you can see the full sprawl in one place.
- Decommission orphaned views. Anything owned by someone who has changed teams or left is a candidate for deletion. Nobody is defending those, and they are the easiest wins.
- Define the shared views the whole team reads from. A small set, by object and by role, not by individual. The unit of ownership is the team, so a new starter inherits the same view as everyone else on day one.
- Move the needed fields into the default record layout. Most private views exist because the default was missing a column. Put those columns in the default and the reason to build a personal view goes away.
- Delete the redundant ones, and gate new views. Set the norm that new shared views go through whoever owns the CRM, so you do not sprawl straight back to where you started.
- Point your automations and agents at the same shared views. Whatever your workflows and AI agents read should be the same picture the humans read, so software and people work from one record, not two.
You cannot trust a forecast, an automation, or an agent that runs on data your own team cannot consistently see. Standardizing on shared views is unglamorous, but it is the cheapest reliability win in the CRM, and moving a team onto shared views is usually a half-day of work rather than a project. If you want a second set of hands on the cleanup, that is exactly the kind of thing our revenue operations and HubSpot implementation work is built to handle. For the adjacent problem of standardizing this before a migration goes live, read the companion piece on the CRM go-live dry run.
- Thomas Redman. “To Improve Data Quality, Start at the Source.” Harvard Business Review, February 2020. hbr.org
- Jason Lemkin. “Which CRM Should You Use in 2026/2027? Follow the Agents.” SaaStr, 2026. saastr.com