Aus dem Ticket wird der Auftrag, sobald das Ticket entsteht – mit dem richtigen Debitor, dem richtigen Vertrag und ohne dass ihn jemand ein zweites Mal tippt.
Das Ticket steht da, mit Beschreibung, Priorität und Kundennummer. Bis daraus ein Serviceauftrag in Business Central wird, muss es jemand abtippen – und bis das passiert, existiert der Vorgang für die Disposition, die Abrechnung und jede Auswertung schlicht nicht.
Fragt der Kunde nach dem Stand, lautet die Antwort, dass man nachsehen müsse. Und nachsehen heißt: in einem anderen System als dem, in dem eigentlich der Auftrag stehen sollte.
Reaktionszeiten stehen im Vertrag, aber die Uhr läuft ab der Meldung – nicht ab dem Moment, in dem jemand sie überträgt. Jede Stunde, die ein Ticket unübertragen liegt, geht von der Zeit ab, die Euch für die eigentliche Arbeit bleibt. Bei knappen Zusagen entscheidet genau diese Stunde.
Wird der Auftrag ohne Bezug zum Wartungsvertrag angelegt, wird falsch abgerechnet – mal zu Lasten des Kunden, mal zu Euren. Und was gar nicht erst als Auftrag entsteht, weil das Ticket im Alltag untergegangen ist, taucht in keiner Rechnung auf. Das sind keine großen Beträge pro Fall; es sind viele Fälle.
Weil unklar ist, ob schon jemand übertragen hat, überträgt sicherheitshalber ein Zweiter. Dann fahren zwei Termine zum selben Problem, oder der Kunde bekommt zwei Rückmeldungen zu einem Vorfall. Das kostet nicht nur Zeit, es kostet Vertrauen – und Vertrauen ist im Service das Produkt.
Die Übertragung skaliert linear mit dem Ticketaufkommen und hängt an wenigen Personen. Wächst der Servicebereich, wächst zuerst der Innendienst – und zwar bevor der zusätzliche Umsatz da ist. Genau das ist die Stelle, an der Betriebe aufhören, Serviceverträge aktiv zu verkaufen.
Sobald ein Ticket entsteht, meldet das Ticketsystem es an AutoFlow. Der Ablauf sucht den passenden Debitor, sieht nach, ob ein aktiver Servicevertrag besteht, und legt den Auftrag mit der Beschreibung aus dem Ticket an – mit der Ticketnummer als Referenz, damit später klar ist, was zu was gehört.
Das Wichtigste ist dabei, was der Ablauf nicht tut: Findet er den Debitor nicht, rät er nicht. Er meldet den Fall an den Innendienst, mit dem vollständigen Ticketinhalt, damit jemand ihn zuordnen kann.
Das Ticketsystem gibt Bescheid, sobald ein Fall entsteht. Niemand muss ein Postfach im Auge behalten.
Passt die Kundennummer auf keinen Debitor, wird nicht geraten – der Fall geht mit vollem Inhalt an den Innendienst.
Ein aktiver Servicevertrag bestimmt, wie der Auftrag entsteht und wie er später abgerechnet wird.
Mit der Beschreibung aus dem Ticket und dessen Nummer als Referenz – disponierbar und abrechenbar.
Der Auftrag entsteht in dem Moment, in dem das Ticket entsteht – nachts, am Wochenende, während der Teamrunde. Die Zeit, die bisher zwischen Meldung und Erfassung verschwand, steht wieder für die eigentliche Bearbeitung zur Verfügung.
Die Ticketnummer am Auftrag beantwortet die Frage, ob es den Fall schon gibt. Ein zweiter Aufruf ändert nichts.
Der Vertragsbezug wird beim Anlegen geprüft, nicht bei der Abrechnung nachgetragen.
Alles, was einen Webhook schicken kann, funktioniert – und das kann praktisch jedes Ticketsystem.
Unbekannter Kunde oder unerwartete Felder: Der Fall geht an einen Menschen statt in einen halben Auftrag.
Am Monatsabschluss. Wenn die Nacharbeit ausbleibt – kein Suchen nach Einsätzen ohne Auftrag, keine Korrektur falsch zugeordneter Verträge, keine Diskussion über doppelte Termine –, dann hat der Ablauf mehr eingebracht als die zwei Tage, die er gekostet hat.
Das Ticket kommt per Webhook, der Debitor wird gesucht, der Servicevertrag geprüft, der Serviceauftrag angelegt. Jeder Fall, der nicht durchgeht, landet als Mail beim Kundenservice statt im Nichts.
Der Ablauf ist in ein bis zwei Tagen gebaut. Die ehrliche Einschränkung: Er steht und fällt mit der Zuordnung zwischen Kunde im Ticketsystem und Debitor in BC. Wenn es die sauber gibt, ist es schnell. Wenn nicht, ist genau das die eigentliche Aufgabe – und sie wäre auch ohne AutoFlow zu erledigen.
Für den Ablauf nicht. Was Du brauchst, ist jemand, der im Ticketsystem einen Webhook einrichten darf – meist ein Häkchen und eine URL. Die Auswertung der Meldung und das Anlegen des Auftrags klickst Du grafisch zusammen, ohne Code.
Nichts. Es liegt keine Erweiterung im BC-Kern, die neu kompiliert werden müsste. Ändert sich etwas, dann eher am Ticketsystem – und wenn das andere Felder schickt als erwartet, läuft der Ablauf in den Fehlerzweig, statt einen halb gefüllten Auftrag anzulegen.
Der Ablauf legt nichts an. Er schickt den vollständigen Ticketinhalt an eine hinterlegte Adresse, damit jemand den Fall zuordnet. Das klingt nach einer Lücke, ist aber Absicht: Ein automatisch angelegter Auftrag beim falschen Debitor kostet mehr Zeit, als er spart – und fällt oft erst bei der Abrechnung auf.
Der Aufruf muss authentifiziert sein; ohne gültige Anmeldeinformationen passiert nichts. Zusätzlich prüft der Ablauf, ob die Meldung plausibel ist, statt jedem zu vertrauen, der die URL kennt. Was ankommt, steht mit im Protokoll – auch das, was abgewiesen wurde.
Ja, das ist die Gegenrichtung und ein eigener Ablauf. Sinnvollerweise baust Du erst die eine Richtung und lässt sie ein paar Wochen laufen – die Rückmeldung ist deutlich weniger wert, wenn die Hinrichtung noch nicht verlässlich läuft.
In der Sandbox kannst Du unbegrenzt bauen und testen, so lange Du willst. Und im Produktivmandanten bleiben zwei aktive Flows dauerhaft kostenlos – kein Testzeitraum, der abläuft.
Beim Buchen einer Verkaufsrechnung erzeugt AutoFlow das PDF, legt es im richtigen SharePoint-Ordner ab und schreibt den Link zurück an den Beleg.
Anwendungsfall lesen
Fällt der Lagerbestand unter den Meldebestand, prüft AutoFlow offene Bestellungen und erstellt automatisch die passende Einkaufsbestellung.
Anwendungsfall lesen