Um das ultimative Ziel eines funktionierenden Ökosystems für die Servicebereitstellung (eines, das frei von manueller und redundanter Arbeit ist) zu erreichen, sind erfolgreich integrierte Ticketing-Tools und -Prozesse unerlässlich.

Darüber hinaus sollten Unternehmen die Freiheit haben, die Tools zu verwenden, an die sie gewöhnt sind, und mit den Prozessen zu arbeiten, die sie bereits eingeführt haben — anstatt ihre Arbeitsweise an die Integrationsmethoden anzupassen. Wenn dies erreicht ist, können Unternehmen schnell mit der Zusammenarbeit beginnen, anstatt Zeit mit der Entwicklung neuer Prozesse, der Implementierung neuer Tools oder der Wartung technischer Lösungen zu verschwenden.

Die Erstellung von Integrationen dauert in der Regel etwa 3 bis 9 Monate, was dazu führt, dass Dienstanbieter und ihre Kunden weiterhin Drehstuhl oder Doppeltaste — anstatt sich für vollwertige Integrationen auf Unternehmensebene zu entscheiden. Einige Prozesse waren entweder zu umständlich, zeitaufwändig oder zu teuer, als dass Dienstanbieter einen neuen Kunden gewinnen konnten. Die Automatisierung der wichtigsten Serviceprozesse sollte kein Projekt sein, das viele Monate in Anspruch nimmt (und beide Parteien in den Wahnsinn treibt!).

In diesem Leitfaden werden wir skizzieren, warum Kommunikationsdienstleister und ihre Kunden von der Schaffung einer vernetzten Dienstarchitektur profitieren — und am Ende erklären wir, wie sie diese mit ONEiO erstellen können. (Sie können diesen Artikel auch als PDF herunterladen hier)

Wer wird sich integrieren und wer wird sich anpassen?

Für Telekommunikationsdienstleister wird es immer schwieriger, ihre Dienste so weit zu differenzieren, dass sie sich von der Konkurrenz abheben — schnelle Konnektivität und gute Betriebszeiten reichen nicht mehr aus.

Dienstleister müssen effizienter denn je arbeiten, um mit den steigenden Kundenanforderungen Schritt zu halten und sicherzustellen, dass sie ihren Kunden die Tools bieten, die eine reibungslose Zusammenarbeit ermöglichen. Während Serviceanbieter mit einem beispiellosen und unvermeidlichen Fachkräftemangel konfrontiert sind, besteht der Nebeneffekt darin, dass die Anbieter gezielter an der Automatisierung arbeiten.

Aber es gibt einen Haken: Derselbe Fachkräftemangel, der die Automatisierung vorantreibt, hindern Unternehmen daran, neue Technologien einzuführen. In der Tat ein Gartner-Umfrage 2021 fand heraus, dass Führungskräfte „die Verfügbarkeit von Talenten als Hauptrisikofaktor für die Einführung der meisten IT-Automatisierungstechnologien (75%) und fast die Hälfte der digitalen Arbeitsplatztechnologien (41%) nannten“

Lassen Sie uns etwas tiefer in die traditionelle Arbeitsweise, die Problembereiche und die Art und Weise eintauchen, wie die Telekommunikationsbranche auf die neue Art der Handhabung umsteigen kann Serviceintegration.

Traditioneller Weg:
Traditionell ist die Lieferkette zwischen dem Endkunden, der IT-Abteilung des Unternehmens, dem Dienstanbieter und den Kommunikationsdienstleistern innerhalb der Unternehmensgrenzen isoliert. Jede Partei verwendet ihr eigenes Portal oder Tool und hofft dann, dass die anderen Parteien es übernehmen. Von dort aus erfolgt die Kommunikation zwischen den Parteien hauptsächlich per E-Mail. In einigen Fällen verwendet der Endbenutzer die Portale oder Tools des Dienstanbieters zur Kommunikation, wenn die IT-Abteilung kein eigenes Portal hat.

