Warum Ihr CRM elf Filter-Editoren hat

Öffnen Sie ein ausgereiftes CRM und machen Sie diesen Test. Legen Sie in einer Listenansicht einen Filter an. Dann denselben Filter als Marketing-Segment. Dann als Bedingung in einer Automatisierung. Dann als Berichtsfilter. Vier Editoren, vier leicht unterschiedliche Sätze an Operatoren und mindestens eine Stelle, an der genau das fehlt, was Sie brauchen.

Das ist in der Kategorie fast überall so, und es liegt nicht daran, dass die Teams hinter diesen Produkten nachlässig wären. Es ist die vorhersehbare Folge davon, Filtern als Funktion statt als Engine zu behandeln. Die Kosten tragen Sie, jede Woche, in einer Form, die sich in einer Bewertung schwer benennen lässt, im Alltag aber offensichtlich ist.

Wie es dazu kommt

Ein CRM startet mit Listenansichten. Jemand schreibt einen Filter-Editor für Listenansichten. Zwei Jahre später kommt Marketing dazu, und das Marketing-Team braucht Zielgruppensegmente. Es könnte den Filter der Listenansicht wiederverwenden, aber dieser Code hängt an einer Tabellenoberfläche, setzt eine Seitengröße voraus und liegt in einem Modul, das dem Marketing-Team nicht gehört. Die pragmatische Entscheidung, die jede vernünftige Engineering-Leitung unter Termindruck trifft, ist ein eigener Segment-Editor.

Dann kommen Automatisierungen und brauchen Bedingungen. Dann Berichte, die Filter mit Gruppierung brauchen. Dann Berechtigungen auf Datensatzebene, im Grunde ein Filter, der unsichtbar auf jede Abfrage angewendet wird. Dann die KI-Suche, die einen Satz in eine Abfrage übersetzen muss. Jedes davon baut ein anderes Team, in einem anderen Quartal, mit einer anderen Deadline.

Nichts ist kaputt. Jeder Editor funktioniert. Aber sie entwickeln sich auseinander, und beim Filtern ist das besonders tückisch, weil die Unterschiede unsichtbar bleiben, bis sie zuschlagen:

• Die Listenansicht behandelt einen leeren Text und einen Nullwert gleich. Der Segment-Editor nicht.
• Die Listenansicht kann nach einem Feld eines verknüpften Datensatzes filtern. Der Berichts-Editor nur nach dem Objekt, das er gerade vor sich hat.
• Die Automatisierungsbedingung wertet Datumsangaben in UTC aus. Die Ansicht in Ihrer Zeitzone. Beides ist vertretbar; zusammen ergibt es einen Bug, der Sie einen Nachmittag kostet.
• Ein Editor kennt „ist eines von“. Ein anderer nur „ist gleich“, also bauen Sie drei Regeln mit ODER.

Das Ergebnis: Die Antwort auf „Kann ich danach filtern?“ ist nie Ja oder Nein. Sie lautet „Auf welchem Bildschirm sind Sie?“

Was es Sie wirklich kostet

Drei Dinge, nach steigender Bedeutung.

Sie lernen Filtern mehrmals

Jede neue Person im Team lernt vier Editoren statt einem, und lernt sie, indem sie die Unterschiede entdeckt. Das zeigt sich als langsame, nicht zuzuordnende Bremse beim Onboarding, für die niemand ein Ticket anlegt.

Logik wird neu eingegeben statt wiederverwendet

Sie definieren „Enterprise-Accounts ohne Aktivität seit dreißig Tagen“ in einer Ansicht. Später wollen Sie eine Kampagne an diese Zielgruppe, also bauen Sie sie im Segment-Editor nach. Dann eine Automatisierung, also bauen Sie sie noch einmal. Jetzt haben Sie drei Definitionen derselben Idee, von Hand gepflegt. Ändert sich die Definition (Enterprise heißt jetzt 200 Plätze statt 100), müssen Sie an alle drei denken. Das werden Sie nicht.

Funktionen kommen ungleichmäßig an, für immer

Das ist der Punkt, der sich aufschaukelt. Wenn das Produkt einen neuen Operator bekommt, landet er in dem Editor, den das zuständige Team pflegt. Nach fünf Jahren ist der Abstand zwischen Ihrer leistungsfähigsten und Ihrer schwächsten Filterstelle riesig, und jeder Wunsch an die Roadmap wird zu „In welchem der fünf hätten Sie es zuerst gern?“

