Quantix & Bot

Von der E-Mail zur Aufgabe: ein kleiner Ablauf mit Rückweg

Für die erste Automatisierung reicht ein enger Eingang und ein überprüfbares Ergebnis. Unser fiktiver Prototyp legt Aufgaben aus ausgewählten E-Mails an, mit Vorschau, Fehlerliste und Abschaltmöglichkeit.

Eine gefaltete E-Mail-Kachel wandert über einen Prüfpunkt in eine Aufgabenkarte. Ein Fehlerabzweig führt zu einer kurzen manuellen Liste.
Eine gefaltete E-Mail-Kachel wandert über einen Prüfpunkt in eine Aufgabenkarte. Ein Fehlerabzweig führt zu einer kurzen manuellen Liste. Illustration / Grafik: Redaktion Quantix & Bot.
In diesem Artikel

In diesem erfundenen Werkstattbeispiel bekommt ein kleines Team wiederkehrende interne Anfragen per E-Mail. Jemand überträgt Betreff und gewünschtes Datum in eine Aufgabenliste. Wir wollen zunächst nur diese Übertragung erleichtern. Der Ablauf beantwortet keine Kundenanfragen und versendet keine Nachrichten.

Lege einen Testeingang mit fiktiven Nachrichten an. Verwende ein eigenes Testkonto und eine leere Aufgabenliste. Keine echte Kundendatei als bequemen Beispieldatensatz importieren. Welche Berechtigungen dafür ausreichen, beschreibt der Beitrag Ein Bot braucht keine Vollmacht für alles.

Den Eingang eng halten

Verarbeite nur Nachrichten, die eine Person ausdrücklich in einen vorgesehenen Testordner verschiebt. Ein Filter allein aufgrund des Wortes „dringend“ wäre schwer überprüfbar und leicht zufällig ausgelöst. Der Prototyp darf auf einen schmalen, bewussten Eingang reagieren.

Speichere für jeden Eingang eine interne Kennung, den Zeitpunkt und den Bearbeitungszustand. Der erste Zustand heißt „eingegangen“. Erst danach wird ein Entwurf für die Aufgabe erstellt. Bei mehrfacher Zustellung muss die Kennung wiedererkannt werden. Unser Beitrag über doppelte Aufträge erläutert die nötigen Grenzen dieser Absicherung.

Für Betreff und ausdrücklich eingetragenes Datum können feste Regeln genügen. Enthält die Nachricht „nächsten Donnerstag“, darf der Testablauf nachfragen oder diesen Fall zur manuellen Prüfung geben. Nicht jede Mehrdeutigkeit braucht ein Sprachmodell. Falls du eines ergänzt, prüfe seinen Vorschlag wie jeden anderen möglicherweise falschen Chatbot-Text.

Fünf Zustände und ein Fehlerabzweig

Jeder Vorgang hat eine eigene Kennung und einen sichtbaren Zustand. Fehlt ein Pflichtfeld oder bleibt der Ausgang unklar, verlässt der Vorgang die Kette und landet in der manuellen Liste. Dort steht er mit Kennung, gescheitertem Schritt und Zeitpunkt.

Nachrichtim OrdnerEingangNachricht liegt im Testor…geprüftPflichtfelder vollständigvorgemerktVorschau wartet auf Freig…angelegtZiel-ID zurückgemeldetüberprüftAbgleich mit der ZiellistemanuelleKlärlisteKennung, Zeitpunkt und Bearbeitungszustand werden bei jedem Schritt gespeichert.
  • bestätigter Abschluss
  • Fehlerabzweig
Zustände als Textalternative
ZustandBedeutungNächster Schritt
EingangNachricht liegt im vorgesehenen Testordner, Kennung vergebenPflichtfelder prüfen
geprüftTitel und Datum liegen im erwarteten Format vorVorschau erzeugen
vorgemerktVorschau wartet auf eine Freigabe durch eine PersonFreigabe oder Ablehnung
angelegtZielsystem hat die Aufgabe bestätigt und eine Ziel-ID geliefertAbgleich mit der Zielliste
überprüftAufgabe ist in der Zielliste tatsächlich vorhandenVorgang abschließen
manuelle KlärlistePflichtfeld fehlt, Datumsformat passt nicht oder Ausgang ist unklarPerson entscheidet

Schematische Darstellung eines fiktiven Werkstattbeispiels

