Service & Support steuert den vollständigen Lebenszyklus des Kundenkontakts über jeden Eingangskanal hinweg. Die kanalübergreifende Annahme nimmt Anliegen per E-Mail, Webportal, Chat, Telefon, Self-Service-Formular und maschinell erzeugter Meldung entgegen und legt sie als strukturierte Vorgänge in der passenden Warteschlange ab. Das Vorgangs- und Ticketmanagement führt anschließend jedes Element durch Triage, Kategorisierung, Zuweisung, Bearbeitung und Lösung, wobei der vollständige Schriftwechsel und die internen Arbeitsnotizen am Datensatz gehalten werden.

Auf dem Helpdesk setzen die drei an ITIL ausgerichteten Disziplinen auf. Das Incident-Management stellt den Service rasch wieder her und dokumentiert jeden ergriffenen Schritt. Das Problem-Management untersucht die zugrunde liegende Ursache wiederkehrender oder schwerwiegender Vorfälle und pflegt eine Bibliothek bekannter Fehler und Workarounds. Das Change-Management regelt jede Änderung am Servicebestand über einen Änderungsantrag, eine Risikobewertung und eine formale Freigabe. Service Level Agreements und Eskalation liegen all dem zugrunde: Sie takten jeden Vorgang gegen seine zugesagten Reaktions- und Lösungsziele und eskalieren, bevor eine Verletzung eintritt. Außendienst und Vor-Ort-Einsätze weiten dieselbe Kontrolle auf Arbeiten aus, die vor Ort erfolgen müssen, indem sie Techniker disponieren, das Geleistete erfassen und den Kreis zurück zum auslösenden Vorgang schließen.

Im Zentrum des Moduls steht der Vorgang: ein einzelnes Kundenanliegen mit einem Verantwortlichen, einem Status, einer Priorität, einem Ursprungskanal und einer vollständigen Historie. Jedes andere Konzept im Modul löst entweder einen Vorgang aus, regelt, wie er zu behandeln ist, oder hält fest, was zu seiner Lösung getan wurde. Vorgänge werden in Service-Warteschlangen gruppiert, von denen jede einen Arbeitsstrom für ein bestimmtes Team, eine Produktlinie oder ein Kundensegment darstellt, sodass Routing und Arbeitslast ausdrücklich geregelt sind und nicht dem Zufall überlassen bleiben.

Jeden Vorgang regelt ein Service Level Agreement, die Zusage, die festlegt, wie schnell auf einen Vorgang einer bestimmten Priorität reagiert und wie schnell er gelöst werden muss. Die Vereinbarung ist kein statisches Dokument, sondern eine aktive Uhr: Sie berechnet Ziele gegen Geschäftskalender, pausiert, wenn ein Vorgang auf den Kunden wartet, und treibt die Eskalation an, sobald Fristen näher rücken. Genau das macht eine Zusage messbar statt bloß wünschenswert.

Wo der Helpdesk einzelne Kontakte bearbeitet, bearbeiten die ITIL-Praktiken Muster. Ein Incident ist eine einzelne Serviceunterbrechung. Ein Problem ist die zugrunde liegende Ursache hinter einem oder vielen Incidents, und seine Untersuchung liefert einen bekannten Fehler: eine dokumentierte Störung mit einem erprobten Workaround, den Agenten sofort anwenden, während die dauerhafte Behebung voranschreitet. Ein Change ist eine kontrollierte Änderung am Servicebestand, die ihre eigene Risikobewertung und Freigabekette mitführt, sodass nichts die Umgebung ohne Prüfung verändert. Schließlich steht ein Vor-Ort-Einsatz für Arbeit, die den Schreibtisch verlässt: eine Zuweisung an einen Techniker, geplant, disponiert und gegen den Vorgang berichtet, dem sie dient. Diese Konzepte hängen als natürliche Kette zusammen, von der gestellten Frage über die gelieferte Behebung bis zur verhinderten Wiederholung.

Der alltägliche Workflow ist der Weg des Tickets. Ein Kontakt trifft auf einem beliebigen Kanal ein, wird als Vorgang erfasst und in eine Warteschlange triagiert, mit einer Kategorie und Priorität, die wiederum das maßgebliche Service Agreement auswählen. Ein Agent nimmt den Vorgang vom wissensgestützten Arbeitsplatz auf, bearbeitet ihn mit vorgeschlagenen Artikeln und früheren Lösungen zur Hand, korrespondiert mit dem Kunden und löst ihn oder eskaliert ihn. Kommentare, sowohl kundengerichtet als auch intern, bilden eine vollständige Nachvollziehbarkeit des Austauschs.

Ist eine Unterbrechung erheblich, übernimmt der Incident-Workflow: Der Schweregrad wird gesetzt, Aktualisierungen werden in Abständen veröffentlicht, die der Auswirkung angemessen sind, und die Beteiligten bleiben informiert, bis der Service wiederhergestellt ist. Wiederholung oder erhebliche Auswirkung löst den Problem-Workflow aus, in dem eine Ursachenanalyse einen bekannten Fehler und letztlich einen Änderungsantrag hervorbringt. Dieser Change durchläuft den Change-Workflow: Ein Änderungsantrag wird gestellt, auf Risiko bewertet, geplant und vor der Umsetzung einem Freigabegremium vorgelegt, dann nach Abschluss überprüft. Der Außendienst-Workflow disponiert Vor-Ort-Arbeiten, verfolgt Zuweisung und Anfahrt und erfasst Abschluss, Ersatzteile und Zeit zurück am Vorgang. Jeder Workflow speist den nächsten, sodass eine einzelne gemeldete Störung sauber vom Incident über das Problem bis zum Change fließen kann, ohne das Modul zu verlassen.

