

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à.

# Scenario e approcci di implementazione in Connect Customer
<a name="scenario-deployment-approaches"></a>

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 durante la progettazione di un carico di lavoro per Connect Customer:
+ Contact center tradizionale
+ In entrata
+ In uscita
+ Contact center ibrido
+ Migrazione del contact center legacy
+ Infrastruttura desktop virtuale (VDI)

## Contact center tradizionale
<a name="traditional-contact-center"></a>

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 hardware e connettività VPN per agenti locali e remoti Text-To-Speech (TTS), Automatic Call Distribution (ACD), Interactive Voice Response (IVR), audio e dati vocali, telefoni fissi da tavolo, registrazione vocale, trascrizioni vocali, chat, reportistica, database, Computer Telephony Integration (CTI), Automatic Speech Recognition (ASR) e Natural Language Understanding (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. 

![Contact center tradizionale.](http://docs.aws.amazon.com/it_it/connect/latest/adminguide/images/architecture/traditionalcontactcenter.png)


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 tuoi 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 NLP e utilizzare lo stesso flusso per chat e voce. È possibile utilizzare Connect Customer Contact Lens per generare automaticamente trascrizioni vocali, eseguire l’identificazione delle parole chiave e l’analisi del sentiment e categorizzare 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
<a name="inbound"></a>

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 il 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 il PSTN e vengono indirizzati al punto di accesso telefonico Connect Customer Instance tramite il numero di telefono indicato nell'istanza. Puoi prenotare un numero di telefono direttamente con Connect Customer, trasferire il tuo 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.

![Un diagramma che mostra una richiesta in entrata al contact center avviata da un contatto.](http://docs.aws.amazon.com/it_it/connect/latest/adminguide/images/architecture/inbound.png)


Quando viene effettuata una telefonata a un numero dichiarato o trasferito sull'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 servizi AWS nativi tra cui Amazon Lex for e Kinesis Video Streams NLU/NLP per lo streaming in tempo reale di 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. 

![Un diagramma che mostra un contatto in entrata in una coda.](http://docs.aws.amazon.com/it_it/connect/latest/adminguide/images/architecture/inbound2.png)


 Quando un contatto in entrata proviene da un browser o da un'app mobile che richiede una 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
<a name="outbound"></a>

Connect Customer ti consente di 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](https://docs.aws.amazon.com/connect/latest/APIReference/API_StartOutboundVoiceContact.html)](https://github.com/aws/amazon-connect-streams), 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 servire tali contatti. 

Le campagne outbound sono in genere basate sui dati dei contatti esportati dai sistemi CRM e separati in elenchi di contatti. A tali contatti viene assegnata la priorità e possono essere inviati agli agenti per l'avvio dopo un periodo di anteprima oppure contattati programmaticamente utilizzando l'API Connect Customer Outbound, basata sulla 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.

## Ibrido
<a name="hybrid"></a>

Se hai bisogno di trasferire i contatti tra Connect Customer e le tecnologie legacy dei contact center, puoi utilizzare un'architettura di modello ibrido per trasmettere i dati di contatto durante il trasferimento. Ad esempio, un'unità aziendale di vendita su una piattaforma di contact center legacy potrebbe dover trasferire una chiamata all'unità aziendale di assistenza che è stata migrata a Connect Customer. Senza un'architettura ibrida, i dettagli della chiamata andrebbero persi e potrebbe essere necessario chiedere al contatto di ripetere le informazioni. I tempi di gestione si allungherebbero e il contatto potrebbe chiamare di nuovo per lo stesso motivo. 

Le architetture ibride richiedono di richiedere un numero di telefono pari al numero massimo di contatti simultanei previsto e un database di stato intermedio accessibile sia da Connect Customer che dalla piattaforma di contact center legacy. 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
<a name="ivr-only"></a>

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

![Un diagramma che mostra un’esperienza di risposta vocale interattiva di un cliente.](http://docs.aws.amazon.com/it_it/connect/latest/adminguide/images/architecture/hybridivr.png)


In questo diagramma, il contatto chiama un numero di telefono richiesto nell'istanza Connect Customer per ricevere assistenza. Se devono essere trasferiti a un agente sulla piattaforma di contact center esistente, viene richiamata una AWS Lambda funzione per richiedere un numero di telefono univoco disponibile, contrassegnarlo come in uso e scrivere i dettagli di contatto pertinenti in un database intermedio. 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
<a name="agent-only"></a>

Con questo approccio, l'IVR del contact center esistente gestisce la logica di routing e self-service IVR del contatto e, se necessario, trasferisce il contatto a Connect Customer per indirizzarlo al numero di agenti.

![Un diagramma che mostra un’esperienza riservata ai soli agenti.](http://docs.aws.amazon.com/it_it/connect/latest/adminguide/images/architecture/hybridagentonly.png)


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 piattaforma di contact center legacy richiederà un numero di telefono univoco disponibile, lo contrassegnerà come in uso e scriverà i dettagli di contatto pertinenti in un database intermedio. Il contatto verrà quindi trasferito a Connect Customer con il numero di telefono restituito dalla richiesta del contact center precedente. Connect Customer richiederà quindi i dati di contatto dal database dell'intermediario utilizzando AWS Lambda, indirizzerà di conseguenza e ripristinerà i dati di contatto nel database dell'intermediario, consentendo il riutilizzo del numero di telefono.

### Misto
<a name="mixed"></a>

In questo scenario, è possibile che l'IVR e gli agenti operino in parallelo su Connect Customer e sulla piattaforma di contact center legacy per consentire migrazioni di siti, gruppi di agenti o linee di business.

![Un diagramma che mostra un’esperienza ibrida di risposta vocale interattiva e riservata ai soli agenti.](http://docs.aws.amazon.com/it_it/connect/latest/adminguide/images/architecture/hybridmixed.png)


## Migrazione del contact center legacy
<a name="legacy-contact-center-migration"></a>

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 di modello ibrido fino al completamento della migrazione. Gli approcci descritti in questa sezione consentono di spostare linee di business specifiche fasi, gestire la formazione e il supporto e mitigare i rischi associati al cambiamento.

### Nuovo carico di lavoro
<a name="new-workload"></a>

È possibile ridurre il rischio associato 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 consente di sfruttare i vantaggi di 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
<a name="ivr-first"></a>

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

### IVR Last
<a name="ivr-last"></a>

Con questo approccio, l'IVR del contact center esistente gestisce la logica di routing e self-service IVR del contatto e, se necessario, trasferisce il contatto a Connect Customer per indirizzarlo al numero di agenti.

### Segmentazione per linea di business
<a name="lob-segmentation"></a>

Se le tue linee di business dispongono di sistemi IVR separati o non richiedono il trasferimento dei contatti verso piattaforme di contact center legacy, potresti valutare un approccio basato sulla 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 a Connect Customer, puoi 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
<a name="agent-segmentation"></a>

Se il tuo contact center ha un'impronta globale, fornisce servizi a contatti di più paesi o è gestito in modo indipendente da una rispettiva area geografica o ubicazione, potresti valutare un approccio alla migrazione basato su un sito fisico o un'area geografica di agenti. Ogni and/or area geografica di popolazione di agenti può avere requisiti e considerazioni unici 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)
<a name="vdi"></a>

Sebbene sia possibile utilizzare Connect Customer Contact Control Panel (CCP) negli ambienti Virtual Desktop Infrastructure (VDI), aggiungerà un altro livello di complessità alla soluzione che giustifica sforzi POC separati e test delle prestazioni per l'ottimizzazione. configuration/support/optimization 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
<a name="vdi-with-browser"></a>

Puoi creare un CCP personalizzato con l'API [Connect Customer Streams](https://github.com/aws/amazon-connect-streams) creando un CCP senza supporti per la segnalazione delle chiamate. In questo modo, il contenuto multimediale viene gestito dal desktop locale utilizzando il CCP standard e i controlli di segnalazione e delle chiamate vengono gestiti sulla connessione remota con il CCP senza alcun contenuto multimediale. Il diagramma seguente descrive questo approccio.

![Client VDI con accesso al browser locale.](http://docs.aws.amazon.com/it_it/connect/latest/adminguide/images/architecture/vdi.png)


### Ottimizzazione audio Citrix VDI con Connect Customer
<a name="vdi-citrix"></a>

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:

![Flusso di lavoro multimediale Connect Customer per ambienti Citrix VDI.](http://docs.aws.amazon.com/it_it/connect/latest/adminguide/images/vdi-citrix.png)


**Nota**  
Questa soluzione richiede di consentire il traffico di segnalazione WebRTC tra il server VDI e Connect Customer e la connessione multimediale tra il desktop dell'agente e Connect Customer. Per ulteriori informazioni, consulta la documentazione [Configura la tua rete per utilizzare il Connect Customer Contact Control Panel (CCP)](ccp-networking.md).

### Ottimizzazione audio di Amazon WorkSpaces VDI con Connect Customer
<a name="vdi-amazon-workspaces"></a>

Utilizzando Amazon WorkSpaces, un ambiente Virtual Desktop Infrastructure (VDI), 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 Amazon WorkSpaces SDK, abilitando il reindirizzamento automatico dei file multimediali dal desktop locale a Connect Customer. Ciò elimina la necessità di sviluppare e gestire un'applicazione agente separata, come Dual-CCP, specifica per il reindirizzamento dei media audio all'interno dei rispettivi ambienti. WorkSpaces Il diagramma seguente illustra questo approccio.

![Ambiente Connect Customer and Workspaces.](http://docs.aws.amazon.com/it_it/connect/latest/adminguide/images/vdi-connect.png)


### Omnissa VDI con ottimizzazione audio Connect Customer
<a name="vdi-omnissa"></a>

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 Connect Customer RTC in combinazione con Horizon WebRTC SDK 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.

![Connect Customer e ambiente Omnissa.](http://docs.aws.amazon.com/it_it/connect/latest/adminguide/images/omnissa-6.png)


### Client VDI senza accesso al browser locale
<a name="vdi-without-browser"></a>

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:

![Client VDI senza accesso al browser locale.](http://docs.aws.amazon.com/it_it/connect/latest/adminguide/images/architecture/vdinobrowser.png)