Eine gespeicherte Ansicht, ein Marketing-Segment, eine Workflow-Bedingung, ein Berichtsfilter und eine Frage an die KI sollten dasselbe Objekt sein, das durch denselben Compiler läuft.

Die Alternative, und was sie verlangt

Die Alternative ist, das Filtern zu einer Engine zu machen, die alles andere nutzt. Eine einzige Darstellung eines Filters (eine strukturierte, serialisierbare Definition) und ein einziger Compiler, der daraus eine Datenbankabfrage macht. Jede Oberfläche wird zu einer anderen Art, dasselbe Objekt zu bauen oder anzuzeigen.

Das gibt es nicht umsonst. Es verlangt eine wirklich unbequeme Disziplin:

1. Das Filterformat muss vor den Funktionen entworfen werden, die es nutzen, also genau dann, wenn Sie sich bei den Anforderungen am wenigsten sicher sind.
2. Jede Stelle, die es nutzt, muss die gemeinsamen Regeln akzeptieren, auch die, die für ihren Bildschirm unpraktisch sind.
3. Niemand darf schnell einen Sonderfall einbauen. Ein Sonderfall in einer gemeinsamen Engine ist ein Sonderfall in fünf Produkten.
4. Sie brauchen Konformitätstests, weil eine kleine Abweichung im Compiler jetzt eine kleine Abweichung überall gleichzeitig ist.

Der Lohn: Funktionen kommen überall gleichzeitig an. Als wir das Navigieren über verknüpfte Datensätze ergänzt haben, erschien es am selben Tag in Ansichten, Segmenten, Automatisierungsbedingungen, Berichten, Berechtigungen und der KI-Suche, nicht weil sich fünf Teams abgestimmt hätten, sondern weil es immer nur eine Implementierung gab.

Was uns überrascht hat

Wir dachten, der Lohn wäre Effizienz in der Entwicklung. Der größere Lohn wird die KI sein.

Wenn Sie einem KI-Copilot eine Frage zu Ihren Daten stellen, muss er etwas liefern. Liefert er Fließtext, können Sie ihn nicht prüfen. Liefert er rohes SQL, kann er eine Abfrage erfinden, die Ihre Berechtigungen ignoriert oder auf eine subtile Weise falsch ist, die Ihnen nicht auffällt.

Weil wir bereits genau ein Filterformat haben, erzeugt die Suche in einfacher Sprache, die wir gerade bauen, genau dieses Format. Sie kommt demnächst, und deshalb wird sie vertrauenswürdig sein. Daraus ergeben sich drei Folgen ganz von selbst, und keine davon war der Grund für die Entscheidung:

• Sie kann keinen Filter ausdrücken, den das Produkt nicht ausführen kann: Das Format ist die Grenze.
• Sie übernimmt die Berechtigungen automatisch, weil es derselbe Compiler ist, der in der Oberfläche den Zugriff auf Datensatzebene durchsetzt.
• Sie können lesen, was sie geschrieben hat, es korrigieren und als Ansicht speichern. Die Antwort ist nachprüfbar, und einer nachprüfbaren Antwort können Sie irgendwann zutrauen, selbst zu handeln.

Die Architekturentscheidung, die nach interner Ordnung aussah, ist genau das, was die KI-Suche vertrauenswürdig statt dekorativ machen wird. So ist es meist mit Fundamenten: Der Grund, warum Sie froh sind, eines gebaut zu haben, ist selten der Grund, warum Sie es gebaut haben.

So prüfen Sie das selbst

Sie müssen einer Architekturaussage nicht blind glauben. Nehmen Sie sich beim Test eines beliebigen CRMs zehn Minuten dafür:

1. Legen Sie in einer Listenansicht einen etwas kniffligen Filter an, der einen verknüpften Datensatz und einen leeren Wert enthält.
2. Versuchen Sie, genau denselben Filter als Zielgruppe einer Kampagne anzulegen.
3. Versuchen Sie es noch einmal als Automatisierungsbedingung und dann als Berichtsfilter.
4. Stellen Sie der KI eine Frage, die denselben Filter ergeben sollte, und prüfen Sie, ob Sie sehen können, was sie ausgeführt hat.

Stimmen alle fünf überein, hat das Produkt eine Engine. Wenn nicht, haben Sie die elf Editoren gefunden, und Sie wissen jetzt, welchem der fünf im vierten Monat der Operator fehlen wird, den Sie brauchen.