Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Scenari e approcci di distribuzione in Connect Customer

Connect Customer offre una configurazione self-service e consente un coinvolgimento dinamico, personale e naturale dei clienti su qualsiasi scala con una varietà di opzioni di migrazione e integrazione. In questa sezione, spieghiamo i seguenti scenari e approcci di implementazione da considerare quando si progetta un carico di lavoro per Connect Customer:

Contact center tradizionale

Il contact center tradizionale richiede un'impronta di carbonio significativa dell'infrastruttura di telefonia, supporto, rete, database ed elaborazione, che può estendersi a diversi fornitori e ubicazioni di data center per gestire i contatti. Ogni singola soluzione e fornitore dispongono di requisiti hardware, software, di rete e architetturali univoci che devono essere soddisfatti risolvendo al contempo i conflitti di controllo delle versioni, compatibilità e licenza.

È comune avere fornitori e requisiti di infrastruttura separati per l'hardware degli agenti locali e remoti e la connettività VPN Text-To-Speech (TTS), la distribuzione automatica delle chiamate (ACD), la risposta vocale interattiva (IVR), l'audio e i dati vocali, i telefoni fissi fisici, la registrazione vocale, le trascrizioni vocali, la chat, la reportistica, il database, l'integrazione della telefonia computerizzata (CTI), il riconoscimento vocale automatico (ASR) e la comprensione del linguaggio naturale (NLP). L'architettura e l'infrastruttura del contact center diventano più complesse se si considera lo sviluppo in più fasi, il controllo della qualità e gli ambienti di test.

Una tipica implementazione di Connect Customer risolve o riduce molte delle sfide associate al controllo delle versioni, alla compatibilità, alle licenze, all'infrastruttura di telefonia dei contact center e alla manutenzione. Offre la flessibilità necessaria per creare istanze in nuove ubicazioni in pochi minuti e migrare i componenti singolarmente o in parallelo per soddisfare al meglio gli obiettivi aziendali individuali. Puoi utilizzare i flussi per te IVR/ACD, far recapitare voce e dati tramite un browser Web supportato al softphone del tuo agente, trasferire i numeri di telefono esistenti, reindirizzare l'audio del softphone su un telefono fisso esistente, richiamare un bot Amazon Lex in modo nativo all'interno del tuo flusso per ASR e PNL e utilizzare lo stesso flusso per chat e voce. Puoi utilizzare l'analisi conversazionale di Connect Customer per generare automaticamente trascrizioni vocali, eseguire l'identificazione delle parole chiave e l'analisi del sentiment e classificare i contatti. Per i dati CTI degli agenti e lo streaming vocale in tempo reale, puoi utilizzare Connect Customer Agent Event Streams e Kinesis Video Streams. Puoi anche creare ambienti di sviluppo, controllo qualità e test a più fasi senza costi aggiuntivi e pagando solo per ciò che usi.

In entrata

Inbound è un termine utilizzato da un contact center per descrivere una richiesta di comunicazione al contact center avviata da un contatto. I contatti possono contattare la tua istanza Connect Customer per un self-service in entrata o per parlare con un agente dal vivo in vari modi, tra cui voce e chat. I contatti vocali passano attraverso la rete PSTN e vengono indirizzati al punto di ingresso telefonico Connect Customer Instance tramite il numero di telefono indicato nell'istanza. È possibile prenotare un numero di telefono direttamente con Connect Customer, trasferire il numero di telefono esistente o inoltrare i contatti vocali a Connect Customer. Connect Customer può fornire numeri locali e gratuiti in tutte le regioni in cui il servizio è supportato.

Quando viene effettuata una telefonata a un numero richiesto o trasferito all'istanza Connect Customer, viene richiamato il flusso associato al numero chiamato. Puoi definire il flusso mediante blocchi di flusso che possono essere configurati senza che siano necessarie conoscenze di scrittura del codice. Il flusso determina il modo in cui il contatto deve essere elaborato e indirizzato, facoltativamente richiedendo al contatto ulteriori informazioni per aiutarlo nelle decisioni di instradamento, archiviando tali attributi nei dettagli del contatto e, se necessario, inoltrando il contatto a un agente con tutti i dettagli e le trascrizioni della chiamata raccolti lungo il percorso. Attraverso il flusso, puoi richiamare AWS Lambda funzioni per richiedere informazioni sui clienti, chiamare altri AWS servizi come Amazon Pinpoint per inviare messaggi di testo SMS e utilizzare integrazioni di AWS servizi native tra cui Amazon Lex for NLU/NLP e Kinesis Video Streams per lo streaming in tempo reale delle chiamate vocali.

Se un contatto inbound deve raggiungere un agente, il contatto viene inserito in una coda e indirizzato a un agente quando il suo stato passa a Disponibile, in base alla configurazione di routing. Quando il contatto dell'agente disponibile viene accettato manualmente o tramite la configurazione di accettazione automatica, Connect Customer collega il contatto con l'agente.

