DE102015104865A1

DE102015104865A1 - Graphdatenbank für ein Contact-Center

Info

Publication number: DE102015104865A1
Application number: DE102015104865.5A
Authority: DE
Inventors: Wen-Hua Ju; Robert C. Steiner
Original assignee: Avaya Inc
Current assignee: Avaya Inc
Priority date: 2014-05-29
Filing date: 2015-03-30
Publication date: 2015-12-03
Also published as: US20150347421A1; BR102015007165A2

Abstract

Es wird eine Graphdatenbank für den Einsatz in Verbindung mit einem Contact-Center beschrieben. Die Graphdatenbank weist mehrere Knoten und Beziehungen auf, die die Operationen, die Entitäten, das Personal und die Attribute im Contact-Center beschreiben. Die Graphdatenbank macht es möglich, dass bisher eigenständige Contact-Center-Komponenten wie Aufgabenzuweisungs-, Berichts-, Personaleinsatzplanungs-, Prognosekomponenten und dergleichen nahtlos und integriert zusammenarbeiten.

Description

GEBIET DER OFFENBARUNG
Die vorliegende Offenbarung betrifft allgemein den Kommunikationsbereich und insbesondere Contact-Center.
ALLGEMEINER STAND DER TECHNIK
Contact-Center entstanden ursprünglich als Analogie zum telefonischen Kundendienst. Bisher hat insbesondere die Warteschlangentheorie die Entwicklung von Contact-Centern dominiert.
In den letzten Jahren kam es jedoch bei der Contact-Center-Architektur zu beträchtlichen Fortschritten sowie zu einem Abrücken von der herkömmlichen Arbeitsaufgabe/Agent-Warteschlange. Ein Beispiel für ein solches Contact-Center ist in US-Patentschrift Nr. 8,619,968 beschrieben, deren gesamter Inhalt durch Verweis darauf als hiermit aufgenommen gilt. Diese Implementierung des warteschlangenfreien Contact-Centers stellte eine völlig neue Denkweise und Herangehensweise im Hinblick auf den Aufbau von Contact-centern dar. Bei der Entwicklung des warteschlangenfreien Contact-Centers wurden einige Hindernisse identifiziert und in den meisten Fällen überwunden. Allgemein bietet das Implementieren eines warteschlangenfreien Contact-Centers beträchtliche Vorteile.
Im Grunde ist das warteschlangenfreie Contact-Center jedoch immer noch von einer großen Anzahl diskreter Module und Systeme abhängig, die miteinander verbunden sind und kommunizieren. Insbesondere ist die Arbeitsaufgaben-Zuweisungsmaschine vom CRM-System (CRM – Customer Relationship Management, dt. Kundenpflege) getrennt und beide sind von Personaleinsatzplanungssystemen (PEP) getrennt. Die Arbeitsaufgaben-Zuweisungsmaschine ist auch von Workflow-(Front- und Back-Office), Sprachportal- und anderen Sprachdialogsystemen (IVR – Interactive Voice Response) sowie zusätzlichen Berichts- und Prognosesystemen getrennt.
Ein Hauptproblem bei bestehenden Contact-Center-Lösungen liegt darin, dass es keine günstige oder einfache Möglichkeit des Zusammenwirkens der oben genannten Contact-Center-Komponenten gibt. Ein weiteres Problem mit dem Abrücken von herkömmlichen Contact-Centern auf Warteschlangenbasis besteht darin, dass die starre Struktur der Warteschlange auf natürliche Weise den Typ von Daten einschränkte, die für Arbeitsaufgabenzuweisung, Berichterstellung usw. von Interesse waren. Somit erhöht sich ohne eine vorhandene Warteschlange die Menge der mit Arbeitsaufgaben und Agenten verknüpften Daten (z. B. Attribute) exponentiell. Derzeitige Contact-Center-Datenbanken unterstützen das Erstellen von Attributsätzen (z. B. eines Satzes von Attributen, die eine bestimmte Arbeitsaufgabe oder einen bestimmten Agenten beschreiben) nicht ohne Weiteres. In der Tat wurde die Contact-Center-Datenbank für jeden neuen oder möglichen Attributsatz manuell aktualisiert. Wird ein einziges Attribut zum Contact-Center hinzugefügt, vervielfacht sich die mögliche Anzahl von Attributsätzen. Diese Datenvolumenzunahme bringt die in Contact-Centern benutzten aktuellen Datenbankstrukturen an ihre Grenzen.
Es wird eine umfassendere Lösung für die Entwicklung eines Contact-Centers benötigt, unabhängig davon, ob dieses warteschlangenfrei ist oder auf Warteschlangen basiert. Es wird insbesondere ein völlig neues Modell benötigt, das den nächsten Durchbruch bei der Contact-Center-Entwicklung ermöglicht.
KURZDARSTELLUNG
Ein Aspekt der vorliegenden Offenbarung besteht daher darin, ein neues Modell für die Verwendung in einem Contact-Center vorzustellen. Ausführungsformen der vorliegenden Offenbarung schlagen insbesondere den Einsatz einer Graphdatenbank vor, die die herkömmlichen hierarchischen Datenbanken ersetzen soll, welche bisher in Contact-Centern verwendet werden, unabhängig davon, ob diese warteschlangenfrei sind oder auf Warteschlangen basieren.
Ein Aspekt der vorliegenden Offenbarung ermöglicht es einem Contact-Center, eine gemeinsame Datenstruktur zu nutzen, die den Zustand des Contact-Centers und der darin befindlichen Komponenten besser beschreibt und sich problemlos auf neue und andere Konzepte wie Zielmanagement, Prozesssteuerung, Analytik und kontextbezogene Arbeitsaufgabenzuweisung erweitern lässt. Bei dem hier vorgeschlagenen neuen Modell handelt es sich um einen Graphen und es wird ein graphbasierter Bezugsrahmen (z. B. eine Graphdatenbank) mit skalierbarer, robuster und kosteneffektiver Modellierung des gesamten Contact-Centers vorgeschlagen. Dieses Modell ermöglicht eine einfache Integration von Arbeitsaufgabenzuweisung, Administration, Berichterstellung, Prozesssteuerung und Medienmanagement ohne Übersetzung in komponentenspezifische Modelle. So stehen nicht nur die Informationen aus der Graphdatenbank problemlos für alle Contact-Center-Teilsysteme zur Verfügung, sondern die Graphdatenbank ist in hohem Maße skalierbar und kann ohne Weiteres kleine, mittlere und große Contact-Center-Installationen unterstützen.
Gemäß zumindest einigen Ausführungsformen beschreibt eine Graphdatenbank alles, was darin gespeichert ist, mit Hilfe von Knoten und Beziehungen. Bei den Knoten kann es sich um alles von Interesse handeln, unter anderem um ein Attribut (z. B. Merkmal oder Eigenschaft einer Ressource, eine Arbeitsaufgabe usw.), eine Ressource selbst, eine Arbeitsaufgabe selbst, ein Ergebnis, ein Maß, eine zwischen Knoten erfolgte Interaktion oder Konferenz usw.
Ein Aspekt der Graphdatenbank besteht darin, dass sie einen Attributbaum unterstützt. Bei einem Attribut handelt es sich um eine Eigenschaft, eine Qualität, eine Bearbeitungsanforderung und/oder ein Merkmal einer Entität. Zu Beispielen für Attribute können Sprache, Alter, Produktinformationen (z. B. SCHLUSSVERKAUF-MÖBEL) und andere demografische Angaben gehören. Attribute werden allgemein von einer Arbeitsaufgaben-Zuweisungsmaschine so für Routing-Entscheidungen berücksichtigt, dass Ziele und/oder Sollmetriken für ein Contact-Center optimal erreicht werden. Aktuelle Systeme erfordern oft das Gruppieren der Attribute zu Sätzen zum Abgleichen und Berichten. Die vorliegende Offenbarung wird hingegen den Attributbaum direkt zum Abgleichen verwenden, dadurch den Attributsatz eliminieren und die auf natürliche Weise definierten Beziehungen eine einfache Nachbarschaftsbestimmung ermöglichen lassen.
So kann beispielsweise durch Verwenden eines Attributbaums bei der Arbeitsaufgabenzuweisung eine Anforderung ENGLISCH von einer Arbeitsaufgabe durch ENGLISCH-GB oder ENGLISCH-USA erfüllt werden, oder eine Anforderung ENGLISCH-GB kann über ENGLISCH-USA bearbeitet werden (weil die Graphdatenbank z. B. die Beziehung beschreibt, sind sowohl britisches als auch US-Englisch Kinder von ENGLISCH), was jedoch mit geringfügigen Kosten belegt oder fast gleich gut wie bzw. besser ist als andere Optionen.
Ausführungsformen der vorliegenden Offenbarung ermöglichen innerhalb des neuen Bezugsrahmens ein Bewegen auf dem Graphen nach oben und unten, um nahe Übereinstimmungen zu erzielen, daher ist die Beziehung zwischen Knoten wichtig. Routing-Entscheidungen können auf der Grundlage der Nähe zu einem vorgegebenen Attribut im Attributbaum gefällt werden. Berichterstellung und Administration können den Baum für „Roll-up“ und „Drill-down“ benutzen.
Ein weiterer Aspekt der vorliegenden Offenbarung besteht in der Nutzung eines Gewichtungssystems zum Bestimmen von Kosten beim Hinauf- und Herabbewegen im Baum und diese Gewichtungen können bei Arbeitsaufgaben-Zuweisungsentscheidungen berücksichtigt werden. Anpassungen können auf jeder Ebene des Attributbaums unter Verwendung des Mechanismus zum Hinauf- und Herabbewegen im Graphen vorgenommen werden. Die vorgeschlagene Offenbarung macht die Notwendigkeit mehrerer Attributsätze und eines Attributsatzausschlusses hinfällig. Die Berichterstellung wird ebenfalls sehr einfach. Es wird ein natürlicher Roll-up- und Drill-Down-Graph bereitgestellt.
Wenn zum Beispiel eine Arbeitsaufgabe eintrifft, die die Attribute Englisch, Verkauf, Bestandskunde, KabelTV und Premium erfordert, kann Agent 2 dann etwas oder alles davon übernehmen? Kann Agent 3 es jetzt übernehmen, so dass das System nicht auf Agent 2 warten muss, obwohl Agent 3 normalerweise nur reguläre und keine Premium-Kunden bedient? Wenn in den nächsten zehn Minuten nur Agent 4, der nur Spanisch spricht, zur Verfügung steht, ist das dann eine brauchbare Option? Wie hoch wären die Kosten? In dem Graphen würde je nach Kosten Nähe als gewichtetes Ziel betrachtet sowie relative Nähe bei Verzweigung. Es könnten Entscheidungen zur besten Übereinstimmung, nächstbesten Übereinstimmung und „Besser als Abbruch“-Übereinstimmung gefällt werden.
Das Erweitern des Graphmodells ermöglicht das Hinzufügen neuer Knoten und Beziehungen, was unkompliziert ist. Es gibt kein vorgegebenes Schema. Der Graph kann statische Beziehungen (z. B. Attribute) und dynamische Beziehungen wie Anrufverlauf, Agentenpräferenzen, Prozessschritte, Ziele, Kosten, Vorteile und Zustand repräsentieren. Durch Durchlaufen des Graphen kann das System die Kosten und Vorteile von Entscheidungen berechnen, und zwar nicht nur bei der Arbeitsaufgabenzuweisung, sondern auch bei Prozesssteuerung und Workflow. Durch Verwenden einer gemeinsamen Datenstruktur (z. B. einer Graphdatenbank) können die gleichen Prinzipien, die für die Arbeitsaufgabenzuweisung verwendet werden, auf andere Entscheidungsbereiche ausgeweitet werden, so dass eine gemeinsam genutzte Arbeitszuweisungsentscheidungsmaschine benutzt werden kann und sich Komplexität und Redundanz des Contact-Centers weiter reduzieren lassen.
Bei manchen Ausführungsformen wird eine Graphdatenbank für das Domain-Modell benutzt. Sie repräsentiert das gesamte System, Echtzeit, Verlauf, Abgleich, Einsatz, Workflow und Administration. Diese Datenbank besteht aus Knoten (z. B. Vertexpunkten), die durch Beziehungen (z. B. Kanten) miteinander verbunden sind. Bei manchen Ausführungsformen kann jeder Knoten und jede Beziehung Eigenschaften besitzen. Die Eigenschaften können einen Namen wie „bearbeitet“ und einen Zeitstempel und eine Dauer wie „@T9,1“ besitzen, die angeben, wann sie auf der Beziehung/dem Knoten platziert werden. Dieser Mechanismus bietet eine einfache Möglichkeit, die Ereignisse (z. B. Änderungen von Eigenschaften und Beziehungen) für die Analyse zeitlich zu ordnen.
Eine erste Implementierung des Graphen kann sehr einfach sein. Es kann drei Klassen geben, die den zugrundeliegenden Graphen bilden. Bei manchen Ausführungsformen kann sich sowohl der Knoten als auch die Beziehung aus der Elementklasse mit dem Satz Eigenschaften ableiten. Beim Verbinden von Instanzen dieser Klassen kann die Beziehung zwischen zwei Entitäten (z. B. Knoten) sowohl zur „An“- als auch zur „Von“-Knotenbeziehungskollektion hinzugefügt werden. Auf diese Weise kann der Graph in beiden Richtungen durchlaufen werden. Aus Effizienzgründen können Namen von Knoten und Eigenschaften als ganze Zahlen und in einer allgemeinen Symboltabelle gespeichert werden. Durch das Vorhandensein einer Symboltabelle erhöht sich zwar die Effizienz der Suche und des Nachschlagens von Namen, doch muss die Symboltabelle in einem Hochverfügbarkeitsnetz (HV-Netz, High Availability Grid) über alle Recheninstanzen hinweg instanziiert sein.
Bei manchen Ausführungsformen kann ein einziges Berichtssystem auf der Grundlage der Möglichkeiten des neuen Graphmodells über alle diskreten und verschiedenen herkömmlichen Komponenten berichten, einschließlich Informationen aus IVR, Arbeitsaufgaben-Zuweisungsmaschine, CRM, PEP, Mediensteuerung, Prognose, Workflow usw.
Bei manchen Ausführungsformen fordert jeder Teil eines Workflows eine Arbeitsaufgaben-Zuweisungsentscheidung zum Hinzufügen einer Ressource zu einem Knoten bei der Bearbeitung an. Wurde die Arbeitsaufgabenzuweisung herkömmlicherweise für die Ressourcenauswahl benutzt, gehören nun alle Teile des Graphen zum Workflow. Jeder Knoten im Workflow-Graph kann eine Ressource enthalten und Aufgaben aus dem Workflow werden von der Ressource erledigt.
Bei manchen Ausführungsformen besitzen die Beziehungen der Graphdatenbank Eigenschaften. Würden diese Beziehungen in einer relationalen Datenbank als weitere Tabelle mit fremden Schlüsseln in die „Knotentabellen“ modelliert, müsste für jeden einzelnen zu einer Beziehung gehörenden Satz Eigenschaften eine weitere Tabelle erstellt und die relationale Datenbank für die von der Software benutzten Objektmodelle modifiziert werden. Das kann sehr kostspielig und komplex werden, wenn es tausende Sätze von Eigenschaften gibt.
Ein Vorteil, der durch Einsatz einer Graphdatenbank statt einer relationalen Datenbank erzielt wird, ist die Erweiterbarkeit. Eine neue Beziehung lässt sich bei einer Graphdatenbank im Gegensatz zu einer relationalen Datenbank einfach und schnell erstellen. Bei einer relationalen Datenbank muss das Schema geändert (neue Tabellen bei neuen Beziehungseigenschaften), müssen neue Schlüssel hinzugefügt und die Daten migriert werden.
Ein Vorteil einer Graphdatenbank für ein Contact-Center besteht darin, dass sich Workflow-Modell, Verlaufs-, Echtzeit- und Arbeitsaufgabenzuweisungsmodell vereinheitlichen lassen, ohne dass Umwandlungen in eine und aus einer relationalen Datenbank (RDB) nötig sind. Dies vereinfacht Implementierung und Pflege und sorgt für mehr Robustheit. Ein weiterer Vorteil besteht hier darin, dass die Kernkomponenten des Contact-Centers (z. B. Workflow, Berichterstellung, Arbeitsaufgabenzuweisung und Steuerung) direkt an dem Modell im Speicher arbeiten können. Somit wird das Implementieren des Skriptings um eine Größenordnung einfacher, da keine Datenbankverwaltung erforderlich ist.
So handelt es sich beim Hinzufügen einer neuen Beziehung beispielsweise einfach um eine Operation „Beziehung mit Eigenschaften hinzufügen“. In der Welt des Skriptings erfordert dies derzeit ein Koordinieren der Modifikation mit einer Änderung der relationalen Datenbank, danach das Hinzufügen der neuen Tabellen und das Hinzufügen von Schlüsseln zu den verbundenen Knoten. Noch schwieriger ist es, wenn die Beziehung mehrere Knotentypen umfasst (ein Knotentyp, z. B. ein Kontakt, würde von einer Tabelle repräsentiert), da jede Tabelle so modifiziert werden müsste, dass sie Schlüssel für die anderen Knoten aufweist, die sich an dem anderen Ende befinden können. Es gibt Möglichkeiten, dies generisch zu tun, doch leiden sie darunter, dass sie selbst für einfache Abfragen komplexe Verknüpfungen benötigen.
Ein weiterer Aspekt der vorliegenden Offenbarung besteht darin, einen Mechanismus für das Berichten über widersprüchliche multidimensionale Metriken zum Bereitstellen eines visuellen Leistungsmodells bereitzustellen. Ziel ist das Bereitstellen einer regionsbasierten, farbcodierten Zuordnung von Maßen als einfache visuelle Ausgabe.
Ein weiterer Aspekt der vorliegenden Offenbarung besteht in der Möglichkeit, mehrere Metriken in neun Regionen (oder potenziell 27 Regionen bei einer 3D-Zuordnung) modellieren zu können, wobei eine Farbe für „überbedient“, eine andere Farbe für „ok“, eine weitere Farbe für „grenzwertig“ und eine weitere Farbe für „ernsthaftes Problem“ steht. Wenn eine Region beispielsweise rot ist, kann das darauf hinweisen, dass (bei einer zweidimensionalen Zuordnung) beide oder (bei einer dreidimensionalen Zuordnung) alle Maße problematisch sind. Bereiche/Schwellenwerte (z. B. 20 bis 40 Sekunden für einen Abbruch) können von einem Administrator für jede der repräsentierten Metriken sowie für Gruppen und Summen von Metriken festgelegt werden. Die Metriken können außerdem zu Berichts- und Dokumentationszwecken gesammelt werden.
Das Anzeigemetrikschaubild kann auf der Grundlage der widersprüchlichen Metriken in neun Regionen unterteilt werden und jede der Regionen kann einer Aktion zugeordnet werden. Der Administrator kann auf der Grundlage des Zustands der Regionen einen Algorithmensatz (20 bis 30 gute Algorithmen) erstellen, der so ausgelegt ist, dass er das Verhalten des Contact-Centers ändert.
Bei einem nicht einschränkenden Beispiel kann das System, wenn der Service-Level Maß A und die Abbruchrate Maß B ist und die Region, in der die beiden konvergieren, rot wird, automatisch Reserveagenten hinzuziehen. Jede Region würde so zugeordnet, dass die Beziehungen auf der Grundlage eines einfachen Modells verwaltet werden, wobei jede der Auswirkung der jeweiligen Änderungen zugeordnet wird. Ein weiteres Beispiel für ein widersprüchliches Paar kann Geld/Kosten sein, wobei eine Region das Metrikpaar beschreibt. Die Anzeige kann, wenn viele Metriken betroffen sind, durch die farbige Darstellung auch darauf hinweisen. Korrekturmaßnahmen können auch angezeigt werden, wenn automatische Aktionen ergriffen werden, und es können Warnungen an Agenten, Gruppen und Administratoren gesendet werden. Außerdem kann die regionale Zuordnung eine Identifizierung komplementärer Metriken und widersprüchlicher Metriken enthalten oder nur komplementäre Metriken, jeweils mit Algorithmen zum Ändern des Contact-Center-Verhaltens auf der Grundlage des Zustands der Regionen.
Ein weiterer Aspekt der vorliegenden Offenbarung besteht darin, einen Mechanismus zum Festlegen von Parametern und Feinabstimmungszielen in einem Contact-Center bereitzustellen. Ziel ist es, einen Schieber für jedes Ziel in der Benutzerschnittstelle bereitzustellen, der einen einfachen Mechanismus zum Modifizieren von Zielen auf Makroebene bereitstellt, sogar von Zielen, die mehrere Maße enthalten.
Ein solches Merkmal gibt dem Administrator die Möglichkeit, an Zielen in einer neuen Benutzerschnittstelle Änderungen auf Makroebene vorzunehmen. Die Schieberbereiche können für (geringfügige und umfangreichere) Anpassungen hin und her verschoben werden. Dies sind die Hebel, die zum Abstimmen des Verhaltens des Contact-Centers verwendet werden.
Bei einem nicht einschränkenden Beispiel werden dem Administrator vier Schieber zum Anpassen von Zielen mit mehreren Metriken zur Verfügung gestellt: (a) Vertrieb/Erstkunde: 0–2 % AB, 95–100 % in 20 s SL, (b) Vertrieb/Bestandskunde: 0–5 % AB, 80–100 % in 30 s SL, (c) Trennen + Internet: 1–2 % AB, 95–100 % in 20 s SL und (d) Problem: 5–10 % AR, 60–90 % in 60 s SL.
Bei einer zusätzlichen Ausführungsform können dem Administrator zusätzliche und/oder andere Schieber zum Ändern kritischer Maße, wie Service-Level-Objective (SLO), zur Verfügung gestellt werden. Alternativ oder zusätzlich dazu können Änderungen eines oder mehrerer Ziele auf der Grundlage der Beziehungen zwischen den Zielen automatisch die Schieberposition für andere Ziele ändern. Bei einem nicht einschränkenden Beispiel können, wenn Ziel A für ein neues Level angepasst wird, bei dem zur Abdeckung der Änderung zusätzliche Ressourcen umgelegt werden, auch die Ressourcen für Ziel B betroffen sein. Ziel B kann weniger Ressourcen haben, da diese nun zur Unterstützung von Ziel A genutzt werden. Der Schieber für Ziel B kann sich automatisch nach oben oder unten verschieben, wenn Ziel A angepasst wird, so dass jedes Ziel weiterhin innerhalb eines Leistungsbereichs liegt, in dem es sich erwartungsgemäß befinden soll. Auf der Grundlage der Abhängigkeiten und Beziehungen zwischen den Zielen muss das Ändern eines Ziels andere Ziele nicht beeinflussen, kann aber ein einzelnes anderes Ziel ändern oder mehrere Ziele ändern, wobei jedes beeinflusste Ziel sich ein wenig verschieben oder eine beträchtliche Verschiebung aufweisen kann.
Ein weiterer Aspekt der vorliegenden Offenbarung besteht darin, ein Zielmodell zur Verfügung zu stellen, das einen Baum, Knoten und Beziehungen definiert, die zum Verwalten mehrerer administrierbarer Ziele mit zugehörigen Metriken und Vorgaben mit komplexen Abfragen umgehen können.
Ein Ziel ist eine Motivation, die abstrakt oder konkret sein kann, wie „meinen Vertrag einhalten“ oder „10% Umsatzsteigerung“. Für jedes Ziel können Metrikgruppen eingerichtet werden, die ein Erreichen des Ziels angeben. Maße können zum Angeben von zielorientierten Ergebnissen benutzt werden (z. B. Berechnungsweise, Variablen, Kosten, Vorteile), einschließlich eines Vorgabebereichs für jede Metrik und/oder Metrikgruppe. Es kann eine Hierarchie eingerichtet werden, die zum Steuern der Operation der Hauptkomponenten des Contact-Centers benutzt werden kann (Hauptkomponenten: Arbeitsaufgabenzuweisung, Administration, Personaleinsatz, Berichterstellung, Steuersysteme, Endpunkte, IVR, Sprachportal, E-Mail-System, Social-Media-Systeme (Orchestrierung), Hilfsmittel für die Zusammenarbeit (z. B. Konferenzeinrichtungen, Hilfsmittel für die gemeinsame Mediennutzung) usw.). Die Konzeption ist von oben nach unten strukturiert und umfasst Sollziele, Sollvorgaben, erforderliche Metriken und Daten.
Dies lässt sich bei der Implementierung auf der Grundlage von gesammelten Daten, berechneten Metriken, ausgewerteten Vorgaben und beeinflussten Zielen individuell anpassen.
Als nicht einschränkendes Beispiel kann sich ein Administrator eine bestimmte Abbruchrate (AR) zum Ziel setzen. Um zur vorgegebenen AR zu gelangen, erstellt der Administrator ein Ziel und legt dabei einen AR-Sollbereich für jede Serviceklasse fest, für die Attribute zum Bestimmen der Serviceklassen benutzt werden. Bei Bedarf können bestimmte Arbeitsaufgaben-/Ressourcen-Richtlinien mit aufgenommen werden. Die Arbeitsaufgaben-Zuweisungsmaschine prüft alle möglichen Routing-Optionen mit einer Scoring-Funktion, um zum Sollbereich der Betriebs-AR zu gelangen. Die Arbeitsaufgaben-Zuweisungsmaschine geht auf der Grundlage einer vom Benutzer vorgegebenen Priorität angemessene Kompromisse zwischen verschiedenen Serviceklassen ein.
Danach legt der Administrator Vorgaben fest. So können beispielsweise die folgenden Vorgaben spezifiziert werden:

