Eine Frage, fünf Bereiche: Wie der CRM-Assistent über Module hinweg liest
Die Frage klingt nach einem Satz: Welche Lieferantenrechnungen sind überfällig, und ist genug Geld auf dem Konto, um sie zu bezahlen? Um sie zu beantworten, öffnet ein Mensch fünf Stellen — Lieferanten, Bestellungen, Lieferantenrechnungen, Bankkonten, Bankumsätze. Ein ERP würde einen Bericht verlangen. Ein CRM-Assistent muss lesen.
Der Assistent in Firmspace ist keine Datenbank mit Chatfenster. Er arbeitet mit einer festen Liste von Werkzeugen, jedes an einen Bereich des CRM gebunden. Die Seiten, nach denen am häufigsten gefragt wird, haben eigene Werkzeuge: Kontakte, Firmen, Deals, Aufgaben, Rechnungen, Ausgaben, Lager, E-Mails, hochgeladene Dokumente. Den Rest deckt ein allgemeiner Leser ab, browse_data.
Dieser Leser kennt sechzehn Arten von Datensätzen: Lager, Lagerbewegungen, Verkaufsaufträge, Angebote, Verträge, Lieferanten, Bestellungen, Lieferantenrechnungen, Produktionsaufträge, wiederkehrende Rechnungen, Bank- und Kassenkonten, Bankumsätze, Anlagegüter, Kalendereinträge, Gespräche und Projekte. Dazu öffnet er die eigenen Tabs — Automatisierungsregeln, Marketingbereiche, Lagerbereiche — über einen Schlüssel wie automation:rules.
Die wichtige Grenze liegt in der Form des Aufrufs. Ein Aufruf liest eine Art von Datensatz. Der Leser kann zwei Tabellen nicht verbinden, nicht über sie hinweg summieren und keiner Beziehung von selbst folgen. Er fragt Lieferantenrechnungen ab und bekommt Zeilen; er fragt Bankkonten ab und bekommt Zeilen; die Verbindung entsteht in der Antwort, nicht in einer Abfrage. Deshalb braucht eine Frage über fünf Bereiche mehrere Schritte — und deshalb kann die Antwort ehrlicher sein als ein Bericht, der still die falschen Schlüssel verbindet.
Jeder Aufruf liefert die Gesamtzahl der Treffer und nur die erste Seite davon. Die Standardseite sind fünfzehn Zeilen, das Maximum vierzig. Eine Suche ist ein Teilstring von bis zu hundert Zeichen über einige Textfelder des Datensatztyps, keine Volltextsuche über die Firma. Ein Datumsbereich nutzt das eigene Datum der Entität: Rechnungsdatum bei Lieferantenrechnungen, Buchungsdatum bei Bankumsätzen, Veranstaltungsdatum im Kalender. Die Reihenfolge ist pro Typ fest — Lieferantenrechnungen nach Fälligkeit, Bankumsätze neueste zuerst —, damit die erste Seite vorhersehbar ist.
Zeilen kommen mit Namen zurück, nicht mit internen Kennungen. Eine Lieferantenrechnung zeigt den Namen des Lieferanten, den Betrag, das bereits Bezahlte und das Offene; eine Lagerbewegung zeigt Produkt und Lager statt zweier IDs. Der Leser löst diese Namen vorab auf, deshalb kann der Assistent von der Rechnung dieses Lieferanten sprechen, ohne ein zweites Mal nachzusehen. Das heißt aber auch: Die Zeile ist eine Zusammenfassung, nicht das ganze Dokument. Positionen, Notizen und Anhänge bleiben, wo sie sind.
Die Grenzen sind dieselben wie die der Person. Der Zugriff wird gegen den Bereich geprüft, zu dem der Datensatz gehört; eine Mitarbeiterin ohne Finanzrechte bekommt keine Finanzzeilen, und das Werkzeug antwortet mit einem Fehler statt mit einer leeren Liste. Nur die Datensätze der eigenen Firma sind einbezogen. Jeder Datensatztyp legt fest, welche Felder die Datenbank verlassen dürfen — Summen, Daten, Namen, Status —, und Geheimnisse wie Bankschlüssel oder Integrationstoken gehören nicht dazu.
Die Frage über fünf Bereiche wird also als Spaziergang beantwortet. Zuerst die Lieferanten, um zu wissen, wer wer ist. Dann ihre Bestellungen, um zu sehen, was bestellt wurde. Dann die Lieferantenrechnungen mit Fälligkeiten und offenen Beträgen. Dann die Bankkonten für die Salden. Dann die Umsätze, um zu sehen, was schon abgegangen ist. Jedes Ergebnis verengt die nächste Frage; der Assistent holt nicht alle fünf auf einmal, und er muss es nicht. Die Antwort setzt sich aus fünf kleinen Lektüren zusammen, von denen ein Mensch jede prüfen könnte.
Was der Leser nicht kann, ist ebenso wichtig. Er kann keine beliebige Kennzahl wie die durchschnittliche Marge pro Monat berechnen, keine Tabelle exportieren und nicht zweihundert Rechnungen von Hand sortieren. Er sieht standardmäßig fünfzehn Zeilen und höchstens vierzig, deshalb braucht eine Frage über einen langen Zeitraum einen Datumsbereich, eine engere Suche oder mehrere Aufrufe. Er meldet die Gesamtzahl — und sagt damit, was nicht gesehen wurde. Ein kleiner Mechanismus für Ehrlichkeit, den eine Tabellenkalkulation selten bietet.
Eine Ausnahme verdient einen eigenen Absatz. Gespräche — WhatsApp, Telegram, der Website-Chat — sind Text von außen. Nachdem der Assistent sie gelesen hat, markiert er den Durchlauf als belastet, und jede Änderung wartet auf eine menschliche Bestätigung, selbst wenn der Automatikmodus an ist. Datensätze sind Daten, keine Anweisungen. Dieselbe Regel gilt für E-Mails und hochgeladene Dokumente, aber bei Gesprächen ist die Versuchung, zu gehorchen, am größten.
Fragen über mehrere Bereiche sind genau die Stelle, an der ein kleines Unternehmen seine Nachmittage verliert: fünf Tabs, zwei Tabellen, eine Person, die weiß, wo alles liegt. Der Assistent ersetzt weder das Urteil dieser Person noch einen Bericht. Er verkürzt den Weg. Eine enge Frage stellen, einen Zeitraum mitgeben, nach der Gesamtzahl fragen — und fünf Bildschirme werden zu einer Antwort mit einer Spur von Lesevorgängen dahinter.