Im Vorzimmer stand Outlook auf dem Bildschirm, Wochenansicht, daneben ein Tischkalender mit Bleistifteinträgen. Die Assistentin hat drei Leitungen parallel bedient und alles Übrige im Kopf gehabt. Wenn jemand einen Termin wollte, hat sie nicht in die Wochenansicht geschaut, sondern an die Decke.
Dann kam der Satz: „Das schafft er nicht.“
Der Mittwochvormittag war frei. Er stand leer im Kalender, zwei Stunden, niemand hatte ihn belegt. Trotzdem ging es nicht, denn der Chef sprach am Dienstagabend in Hamburg, der Rückflug ging erst um 8:15 Uhr, und der Kunde, der gerade anrief, saß in München. Nachgeschlagen hat sie das nie. Sie wusste es.
Diese Rechnung im Kopf ist der Teil der Arbeit, den bis heute kaum eine Terminsoftware übernimmt. Tools wie Calendly, SuperSaaS, die Terminfunktion von Google: Sie alle beantworten nur, ob in einem Kalender an dieser Stelle etwas eingetragen ist. Die Assistentin hat eine andere Frage beantwortet. Sie hat gefragt, ob der Mensch einen Termin überhaupt wird halten können, mit Reisezeit und allem Gedönse drumherum.
Ein Buchungssystem für einen einzigen Menschen
Die Aufgabe, die ich mit KI gelöst habe, war zugegebenermaßen etwas eigenwillig zugeschnitten: ein Terminbuchungstool für eine Person. Für einen Menschen mit drei Webauftritten und entsprechend unterschiedlichen Aktionsfeldern, mit Kunden, die er in einem Feld siezt, und Kunden, die er in einem anderen Feld duzt, mit Trainingsterminen der mobilen Hundeschule entweder beim Termin zu Hause und Beratungsgesprächen per Video, mit Zeiten, in denen er dreihundert Kilometer entfernt ist, und mit einem Kalender, in dem all das nebeneinander steht.
Das ist der Grund, warum ich diesen Fall für ein gutes Beispiel halte. Standardsoftware rechnet mit dem Durchschnitt vieler Kunden, denn anders rechnet sie sich nicht. Wer sie einsetzt, passt sich an: Man lässt Anforderungen weg, die das Werkzeug nicht kennt, gewöhnt sich Umwege an und erklärt sie irgendwann für normal. Jeder kennt das aus dem eigenen Arbeitsalltag.
Mit KI-Unterstützung verschiebt sich diese Rechnung. Software, die auf eine einzige Arbeitsweise zugeschnitten ist, war für den Bedarf einer Person früher zu teuer. Heute lohnt sie sich. Und die Anforderungen dürfen dabei so eigen sein, wie sie eben sind: drei Auftritte mit drei Gestaltungen, zwei Anreden, Termine mit und ohne Anfahrt, ein eigener Radius je Marke. Das lässt sich abbilden, statt es auf das zu kürzen, was ein fremdes Formular hergibt.
Was der Besucher am Ende sieht, sind ein paar freie Uhrzeiten. Dahinter liegen sechs Prüfungen. Zwei davon schauen aus dem Kalender heraus.
Sechs Prüfungen, bis ein Termin buchbar ist
Die Reihenfolge ist eine Entscheidung. Sie geht von billig nach teuer: Was das eigene Regelwerk schon ausschließt, muss keine fremde Schnittstelle mehr beantworten. Die beiden Prüfungen, die einen Kartendienst kosten, stehen deshalb am Ende, und sie laufen ausschließlich bei Terminen der Kategorie „vor Ort“. An einem Tag ohne Vor-Ort-Termin kostet dieser Teil des Systems nichts.
Eine Regel gilt dabei ohne Ausnahme: Frei ist eine Zeit nur dann, wenn sie in allen als sperrend markierten Google-Kalendern frei ist. Die Datenbank bildet den Kalender nicht nach. Sie fragt ihn.
Die Fahrzeit liegt zwischen zwei Terminen
Der naheliegende Weg wäre gewesen, an jeden Vor-Ort-Termin einen festen Puffer zu hängen. Neunzig Minuten davor, neunzig danach, fertig. Der Fehler daran sitzt im Ansatz, denn ein fester Puffer kennt immer nur eine Zahl, während die tatsächliche Fahrzeit davon abhängt, ob man am Vortag aus Hamburg anreist, aus dem Nachbarhaus kommt oder morgens zu Hause losfährt.
Die Fahrzeit gehört also dorthin, wo sie entsteht: auf die Strecke zwischen zwei Terminen. Und welche Strecke das ist, steht in den Nachbarterminen. Wir haben deshalb eine Ortskette über den Tag modelliert, und sie hat zwei Regeln.
Erstens: Online-Termine erben ihren Ort. Ein Videogespräch findet dort statt, wo Sie ohnehin schon sind, und weil es Sie nicht bewegt, gibt der letzte Vor-Ort-Termin seinen Standort über das Gespräch hinweg an den nächsten weiter.
Zweitens: Zwischen zwei ortsgebundenen Terminen muss die Fahrzeit in die Zeit passen, die wirklich frei ist. Nicht in den Abstand zwischen ihnen, sondern in das, was davon übrig ist. Ein Videogespräch dazwischen verbraucht diese Zeit, es sei denn, es ist als Termin gekennzeichnet, der auch unterwegs stattfinden kann. Ein Zwanzig-Minuten-Gespräch geht aus dem stehenden Auto. Eine Anamnese beim Hund geht dort nicht.
Der Reiz an diesen zwei Regeln ist, dass die Ausnahmen von selbst herausfallen. Wir mussten weder den Fall „Videocall direkt nach einem Kundentermin“ noch den Fall „zwei Kunden in derselben Straße“ einzeln programmieren. Beide ergeben sich.
Sieben Minuten schlagen wir übrigens auf jede errechnete Fahrzeit auf, in beide Richtungen. Zum Auto laufen, Parkplatz suchen, beim Kunden bis zur Tür. Google rechnet Straße zu Straße. Der Rest ist Erfahrung.
Wie weit ist zu weit?
Vor der Fahrtkette liegt eine gröbere Frage. Ist der Kunde überhaupt in Reichweite? Dafür sind Aufenthaltszeiträume hinterlegt, also wo man in welchen Wochen ist: zwei Wochen bei der Familie, ein Monat im Ferienhaus, vierzehn Tage mit dem Wohnmobil auf einem Campingplatz.
Der Radius kennt drei Ebenen, und die speziellere gewinnt jeweils gegen die allgemeinere. Ganz unten liegt eine Grundeinstellung von derzeit 150 Kilometern, die immer dann zieht, wenn nichts anderes hinterlegt ist. Darüber steht die Regel des jeweiligen Auftritts, denn für Hundetraining vor Ort fahren wir 100 Kilometer und für ein Beratungsgespräch 150. Und ganz oben steht der einzelne Aufenthalt, an dem sich Ausnahmen eintragen lassen: Vom Ferienhaus aus sind es null Kilometer, dort gibt es überhaupt keine Vor-Ort-Termine.
Wenn ein Termin an der Entfernung scheitert, verschwindet er nicht wortlos aus der Liste. Der Besucher liest, warum, und er liest im selben Satz, dass derselbe Termin online möglich ist. Eine Absage ohne Ausweg ist eine verlorene Anfrage.
Ein abgelehnter Termin steht weiter im Kalender
Beim Testen ist uns etwas aufgefallen, das für jeden gilt, der Google Kalender beruflich benutzt, ganz ohne eigene Software. Ablehnen ist etwas anderes als absagen.
Der Eintrag steht nach dem Ablehnen weiter in Ihrem Kalender, durchgestrichen. Die anderen Teilnehmer erfahren nichts, ihre Kopie zeigt den Termin unverändert als bestätigt. Und die Zeit gibt Google für andere wieder frei, denn ein abgelehnter Termin zählt in der Verfügbarkeitsabfrage als unbelegt. Wir haben das nachgemessen, indem wir denselben Kalendereintrag einmal auf abgelehnt und einmal auf zugesagt gestellt haben. Im ersten Fall bot das System die Zeit wieder an, im zweiten nicht.
Für unsere eigenen Buchungen fängt die Datenbank das ab, weil sie den Termin unabhängig von Google kennt und die Zeit auch dann sperrt, wenn Google sie längst wieder anbietet. Für fremde Einladungen in Ihrem Kalender greift dieser Schutz nicht, und deshalb läuft seither ein stündlicher Wächter mit, der eine Meldung aufs Telefon schickt, sobald ein Termin auf abgelehnt steht und trotzdem weiter gilt.
Sechs Folgen einer bestätigten Buchung
Die Buchung selbst ist eine einzige, unteilbare Zeile in der Datenbank. Wenn zwei Menschen im selben Augenblick dieselbe Uhrzeit anklicken, wird die zweite Buchung von der Datenbank selbst abgewiesen, bevor irgendein Programmteil die Gelegenheit bekommt, sich zu irren. Das ist eine Eigenschaft der Datenbank und keine Frage der Reihenfolge, in der die Klicks eintreffen.
Die Fahrten sind eigene Termine im Kalender, keine unsichtbaren Puffer. Sie sperren die Zeit für weitere Buchungen, weil das System den Kalender ja ohnehin fragt. Und sie lassen sich von Hand verschieben, ohne dass etwas dagegenhält. Wer sich sein eigenes System baut, sollte es sich nicht in den Weg stellen.
Vier Webseiten, eine gemeinsame Grundlage
Alle vier Webseiten laufen durch dieselbe Datenbank und dieselbe Schnittstelle. Was sich unterscheidet, ist Konfiguration, nie kopierter Programmcode. Das Buchungsfenster liest das Design der Seite zur Laufzeit aus, also Farben, Schriften und Rundungen, statt sie einmal abzuschreiben und danach zu verwalten. Ändern wir das Theme einer Seite, ändert sich das Buchungsfenster mit.
Der Unterschied zu einem Mietwerkzeug
| Mietwerkzeug | Eigenbau | |
|---|---|---|
| Aussehen | ein Fenster, das nach dem Anbieter aussieht | liest das Design der Seite zur Laufzeit aus |
| Regeln | was der Anbieter vorgesehen hat | was der Fall verlangt, etwa die Fahrtkette |
| Mehrere Marken | je Marke ein Konto, je Konto eine Rechnung | eine gemeinsame Grundlage, vier Konfigurationen |
| Kundendaten | auf den Servern des Anbieters | auf dem eigenen Server in Deutschland |
| Laufende Kosten | je Nutzer und Monat, dauerhaft | Server und Kartenabfragen |
| Änderungswunsch | ein Wunsch in der Ideenliste des Anbieters | ein Eintrag auf der eigenen Aufgabenliste |
Der Unterschied liegt beim Preis am wenigsten. Ein Mietwerkzeug kostet zwölf bis zwanzig Euro im Monat, und daran geht niemand zugrunde. Er liegt darin, dass die Regeln dem Geschäft folgen und nicht umgekehrt.
Drei Stellen, an denen es länger dauerte
Dazu gehört Ehrlichkeit, denn das hier ist kein Wochenendprojekt. Der Bau hat mehrere Tage konzentrierter Arbeit gebraucht. Fertig ist er nicht. Und drei Stellen haben deutlich mehr Zeit gekostet als eingeplant.
Die Anmeldung bei Google war die erste. Ein Zugang im Testmodus verliert seine Berechtigung nach sieben Tagen, was in keiner der Fehlermeldungen steht, die man dabei zu sehen bekommt. Die zweite war ein Zeichenproblem: Der von uns eingesetzte Automatisierungsdienst deutet Dollarzeichen in Datenbankabfragen als Platzhalter und zerlegt damit still funktionierenden Programmcode. Die dritte war ein Anzeigefehler, den wir erst im Browser gesehen haben, nachdem die Schnittstelle längst fehlerfrei antwortete. Umbrüche folgten der Fensterbreite statt der Breite des Buchungsfensters, und in einer schmalen Spalte sah das kaputt aus.
Was man dafür können muss, lässt sich in drei Punkten sagen. Datenbanken so weit, dass ein Datenmodell entsteht, das die nächsten Erweiterungswünsche aushält, ohne dass man es nach vier Wochen umwirft. Ein Gefühl dafür, wie sich Schnittstellen verhalten, wenn sie schweigen oder Unsinn antworten, denn beides kommt häufiger vor als der Fehlerfall, den die Dokumentation beschreibt. Und die Geduld, jede Änderung im echten Browser auf der echten Seite nachzusehen, statt sich auf eine fehlerfreie Antwort der Schnittstelle zu verlassen. Der Programmcode selbst ist mit KI-Unterstützung entstanden und war der leichteste Teil der Arbeit.
Zurück ins Vorzimmer
Outlook steht in diesem Vorzimmer bis heute, die Assistentin von damals arbeitet in einer anderen Branche. Ihre Rechnung fehlt seitdem. Jedes Terminwerkzeug, das ich seither benutzt habe, hätte den Mittwochvormittag angeboten, weil die Wochenansicht dort leer aussah.
Unseres bietet ihn erst gar nicht an. Es rechnet, wie lange man von Hamburg nach München braucht, vergleicht das mit der Zeit, die dazwischen wirklich frei ist, und nimmt die Uhrzeit aus der Liste. Der Kunde sieht sie nie. Er sieht die nächste, die geht.
Das schafft er nicht: Diesen Satz sagt jetzt die Software.
Schreibe einen Kommentar