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.

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.
- bestätigter Abschluss
- Fehlerabzweig
| Zustand | Bedeutung | Nächster Schritt |
|---|---|---|
| Eingang | Nachricht liegt im vorgesehenen Testordner, Kennung vergeben | Pflichtfelder prüfen |
| geprüft | Titel und Datum liegen im erwarteten Format vor | Vorschau erzeugen |
| vorgemerkt | Vorschau wartet auf eine Freigabe durch eine Person | Freigabe oder Ablehnung |
| angelegt | Zielsystem hat die Aufgabe bestätigt und eine Ziel-ID geliefert | Abgleich mit der Zielliste |
| überprüft | Aufgabe ist in der Zielliste tatsächlich vorhanden | Vorgang abschließen |
| manuelle Klärliste | Pflichtfeld fehlt, Datumsformat passt nicht oder Ausgang ist unklar | Person 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
Weiterlesen
Die Grenze zwischen simuliertem Erfolg und belastbarer Ausführung zeigt sich auch hier: Ein Backtest ist noch kein funktionierender Trading-Bot.