Endkunden erwarten, dass ihre Probleme zeitnah und ohne Frustration gelöst werden. Andererseits müssen die Service Desks innerhalb der Grenzen von SLAs und OLAs arbeiten — mit anderen Worten, sie müssen in der Lage sein, die Dienstleistungen innerhalb der vereinbarten Fristen und in der vereinbarten Qualität zu erbringen.

Wenn ein Endbenutzer beispielsweise ein Problem- oder Bestellticket einreicht, sendet die IT-Abteilung eine Benachrichtigung an den Endbenutzer, in der bestätigt wird, dass er das Ticket erhalten hat. Wenn der Service Desk das Ticket nicht selbst lösen kann, leitet er es einfach an den für den jeweiligen Service zuständigen Dienstanbieter weiter. Der Endkunde hat jedoch nur die erste Bestätigungs-E-Mail erhalten und hat daher keinen Überblick über den Ticketstatus.

Schmerz für den Endkunden:
‍Sobald der Endkunde das Ticket erstellt hat, möchte er natürlich über den Fortschritt informiert werden. Auf herkömmliche Weise muss der Endkunde das Portal besuchen, eine E-Mail senden oder die IT-Abteilung anrufen, um nach Updates zu fragen.

Schmerz für den Service Desk:
‍Der Vorgang ist nicht nur für den Endbenutzer frustrierend, der sich an die IT-Abteilung wenden und nach dem Status des Tickets fragen muss, sondern auch für jeden Service Desk, da er andere Anbieter per E-Mail oder Anruf kontaktieren muss, um Ticketaktualisierungen zu erhalten. Diese Maßnahmen verschwenden Unternehmensressourcen für Prozesse, die automatisiert werden könnten.

Wenn andererseits eine der Parteien andere Anbieter und die Endbenutzer über einen Serviceausfall informieren muss, müssen sie alle Beteiligten separat benachrichtigen. Und im schlimmsten Fall senden Sie die Benachrichtigungen an eine spezielle E-Mail-Adresse — wo sie im Meer der E-Mail-Benachrichtigungen verloren gehen könnten.

Der neue Weg:
‍Wenn alle Parteien in der gesamten Lieferkette der Leistungserbringung integriert würden, würden die Tickets zwischen den Tools fließen und sich an die Prozesse der einzelnen Parteien anpassen. Der Ticketstatus würde in der gesamten Kette aktualisiert und es den Unternehmen ermöglichen, in einer vernetzten Servicearchitektur effizient zusammenzuarbeiten.

Auf diese Weise würden alle Beteiligten Frustration vermeiden, die durch mangelnde Transparenz und das endlose Senden und Anrufen von E-Mails und Anrufen entsteht, um den Ticketstatus herauszufinden. Jeder kann mit seinen eigenen Prozessen arbeiten und entscheiden, wie sich die Prozesse der anderen Unternehmen an die eigenen anpassen. Eine vernetzte Servicearchitektur führt zu effizienteren und zufriedeneren Servicedesk-Mitarbeitern, zufriedeneren Endbenutzern und ermöglicht Skalierbarkeit, da die IT nicht zum Engpass des Geschäftswachstums wird.

Drei spezifische Bereiche, in denen Kommunikationsdienstleister und ihre Kunden von einer vernetzten Dienstarchitektur profitieren würden:

1. Problemticket für den Kunden an den Dienstanbieter
   ‍
2. Kundenbestellung an Dienstleister
   ‍
3. Benachrichtigung des Dienstleisters an den Kunden

Szenario 1: Ein Kunde sendet ein Trouble Ticket an den Dienstanbieter

Traditioneller Weg:  
Nehmen wir an, der Endbenutzer bemerkt, dass seine Internetverbindung unterbrochen ist. In den meisten Fällen würde der Kunde das Problem melden, indem er entweder ein Ticket im Tool seiner eigenen IT-Abteilung erstellt oder das Service Provider-Portal verwendet.

Bild: Das traditionelle Missverhältnis zwischen den Aktualisierungen des Ticketprozesses zwischen dem Dienstanbieter und der IT-Abteilung.

