Prozess-Buttons: wiederkehrende Abläufe mit einem Klick

Ein Interessent hat angerufen, das Erstgespräch war gut. Jetzt folgt, was immer folgt: das Gespräch als Aktivität festhalten, die Verkaufschance anlegen, den Kampagnenstatus weitersetzen, eine kurze Zusammenfassung mit den nächsten Schritten per E-Mail schicken und sich in einer Woche eine Wiedervorlage setzen. Fünf Handgriffe an fünf Stellen. Am Montag macht das jeder im Team vollständig, am Freitagnachmittag fehlt mal die Wiedervorlage, mal die Mail. Im Support ist es nicht anders: Ein Ticket an die Technik zu übergeben heißt Status ändern, Bearbeiter setzen, Priorität prüfen, einen Kommentar schreiben und den Kunden informieren. In der Buchhaltung heißt eine Rechnung per Post zu versenden, den Brief auszulösen, den Status zu setzen und eine Zahlungserinnerung vorzumerken.

All das ist Automatisierung, die keine KI und keinen externen Workflow braucht. Die Schritte sind bekannt, die Reihenfolge steht fest, nur das Ausführen kostet Zeit und Aufmerksamkeit. Genau dafür hat ameax Prozess-Buttons.

Fünf Bereiche, ein Prinzip

Technisch sind es fünf getrennte Mechanismen — am Kunden, am Ticket, am Beleg, am Objekt und im Matching. Jeder bringt die Aktionen mit, die an seiner Stelle gebraucht werden, und wird dort eigens eingerichtet. Das Prinzip ist überall dasselbe, nur der Vorrat an Aktionen unterscheidet sich. Objekte sind dabei Anlagen oder Geräte beim Kunden; das Matching stellt Quelle und Ziel gegenüber und liefert eine Liste von Treffern.

Der Kunden-Button ist der umfangreichste. Er erscheint nicht nur am Kunden, sondern mit derselben Einrichtung auch an der Verkaufschance, am Beleg, an Formularen, je Zeile in der Wiedervorlagenliste und beim Anlegen einer Aktivität. Im Detail beschreibt ihn die Funktionsseite Geführte Prozesse; hier geht es um den Blick quer durch die Software.

Beispiel „Erstgespräch geführt“: Der Button legt eine Aktivität der Art „Erstgespräch“ an, setzt den Kampagnenstatus auf „Qualifiziert“, legt eine Verkaufschance an, erzeugt aus der Textvorlage „Danke für das Gespräch“ eine E-Mail an den gewählten Ansprechpartner und setzt dem Betreuer eine Wiedervorlage in sieben Tagen. Firmenname, Anrede und Ansprechpartner kommen über Platzhalter in den Text. Braucht der Ablauf eine Angabe, die nicht feststeht, fragt ein kurzes Formular vor der Ausführung danach.

Bereich, Aktionen, Auslöser im Überblick

Die Tabelle hilft bei der Entscheidung, an welcher Stelle ein Ablauf am besten aufgehoben ist. Ein Ablauf, der am Kunden hängt, gehört an den Kunden — auch dann, wenn er einen Beleg erzeugt.

Wann ein Button erscheint und wann er läuft

Der Regelfall ist der Klick. Ein Mitarbeiter sieht am Datensatz die Buttons, die dort gerade passen, und löst den richtigen aus.

Bei Tickets drücken auch Kunden. Im Kundenportal sieht ein Kunde die Buttons, die für seine Portal-Rolle im jeweils aktuellen Status freigegeben sind, etwa „Problem besteht weiterhin“ oder „Kann geschlossen werden“. Das ist der einzige Bereich, in dem das möglich ist.

Welche Buttons überhaupt sichtbar sind, steuern Vorbedingungen. Sie prüfen in dem Moment, in dem jemand den Datensatz öffnet, dessen aktuellen Zustand — und damit auch, was vorher schon getan wurde. Ein Button, der nur erscheint, solange keine Wiedervorlage offen ist, verschwindet, sobald jemand eine gesetzt hat. So steht am Datensatz immer nur der Schritt, der gerade an der Reihe ist.

Geprüft werden je nach Bereich unterschiedliche Angaben. Ein Kunden-Button zeigt sich zum Beispiel nur bei einem bestimmten Status oder Typ, bei gesetzten Kategorien, bei einem bestimmten Betreuer, bei offenen oder fehlenden Wiedervorlagen, bei passenden Kundenfeldern oder nur bei Debitoren. Ein Ticket-Button hängt an den Status, in denen er sichtbar sein soll, ein Beleg-Button an Belegart und Belegstatus. Kunden-Buttons kann man zusätzlich auf Kampagnen, Benutzer und Gruppen beschränken.

Beispiel „An Technik übergeben“: Der Button erscheint nur im Status „In Prüfung“. Er setzt den Status „Technik“, bestimmt den Bearbeiter aus der Technik, erhöht bei Bedarf die Priorität und verlangt einen Pflichtkommentar, in dem der Support festhält, was schon geprüft wurde. Der Kunde bekommt aus einer Textvorlage die Nachricht, dass sein Anliegen an die Fachabteilung gegangen ist.

Beispiel „Rechnung per onlinebrief24 versenden“: Über Belegart und Belegstatus erscheint der Button nur bei Rechnungen, die noch nicht versendet sind. Er übergibt die Rechnung, setzt den Belegstatus weiter und legt der Buchhaltung eine Wiedervorlage zum Zahlungsziel an. Wie Belege weitergeführt werden, zeigt Belege weiterführen.

Ein Button, der nur dort erscheint, wo er passt, kann nicht falsch gedrückt werden. Das ist die wirksamste Qualitätskontrolle, die dieser Mechanismus mitbringt, und bei der Einrichtung kostet sie ein paar Minuten.

Ohne Klick

An einigen fest definierten Stellen läuft ein Prozess-Button von selbst:

• Webformular: Ein ameax-Webformular führt bei der Absendung einen Kunden-Button aus, etwa für Eingangsbestätigung, Aktivität und Wiedervorlage an den Vertrieb. Der Button läuft beim Absenden, nicht erst nach der Bestätigung eines Double-Opt-in.
• Kundenportal: Die Registrierung eines Portal-Kontos sowie Buchung und Stornierung von Terminen und Webinaren führen je einen hinterlegten Kunden-Button im Hintergrund aus.
• E-Mail an die Ticket-Adresse: Entsteht aus einer E-Mail ein Ticket oder kommt eine neue E-Mail zu einem bestehenden, läuft der dafür hinterlegte Ticket-Button — etwa um ein abgeschlossenes Ticket wieder zu öffnen.
• Ticket im Kundenportal: Legt ein Kunde im Portal ein Ticket an, läuft ebenfalls ein hinterlegter Button, der zum Beispiel Bearbeiter und Priorität setzt.
• REST-API: Kunden- und Ticket-Buttons kann ein Workflow über POST /api/v2/customers/{id}/proceedings/{pid}/execute und POST /api/v2/tasks/{id}/proceedings/{pid}/execute von außen auslösen.
• Folgeschritt: Ein Objekt-Button führt einen Kunden-Button aus, ein Kunden-Button einen Folge-Button, und Beleg- und Ticket-Buttons starten einen neu angelegten Vorgang gleich mit dessen Ticket-Button. Diese Verkettung ist linear, eine Verzweigung nach Ergebnis gibt es nicht.

Zwei Einschränkungen

Die Beschränkung auf Kampagne, Benutzer und Gruppe gilt nur beim Klick in der Oberfläche, nicht beim Auslösen über Webformular, Portal oder API. Wer einen Button für die API freigibt, sollte ihn deshalb so bauen, dass er für jeden Kunden sicher ist, den ein Workflow übergibt.

Es gibt keine zeit- oder ereignisgesteuerten Kunden-Buttons. Ein Kunden-Button startet nicht, weil ein Status wechselt oder ein Datum erreicht ist, und ein Ticket-Status löst keinen Kunden-Button aus. Wer „jeden Montag“ oder „sobald X passiert“ braucht, lässt einen Workflow die API abfragen und den Button auslösen — dazu weiter unten mehr.

Protokoll und Auswertung

Jede Ausführung wird mitgeschrieben: welcher Button, wann und durch wen. Das hat zwei Seiten. Im Einzelfall ist nachvollziehbar, warum eine Mail herausgegangen ist oder woher eine Wiedervorlage stammt. In der Summe wird sichtbar, wie das Team tatsächlich arbeitet.

Beispiel „Treffer vorschlagen“ und „Abgelehnt“: Im Matching setzt der eine Button den Ergebnisstatus auf „vorgeschlagen“, schickt der Quelle eine E-Mail aus einer Textvorlage und legt eine Wiedervorlage an, um in drei Tagen nachzuhaken. Der zweite setzt nur den Status und hält die Entscheidung als Aktivität fest. Sein einziger Zweck ist der Eintrag — damit in drei Monaten noch erkennbar ist, dass dieser Treffer geprüft und verworfen wurde.

