Was zurück ins CRM geht, und was niemals

Ein Werkzeug, das eine Einschätzung erzeugt, muss sie dorthin bringen, wo gearbeitet wird. Für ein Maklerbüro ist das nicht unsere Oberfläche, sondern onOffice. Der Weg dorthin heißt Rückschreiben, und er ist der Teil des Werkzeugs, bei dem ein Fehler am längsten unbemerkt bleibt.

Die Grundregel: eigene Felder, immer#

Naheliegend wäre, die eingeschätzte Kontaktart in das Standardfeld für Kontaktarten zu spiegeln. Das Büro müsste dann gar nichts einrichten, und die Einschätzung stünde sofort dort, wo alle hinschauen.

Das ist ausgeschlossen, und zwar per Test festgehalten. Das Standardfeld pflegt das Büro selbst. Es trägt eine Tatsache, die eine Person eingetragen hat. Eine automatische Einschätzung, die dorthin schreibt, überschreibt echte Daten mit einer Wahrscheinlichkeitsaussage, und beim nächsten Lauf wieder, und niemand kann später rekonstruieren, was ursprünglich dort stand.

KI-Ergebnisse gehen deshalb ausnahmslos in eigene Spiegel-Felder. Das kostet das Büro einen Einrichtungsschritt, und dieser Schritt ist der Preis dafür, dass der eigene Datenbestand unangetastet bleibt.

Die Zuordnung, die niemand geprüft hat#

Die erste Fassung wurde mit vorbelegten onOffice-Feldnamen ausgeliefert, übernommen aus dem Konto, in dem entwickelt wurde. In jedem anderen Konto war das erfundener Text. Beim ersten Öffnen der Einstellungen sahen alle sieben Bereiche fertig eingerichtet aus, und es gab kein Merkmal, an dem sich eine geprüfte Zuordnung von einer geratenen unterscheiden ließ.

Das Rückschreiben schrieb daraufhin in Felder, die es nicht gibt. Fehlertolerant, also lautlos.

Heute wird nur noch die Taxonomie ausgeliefert, also die Bedeutung eines Parameters und woran man ihn erkennt. Die Feldnamen sind leer. Die Verbindung entsteht im Konto, und jede Zuordnung trägt einen sichtbaren Zustand:

• verbunden, nachgewiesen gegen den Live-Katalog des Kontos,
• unbekannt, also gespeichert, aber im Katalog nicht gefunden,
• nicht gesetzt,
• ungeprüft, wenn der Katalog gerade nicht erreichbar ist.

Der Zustand „verbunden" wird ausschließlich gegen einen echten Katalogabruf vergeben. Eine Zuordnung, die man nicht von einer Behauptung unterscheiden kann, ist schlechter als gar keine, denn sie führt dazu, dass niemand nachsieht.

Leere Zuordnungen werden auf Wunsch automatisch aus dem echten Katalog gefüllt. Drei Regeln dabei: Es wird beim Vergleich normalisiert, es wird nie eine bestehende Zuordnung überschrieben, und Unklares bleibt leer. Automatisch zu raten wäre derselbe Fehler in Grün: Ein falsch gesetztes Signal im CRM ist schlimmer als ein leeres Feld.

Erfolg gemeldet, nichts angekommen#

Der zweite Befund ist der unangenehmste. Ein Feld für den Zeitstempel der letzten Einschätzung wurde geschrieben, kam in onOffice aber nicht an.

Die Ursache liegt in der Schnittstelle: onOffice quittiert einen Änderungsvorgang mit Erfolg, auch wenn es einen einzelnen Wert am Ende verwirft, etwa ein Datum in einer Schreibweise, die das Zielfeld nicht führt. Von außen ist das nicht von „es wurde geschrieben" zu unterscheiden. Die Notiz im Verlauf meldete Erfolg, im Datensatz stand nichts.

Zwei Ebenen stehen seitdem dagegen.

Die Schreibweise richtet sich nach dem Feldtyp aus dem Katalog, und zur Auswahl stehen für einen Zeitstempel nur noch Datumsfelder. Ein Datum in ein Textfeld zu schreiben geht technisch, führt aber genau zu den Formatproblemen, die den Wert später unbrauchbar machen.

Nach jedem erfolgreichen Schreibvorgang wird zurückgelesen, und zwar genau die geschriebenen Felder. Was nicht angekommen ist, steht danach im Verlauf des Kontakts und in der Rückmeldung der Aktion.

Die Rückleseprüfung ist bewusst nachsichtig nach oben: Ist der Datensatz gerade nicht lesbar, lautet das Ergebnis „keine Aussage", nie „Fehler". Fehlalarme liest nach dem dritten Mal niemand mehr, und dann ist auch die echte Warnung wertlos.

Der Eintrag ins Maklerbuch#

Das Rückschreiben in Felder hat einen strukturellen Nachteil: Es überschreibt bei jedem Lauf den Vorwert. Der Verlauf einer Einschätzung geht verloren. Wer wissen will, wie ein Kontakt vor einem halben Jahr eingeschätzt wurde, findet es nicht mehr.

Deshalb gibt es einen zweiten, optionalen Weg: eine Zeile im Maklerbuch des Kontakts. Der Schalter dafür ist in der Vorgabe aus, und das ist eine Entscheidung, keine Vorsicht. Der Verlauf eines Kontakts wird in manchen Büros täglich gelesen, und was einmal im Maklerbuch steht, bekommt die Schnittstelle nicht wieder heraus. Beide Seiten dieser Abwägung stehen im Klartext neben dem Schalter.

Wer ihn einschaltet, bekommt vier Zusicherungen:

Der Eintrag läuft vor dem Ausstieg „nichts zu schreiben". Stünde er dahinter, wäre er ausgerechnet in dem Fall verloren, für den es ihn gibt: in einem Konto ohne eine einzige Feld-Zuordnung.

Ohne lesbare Datensatznummer wird nichts geschrieben. Ein Eintrag im Verlauf des falschen Kontakts ist schlimmer als keiner.

Ohne inhaltlichen Satz wird nichts geschrieben. „Qualifizierung gelaufen" ohne Inhalt ist im Verlauf reines Rauschen, und Rauschen im Maklerbuch ist der schnellste Weg, dass niemand mehr hineinschaut.

Datum und Benutzer bleiben offen. onOffice stempelt selbst, und einen Mitarbeiter zu erfinden, der die Zeile nicht geschrieben hat, wäre die schlechtere Auskunft.

Wer die Zeile geschrieben hat#

Eine Verfeinerung, die spät kam und viel ausmacht: Ein Eintrag, den eine Person auslöst, etwa eine Notiz oder das Ergebnis eines Gesprächs, wird unter ihrem onOffice-Benutzernamen eingetragen. Ein Eintrag, den der Scan erzeugt, bleibt beim technischen Benutzer der Schnittstelle.

Der Grund ist eine Aussage über Verantwortung. Eine Maschine unter dem Namen einer Person wäre im Maklerbuch eine falsche Auskunft darüber, wer gehandelt hat. Umgekehrt gehört eine Notiz, die eine Kollegin geschrieben hat, unter ihren Namen und nicht unter „API".

Die Zuordnung zwischen einem Mitglied des Arbeitsbereichs und seinem onOffice-Benutzer wird in den Einstellungen gepflegt. Fehlt sie, entsteht sie beim ersten Bedarf über einen Abgleich der E-Mail-Adresse gegen die Benutzerliste und wird festgeschrieben. Gibt es keinen Treffer, bleibt das Feld leer und onOffice trägt den technischen Benutzer ein. Geraten wird nicht: „Maria Krause" gibt es in einem größeren Büro zweimal, den Benutzernamen einmal.

Fehler landen dort, wo jemand hinschaut#

Schlägt ein Rückschreiben fehl, geht der Fehler zwei Wege: als Protokollzeile mit der vollständigen Ursachen-Kette und als Systemnotiz in die Zeitachse des Kontakts.

Die Ursachen-Kette ist dabei kein Detail für Entwickler. Bei einer von onOffice abgelehnten Aktionsart steht die eigentliche Auskunft nicht in der obersten Fehlermeldung, sondern eine Ebene tiefer. Wer nur die oberste Zeile protokolliert, bekommt „Anfrage fehlgeschlagen" und beginnt zu raten. Genau das hat an anderer Stelle im System dazu geführt, dass ein Wartungslauf tagelang scheiterte und niemand sagen konnte warum.

Zusammengefasst#

Das Rückschreiben ist der Teil des Werkzeugs mit dem größten Schadenspotenzial: Es verändert Daten in einem System, das dem Büro gehört. Die drei Regeln, aus denen alles andere folgt, sind deshalb kurz. Eigene Felder, immer. Nach dem Schreiben zurücklesen. Und was nicht rückholbar ist, ist in der Vorgabe aus.