Schmerz für den Endverbraucher:
Wenn der Endbenutzer im Portal des Dienstanbieters ein Trouble-Ticket über den Ausfall der Internetverbindung einreicht, ist die IT-Abteilung nicht in den Prozess involviert, obwohl sie immer noch für die Bereitstellung des Dienstes verantwortlich ist. Wenn der Kunde nach einer Aktualisierung des Tickets fragt, beginnt er in der Regel am Servicedesk der IT-Abteilung, der den Servicedesk des anderen Dienstanbieters kontaktieren muss, um die Informationen zu erhalten. Darüber hinaus müssen sie ein anderes Portal verwenden, das sich von dem Portal ihrer eigenen IT-Abteilung unterscheidet. Sehen Sie, wo es anfangen kann, kompliziert zu werden?

Schmerz für die IT-Abteilung:
Darüber hinaus wird die IT-Abteilung, die die SLAs versteht, keinen Einblick in den Prozess haben, da das Ticket an das Portal des Dienstanbieters übermittelt wurde. Dies verursacht auch manuelle Arbeit für den Service Desk, mit dem sich die IT-Abteilung in Verbindung setzt, und reduziert somit deren Produktivität.

Der neue Weg:
Im Idealfall könnte der Endbenutzer weiterhin sein eigenes Portal oder ein anderes Tool verwenden, um das Ticket zu erstellen, unabhängig davon, wer den Service anbietet, anstatt mehrere verschiedene Portale zu verwenden. Das Incident-Ticket wird automatisch erstellt und allen Beteiligten, wie im Prozessablauf definiert, pünktlich und mit den richtigen Informationen zugestellt. Der Kunde bleibt während des gesamten Prozesses über den Ticketstatus auf dem Laufenden und weder die IT-Abteilung noch der Dienstleister müssen manuell über den Ticketstatus kommunizieren — alles würde automatisch aktualisiert.

Bild: Der Ticketstatus wird bidirektional zwischen dem Endbenutzer, der IT-Abteilung und den Dienstanbietern aktualisiert.

Szenario 2: Kunde, der eine Bestellung an den Dienstleister erstellt

Traditioneller Weg:
Wenn ein Endkunde beispielsweise ein neues iPhone bestellen muss, füllt er normalerweise ein Bestellticket oder ein Bestellformular auf dem eigenen Portal des Dienstanbieters aus. Sehr oft muss der Kunde auch mehrere andere Portale verwenden, um Artikel bei verschiedenen Dienstleistern zu bestellen.

Bild: Der Endverbraucher nutzt verschiedene Portale, um eine Bestellung aufzugeben, sodass der Prozess auf verschiedene Dienstleister verteilt ist.

Schmerz für den Endverbraucher:
Während des Bestellvorgangs müssen der Bestellung weitere verwandte Produkte wie SIM-Karten und Hüllen hinzugefügt werden. Sie müssen jedoch auch die Möglichkeit haben, das Telefon an den Mitarbeiter auszuliefern. Alle am Prozess beteiligten Parteien müssen über die Bestellung informiert werden, um auf ihrer Seite eine Reihe weiterer Prozesse auszulösen. Aufgrund der getrennten Systeme verlieren Kunden und Servicedesk-Mitarbeiter den Überblick über die Bestellungen.

Schmerz für die IT-Abteilung:
Damit die IT-Abteilung die Bestellungen bei jedem Anbieter manuell tätigen kann und Über den Prozess auf dem Laufenden zu bleiben ist ein Albtraum. Wenn ein Unternehmen 100 neue Mitarbeiter pro Monat einstellt, kann diese Art von IT-Prozess zum Engpass für das Geschäftswachstum werden.

Der neue Weg:
In einer vernetzten Servicearchitektur wird die Übertragung der Informationen vom Dienstleister und Kundenportal zum Auftragsverwaltungssystem und wieder zu allen verbundenen Parteien transformiert. Der Bestellvorgang kann die entsprechenden Bestellungen für andere Anbieter automatisch ausfüllen und den Status jeder Bestellung derselben Bestellung aktualisieren. Auf diese Weise bleibt jeder über den Prozess auf dem Laufenden, ohne mit den anderen Anbietern kommunizieren zu müssen.