Quando un contatto in entrata proviene da un browser o da un'app mobile per una richiesta di sessione di chat, la richiesta viene indirizzata a un servizio Web o a un endpoint Amazon API Gateway che chiama l'API di chat Connect Customer per richiamare il flusso configurato nella richiesta. Puoi utilizzare gli stessi flussi per chat e voce, in cui l'esperienza viene gestita e indirizzata in modo dinamico, in base alla logica definita nel flusso.

In uscita

Con Connect Customer, puoi effettuare in modo programmatico tentativi di contatto in uscita verso endpoint locali e internazionali, ridurre i tempi di configurazione degli agenti tra i contatti e migliorare la produttività degli agenti. Utilizzando l'API Connect Customer Streams StartOutboundVoiceContact, puoi sviluppare la tua soluzione in uscita o sfruttare le integrazioni dei partner esistenti che funzionano con i tuoi dati CRM per creare esperienze dinamiche e personalizzate per i tuoi contatti e fornire ai tuoi agenti gli strumenti e le risorse di cui hanno bisogno per fornire assistenza a tali contatti.

Le campagne outbound sono in genere basate sui dati dei contatti esportati dai sistemi CRM e separati in elenchi di contatti. A questi contatti viene assegnata la priorità e vengono consegnati agli agenti per avviarli dopo un periodo di anteprima o contattati a livello di programmazione utilizzando l'API Connect Customer Outbound, guidata dalla logica di flusso e connettendosi agli agenti secondo necessità. I tipici casi d'uso dei contact center outbound includono avvisi di frode e assistenza, riscossioni e conferme di appuntamenti.

Per effettuare una chiamata in uscita a un cliente ed eseguire il flusso specificato, utilizza il seguente comando CLI. AWS Il numero di telefono di destinazione deve essere in E.164 formato. È necessario specificare un numero di telefono di origine o una coda. Se non specifichi una coda, il contatto in uscita utilizza la coda definita in quel flusso.

Nel comando seguenteinstance-id, contact-flow-id sostituisci i valori dei numeri di telefono e aws-region con i tuoi valori. Il --source-phone-number parametro è facoltativo se si specifica una coda nel flusso.

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"

In caso di successo, il comando restituisce il valore ContactId del nuovo contatto:

{
    "ContactId": "00000000-0000-0000-0000-000000000000"
}

Ibrido

Se hai bisogno di trasferire i contatti tra Connect Customer e le tecnologie precedenti dei contact center, puoi utilizzare un'architettura a modello ibrido per trasferire i dati di contatto con il trasferimento. Ad esempio, un'unità aziendale di vendita su una piattaforma di contact center precedente potrebbe dover trasferire una chiamata alla business unit di assistenza che è stata migrata a Connect Customer. Senza un'architettura ibrida, i dettagli della chiamata andranno persi e potrebbe essere necessario che il contatto ripeta le informazioni. Ciò potrebbe aumentare i tempi di gestione e comportare una nuova chiamata di contatto per lo stesso scopo.

Le architetture ibride richiedono di richiedere tanti numeri di telefono quanti sono i contatti simultanei massimi previsti e un database di stato intermedio accessibile sia da Connect Customer che dalla piattaforma di contact center esistente. Quando è necessario un trasferimento verso l'altra piattaforma, userai uno di questi numeri di telefono come identificatore univoco, lo contrassegnerai come in uso nel database intermedio, inserirai i dettagli del contatto e utilizzerai quel numero come ANI o DNIS quando trasferisci il contatto. Quando il contatto viene ricevuto dall'altra piattaforma di contact center, richiederai al database intermedio i dettagli del contatto in base all'ANI o DNIS univoco che hai utilizzato. Le architetture ibride vengono in genere utilizzate come passaggio di migrazione provvisoria a causa dei costi e della complessità aggiuntivi associati.

IVR-only

Potresti scegliere di utilizzare Connect Customer per migliorare l'esperienza IVR del contatto mentre il numero di agenti rimane sulla tua piattaforma di contact center precedente. Con questo approccio, è possibile utilizzare i flussi Connect Customer per gestire la logica self-service e di routing e, se necessario, trasferire il contatto all'agente o alla coda degli agenti di destinazione sulla piattaforma di contact center esistente.

In questo diagramma, il contatto compone un numero di telefono richiesto dall'istanza Connect Customer per l'assistenza. Se devono essere trasferiti a un agente sulla vostra piattaforma di contact center precedente, viene richiamata una AWS Lambda funzione per richiedere un numero di telefono univoco disponibile, contrassegnarlo come in uso e scrivere i dati di contatto pertinenti in un database degli intermediari. Il contatto viene quindi trasferito alla piattaforma di contact center legacy con il numero di telefono restituito dalla funzione Lambda. Il contact center legacy eseguirà quindi una query sul database intermedio per recuperare i dati del contatto, indirizzerà il contatto di conseguenza e ripristinerà i dati del contatto nel database intermedio per consentire di riutilizzare il numero di telefono.

Agent-only

Con questo approccio, l'IVR del contact center precedente gestisce la logica di routing e self-service dell'IVR del contatto e, se necessario, trasferisce il contatto a Connect Customer per indirizzarlo alla popolazione di agenti del cliente.

In questo diagramma, il contatto compone un numero di telefono rivendicato dalla piattaforma di contact center legacy. Se devono essere trasferiti a un agente su Connect Customer, la precedente piattaforma di contact center richiederà un numero di telefono univoco disponibile, lo contrassegnerà come in uso e scriverà i dati di contatto pertinenti in un database degli intermediari. Il contatto verrà quindi trasferito a Connect Customer con il numero di telefono restituito dalla richiesta del precedente contact center. Connect Customer interrogherà quindi i dati di contatto dal database degli intermediari utilizzando AWS Lambda, indirizzando di conseguenza e reimpostando i dati di contatto nel database degli intermediari, consentendo di utilizzare nuovamente il numero di telefono.

Misto

In questo scenario, è possibile che l'IVR e gli agenti operino in parallelo su Connect Customer e sulla piattaforma di contact center esistente per consentire le migrazioni del sito, del gruppo di agenti o delle linee di business.

Migrazione del contact center legacy

Quando si valuta Connect Customer per carichi di lavoro nuovi o esistenti, è possibile prendere in considerazione diverse strategie. Per le situazioni che richiedono l'inclusione dei dati di contatto quando i contatti vengono trasferiti tra Connect Customer e la soluzione di contact center esistente, sarà necessaria un'architettura modello ibrido fino al completamento della migrazione. Con gli approcci descritti in questa sezione, è possibile spostare specifiche linee di business in più fasi, gestire la formazione e il supporto e mitigare i rischi associati al cambiamento.

Nuovo carico di lavoro

È possibile ridurre i rischi associati alle modifiche alle unità aziendali esistenti e aumentare la flessibilità e il potenziale di innovazione digitale adottando un nuovo carico di lavoro netto su Connect Customer. I nuovi carichi di lavoro netti che non richiedono l'architettura del modello ibrido sono meno complessi, non sono influenzati dai cambiamenti nei processi aziendali o nella routine degli agenti e offrono un time-to-market più rapido. L'adozione di un nuovo carico di lavoro netto ti aiuta a sfruttare i prezzi basati sull'utilizzo e con pagamento in base al consumo. Le risorse del tuo contact center sono disponibili per creare una nuova esperienza per gli utenti finali, testarla e implementarla per valutare la piattaforma, acquisire fiducia e sviluppare le competenze e i meccanismi operativi necessari per prepararsi a una migrazione più ampia dei carichi di lavoro esistenti.

IVR First

Potresti scegliere di utilizzare Connect Customer per migliorare l'esperienza IVR del contatto mentre il numero di agenti rimane sulla tua piattaforma di contact center precedente. Con questo approccio, potete utilizzare Connect Customer Flows per promuovere la logica self-service e di routing e, se necessario, trasferire il contatto all'agente o alla coda degli agenti di destinazione sulla vostra piattaforma di contact center precedente.

IVR Last

Con questo approccio, l'IVR del vostro contact center precedente gestisce la logica di routing e self-service dell'IVR del contatto e, se necessario, trasferisce il contatto a Connect Customer per indirizzarlo alla vostra popolazione di agenti.

Segmentazione per linea di business

Se le vostre linee di business hanno IVR separati o non richiedono il trasferimento dei contatti su piattaforme di contact center precedenti, potreste prendere in considerazione un approccio alla migrazione delle linee di business. Ad esempio, selezionando il service desk per il supporto interno come prima linea di business da migrare. Dopo aver migrato l'IVR del service desk e il numero di agenti su Connect Customer, potresti scegliere di inoltrare il contatto esistente a Connect Customer, trasferendo l'endpoint dopo il completamento dei test e della convalida aziendale.

Segmentazione per sito o gruppo di agenti

Se il vostro contact center ha una presenza globale, serve contatti da più Paesi o è gestito in modo indipendente da una rispettiva area geografica o ubicazione, potreste prendere in considerazione un approccio di migrazione basato su un sito fisico o sulla geografia degli agenti. Ogni popolazione o area geografica di agenti può avere requisiti e considerazioni specifici che potrebbero non essere applicabili a livello globale. Questo approccio alla migrazione consentirà a ciascun sito o gruppo di agenti di acquisire le competenze necessarie per continuare a operare in modo indipendente prima di passare a quello successivo.