Das Modul ist auf die Substanz der ITIL-Servicemanagement-Praktiken hin gebaut, nicht auf ein bloßes Anerkennen ihres Vokabulars. Incident, Problem und Change sind eigenständige Disziplinen mit jeweils eigenen Status, Rollen und Datensätzen, und die Grenzen zwischen ihnen werden durchgesetzt statt verwischt. Der Change trägt ein echtes Kontrollregime: Jeder Änderungsantrag hält eine Einstufung nach Typ und Risiko, einen definierten Umsetzungs- und Rückfallplan sowie eine formale Freigabesequenz, die an die Stelle eines Change Advisory Boards tritt, sodass Notfall-, Standard- und normale Changes jeweils dem Pfad folgen, den ihr Risiko rechtfertigt.

Das Service-Level-Management ist ebenso präzise. Ziele werden gegen definierte Betriebskalender und Prioritätsmatrizen bewertet, sodass ein Vier-Stunden-Ziel vier Geschäftsstunden bedeutet und Pausen, während ein Vorgang auf die Zuarbeit des Kunden wartet, korrekt berücksichtigt. Die Eskalation ist gestuft und zeitbasiert und hebt Verantwortung und Sichtbarkeit an, während eine Frist näher rückt, statt erst nachdem sie verstrichen ist. Jeder Vorgang, jeder Incident, jedes Problem, jeder Change und jeder Vor-Ort-Einsatz trägt eine dauerhafte, menschenlesbare Referenz, und die vollständige Statushistorie wird aufbewahrt, was einen lückenlosen und prüffähigen Nachweis darüber liefert, wer was wann getan hat. Die Wissensdatenbank wird als erstklassige Kontrollfläche behandelt: Bekannte Fehler und Artikel werden im Kontext eingeblendet, sodass ein erprobter Workaround den Agenten genau im Moment des Bedarfs erreicht und die Lösungsqualität nicht vom individuellen Gedächtnis abhängt.

Service & Support ist bewusst keine Insel. Es bezieht den Kunden-, Kontakt- und Anspruchskontext, den es benötigt, aus dem Modul CRM und Vertrieb, sodass jeder Vorgang an einem realen Konto und dessen Geschäftsbeziehung verankert ist. Service Agreements werden gegen die im Contract Management gehaltenen Bedingungen erfüllt, sodass die Reaktion, die ein Kunde erhält, dem Service entspricht, den er gekauft hat. Wird ein Vorgang abrechenbar, sei es für Arbeit außerhalb des Leistungsumfangs, für Ersatzteile oder für einen Vor-Ort-Besuch, fließen die Kosten für Fakturierung und Umsatzrealisierung an die Finanzbuchhaltung, statt von Hand zusammengezählt zu werden.

Vor-Ort-Einsätze stimmen sich mit dem Bestands- und Anlagenmanagement über die verbrauchten Ersatzteile und die gewarteten Geräte ab sowie mit den Personaldaten im Human Resources über die eingesetzten Techniker und die Qualifikationen, die sie besitzen. Changes, die den Servicebestand berühren, werden gegen dieselben Anlagendatensätze abgeglichen, sodass die von einem Change veränderte Konfiguration die Konfiguration ist, die der Rest der Suite sieht. Da jedes Modul eine gemeinsame Identitäts-, Berechtigungs- und Datenbasis teilt, wirken ein Support-Agent, ein Finanzcontroller und ein Servicetechniker alle auf demselben zugrunde liegenden Datensatz, und eine einmal erfasste Lösung ist überall dort sichtbar, wo sie relevant ist.

AI Workers sind erstklassige Nutzer des Moduls, die dieselben Berechtigungen halten und denselben Prüfpfad hinterlassen wie ihre menschlichen Kollegen. Über konversationelle Abfrage fragt ein Manager in einfacher Sprache, welche Agreements heute Nachmittag gefährdet sind oder wie viele Incidents auf ein einziges Problem zurückgehen, und erhält eine Antwort aus Live-Vorgangsdaten statt aus einem veralteten Bericht. Worker führen Aktionen direkt aus: Sie triagieren und leiten einen eingehenden Vorgang, entwerfen eine Kundenantwort aus der Wissensdatenbank, veröffentlichen ein Incident-Update oder disponieren einen Vor-Ort-Einsatz zum nächstgelegenen qualifizierten Techniker.

Sie überwachen fortlaufend auf Anomalien und Ausnahmen. Ein Worker markiert einen Vorgang, der auf eine Serviceverletzung zutreibt, ein Bündel von Incidents, das ein aufkommendes Problem signalisiert, oder einen in ein riskantes Zeitfenster geplanten Change, und meldet ihn, bevor daraus ein Ausfall wird. Bei der Annahme führen Worker die Extraktion von Dokumenten und Daten durch, indem sie eine eingehende E-Mail oder einen angehängten Bericht lesen, um Kategorie, Priorität und betroffenes Asset ohne manuelle Erfassung zu befüllen. Sie bieten Agenten und Change-Managern Entscheidungsunterstützung, indem sie eine Vorgangshistorie zusammenfassen, aus früheren bekannten Fehlern eine wahrscheinliche Ursache vorschlagen oder das Risiko eines vorgeschlagenen Changes gegen frühere Ergebnisse bewerten. Ein Worker kann zudem als Freigabe- oder Prüfknoten in einem Workflow stehen: Er sitzt in einer Change-Advisory-Sequenz, um risikoarme Standard-Changes im Rahmen der Richtlinie zu genehmigen und alles darüber Hinausgehende an einen Menschen zu eskalieren, sodass der Routinedurchsatz schnell bleibt und echte Ermessensentscheidungen weiterhin eine Person erreichen.