Die Zustandsnamen sind ein Vorschlag der Redaktion. Wie ein konkretes Werkzeug Zustände benennt und speichert, steht in dessen Dokumentation.

Eine Vorschau vor der Zielaktion

Die Vorschau enthält Titel, Datum, Ziel-Liste und Eingangskennung. Eine Person prüft sie und gibt den Entwurf frei. Fehlt ein Pflichtfeld oder passt das Datum nicht zum vereinbarten Format, bleibt der Vorgang in der Prüfliste. Kein stiller Ersatz durch das heutige Datum.

Nach der Freigabe legt der Ablauf die Aufgabe an. Er speichert die zurückgegebene Ziel-ID und kontrolliert, ob der Vorgang abgeschlossen wurde. Der Status „angelegt“ ist etwas anderes als „Entwurf erstellt“. Ein unklarer Timeout führt in den Fehlerpfad, nicht zu blindem Neuversand.

Falls das Team vor der Freigabe eine Rückfrage zu seinen eigenen Regeln hat, kann ein kleiner FAQ-Bot mit Fundstellen helfen. Er darf die fehlende Freigabe nicht stellvertretend erteilen. Nachschlagen und entscheiden bleiben getrennt.

Fehler brauchen einen bekannten Ort

Die Fehlerliste zeigt nur, was zur Klärung nötig ist: Vorgangskennung, gescheiterter Schritt, Zeitpunkt und zuständige Person. Vollständige Mailtexte gehören nicht automatisch in jedes Protokoll. Auch fiktive Daten sollten so verarbeitet werden, dass der spätere reale Einsatz nicht alle Informationen in Logs kopiert.

Lege fest, wie der Ablauf angehalten wird. Neue Eingänge bleiben dann unbearbeitet oder werden klar als wartend markiert. Nach einem Neustart darf nicht der ganze Testordner nochmals ungeprüft abgearbeitet werden. Für die Wahl zwischen Anbieterbetrieb und eigenem Server ist diese Bedienbarkeit ein gutes Kriterium; siehe Wo soll dein Workflow laufen?.

Erst Fehler zählen, dann Zeitersparnis

Teste mindestens diese Fälle: vollständige Nachricht, fehlendes Datum, ungültiges Datum, identischer zweiter Eingang, fehlende Berechtigung am Ziel und unklarer Ausgang nach einer verspäteten Antwort. Das ist ein Testauftrag, keine Behauptung, dass diese Tests bereits ausgeführt wurden.

Miss die Gesamtzeit einschließlich Prüfung und Nacharbeit. Halte die Einzelwerte fest und kennzeichne Fehler getrennt von langsamen, aber richtigen Ergebnissen. Wie ein einzelner schwieriger Vorgang den Mittelwert beeinflusst, erklärt unser Zahlenbeispiel mit dem langen Donnerstag.

Der Prototyp ist brauchbar, wenn eine andere Person sagen kann, was bei einem fehlenden Datum passiert und wo ein unklarer Auftrag landet. Danach darf der Umfang vorsichtig wachsen. Ein automatisch versendeter Antworttext wäre ein neuer Auftrag mit eigenen Tests, kein kleiner Schalter im bisherigen Ablauf.

Quellen und weiterführende Lektüre

Quellen und weiterführende Lektüre

Fiktives Werkstattbeispiel der Redaktion. Keine realen Kundendaten, keine gemessene Ersparnis und kein belegter Produktvergleich. Die konkrete Umsetzung benötigt die offizielle Dokumentation ihrer verwendeten Dienste.

  • Fiktives Werkstattbeispiel der Redaktion. Keine realen Kundendaten, keine gemessene Ersparnis und kein belegter Produktvergleich.

    Prüfprotokoll: docs/research/A04.md, kein öffentlicher Link

  • Die konkrete Umsetzung benötigt die offizielle Dokumentation der jeweils verwendeten Dienste.

    Prüfprotokoll: docs/research/A04.md, kein öffentlicher Link

Schlagwörter

  • Workflow
  • Vorschau
  • Fehlerliste
  • Testeingang
  • Freigabe

Die Grenze zwischen simuliertem Erfolg und belastbarer Ausführung zeigt sich auch hier: Ein Backtest ist noch kein funktionierender Trading-Bot.

Zum Datenschutz

Wir verwenden zum Start keine Analyse- oder Werbedienste. Schriftdateien, Bilder und die Suche kommen von unserem eigenen Webhosting. Details findest du in den Datenschutzinformationen.

Datenschutz ansehenImpressum