%Abbruch-Vorgaben

Vertrieb/Erstkunde: 0–2 %

Vertrieb/Bestandskunde: 0–5 %

Kundendienst/Problem: 5–10 %

Sonstige: 0–20 %.
Als Drittes definiert der Administrator, welche Metriken und Daten benötigt werden. Die AR-Zählung kann auf flexible Weise feinabgestimmt/individuell angepasst werden, um die besonderen Anforderungen des Contact-Centers zu erfüllen. Für jede Vorgabengruppe werden Prioritäten bestimmt. Die Gruppe/n mit der höchsten Priorität wird/werden ausgewählt und die Aufgabe/n mit der höchsten Abbruchwahrscheinlichkeit wird/werden gewählt.
Durch Abarbeiten einer Aufgabe in einer Gruppe „unter Vorgabe“ kann der Administrator die %Abbruch in den Vorgabebereich bringen (verbessern). Indem er eine Gruppe „über Vorgabe“ nicht bedient, kann der Administrator die %Abbruch wieder in den Vorgabebereich zurückschieben. Innerhalb der Berichtsstruktur wird die AR erfolgreich zur Vorgabe hin geführt.

Bei einem weiteren nicht einschränkenden Beispiel kann der Administrator wünschen, Ziele für AR und Service-Level (SL) festzulegen. Dementsprechend legt der Administrator einen Sollbereich für SL und AR für jede Attributgruppe fest. Attribute werden zum Bestimmen von Übereinstimmungen benutzt. Der Mechanismus prüft alle möglichen Routing-Optionen mit einer Scoring-Funktion, um gleichzeitig zum Sollbereich des Betriebs-SL und der Betriebs-AR zu gelangen, und geht auf der Grundlage der vom Administrator vorgegebenen Priorität zwischen verschiedenen Gruppen angemessene Kompromisse ein. So können beispielsweise die folgenden Ziele definiert sein: Ziele

Vertrieb/Erstkunde	(so schnell wie möglich bedienen)
0–2 % AB	95–100 % in 20 s SL
Vertrieb/Bestandskunde	(kann warten, da es keine Sonderangebote gibt)
0–5 % AB	80–100 % in 30 s SL
Trennen + Internet	(Werbeaktion zwecks Kundenbindung)
1–2 % AB	95–100 % in 20 s SL
Problem	(nicht überbedienen)
5–10 % AB	60–90 % in 60 s SL
Sonstige	(bisher nicht wichtig für das Geschäft)
10–20 % AB	70–95 % in 120 s SL

Zu über solche Ziele gewonnenen Erkenntnissen gehört die Möglichkeit, die Verteilung auf Anrufe für verschiedene Produkte zu bestimmen, Aktivitäten wie Wartezeit gründlich zu untersuchen, die Klärung über verschiedene Ressourcen zu bestimmen, um Schulungsbedarf zu identifizieren und Beziehungen zwischen AB/SL und einer Kundenzufriedenheitswertung zu finden. Mehrere Ziele können erfolgreich zu einer regionalen Vorgabe hin geführt werden.
Ein weiterer Aspekt der vorliegenden Offenbarung besteht im Bereitstellen eines Workflows, der zeitliche Ziele unterstützt und einen flexiblen Bezugsrahmen für Prozessmetriken definiert. Insbesondere gibt es viele Aspekte bei Operationen eines Contact-Centers und es wäre vorteilhaft, nur ein System und einen Workflow-Prozess als Quelle für Ereignisse zu haben, die Befehle zur Ausführung an Controller sendet. Das vorgeschlagene System sammelt Ereignisse von Controllern und benutzt den Workflow zum Orchestrieren von Befehlen. Die Befehle benutzen mit dem Workflow verknüpfte Skripts für detaillierte Operationen.
Workflow-Knoten weisen einige Grundeigenschaften auf, die prozessbasierte Metriken festlegen, einschließlich der Anzahl der Bearbeitungen seit Start, der Anzahl der derzeit aktiven sowie Angabe der letzten Beziehung, die diese Aufgabe erledigt hat. Ein Beispiel für einen Workflow-Aufgabenknoten könnte das Kontakt-Sprach-IVR sein. Ein Beispiel für einen Entscheidungsknoten könnte der Kontostatus sein. „Besten Agenten suchen“ kann Eigenschaften wie „Anzahl bearbeitet“, „Gesamtdauer“, „Anzahl in Bearbeitung“ und „Letzte Beziehung“ aufweisen. Jedes der Workflow-Elemente kann zum Nachstellen eines Kundenerlebnisses und zum Erstellen neuer und feinabgestimmter Metriken benutzt werden.
Bei einem nicht einschränkenden Beispiel kann ein Workflow zum Zählen der Anzahl von Abbrüchen benutzt werden. Die Zählung kann Abbrüche in jeder Phase umfassen, einschließlich Kontakt-IVR, Kontostatus, besten Agenten suchen, Agentenbegrüßung usw. Wenn ein Administrator nur eine Metrik braucht, die „Besten Agenten suchen“ und „Abbrüche bei Agentenbegrüßung“ zählt, kann er das Berichten feinabstimmen, da sich alle Elemente in einem System befinden. Die Zählung von Quellereignissen für Abbrüche wird durch Betrachten des Workflows und Festlegen der Aufgaben, die für einen Abbruch in Frage kommen, definiert.
Der vorgeschlagene Workflow bietet Flexibilität, die im Gegensatz zu einem vorgegebenen Zustandsmodell in einer oder mehreren Datenbanken vollständig vom Contact-Center-Administrator definiert wird. Der Workflow liefert Struktur und die Quelle für Ereignisse statt eines starren Systems, das Code schreibt, um ein Ereignis abzurufen oder abzufragen, ob das Ereignis existiert.
Noch ein weiterer Aspekt der vorliegenden Offenbarung besteht darin, dass sie einen Mechanismus zum Integrieren unstrukturierter Daten in ein Contact-Center auf Graphbasis bereitstellt, wobei die Beziehungen beim Aufzeichnen tatsächlicher Verknüpfungen zwischen Knoten in der Graphdatenbank definiert werden. Bei dem Contact-Center auf Graphbasis ist kein vorgefertigtes oder a priori definiertes Schema erforderlich. Knoten in der Graphdatenbank werden automatisch auf der Grundlage unstrukturierter Daten erzeugt, die im Contact-Center eintreffen. Das Modell enthält grundlegende Knoten und Beziehungen, die sich erweitern, wenn neue Kategorien und Werte im Contact-Center eintreffen und zum Modell hinzugefügt werden. Attribute für Agenten und Kunden können organisiert werden und auf der Grundlage von Notizen/Rückmeldungen von Agenten, Informationen aus von Agenten verfassten Texten, Schlüsselwörtern, Markierungen und Themen können Knoten und Beziehungen erstellt werden. Diese können allesamt in Beziehungen und Knoten übersetzt werden, was umgehenden Zugriff und Effizienz bei Arbeitsaufgabenzuweisung, IVR und Berichterstellung für alle Daten ermöglicht.
Die durch die Beziehungen verbundenen Knoten sorgen für einen wesentlich höheren Vernetzungsgrad, der sich über Mustererkennung ableiten lässt, da es kein zu vergleichendes Muster gibt. Anders als ein Schema oder ein gemeinsamer strukturierter/unstrukturierter Speicher verbindet der Graph selbst die Daten miteinander. Sämtliche Daten werden in der Graphdatenbank gespeichert und sämtliche Daten können zum Ableiten von Kausalverhalten und Einflussbereich auf sehr komplexe Art und Weise abgefragt werden. Auf der Grundlage von „Gegenmustern“, die eine Abweichung vom Erwarteten verursachen, können verborgene Konzepte und Mechanismen aufgedeckt werden.
Die vorgeschlagene Lösung löst Probleme des Standes der Technik, indem sie ein System von Metriken in einem Contact-Center auf Graphbasis definiert, das über einen Graphen mit Zielen und Schwellenwerten in Beziehung gesetzt wird. Die Beziehungen sind im Modell implizit, so dass das Kommunikationssystem die Daten nicht analysieren muss, um die Beziehungen zu finden.
Andere Beziehungen, die bisher unbekannt und/oder noch nicht aufgedeckt sind, können aufgedeckt und durch Verfolgen der Datenquellenbeziehungen abgefragt werden. Der Graph kann zum Suchen unerwarteter oder verborgener Beziehungen benutzt werden, die um zwei oder mehr (sogar 10) Beziehungen vom Bekannten entfernt liegen, etwa so, als wenn die Freunde von Freunden von Freunden auf der Grundlage von Statusmeldungen auf Facebook ein Produkt kaufen.
Die Beziehung lässt sich durch Durchlaufen der Knoten und Beziehungen des Graphen aufdecken. Aus Kaufinformationen kann das Kommunikationssystem ein erwartetes Verhalten ableiten und dann das erwartete Verhalten messen, wenn sich das System ändert. Da es weiß, was sich geändert hat (zeitliche Änderung vorausgesetzt), kann das Kommunikationssystem die Beziehung der Metriken, die für die Änderungen benutzt worden sind, sowie alle Beziehungen zu den bereits gemessenen Metriken ableiten. Diese beiden Metriken können dann in dem Graph über Eigenschaften und/oder Symbolformeln (auch Eigenschaften) zueinander in Beziehung gesetzt werden.
Bei einem nicht einschränkenden Lernszenario kommen die folgenden Schritte vor:

(1) Es geht ein Anruf von Kundin Mary mit zugehörigen Attributen ein. Mary ruft an, um einen Bestellstatus zu erfragen.
(2) Eine Arbeitsaufgaben-Zuweisungsmaschine vergibt den Anruf an den Agenten Ted. Ted klärt das Problem durch Übermitteln des Status.
(3) Alle Attribute der Anruferin, des Agenten, der Konferenz und des positiven Ausgangs werden einem Lernprogramm zugeführt.
(4) Das Lernprogramm aktualisiert Regeln auf der Grundlage der Ergebnisse der Interaktion.

Der Lernprozess wird als „maschinelles Online-Lernen“ bezeichnet, wobei das Lernprogramm so ausgelegt ist, dass es aus jeweils einem Beispiel lernt. Auf der Grundlage des erfahrungsbasierten Lernens kann das Lernprogramm die Wahrscheinlichkeit eines positiven Ausgangs prognostizieren. Bei dem Beispiel besteht das Ziel für den Agenten Ted darin, das Problem zu klären. Wenn ein Arbeitsaufgabe eintrifft, kann die Arbeitsaufgaben-Zuweisungsmaschine alle möglichen Übereinstimmungen in Betracht ziehen und auf der Grundlage vorheriger Klärungen und aller Parameter und Attribute der Interaktionen eine Übereinstimmung mit der höchsten Wahrscheinlichkeit heraussuchen, dass die Konferenz einen Klärungsknoten (z. B. einen bestimmten Knotentyp in der Graphdatenbank) erreicht.
Der Begriff „automatisch“ und Variationen davon beziehen sich hier auf jeden Prozess oder jede Operation, der/die ohne wesentliche menschliche Beteiligung ausgeführt wird. Ein Prozess oder eine Operation kann jedoch automatisch sein, selbst wenn das Ausführen des Prozesses oder der Operation unter wesentlicher oder unwesentlicher menschlicher Beteiligung erfolgt, sofern diese vor dem Ausführen des Prozesses oder der Operation stattfindet. Die menschliche Beteiligung wird als wesentlich betrachtet, wenn sie die Art der Ausführung des Prozesses oder der Operation beeinflusst. Menschliche Beteiligung in Form einer Zustimmung zum Ausführen des Prozesses oder der Operation gilt nicht als „wesentliche“ Beteiligung.
Der Begriff „computerlesbares Medium“, wie er hier verwendet wird, betrifft jeden materiellen Speicher, der am Bereitstellen von ausführbaren Befehlen für einen Prozessor beteiligt ist. Ein solches Medium kann in vielerlei Form vorliegen, wie unter anderem in Form nichtflüchtiger Medien, flüchtiger Medien und Übertragungsmedien. Zu nichtflüchtigen Medien gehören beispielsweise NVRAM oder magnetische oder optische Platten. Zu flüchtigen Medien gehört dynamischer Speicher, wie Arbeitsspeicher. Zu üblichen Formen computerlesbarer Medien gehören beispielsweise Floppy-Disk, flexible Diskette, Festplatte, Magnetband oder jedes beliebige andere magnetische Medium, magnetooptisches Medium, CD-ROM, jedes beliebige andere optische Medium, Lochkarten, Papierband, jedes beliebige andere physische Medium mit Lochmustern, RAM, PROM, EPROM, FLASH-EPROM, Halbleitermedium wie Speicherkarte, jeder beliebige andere Speicherchip oder -einsatz oder jedes beliebige andere Medium, aus dem ein Computer auslesen kann. Wenn das computerlesbare Medium als Datenbank konfiguriert ist, versteht es sich, dass es sich bei dieser um eine hier beschriebene Graphdatenbank handeln kann. Dementsprechend wird davon ausgegangen, dass zur Offenbarung ein materielles Speichermedium und im Stand der Technik bekannte Äquivalente und Nachfolgemedien gehören, auf denen die Softwareimplementierungen der vorliegenden Offenbarung gespeichert sind.
Die Begriffe „bestimmen“, „kalkulieren“ und „berechnen“ sowie Variationen davon werden hier synonym verwendet und umfassen jede Art Methodologie, Prozess, mathematischer Operation oder Technik.
Der Begriff „Modul“ bezieht sich hier auf beliebige bereits bekannte oder später entwickelte Hardware, Software, Firmware, künstliche Intelligenz, unscharfe Logik oder Kombinationen von Hardware und Software, die die mit diesem Element verknüpften Funktionen ausführen können. Die Offenbarung wird zwar im Sinne von Ausführungsbeispielen beschrieben, es versteht sich jedoch, dass einzelne Aspekte davon separat beansprucht werden können.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
Die vorliegende Offenbarung wird in Verbindung mit den angehängten Figuren beschrieben:
1 ist ein Blockdiagramm eines Kommunikationssystems gemäß Ausführungsformen der vorliegenden Offenbarung,
2 ist ein Blockdiagramm, das eine Graphdatenbank gemäß Ausführungsformen der vorliegenden Offenbarung darstellt,
3 ist ein Blockdiagramm, das Komponenten einer Arbeitsaufgaben-Zuweisungsmaschine gemäß Ausführungsformen der vorliegenden Offenbarung darstellt,
4 ist ein Blockdiagramm, das einen ersten Workflow gemäß Ausführungsformen der vorliegenden Offenbarung darstellt,
5 ist ein Blockdiagramm, das einen in eine Graphdatenbank integrierten Workflow gemäß Ausführungsformen der vorliegenden Offenbarung darstellt,
6A ist ein Blockdiagramm, das eine Graphdatenbank gemäß Ausführungsformen der vorliegenden Offenbarung darstellt, bei der ein Workflow nicht abgeschlossen und die damit verknüpfte Arbeitsaufgabe nicht geklärt sind,
6B ist ein Blockdiagramm, das eine Graphdatenbank gemäß Ausführungsformen der vorliegenden Offenbarung darstellt, bei der ein Workflow abgeschlossen und das damit verknüpfte Arbeitsaufgabe geklärt sind,
7 ist ein Ablaufdiagramm, das ein Verfahren zum Melden von Ursachen für Abbrüche gemäß Ausführungsformen der vorliegenden Offenbarung darstellt,
8 ist ein Ablaufdiagramm, das ein Verfahren zum Melden von Ursachen für die durchschnittliche Antwortzeit gemäß Ausführungsformen der vorliegenden Offenbarung darstellt,
9 ist ein Ablaufdiagramm, das ein Verfahren zum Melden von Ursachen für den Service-Level gemäß Ausführungsformen der vorliegenden Offenbarung darstellt,
10 ist ein Blockdiagramm, das eine Mehrfachkontakt-Arbeitsaufgabe in einer Graphdatenbank gemäß Ausführungsformen der vorliegenden Offenbarung darstellt,
11 ist ein Ablaufdiagramm, das ein Verfahren zum Optimieren von Zielen gemäß Ausführungsformen der vorliegenden Offenbarung darstellt,
12 ist ein Blockdiagramm, das einen Attributbaum gemäß Ausführungsformen der vorliegenden Offenbarung darstellt,
13 ist ein Ablaufdiagramm, das ein erstes Arbeitsaufgaben-Zuweisungsverfahren gemäß Ausführungsformen der vorliegenden Offenbarung darstellt,
14A ist ein Ablaufdiagramm, das ein zweites Arbeitsaufgaben-Zuweisungsverfahren gemäß Ausführungsformen der vorliegenden Offenbarung darstellt,
14B ist eine Benutzerschnittstelle, die den Status mehrerer Zielstellungen gemäß Ausführungsformen der vorliegenden Offenbarung darstellt,
15A ist ein Blockdiagramm, das ein Verfahren zum Durchlaufen eines Attributbaums in Verbindung mit dem Fällen einer Arbeitsaufgaben-Zuweisungsentscheidung gemäß Ausführungsformen der vorliegenden Offenbarung zeigt,
15B ist ein Blockdiagramm, das die jeweilige Beziehung eines Agenten zu einem Attributbaum gemäß Ausführungsformen der vorliegenden Offenbarung darstellt,
16A ist eine erste Graphdarstellung mehrerer Kontakte und Arbeitsaufgaben in einem Contact-Center gemäß Ausführungsformen der vorliegenden Offenbarung, und
16B ist eine zweite Graphdarstellung mehrerer Kontakte und Arbeitsaufgaben in einem Contact-Center gemäß Ausführungsformen der vorliegenden Offenbarung.
AUSFÜHRLICHE BESCHREIBUNG
Die nachfolgende Beschreibung stellt nur Ausführungsformen bereit und soll den Schutzumfang, den Geltungsbereich oder die Konfiguration der Ansprüche nicht einschränken. Sie liefert stattdessen eine Beschreibung, die Fachleute in die Lage versetzt, die Ausführungsformen zu implementieren. Dabei versteht es sich, dass an Funktion und Anordnung von Elementen verschiedene Änderungen vorgenommen werden können, ohne vom Gedanken und Schutzumfang der angehängten Ansprüche abzuweichen.
1 zeigt ein Ausführungsbeispiel für ein Kommunikationssystem 100 gemäß zumindest einigen Ausführungsformen der vorliegenden Offenbarung. Bei dem Kommunikationssystem 100 kann es sich um ein verteiltes System handeln und es umfasst bei manchen Ausführungsformen ein Kommunikationsnetzwerk 104, das Komponenten eines Contact-Centers 102 mit einem oder mehreren Kundenkommunikationsgeräten 108 verbindet.
Gemäß zumindest einigen Ausführungsformen der vorliegenden Offenbarung kann das Kommunikationsnetzwerk 104 ein bekanntes Kommunikationsmedium oder eine Ansammlung von Kommunikationsmedien beliebigen Typs umfassen und beliebige Protokolltypen zum Befördern von Nachrichten zwischen Endpunkten benutzen. Das Kommunikationsnetzwerk 104 kann drahtgebundene und/oder drahtlose Kommunikationstechnologien umfassen. Das Internet ist ein Beispiel für das Kommunikationsnetzwerk 104, das ein IP-Netzwerk (Internet Protocol) bildet, welches aus vielen Computern, Computernetzwerken und anderen Kommunikationsgeräten auf der ganzen Welt besteht, welche über zahlreiche Telefonsysteme und andere Mittel verbunden sind. Zu anderen Beispielen für das Kommunikationsnetzwerk 104 zählen u. a. ein normales analoges Telefonsystem (POTS – Plain Old Telephone System), ein Integrated Services Digital Network (ISDN), das öffentliche Telefonnetz (PSTN – Public Switched Telephone Network), ein lokales Netzwerk (LAN – Local Area Network), ein Weitverkehrsnetz (WAN – Wide Area Network), ein SIP-Netzwerk (Session Initiation Protocol), ein VoIP-Netzwerk (Voice over IP), ein Mobilfunknetz und jeder andere in der Technik bekannte Typ paket- oder leitungsvermittelter Netzwerke. Außerdem versteht es sich, dass das Kommunikationsnetzwerk 104 nicht auf einen Netzwerktyp beschränkt sein muss und stattdessen aus einer Anzahl verschiedener Netzwerke und/oder Netzwerktypen bestehen kann. Ausführungsformen der vorliegenden Offenbarung können beispielsweise zum Erhöhen der Effizienz eines versorgungsnetzbasierten (engl.: grid-based) Contact-Centers genutzt werden. Beispiele für ein solches versorgungsnetzbasiertes Contact-Center sind in US-Patentanmeldung Nr. 12/469,523 von Steiner ausführlicher beschrieben, deren gesamter Inhalt durch Verweis darauf als hier mit aufgenommen gilt. Darüber hinaus kann das Kommunikationsnetzwerk 104 eine Anzahl unterschiedlicher Kommunikationsmedien wie Koaxialkabel, Kupferkabel/-draht, Glasfaserkabel, Antennen zum Übertragen/Empfangen von Funknachrichten und Kombinationen davon umfassen.
Die Kommunikationsgeräte 108 können Kundenkommunikationsgeräten entsprechen. Gemäß zumindest einigen Ausführungsformen der vorliegenden Offenbarung kann ein Kunde sein Kommunikationsgerät 108 zum Auslösen einer Arbeitsaufgabe benutzen, wobei es sich allgemein um eine Anforderung einer Bearbeitungsressource 112 handelt. Zu beispielhaften Arbeitsaufgaben gehören u. a. ein Kontakt, der zu einem Contact-Center weitergeleitet wird und dort eingeht, eine Webseitenanforderung, die zu einer Serverfarm (z. B. einer Ansammlung von Servern) weitergeleitet wird und dort eingeht, eine Medienanforderung, eine Anwendungsanforderung (z. B. eine Anforderung von Anwendungsressourcen auf einem ausgelagerten Anwendungsserver, wie einem SIP-Anwendungsserver) und dergleichen. Die Arbeitsaufgabe kann in Form einer Nachricht oder einer Ansammlung von Nachrichten vorliegen, die über das Kommunikationsnetzwerk 104 übertragen wird. Die Arbeitsaufgabe kann beispielsweise als Telefonanruf, Paket oder Ansammlung von Paketen (z. B. über ein IP-Netzwerk übertragene IP-Pakete), E-Mail-Nachricht, Sofortnachricht, SMS-Nachricht, Fax und Kombinationen daraus übertragen werden. Bei manchen Ausführungsformen kann es sein, dass die Kommunikation nicht unbedingt an den Aufgabenzuweisungsmechanismus 116 gerichtet ist, sondern sich auf einem anderen Server im Kommunikationsnetzwerk 104 befindet, wo sie vom Arbeitsaufgaben-Zuweisungsmechanismus 116 eingesammelt wird, der eine Arbeitsaufgabe für die eingesammelte Kommunikation generiert. Ein Beispiel für derartige eingesammelte Kommunikation ist eine Social-Media-Kommunikation, die von dem Aufgabenzuweisungsmechanismus 116 in einem Social-Media-Netzwerk oder Server eingesammelt wird. Beispielhafte Architekturen für das Einsammeln von Social-Media-Kommunikation und das darauf beruhende Generieren von Arbeitsaufgaben sind in den US-Patentanmeldungen Nr. 12/784,369, 12/706,942 und 12/707,277 beschrieben, die am 20. März 2010, am 17. Februar 2010 bzw. am 17. Februar 2010 eingereicht wurden und deren gesamter Inhalt als durch Verweis darauf hier mit aufgenommen gilt.
Das Format der Arbeitsaufgabe kann von den Fähigkeiten des Kommunikationsgeräts 108 und dem Format der Kommunikation abhängen. Arbeitsaufgaben sind insbesondere logische Repräsentationen von Arbeitsaufgaben in einem Contact-Center, die in Verbindung mit dem Bedienen einer Kommunikation ausgeführt werden müssen, die im Contact-Center (und insbesondere Aufgabenzuweisungsmechanismus 116) eingegangen ist. Die Kommunikation kann bei dem Aufgabenzuweisungsmechanismus 116, einem mit dem Aufgabenzuweisungsmechanismus 116 verbundenen Switch oder Server oder dergleichen eingehen und verwaltet werden, bis der Arbeitsaufgabe, die diese Kommunikation repräsentiert, eine Ressource 112 zugewiesen wird, wobei der Aufgabenzuweisungsmechanismus 116 an diesem Punkt die Arbeitsaufgabe an eine Routing-Engine 128 übergibt, damit das Kommunikationsgerät 108, das die Kommunikation ausgelöst hat, mit der zugewiesenen Ressource 112 verbunden wird.
Die Routing-Engine 128 ist zwar separat zum Aufgabenzuweisungsmechanismus 116 dargestellt, kann aber in diesen integriert sein, oder ihre Funktionen können von der Arbeitsaufgaben-Zuweisungsmaschine 120 ausgeführt werden.
Gemäß zumindest einigen Ausführungsformen der vorliegenden Offenbarung können die Kommunikationsgeräte 108 jede Art bekannter Kommunikationsausrüstung oder eine Ansammlung von Kommunikationsausrüstungen beliebigen Typs umfassen. Zu Beispielen für ein geeignetes Kommunikationsgerät 108 gehören u.a. Personalcomputer, Laptop, persönlicher Assistent (PDA), Mobiltelefon, Smartphone, Telefon oder Kombinationen davon. Im Allgemeinen kann jedes Kommunikationsgerät 108 zum Unterstützen von Video-, Audio-, Text- und/oder Datenkommunikation mit anderen Kommunikationsgeräten 108 sowie den Bearbeitungsressourcen 112 angepasst werden. Der vom Kommunikationsgerät 108 für das Kommunizieren mit anderen Kommunikationsgeräten 108 oder Bearbeitungsressourcen 112 verwendete Medientyp kann von den auf dem Kommunikationsgerät 108 verfügbaren Kommunikationsanwendungen abhängig sein.
Gemäß zumindest einigen Ausführungsformen der vorliegenden Offenbarung wird die Arbeitsaufgabe durch Zusammenwirken des Aufgabenzuweisungsmechanismus 116 und der Routing-Engine 128 zu einer Ansammlung von Bearbeitungsressourcen 112 gesendet. Bei den Ressourcen 112 kann es sich entweder um vollautomatisierte Ressourcen (z. B. Prozessoren, Server oder dergleichen), menschliche Ressourcen, die Kommunikationsgeräte benutzen (z. B. menschliche Agenten, die einen Computer, ein Telefon, einen Laptop usw. benutzen), oder beliebige andere Ressourcen handeln, die bekanntlich in Contact-Centern verwendet werden. Bei anderen Ausführungsformen kann der Aufgabenzuweisungsmechanismus 116 eine Arbeitsaufgabe vor oder gleichzeitig mit der Zuweisung an eine menschliche Ressource 112 (z. B. Contact-Center-Agent) einem IVR 144, einem Sprachportal 140 oder einer anderen Komponente des Contact-Centers 102 zuweisen. Wie hier noch ausführlich erläutert wird, können die Komponenten des Contact-Centers 102 so konfiguriert sein, dass sie zusammen so funktionieren, dass eine Arbeitsaufgabe geklärt wird, und vom Aufgabenzuweisungsmechanismus 116 kann ein Workflow implementiert werden, der sicherstellt, dass diese Klärung zur Zufriedenheit des Kunden erfolgt.
Bei manchen Ausführungsformen können die Komponenten des Contact-Centers 102 zu einer gemeinsamen Entität gehören und von dieser betrieben werden. Bei manchen Ausführungsformen kann jede Komponente des Contact-Centers 102 von einer einzelnen Entität geführt werden, bei anderen Ausführungsformen können jedoch verschiedene Komponenten des Contact-Centers 102 von verschiedenen Entitäten geführt werden. Zum Beispiel können manche Ressourcen 102 von der Entität verwaltet werden, die den Aufgabenzuweisungsmechanismus 116 verwaltet (z. B. interne Ressourcen 112), und andere Ressourcen 112 können von anderen Entitäten als derjenigen verwaltet werden, die den Aufgabenzuweisungsmechanismus 116 verwaltet (z. B. externe Ressourcen). Die Nutzung externer Ressourcen 112 kann zu Zeiten eines Arbeitsaufgabenüberschusses sinnvoll sein, wenn das Arbeitsaufgabenvolumen für die internen Ressourcen 112 so groß ist, dass sie die Arbeitsaufgaben nicht ordnungsgemäß bearbeiten können.
Bei manchen Ausführungsformen umfasst der Aufgabenzuweisungsmechanismus 116 eine Aufgabenzuweisungsmaschine 120, die es dem Aufgabenzuweisungsmechanismus 116 ermöglicht, intelligente Routing-Entscheidungen für Arbeitsaufgaben zu fällen. Bei manchen Ausführungsformen ist die Aufgabenzuweisungsmaschine 120 so konfiguriert, dass sie Aufgabenzuweisungsentscheidungen in einem warteschlangenfreien Contact-Center fällt und verwaltet, wie es in der US-Patentanmeldung mit der lfd. Nr. 12/882,950 beschrieben ist, deren gesamter Inhalt durch Verweis darauf als hier mit aufgenommen gilt. Bei anderen Ausführungsformen kann die Aufgabenzuweisungsmaschine 120 so konfiguriert sein, dass sie Aufgabenzuweisungsentscheidungen in einem herkömmlichen, warteschlangenbasierten (oder kompetenzbasierten) Contact-Center ausführt.
Insbesondere kann die Aufgabenzuweisungsmaschine 120 bestimmen, welche der mehreren Bearbeitungsressourcen 112 qualifiziert und/oder geeignet ist, das Arbeitsaufgabe entgegenzunehmen, und ferner bestimmen, welche der mehreren Bearbeitungsressourcen 112 am besten dazu geeignet ist, den Bearbeitungsbedarf für das Arbeitsaufgabe zu übernehmen. Falls ein Arbeitsaufgabeüberschuss besteht, kann die Aufgabenzuweisungsmaschine 120 auch Gegenteiliges (d. h. die optimale Zuweisung einer Arbeitsaufgabe an eine Ressource) bestimmen. Bei manchen Ausführungsformen ist die Aufgabenzuweisungsmaschine 120 so konfiguriert, dass sie eine echte Eins-zu-Eins-Übereinstimmung erzielt, indem sie Bitmaps/Tabellen und andere Datenstrukturen nutzt.
Zu zusätzlichen gezeigten Komponenten des Contact-Centers 102 gehören ein Randelement 124, ein Personaleinsatzplanungsmodul (PEP-Modul) 132, ein Berichtsmodul 136, ein Sprachportal 140, ein IVR 144, ein CRM-Modul (CRM – Customer Relationship Management, dt. Kundenpflege) 148, ein Aufgabenprognosemodul 152 und eine Graphdatenbank 160. Jede der dargestellten Komponenten kann innerhalb des Contact-Centers 102 über ein internes Netzwerk 156 mit den anderen verbunden sein. Bei manchen Ausführungsformen kann das interne Netzwerk 156 einem geschützten LAN oder WAN entsprechen, dessen Sicherheit von einem Administrator des Contact-Centers 102 aufrechterhalten wird. Obwohl die einzelnen Komponenten des Contact-Centers 102 so dargestellt sind, als wären sie gebündelt, versteht es sich jedoch, dass eine solche Komponentenkonfiguration nicht erforderlich ist. Im Gegensatz können einige der Komponenten des Contact-Centers 102 verteilt und über das Kommunikationsnetzwerk 104 miteinander verbunden sein, aber die Kommunikation zwischen solchen Komponenten kann mit Tunnelprotokollen oder einem VPN (Virtual Private Network) gesichert werden.
Das Randelement 124 ist bei manchen Ausführungsformen so ausgelegt, dass es eine sichere Trennung zwischen dem ungeschützten und nicht vertrauenswürdigen Kommunikationsnetzwerk 104 und dem internen Netzwerk 156 aufrechterhält. Zu Beispielen für das Randelement 124 gehören u. a. ein Session Border Controller (SBC), eine Firewall, ein Gateway, ein Router oder dergleichen. Das Randelement 124 kann Logik umfassen, die eine Kommunikation zwischen den Netzwerken 104, 156 ermöglicht, selbst wenn die Netzwerke 104, 156 eventuell unterschiedliche Kommunikationsprotokolle benutzen. Darüber hinaus kann das Randelement 124 Sicherheitsmerkmale umfassen, die nicht vertrauenswürdige oder unerwünschte Kommunikationsversuche aus dem Kommunikationsnetzwerk 104 blockieren und dadurch Sicherheitsverstöße im internen Netzwerk 156 verhindern.
Das PEP-Modul 132 kann so konfiguriert sein, dass es den Personaleinsatz des Contact-Centers 102 (also die Arbeitskräfte 112) verwaltet. Das PEP-Modul 132 kann Funktionen umfassen, die das aktuelle Arbeitsaufgabenvolumen, die aktuelle Ressourcenverfügbarkeit/-auslastung, das bisherige Arbeitsaufgabenvolumen, die bisherige Ressourcenverfügbarkeit/-auslastung, geschätzte Wartezeiten, Service-Levels und andere Zielstellungen überwacht, um zu bestimmen, ob das Contact-Center 102 gemäß einer oder mehreren vorgegebenen Zielstellungen arbeitet. Das PEP-Modul 132 kann auch so konfiguriert sein, dass es auf der Grundlage seiner Überwachungsaktivität den Personaleinsatz anpasst oder Anpassungen dafür vorschlägt. Das PEP-Modul 132 kann auch so konfiguriert sein, dass es Service Level Agreements (SLA – Dienstleistungsvereinbarungen) zwischen dem Contact-Center 102 und Anbietern externer Ressourcen 112 überwacht, um sicherzustellen, dass die SLA eingehalten werden. Das PEP-Modul 132 kann ferner so konfiguriert sein, dass es die Einhaltung von Zeitplanung, Social-Media-Aktivität und dergleichen überwacht, und es kann das Ausschreiben von Schichten, Zeitplananpassungen, das Umdisponieren von von zu Hause aus arbeitenden Agenten und dergleichen ermöglichen. Im Grunde kann jeder Aspekt der Ressourcenverwaltung vom PEP-Modul 132 übernommen oder für einen Contact-Center-Administrator oder -Manager zwecks Ausführung verfügbar gemacht werden.
Das Berichtsmodul 136 kann zum Generieren eines oder mehrerer Berichte benutzt werden, die die Leistung des Contact-Centers 102 angeben. Bei manchen Ausführungsformen kann das Berichtsmodul 136 so konfiguriert sein, dass es Daten aus der Graphdatenbank 160 abruft und diese Daten in einem für den Menschen lesbaren Format aufbereitet. Das Berichtsmodul 136 kann vorteilhafterweise so konfiguriert sein, dass es in vorgegebenen Intervallen automatisch einen oder mehrere Berichte für vorgegebene Daten ausführt. Das Berichtsmodul 136 kann auch in der Lage sein, auf der Grundlage von Eingaben eines Contact-Center-Administrators oder -Managers kurzfristig Berichte zu erstellen. Darüber hinaus kann das Berichtsmodul 136 so konfiguriert sein, dass es als Reaktion auf ein vorgegebenes Ereignis oder eine vorgegebene Reihe von Ereignissen im Contact-Center 102 Berichte erstellt. Wie nachfolgend ausführlich beschrieben, stehen dem Berichtsmodul 136 dank des Einsatzes einer Graphdatenbank 160 im Contact-Center 102 wesentlich reichhaltigere Informationen zur Verfügung als bei bisherigen Contact-Center-Architekturen. Die Graphdatenbank 160 kann so konfiguriert sein, dass sie Informationen über beliebige oder alle Komponenten des Contact-Centers 102 und somit viele, beliebige oder alle Informationen speichert, die dem Berichtsmodul 136 zur Verfügung stehen. Da die in der Graphdatenbank 160 verwalteten Informationen nicht eingeschränkt oder auf eine vorgegebene Weise strukturiert sind, kann das Berichtsmodul 136 darüber hinaus so konfiguriert sein, dass es Berichte erstellt, die Beziehungen zwischen verschiedenen Komponenten des Contact-Centers 102 aufzeigen. Als nicht einschränkendes Beispiel kann das Berichtsmodul 136 so konfiguriert sein, dass es einen Bericht erstellt, der gleichzeitig PEP-Statistiken (z. B. Ressourcennutzung, Einhaltung von SLA-Vereinbarungen, Einhaltung von Zielstellungen usw.) mit Agentenleistungsstatistiken (z. B. Leistungskennzahlen (KPI – Key Performance Indicators)) und Aufgabenzuweisungsmaschinen-Leistungsstatistiken (z. B. Entscheidungen pro Zeitraum, erfolgreiche Routing-Entscheidungen, geschätzte Wartezeit usw.) zeigt.
Das Sprachportal 140 und/oder das IVR 144 kann so konfiguriert sein, dass es Mediendienste und/oder automatische Kundendienstbearbeitung zu Arbeitsaufgaben im Contact-Center bereitstellt. Bei manchen Ausführungsformen kann das Sprachportal 140 den zum Erfüllen von IVR-Funktionen erforderlichen Medienteil bereitstellen, während das IVR 144 die Logik für die Interaktion mit einem Kunden bereitstellt. Anders ausgedrückt, können das IVR 144 und das Sprachportal 140 in Kombination IVR-Dienste für Kunden zur Verfügung stellen. Das IVR 144 kann das Sprachportal 140 in Übereinstimmung mit in dem IVR 144 enthaltener Logik steuern oder betreiben.
Das CRM-Modul 148 kann so konfiguriert sein, dass es Kundenbestandsdaten, aktuelle Kundendaten, Informationen zu Interaktionen zwischen einem Kunden und einem Contact-Center 102, Kundenpräferenzen, bisherige Kundenkäufe, bisherige Kundenretouren, Kundenpseudonyme (z. B. in Social-Media-Netzwerken) und dergleichen verwaltet. Derartige Informationen können in der Graphdatenbank 160 gespeichert und verwaltet werden. Das CRM-Modul 148 kann das Contact-Center 102 dabei unterstützen, ein robusteres und persönlicher gestaltetes Kundendiensterlebnis anzubieten. Bei manchen Ausführungsformen kann das CRM-Modul 148 auch gewünschte CRM-Daten aus der Graphdatenbank 160 abrufen, damit eine Ressource 112 eine Arbeitsaufgabe für einen Bestandskunden oder bekannten Kunden effizienter bearbeiten kann. Wenn beispielsweise eine Arbeitsaufgabe in einem Contact-Center 102 eingeht und mit einem Kunden verknüpft ist, für den Bestandsdaten als CRM-Daten in der Graphdatenbank 160 gespeichert sind, kann das CRM-Modul 148 alle diese CRM-Daten oder einen Teil davon abrufen und die abgerufenen Daten einer Ressource 112 zur Verfügung stellen, so dass diese dem Kunden einen persönlicher gestalteten Dienst anbieten kann.
Das Prognosemodul 152 kann mit dem PEP-Modul 132 zusammenarbeiten. Das PEP-Modul 132 kann insbesondere versuchen, Ressourcen 112 für zukünftige Schichten im Contact-Center 102 einzuplanen, und das Prognosemodul 152 kann zur Unterstützung bei der Prognose des Arbeitsaufgabenvolumens im Contact-Center für den gewünschten Schichtzeitraum genutzt werden. Zusätzlich dazu kann das Prognosemodul 152 zum automatischen Identifizieren zukünftiger Probleme bei der Ressourcenverfügbarkeit (kurz- oder langfristig) und zum Benachrichtigen des PEP 132 dienen, so dass das PEP 132 je nach Bedarf mehr oder weniger Ressourcen 112 einplanen kann. Bei manchen Ausführungsformen ist das Prognosemodul 152 zusätzlich zum Überwachen des aktuellen Volumens in der Lage, bisherige Contact-Center-Leistung und bisheriges Kontaktvolumen zu analysieren, um zu bestimmen, ob das Contact-Center zu einem gegebenen Zeitpunkt mehr oder weniger Ressourcen 112 benötigt.
Die Graphdatenbank 160 kann einem oder vielen Datenbanksystemen entsprechen, die Daten in Bezug auf das Contact-Center 102 in einem graphbasierten Format verwalten. Im Gegensatz zu herkömmlichen hierarchischen Datenbanken handelt es sich bei der Graphdatenbank 160 um eine Datenbank, die Graphstrukturen mit Knoten, Kanten und Eigenschaften zum Darstellen und Speichern von Daten benutzt. Eine Graphdatenbank 160 kann einem beliebigen Speichersystem entsprechen, das indexfreie Adjazenz bietet, was bedeutet, dass jedes Element in der Graphdatenbank 160 einen direkten Zeiger auf seine benachbarten Elemente enthält und kein Nachschlagen im Index erforderlich ist. Allgemeine Graphdatenbanken, die jeden beliebigen Graphen speichern können, unterscheiden sich von Spezialgraphdatenbanken wie Triplestores und Netzwerkdatenbanken. Es versteht sich, dass ein beliebiger, bereits bekannter oder noch zu entwickelnder Graphdatenbanktyp als Graphdatenbank 160 benutzt werden kann.
Verglichen mit relationalen Datenbanken ist die Graphdatenbank 160 bei assoziativen Datensätzen schneller und bildet direkter auf der Struktur objektorientierter Anwendungen ab. Die Graphdatenbank 160 lässt sich auf natürlichere Weise auf große Datensätze skalieren, da sie in der Regel keine aufwändigen Verknüpfungsoperationen erfordert. Da die Graphdatenbank 160 in geringerem Maße von einem starren Schema abhängig ist, eignet sie sich eher für Ad-hoc- und veränderliche Daten mit sich entwickelnden Schemata. Wie hier noch erläutert wird, ist die Graphdatenbank 160 leistungsfähig, da sie zum Abarbeiten von graphartigen Abfragen wie beispielsweise zum Berechnen des kürzesten Wegs zwischen zwei Knoten im Graph benutzt werden kann, was für das PEP-Modul 132, das Berichtsmodul 136, das Prognosemodul 152 und dergleichen sehr nützlich sein kann. Andere graphartige Abfragen können auf natürliche Weise über eine Graphdatenbank ausgeführt werden (beispielsweise Berechnungen des Graphdurchmessers oder Community Detection).
Es werden nun unter Bezugnahme auf 2 weitere Einzelheiten zu einer in einem Contact-Center 102 benutzten Graphdatenbank 160 gemäß zumindest einigen Ausführungsformen der vorliegenden Offenbarung beschrieben. Die Graphdatenbank 160 kann über eine Datenbankschnittstelle 204 mit dem Contact-Center-Netzwerk 208 (z. B. dem internen Netzwerk 156) verbunden sein. Die Datenbankschnittstelle 204 kann den Mechanismus bereitstellen, nach dem verschiedene Komponenten des Contact-Centers 102 Daten in die Graphdatenbank 160 schreiben beziehungsweise aus dieser abrufen. Bei manchen Ausführungsformen kann die Datenbankschnittstelle 204 die Befehle zum Abrufen von Daten aus der Graphdatenbank 160 sowie zum Schreiben von Daten in die Graphdatenbank 160 definieren.
Bei manchen Ausführungsformen kann die Graphdatenbank 160 eine Vielzahl von Datenelementen (z. B. Dateninstanzen) in Form von Knoten und Beziehungen für die Ereignisse, Aktivitäten, Entitäten, das Personal und Komponenten des Contact-Centers 102 umfassen. Die Graphdatenbank 160 kann insbesondere eine Knotentypdefinition 212, ein Knotenwörterbuch 216 und Knoteneigenschaften 220 umfassen. Die Graphdatenbank 160 kann gleichermaßen eine Beziehungstypdefinition 224, ein Beziehungswörterbuch 228 und Beziehungseigenschaften 232 umfassen. Die Knotentypdefinition 212 kann Informationen umfassen, die Knoten in der Graphdatenbank 160 definieren, während die Beziehungstypdefinition 224 Informationen umfassen kann, die die Beziehungen zwischen Knoten in der Graphdatenbank 160 definieren. Zu Beispielen für Datenelemente, die in der Graphdatenbank 160 als Knoten dargestellt werden können (der z. B. ein definierter Knotentyp 212 sein kann), können u. a. Ressourcen (z. B. Personal, Maschinen, Rechner, Ausrüstung usw.), Ressourcengruppen, Arbeitsaufgaben, Kundenkontakte (die mit Arbeitsaufgaben verknüpft sind), Konferenzen, Klärung, Workflow-Aktionen, Berichtsaktionen, PEP-Aktionen, Arbeitsaufgaben-Prognoseereignisse, Routing-Ereignisse, Ressourcen- und/oder Arbeitsaufgabenattribute (z. B. in Form eines Attributbaums) usw. gehören. Das Knotenwörterbuch 216 kann eine Beschreibung und/oder Definition jedes Knotens in der Graphdatenbank 160 umfassen. Wenn das Contact-Center 102 beispielsweise Knoten für Ressourcen, Arbeitsaufgaben, Kundenkontakte, Konferenzen und Problemklärung umfasst, dann kann das Knotenwörterbuch 216 diese Knoten identifizieren und ferner Informationen zum Definieren dieser Knoten innerhalb der Graphdatenbank 160 bereitstellen.
Die Knoteneigenschaften 220 können ferner die Eigenschaften definieren, die zu einem Knoten in der Graphdatenbank 160 gehören können. Als nicht einschränkendes Beispiel können zu den Eigenschaften eines Ressourcenknotens der Ressourcenname, die Ressourcenkennung (falls sie sich vom Namen unterscheidet), das Datum der Knotenerstellung, das Datum der Knotenmodifikation usw. gehören.
Ähnlich wie die Knoten können die Beziehungen ein weiteres Datenelement in der Graphdatenbank 160 sein und sie können einen definierten Beziehungstyp aufweisen, der die Art der Beziehung zwischen zwei Knoten definiert, und ein Beziehungswörterbuch 228 kann eine Liste aller Beziehungen sowie Informationen in der Graphdatenbank 160 verwalten, die diese Beziehungen (im Vergleich zu anderen Beziehungen) definieren. Der Beziehungstyp kann von den durch diese Beziehung verbundenen Knoten abhängig sein. Zum Beispiel kann eine Beziehung zwischen einem Ressourcenknoten und einem Konferenzknoten den Entstehungszeitpunkt der Beziehung, eine Dauer der Beziehung und einen Wert, der die Beziehung zwischen der Ressource und dem Konferenzknoten beschreibt (z. B. Aufgabenzuweisungsentscheidung, Routing usw.), identifizieren. Die Beziehungseigenschaften 2323 können die für jede der Beziehungen in der Graphdatenbank 160 zur Verfügung stehenden Eigenschaften auf ähnliche Weise definieren, wie die Knoteneigenschaften 220 die für Knoten in der Graphdatenbank 160 zur Verfügung stehenden Eigenschaften definieren. Es versteht sich, dass sich die Beziehungseigenschaften 232 und/oder die Knoteneigenschaften 220 dynamisch ändern können, während das Contact-Center 102 weiterarbeitet, und neue Beziehungen zwischen Knoten benötigt werden und/oder entstehen. Die Knotentypen 212 können auf ähnliche Weise dynamisch modifiziert (z. B. erstellt, geändert, gelöscht, zusammengelegt usw.) werden, während ein automatisiertes System (z. B. auf der Grundlage der Auslastung, Überlastung oder Unterauslastung von Knoten/Beziehungen im Contact-Center 102) die Notwendigkeit einer Modifikation solcher Knoten im Contact-Center 102 identifiziert.
Es werden nun unter Bezugnahme auf 3 weitere Einzelheiten zu einer Aufgabenzuweisungsmaschine 120 gemäß zumindest einigen Ausführungsformen der vorliegenden Offenbarung beschrieben. Die Aufgabenzuweisungsmaschine 120 kann Vermittlungslogik 304 umfassen, die Arbeitsaufgaben aus einem Aufgabenpool 312 mit Ressourcen aus einem Ressourcenpool 308 abgleicht. Bei manchen Ausführungsformen kann die Aufgabenzuweisungsmaschine 120 Daten aus der Graphdatenbank 160 berücksichtigen, wenn sie intelligente Aufgabenzuweisungsentscheidungen fällt. Die Aufgabenzuweisungsmaschine 120 kann auch Knoten und/oder Beziehungen in der Graphdatenbank 160 aktualisieren, wenn Aufgabenzuweisungsentscheidungen gefällt werden, damit erkennbar ist, dass eine bestimmte Arbeitsaufgabe (oder eine Gruppe von Arbeitsaufgaben) an eine bestimmte Ressource (oder Gruppe von Ressourcen) vergeben worden ist. Bei manchen Ausführungsformen kann die Aufgabenzuweisungsentscheidung in der Graphdatenbank 160 als direkte oder indirekte Beziehung zwischen einem Ressourcenknoten und einem Arbeitsaufgabenknoten referenziert sein. Im Sinne eines nicht einschränkenden Beispiels kann der Arbeitsaufgabenknoten zunächst mit einem Konferenzknoten verbunden sein, wenn die Arbeitsaufgabe in dem Contact-Center erstellt wird. Wenn die Ressource der Arbeitsaufgabe zugewiesen ist, kann der Ressourcenknoten, der der zugewiesenen Ressource entspricht, mit dem gleichen Konferenzknoten verbunden werden, mit dem die Arbeitsaufgabe verbunden ist, was eine Zuweisung der Ressource zu der Arbeitsaufgabe angibt. Die Beziehung zwischen der Ressource und dem Konferenzknoten kann angeben, wann die Beziehung entstanden ist (z. B. wann die Aufgabenzuweisungsentscheidung gefällt wurde), sowie wie lange die Beziehung bestanden hat (z. B. wie lange die Ressource für die Bearbeitung der Arbeitsaufgabe benötigt hat). Diese Informationen können dann in der Graphdatenbank 160 so aufbewahrt werden, dass sie für das PEP-Modul 132 und/oder das Berichtsmodul 136 bereitstehen.
Es werden nun unter Bezugnahme auf die 4 bis 6B Beispiele für Workflows und andere Datenstrukturen in der Graphdatenbank 160 gemäß zumindest einigen Ausführungsformen der vorliegenden Offenbarung beschrieben. Es wird zunächst auf 4 Bezug genommen, in der ein beispielhafter Workflow 400 abgebildet ist, welcher mehrere Knoten 404, 408, 412, 416, 420 enthält, die jeweils über eine Beziehung direkt oder indirekt miteinander verbunden sind. Der gezeigte Workflow 400 enthält insbesondere einen Startknoten 404, einen Workflow-Aufgabenknoten 408, einen Entscheidungsknoten 412, einen Entscheidungsausführungsknoten 416 und einen Ergebnisknoten 420. Der Startknoten 404 gibt einen Start des Workflows 400 an. Zu den Eigenschaften des Startknotens kann gehören, wann der Workflow 400 ausgelöst/erstellt wurde sowie wann andere Knoten in der Graphdatenbank 160 mit dem Workflow 400 verbunden wurden.
Der Aufgabenknoten 408 kann eine erste Aufgabe für den Workflow 400 angeben. Bei dem abgebildeten Beispiel entspricht die erste Aufgabe einer IVR-Aufgabe, bei der ein Kunde/ein Kontakt mit dem IVR 144 und/oder dem Sprachportal 140 verbunden ist. Nach Erledigung der IVR-Aufgabe fährt der Workflow 400 mit einem Entscheidungsknoten 412 fort, bei dem bestimmt wird, ob der Kunde Kontodaten (z. B. Bankkontodaten) haben möchte. Es sei angemerkt, dass das Erstellen des Entscheidungsknotens erst nach Abschluss der IVR-Aufgabe erfolgen kann – das heißt, die Bestimmung, dass der Kunde Kontodaten haben möchte, kann von den Interaktionen des Kunden mit dem IVR abhängig sein. Dementsprechend versteht es sich, dass das Erstellen von Knoten im Workflow 400 dynamisch erfolgen und auf Eingaben des Kunden und/oder der Ressource beruhen kann, die über die Dauer der Arbeitsaufgabe im Contact-Center erfolgen können (z. B. bis die Arbeitsaufgabe vollständig geklärt ist).
Sobald feststeht, dass ein Kontostatus gewünscht wird, fährt der Workflow 400 am Entscheidungsausführungsknoten 416 fort. Im dargestellten Beispiel kann der Entscheidungsausführungsknoten 416 einem Knoten entsprechen, an dem die Aufgabenzuweisungsmaschine 120 einen Aufgabenzuweisungsprozess beginnt und versucht, dem eingehenden Kontakt entsprechend einer Arbeitsaufgabe eine Ressource 112 zuzuweisen. Zu Eigenschaften des Entscheidungsausführungsknotens 416 kann gehören, wie oft die Aufgabenzuweisungsentscheidung gezählt worden ist, wie lange der Prozess bis zum Abschluss gedauert hat, ob derzeit eine Zählung durchgeführt wird, und andere Informationen, die die letzte(n) Beziehung(en) zwischen dem Entscheidungsausführungsknoten 416 und anderen Knoten (z. B. letzte Startzeit, letzte Dauer, letzte Endzeit usw.) identifizieren.
Wenn der Workflow 400 abgeschlossen und eine Aufgabenzuweisungsentscheidung gefällt ist, kann der Workflow 400 auch einen Ergebnisknoten 420 umfassen. Aus dem Ergebnisknoten 420 kann ein vollständig belegter Knoten (z. B. mit einem kompletten Satz Eigenschaften) werden, wenn der Workflow 400 erfolgreich abgeschlossen wird. Wenn jedoch der Workflow 400 nicht abgeschlossen wird, dann bleibt der Ergebnisknoten 420 vollständig oder teilweise unbelegt.
5 stellt den Workflow 400 im Kontext einer weiteren Datenstruktur dar, die in der Graphdatenbank 160 gespeichert ist. Der Workflow 400 ist insbesondere mit einem Konferenzknoten 508 verbunden, der mit einem Kontaktknoten 504 verbunden ist. Es versteht sich, dass der Kontaktknoten 504 einem beliebigen Knoten entsprechen kann, der einen Kunden, eine Gruppe von Kunden oder eine andere mit einer Arbeitsaufgabe verknüpfte Entität beschreibt. Der Kontaktknoten kann insbesondere einem Anrufknoten entsprechen, wobei der Kontakttyp (statt eines nicht in Echtzeit erfolgenden Kontakts wie SMS, Chat, E-Mail, Fax usw.) ein Anruf ist und der Konferenzknoten 508 in diesem Fall einem generischen Knoten entsprechen kann. Bei einer weiteren Konfiguration kann der Kontaktknoten 504 einem generischen Knoten entsprechen und der Konferenzknoten 508 kann den Kontakttyp (z. B. Anruf, SMS, Chat, E-Mail, Fax, Video usw.) identifizieren. Der Kontaktknoten 504 kann auch den mit dem Kontakt verknüpften Kunden identifizieren und sofort nach Eingang des Kontakts im Contact-Center 102 erstellt werden. Der Konferenzknoten 508 kann der in Verbindung mit dem Kontakt auszuführenden Arbeit (z. B. einer Arbeitsaufgabe) entsprechen und die Beziehung zwischen dem Kontaktknoten 504 und dem Konferenzknoten 508 kann feststellen, wann die Beziehung erstellt wurde sowie wie lange sie bestand. Bei manchen Ausführungsformen kann die Beziehung ferner den Typ der Beziehung zwischen dem Kontaktknoten 504 und dem Konferenzknoten 508 identifizieren. Bei dem Beispiel in 5 handelt es sich bei der Beziehung um eine Beziehung vom Sprachtyp mit einem Entstehungszeitpunkt T = 2 und einer Dauer von vier (4) Zeiteinheiten (z. B. Sekunden, Minuten, Stunden, Tage usw.). Die Zeiteinheiten für die Beziehung können in den Beziehungseigenschaften 232 der Graphdatenbank 160 bereitgestellt werden.
Der Konferenzknoten 508 ist auch mit den verschiedenen Knoten im Workflow 400 verbunden und jede Verbindung mit dem Workflow 400 kann einen anderen Beziehungstyp und andere Eigenschaften aufweisen. Als beispielsweise der Workflow 400 erstellt wurde, kann der Konferenzknoten 508 zunächst über eine Beziehung mit IVR als Typ, einem Erstellungszeitpunkt T = 2 und einer Dauer von einer (1) Zeiteinheit mit dem Workflow-Aufgabenknoten 408 verbunden gewesen sein. Nach Abschluss der IVR-Funktion fährt der Workflow 400 fort und der Konferenzknoten 508 wird dann zum Zeitpunkt T = 3 mit dem Entscheidungsknoten 412 verbunden. Danach wird der Konferenzknoten 508 zum Zeitpunkt T=3 mit dem Entscheidungsausführungsknoten 416 verbunden. Da die Aufgabenzuweisungsmaschine 120 versucht, eine optimale Ressource/einen optimalen Agenten für die Arbeitsaufgabe zu finden, nimmt die Dauer der Beziehung zwischen dem Konferenzknoten 508 und dem Entscheidungsausführungsknoten 416 immer weiter zu, und als Beziehungstyp ist „Wartend“ oder „Warten“ eingestellt.
Bis der Entscheidungsausführungsknoten 416 abgeschlossen und die Arbeitsaufgabe einer Ressource 112 zugewiesen ist. Die 6A und 6B zeigen die beiden möglichen Resultate (z. B. unterschiedliche Konfigurationen von Datenstrukturen 500), die in Abhängigkeit davon entstehen können, wie die Aufgabenzuweisungsentscheidung geklärt wird und ob die Entscheidung rechtzeitig erfolgt (z. B. bevor der Kunde auflegt).
Bei dem Beispiel in 6A schlägt der Entscheidungsausführungsknoten 416 fehl und der Workflow 400 kann nicht abgeschlossen werden. Wenn der Workflow 400 nicht abgeschlossen wird, wird der Konferenzknoten 508 mit einem Ergebnisknoten 512 vom Typ „nicht geklärt“ verbunden. Die Beziehung zwischen dem Konferenzknoten 508 und dem Ergebnisknoten 512 zeigt an, dass der Workflow 400 zum Zeitpunkt T = 7 fehlgeschlagen und somit keine Klärung erfolgt ist. Bei diesem konkreten Beispiel kann es sein, dass die Aufgabenzuweisungsmaschine 120 nicht rechtzeitig eine geeignete Ressource 112 finden konnte oder die Arbeitsaufgabe zwar an eine Ressource 112 vergeben wurde, die Ressource 112 jedoch nicht in der Lage war, die Bearbeitung der Arbeitsaufgabe rechtzeitig abzuschließen. In beiden Fällen wird der Workflow 400 nicht abgeschlossen und die Beziehung zwischen dem Konferenzknoten 508 und dem Ergebnisknoten 512 gibt an, dass die Arbeitsaufgabe nicht geklärt wurde.
6A zeigt auch einen Berichtsknoten 604, der mit dem Konferenzknoten 508 verbunden ist. Der Berichtsknoten 604 kann zum Melden einiger oder aller Informationen über den Workflow 400, den Konferenzknoten 508 oder einen beliebigen anderen Knoten oder eine beliebige andere Beziehung benutzt werden, der/die mit dem Konferenzknoten 508 verbunden ist. Bei manchen Ausführungsformen kann der Berichtsknoten 604 zeitweilig für das Abrufen eines einzelnen Datenelements aus der Datenstruktur 500 eingerichtet werden. Bei anderen Ausführungsformen kann der Berichtsknoten 604 in der Datenstruktur 500 ständig vorhanden sein und weiterhin Operationen an Knoten melden, die mit dem Konferenzknoten 508 verbunden sind.
6B stellt im Gegensatz zu 6A einen Fall dar, bei dem der Workflow 400 abgeschlossen und die Agentenanforderung erfüllt ist. Wenn die Aufgabenzuweisungsmaschine 120 in der Lage ist, die Arbeitsaufgabe mit einer Ressource zu verbinden, entspricht der Ergebnisknoten 512 einem Typ „geklärt“. Da die Arbeitsaufgabe von der Aufgabenzuweisungsmaschine 120 an eine Ressource vergeben wird, werden darüber hinaus die zugewiesene Ressource (z. B. Agent Ted) und ein Ressourcenknoten 608, der die zugewiesene Ressource repräsentiert, mit dem Konferenzknoten 508 verbunden. Durch Verbinden des Ressourcenknotens 608 mit dem Konferenzknoten 508 kann die Beziehung zwischen der Arbeitsaufgabe und der Ressource problemlos ermittelt und von dem Berichtsknoten 604 gemeldet werden. Bei der dargestellten Ausführungsform ist die Ressource auch in der Lage, den Bearbeitungsbedarf für die Arbeitsaufgabe vollständig zu klären, so dass der Konferenzknoten 508 mit dem Ergebnisknoten 512 „geklärt“ verbunden werden kann. Bei der dargestellten Ausführungsform werden die Zeitpunkte für das Erstellen der Beziehung und deren Dauer außerdem für jede der Beziehungen beibehalten. Diese Informationen können für den Berichtsknoten 604 nützlich sein, wenn er Berichte zum Erfolg oder fehlenden Erfolg bei der Klärung der mit dem Konferenzknoten 508 verknüpften Arbeitsaufgabe erstellt.
Es wird nun unter Bezugnahme auf 7 ein Verfahren zum Melden einer Ursache für Abbrüche gemäß zumindest einigen Ausführungsformen der vorliegenden Offenbarung beschrieben. Das Verfahren beginnt, wenn bestimmt wird, dass die Ursache für Abbrüche gefunden werden soll und ein Bericht erforderlich ist (Schritt 704). Als Reaktion auf den Beginn des Berichtsprozesses fährt das Verfahren dadurch fort, dass die Anzahl der Abbrüche in der Graphdatenbank 160 gezählt wird (Schritt 708). Diese Zählung kann einer Gesamtzählung aller Abbrüche entsprechen oder einer Zählung der Abbrüche in einem vorgegebenen Zeitraum. Die Abbrüche können unter Verwendung eines Berichtsknotens 604, der nach allen Knoten in der Graphdatenbank 160 vom Typ „Erfüllung“ sucht, sowie der Anzahl Startknoten 404 gezählt werden. Die Startanzahl kann dann zwecks Erhaltens einer Zählung der Anzahl von Abbrüchen von der Gesamtanzahl der Erfüllungsanforderungen abgezogen werden.
Das Verfahren fährt mit dem Zählen der Gesamtanzahl der Startanforderungen fort (wie bereits in Schritt 708 gezählt) (Schritt 712). Es versteht sich, dass die Zählung in Schritt 712 vor, nach oder gleichzeitig mit Schritt 708 durchgeführt werden kann. Der prozentuale Anteil der Abbrüche kann dann durch Dividieren der in Schritt 708 bestimmten Anzahl Abbrüche durch die in Schritt 712 ermittelte Gesamtanzahl berechnet werden (Schritt 716). Dieser Wert kann zwecks Erhalten eines prozentualen Anteils wahlweise mit einhundert (100) multipliziert werden. Darüber hinaus kann durch Einsatz des Berichtsknotens 604, der die Anzahl der Erfüllungsanforderungen zählen kann, die während des Workflow-Aufgabenknotens 408, des Entscheidungsknotens 412, des Entscheidungsausführungsknotens 416 beziehungsweise des Ergebnisknotens 420 fehlgeschlagen sind, die Ursache für Abbrüche identifiziert werden. Die vom Berichtsknoten 604 erhaltenen Informationen können identifizieren, in welchem Verhältnis es in verschiedenen Phasen des Workflows 400 zu Abbrüchen kommt. Wenn es in einer bestimmten Phase des Workflows 400 (z. B. beim IVR oder bei der Aufgabenzuweisung) zu einem höheren prozentualen Anteil von Abbrüchen kommt, kann die Ursache für Abbrüche identifiziert oder zumindest abgeleitet werden. Wenn es z. B. während des IVR-Knotens zu einem Großteil (z. B. mehr als 40%) der Abbrüche kommt, kann abgeleitet werden, dass es ein Problem mit dem IVR-Script gibt, wie beispielsweise eine Programmschleife, fehlerhafte Spracherkennung, falsche Menüpunkte usw. Wenn es als weiteres Beispiel während des Entscheidungsausführungsknotens 416 (z. B. bei der Aufgabenzuweisung) zu einem Großteil der Abbrüche kommt, kann bestimmt werden, dass die Wartezeit für die Kundenzufriedenheit zu lang wird, und das PEP-Modul 132 kann zwecks Bestimmung eines optimalen Personaleinsatzes implementiert werden.
Es wird nun unter Bezugnahme auf 8 ein Verfahren zum Melden einer durchschnittlichen Antwortgeschwindigkeit (DAG) gemäß zumindest einigen Ausführungsformen der vorliegenden Offenbarung beschrieben. Das Verfahren beginnt, wenn bestimmt wird, dass ein Bericht zur DAG erforderlich ist (Schritt 804). Dies kann systematisch und regelmäßig erfolgen oder als Reaktion darauf bestimmt werden, dass ein Administrator oder Manager aus dem Contact-Center einen solchen Bericht anfordert.
Das Verfahren fährt mit dem Bestimmen einer Startzeit für jedes Agentenbegrüßungsereignis in der Graphdatenbank 160 fort (Schritt 808). Bei manchen Ausführungsformen können die Startzeiten nur für Agentenbegrüßungsereignisse bestimmt werden, zu denen es innerhalb eines vorgegebenen Zeitraums gekommen ist. Diese Ereignisse können Knoten in der Graphdatenbank 160 entsprechen.
Für jeden Workflow 408 mit einem in Schritt 808 identifizierten Agentenbegrüßungsereignis und einer dafür bestimmten Startzeit fährt das Verfahren fort, indem es eine Startzeit eines eventuellen IVR-Ereignisses für den Workflow 400 bestimmt (Schritt 812). Wenn also ein Workflow sowohl ein abgeschlossenes Agentenbegrüßungsereignis als auch ein IVR-Ereignis umfasst, dann werden die Startzeiten für diese beiden Ereignisse bestimmt.
Danach fährt das Verfahren mit der Bestimmung der Summe der Antwortdauer auf der Grundlage des Workflows fort (Schritt 816). Bei manchen Ausführungsformen entspricht die Summe der Antwortdauer einem Summenwert der Agentenbegrüßungszeit für jeden Workflow minus der Startzeit des IVR-Ereignisses. Anders ausgedrückt, wird die Summe aller Antwortdauern für den fraglichen Zeitraum bestimmt, indem Workflows analysiert werden und der Zeitraum bestimmt wird, der zwischen der Startzeit eines IVR-Ereignisses und der Startzeit einer Agentenbegrüßung verstrichen ist.
Das Verfahren fährt fort, indem es die Anzahl der Agentenbegrüßungsereignisse in den zu analysierenden Workflows zählt (Schritt 820) und dann die DAG für die Workflows berechnet (Schritt 824). Bei manchen Ausführungsformen wird die DAG durch Dividieren der in Schritt 816 bestimmten Summe der Antwortdauer durch die Gesamtanzahl der in Schritt 820 gezählten Agentenbegrüßungen berechnet. Es versteht sich, dass zum Berechnen oder Schätzen der DAG andere Metriken benutzt werden können, ohne dass vom Schutzumfang der vorliegenden Offenbarung abgewichen würde.
Es wird nun unter Bezugnahme auf 9 ein Verfahren zum Melden einer Ursache für Service-Level (SL) gemäß zumindest einigen Ausführungsformen der vorliegenden Offenbarung beschrieben. Das Verfahren beginnt mit der Bestimmung, dass ein Bericht zum Service-Level oder einer Quelle davon erforderlich ist (Schritt 904). Danach wird die Gesamtanzahl der Kontakte (z. B. Kontaktknoten) gezählt (Schritt 908). Bei manchen Ausführungsformen werden nur die Kontaktknoten mit Erstellungszeitpunkt innerhalb eines interessierenden Zeitraums in Schritt 908 gezählt.
Für jeden in Schritt 908 gezählten Kontakt fährt das Verfahren mit der Bestimmung einer tatsächlichen Wartezeit für die Kontakte fort (Schritt 912). Bei manchen Ausführungsformen kann die Wartezeit für einen Kontakt einer Differenz zwischen dem Erstellungszeitpunkt für eine mit dem Kontakt verknüpfte Arbeitsaufgabe und dem Zeitpunkt entsprechen, an dem ein Agent/eine Ressource mit der Arbeitsaufgabe verbunden wird. Bei manchen Ausführungsformen kann die Wartezeit für einen Kontakt einer Differenz zwischen einem Zeitpunkt, an dem ein Kontaktknoten mit einem Konferenzknoten verbunden wird, und einem Zeitpunkt, an dem eine zugewiesene Ressource mit dem gleichen Konferenzknoten verbunden wird, entsprechen. Bei manchen Ausführungsformen kann die Wartezeit für einen Kontakt einer Dauer einer Beziehung zwischen einem Kontaktknoten und einem Aufgabenzuweisungsentscheidungsknoten 416 entsprechen.
Das Verfahren fährt mit der Bestimmung einer Service-Level-Vorgabe für jeden in Schritt 908 gezählten Kontakt fort (Schritt 916). Die Service-Level-Vorgabe kann als Absolutzeitwert dargestellt und auf die Zeiteinheiten normiert werden, die in Schritt 912 zum Berechnen der Dauer benutzt werden. Bei manchen Ausführungsformen kann die Service-Level-Vorgabe einer bestimmten vorgegebenen Zeit oder einer Reihe von vorgegebenen Zeiten (z. B. einem zulässigen Bereich oberhalb eines Mindestwertes und unterhalb eines Höchstwertes) entsprechen.
Das Verfahren fährt weiter mit dem Zählen der Anzahl der Kontakte fort, bei denen die Wartedauer der Service-Level-Vorgabe entsprach (Schritt 920). Die Kontakte, bei denen die Wartedauer der Service-Level-Vorgabe entsprach, können zumindest vom Aufgabenzuweisungsstandpunkt her als erfolgreiche Agenteninteraktionen betrachtet werden.
Der Service-Level wird dann durch Dividieren der in Schritt 920 identifizierten erfolgreichen Agenteninteraktionen durch die in Schritt 908 bestimmte Gesamtanzahl der Kontakte berechnet (Schritt 924). Der Service-Level kann dann über das Berichtsmodul 136 gemeldet werden.
In 10 ist ein weiteres Beispiel für eine Datenstruktur 1000 in einer Graphdatenbank 160 gezeigt, wobei die Problemklärung nach zwei Versuchen als erfolgreich betrachtet wird. Anders ausgedrückt, verlief der erste Versuch einer Problemklärung bei den in der Datenstruktur 1000 dargestellten Ereignissen tatsächlich erfolglos. Dank der Nutzung einer Graphdatenbank 160 kann jedoch der erste, fehlgeschlagene Versuch einer Klärung mit dem zweiten, erfolgreichen Versuch einer Klärung logisch verbunden werden und ein Berichtsmodul 136 kann die Kundeninteraktion mit dem Contact-Center 102 insgesamt als erfolgreich bezeichnen.
Der in der Datenstruktur 1000 gezeigte Kontaktknoten 504 ist insbesondere mit einem ersten Konferenzknoten 508A und einem zweiten Konferenzknoten 508B verbunden. Der erste gezeigte Konferenzknoten 508A ist von anderem Typ als der zweite Konferenzknoten 508B (z. B. Sprachkonferenz im Gegensatz zu Chat-Konferenz). Da jedoch sowohl die Konferenzen als auch damit verknüpfte separate Arbeitsaufgaben eigentlich von demselben Kunden (z. B. Mary) ausgelöst wurden, kann die Graphdatenbank 160 eine logische Verknüpfung mit den beiden Interaktionen beibehalten und über den Berichtsknoten 604 kann gleichzeitig über beide Interaktionen berichtet werden.
Wie in dem dargestellten Beispiel gezeigt, ist der erste Konferenzknoten 508A mit einem ersten Klärungsknoten 512A verbunden, während der zweite Konferenzknoten 508B mit einem zweiten Klärungsknoten 512B verbunden ist. Die Konferenzknoten 508A, 508B können beide mit demselben Kontaktknoten 504 und demselben Berichtsknoten 604 verbunden sein. Der Bericht, der von dem Berichtsknoten 604 generiert werden kann, kann angeben, dass der erste Konferenzknoten zum Zeitpunkt T = 2 mit dem Kontaktknoten 504 verbunden war und dass versucht wurde, einen Anruf einer Ressource zuzuweisen. Da für den Kontakt bis zum Zeitpunkt T = 7 keine Klärung erreicht werden konnte, wurde der erste Konferenzknoten 508A mit dem ersten Klärungsknoten 512A verbunden. Zum Zeitpunkt T = 10 eskalierte dieselbe Kundin Mary jedoch einen weiteren Kontakt (z. B. Chat). Dieser Chat wurde schließlich zum Zeitpunkt T = 12 einer qualifizierten Ressource zugewiesen, was dazu führte, dass der zweite Konferenzknoten 508B mit dem zweiten Klärungsknoten 512B verbunden wurde.
Es wird nun unter Bezugnahme auf 11 ein Verfahren zum Optimieren von Zielen durch vorgabengeleitetes Verhalten, welches über Metriken gemessen wird, gemäß Ausführungsformen der vorliegenden Offenbarung beschrieben. Das Verfahren wird durch Aufstellen eines oder mehrerer Ziele ausgelöst (Schritt 1104). Zu Beispielen für Ziele, die in einem Contact-Center aufgestellt werden können, gehören unter anderem Zielstellungen bezüglich der Kosten, des Service-Levels, der DAG, der Abbrüche, der Klärung beim ersten Anruf, Kombinationen daraus oder jede andere Zielstellung in Bezug auf eine oder mehrere KPI in einem Contact-Center.
Für jedes Ziel oder jede Zielstellung werden Metrikgruppen eingerichtet (Schritt 1108) und für jede Metrikgruppe wird ein Vorgabebereich eingerichtet (Schritt 1112). Die Zielstellungen bezüglich einer Klärung beim ersten Anruf können beispielsweise Metrikgruppen umfassen, die Kontaktversuche, Metriken zum Definieren einer erfolgreichen Problemklärung und Metriken zum Festlegen, wann ein Kontakt gezählt werden sollte, betreffen. Der Vorgabebereich kann dann die Metriksollwerte für dieses bestimmte Ziel oder diese bestimmte Zielstellung definieren.
Für die in den Schritten 1108 bis 1116 definierten Metriken und Vorgaben werden die zum Definieren der Metriken und Vorgaben aus der Graphdatenbank 160 benötigten Daten identifiziert (Schritt 1120). Zusätzlich dazu wird die aus der Graphdatenbank 160 zu gewinnende Datenbeziehung (Schritt 1124) sowie das Reset-Verhalten definiert (Schritt 1128). Das Reset-Verhalten kann dem Verhalten des Contact-Centers 102 entsprechen, wenn das System nach einem Betriebszeitraum zurückgesetzt wird (z. B. Rücksetzen des Ziels am Ende eines Zyklus). Wenn ein Minimieren der Abbrüche das Ziel ist, dann können beispielsweise die Metriken, von denen bekannt ist, dass sie zu mehr Abbrüchen führen, Erhöhungen der geschätzten Wartezeit oder der DAG sein. Die entgegengesetzte Bewegung von geschätzter Wartezeit und DAG kann die Anzahl der Abbrüche nach unten drücken. Bei diesem Beispiel kann das Reset-Verhalten einer Konfiguration des Verhaltens oder des Contact-Centers 102 entsprechen, bei der bekannt ist, dass sie das Contact-Center 102 am Ende eines Tages, einer Woche usw. auf eine vorgegebene geschätzte Wartezeit oder DAG zurücksetzt.
Metriken, Ziele und Reset-Verhalten können von einem Administrator oder Manager des Contact-Centers 102 definiert werden, sie müssen nicht unbedingt vom Anbieter der Ausstattung für das Contact-Center 102 definiert werden. Dementsprechend ist es für den Contact-Center-Betreiber (z. B. Administrator oder Manager) möglich, das Contact-Center 102 zu betreiben, wodurch Daten generiert werden, die die Metriken entsprechend bestimmen (Schritt 1132). Die aus der Graphdatenbank 160 stammenden Metriken werden dann mit den definierten Vorgaben verglichen (Schritt 1136) und die Ziele können optimiert werden, indem das Verhalten des Contact-Centers 102, das über die Metriken gemessen wird, an den Vorgaben ausgerichtet wird (Schritt 1140). Da die Daten zum Ausrichten des Contact-Centers 102 aus der Graphdatenbank 160 gewonnen werden, können vorteilhafterweise herkömmliche Aufgabenzuweisungsdaten sowie andere Contact-Center-Daten (z. B. PEP-Daten, CRM-Daten, Workflow-Daten usw.) dazugehören.
Es wird nun unter Bezugnahme auf 12 die Nutzung eines Attributbaums 1200 in einem Contact-Center 102 gemäß zumindest einigen Ausführungsformen der vorliegenden Offenbarung beschrieben. Der Attributbaum 1200 repräsentiert eine Datenstruktur der Graphdatenbank 160, die mehrere Datenelemente enthält, welche Attribute im Contact-Center beschreiben und neben anderen Komponenten des Contact-Centers 102 von der Aufgabenzuweisungsmaschine 120 genutzt werden können. Der Attributbaum 1200 wird zum Definieren möglicher und tatsächlicher Ressourcen- und/oder Arbeitsaufgabenattribute benutzt, die gewöhnlich als Kompetenzen oder Bearbeitungsanforderungen bezeichnet werden. Bisher musste der Contact-Center-Administrator einen neuen Attributsatz für jede mögliche oder tatsächliche Attributkombination im Contact-Center 102 vordefinieren. Es versteht sich, dass sich, wenn die Anzahl der im Contact-Center 102 unterstützten Attribute steigt, die Anzahl der Attributsätze exponentiell erhöht. Der Attributbaum 1200 löst dieses Skalierungsproblem in einem Contact-Center 102, indem er eine einfache und elegante Datenstruktur bereitstellt, mit der sich Attribute auf logische Weise definieren und Attributsätze für jede Ressource und/oder jede Arbeitsaufgabe unbegrenzt kombinieren lassen, ohne dass derartige Attributkombinationen vorgegeben werden müssten.
Bei der dargestellten Ausführungsform entspricht der Attributbaum 1200 einer Graphdatenbank-Datenstruktur, in der Knoten Attribute sind und die Beziehungen zwischen den Knoten Gewichtungen entsprechen, die zum Traversieren der Beziehung und Ankommen an einem anderen Knoten benötigt werden. Alternativ oder zusätzlich dazu können die zum Traversieren eines Knotens benötigten Gewichtungen statt als Eigenschaft einer Beziehung als Eigenschaft des Knotens geführt werden. Ein weiterer Vorteil des Attributbaums 1200 besteht darin, dass die Aufgabenzuweisungsmaschine 120 mit Hilfe von nähebasierten Routing-Techniken eine bestmögliche Übereinstimmung zwischen einer Ressource und einer Arbeitsaufgabe finden kann, selbst wenn die Ressource nicht über genau die für die Bearbeitung der Arbeitsaufgabe erforderliche Attributkombination verfügt.
Der gezeigte Attributbaum 1200 weist einen Basisknoten 1204 auf, der mit einer ersten Ebene von Knoten 1208 verbunden ist. Die Knoten 1208 der ersten Ebene sind mit Knoten 1212 einer zweiten Ebene verbunden, die mit Knoten 1216 einer dritten Ebene verbunden sind usw. Der gezeigte Attributbaum 1200 weist zwar nur drei Ebenen von Knoten auf, es versteht sich jedoch, dass Attributbäume mit viel größerer Tiefe und einer viel größeren Anzahl Ebenen benutzt werden können. Der dargestellte einfache Attributbaum 1200 soll die vorliegende Offenbarung besser verständlich machen.
Bei dem dargestellten Beispiel kann die erste Ebene von Knoten 1208 einem höchsten Wert von Attributen oder Kompetenzen im Contact-Center 102 entsprechen (z. B. Sprache, Service, Produkt usw.). Die Art und die Typen von Knoten in jeder Ebene des Attributbaums 1200 können vom Anbieter des Contact-Centers 102 oder von einem Benutzer des Contact-Centers (z. B. Manager oder Administrator) definiert werden. Je nach den Bedürfnissen und den vom Contact-Center angebotenen Diensten werden sich die Knotentypen auf der ersten Ebene von Knoten 1208 wahrscheinlich von den in 12 dargestellten unterscheiden.
Die zweite Ebene von Knoten 1212 entspricht den mit der ersten Ebene von Knoten 1208 verbundenen Unterknoten. Zu den dargestellten Beispielen für Knoten auf der zweiten Ebene von Knoten 1212 gehören Englisch, Spanisch usw. (als Unterknoten für den Knoten „Sprache“), Vertrieb, Kundendienst usw. (als Unterknoten für den Knoten „Service“) und Kabelfernsehen, Telefonie, Internet (als Unterknoten für den Knoten „Produkt“). Bei diesem konkreten Beispiel kann das Contact-Center 102, das diesen konkreten Attributbaum 1200 benutzt, einem Internet-, Telefon- und Kabelanbieter (z. B. einem Netzwerkanbieter) entsprechen und die verschiedenen Kategorien von Attributen auf der zweiten Ebene von Knoten 1212 können die Diensttypen definieren, die speziell in dem Contact-Center 102 abgewickelt werden.
Die dritte Ebene von Knoten 1216 entspricht den mit der zweiten Ebene von Knoten 1212 verbundenen Unterknoten. Zu den abgebildeten Beispielen für Knoten auf der dritten Ebene von Knoten 1216 gehören US, GB usw. (als Unterknoten für den Sprachknoten „Englisch“), Erstkunde, Bestandskunde usw. (als Unterknoten für den Knoten „Vertrieb“), Fehlersuche, Verbindungstrennung, Buchhaltung und Abrechnung usw. (als Unterknoten für den Knoten „Kundendienst“) und normal, Premium usw. (als Unterknoten für den Knoten „Kabelfernsehen“). Es versteht sich, dass es für die anderen Knoten auf der zweiten Ebene von Knoten 1212 definierte Unterknoten geben kann. Weitere Einzelheiten zum Attributbaum 1200 werden in Verbindung mit der Aufgabenzuweisungsmaschine 120 und ihrem Betrieb beschrieben.
Es wird nun unter Bezugnahme auf 13 ein Aufgabenzuweisungsverfahren gemäß Ausführungsformen der vorliegenden Offenbarung beschrieben. Das Verfahren beginnt bei Schritt 1304, wenn beispielsweise im Contact-Center 102 eine Arbeitsaufgabe erstellt oder eine Ressource verfügbar wird. Sobald der Aufgabenzuweisungsprozess beginnt, werden die Prioritäten für jede Vorgabengruppe von der Aufgabenzuweisungsmaschine 120 bestimmt (Schritt 1308) und die Gruppe/n mit der höchsten Priorität wird/werden zur Unterstützung der Aufgabenzuweisungsentscheidung ausgewählt (Schritt 1312). Bei manchen Ausführungsformen kann ein Contact-Center-Administrator oder -Manager die Prioritäten von Vorgabengruppen definieren (z. B. höchste Priorität ist Profit, zweithöchste Priorität ist Abbruchrate, dritthöchste Priorität ist DAG usw.) und die Prioritäten können je nach Bedarf während des Betriebs des Contact-Centers 102 individuell angepasst und geändert werden. Weiterhin sei bei diesem konkreten Beispiel angenommen, dass Abbruch oder Abbruchrate als Gruppe mit der höchsten Priorität ausgewählt ist (z. B. Abbruchrate minimieren).
Das Verfahren fährt mit der Auswahl der ersten Aufgabe fort, die sich am wahrscheinlichsten auf die Gruppe mit der höchsten Priorität auswirkt (z. B. Aufgaben, die wahrscheinlich zu Abbrüchen führen) (Schritt 1316), sowie den Aufgaben, die Abbrüche am wahrscheinlichsten reduzieren (Schritt 1320). Bei diesem Beispiel kann das Hinzufügen weiterer Ressourcen zum Pool verfügbarer Ressourcen (z. B. Einsatz externer Ressourcen) dazu beitragen, Abbrüche zu reduzieren, während das Zuweisen von Ressourcen zu anderen Aufgaben zu Abbrüchen führen kann. Die Aufgabenzuweisungsmaschine 120 wird die in Schritt 1316 und 1320 identifizierten Aufgaben je nach aktuellem Zustand des Contact-Centers implementieren, um das Verhalten des Contact-Centers auf das Sollziel für die Gruppe mit der höchsten Priorität auszurichten (Schritt 1324). Die Aufgabenzuweisungsmaschine 120 kann wie oben erwähnt versuchen, die Ziele im Hinblick auf Abbrüche zu erfüllen, indem sie bei Aufgabenzuweisungsentscheidungen den Attributbaum 1200 benutzt. Wenn Abbrüche in direkter Beziehung zur geschätzten Wartezeit stehen, kann die Aufgabenzuweisungsmaschine 120 ihre Abgleichlogik so lockern, dass bei einer Aufgabenzuweisungsentscheidung ein umfangreicheres Traversieren des Attributbaums 1200 möglich ist. Anders ausgedrückt, benötigt die Aufgabenzuweisungsmaschine 120 nicht unbedingt eine perfekte Übereinstimmung zwischen einer Arbeitsaufgaben-Bearbeitungsanforderung (laut Definition durch Attribute im Attributbaum 1200) und den Kompetenzen einer Ressource (laut Definition durch Attribute im Attributbaum 1200). Stattdessen kann ein „ausreichend geeigneter“ Agent anhand der Nähe des Agenten zu den erforderlichen Attributen im Attributbaum 1200 ausgewählt werden.
Es wird nun unter Bezugnahme auf die 14A und 14B ein Aufgabenzuweisungsverfahren gemäß zumindest einigen Ausführungsformen der vorliegenden Offenbarung beschrieben, das gleichzeitig zwei oder mehrere Ziele erfüllt. Die bei diesem bestimmten Verfahren zu erfüllenden Ziele können kompatibel (z. B. durch die Verschiebung der Metriken in die gleiche Richtung auf einen optimalen Wert ausgerichtet) sein oder auch nicht. Ein Beispiel für nicht kompatible Ziele kann die Maximierung des Profits und die Maximierung der Kundenzufriedenheit sein. Ein weiteres Beispiel für nicht kompatible Ziele kann das Erzielen eines vorgegebenen Service-Levels und das Erzielen einer vorgegebenen Abbruchrate sein. Diese Ziele können zwar kompatibel sein, es ist jedoch wahrscheinlicher, dass sich das Erfüllen eines Ziels (z. B. Service-Level) negativ auf das Erfüllen des anderen Ziels (z. B. Abbruchrate) auswirkt. Das Verfahren beginnt, wenn die Aufgabenzuweisungsmaschine 120 eingeschaltet ist (Schritt 1404) und Arbeitsaufgaben im Contact-Center eintreffen. Vor dem Starten der Aufgabenzuweisungsmaschine 120 können die Vorgaben oder Vorgabenbereiche für die beiden oder mehreren Ziele identifiziert und der Aufgabenzuweisungsmaschine 120 zur Verfügung gestellt werden (Schritt 1408).
Die Aufgabenzuweisungsmaschine 120 benutzt die für die zwei oder mehreren Ziele definierten Vorgaben für ihre Aufgabenzuweisungsentscheidungen und der Attributbaum 1200 kann zum Abgleichen von Arbeitsaufgaben mit Ressourcen benutzt werden (Schritt 1412). Die Aufgabenzuweisungsmaschine 120 ist insbesondere in der Lage, alle möglichen Zuweisungsentscheidungen für eine Arbeitsaufgabe und/oder eine Ressource mit einer Scoring-Funktion zu prüfen, damit sie die zwei oder mehreren Ziele (z. B. Service-Level und Abbruchrate) gleichzeitig auf einen Sollbereich ausrichten kann (Schritt 1416). Da der Aufgabenzuweisungsmaschine 120 die mehrfachen Ziele bekannt sind und sie den Attributbaum 1200 traversieren und „weichere“ Aufgabenzuweisungsentscheidungen treffen kann (z. B. Entscheidungen, die nicht auf einen definierten Satz Attributkombinationen beschränkt sind), ist sie in der Lage, auf der Grundlage der vom Benutzer angegebenen Prioritäten bezüglich der Ziele angemessene Kompromisse zwischen verschiedenen Gruppen einzugehen (Schritt 1420).
Wie in 14B dargestellt, kann eines der Ziele auf einer Achse eines sichtbaren Graphen und das andere Ziel auf einer anderen Achse des Graphen dargestellt sein. Die dadurch erzeugte Matrix kann Zuständen des Contact-Centers entsprechen, bei denen das Viereck in der Mitte der Matrix einen Zustand repräsentiert, in dem beide Ziele erreicht sind (z. B. Metriken liegen in Vorgabebereichen für beide Ziele). Die Aufgabenzuweisungsmaschine 120 kann so konfiguriert sein, dass sie solche Aufgabenzuweisungsentscheidungen trifft, dass das Verhalten des Contact-Centers 102, wenn es sich nicht in dem Zielviereck in der Mitte befindet, so angepasst wird, dass es auf das Zielviereck in der Mitte ausgerichtet ist, bei dem der Service-Level nicht zu hoch oder zu gering und die Abbruchrate nicht zu hoch oder zu gering ist. Wenn insbesondere die Service-Level zu hoch sind, kann die Aufgabenzuweisungsmaschine 120 versuchen, den Personaleinsatz zu reduzieren und dadurch den Service-Level in den Vorgabebereich zu bringen. Gleichermaßen kann die Aufgabenzuweisungsmaschine 120, wenn die Abbruchrate zu hoch wird, mehr Ressourcen zum Pool verfügbarer Ressourcen hinzufügen oder die Aufgabenzuweisungsmaschine 120 kann ihre Restriktionen hinsichtlich der Aufgabenzuweisungsanforderungen lockern (z. B. für die Suche nach einer übereinstimmenden Ressource für eine Arbeitsaufgabe ein umfangreicheres Traversieren des Attributbaums 1200 zulassen).
Es werden nun unter Bezugnahme auf die 15A und 15B weitere Einzelheiten zu einem Attributbaum 1500 gemäß Ausführungsformen der vorliegenden Offenbarung beschrieben. Der Attributbaum 1500 kann dem Attributbaum 1200 aus 12 ähneln oder gleichen. Der Attributbaum 1500 zeigt ferner, dass einige oder alle Knoten des Attributbaums 1500 Gewichtungen oder Traversierwerte 1504 umfassen können. Diese Gewichtungen können für die Aufgabenzuweisungsmaschine 120 einen Mechanismus zum Bestimmen liefern, ob eine konkrete Ressource einer konkreten Arbeitsaufgabe zugewiesen werden kann. Eine Arbeitsaufgabe kann beispielsweise ein Sprachattribut „Englisch:GB“ umfassen. Wenn die Aufgabenzuweisungsmaschine 120 bestimmt, dass keine verfügbare Ressource genau die richtige Sprachvoraussetzung umfasst, die mit dem Sprachattribut der Arbeitsaufgabe übereinstimmt, dann kann die Aufgabenzuweisungsmaschine 120 nach einer besten verfügbaren zweiten Option suchen. Zu dieser Suche kann gehören, dass die Aufgabenzuweisungsmaschine 120 die Knoten des Attributbaums 1500 traversiert, bis ein Knoten mit einer damit verbundenen verfügbaren Ressource gefunden ist. Wenn in Fortführung des obigen Beispiels eine verfügbare Ressource ein Sprachattribut „Englisch:USA“ besitzt, dann kann die Aufgabenzuweisungsmaschine in die Lage versetzt werden, die Arbeitsaufgabe an die Ressource zu vergeben, indem sie den Attributbaum 1500 vom Knoten „Englisch:GB“ zum Knoten „Englisch“ und dann zum Knoten „Englisch:USA“ traversiert. Der Traversierwert 1504 für die Bewegung vom Knoten „Englisch:USA“ zum Knoten „Englisch“ kann ein Punkt und der Traversierwert 1504 vom Knoten „Englisch“ zum Knoten „Englisch:GB“ dann zwei Punkte sein. Bei diesem Beispiel gibt die Aufgabenzuweisungsmaschine der Entscheidung, die Arbeitsaufgabe an die Ressource mit dem Attribut „Englisch:USA“ zu vergeben, eine negative Gewichtung von insgesamt drei Punkten. Dies kann als zwar zulässige, aber nicht ganz optimale Aufgabenzuweisungsentscheidung betrachtet werden, jedoch angesichts zunehmender Wartezeiten und eines steigenden Abbruchrisikos kann es der Aufgabenzuweisungsmaschine 120 erlaubt sein, die nicht ganz optimale Aufgabenzuweisungsentscheidung zu treffen. Mit Hilfe der Traversierwerte 1504 kann überprüft werden, wie flexibel die Aufgabenzuweisungsmaschine 120 beim Fällen ihrer Entscheidungen sein kann.
Der Attributbaum 1500 repräsentiert daher eine hierarchische Organisation von Attributen im Contact-Center 102 und kann zum Abgleichen auf flexible Weise benutzt werden. Der Attributbaum 1500 eliminiert die Notwendigkeit vordefinierter Attributsätze und ermöglicht, dass die natürlich definierten Beziehungen Nachbarschaftsbestimmungen vereinfachen. Darüber hinaus müssen die Attribute zum Abgleichen und Berichten nicht zu Sätzen gruppiert werden.
Ein einzelner Attributbaum 1500 kann in der Graphdatenbank 160 definiert sein, und wenn Ressourcen und/oder Arbeitsaufgaben zum Contact-Center 102 hinzugefügt werden, können die Kompetenzniveaus oder Bearbeitungsanforderungen für die Ressourcen/Arbeitsaufgaben definiert werden, indem die Knoten der Ressource/der Arbeitsaufgabe mit den Knoten im Attributbaum verbunden werden. 15B zeigt, wie das Kompetenzniveau eines beispielhaften Agenten (z. B. Agent Ted) dadurch definiert wird, dass der Knoten des Agenten mit den entsprechenden Knoten im Attributbaum 1500 verbunden ist. Wenn der Agent eine bestimmte Kompetenz besitzt, dann ist sein Knoten mit dem entsprechenden Knoten im Attributbaum 1500 verbunden, und der Beziehung zwischen dem Agentenknoten und dem Knoten im Attributbaum 1500 kann eine Gewichtung zugewiesen werden. Obwohl dies nicht gezeigt ist, kann der Arbeitsaufgaben- oder Kontaktknoten gleichermaßen mit Knoten im Attributbaum 1500 verbunden sein. Das bedeutet, dass die Aufgabenzuweisungsmaschine 120 den Attributbaum 1500 nur von der Arbeitsaufgabe bis zur nächstgelegenen Ressource zu traversieren braucht, um eine optimale oder ausreichend geeignete Übereinstimmung für die Arbeitsaufgabe zu identifizieren. Wenn mehrere Ressourcen die gleichen Kompetenzen besitzen und mit den gleichen Knoten im Attributbaum 1500 verbunden sind, kann die Aufgabenzuweisungsmaschine 120 die Knoten in der Graphdatenbank 160 weiter traversieren, um andere Parameter zu identifizieren, die sich zum Fällen einer Aufgabenzuweisungsentscheidung eignen (z. B. kann eine Leerlaufzeit (die von anderen Knoten in der Graphdatenbank 160 definiert werden kann) für gleich qualifizierte Agenten beim Fällen der Aufgabenzuweisungsentscheidung berücksichtigt werden).
Bei dem Beispiel in 15B besitzt Agent Ted eine Gewichtung von Null für seine Verbindungen zu den Knoten „Englisch:US“ und „Premium-Kabel“. Dies kann darauf hinweisen, dass Ted mit diesen bestimmten Aspekten eines Kontakts völlig kompetent umgehen kann. Dank einer durch den Attributbaum 1500 ermöglichten Nachbarschaftsübereinstimmung kann Agent Ted jedoch, wenn eine Arbeitsaufgabe ein Attribut „Englisch:GB“ aufweist und Produktinformationen für normales Kabelfernsehen (statt Premium-Kabelfernsehen) gefragt sind, trotzdem eine brauchbare Option für die Aufgabenzuweisungsmaschine 120 sein, da die zu traversierenden Knoten des Attributbaums 1500 nicht besonders wichtig und die Traversierwerte 1504 für den Weg zu solchen Knoten relativ gering sind. Wenn jedoch eine Arbeitsaufgabe ein Attribut „Spanisch“ aufweist, ist es möglich, dass die Aufgabenzuweisungsmaschine 120 die Arbeitsaufgabe nicht an den Agenten Ted vergeben kann, da das Traversieren des Attributbaums von „Englisch“ zu „Spanisch“ (aufgrund des fehlenden Traversierwerts 1504 am Knoten „Sprache“) nicht zulässig ist. Es können jedoch andere Knoten auf der ersten Ebene von Knoten 1208 traversiert werden, wie von den Traversierwerten des Serviceknotens und des Produktknotens angegeben wird.
Die 16A und 16B stellen weitere Einzelheiten zu Datenstrukturen in einer Graphdatenbank 160 eines Contact-Centers 102 dar. Die Nutzung einer Graphdatenbank gestaltet sich, wie hier erläutert, flexibel und kann so modifiziert werden, dass eine beliebige Anzahl Contact-Center-Bedingungen berücksichtigt werden. Die Datenstruktur aus 16A zeigt, wie Kontaktknoten mit mehreren verschiedenen Konferenzknoten und die Konferenzknoten verschiedener Kunden mit einem gemeinsamen Klärungsknoten verbunden sein können. Bei dem dargestellten Beispiel können die Konferenzknoten, die mit dem Kontaktknoten von Mary verbunden sind, beide mit einem Klärungsknoten „nicht abgebrochen“ verbunden sein. Der Konferenzknoten, der mit dem Kontaktknoten von Fred verbunden ist, kann mit einem Klärungsknoten „abgebrochen“ verbunden sein. Der Konferenzknoten, der mit dem Contact-Center von Tim verbunden ist, kann ebenfalls mit dem Klärungsknoten „abgebrochen“ verbunden sein. Dies ist nützlich, da das Contact-Center 102 weiterarbeitet und weitere Kontaktknoten entstehen. Es kann insbesondere ein einzelner Berichtsknoten erstellt und zum Generieren eines Berichts über fehlgeschlagene Klärungen (z. B. zum Bestimmen von Abbrüchen, der Ursache von Abbrüchen usw.) mit den entsprechenden Knoten in der Graphdatenbank 160 verbunden werden.
16B zeigt eine weitere mögliche Repräsentation des gleichen in 16A dargestellten Szenarios in einer Graphdatenbank 160, nur gibt es in der Graphdatenbank 160 keine speziellen Klärungsknoten für „Abbruch“ und „nicht Abbruch“. Stattdessen sind alle Konferenzknoten mit einem gemeinsamen Ergebnisknoten verbunden und die Beziehungen zwischen den Konferenzknoten und dem gemeinsamen Ergebnisknoten zeigen, ob das Ergebnis ein Abbruch war oder nicht. Mit anderen Worten versteht es sich, dass Ausführungsformen der vorliegenden Offenbarung nicht auf die hier dargestellten und beschriebenen bestimmten Graphdatenbankkonfigurationen beschränkt sind. Ausführungsformen der vorliegenden Offenbarung hingegen ziehen zum Beschreiben des Betriebs eines Contact-Centers jede Konfiguration von Graphdatenbankknoten und/oder Beziehungen in Erwägung. Darüber hinaus kann die Graphdatenbank so erweitert werden, dass sie einen Attributbaum und andere Datenstrukturen enthält, die den Betrieb anderer Contact-Center-Komponenten unterstützen. Durch Aufnehmen dieser Datenstrukturen in eine gemeinsame Datenbank und ein gemeinsames Datenschema verbessert sich der Betrieb des s 102 im Vergleich zum Stand der Technik beträchtlich und die bisher inkompatiblen Komponenten können nahtlos betrieben werden.
Bei der vorangegangenen Beschreibung wurden zur Veranschaulichung Verfahren in einer bestimmten Reihenfolge beschrieben. Es versteht sich, dass die Verfahren bei alternativen Ausführungsformen in einer anderen Reihenfolge als der beschriebenen ausgeführt werden können. Es versteht sich auch, dass die oben beschriebenen Verfahren von Hardware-Komponenten ausgeführt werden oder in Sequenzen von maschinenausführbaren Befehlen enthalten sein können, mit deren Hilfe eine Maschine, wie beispielsweise ein Universal- oder Spezialprozessor (GPU oder CPU), oder mit den Befehlen programmierte Logikschaltkreise dazu veranlasst werden können, die Verfahren auszuführen (FGPA). Diese maschinenausführbaren Befehle können auf einem oder mehreren maschinenlesbaren Medien, wie beispielsweise CD-ROM oder einem anderen Typ optischer Platten, flexiblen Platten, ROM, RAM, EPROM, EEPROM, Magnetkarten oder optischen Karten, Flash-Speicher oder anderen Typen maschinenlesbarer Medien, gespeichert sein, die sich zum Speichern von elektronischen Befehlen eignen. Alternativ dazu können die Verfahren von einer Kombination aus Hardware und Software ausgeführt werden.
In der Beschreibung wurden genaue Einzelheiten angegeben, die für eine umfassende Verständlichkeit der Ausführungsformen sorgen sollen. Durchschnittsfachleute dürften jedoch erkennen, dass die Ausführungsformen ohne diese speziellen Einzelheiten praktiziert werden können. So können Schaltkreise in Blockdiagrammen gezeigt sein, damit die Ausführungsformen nicht aufgrund unnötiger Einzelheiten unklar werden. Bei anderen Beispielen können bekannte Schaltkreise, Prozesse, Algorithmen, Strukturen und Techniken ohne unnötige Einzelheiten gezeigt sein, um zu vermeiden, dass die Ausführungsformen unklar werden.
Es sei auch angemerkt, dass die Ausführungsformen als Prozess beschrieben wurden, der als Ablaufdiagramm, Flussdiagramm, Datenflussdiagramm, Strukturdiagramm oder Blockdiagramm dargestellt ist. Ein Ablaufdiagramm kann die Operationen zwar als sequentiellen Prozess beschreiben, doch können viele der Operationen parallel oder gleichzeitig ausgeführt werden. Außerdem kann die Reihenfolge der Operationen geändert werden. Ein Prozess wird beendet, wenn seine Operationen abgeschlossen sind, könnte jedoch weitere Schritte aufweisen, die nicht in der Figur enthalten sind. Ein Prozess kann einem Verfahren, einer Funktion, einem Vorgang, einer Subroutine, einem Unterprogramm usw. entsprechen. Wenn ein Prozess einer Funktion entspricht, entspricht seine Beendigung einer Rückkehr der Funktion zur aufrufenden oder Hauptfunktion.
Ausführungsformen können ferner durch Hardware, Software, Firmware, Middleware, Mikrocode, Hardware-Beschreibungssprache oder eine beliebige Kombination daraus implementiert werden. Bei einer Implementierung in Software, Firmware, Middleware oder Mikrocode können der Programmcode oder Codesegmente, die die erforderlichen Aufgaben ausführen, auf einem maschinenlesbaren Medium wie einem Speichermedium gespeichert sein. Ein oder mehrere Prozessoren können die erforderlichen Aufgaben ausführen. Ein Codesegment kann einen Vorgang, eine Funktion, ein Unterprogramm, ein Programm, eine Routine, eine Subroutine, ein Modul, ein Softwarepaket, eine Klasse oder eine beliebige Kombination aus Befehlen, Datenstrukturen oder Programmanweisungen repräsentieren. Ein Codesegment kann mit einem anderen Codesegment oder einem Hardware-Schaltkreis durch Weiterleiten und/oder Empfangen von Informationen, Daten, Argumenten, Parametern oder Speicherinhalten gekoppelt sein. Informationen, Argumente, Parameter, Daten usw. können über beliebige geeignete Mittel wie gemeinsame Speichernutzung, Nachrichtenweitergabe, Token-Weitergabe, Netzwerkübertragung usw. weitergegeben, weitergeleitet oder übertragen werden.
Es wurden hier zwar Ausführungsbeispiele für die Offenbarung ausführlich beschrieben, es versteht sich jedoch, dass die erfindungsgemäßen Konzepte auch anderweitig auf verschiedene Weise verkörpert und eingesetzt werden können und dass die beigefügten Ansprüche so ausgelegt werden müssen, dass sie, sofern der Stand der Technik dies nicht einschränkt, derartige Variationen umfassen.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Patentliteratur

