Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Szenario und Bereitstellungsansätze in Connect Customer
Connect Customer bietet eine Self-Service-Konfiguration und ermöglicht eine dynamische, persönliche und natürliche Kundenbindung in jeder Größenordnung mit einer Vielzahl von Migrations- und Integrationsoptionen. In diesem Abschnitt erläutern wir die folgenden Szenarien und Bereitstellungsansätze, die bei der Planung eines Workloads für Connect Customer zu berücksichtigen sind:
-
Traditionelles Contact Center
-
Eingehend
-
Ausgehend
-
Hybrides Contact Center
-
Migration alter Contact Center
-
Virtual Desktop Infrastructure (VDI)
Traditionelles Contact Center
Traditionelle Contact Center setzen eine aufwändige Infrastruktur für Telefonie, Medien, Netzwerk, Datenbanken und Verarbeitung voraus, die mehrere Anbieter und Standorte für Rechenzentren bis hin zu Servicekontakten umfassen kann. Jede Lösung und jeder Anbieter kann eigene Anforderungen an die Hardware, die Software, das Netzwerk und die Architektur haben, die erfüllt werden müssen, während gleichzeitig eine Behebung von Konflikten bei der Versionierung, Kompatibilität und Lizenzierung erfolgen muss.
Es ist üblich, separate Anbieter und Infrastrukturanforderungen für lokale und entfernte Agentenhardware und VPN-Konnektivität Text-To-Speech (TTS), automatische Anrufverteilung (ACD), Interactive Voice Response (IVR), Sprachaudio und Daten, physische Tischtelefone, Sprachaufzeichnung, Sprachtranskriptionen, Chat, Berichterstattung, Datenbank, Computer-Telefonie-Integration (CTI), automatische Spracherkennung (ASR) und Natural Language Understanding (NLP) zu haben. Ihre Contact-Center-Architektur und -Infrastruktur werden komplizierter, wenn Sie mehrstufige Entwicklungs-, Qualitätssicherungs- und Testumgebungen berücksichtigen.
Eine typische Connect-Kundenbereitstellung löst oder reduziert viele der Herausforderungen im Zusammenhang mit Versionierung, Kompatibilität, Lizenzierung, Contact-Center-Telefonie-Infrastruktur und Wartung. Sie bietet Ihnen die Flexibilität, innerhalb von Minuten Instances an neuen Standorten zu erstellen und Komponenten einzeln oder parallel zu migrieren, um Ihre individuellen Geschäftsziele bestmöglich zu erreichen. Sie können Flows für Ihr verwenden IVR/ACD, Sprache und Daten über einen unterstützten Webbrowser auf das Softphone Ihres Agenten übertragen lassen, Ihre vorhandenen Telefonnummern portieren, Softphone-Audio auf ein vorhandenes Tischtelefon umleiten, einen Amazon Lex-Bot nativ in Ihrem Flow für ASR und NLP aufrufen und denselben Flow für Chat und Voice verwenden. Sie können Connect Customer Conversational Analytics verwenden, um automatisch Sprachtranskriptionen zu generieren, Stichwortidentifikationen und Stimmungsanalysen durchzuführen und Kontakte zu kategorisieren. Für CTI-Daten von Agenten und Sprachstreaming in Echtzeit können Sie Connect Customer Agent Event Streams und Kinesis Video Streams verwenden. Sie können auch mehrstufige Entwicklungs-, Qualitätssicherungs- und Testumgebungen ohne zusätzliche Kosten einrichten und nur für das bezahlen, was Sie tatsächlich nutzen.
Eingehend
„Eingehend“ ist ein Begriff im Contact Center, der verwendet wird, um eine Kommunikationsanfrage zu beschreiben, die von einem Kontakt initiiert wurde und an das Center gerichtet ist. Kontakte können Ihre Connect Customer-Instanz für eingehenden Self-Service oder um mit einem Live-Agenten auf verschiedene Weise zu sprechen, einschließlich Sprach- und Chat-Funktion, erreichen. Sprachkontakte laufen über das PSTN und werden über die in Ihrer Instanz angegebene Telefonnummer an den Telefonieeingangspunkt der Connect Customer Instance weitergeleitet. Sie können eine Telefonnummer direkt bei Connect Customer reservieren, Ihre bestehende Telefonnummer portieren oder Sprachkontakte an Connect Customer weiterleiten. Der Connect-Kunde kann in allen Regionen, in denen der Dienst unterstützt wird, lokale und gebührenfreie Nummern bereitstellen.
Wenn ein Telefonanruf an eine Nummer getätigt wird, die in Ihrer Connect Customer-Instance beansprucht oder auf diese portiert wurde, wird der Flow aufgerufen, der der angerufenen Nummer zugeordnet ist. Sie können den Flow mithilfe von Flowblöcken definieren, die sich ohne Programmierkenntnisse konfigurieren lassen. Der Flow gibt vor, wie der Kontakt verarbeitet und weitergeleitet werden soll, und fordert den Kontakt optional zur Eingabe zusätzlicher Informationen auf, die bei der Entscheidung über die Weiterleitung helfen können. Diese Attribute werden in den Kontaktdaten gespeichert und der Kontakt wird bei Bedarf mit allen während des Gesprächs erhobenen Anrufdetails und Transkripten an Kundendienstmitarbeiter weitergeleitet. Über den Ablauf können Sie AWS Lambda Funktionen aufrufen, um Kundeninformationen abzufragen, andere AWS Dienste wie Amazon Pinpoint anrufen, um SMS-Textnachrichten zu senden, und native AWS Serviceintegrationen wie Amazon Lex for NLU/NLP und Kinesis Video Streams für das Echtzeit-Streaming von Sprachanrufen verwenden.
Wenn ein eingehender Kontakt Kundendienstmitarbeiter erreichen muss, wird der Kontakt in eine Warteschlange platziert und an Kundendienstmitarbeiter weitergeleitet, wenn diese ihren Status auf „Verfügbar“ ändern, entsprechend Ihrer Weiterleitungskonfiguration. Wenn der Kontakt des verfügbaren Agenten manuell oder über die Konfiguration für die automatische Annahme akzeptiert wird, verbindet Connect Customer den Kontakt mit dem Agenten.
Wenn ein eingehender Kontakt von einer Browser- oder mobilen App-Anfrage für eine Chat-Sitzung kommt, wird die Anfrage an einen Webservice oder einen Amazon API Gateway-Endpunkt weitergeleitet, der die Connect Customer Chat-API aufruft, um den in Ihrer Anfrage konfigurierten Ablauf aufzurufen. Sie können dieselben Flows für Chats und Sprachanrufe verwenden, wobei die Nutzung auf Grundlage der im Flow definierten Logik dynamisch verwaltet und weitergeleitet wird.
Ausgehend
Mit Connect Customer können Sie programmgesteuert ausgehende Kontaktversuche mit lokalen und internationalen Endpunkten durchführen, die Zeit für die Einrichtung von Agenten zwischen Kontakten verkürzen und die Produktivität der Agenten verbessern. Mithilfe der Connect Customer Streams
Für ausgehende Kampagnen werden in der Regel Kontaktdaten verwendet, die aus CRMs exportiert und in Kontaktlisten aufgeteilt werden. Diese Kontakte werden priorisiert und entweder nach einer Vorschauphase an die Agenten zur Initiierung weitergeleitet oder programmgesteuert über die Connect Customer Outbound API kontaktiert, gesteuert von Ihrer Ablauflogik, und stellen bei Bedarf eine Verbindung zu Agenten her. Zu den typischen Anwendungsfällen von Contact Centern mit ausgehenden Kontakten gehören Betrugs- und Servicemitteilungen, Erhebungen und Terminbestätigungen.
Verwenden Sie den folgenden CLI-Befehl, um einen ausgehenden Anruf an einen Kunden zu tätigen und den angegebenen Flow auszuführen. AWS Die Zieltelefonnummer muss ein E.164 Format haben. Sie müssen entweder eine Quelltelefonnummer oder eine Warteschlange angeben. Wenn Sie keine Warteschlange angeben, verwendet der ausgehende Kontakt die in diesem Flow definierte Warteschlange.
Ersetzen Sie im folgenden Befehl die Telefonnummernwerte instance-id durch Ihre eigenen Werte. aws-region Der contact-flow-id--source-phone-number Parameter ist optional, wenn Sie eine Warteschlange im Flow angeben.
aws connect start-outbound-voice-contact \ --instance-id "instance-id" \ --contact-flow-id "contact-flow-id" \ --destination-phone-number "+15551234567" \ --source-phone-number "+15557654321" \ --region "aws-region"
Bei Erfolg gibt der Befehl den Wert ContactId des neuen Kontakts zurück:
{ "ContactId": "00000000-0000-0000-0000-000000000000" }
Hybrid
Wenn Sie Kontakte zwischen Connect Customer und älteren Contact-Center-Technologien übertragen müssen, können Sie eine hybride Modellarchitektur verwenden, um die Kontaktdaten bei der Übertragung weiterzuleiten. Beispielsweise muss eine Vertriebsabteilung auf einer älteren Contact-Center-Plattform möglicherweise einen Anruf an die Servicegeschäftseinheit weiterleiten, die zu Connect Customer migriert wurde. Ohne eine Hybridarchitektur gehen die Anrufdetails verloren und der Kontakt muss die Informationen möglicherweise wiederholen. Dies könnte die Bearbeitungszeiten verlängern und dazu führen, dass der Kontakt erneut aus demselben Grund anruft.
Bei Hybridarchitekturen müssen Sie so viele Telefonnummern angeben, wie Sie voraussichtlich die maximale Anzahl gleichzeitiger Kontakte haben. Außerdem gibt es eine zwischengeschaltete Datenbank, auf die sowohl Connect Customer als auch Ihre alte Contact-Center-Plattform zugreifen können. Wenn eine Weiterleitung auf die andere Plattform erforderlich ist, verwenden Sie eine dieser Telefonnummern als eindeutige Kennung, kennzeichnen sie in Ihrer Zwischendatenbank als verwendet, fügen Ihre Kontaktdaten ein und verwenden diese Nummer als Ihre ANI- oder DNIS-Nummer, wenn Sie den Kontakt weiterleiten. Wenn der Kontakt auf der anderen Contact-Center-Plattform eingegangen ist, fragen Sie die Kontaktdaten auf Grundlage der eindeutigen ANI- oder DNIS-Nummer, die Sie verwendet haben, von der Zwischendatenbank ab. Hybride Architekturen kommen aufgrund der damit verbundenen zusätzlichen Kosten und Komplexität in der Regel als Zwischenschritt bei der Migration zum Einsatz.
IVR-only
Sie könnten sich dafür entscheiden, Connect Customer zu verwenden, um das IVR-Erlebnis des Kontakts zu verbessern, während die Anzahl Ihrer Agenten auf Ihrer alten Contact-Center-Plattform verbleibt. Bei diesem Ansatz können Sie Connect Customer Flows verwenden, um die Self-Service- und Routing-Logik zu steuern und den Kontakt bei Bedarf an den Zielagenten oder die Agenten-Warteschlange auf Ihrer alten Contact-Center-Plattform weiterzuleiten.
In diesem Diagramm wählt der Kontakt eine Telefonnummer, die in Ihrer Connect Customer-Instanz für den Service beansprucht wird. Wenn sie an einen Agenten auf Ihrer alten Contact-Center-Plattform weitergeleitet werden müssen, wird eine AWS Lambda Funktion aufgerufen, um eine verfügbare eindeutige Telefonnummer abzufragen, sie als aktuell zu kennzeichnen und relevante Kontaktdaten in eine Vermittlerdatenbank zu schreiben. Der Kontakt wird dann mit der von der Lambda-Funktion zurückgegebenen Telefonnummer an die alte Contact-Center-Plattform weitergeleitet. Das alte Contact Center fragt dann die Kontaktdaten von der Zwischendatenbank ab, nimmt eine entsprechende Weiterleitung vor und setzt die Kontaktdaten in der Zwischendatenbank zurück, sodass die Telefonnummer wieder verwendet werden kann.
Agent-only
Bei diesem Ansatz steuert Ihre herkömmliche Kontaktcenter-IVR die IVR-Self-Service- und Routing-Logik des Kontakts und leitet den Kontakt bei Bedarf an Connect Customer weiter, um ihn an Ihren Agentenstamm weiterzuleiten.
In diesem Diagramm wählt der Kontakt eine Telefonnummer, die mit Ihrer alten Contact-Center-Plattform beansprucht wurde. Wenn sie an einen Agenten auf Connect Customer weitergeleitet werden müssen, fragt die herkömmliche Contact-Center-Plattform eine verfügbare eindeutige Telefonnummer ab, kennzeichnet sie als in Gebrauch und schreibt relevante Kontaktdaten in eine Vermittlerdatenbank. Der Kontakt wird dann mit der Telefonnummer, die bei der Anfrage des alten Kontaktzentrums zurückgegeben wurde, an Connect Customer weitergeleitet. Der Connect-Kunde fragt dann die Kontaktdaten aus der Vermittlerdatenbank ab AWS Lambda, leitet sie entsprechend weiter und setzt die Kontaktdaten in der Vermittlerdatenbank zurück, sodass die Telefonnummer erneut verwendet werden kann.
Gemischt
In diesem Szenario arbeiten Ihr IVR und Ihre Agenten möglicherweise parallel auf Connect Customer und Ihrer alten Contact-Center-Plattform, um Migrationen von Standorten, Agentengruppen oder Geschäftsbereichen zu ermöglichen.
Migration alter Contact Center
Wenn Sie Connect Customer für neue oder bestehende Workloads evaluieren, können Sie verschiedene Strategien in Betracht ziehen. In Situationen, in denen Kontaktdaten bei der Übertragung von Kontakten zwischen Connect Customer und Ihrer alten Contact-Center-Lösung angegeben werden müssen, ist eine hybride Modellarchitektur erforderlich, bis die Migration abgeschlossen ist. Mit den in diesem Abschnitt beschriebenen Ansätzen können Sie bestimmte Geschäftsbereiche phasenweise verlagern, Schulungen und Support verwalten und die mit Änderungen verbundenen Risiken minimieren.
Neuer Workload
Sie können das Risiko verringern, das mit Änderungen in bestehenden Geschäftsbereichen verbunden ist, und die Flexibilität und das Potenzial für digitale Innovationen erhöhen, indem Sie eine neue Arbeitslast für Connect Customer einführen. Neue Nettoworkloads, für die die Architektur des hybriden Modells nicht erforderlich ist, sind weniger komplex, werden nicht durch Änderungen des Geschäftsprozesses oder der Kundendienstmitarbeiterroutine beeinträchtigt und ermöglichen eine schnellere Markteinführung. Durch die Einführung einer neuen Netto-Workload können Sie von nutzungsabhängigen Preisen mit nutzungsabhängiger Bezahlung profitieren. Ihre Contact-Center-Ressourcen sind verfügbar, um neue Nutzungsmöglichkeiten für ihre Endbenutzer zu schaffen, sie zu testen und zu implementieren, um die Plattform zu evaluieren, Vertrauen zu gewinnen und die Fähigkeiten und operativen Mechanismen aufzubauen, um sich auf eine größere Migration zwischen bestehenden Workloads vorzubereiten.
Priorisieren von IVR
Sie könnten sich dafür entscheiden, Connect Customer zu verwenden, um das IVR-Erlebnis des Kontakts zu verbessern, während die Anzahl Ihrer Agenten auf Ihrer alten Contact-Center-Plattform verbleibt. Bei diesem Ansatz können Sie Connect Customer Flows verwenden, um die Self-Service- und Routing-Logik zu steuern und den Kontakt bei Bedarf an den Zielagenten oder die Agenten-Warteschlange auf Ihrer alten Contact-Center-Plattform weiterzuleiten.
IVR mit niedrigster Priorität
Bei diesem Ansatz steuert Ihre herkömmliche IVR im Contact Center die IVR-Self-Service- und Routing-Logik des Kontakts und leitet den Kontakt bei Bedarf an Connect Customer weiter, um ihn an Ihren Agentenstamm weiterzuleiten.
Segmentierung von Geschäftsbereichen
Wenn Ihre Geschäftsbereiche über separate IVRs verfügen oder keine Kontaktweiterleitung auf ältere Contact-Center-Plattformen erforderlich ist, sollten Sie möglicherweise einen branchenspezifischen Migrationsansatz in Betracht ziehen. So können Sie beispielsweise Ihren Service Desk für internen Support als ersten Geschäftsbereich für die Migration auswählen. Nachdem Sie Ihre Service Desk-IVR und die Anzahl Ihrer Agenten auf Connect Customer migriert haben, können Sie Ihren bestehenden Kontakt an Connect Customer weiterleiten und den Endpunkt nach Abschluss der Tests und der Geschäftsvalidierung portieren.
Segmentierung von Standorten oder Kundendienstmitarbeitergruppen
Wenn Ihr Kontaktzentrum über eine globale Präsenz verfügt, Ansprechpartner aus mehreren Ländern betreut oder unabhängig von einer bestimmten Region oder einem Standort verwaltet wird, sollten Sie einen Migrationsansatz in Betracht ziehen, der auf einem physischen Standort oder der geografischen Verteilung der Agenten basiert. Jeder Kundenstamm oder jede Region kann ihre eigenen Anforderungen und Überlegungen haben, die möglicherweise nicht weltweit gelten. Wenn Sie diesen Ansatz für Ihre Migration wählen, kann jeder Standort oder jede Gruppe von Kundendienstmitarbeitern die Fähigkeiten erwerben, die sie für einen unabhängigen Betrieb benötigen, bevor sie mit dem nächsten Standort oder der nächsten Gruppe fortfahren.
Virtual Desktop Infrastructure (VDI)
Sie können das Connect Customer Contact Control Panel (CCP) zwar in einer Virtual Desktop Infrastructure (VDI) -Umgebung verwenden, Ihre Lösung wird dadurch jedoch noch komplexer, sodass separate POC-Maßnahmen und Leistungstests zur Optimierung erforderlich sind. Die configuration/support /optimierung wird am besten von Ihrem VDI-Supportteam durchgeführt. Die folgenden Bereitstellungsmodelle werden am häufigsten implementiert.
VDI-Client mit lokalem Browserzugriff
Sie können ein benutzerdefiniertes CCP mit der Connect Customer Streams
Citrix VDI mit Connect Customer — Audiooptimierung
Wenn Sie die Citrix Virtual Desktop Infrastructure (VDI) -Umgebung verwenden, können Sie ein benutzerdefiniertes CCP mit der Connect Customer JavaScript RTC-Bibliothek erstellen, die in das Citrix United Communications SDK (ucsdk) integriert ist und die Medien automatisch von Ihrem lokalen Desktop an Connect Customer umleitet. Auf diese Weise können Ihre Kundendienstmitarbeiter Citrix–VDI-Clientanwendungen wie Citrix Workspaces verwenden, um eine Verbindung zu ihren benutzerdefinierten Kundendienstmitarbeiteranwendungen oder benutzerdefinierten CCPs herzustellen. Dadurch entfällt die Notwendigkeit, eine separate Kundendienstmitarbeiteranwendung wie Dual-CCPs für die Audiomedienumleitung für ihre Citrix-Umgebungen zu entwickeln und zu verwalten. Dieser Ansatz wird auf dem folgenden Diagramm dargestellt:
Anmerkung
Für diese Lösung müssen Sie den WebRTC-Signalverkehr zwischen Ihrem VDI-Server und Connect Customer sowie die Medienverbindung zwischen dem Desktop des Agenten und Connect Customer zulassen. Weitere Informationen finden Sie in der Dokumentation zu Richten Sie Ihr Netzwerk für die Verwendung des Connect Customer Contact Control Panels (CCP) ein.
Amazon WorkSpaces VDI mit Connect Customer-Audiooptimierung
Mithilfe von Amazon WorkSpaces, einer Virtual Desktop Infrastructure (VDI) -Umgebung, haben Sie die Möglichkeit, mithilfe der Connect Customer Real-Time Communications (RTC) -Bibliothek ein benutzerdefiniertes Contact Control Panel (CCP) zu erstellen. JavaScript Diese Bibliothek lässt sich nahtlos in das Amazon WorkSpaces SDK integrieren und ermöglicht die automatische Medienumleitung von Ihrem lokalen Desktop zu Connect Customer. Dadurch entfällt die Notwendigkeit, eine separate Agentenanwendung, wie z. B. Dual-CCPS, speziell für die Umleitung von Audiomedien in ihren Umgebungen zu entwickeln und zu verwalten. WorkSpaces Das folgende Diagramm veranschaulicht diesen Ansatz.
Omnissa VDI mit Connect Customer — Audiooptimierung
Die Omnissa Virtual Desktop Infrastructure (VDI) -Lösung ermöglicht eine optimierte Integration mit Connect Customer durch die Implementierung eines benutzerdefinierten Contact Control Panels (CCP).
Durch die Verwendung der Connect Customer JavaScript RTC-Bibliothek in Verbindung mit dem Horizon WebRTC SDK von Omnissa wird die Audioverarbeitung optimiert, indem Medienstreams direkt vom lokalen Endpunkt des Agenten zum Connect Customer umgeleitet werden. Diese Architektur eliminiert die traditionellen Herausforderungen bei der Audioweiterleitung über virtuelle Desktops und bietet Kundendienstmitarbeitern ein hervorragendes Spracherlebnis bei der Nutzung ihrer Omnissa-VDI-Umgebung. Die Lösung beseitigt die Komplexität der Verwaltung separater Anwendungen für die Audioumleitung und bietet eine einzige, einheitliche Oberfläche für Kundendienstmitarbeiter-Interaktionen. Das folgende Diagramm veranschaulicht diesen Architekturansatz.
Azure Virtual Desktop und Windows 365 VDI mit Connect Customer-Audiooptimierung
Wenn Ihre Agenten Azure Virtual Desktop (AVD) oder Windows 365 Cloud PC verwenden, können Sie die Audiowiedergabe von Connect Customer mit Microsoft Multimedia Redirection (MMR) optimieren. Für diesen Ansatz ist kein plattformspezifisches SDK in Ihrem CCP erforderlich. Die MMR-Browsererweiterung leitet die Standard-WebRTC-Medien transparent vom Sitzungshost zum lokalen Gerät des Agenten weiter, wo eine direkte Verbindung mit Connect Customer hergestellt wird. Das lokale Gerät des Agenten verarbeitet Audio und nicht der Sitzungshost. Dadurch werden Netzwerksprünge reduziert und die Audioqualität verbessert. Das folgende Diagramm veranschaulicht diesen Ansatz.
VDI-Client ohne lokalen Browserzugriff
Manchmal hat der VDI-Client keinen Zugriff auf einen lokalen Browser. In diesem Szenario können Sie eine einzelne CCP-Instance mit Medien erstellen, die vom VDI-Server ausgeführt wird und den Zugriff auf Unternehmensressourcen ermöglicht. Für dieses Bereitstellungsmodell ist im VDI-Betriebssystem normalerweise UDP-Audio aktiviert. Für dieses Bereitstellungsmodell sind umfangreiche Tests erforderlich, um die verschiedenen VDI-Serverparameter zu kalibrieren und so die Nutzung zu optimieren: