Vom Formular zur Berechnung, zum PDF und zur E-Mail: ein vollständiger digitaler Service.

Viele sogenannte digitale Prozesse enden nach dem Absenden eines Webformulars. Der Inhalt wird per E-Mail an einen Mitarbeiter gesendet, der die Daten erneut überträgt, Berechnungen in einer Tabelle durchführt, ein Dokument erstellt und die Antwort manuell versendet.

Die sichtbare Eingabe ist digital. Der eigentliche Geschäftsprozess bleibt manuell.

Ein vollständiger digitaler Service verbindet dagegen:

Eingabe → Validierung → Fachlogik → Berechnung
→ Dokument → Versand → Speicherung
→ Übergabe an CRM oder Fachsystem
→ Status und Monitoring

Der Unterschied liegt nicht in einem schöneren Formular, sondern in der durchgängigen Verarbeitung.

Der Prozess beginnt vor dem Formular

Bevor Felder gestaltet werden, muss der fachliche Ablauf verstanden werden:

• Wer nutzt den Service?
• Welche Entscheidung oder welches Ergebnis wird benötigt?
• Welche Daten kennt der Nutzer?
• Welche Daten liegen bereits im Unternehmen vor?
• Welche Regeln bestimmen das Ergebnis?
• Welche Sonderfälle benötigen menschliche Prüfung?
• Welche Dokumente oder Nachweise entstehen?
• Welche Systeme müssen informiert werden?

Ein Formular sollte nur Daten abfragen, die tatsächlich benötigt werden und nicht zuverlässig aus vorhandenen Quellen geladen werden können.

Strukturierte Eingaben statt Freitext-E-Mail

Je strukturierter die Eingabe, desto mehr lässt sich automatisiert prüfen und verarbeiten.

Geeignete Feldtypen:

• kontrollierte Auswahlwerte,
• Datum und Zeitraum,
• numerische Werte mit Einheit,
• Adress- oder Objektauswahl,
• Datei mit klarer Kategorie,
• dynamische Folgefragen,
• bestätigte Einwilligungen,
• Freitext nur für tatsächlich offene Informationen.

Dynamische Formulare können irrelevante Fragen ausblenden und abhängig von vorherigen Antworten weitere Informationen anfordern.

Validierung auf mehreren Ebenen

Syntaktisch

• Pflichtfeld vorhanden,
• Zahl oder Datum formal gültig,
• Datei im erlaubten Format,
• E-Mail-Adresse plausibel.

Fachlich

• Wert innerhalb zulässiger Grenzen,
• Kombinationen erlaubt,
• Termin verfügbar,
• Objekt für den Prozess freigegeben,
• Voraussetzung erfüllt.

Systemübergreifend

• Kundennummer existiert,
• Produktstatus aktuell,
• Vertrag aktiv,
• Datenquelle erreichbar,
• Preis- oder Konfigurationsregel anwendbar.

Fehler sollten möglichst früh und verständlich angezeigt werden. Nicht jeder Systemfehler darf jedoch dem Nutzer rohe technische Details offenlegen.

Fachlogik als eigener Service

Komplexe Berechnungen oder Konfigurationen gehören nicht in verstreute Frontend-Bedingungen.

Ein Fachservice kann:

• Eingaben entgegennehmen,
• Regeln anwenden,
• Berechnungen durchführen,
• zulässige Optionen bestimmen,
• Ergebnis und Begründung strukturiert zurückgeben,
• verwendete Regelversion dokumentieren.

Beispiel:

Input:
- Objekt
- Eigenkapital
- Finanzierungsdauer
- angenommener Zinssatz

Output:
- mögliche Konfigurationen
- berechnete Kennzahlen
- Warnungen
- benötigte nächste Schritte
- Dokumentdaten

Frontend, Partnerwebsite und interne Anwendung können denselben Service verwenden.

Berechnungsergebnis versionieren

Wenn Regeln, Zinssätze, Preise oder Annahmen veränderlich sind, muss gespeichert werden, welche Version verwendet wurde.

Ein Snapshot kann enthalten:

• Eingabedaten,
• ergänzte Systemdaten,
• Regelversion,
• Berechnungszeitpunkt,
• Zwischenergebnisse,
• Endergebnis,
• Warnungen,
• Nutzer und Kanal.

So lässt sich später nachvollziehen, warum ein bestimmtes PDF oder Angebot entstanden ist.

PDF-Erzeugung als strukturierte Ausgabe

Ein PDF sollte nicht aus einem Screenshot der Website entstehen. Besser ist ein dokumentenspezifisches Template, das strukturierte Ergebnisdaten erhält.

Der Prozess:

1. 1Berechnung liefert ein definiertes Dokumentmodell.
2. 2Template wählt Layout, Sprache und Dokumenttyp.
3. 3Inhalte werden formatiert.
4. 4Pflichtangaben und Seitenumbrüche werden geprüft.
5. 5PDF erhält eindeutige ID und Version.
6. 6Datei wird gespeichert oder zeitlich begrenzt bereitgestellt.

Mögliche Dokumente:

• Berechnung,
• Konfiguration,
• Angebot,
• Zusammenfassung,
• Bestätigung,
• Informationspaket.

Das System kann mehrere PDFs für unterschiedliche Empfänger erzeugen, ohne dieselbe Berechnung erneut durchzuführen.

E-Mail ist ein Ausgabekanal, nicht der Prozess

Nach Erstellung eines Dokuments kann eine E-Mail versendet werden. Sie sollte jedoch nicht der einzige Ort sein, an dem das Ergebnis existiert.

Zu speichern sind:

• Empfänger,
• verwendetes Template,
• Sprache,
• Dokumentversion,
• Versandzeitpunkt,
• Zustellstatus soweit verfügbar,
• Zusammenhang mit Vorgang und Nutzer.

Optional erhält der Nutzer zusätzlich einen geschützten Link im Portal. Dadurch bleibt das Ergebnis zugänglich, auch wenn die E-Mail verloren geht.

Übergabe an CRM oder Fachsystem

Ein vollständiger Service erzeugt einen strukturierten Vorgang.

Mögliche Übergabedaten:

• Kontakt und Organisation,
• Quelle und Kampagne,
• Eingaben,
• Berechnungsergebnis,
• Dokumentlinks,
• Einwilligungen,
• Priorität oder Qualifikation,
• gewünschter nächster Schritt,
• Status.

Die Übergabe erfolgt über API oder Ereignis, nicht als unstrukturierte E-Mail, die ein Mitarbeiter erneut erfassen muss.

Idempotenz gegen doppelte Vorgänge

Nutzer klicken mehrfach, Browser wiederholen Requests oder ein Integrationsjob wird erneut ausgeführt. Ohne Schutz können doppelte PDFs, E-Mails und CRM-Leads entstehen.

Jeder Vorgang erhält eine Idempotency ID. Wiederholte identische Anfragen liefern denselben bestehenden Vorgang oder setzen die Verarbeitung kontrolliert fort.

Besonders wichtig bei:

• kostenpflichtigen Aktionen,
• Dokumenterzeugung,
• CRM-Anlage,
• E-Mail-Versand,
• externen APIs.

Asynchrone Verarbeitung und Status

Aufwendige Berechnungen, Dateiprüfungen oder PDF-Erzeugung müssen nicht innerhalb eines einzigen Browserrequests abgeschlossen werden.

Ein asynchroner Prozess kann Zustände besitzen:

received → validating → calculating
→ generating_documents → sending → completed

Fehlerzustände:

needs_user_input
manual_review
retrying
failed

Der Nutzer erhält einen verständlichen Status und kann bei Bedarf später auf das Ergebnis zugreifen.

Human-in-the-Loop für Sonderfälle

Nicht jeder Vorgang lässt sich vollständig automatisieren.

Beispiele:

• widersprüchliche Dokumente,
• Werte außerhalb normaler Grenzen,
• individuelle Vertragsausnahme,
• unklare Konfiguration,
• hohe finanzielle Tragweite.

Das System bereitet den Fall vor:

• relevante Daten zusammenstellen,
• Unklarheit markieren,
• Berechnungsvorschlag liefern,
• zuständigen Mitarbeiter zuweisen,
• Entscheidung protokollieren,
• Prozess anschließend automatisch fortsetzen.

Der Mensch wird gezielt an der notwendigen Stelle eingebunden, nicht als Ersatz für die gesamte Verarbeitung.

Security und Datenschutz

Ein digitaler Service verarbeitet möglicherweise sensible Angaben und Dokumente.

Zu berücksichtigen:

• Datenminimierung,
• verschlüsselte Übertragung und Speicherung,
• Rollen und Zugriffe,
• zeitlich begrenzte Downloadlinks,
• Viren- und Dateiprüfung,
• Aufbewahrungs- und Löschregeln,
• Protokollierung kritischer Aktionen,
• Schutz vor automatisiertem Missbrauch,
• sichere Template- und PDF-Erzeugung.

Fachliches Monitoring

Mögliche Kennzahlen:

• gestartete und abgeschlossene Vorgänge,
• Abbruch je Schritt,
• Validierungsfehler,
• Fälle in manueller Prüfung,
• Berechnungs- und PDF-Laufzeit,
• fehlgeschlagene E-Mails,
• nicht übertragene CRM-Vorgänge,
• doppelte oder wiederholte Anfragen,
• Ergebnisverteilung und ungewöhnliche Ausreißer.

So wird sichtbar, ob der Service operativ funktioniert.