Konfigurierbare Process-Engine für die Onboarding-Prozesse eines Bildungsträgers
Ein Bildungsträger berät Kunden durch mehrstufige Förderprogramme, vom Vertragsschluss bis zur ersten Schulung. Jedes Programm hat seine eigene Abfolge an Status, Terminen und Dokumenten.
Dafür haben wir eine Workflow-Engine entwickelt. Sie bildet die Prozesse als Konfiguration ab: Status pro Produkt, Aktionen pro Schritt. Berater und Vertrieb arbeiten in einem Cockpit, das CRM, Vertrags-Tool und WhatsApp-Service zusammenführt.
TODO: optional gegen echten Cockpit-Screenshot mit Deal-Tabelle ersetzen.
Vor dem Tool gab es kein gemeinsames System für das Onboarding. Welcher Kunde an welchem Punkt im Prozess stand, wusste niemand verlässlich. Es gab Excel-Listen, die wurden aber nicht gepflegt: die Daten lagen verteilt in CRM, Vertrags-Tool und Posteingang, und die Listen stimmten teilweise nicht.
Manchmal meldete sich monatelang niemand bei einem Kunden, weil die Übersicht fehlte. Updates blieben aus. Viele Kunden waren unzufrieden. Das ließ sich mit steigender Kundenzahl nicht skalieren.
Im Zentrum steht eine Process-Engine. Pro Förderprodukt wird ein Status-Modell hinterlegt: welche Status es gibt, in welcher Reihenfolge, welche Pflichtfelder beim Übergang ausgefüllt sein müssen, welche Vorbedingungen gelten. Beispiel: Der zweite BAFA-Termin muss gebucht sein, bevor der Onboarding-Termin als abgeschlossen zählt. Aktuell laufen zwei Prozesse: BAFA mit elf Status vom Vertragsschluss bis zum letzten Kundentermin, und KOMPASS mit acht Status.
Pro Status lassen sich Aktionen anstoßen: Onboarding-Mails, WhatsApp-Templates, Calendly-Booking-Links. Manche Aktionen löst der Berater per Klick aus, andere laufen automatisch beim Status-Wechsel. Die Inhalte der Mails und Templates liegen versioniert im Code, statt in privaten Mail-Entwürfen verteilt zu sein.
Berater und Vertrieb sehen ihre Deals in einer Tabelle mit Filter, Sortierung und Volltextsuche über die CRM-Lead-Namen. In der Detail-Ansicht zeigt ein Stepper den aktuellen Stand und die nächsten Pflicht-Schritte. Drei Rollen sind eingebaut: Admin, Vertrieb, Berater. Berater sehen nur ihre eigenen Produkte und nicht die frühen Vertriebs-Status.
Mit der Engine sind heute zehn- bis hundertmal so viele Kunden im Onboarding wie vorher. Das Berater-Team ist dabei nicht entsprechend gewachsen.
Berater wissen jederzeit, welcher Kunde welchen Status hat und welcher Schritt als Nächstes fällig ist. Folge-Mails und WhatsApp-Templates verschicken sich beim Status-Wechsel selbst, statt von Hand kopiert zu werden. Vorbedingungen werden geprüft, bevor ein Status weitergesetzt wird. Kein Übergang ohne die nötigen Informationen.
Kunden bekommen Updates, wenn welche fällig sind. Niemand bleibt mehr monatelang ohne Rückmeldung liegen, weil die Übersicht fehlt.
Die Engine besteht aus zwei Teilen. Die Process-Definition ist typisierte TypeScript-Konfiguration: Status, Transitions, Pflichtfelder, Vorbedingungen, Aktions-Buttons pro Schritt. Die Laufzeit liegt im Next-Server, validiert Übergänge, ruft Action-Handler auf, schreibt in Supabase und stößt externe APIs an.
Cockpit-UI für Berater und Vertrieb. Tabelle, Stepper, Detail-Ansicht.
Status, Transitions und Aktionen leben als typisierte Konfiguration. Neue Prozesse sind ein neuer Eintrag, kein neuer Code-Pfad.
Supabase für Datenbank und Login. Eine deals-Tabelle mit Status und JSONB-Metadaten pro Schritt.
Lead- und Kontaktdaten aus dem CRM, Vertrags-IDs aus dem Vertrags-Tool, Mails und WhatsApp-Templates über interne Services.
Vercel-Deployment. Auth als Middleware vor allen Dashboard-Routen.
Ob App, Plattform oder einzelner Workflow — wir bauen die Software-Ebene, die Ihr Unternehmen braucht, um ohne mehr Personal zu wachsen.