Bild: Der Endbenutzer verwendet ein Portal, um eine Bestellung aufzugeben, und der Prozess löst die eigenen Tools und Prozesse des Dienstanbieters aus.

Szenario 3: Der Dienstanbieter sendet eine Benachrichtigung an den Kunden

Traditioneller Weg:
Wenn eine IT-Abteilung mehrere Tickets zu ähnlichen Problemen erhält, handelt es sich in der Regel um ein größeres Problem. Nachdem sie das Problem bemerkt haben, müssen sie die Endbenutzer und alle betroffenen Anbieter separat benachrichtigen. Wenn der Dienstanbieter ein Problem mit seinen Diensten feststellt, müsste er außerdem alle zugehörigen Kunden darüber informieren.

Bild: Dienstleister, der eine Benachrichtigung an die Kunden sendet.

Schmerz für den Dienstleister:
Sobald der Dienstleister alle Kunden über den Mangel und den Prozess seiner Behebung informieren möchte, muss er alle Tickets beantworten und die entsprechenden Anbieter separat benachrichtigen. Wenn der Dienstanbieter Benachrichtigungen an andere Anbieter versenden möchte, sind die entsprechenden E-Mail-Ordner zudem voll mit anderen, weniger relevanten Benachrichtigungen, und im schlimmsten Fall bleiben die Benachrichtigungen unbemerkt. In diesem Betriebsmodus wird die kritischste Zeit (die Zeit unmittelbar nach dem Auftreten des Problems) mit der Kommunikation verbracht über das Problem — und nicht darauf, es zu lösen.

Der neue Weg:
In einer vernetzten Servicearchitektur kann die IT-Abteilung ein Mutterticket für ihre eigenen und die IT-Systeme der entsprechenden Anbieter erstellen. Von dort aus können sie damit beginnen, die untergeordneten Tickets zu gruppieren. Es kann auch alle relevanten Anbieter über das Problem informieren und automatisch ein Hauptproblem für ihre Systeme erstellen, auch wenn die Systeme unterschiedliche Tools und Prozesse verwenden.

Auf diese Weise können alle Tickets gleichzeitig über den Prozess aktualisiert werden und bleiben transparent. Die Hauptsache ist, dass jeder das Format der Benachrichtigungen, die er erhält, selbst entscheiden und es so anpassen kann, dass es am besten zu seinem Prozess passt, sodass jeder Benachrichtigungs-Spam vermeidet und dennoch flexibel gegenüber anderen Anbietern bleibt.

Bild: Service Provider sendet eine Benachrichtigung in einer Connected Services Architecture und löst relevante Prozesse in den Tools des Kunden aus.

So erstellen Sie mit ONEiO eine vernetzte Dienstarchitektur

Im Vorfeld von Welt der digitalen Transformation 2022, ONEiO arbeitete mit Accenture, Ericsson, Telia Company, ServiceNow, AT&T und TIM zusammen, um eine vernetzte Servicearchitekturlösung zu entwickeln, die auf den Open APIs von TM Forum basiert.

Die Lösung ermöglicht es Unternehmen, Prozesse wie Produktbestellung und Serviceversicherung wie Incident, Problem und Change einfacher abzuschließen. Und für Dienstleister hilft sie ihnen, sich an die neue Art der Servicebereitstellung anzupassen.

Im nächsten Abschnitt werden wir uns mit den technischen Aspekten befassen, wie Dienstanbieter und ihre Kunden eine vernetzte Dienstarchitektur mit ONEiO erstellen und verwenden können.
‍

Bild: Connected Services Architecture, wie sie im TM Forum vorgestellt wurde.

Ein zentraler Hub, um Ihre Tools zu verbinden