Infrastruttura desktop virtuale (VDI)

Sebbene sia possibile utilizzare il Connect Customer Contact Control Panel (CCP) all'interno di ambienti VDI (Virtual Desktop Infrastructure), aggiungerà un ulteriore livello di complessità alla soluzione che richiede sforzi POC separati e test delle prestazioni per l'ottimizzazione. L' configuration/supportottimizzazione viene gestita al meglio dal team di supporto VDI e i seguenti modelli di implementazione sono i più comunemente implementati.

Client VDI con accesso al browser locale

Puoi creare un CCP personalizzato con l'API Connect Customer Streams creando un CCP senza supporti per la segnalazione delle chiamate. In questo modo, i file multimediali vengono gestiti sul desktop locale utilizzando lo standard CCP. La segnalazione e i controlli delle chiamate vengono gestiti tramite la connessione remota con il CCP senza supporti. Il diagramma seguente descrive questo approccio.

Ottimizzazione audio Citrix VDI con Connect Customer

Se utilizzate l'ambiente Citrix Virtual Desktop Infrastructure (VDI), potete creare un CCP personalizzato con la JavaScript libreria RTC Connect Customer che si integra con Citrix United Communications SDK (ucsdk) e reindirizza automaticamente i file multimediali dal desktop locale a Connect Customer. Ciò consente agli agenti di utilizzare le applicazioni client Citrix VDI, come Citrix Workspaces, per connettersi alle applicazioni agente personalizzate o ai CCP personalizzati. Ciò elimina la necessità di sviluppare e gestire un'applicazione agente separata, come dual-CCP, per il reindirizzamento dei contenuti multimediali audio per gli ambienti Citrix. Il diagramma seguente descrive questo approccio:

Amazon WorkSpaces VDI con Connect Customer: ottimizzazione audio

Utilizzando Amazon WorkSpaces, un ambiente VDI (Virtual Desktop Infrastructure), hai la possibilità di creare un Contact Control Panel (CCP) personalizzato utilizzando la libreria Connect Customer Real-Time Communications (RTC). JavaScript Questa libreria si integra perfettamente con l'Amazon WorkSpaces SDK, consentendo il reindirizzamento automatico dei file multimediali dal desktop locale a Connect Customer. Ciò elimina la necessità di sviluppare e gestire un'applicazione agente separata, ad esempio Dual-CCP, specifica per il reindirizzamento dei file multimediali audio all'interno dei rispettivi ambienti. WorkSpaces Il diagramma seguente illustra questo approccio.

Omnissa VDI con ottimizzazione audio Connect Customer

La soluzione Omnissa Virtual Desktop Infrastructure (VDI) consente un'integrazione semplificata con Connect Customer attraverso l'implementazione di un Contact Control Panel (CCP) personalizzato.

Utilizzando la JavaScript libreria RTC Connect Customer insieme all'SDK Horizon WebRTC di Omnissa, l'elaborazione audio è ottimizzata reindirizzando i flussi multimediali direttamente dall'endpoint locale dell'agente a Connect Customer. Questa architettura elimina le sfide tradizionali di instradamento dell’audio attraverso desktop virtuali, offrendo agli agenti un’esperienza vocale superiore durante l’utilizzo dell’ambiente Omnissa VDI. La soluzione elimina la complessità della gestione di applicazioni di reindirizzamento audio separate, offrendo una singola interfaccia unificata per le interazioni tra agenti. Il diagramma seguente illustra questo approccio a livello di architettura.

Azure Virtual Desktop e Windows 365 VDI con ottimizzazione audio Connect Customer

Se i tuoi agenti utilizzano Azure Virtual Desktop (AVD) o Windows 365 Cloud PC, puoi ottimizzare l'audio di Connect Customer con Microsoft Multimedia Redirection ()MMR. Questo approccio non richiede un SDK specifico per la piattaforma nel tuo CCP. L'estensione del browser MMR reindirizza in modo trasparente i contenuti multimediali WebRTC standard dall'host della sessione al dispositivo locale dell'agente, dove si connette direttamente a Connect Customer. Il dispositivo locale dell'agente elabora l'audio anziché l'host della sessione, il che riduce i salti di rete e migliora la qualità audio. Il diagramma seguente illustra questo approccio.

Client VDI senza accesso al browser locale

In alcuni casi, il client VDI non ha accesso a un browser locale. In questo scenario è possibile creare una singola istanza del Pannello di controllo dei contatti con contenuti multimediali eseguiti dal server VDI che consente l'accesso alle risorse aziendali. Per questo modello di implementazione, l'audio UDP è in genere abilitato nel sistema operativo VDI. Questo modello di implementazione richiede test approfonditi per calibrare i diversi parametri del server VDI e ottimizzare la qualità dell'esperienza: