DB-Leads verstehenTeil 8 von 13
Die Einrichtung: sieben Felder, drei Stufen, eine Prüfschleife
Die naheliegende Lösung wäre ein Assistent, der die Felder anlegt. Die geht nicht, und der Grund liegt nicht bei uns. Teil 8 der Serie über einen Einrichtungsweg, der sich selbst kontrolliert.
REOSA-Team · 05.09.2026 · 5 Min. Lesezeit
- Warum kein Assistent die Felder anlegen kann
- Die sieben Felder und ihre drei Stufen
- Die Auswahlwerte kommen aus dem eigenen Konto
- Vier Befunde je Feld
- Geprüft wird gegen die Zuordnung, nicht gegen den Namen
- Kein Vorschlag zeigt auf ein Standardfeld
- Der zweite Teil: welche Felder die Analyse lesen darf
- Was die Einrichtung insgesamt kostet
Ein Werkzeug, das Ergebnisse ins CRM zurückschreibt, braucht dort Felder, in die es schreiben darf. Die naheliegende Lösung wäre ein Einrichtungsassistent, der sie anlegt. Sie geht nicht, und die Gründe sind einen Absatz wert, weil sie erklären, warum die Einrichtung so aussieht, wie sie aussieht.
Warum kein Assistent die Felder anlegen kann#
| Weg | Warum er ausfällt |
|---|---|
| Die Datensatz-Schnittstelle | Legt Datensätze an, keine Felder. In der Ressourcenliste gibt es schlicht keinen Feld-Typ. |
| Die Feld-Abfragen | Die Feldkonfiguration ist ausdrücklich lesend. Es gibt kein Gegenstück zum Schreiben. |
| Eine Marktplatz-App in onOffice | Läuft als eingebettetes Fenster im Kontext der angemeldeten Person, nicht mit Adminrechten. Kein Zugriff auf die Administration. |
Feld-, Kategorie- und Maskenverwaltung liegt ausschließlich in der Enterprise-Administration, also unter Extras, Einstellungen, Administration, Eingabefelder. Das ist kein fehlender Endpunkt, sondern eine bewusste Grenze von onOffice, und sie ist richtig gezogen: Eine Schnittstelle, die die Datenstruktur eines Kontos verändern darf, ist ein Risiko, das kein Softwarehaus sinnvoll vergeben kann.
Also: keine Automatik. Stattdessen eine Anleitung, die ihre eigene Befolgung prüft.
Die sieben Felder und ihre drei Stufen#
Der Bauplan nennt sieben Felder, jedes mit einem Namen zum Kopieren, der geforderten Feldart, seinem Zweck und seiner Stufe.
Stufe Minimum, zwei Felder. Eine Zusammenfassung und ein Stand. Damit ist jede Einschätzung in onOffice sichtbar: Was hat die Analyse gefunden, und wo steht der Kontakt. Wer nur diese zwei anlegt, hat ein vollständig funktionierendes Werkzeug.
Stufe Standard. Felder, mit denen man in onOffice filtern kann: die eingeschätzte Verkaufsbereitschaft, die erkannten Signale, der Zeitstempel der letzten Einschätzung.
Stufe voll. Der Rest, unter anderem eine Einordnung in Personengruppen und ein Feld für die explizite Verkaufsabsicht.
Die Stufen sind der entscheidende Teil dieser Einrichtung. Sieben Pflichtfelder wären eine Hürde, an der ein Büro abbricht, bevor es je einen Fund gesehen hat. Zwei Pflichtfelder sind zehn Minuten Arbeit. Der Rest kann kommen, wenn das Werkzeug seinen Wert gezeigt hat.
Die Auswahlwerte kommen aus dem eigenen Konto#
Ein Feld wie „Stand" ist ein Auswahlfeld, und die Werte darin müssen zu dem passen, was das Büro tatsächlich verwendet. Deshalb wird der Bauplan aufgelöst, bevor er angezeigt wird: Die vorgeschlagenen Auswahlwerte stammen aus der Taxonomie dieses Arbeitsbereichs, und beim Feld für den Akquise-Stand aus den echten Phasen der Pipeline.
Ein Bauplan mit Beispielwerten aus einem fremden Konto wäre wieder derselbe Fehler wie bei den vorbelegten Feldnamen aus Teil 7: Er sieht fertig aus und ist erfunden.
Vier Befunde je Feld#
Die Prüfung vergleicht den Bauplan gegen den echten Feldkatalog des Kontos und kennt vier Ergebnisse:
- in Ordnung, Feld existiert, Typ passt, Werte vorhanden,
- falscher Typ, Feld existiert, aber die Feldart passt nicht,
- Werte fehlen, Feld und Typ passen, aber einzelne Auswahlwerte fehlen,
- fehlt, kein solches Feld im Konto.
Ist der Katalog gerade nicht abrufbar, lautet der Befund ausnahmslos unbekannt. Nicht „in Ordnung" und nicht „fehlt". Beides wäre eine Behauptung über einen Zustand, den man gerade nicht sehen kann.
Der Befund „falscher Typ" ist der Grund, warum die Prüfschleife überhaupt existiert. Eine Anleitung ohne Kontrolle endet bei „ich habe das doch angelegt" gegen „es kommt nichts an", und die Ursache ist dann meistens die Feldart: Eine mehrsätzige Zusammenfassung in einem einzeiligen Textfeld wird abgeschnitten. Das fällt erst auf, wenn im CRM ein halber Satz steht, und dann sucht jemand den Fehler bei der Analyse.
Geprüft wird gegen die Zuordnung, nicht gegen den Namen#
Die wichtigste Regel der ganzen Einrichtung: Geprüft wird gegen die bestehende Zuordnung, nicht gegen den vorgeschlagenen Feldnamen.
Wer sein Feld beim Anlegen anders benannt hat und es in den Einstellungen korrekt zugeordnet hat, ist fertig. Ihn zum Anlegen eines zweiten Feldes mit unserem Wunschnamen aufzufordern, wäre der sicherste Weg, ein sauberes Setup kaputtzumachen. Es entstünden zwei Felder mit derselben Bedeutung, eines davon leer, und in einem Jahr weiß niemand mehr, welches gilt.
Der Namensvorschlag ist ein Vorschlag. Er existiert für den Fall, dass jemand bei null anfängt und sich nichts ausdenken will.
Kein Vorschlag zeigt auf ein Standardfeld#
Auch hier gilt die Regel aus Teil 7, und sie ist im Bauplan verankert: Kein einziges der sieben Felder ist ein onOffice-Standardfeld. Naheliegend wäre, die eingeschätzte Kontaktart in das vorhandene Standardfeld zu spiegeln und dem Büro die Einrichtung zu ersparen. Genau das ist ausgeschlossen. Standardfelder pflegt das Büro, Einschätzungen gehören in eigene Felder.
Der zweite Teil: welche Felder die Analyse lesen darf#
Neben den Zielfeldern für das Rückschreiben gibt es eine zweite Einstellung: welche onOffice-Felder die Analyse überhaupt sehen darf.
Der erste Entwurf übergab neun fest verdrahtete Felder. Was ein Maklerbüro sonst pflegt, also Vorqualifizierungs-Status, Objektwunsch, Finanzierungsstand, eigene Merkmale, erreichte die Analyse nie, auch bei perfekter Zuordnung nicht. Ein gewachsenes onOffice hat Dutzende eigener Felder, und genau die tragen die Information, aus der sich etwas ableiten lässt.
Heute ist es ein Häkchen je Feld. Der onOffice-Anzeigename wird zum Schlüssel, unter dem der Wert bei der Analyse ankommt: „Status Vorqualifizierung: Angeschrieben". Ein technischer Feldname wie „ind_2072_Feld_adressen10" sagt einem Sprachmodell nichts, der Anzeigename sagt alles. Optional kommt ein Satz Erklärung dazu, wenn der Name allein nicht reicht.
Zwei Feinheiten dabei:
Gesperrte Felder. Felder, deren Inhalt ein geschütztes Merkmal ist, also Geburtsdatum, Alter, Geschlecht, Herkunft, Religion, Familienstand, Gesundheit, sind als Analyse-Kontext nicht wählbar. Durchgesetzt wird das an zwei Stellen: beim Speichern und noch einmal beim Zusammenstellen des Prompts. Die Oberfläche ist Bedienkomfort, keine Sicherheit, und ein Feld kann nach dem Freischalten in onOffice umbenannt worden sein. Mehr dazu in Teil 9.
Eine Ersatz-Ordnung für die Auswahl. onOffice liefert Kategorien nur für Felder, die für die Adressvervollständigung markiert sind. Gemessen in einem echten Konto waren das 20 von 123 Adressfeldern, und 30 der 34 eigenen Felder hatten keine. Eine Sammelgruppe mit 103 Einträgen ist keine Gruppierung, sondern eine Liste mit Überschrift, und ausgerechnet die eigenen Felder wären darin vergraben gewesen. Deshalb wird eine Ersatz-Ordnung abgeleitet: eigene Felder zuerst, dann nach Art des Inhalts. Echte Kategorien behalten Vorrang.
Die Reihenfolge folgt der Frage, mit der jemand diese Seite öffnet: Welches Feld weiß etwas über diesen Kontakt? Eigene Felder sind in den meisten Konten die Antwort, denn ein Büro legt ein Feld nur an, wenn es etwas festhalten will.
Was die Einrichtung insgesamt kostet#
Realistisch: eine halbe Stunde für die zwei Pflichtfelder samt Zuordnung, plus die Zeit, die eine Person braucht, um die eigenen Felder für den Analyse-Kontext durchzugehen. Letzteres ist der Schritt, der über die Qualität der Ergebnisse entscheidet, und der einzige, den niemand sonst erledigen kann: Welche Felder in diesem Büro Bedeutung tragen, weiß nur dieses Büro.