ONEiO ist sofort einsatzbereit, mit den meisten IT-Tools zu kommunizieren, und wir haben die Plattform so konzipiert, dass sie die verschiedenen Prozesse und Mechanismen versteht, die diesen einzelnen Tools innewohnen, egal ob es sich um ServiceNow, Jira oder BMC Remedy oder ein anderes Tool handelt. Das bedeutet, dass ein Großteil der Arbeit, die in eine traditionelle ITSM-Integration gesteckt wird, bereits in ONEiO vorinstalliert wurde.

Der Unterschied zwischen ONEiO und vielen anderen traditionellen Integrationsplattformen besteht darin, dass Sie mit ONEiO Ihre Systeme tatsächlich mit dem zentralen ONEiO-Hub verbinden. Das bedeutet, dass es keine Punkt-zu-Punkt-Integrationen gibt, sondern ONEiO als intelligenter Integrationsbroker zwischen den verschiedenen Systemen fungiert.

Bild: Die ONEiO-Benutzeroberfläche, die in jedem modernen Browser funktioniert und veranschaulicht, wie ONEiO als zentrale Schnittstelle zwischen Ihren ITSM-Tools funktioniert.

Einfache Änderung und Entwicklung von Integrationsregeln und Mappings

Die grundlegende Integrationskonfiguration in ONEiO besteht aus Endpunkttypen und Routing-Regeln. Endpunkttypen sind Konnektoren, die entweder so konzipiert sind, dass sie den Anforderungen eines bestimmten Tools entsprechen, oder, im Fall von Dienstanbietern, der gesamten Palette exponierter Dienste, die der Dienstanbieter seinen Endkunden anbieten möchte.

Bei Endpunkttypen werden auch verschiedene Authentifizierungsmethoden für bestimmte Tools und APIs mithilfe von Routing-Regeln verwaltet. Andererseits stellen sie den tatsächlichen Anwendungsfall und die Logik dar, die die Integrationsregeln bestimmt.

Routing-Regeln sind auch der Ort, an dem Werttransformationen und Zuordnungen vorgenommen werden. Auf diese Ebene kann jeder, der unsere Lösungen verwendet, zugreifen und die Integrationsregeln und Zuordnungen einfach ändern und weiterentwickeln.

TM Forum Catalyst projektspezifische Endpunkttypen für Kommunikationsdienstleister

Für dieses Catalyst-Projekt haben wir an der Erstellung spezieller Endpunkttypen gearbeitet, die den API-Spezifikationen und -Standards von TMF 621 und TMF 622 entsprechen. Das heißt, wenn Sie als Dienstanbieter Ihre APIs gemäß diesen TMF-Spezifikationen erstellt haben, verfügen wir bereits über die Möglichkeit, diese APIs innerhalb von Minuten zu nutzen.

Wenn Sie andererseits keine APIs haben, die auf den TMF-Spezifikationen basieren, können wir einfach eine direkte Verbindung zu Ihrem ITSM-Tool herstellen und dieselben Funktionen problemlos nutzen. Schauen Sie sich als Nächstes die Konfigurationen der Endpunkttypen für das Catalyst-Projekt an.
‍

Bild: Drei verschiedene Endpunkttypkonfigurationen in der ONEiO-Benutzeroberfläche.

Endpunkttyp 1: Übertragung von Bestellungen und Trouble Tickets

Der erste Endpunkttyp steht für große Unternehmenskunden, in diesem Fall für diejenigen, die ServiceNow verwenden. Dieser Endpunkttyp wird verwendet, um die Bestellungen und Problemtickets zu übertragen, die der Kunde an den CSP senden würde. Die Authentifizierungs- und Entitätstypen werden dann in der Haupt-Endpunktansicht in ONEiO konfiguriert, die Sie in der Abbildung unten sehen können.
‍

Bild: Konfigurationsansicht des Endpunkt-Typs 1 in ONEiO. Einschließlich der URL zum ServiceNow-Instant, den wir für den Kunden verwenden, sowie des Authentifizierungs-Benutzernamens und -Passworts.

