Zwei Personen öffnen denselben Kontakt im selben CRM. Die eine sieht das Datum des letzten Anrufs, den Deal-Owner und die Renewal-Markierung. Die andere sieht nichts davon, weil die Spalten dem Layout, das sie gerade betrachtet, nie hinzugefügt wurden. Sie streiten nicht über Strategie. Sie streiten darüber, was der Datensatz aussagt, und beide haben recht, weil sie zwei unterschiedliche Anzeige-Oberflächen über demselben Datenbestand lesen.
Das ist die stille Fehlerquelle hinter den meisten „Unsere Zahlen passen nicht zusammen“-Gesprächen. Es ist selten ein Reporting-Problem. Fast immer ist es die Frage, wer welches Layout konfiguriert hat und wie viele dieser Layouts inzwischen existieren.
Früher kostete eine solche Uneinigkeit ein paar verwirrte Minuten in einem Call. Heute summiert sie sich. Sobald GTM-Teams KI-Agenten auf das CRM ansetzen, um Follow-ups zu entwerfen, Accounts zu bewerten und Datensätze zu aktualisieren, wird das System of Record zur Grundlage, aus der alles liest. Jason Lemkins Argument in seinem Beitrag von 2026 über agentenbasiertes CRM lautet, dass das CRM zur zentralen Drehscheibe wird, über die mehrere Agenten Historie abrufen und Signale zurückspielen. Wenn sich Ihre eigenen Mitarbeitenden nicht einig sind, was ein Datensatz zeigt, erben die Agenten, die denselben Datensatz lesen, diese Verwirrung in Maschinengeschwindigkeit.
Die Disziplin, die früher ein Nice-to-have war, ist also jetzt tragend. Eine unaufgeräumte Anzeigeschicht war verkraftbar, solange nur Menschen sie lasen. Sie ist es nicht mehr, wenn Software sie liest.
Das Anzeichen ist einfach. Bitten Sie zwei Personen aus demselben Team, denselben Account aufzurufen und zu beschreiben, was sie sehen. Wenn die Antwort „nun, in meiner Ansicht“ lautet, haben Sie es bereits gefunden. Die Daten darunter sind identisch. Die Layouts darüber nicht.
Jedes moderne CRM mit gespeicherten Ansichten, ob HubSpot, Salesforce oder Pipedrive, behandelt eine Ansicht als gespeicherte Konfiguration aus Filtern, sortierten Spalten und sichtbaren Eigenschaften. Das ist eine Bequemlichkeit. Das Problem beginnt, wenn aus Bequemlichkeit Privatbesitz wird: Jede Vertriebskraft, jede Führungskraft und jedes Team baut eigene gespeicherte Ansichten, und niemand löscht die alten.
Es ist keine Nachlässigkeit. Es ist das Standardverhalten eines flexiblen Tools. Jemand braucht im März eine Spalte für eine Kampagne und fügt sie einer persönlichen Ansicht hinzu. Eine Führungskraft will Deals für einen Forecast-Call nach Abschlussdatum sortiert und speichert das. Ein neuer Mitarbeiter kopiert eine bestehende Ansicht und passt sie an. Keines davon ist für sich genommen falsch. Sechs Monate später gibt es zwanzig gespeicherte Ansichten, die Hälfte davon im Besitz von Personen, die das Team gewechselt haben, und keine zwei zeigen dieselben Felder.
Das Ergebnis ist eine Anzeigeschicht, die sich von jeder gemeinsamen Definition des Datensatzes entfernt. Wenn jemand Informationen mit einer Kollegin teilt, findet die Kollegin sie nicht, weil sie einer Ansicht hinzugefügt wurde und der anderen nicht. Die Daten waren die ganze Zeit da. Sie waren nur von dem Standpunkt aus nicht sichtbar, an dem die Person gerade stand.
Hier ist der Reframe, der das Denken korrigiert. Eine gespeicherte Ansicht ist eine Anzeige-Entscheidung. Sie ist nicht die Daten, und sie ist nicht die Wahrheit. Layouts so zu behandeln, als trügen sie Bedeutung, ist der Weg, auf dem Teams am Ende Dashboards abgleichen, statt das Eigentliche darunter zu reparieren.
Das ist dieselbe Lektion, die Thomas Redman seit Jahren über Datenqualität vermittelt: In seiner Arbeit für die Harvard Business Review lautet das Argument, dass man Qualität an dem Punkt steuert, an dem Daten entstehen, und dass eine nachgelagerte Bereinigung teuer ist und nicht skaliert. Ansichten-Wildwuchs ist ein nachgelagertes Symptom. Jedes zusätzliche Layout ist ein weiterer Ort, an dem das Bild von dem aller anderen abweichen kann. Das beheben Sie nicht, indem Sie ein besseres Dashboard obendrauf bauen. Sie beheben es, indem Sie zuerst die Zahl der Oberflächen reduzieren.
Der Reflex, wenn Zahlen nicht zusammenpassen, ist, ein neues „Single-Source-of-Truth“-Dashboard zu bauen, dem alle vertrauen sollen. Das fügt eine Oberfläche hinzu. Es entfernt nicht die widersprüchlichen, also haben Sie jetzt eine Sache mehr, die synchron gehalten werden muss.
Spielen Sie das Gegenteil. Machen Sie bei Ihren gespeicherten Ansichten einen Behalten-, Anpassen-, Löschen-Durchgang, genauso wie bei einer aufgeblähten Pipeline oder einer überwucherten Eigenschaftsliste. Behalten Sie die wenigen geteilten Ansichten, aus denen das ganze Team liest. Passen Sie das Standard-Layout des Datensatzes so an, dass es die Felder enthält, die die Leute wirklich brauchen, damit niemand eine private Ansicht bauen muss, um sie zu sehen. Löschen Sie den Rest. Das Ziel ist nicht die mächtigste Ansicht. Es sind die wenigsten geteilten Ansichten, die die Aufgabe noch erfüllen, im Besitz des Teams statt einzelner Personen.
Machen Sie es nicht komplizierter als nötig. Die meisten Teams mit ein paar hundert Seats brauchen eine Handvoll geteilte Ansichten, nicht zwanzig private.
Wir haben kürzlich mit einem Series-B-B2B-SaaS-Team in der DACH-Region gearbeitet, das auf ein einziges CRM konsolidierte. Mittendrin öffneten zwei Personen in einer Working Session, was beide „die Kontakt-Ansicht“ nannten, und redeten aneinander vorbei, weil die Felder nicht übereinstimmten. Wir zählten die gespeicherten Ansichten auf den Kernobjekten. Allein auf Kontakten waren es mehr als ein Dutzend, mehrere im Besitz von Personen, die die Rolle gewechselt hatten, jede zeigte einen leicht anderen Ausschnitt.
Die Lösung war kein eigenes Migrationsprojekt. Wir sorgten dafür, dass das Standard-Kontaktlayout alles enthielt, was die individuelle Ansicht des Service-Teams hatte, holten die Zustimmung ein, die überflüssigen zu löschen, und etablierten die Erwartung, dass das Team aus geteilten Ansichten statt aus persönlichen arbeitet. Das Abgleich-Problem verschwand, weil es nichts mehr abzugleichen gab. Endlich betrachteten alle denselben Datensatz auf dieselbe Weise.
- Inventarisieren Sie jede gespeicherte Ansicht auf Ihren Kernobjekten. Listen Sie jede mit Owner und dem Zeitpunkt der letzten tatsächlichen Nutzung auf. Sie können nicht entscheiden, was wegfällt, bevor Sie den gesamten Wildwuchs an einem Ort sehen.
- Mustern Sie verwaiste Ansichten aus. Alles im Besitz von Personen, die das Team gewechselt haben oder gegangen sind, ist ein Löschkandidat. Niemand verteidigt sie, und sie sind die leichtesten Erfolge.
- Definieren Sie die geteilten Ansichten, aus denen das ganze Team liest. Ein kleiner Satz, nach Objekt und nach Rolle, nicht nach Person. Die Einheit des Besitzes ist das Team, sodass ein neuer Mitarbeiter am ersten Tag dieselbe Ansicht erbt wie alle anderen.
- Verschieben Sie die nötigen Felder in das Standard-Layout des Datensatzes. Die meisten privaten Ansichten existieren, weil im Standard eine Spalte fehlte. Setzen Sie diese Spalten in den Standard, und der Grund für eine persönliche Ansicht verschwindet.
- Löschen Sie die überflüssigen, und kontrollieren Sie neue Ansichten. Etablieren Sie die Norm, dass neue geteilte Ansichten über die Person laufen, die das CRM verantwortet, damit Sie nicht direkt wieder dorthin wuchern, wo Sie angefangen haben.
- Richten Sie Ihre Automatisierungen und Agenten auf dieselben geteilten Ansichten aus. Was Ihre Workflows und KI-Agenten lesen, sollte dasselbe Bild sein, das die Menschen lesen, damit Software und Menschen aus einem Datensatz arbeiten, nicht aus zweien.
Sie können einem Forecast, einer Automatisierung oder einem Agenten nicht vertrauen, der auf Daten läuft, die Ihr eigenes Team nicht durchgängig sehen kann. Sich auf geteilte Ansichten zu standardisieren ist unspektakulär, aber es ist der günstigste Zuverlässigkeitsgewinn im CRM, und ein Team auf geteilte Ansichten umzustellen ist meist ein halber Tag Arbeit, kein Projekt. Wenn Sie eine zweite Hand bei der Bereinigung wollen, ist genau das die Art von Aufgabe, für die unsere Arbeit in Revenue Operations und HubSpot-Implementierung gemacht ist. Für das angrenzende Problem, dies vor einem Go-live zu standardisieren, lesen Sie den begleitenden Beitrag über den Probelauf vor dem CRM-Go-live.
- Thomas Redman. „To Improve Data Quality, Start at the Source.“ Harvard Business Review, Februar 2020. hbr.org
- Jason Lemkin. „Which CRM Should You Use in 2026/2027? Follow the Agents.“ SaaStr, 2026. saastr.com