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à.
Le migliori pratiche per progettare le basi di un'esperienza IVR dinamica e modulare su Amazon Connect
Ayesha Borker e Nicholas Pung, Amazon Web Services ()AWS
Agosto 2023 (cronologia dei documenti)
Gli architetti tecnici, gli sviluppatori e i team aziendali hanno l'opportunità di reimmaginare le esperienze self-service automatizzate che offrono ai propri clienti quando migrano a un contact center basato sul cloud utilizzando Amazon Connect.
I team aziendali in genere desiderano aggiungere funzionalità e caratteristiche rendendo l'esperienza self-service più personalizzata. Gli architetti tecnici e gli sviluppatori si concentrano principalmente su come ridurre la ridondanza, consentire cambiamenti rapidi e flessibilità, modularizzare i processi ripetuti e ridurre il sovraccarico di manutenzione.
Questa guida fornisce agli architetti tecnici una serie di best practice da utilizzare per creare il design di base della loro applicazione di risposta vocale interattiva (IVR) in modo modulare e dinamico. Fornisce esempi di sistemi IVR (ovvero tecnologie vocali). Tuttavia, è possibile estendere gli stessi concetti a qualsiasi altro canale. La guida si concentra sulla creazione di un design IVR modulare e scalabile utilizzando flussi e moduli Amazon Connect. Amazon Lex, che consente di aggiungere funzionalità di linguaggio naturale (NL) all'applicazione IVR, non rientra nell'ambito di applicazione.
Panoramica
I metodi tradizionali per la progettazione di esperienze IVR possono essere statici e complessi. Le organizzazioni spesso gestiscono esperienze separate per diverse lingue, ambienti di distribuzione (come sviluppo, test e produzione), paesi e linee di business (LOBs). Spesso si affidano ai talenti della voce umana per creare istruzioni, che vengono poi caricate e referenziate in script codificati. Ciò complica il processo di modifica e aggiornamento, soprattutto in tempo reale per emergenze o annunci urgenti. Quando le applicazioni vengono separate in questo modo, spesso osserviamo che i casi d'uso comuni si ripetono e vengono gestiti in modo ridondante. Gli esempi più comuni includono l'accettazione di pagamenti su un sistema IVR o l'invio di SMS dopo la transazione. Le integrazioni di backend con database, soluzioni CRM (Customer Relationship Management) o altri sistemi di terze parti sono spesso codificate, il che significa che le modifiche devono essere replicate manualmente su più applicazioni.
Questo tipo di architettura monolitica comporta processi amministrativi e costi di gestione eccessivi e ostacola l'innovazione. Gli sviluppatori dedicano più tempo all'implementazione di piccole modifiche su più dipendenze, il che rende difficile per loro seguire processi agili. Spesso, questa complessità diventa gravosa e le aziende devono affidarsi a organizzazioni di servizi professionali o consulenti esterni per gestire questi cambiamenti. Di conseguenza, l'azienda riscontra un aumento dei tempi di risposta per gli aggiornamenti tipici. Un'architettura complicata che coinvolge questi cicli di sviluppo complessi e dispendiosi in termini di tempo comporta un aumento dei costi.
Questa guida si concentra su un'architettura di base per un'applicazione IVR che aiuta a eliminare le ridondanze e semplifica il processo di gestione delle modifiche. Questa architettura semplifica la manutenzione e l'innovazione per gli sviluppatori e offre inoltre alle aziende l'agilità di cui hanno bisogno.
Indice