Für die Kunden-Buttons gibt es in den Hub-Dashboards einen eigenen Baustein: Kennzahlen zu den Ausführungen und eine Matrix aus Benutzern oder Teams und Buttons. Daran sehen Sie, dass ein Team „Erstgespräch geführt“ regelmäßig nutzt und ein anderes kaum. Oder dass ein Button, den Sie für wichtig hielten, praktisch nie gedrückt wird.

Daraus folgt meistens eine Änderung am Ablauf, nicht an den Leuten. Ein Button, der nicht benutzt wird, steht an der falschen Stelle, heißt falsch oder beschreibt einen Weg, den im Alltag niemand geht. Die Einrichtung dauert Minuten, also richtet man ihn um und sieht im nächsten Monat nach, ob er jetzt läuft.

Weil die Buttons Aktivitäten, Wiedervorlagen und Statuswechsel erzeugen, tauchen ihre Ergebnisse außerdem dort auf, wo das Team ohnehin hinsieht: im Verlauf am Kunden, in den offenen Wiedervorlagen, in Kampagnenauswertungen und in den Aktivitäten-Zielen. Bei Tickets hält die Status-Historie jeden Wechsel fest, auch den, den ein Button ausgelöst hat.

Prozess-Buttons als Bausteine für KI und n8n

Prozess-Buttons und KI-Workflows schließen sich nicht aus, sie ergänzen sich. Ein Button kennt nur den Klick und die oben genannten festen Auslöser. Ein Workflow in n8n läuft dagegen zeitgesteuert, bezieht Daten aus anderen Systemen ein und kann ein Sprachmodell entscheiden lassen.

Die sinnvolle Arbeitsteilung: Der Ablauf selbst bleibt als Prozess-Button in ameax gepflegt, der Workflow entscheidet nur, wann und für wen er läuft. Das Sprachmodell wählt aus, es führt nicht aus. Was am Ende am Kunden passiert, steht weiterhin im Button, und dort sieht es auch jeder im Team.

Das hat praktische Folgen. Die Textvorlage für die Nachfass-Mail pflegt das Vertriebsteam in ameax, nicht jemand im Workflow-Editor. Ändert sich die Wiedervorlagenfrist, passen Sie den Button an, und Oberfläche wie Workflow benutzen sofort dieselbe neue Fassung. Und für eine Kette aus Aktivität, Statuswechsel, E-Mail und Wiedervorlage braucht der Workflow einen einzigen API-Aufruf statt vier.

Bei E-Mails ist das mehr als bequem: Die REST-API verschickt selbst keine E-Mails und trägt nicht in einen Automailer ein. Ein Prozess-Button, der beides tut und per API ausgelöst wird, schließt diese Lücke.

POST /api/v2/customers/4711/proceedings/12/execute
Authorization: Bearer <Token des technischen Benutzers>
Content-Type: application/json

{"person_id": 8150}

Die Werte 4711, 12 und 8150 sind Beispiel-IDs, person_id ist der optionale Ansprechpartner. Die Antwort meldet in data.attributes.success und message, ob der Ablauf durchgelaufen ist. Prüfen Sie dieses Feld, denn ameax antwortet auch bei einem Misserfolg mit HTTP 200. Bei Tickets steht das Ergebnis im Feld done.

Drei Grenzen

Drei Punkte sollten Sie vor der Planung kennen.

• Über die API wird keine Vorbedingung geprüft. GET /api/v2/customers/{id}/proceedings listet alle Buttons auf, unabhängig davon, ob sie für diesen Kunden gerade passen. Die fachliche Entscheidung trifft der Workflow.
• Beleg-, Objekt- und Matching-Buttons laufen nur in der Oberfläche. Die API löst sie nicht aus.
• Ein Prozess-Button läuft immer für genau einen Datensatz. Für einen vollständigen Ablauf über viele Kunden ruft der Workflow den Button je Kunde einzeln auf; für dieselbe einzelne Änderung an vielen Kunden gibt es die Sammelbearbeitung.

Typische Kombinationen

• Leadeingang: Ein Sprachmodell liest die Anfrage und bewertet sie, der Workflow legt den Kunden an und löst den Button „Neuer Lead“ aus, der Eingangsbestätigung, Aktivität und Wiedervorlage erledigt.
• Nurturing: Das Modell entscheidet anhand der Historie, welche Strecke passt, und der Workflow löst den Button aus, der in den passenden Automailer einträgt.
• Ticket-Eingang: Das Modell ordnet ein Ticket ein, der Workflow führt den Ticket-Button „An Technik übergeben“ per API aus.
• Pipeline-Pflege: Ein zeitgesteuerter Workflow findet liegengebliebene Verkaufschancen und löst für jede den Button „Angebot nachfassen“ aus.

Wie Sie n8n mit Token und HTTP-Request-Knoten anbinden, beschreibt n8n an ameax anbinden. Die Übersicht aller Szenarien steht unter Automatisierung.

Best Practices

Technisch ist ein Prozess-Button schnell eingerichtet. Ob er im Alltag auch benutzt wird, entscheidet sich woanders: am Namen, an der Anzahl und daran, wie weit ein einzelner Button reicht.

Beispiel „Wartungsprotokoll als PDF an den Kunden“: Der Techniker füllt die Wartungsdaten am Objekt aus und drückt den Button. ameax erzeugt das Protokoll als PDF auf Ihrem Briefpapier und schickt es an den Ansprechpartner, der im Objekt als Verantwortlicher eingetragen ist. Der anschließend ausgeführte Kunden-Button hält die Wartung als Aktivität fest und setzt die Wiedervorlage für den nächsten Termin. Zwei getrennte Mechanismen, für den Techniker ein Handgriff.

• Nach dem Ergebnis benennen, nicht nach der Technik. „Erstgespräch geführt“ oder „An Technik übergeben“ sagt dem Mitarbeiter, wann er drücken soll. „Aktivität + Mail + WV“ sagt ihm nur, was passiert, und führt zu Fehlgriffen. Farben helfen zusätzlich, etwa grün für den nächsten Schritt nach vorn und grau für die Ablage.
• Wenige gute Buttons statt vieler. Acht Buttons an einem Kunden lesen sich wie eine Speisekarte, drei passende werden benutzt. Beginnen Sie mit den zwei oder drei Abläufen, die am häufigsten vorkommen, und ergänzen Sie erst, wenn das Protokoll zeigt, dass sie genutzt werden.
• Textvorlagen mit Platzhaltern pflegen. Anrede, Ansprechpartner, Firmenname und Name des Mitarbeiters kommen aus Platzhaltern, der Rest aus einer gut formulierten Vorlage. So klingt jede Mail persönlich, und eine Änderung am Text wirkt in allen Buttons, die die Vorlage benutzen.
• Zum Einstieg Entwurf statt Direktversand. Lassen Sie neue Buttons E-Mails zunächst als Entwurf anlegen. Das Team sieht, was der Button erzeugt, und korrigiert Vorlage oder Platzhalter, bevor eine Mail ungeprüft beim Kunden landet. Nach einigen Wochen schalten Sie auf Versand um.
• Pflichtkommentare dort, wo Wissen übergeben wird. Bei Ticket-Buttons, die an ein anderes Team übergeben, sorgt ein Pflichtkommentar dafür, dass der Empfänger weiß, was schon geprüft wurde. Beim Schließen eines Tickets ist er meist überflüssig.
• Für die API eigene Buttons anlegen. Die Beschränkung auf Kampagne, Benutzer und Gruppe greift beim API-Aufruf nicht. Ein eigens benannter Button wie „Workflow: Nurturing eintragen“ zeigt im Protokoll, was der Workflow ausgelöst hat, und Sie ändern ihn, ohne die Klick-Variante anzufassen.
• Was ständig gedrückt wird, kann von selbst laufen. Ein Button, den das Team jeden Tag benutzt, ist ein Kandidat für einen der klicklosen Auslöser: das Webformular, das Kundenportal oder einen Workflow.

Weitere eingebaute Abläufe

Neben den Prozess-Buttons und dem Automailer bringt ameax Abläufe mit, die Sie einmal einrichten und die danach regelmäßig oder bei einem bestimmten Ereignis von selbst laufen. Ein Button ist dafür nicht nötig.

Fazit

Prozess-Buttons sind die Automatisierung, die in ameax an jeder Ecke schon da ist: am Kunden und an der Verkaufschance, im Ticket und im Kundenportal, am Beleg, am Objekt und im Matching. Sie machen aus wiederkehrenden Handgriffen einen Klick, der die Benutzer Schritt für Schritt durch die festgelegte Abfolge führt und dabei keinen Schritt auslässt. Jede Ausführung steht danach im Protokoll. An festen Stellen laufen sie auch ohne Klick: beim Webformular, im Kundenportal, bei eingehender E-Mail oder per API.

Was sie nicht tun, ist entscheiden oder warten. Das übernimmt bei Bedarf ein Workflow, der den Button zum richtigen Zeitpunkt auslöst. So bleibt der Ablauf dort gepflegt, wo Ihr Team arbeitet, und die Automatisierung wächst mit, ohne dass eine zweite Wahrheit entsteht.