Darüber hinaus zeigt diese Ansicht die Entitätstypen, die wir für diesen Endpunkttyp konfiguriert haben. Insgesamt haben wir Änderungsanträge, CSM-Bestellungen, CSM-Auftragspositionen, Vorfälle, Probleme und Serviceanfragen. Dies sind alles einfache Konfigurationen, bei denen wir ONEiO im Wesentlichen mitteilen, welche Art von Feldern sie für jeden dieser Entitätstypen erwarten sollten.
‍

Bild: Konfigurationen für verschiedene Entitätstypen, dargestellt auf der ONEiO-Benutzeroberfläche.

Endpunkttyp 2: Problembehandlung und proaktive Tickets

Der zweite Endpunkttyp steht für den CSP Service Desk. Dieser Endpunkt wird für die Bearbeitung der vom Kunden gesendeten Trouble Tickets verwendet. Er kann aber auch proaktive Tickets vom CSP verarbeiten und diese an die Kunden weiterleiten — das ITSM-Tool.

Wenn der CSP beispielsweise feststellt, dass ein Serviceausfall vorliegt, kann er einen Vorfall erstellen und ihn an den Kunden weiterleiten, damit der Kunde reagieren und das Problem beheben kann. Und für diesen Endpunkt ist es dasselbe Setup. Wir haben die URL zur ServiceNow-Instanz des CSP sowie die Authentifizierungs- und Benutzeranmeldeinformationen, wie in der Abbildung unten dargestellt.
‍

Bild: Endpunkt-Typ-2-Konfigurationsansicht in ONEiO.

Bei den Entitätstypen unterscheiden sie sich ein wenig, da wir für den CSP mit den Entitäten Case Change Request, Incident, Problem und Service Request arbeiten.

Endpunkttyp 3: Weiterleitung von Bestellungen auf Kundengeräten an das Auftragsabwicklungssystem

Schließlich haben wir den CSP-Bestellendpunkttyp, der verwendet wird, um die Bestellungen von Kundengeräten an das Auftragsabwicklungssystem weiterzuleiten, das in diesem Fall von Ericson entwickelt wurde. Auch hier handelt es sich um eine ähnliche Konfiguration mit einer etwas anderen Ansicht aufgrund unterschiedlicher Authentifizierungsmethoden. Hier die URL, die Owl-Anmeldeinformationen und die Entitätstypen. In diesem Fall handelt es sich nur um Bestellungen, da es sich nur um Bestellungen an Ericsson handelt.
‍

Bild: Endpunkt-Typ-3-Konfigurationsansicht in ONEiO.

Traditionelle Konfigurationsarbeiten sind nicht erforderlich

Die Stärke von ONEiO liegt in seiner Anpassungsfähigkeit. Unsere Plattform wandelt alle Payloads, die wir erhalten, in ein generisches ONEiO-Datenmodell um, was bedeutet, dass es uns egal ist, in welchem Format Ihr Tool spricht. Das bedeutet auch, dass keine Datenmodelltransformationen konfiguriert werden müssen und die eigentlichen Integrationsregeln leicht wiederverwendet werden können, da sie nicht an ein bestimmtes Datenformat gebunden sind.

Die Konvertierung von Daten in die ausgehende Nutzlast ist dann ähnlich einfach — und Sie können wahrscheinlich verstehen, wie viel von der herkömmlichen Konfigurationsarbeit durch diese Art der Datenverwaltung weggenommen wird. Als Nächstes werfen wir einen Blick auf die Nachrichtenansicht der ONEiO-Benutzeroberfläche.
‍

Bild: ONEiO-Nachrichtenansicht.

In der ONEiO-Nachrichtenansicht stellen wir fest, dass wir eine neue Bestellung von der Kundenseite haben. Im Grunde erhalten wir eine eingehende Nachricht von ServiceNow des Kunden, und es wird erkannt, dass es sich um eine neue Gerätebestellung handelt, die vom Kunden ausgestellt wurde. Dann analysieren wir automatisch die eingehenden Feldwerte, und danach sind sie sofort als generische Eingabewerte verfügbar, die ONEiO verwenden und weiterleiten kann.