US 8619968 [0003]

Claims

Graphdatenbank, die Folgendes umfasst: eine Datenbankschnittstelle, die die Graphdatenbank mit einem Kommunikationsnetzwerk verbindet, und ein Datenspeichermedium, das mehrere darauf gespeicherte Datenelemente umfasst, zu denen ein erster Knoten und ein zweiter Knoten gehört, wobei sowohl der erste als auch der zweite Knoten ein Attribut, eine Arbeitsaufgabe, einen Kontakt, eine Ressource, eine Entität, ein Ereignis oder/und eine Komponente in einem Contact-Center repräsentiert und der erste und der zweite Knoten über mindestens eine Beziehung miteinander verbunden sind.
Graphdatenbank nach Anspruch 1, bei der die mindestens eine Beziehung einen Beziehungstyp umfasst, der in der Graphdatenbank definiert ist, sowie eine oder mehrere Eigenschaften, die die Beziehung zwischen dem ersten und dem zweiten Knoten beschreiben.
Graphdatenbank nach Anspruch 1, wobei die Graphdatenbank ferner ein Knotenwörterbuch und ein Beziehungswörterbuch umfasst, wobei das Knotenwörterbuch jeden derzeit auf dem Datenspeichermedium gespeicherten oder speicherbaren Knotentyp und das Beziehungswörterbuch jeden derzeit auf dem Datenspeichermedium gespeicherten oder speicherbaren Beziehungstyp identifiziert.
Graphdatenbank nach Anspruch 1, wobei mindestens einer des ersten oder des zweiten Knotens eine Komponente im Contact-Center repräsentiert und wobei die von mindestens dem ersten oder dem zweiten Knoten repräsentierte Komponente ein Personaleinsatzplanungsmodul umfasst.
Graphdatenbank nach Anspruch 1, wobei mindestens einer des ersten oder des zweite Knotens eine Komponente im Contact-Center repräsentiert und wobei die von dem mindestens ersten oder zweiten Knoten repräsentierte Komponente ein Berichtsmodul umfasst, wobei das Berichtsmodul mindestens einen Knoten in der Graphdatenbank bereitstellt, der mindestens mit dem ersten oder dem zweiten Knoten dergestalt verbunden ist, dass ein Bericht generiert werden kann, der Informationen über mindestens einen des ersten Knotens, des zweiten Knotens und die mindestens eine Beziehung enthält, die den ersten mit dem zweiten Knoten verbindet.
Graphdatenbank nach Anspruch 1, wobei mindestens einer des ersten oder des zweiten Knotens eine Komponente im Contact-Center repräsentiert und wobei die von dem mindestens ersten oder zweiten Knoten repräsentierte Komponente ein Prognosemodul umfasst.
Graphdatenbank nach Anspruch 1, wobei mindestens einer des ersten Knotens oder des zweiten Knotens ein Attribut repräsentiert und wobei das Attribut in einem Attributbaum enthalten ist, der mehrere Attributknoten umfasst, die auf hierarchische Weise organisiert sind.
Graphdatenbank nach Anspruch 1, wobei der erste Knoten einem Kontaktknoten entspricht, wobei der zweite Knoten einem Ressourcenknoten entspricht und wobei der erste und der zweite Knoten über einen Zwischenknoten, bei dem es sich um einen Konferenzknoten handelt, miteinander verbunden sind.
Contact-Center, das Folgendes umfasst: mindestens einen Server, der so konfiguriert ist, dass er eine oder mehrere Operationen im Contact-Center ausführt, und eine Graphdatenbank, die Folgendes umfasst: eine Datenbankschnittstelle, die die Graphdatenbank mit dem mindestens einen Server verbindet, und ein Datenspeichermedium, das mehrere darauf gespeicherte Datenelemente umfasst, wobei die mehreren Datenelemente einen ersten Knoten und einen zweiten Knoten umfassen, wobei sowohl der erste als auch der zweite Knoten mindestens eines von einem Attribut, einer Arbeitsaufgabe, einem Kontakt, einer Ressource, einer Entität, einem Ereignis und einer Komponente in einem Contact-Center repräsentieren und wobei der erste Knoten und der zweite Knoten über mindestens eine Beziehung miteinander verbunden sind.
Contact-Center nach Anspruch 9, wobei die mindestens eine Beziehung einen Beziehungstyp umfasst, der in der Graphdatenbank definiert ist, sowie eine oder mehrere Eigenschaften, die die Beziehung zwischen dem ersten Knoten und dem zweiten Knoten beschreiben, wobei die Graphdatenbank ferner ein Knotenwörterbuch und ein Beziehungswörterbuch umfasst, wobei das Knotenwörterbuch jeden derzeit auf dem Datenspeichermedium gespeicherten oder speicherbaren Knotentyp und das Beziehungswörterbuch jeden derzeit auf dem Datenspeichermedium gespeicherten oder speicherbaren Beziehungstyp identifiziert, wobei mindestens einer des ersten Knotens und des zweiten Knotens eine Komponente im Contact-Center repräsentiert und wobei die von dem mindestens ersten Knoten und zweiten Knoten repräsentierte Komponente ein Personaleinsatzplanungsmodul umfasst, wobei mindestens einer des ersten Knotens und des zweiten Knotens eine Komponente im Contact-Center repräsentiert und wobei die von dem mindestens ersten Knoten und zweiten Knoten repräsentierte Komponente ein Berichtsmodul umfasst, wobei das Berichtsmodul mindestens einen Knoten in der Graphdatenbank bereitstellt, der so mit dem mindestens einem des ersten Knotens und zweiten Knotens verbunden ist, dass ein Bericht generiert werden kann, der Informationen über mindestens einen des ersten Knotens, des zweiten Knotens und die mindestens eine Beziehung enthält, die den ersten Knoten mit dem zweiten Knoten verbindet.