Dann erstellen wir die richtige Nutzlast für ausgehende Daten, die dem TMF 622-Standard entsprechen, und leiten sie an die TMF 622-API weiter, die Ericsson für sein Auftragsverwaltungssystem eingerichtet hat. Links im Bild unten sehen Sie die Nutzlast für eingehende Daten und rechts die Nutzlast für ausgehende Daten.
‍

Bild: Neue Gerätebestellung in der ONEiO-Messaging-Ansicht. Eingehende Datennutzlast auf der linken Seite und ausgehende Nutzlast auf der rechten Seite in der ONEiO-Messaging-Ansicht.

Wenn wir uns die Details ansehen, können wir sehen, dass dies die tatsächliche JSON-Nutzlast ist, die wir an Ericsson senden, und sie entspricht dem TMF 626-Standard und der Spezifikation.
‍

Bild: JSON-Spezifikation, dargestellt in ONEiO.

Wenn wir uns dann die tatsächliche Zuordnung hinter dieser Regel ansehen, können Sie sehen, dass es sehr einfach von einem Feld zum anderen ist, und das ist alles, was benötigt wird.
‍

Bild: In ONEiO illustrierte Mappings.

Wenn wir wieder zur Nachrichtenansicht zurückkehren, können wir auch sehen, dass wir einen tatsächlichen Vorfall von einem Kunden haben. Die eingehende Payload befindet sich links und die ausgehende Payload rechts.
‍

Bild: Vorfall eines Kunden, der auf der ONEiO-Benutzeroberfläche dargestellt ist.

Dies verwendet jetzt die TMF 621-API-Spezifikation, daher sieht es ein bisschen anders aus — aber die gleichen Prinzipien gelten auch hier. Wenn Sie die Regel hinter der Aktion „Erstellen“ beachten und zu den Mappings navigieren, können wir sehen, dass es immer noch ziemlich einfach ist.

Zum Beispiel haben wir Status und Status auf der ausgehenden Seite, und wir können sozusagen bedingte Zuordnungen durchführen. Wenn also ein Status auf Kundenseite beispielsweise zwei ist, dann entspricht das einem Status, der auf der CSP-Seite in Bearbeitung ist, und dasselbe kann mit Schweregrad, Auswirkung, Priorität geschehen — alles, was Sie wollen.
‍

Bild: Bedingte Zuordnungen, dargestellt auf der ONEiO-Benutzeroberfläche.

Behalten Sie den Überblick über den Kontext mit der Konversationsfunktion

Es gibt eine Funktion in ONEiO, die (zumindest unserer Meinung nach) sehr cool ist, und das sind Konversationen. Wenn wir von der Nachrichtenansicht zu einer Konversation navigieren, können wir sehen, dass ONEiO alle Nachrichten verfolgt, die mit einer einzelnen Konversation verknüpft sind. Dies ist besonders wichtig, wenn wir Fälle zwischen zwei verschiedenen Systemen austauschen, bei denen wir den Kontext des Austauschs beibehalten müssen. Wir wiederum wissen, dass dieses Ticket oder dieser Vorfall auf der einen Seite genau diesem Ticket oder Vorfall auf der anderen Seite entspricht, und das ist in ONEiO integriert.

Bild: Verwenden der Konversationsfunktion auf der ONEiO-Benutzeroberfläche.

Im Wesentlichen werden Konversationen an Ort und Stelle gehalten und verfolgt. Auf diese Weise werden keine Aktualisierungen an den falschen Entitäten auf beiden Seiten vorgenommen, wie wir es durch die durchgängige Protokollierung einzelner Konversationen getan haben.

Fazit

Dies war ein kurzer Überblick über die Grundprinzipien, mit denen ONEiO arbeitet. ONEiO ist ein maßgeschneidertes Tool für die nahtlose Kommunikation und Zusammenarbeit zwischen Kunden und Kommunikationsdienstleistern.

Wir hoffen, dass Sie sich ein Bild von unserer Technologie gemacht haben, und wenn Sie weitere Fragen haben, zögern Sie bitte nicht kontaktiere uns bei ONEiO.

‍

Laden Sie diesen Artikel als PDF herunter