Telefoni

För telefoni bestäms hanteringen av inkommande röstsamtal av hur samtalet kom in i kontaktcentret (se Ingressmekanismer nedan) och det Webex CC-flöde som är associerat med startpunkten.

Samtalet besvaras och ytterligare åtgärder utförs enligt Webex CC Flow-definitionen - vilket är en programmatisk representation av de åtgärder som ska utföras vid hantering av samtalet, antingen före kö och dirigering till en agent eller själva flödet kan hantera samtalet utan överföring till en agent.

Med Flow Builder i Webex CC kan utvecklare definiera flödet och tilldela det till startpunkten via vilken samtalet tas emot i Webex CC.

Dessa konfigurationsentiteter och deras användning omfattas av konfigurationsentiteter.

Mer information om Flow Builder finns i det kommande avsnittet om IVR System.

E-post och meddelanden

Ur Webex CC-perspektiv tillhandahåller Webex Connect in- och utgångsfunktioner för alla digitala kanaler - e-post, meddelandekanaler, som slutanvändare kan använda för att kontakta kontaktcenter.

Webex Connect Flow

• Bestämmer hanteringen av sådana interaktioner tills interaktionerna köas och dirigeras till agenter. Detta inkluderar automatisk hantering och BOT-behandlingar för alla former av meddelanden och e-postinteraktioner.

• Tillämpar affärslogik på inkommande interaktion.

• Hanterar kontakt före kö.

• Flow själv kan hantera interaktionen utan överföring till live-agent.

De meddelandekanaler som stöds av Webex CC är:

• Web App / Chatt med mobilapp

• WhatsApp

• Facebook Messenger

• SMS

De e-postkanaler som stöds av Webex CC är:

• Gmail

• Office365

Ingressmekanismer

Det här avsnittet beskriver de mekanismer genom vilka en interaktion kan komma in Webex CC. Baserat på medietypen är mekanismerna genom vilka en interaktion når Webex CC olika.

Inom telefoni krävs till exempel etablering av fysisk infrastruktur för att aktivera PSTN-anslutning, konfiguration av telefonnummer och dirigering av samtalen till Webex CC.

För e-post-/meddelandekanaler måste ingresskonfigurationen göras i Webex Connect och det omfattar etablering av e-post-/meddelandekonto och Webex Connect-flödeskonfiguration.

Inkommande röst

För röstsamtal är ett typiskt scenario där användare ringer ett PSTN-telefonnummer som sedan ansluts till kontaktcentret. Ur ett ingångsperspektiv behöver detta en mekanism för att dirigera samtal från PSTN till Webex CC.

Figur 1 illustrerar inmatningen av röstsamtal till Webex CC.

Voice Ingress Services i Webex CC utför samtalskontroll från tredje part med SIP och besvarar det inkommande samtalet samt utför överförings-, konferens- och andra samtalskontrollåtgärder.

Den logiska startpunkten för samtal i Webex CC är konfigurationsenheten med namnet "Entrypoint". För röstingress är nyckelkonfigurationen för Entrypoint det telefonnummer som är associerat med den, vilket vanligtvis är ett giltigt PSTN-telefonnummer som hämtas från den valda PSTN-leverantören.

Detta gör det möjligt att upptäcka inkommande samtal på telefonnumret, associera samtalet till startpunkten och använda andra konfigurationsparametrar för startpunkten för att hantera samtalet enligt Webex CC-flödesdefinitionen som ska utlösas för interaktionen.

Obs:

Mer information om PSTN-anslutningsalternativen finns i https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/webexcc/Voiceonboarding2/wcc-voice-onboarding-2-book/wcc_b__voiceonboarding_private_conn.html.

Skalbarhet och tillgänglighet för röstkantsinfrastruktur

Webex CC VPOP-infrastrukturen innehåller redundanta par SIP-SBC:er som säkerställer hög tillgänglighet och fler SBC:er kan läggas till för att skala de samtidiga samtalsvolymer som ska stödjas.

Det maximala antalet samtidiga samtal som VPOP kan hantera beror på antalet SBC:er som körs och till vilka samtal som skickas.

För geografisk redundans stöds ett nät av VPOP SBC med sammankopplingar över flera par mellan regioner.

För röstingresstjänster är de horisontellt skalbara för att hantera ett ökande antal samtidiga röstsamtal som ska matas in till Webex CC.

Säkerhetsöverväganden med röstgränsinfrastruktur

Tabellen nedan innehåller information om anslutningsalternativen till Voice Edge Infrastructure.

Mer information finns i https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/webexcc/Voiceonboarding2/wcc-voice-onboarding-2-book/wcc_b__voiceonboarding_private_conn.html.

IVR-systemet

Varje röstsamtal som kommer in till ett telefonnummer som är kopplat till en startpunkt, besvaras av Webex kopia och körning av ett Webex CC-flöde som är associerat med startpunkten startas.

Webex CC Flow Builder tillhandahåller programmeringskonstruktioner/operatorer och funktionsblock, så kallade aktiviteter, så att administratörer eller någon som utformar och implementerar den IVR logiken kan kombinera dessa byggstenar och skapa Flow-definitionen.

Programmeringskonstruktionerna som Flow stöder är:

• Deklarations- och inställningsvariabler – tillstånd som är associerat med en flödeskörning

  • Pebble-uttryck för att ange värde för variabler

• Villkorliga kontroller

• Looping - med hjälp av villkor och gå till (möjlighet att länka aktiviteter tillsammans)

• Anropa REST-API:er

• Parsa data – JSON, TOML XML används vanligtvis för att parsa API svar.

• Komponera aktiviteter

En representativ uppsättning aktiviteter som Flow levererar är: Spela upp meddelanden Samla in användardata Överföra samtalet till en annan destination/ett annat telefonnummer Skicka samtalet till en virtuell agent Ställ samtalet i kö så att det kan besvaras av en agent.

För varje samtal som är aktivt är även en instans av flödeskörning aktiv tills samtalet avslutas, vilket resulterar i samtidiga körningar av flöden.

Varje instans av flödeskörning ger isolerad miljö för data / tillstånd som är associerat med flödet och där av samtalet.

Under samtalets hela livscykel gör flödet det också möjligt att svara på vissa händelser som inträffar och hantera dem – till exempel när ett samtal besvaras av en agent kan en händelsehanterare utlösa en skärmfönster i agentens skrivbordsgränssnitt.

Mer information om Webex CC Flow finns ihttps://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/webexcc/SetupandAdministrationGuide_2/b_mp-release-2/b_cc-release-2_chapter_0100.html#Cisco_Generic_Topic.dita_e338e055-64b0-4973-bd52-8a5581dcb0ee.

Stöd för virtuell agent

Flow tillhandahåller en aktivitet för att överföra interaktionen till en virtuell agent som är förkonfigurerad i Webex Control Hub.

När samtalet är kopplat till en virtuell agent ger det användaren en konversations- IVR upplevelse och aktiviteten slutar antingen med att samtalet avslutas eller med att samtalet eskaleras till en agent.

Vid eskalering kan flödet konfigureras för att köa samtalet som sedan besvaras av en agent.

Inkommande digitala interaktioner

För e-post och meddelandekanal för inkommande interaktioner använder Webex CC Webex Connect för etablering av tillgångarna, flöde för att hantera inkommande interaktioner och dirigerar sedan interaktionen till Webex CC när Webex Connect-flödet uttryckligen köar interaktionen så att den kan hanteras av en agent.

Figur 2 illustrerar inmatningen av e-post- och meddelandeinteraktioner i Webex kopia.

Virtuell agent / BOT-integrationer

För interaktion via e-post och meddelanden/sociala kanaler konfigureras den virtuella agenten/BOT-behandlingarna i Webex Connect-flödet.

Precis som med Virtual Agents for Voice köas interaktionen och dirigeras till en agent om BOT-behandlingen slutar med eskalering som resultat.

Val av agent

Köer i Webex CC stöder följande algoritmer för agentval:

• Längsta tillgängliga agentroutning

• Kompetent baserad routing

  • Agent som är tillgänglig längst (LAA)

  • Bästa tillgängliga agent (BAA)

Agenter associeras med köer via team.

En kö kan tilldelas flera samtalsdistributionsgrupper (där varje grupp har ett eller flera team) på ett sekventiellt sätt med konfigurerad väntan på att samtalsdistributionsgruppen ska läggas till i kön, så att sökutrymmet för en matchande agent utökas till ytterligare samtalsdistributionsgrupper med tiden.

För färdighetsbaserad routning väljs en agent baserat på LAA- eller BAA-konfigurationer bland de kunskapskrav som matchar agenter som är associerade med kön.

Specifika extrafunktioner för röst-/telefoni

Agentbaserad routning (endast för röst-/telefonikanal)

Webex CC Flow kan med aktiviteten QueueToAgent dirigera interaktioner direkt till den valda agenten baserat på agentens ID.

Om agenten inte är tillgänglig för att hantera interaktioner kan interaktionen parkeras i en agentspecifik kö i väntan på att agenten blir tillgänglig

Avancerad köinformation

Webex CC Flow kan med hjälp av aktiviteten GetQueueInfo hämta realtidsinformation för en kö som Position in Queue (PIQ), Estimated Wait Time (EWT), antal agenter som är tillgängliga i kön och kan användas för att avgöra om kontakten ska placeras i kö eller inte.

Återuppringning med tillstånd

Webex CC Flow, som använder aktiviteten Återuppringning, låter kunden koppla bort samtalet med bibehållen position i kön och få en återuppringning när den virtuella interaktionen i kön dirigeras till en agent.

Hantering av spill

Webex CC stöder spillhantering med hjälp av kapacitetsbaserade team (CBT).

KBT är som ett vanligt team med en kapacitet och ett tillhörande externt DN som tjänar den kapaciteten. Den kan konfigureras tillsammans med andra team i distributionscyklerna för kösamtal.

Vanligtvis konfigureras detta som den senaste cykeln så att den fungerar som ett spill om ingen agent är tillgänglig även om alla konfigurerade samtalsdistributionsgrupper inte hittar en tillgänglig matchande agent för att hantera interaktionen.

Agent Desktop operationer

När en agent loggar in Webex CC Agent Desktop anger agenten ett telefonnummer som inkommande samtal till agenten kan kopplas till. Det kan vara en PSTN-telefon, mobiltelefon eller en anknytning om agenten är en Cisco Webex Calling användare.

Observera att detta nummer måste vara ett giltigt telefonnummer som samtal kan kopplas till. Om den inte är det kan agenten inte ta emot inkommande samtal.

Beroende på vilken typ av interaktion agenten hanterar kan widgetarna på agentskrivbordet utföra vissa mediekontrollåtgärder.

När ett samtal har besvarats kan agenten till exempel utföra följande åtgärder i samband med samtalet.

• Parkera samtalet

• Starta konsultsamtal och

  • Överför samtalet till ett annat telefonnummer (t.ex. agentens telefonnummer) / startpunkt

  • Ge en annan agent konferenssamtal

• Överföra samtalet till en annan kö

• Avsluta samtalet

Med Agent Desktop kan administratörer lägga till anpassade widgetar där genom att utöka skrivbordsfunktionerna och göra det till en enhetlig samling widgetar som agenter behöver för att få jobbet gjort på ett effektivt sätt.

Skrivbordsarkitektur

Agent Desktop är ett micro frontend-baserat ensidesprogram som är värd för widgetar byggda baserat på arkitektur för webbkomponenter. Alla standard- / lagerwidgets drivs av data som hämtas av API: er eller push-mekanismer på serversidan.

Dessa är vanligtvis asynkrona API:er, där svaret för ett anrop kommer till skrivbordet via en WebSocket-anslutning.

Webex CC autentiserar Agent Desktop användare med Cisco Common Identity (CI) och token skickas vidare till alla API anrop. Även för anpassade widgetar, baserat på autentiseringsmodellen, ger det agenter enkel inloggning om den anpassade widgetens autentiseringsmodell är integrerad med CI.

När en agent är en del av en interaktion skickas alla uppdateringar av interaktionstillståndet eller associerade data till skrivbordet via WebSocket-anslutningen.

Skrivbordets motståndskraft mot anslutning och svarstid

Den asynkrona API- och serversidans push möjliggör skalning och eventuella anslutningsförluster till WebSocket-gränssnittet identifieras och skrivbordet försöker återansluta och logga in igen.

Bild 2 illustrerar agentskrivbordsarkitekturen i Webex CC.

Onboarding av kunder

Webex Control Hub är det primära gränssnittet som används av partner och kunder för att registrera kunder och aktivera eller konfigurera funktioner.

När organisationen och kontaktcenterfunktionerna har etablerats i Control Hub utlöser det ett arbetsflöde i Webex CC som gör resten av stegen i etableringen av alla kontaktcenterfunktioner enligt de erbjudanden som kunden valt.

All etablering av kontaktcenter görs med hjälp av en BPM-arbetsflödesmotor som möjliggör ett deklarativt sätt att definiera de steg som ingår och gör hela etableringsstegen motståndskraftiga mot fel och säkerställer dataintegritet.

Bild 1 illustrerar etableringsarbetsflödet i Webex CC.

Konfigurationsentiteter

De viktigaste konfigurationsentiteterna i Webex CC, som är begränsade inom en organisation, är:

Plats

Plats betyder en plats där ett eller flera team, användare (agenter / arbetsledare) finns.

Varje användare och team måste tillhöra en webbplats.

Team

En grupp användare. Team används för att distribuera interaktioner till agenter via köer.

Varje team måste tillhöra en webbplats.

Agenter

Användare som kan logga in i Agent Desktop och hantera interaktioner mellan de medietyper som konfigureras i Webex CC.

Arbetsledare

Arbetsledare tilldelas team och kan övervaka/coacha agenten och har tillgång till status på teamnivå och agentstatistik för de som tillhör de team som arbetsledaren är tilldelad till.

Kö

En kö är en logisk enhet där interaktioner kan hållas i väntan på att agenter ska bli tillgängliga, som sedan dirigeras till agenten.

Köer mappas till team, som sökutrymme för agenter, med möjlighet att utöka sökutrymmet baserat på tröskeln för förfluten tid genom att lägga till andra team i sökutrymmet.

Startpunkt

Startpunkt är en logisk entitet som representerar ingångspunkten för interaktioner som ska komma in i Webex kopia. För telefoni mappas detta främst till telefonnumret som samtalen kommer till och för e-post-/meddelandekanaler pekar startpunkten på resurskonfigurationen i Webex Connect.

Flöde

Det flöde som är associerat med startpunkten (via routningsstrategin), som bestämmer vilka steg som ska ingå i hanteringen av interaktioner.

För icke-telefonikanaler (e-post, meddelanden/sociala medier) väljs Flow som en del av resurskonfigurationen i Webex Connect.

Åtkomstkontroll för kontaktcenter på flera platser

Webex CC-administratörer kan konfigurera användarprofiler med åtkomsträttigheter till specifika platser, team, köer och startpunkter. På grund av webbplatsernas och teamens hierarkiska karaktär kan användaren dessutom komma åt endast de team eller det datum som hör till teamen, som tillhör dessa webbplatser eller en uttryckligen angiven delmängd av sådana team, när åtkomst till specifika webbplatser har tillhandahållits.

För köer och startpunkter är de globala på organisationsnivå, så för olika geografiska platser (platser där specifika agenter och team finns) kan separata startpunkter och köer konfigureras, och arbetsledare / användare kan ha åtkomst till de enheter som är tillämpliga för specifika platser.

Bild 2 illustrerar de viktigaste konfigurationsentiteterna och användarprofilen som refererar till dessa entiteter.

Förutom att begränsa åtkomsten till dessa enheter kan Webex CC-administratörer styra de specifika funktioner/moduler som en användare kan komma åt i administrationsgränssnittet och därigenom ha användare med administrations-/konfigurationsbehörighet till specifika enheter samt sektioner/funktioner i Webex CC-administrationsgränssnittet.

Skrivbordsinbäddade anslutningar: CRM-program som primärt gränssnitt

I det här läget loggar agenten in på CRM-konsolen som primärt program.

Webex CC är ett inbäddat program (även kallat ett inbäddat skrivbordsprogram eller inbäddad softphone) som främst används för att logga in på kontaktcentret och ta emot Webex CC-dirigerade kontaktcenterinteraktioner.

När du tar emot ett samtal eller en konversationsförfrågan utför CRM-integreringen följande åtgärder på CRM-konsolen

• Skärma upp kundposten som är knuten till ANI eller andra samtalsrelaterade data.

• Metadata efter samtal som aktivitetsanteckningar i kundposten

• Låt agenten "Click to Call" genom att klicka på kontakten i CRM och initiera ett utgående samtal till kunden

• Bokföra samtalsposter i CRM-rapporteringstabellerna för primär rapportering på CRM.

• Ger alla funktioner i Agent Desktop- och samtalskontrollerna (inbäddad och minifierad version av skrivbordsappen)

Det primära sättet att integrera med CRM: erna är genom att bädda in Webex CC Desktop-applikation i en separat iFrame.

Dessutom kör Webex CC Desktop-programmet en anpassad headless-widget (inget användargränssnitt) som körs i bakgrunden och interagerar med det underliggande CRM-systemet för att utföra automatiserade åtgärder på uppdrag av agenten.

Interaktionerna drivs av två SDK: er som den headless-widgeten använder.

• Webex CC Desktop JS SDK: Detta är JavaScript SDK som tillhandahålls av Webex CC för att registrera händelseavlyssnare för agent- och kontaktåtgärder.

• CRM JS SDK: Det här är CRM-klient-SDK:n som gäller per CRM och som abstraherar REST-API-anrop med CRM. Till exempel för salesforce används CTI JS-biblioteket som tillhandahålls av Salesforce för att utföra åtgärder och lyssna efter händelser i CRM.

Figur 1 illustrerar CRM inbäddad Webex CC skrivbords- och anslutningsarkitektur

Webex CC stöder följande CRM-lösningar för ovan nämnda integration:

• Salesforce

• ServiceNu

• Microsoft Dynamics 365

• Zendesk

• Freshdesk

Mer information finns i https://help.webex.com/en-us/result/integrate%20with%20webex%20contact%20center?offset=10.

Mer information om hur du konfigurerar Webex CC-skrivbordslayouter för aktivering av CRM-anslutning, funktionsuppsättningar och ändringsloggar finns på https://github.com/CiscoDevNet/webex-contact-center-crm-integrationshttps://github.com/CiscoDevNet/webex-contact-center-crm-integrations.

Global tillgänglighet för CRM-kopplingar

CRM-anslutningsapparna är tillgängliga i alla geografiska områden och regioner där Webex CC används.

Elastisk skala och prestanda

Webex CC är värd för den anpassade widgeten som möjliggör dubbelriktad kommunikation mellan CRM-applikationen och Webex CC-skrivbordet i AWS CloudFront CDN, vilket säkerställer hög tillgänglighet för widgeten AWS över tillgänglighetszoner och regioner.

All CRM-integrationsspecifik beräkning sker i webbläsaren där agenter använder CRM-programmet med Webex CC-skrivbord inbäddat i CRM-programmet.

Säkerhet

CRM-kopplingarna anropas via Webex CC-agentskrivbordslayouten och valfria parametrar skickas via skrivbordslayouten till widgeten för att aktivera och inaktivera funktioner.

Om du till exempel vill aktivera widgeten Salesforce-åtgärder kan administratören aktivera skrivbordslayoutparameterinställningen sfdcWidgetEnabled till true.

Installation av paket

För att integreringen ska fungera dubbelriktat måste CRM-konsolen ha det inbäddade programmet installerat. Detta för att stödja laddning av skrivbordsprogrammet inuti en iFrame.

Alla Desktop Embedded-kopplingar är tillgängliga på CRM-marknadsplatsen.

Till exempel,

ServiceNow: https://store.servicenow.com/sn_appstore_store.do#!/store/application/6c8e2a4edbc73410e1c75e25ca961947/1.0.5?

Zendesk: https://www.zendesk.com/marketplace/apps/support/202570/webex-contact-center/

Installationen av Marketplace-programmet aktiverar nödvändiga plugin-program och importerar de nödvändiga XML filerna till CRM-konsolen för att stödja rapportering av samtalsposter på CRM.

Flödesintegreringar via HTTPs-anslutningsappar i IVR

Webex CC Flow-byggaren stöder dubbelriktade dataflöden mellan Webex CC och CRM-systemet med HTTPs-anslutningar som konfigurerats i Webex Control Hub och används på Webex CC Flow.

Dessa används främst för personalisering inom röstinteraktioner och anpassad routing inom IVR.

Som standard stöder Webex CC Salesforce HTTP Connector på Control Hub. De andra CRM-kopplingarna kan läggas till som anpassade anslutningsprogram i Webex Control Hub.

Mer information om HTTP-anslutningsappar finns i https://github.com/CiscoDevNet/webex-contact-center-crm-integrations.

IVR HTTP-anslutningar:

• Salesforce IVR HTTP-anslutning (inbyggd): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/Salesforce/salesforce-ivr-http-connector

• Zendesk IVR HTTP-anslutning (anpassad): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/Zendesk/zendesk-ivr-http-connector

• ServiceNow IVR HTTP-anslutning (anpassad): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/ServiceNow/servicenow-ivr-http-connector

Röstinfrastruktur på Edge

Voice Edge-komponenterna gör det möjligt för SIP-trunkar från kundnätverk / PSTN-operatörer att avslutas, och detta aktiveras baserat på vitlistade IP-adresser som får ansluta till gränskomponenterna.

Säkerhet för beräkningsinfrastruktur

Webex CC-beräkningsinstanser etableras i AWS och tjänster körs som poddar i Kubernetes-kluster som har flera namnrymder och åtkomsten till varje namnområde är begränsad med separata autentiseringsuppgifter.

All etablering av infrastruktur görs med hjälp av kod – inga manuella steg – och ingen av autentiseringsuppgifterna kan nås manuellt.

Det finns ett centralt arkiv med specifika sökvägar konfigurerade för en specifik uppsättning tjänster/team och åtkomsten till själva arkivet för autentiseringsuppgifter är begränsad och konfigurerad som hemligheter i bygg- och distributionssystemen.

Ingen av infrastrukturkomponenterna/tjänsterna är direkt exponerade utanför AWS VPC och endast offentligt exponerade gränssnitt är API:er och WebSocket-servrar som styrs och hanteras med hjälp av api-gateway,

Bortsett från detta finns det vissa interna system och gränssnitt som används av utvecklare som används för att visa loggar, mätvärden, distributionsdetaljer, byggstatus och testresultat, som är säkrade med roller och grupper och integrerade med Ciscos interna autentiseringssystem.

Autentisering och auktorisering för användargränssnitt

Alla användargränssnitt som används av olika kontaktcenteranvändare (agenter, arbetsledare, administratörer, analytiker) skyddas av OAuth-flöden (Cisco Common Identity-baserad autentisering med innehavartoken).

Auktoriseringen görs med hjälp av roller för den användare som hämtade token och omfång som tilldelats token.

Data under överföring

Inget av gränssnitten för den distribuerade tjänste-/infrastrukturkomponenten exponeras direkt för extern inkommande trafik.

Välj tjänster, med http-API:er exponerar dessa gränssnitt via en gateway och alla inkommande https (inklusive WebSocket) avslutas i ALB och intern trafik över http dirigeras till tjänsterna.

Alla utgående interaktioner är över https / TLS (för icke-http-protokoll).

Inuti VPC är den interna kommunikationen mellan tjänster – över http / custom TCP protokoll - över vanligt TCP uttag.

Vilande data

All data som lagras krypteras på lagringslagret. Vidare är de datalager som ligger utanför VPC skyddade och åtkomstkontroll och behörigheter med autentiseringsuppgifter säkert lagrade och hanterade i ett hemligt arkiv.

Figur 1 illustrerar dataflödes- och säkerhetsmodellen för överföring och i vila.

PII-data för slutanvändare

Webex CC Flow, som är den programmatiska styrenheten för hantering av interaktioner, kan användas för att samla in användardata, som kan tilldelas flödesvariabler som är särskilt märkta som "Innehåller känsliga data". Värdena för sådana data är krypterade och inga tjänster i överföringsvägen för data kommer att ha åtkomst till dessa data.

Vidare bevaras aldrig sådana data i Webex CC-rapporteringsdatalager och loggarna / meddelandeinfrastrukturen kommer att ha krypterade data och klartextdata lagras inte någonstans inom Webex CC.

PII-data för kontaktcenteragent/arbetsledare

Kontaktcentrets användarrelaterade data redigeras i loggar men är tillgängliga för dataanalys och visualisering i Webex CC-datalagret.

Faktorer för skala

För Webex CC är de faktorer som påverkar skalan:

• Samtidiga antal inloggade agenter

• Samtidig antal pågående interaktioner

  • Åtgärder som utförts på dessa interaktioner

• Samtidig antal åtgärder som arbetsledare/agenter utför, utöver hanteringen av interaktionerna

• Mängden data som genererats och bevarats

Arkitektoniska aspekter som möjliggör skalbarhet

De principer som Webex CC bygger på och utformas gör att lösningen kan skalas dynamiskt efter behov inom de gränser som tillämpas av den infrastruktur som tillhandahålls för de olika tjänsterna och plattformskomponenterna.

Händelsedriven arkitektur

Tjänsterna i Webex CC kommunicerar med hjälp av meddelanden och de kritiska meddelandebearbetningsflödena innebär inte några blockerande I/O-åtgärder och det tillstånd som krävs för bearbetning av meddelanden lokaliseras till instansen av tjänsten som bearbetar meddelandet.

Tillståndslösa tjänster (eller externt tillstånd)

Tillståndslösa tjänster möjliggör elasticitet genom att enkelt lägga till/ta bort ytterligare instanser av tjänsterna. Det finns vissa tjänster som i sig är tillståndsfulla till sin natur och de har externaliserat tillståndslager och infrastrukturen stöder dynamiska förändringar av antalet instanser av sådana tjänster också med automatisk ombalansering / tillståndsöverföring / lokalisering av tillståndet till den instans som behöver tillståndet.

Elastisk infrastruktur

Alla tjänster körs i Kubernetes och infrastrukturen, även kallad Kubernetes-noder, skalas automatiskt baserat på användningen och detta gör det möjligt att dynamiskt lägga till fler beräkningsnoder upp till ett maximalt högt tröskelvärde som är förkonfigurerat.

Laddningsprojektion och regelbunden validering

Alla tjänster jämförs för prestandaegenskaper och skalningsmönster valideras på servicenivå.

Ytterligare kontinuerliga validerings-, toppbelastnings- och uthållighetstester utförs med testparametrar justerade för beräknad tillväxt i skalan som påverkar attribut, vilket gör det möjligt att identifiera flaskhalsar, planera att uppdatera den höga tröskeln för infrastrukturresursanvändning och vara redo för speldagen.

Telefoni

För telefoni bestäms hanteringen av inkommande röstsamtal av hur samtalet kom in i kontaktcentret (se Ingressmekanismer nedan) och det Webex CC-flöde som är associerat med startpunkten.

Samtalet besvaras och ytterligare åtgärder utförs enligt Webex CC Flow-definitionen - vilket är en programmatisk representation av de åtgärder som ska utföras vid hantering av samtalet, antingen före kö och dirigering till en agent eller själva flödet kan hantera samtalet utan överföring till en agent.

Med Flow Builder i Webex CC kan utvecklare definiera flödet och tilldela det till startpunkten via vilken samtalet tas emot i Webex CC.

Dessa konfigurationsentiteter och deras användning omfattas av konfigurationsentiteter.

Mer information om Flow Builder finns i det kommande avsnittet om IVR System.

E-post och meddelanden

Ur Webex CC-perspektiv tillhandahåller Webex Connect in- och utgångsfunktioner för alla digitala kanaler - e-post, meddelandekanaler, som slutanvändare kan använda för att kontakta kontaktcenter.

Webex Connect Flow

• Bestämmer hanteringen av sådana interaktioner tills interaktionerna köas och dirigeras till agenter. Detta inkluderar automatisk hantering och BOT-behandlingar för alla former av meddelanden och e-postinteraktioner.

• Tillämpar affärslogik på inkommande interaktion.

• Hanterar kontakt före kö.

• Flow själv kan hantera interaktionen utan överföring till live-agent.

De meddelandekanaler som stöds av Webex CC är:

• Web App / Chatt med mobilapp

• WhatsApp

• Facebook Messenger

• SMS

De e-postkanaler som stöds av Webex CC är:

• Gmail

• Office365

Ingressmekanismer

Det här avsnittet beskriver de mekanismer genom vilka en interaktion kan komma in Webex CC. Baserat på medietypen är mekanismerna genom vilka en interaktion når Webex CC olika.

Inom telefoni krävs till exempel etablering av fysisk infrastruktur för att aktivera PSTN-anslutning, konfiguration av telefonnummer och dirigering av samtalen till Webex CC.

För e-post-/meddelandekanaler måste ingresskonfigurationen göras i Webex Connect och det omfattar etablering av e-post-/meddelandekonto och Webex Connect-flödeskonfiguration.

Inkommande röst

För röstsamtal är ett typiskt scenario där användare ringer ett PSTN-telefonnummer som sedan ansluts till kontaktcentret. Ur ett ingångsperspektiv behöver detta en mekanism för att dirigera samtal från PSTN till Webex CC.

Figur 1 illustrerar inmatningen av röstsamtal till Webex CC.

Voice Ingress Services i Webex CC utför samtalskontroll från tredje part med SIP och besvarar det inkommande samtalet samt utför överförings-, konferens- och andra samtalskontrollåtgärder.

Den logiska startpunkten för samtal i Webex CC är konfigurationsenheten med namnet "Entrypoint". För röstingress är nyckelkonfigurationen för Entrypoint det telefonnummer som är associerat med den, vilket vanligtvis är ett giltigt PSTN-telefonnummer som hämtas från den valda PSTN-leverantören.

Detta gör det möjligt att upptäcka inkommande samtal på telefonnumret, associera samtalet till startpunkten och använda andra konfigurationsparametrar för startpunkten för att hantera samtalet enligt Webex CC-flödesdefinitionen som ska utlösas för interaktionen.

Obs:

Mer information om PSTN-anslutningsalternativen finns i https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/webexcc/Voiceonboarding2/wcc-voice-onboarding-2-book/wcc_b__voiceonboarding_private_conn.html.

Skalbarhet och tillgänglighet för röstkantsinfrastruktur

Webex CC VPOP-infrastrukturen innehåller redundanta par SIP-SBC:er som säkerställer hög tillgänglighet och fler SBC:er kan läggas till för att skala de samtidiga samtalsvolymer som ska stödjas.

Det maximala antalet samtidiga samtal som VPOP kan hantera beror på antalet SBC:er som körs och till vilka samtal som skickas.

För geografisk redundans stöds ett nät av VPOP SBC med sammankopplingar över flera par mellan regioner.

För röstingresstjänster är de horisontellt skalbara för att hantera ett ökande antal samtidiga röstsamtal som ska matas in till Webex CC.

Säkerhetsöverväganden med röstgränsinfrastruktur

Tabellen nedan innehåller information om anslutningsalternativen till Voice Edge Infrastructure.

Mer information finns i https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/webexcc/Voiceonboarding2/wcc-voice-onboarding-2-book/wcc_b__voiceonboarding_private_conn.html.

IVR-systemet

Varje röstsamtal som kommer in till ett telefonnummer som är kopplat till en startpunkt, besvaras av Webex kopia och körning av ett Webex CC-flöde som är associerat med startpunkten startas.

Webex CC Flow Builder tillhandahåller programmeringskonstruktioner/operatorer och funktionsblock, så kallade aktiviteter, så att administratörer eller någon som utformar och implementerar den IVR logiken kan kombinera dessa byggstenar och skapa Flow-definitionen.

Programmeringskonstruktionerna som Flow stöder är:

• Deklarations- och inställningsvariabler – tillstånd som är associerat med en flödeskörning

  • Pebble-uttryck för att ange värde för variabler

• Villkorliga kontroller

• Looping - med hjälp av villkor och gå till (möjlighet att länka aktiviteter tillsammans)

• Anropa REST-API:er

• Parsa data – JSON, TOML XML används vanligtvis för att parsa API svar.

• Komponera aktiviteter

En representativ uppsättning aktiviteter som Flow levererar är: Spela upp meddelanden Samla in användardata Överföra samtalet till en annan destination/ett annat telefonnummer Skicka samtalet till en virtuell agent Ställ samtalet i kö så att det kan besvaras av en agent.

För varje samtal som är aktivt är även en instans av flödeskörning aktiv tills samtalet avslutas, vilket resulterar i samtidiga körningar av flöden.

Varje instans av flödeskörning ger isolerad miljö för data / tillstånd som är associerat med flödet och där av samtalet.

Under samtalets hela livscykel gör flödet det också möjligt att svara på vissa händelser som inträffar och hantera dem – till exempel när ett samtal besvaras av en agent kan en händelsehanterare utlösa en skärmfönster i agentens skrivbordsgränssnitt.

Mer information om Webex CC Flow finns ihttps://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/webexcc/SetupandAdministrationGuide_2/b_mp-release-2/b_cc-release-2_chapter_0100.html#Cisco_Generic_Topic.dita_e338e055-64b0-4973-bd52-8a5581dcb0ee.

Stöd för virtuell agent

Flow tillhandahåller en aktivitet för att överföra interaktionen till en virtuell agent som är förkonfigurerad i Webex Control Hub.

När samtalet är kopplat till en virtuell agent ger det användaren en konversations- IVR upplevelse och aktiviteten slutar antingen med att samtalet avslutas eller med att samtalet eskaleras till en agent.

Vid eskalering kan flödet konfigureras för att köa samtalet som sedan besvaras av en agent.

Inkommande digitala interaktioner

För e-post och meddelandekanal för inkommande interaktioner använder Webex CC Webex Connect för etablering av tillgångarna, flöde för att hantera inkommande interaktioner och dirigerar sedan interaktionen till Webex CC när Webex Connect-flödet uttryckligen köar interaktionen så att den kan hanteras av en agent.

Figur 2 illustrerar inmatningen av e-post- och meddelandeinteraktioner i Webex kopia.

Virtuell agent / BOT-integrationer

För interaktion via e-post och meddelanden/sociala kanaler konfigureras den virtuella agenten/BOT-behandlingarna i Webex Connect-flödet.

Precis som med Virtual Agents for Voice köas interaktionen och dirigeras till en agent om BOT-behandlingen slutar med eskalering som resultat.

Val av agent

Köer i Webex CC stöder följande algoritmer för agentval:

• Längsta tillgängliga agentroutning

• Kompetent baserad routing

  • Agent som är tillgänglig längst (LAA)

  • Bästa tillgängliga agent (BAA)

Agenter associeras med köer via team.

En kö kan tilldelas flera samtalsdistributionsgrupper (där varje grupp har ett eller flera team) på ett sekventiellt sätt med konfigurerad väntan på att samtalsdistributionsgruppen ska läggas till i kön, så att sökutrymmet för en matchande agent utökas till ytterligare samtalsdistributionsgrupper med tiden.

För färdighetsbaserad routning väljs en agent baserat på LAA- eller BAA-konfigurationer bland de kunskapskrav som matchar agenter som är associerade med kön.

Specifika extrafunktioner för röst-/telefoni

Agentbaserad routning (endast för röst-/telefonikanal)

Webex CC Flow kan med aktiviteten QueueToAgent dirigera interaktioner direkt till den valda agenten baserat på agentens ID.

Om agenten inte är tillgänglig för att hantera interaktioner kan interaktionen parkeras i en agentspecifik kö i väntan på att agenten blir tillgänglig

Avancerad köinformation

Webex CC Flow kan med hjälp av aktiviteten GetQueueInfo hämta realtidsinformation för en kö som Position in Queue (PIQ), Estimated Wait Time (EWT), antal agenter som är tillgängliga i kön och kan användas för att avgöra om kontakten ska placeras i kö eller inte.

Återuppringning med tillstånd

Webex CC Flow, som använder aktiviteten Återuppringning, låter kunden koppla bort samtalet med bibehållen position i kön och få en återuppringning när den virtuella interaktionen i kön dirigeras till en agent.

Hantering av spill

Webex CC stöder spillhantering med hjälp av kapacitetsbaserade team (CBT).

KBT är som ett vanligt team med en kapacitet och ett tillhörande externt DN som tjänar den kapaciteten. Den kan konfigureras tillsammans med andra team i distributionscyklerna för kösamtal.

Vanligtvis konfigureras detta som den senaste cykeln så att den fungerar som ett spill om ingen agent är tillgänglig även om alla konfigurerade samtalsdistributionsgrupper inte hittar en tillgänglig matchande agent för att hantera interaktionen.

Agent Desktop operationer

När en agent loggar in Webex CC Agent Desktop anger agenten ett telefonnummer som inkommande samtal till agenten kan kopplas till. Det kan vara en PSTN-telefon, mobiltelefon eller en anknytning om agenten är en Cisco Webex Calling användare.

Observera att detta nummer måste vara ett giltigt telefonnummer som samtal kan kopplas till. Om den inte är det kan agenten inte ta emot inkommande samtal.

Beroende på vilken typ av interaktion agenten hanterar kan widgetarna på agentskrivbordet utföra vissa mediekontrollåtgärder.

När ett samtal har besvarats kan agenten till exempel utföra följande åtgärder i samband med samtalet.

• Parkera samtalet

• Starta konsultsamtal och

  • Överför samtalet till ett annat telefonnummer (t.ex. agentens telefonnummer) / startpunkt

  • Ge en annan agent konferenssamtal

• Överföra samtalet till en annan kö

• Avsluta samtalet

Med Agent Desktop kan administratörer lägga till anpassade widgetar där genom att utöka skrivbordsfunktionerna och göra det till en enhetlig samling widgetar som agenter behöver för att få jobbet gjort på ett effektivt sätt.

Skrivbordsarkitektur

Agent Desktop är ett micro frontend-baserat ensidesprogram som är värd för widgetar byggda baserat på arkitektur för webbkomponenter. Alla standard- / lagerwidgets drivs av data som hämtas av API: er eller push-mekanismer på serversidan.

Dessa är vanligtvis asynkrona API:er, där svaret för ett anrop kommer till skrivbordet via en WebSocket-anslutning.

Webex CC autentiserar Agent Desktop användare med Cisco Common Identity (CI) och token skickas vidare till alla API anrop. Även för anpassade widgetar, baserat på autentiseringsmodellen, ger det agenter enkel inloggning om den anpassade widgetens autentiseringsmodell är integrerad med CI.

När en agent är en del av en interaktion skickas alla uppdateringar av interaktionstillståndet eller associerade data till skrivbordet via WebSocket-anslutningen.

Skrivbordets motståndskraft mot anslutning och svarstid

Den asynkrona API- och serversidans push möjliggör skalning och eventuella anslutningsförluster till WebSocket-gränssnittet identifieras och skrivbordet försöker återansluta och logga in igen.

Bild 2 illustrerar agentskrivbordsarkitekturen i Webex CC.

Onboarding av kunder

Webex Control Hub är det primära gränssnittet som används av partner och kunder för att registrera kunder och aktivera eller konfigurera funktioner.

När organisationen och kontaktcenterfunktionerna har etablerats i Control Hub utlöser det ett arbetsflöde i Webex CC som gör resten av stegen i etableringen av alla kontaktcenterfunktioner enligt de erbjudanden som kunden valt.

All etablering av kontaktcenter görs med hjälp av en BPM-arbetsflödesmotor som möjliggör ett deklarativt sätt att definiera de steg som ingår och gör hela etableringsstegen motståndskraftiga mot fel och säkerställer dataintegritet.

Bild 1 illustrerar etableringsarbetsflödet i Webex CC.

Konfigurationsentiteter

De viktigaste konfigurationsentiteterna i Webex CC, som är begränsade inom en organisation, är:

Plats

Plats betyder en plats där ett eller flera team, användare (agenter / arbetsledare) finns.

Varje användare och team måste tillhöra en webbplats.

Team

En grupp användare. Team används för att distribuera interaktioner till agenter via köer.

Varje team måste tillhöra en webbplats.

Agenter

Användare som kan logga in i Agent Desktop och hantera interaktioner mellan de medietyper som konfigureras i Webex CC.

Arbetsledare

Arbetsledare tilldelas team och kan övervaka/coacha agenten och har tillgång till status på teamnivå och agentstatistik för de som tillhör de team som arbetsledaren är tilldelad till.

Kö

En kö är en logisk enhet där interaktioner kan hållas i väntan på att agenter ska bli tillgängliga, som sedan dirigeras till agenten.

Köer mappas till team, som sökutrymme för agenter, med möjlighet att utöka sökutrymmet baserat på tröskeln för förfluten tid genom att lägga till andra team i sökutrymmet.

Startpunkt

Startpunkt är en logisk entitet som representerar ingångspunkten för interaktioner som ska komma in i Webex kopia. För telefoni mappas detta främst till telefonnumret som samtalen kommer till och för e-post-/meddelandekanaler pekar startpunkten på resurskonfigurationen i Webex Connect.

Flöde

Det flöde som är associerat med startpunkten (via routningsstrategin), som bestämmer vilka steg som ska ingå i hanteringen av interaktioner.

För icke-telefonikanaler (e-post, meddelanden/sociala medier) väljs Flow som en del av resurskonfigurationen i Webex Connect.

Åtkomstkontroll för kontaktcenter på flera platser

Webex CC-administratörer kan konfigurera användarprofiler med åtkomsträttigheter till specifika platser, team, köer och startpunkter. På grund av webbplatsernas och teamens hierarkiska karaktär kan användaren dessutom komma åt endast de team eller det datum som hör till teamen, som tillhör dessa webbplatser eller en uttryckligen angiven delmängd av sådana team, när åtkomst till specifika webbplatser har tillhandahållits.

För köer och startpunkter är de globala på organisationsnivå, så för olika geografiska platser (platser där specifika agenter och team finns) kan separata startpunkter och köer konfigureras, och arbetsledare / användare kan ha åtkomst till de enheter som är tillämpliga för specifika platser.

Bild 2 illustrerar de viktigaste konfigurationsentiteterna och användarprofilen som refererar till dessa entiteter.

Förutom att begränsa åtkomsten till dessa enheter kan Webex CC-administratörer styra de specifika funktioner/moduler som en användare kan komma åt i administrationsgränssnittet och därigenom ha användare med administrations-/konfigurationsbehörighet till specifika enheter samt sektioner/funktioner i Webex CC-administrationsgränssnittet.

Skrivbordsinbäddade anslutningar: CRM-program som primärt gränssnitt

I det här läget loggar agenten in på CRM-konsolen som primärt program.

Webex CC är ett inbäddat program (även kallat ett inbäddat skrivbordsprogram eller inbäddad softphone) som främst används för att logga in på kontaktcentret och ta emot Webex CC-dirigerade kontaktcenterinteraktioner.

När du tar emot ett samtal eller en konversationsförfrågan utför CRM-integreringen följande åtgärder på CRM-konsolen

• Skärma upp kundposten som är knuten till ANI eller andra samtalsrelaterade data.

• Metadata efter samtal som aktivitetsanteckningar i kundposten

• Låt agenten "Click to Call" genom att klicka på kontakten i CRM och initiera ett utgående samtal till kunden

• Bokföra samtalsposter i CRM-rapporteringstabellerna för primär rapportering på CRM.

• Ger alla funktioner i Agent Desktop- och samtalskontrollerna (inbäddad och minifierad version av skrivbordsappen)

Det primära sättet att integrera med CRM: erna är genom att bädda in Webex CC Desktop-applikation i en separat iFrame.

Dessutom kör Webex CC Desktop-programmet en anpassad headless-widget (inget användargränssnitt) som körs i bakgrunden och interagerar med det underliggande CRM-systemet för att utföra automatiserade åtgärder på uppdrag av agenten.

Interaktionerna drivs av två SDK: er som den headless-widgeten använder.

• Webex CC Desktop JS SDK: Detta är JavaScript SDK som tillhandahålls av Webex CC för att registrera händelseavlyssnare för agent- och kontaktåtgärder.

• CRM JS SDK: Det här är CRM-klient-SDK:n som gäller per CRM och som abstraherar REST-API-anrop med CRM. Till exempel för salesforce används CTI JS-biblioteket som tillhandahålls av Salesforce för att utföra åtgärder och lyssna efter händelser i CRM.

Figur 1 illustrerar CRM inbäddad Webex CC skrivbords- och anslutningsarkitektur

Webex CC stöder följande CRM-lösningar för ovan nämnda integration:

• Salesforce

• ServiceNu

• Microsoft Dynamics 365

• Zendesk

• Freshdesk

Mer information finns i https://help.webex.com/en-us/result/integrate%20with%20webex%20contact%20center?offset=10.

Mer information om hur du konfigurerar Webex CC-skrivbordslayouter för aktivering av CRM-anslutning, funktionsuppsättningar och ändringsloggar finns på https://github.com/CiscoDevNet/webex-contact-center-crm-integrationshttps://github.com/CiscoDevNet/webex-contact-center-crm-integrations.

Global tillgänglighet för CRM-kopplingar

CRM-anslutningsapparna är tillgängliga i alla geografiska områden och regioner där Webex CC används.

Elastisk skala och prestanda

Webex CC är värd för den anpassade widgeten som möjliggör dubbelriktad kommunikation mellan CRM-applikationen och Webex CC-skrivbordet i AWS CloudFront CDN, vilket säkerställer hög tillgänglighet för widgeten AWS över tillgänglighetszoner och regioner.

All CRM-integrationsspecifik beräkning sker i webbläsaren där agenter använder CRM-programmet med Webex CC-skrivbord inbäddat i CRM-programmet.

Säkerhet

CRM-kopplingarna anropas via Webex CC-agentskrivbordslayouten och valfria parametrar skickas via skrivbordslayouten till widgeten för att aktivera och inaktivera funktioner.

Om du till exempel vill aktivera widgeten Salesforce-åtgärder kan administratören aktivera skrivbordslayoutparameterinställningen sfdcWidgetEnabled till true.

Installation av paket

För att integreringen ska fungera dubbelriktat måste CRM-konsolen ha det inbäddade programmet installerat. Detta för att stödja laddning av skrivbordsprogrammet inuti en iFrame.

Alla Desktop Embedded-kopplingar är tillgängliga på CRM-marknadsplatsen.

Till exempel,

ServiceNow: https://store.servicenow.com/sn_appstore_store.do#!/store/application/6c8e2a4edbc73410e1c75e25ca961947/1.0.5?

Zendesk: https://www.zendesk.com/marketplace/apps/support/202570/webex-contact-center/

Installationen av Marketplace-programmet aktiverar nödvändiga plugin-program och importerar de nödvändiga XML filerna till CRM-konsolen för att stödja rapportering av samtalsposter på CRM.

Flödesintegreringar via HTTPs-anslutningsappar i IVR

Webex CC Flow-byggaren stöder dubbelriktade dataflöden mellan Webex CC och CRM-systemet med HTTPs-anslutningar som konfigurerats i Webex Control Hub och används på Webex CC Flow.

Dessa används främst för personalisering inom röstinteraktioner och anpassad routing inom IVR.

Som standard stöder Webex CC Salesforce HTTP Connector på Control Hub. De andra CRM-kopplingarna kan läggas till som anpassade anslutningsprogram i Webex Control Hub.

Mer information om HTTP-anslutningsappar finns i https://github.com/CiscoDevNet/webex-contact-center-crm-integrations.

IVR HTTP-anslutningar:

• Salesforce IVR HTTP-anslutning (inbyggd): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/Salesforce/salesforce-ivr-http-connector

• Zendesk IVR HTTP-anslutning (anpassad): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/Zendesk/zendesk-ivr-http-connector

• ServiceNow IVR HTTP-anslutning (anpassad): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/ServiceNow/servicenow-ivr-http-connector

Röstinfrastruktur på Edge

Voice Edge-komponenterna gör det möjligt för SIP-trunkar från kundnätverk / PSTN-operatörer att avslutas, och detta aktiveras baserat på vitlistade IP-adresser som får ansluta till gränskomponenterna.

Säkerhet för beräkningsinfrastruktur

Webex CC-beräkningsinstanser etableras i AWS och tjänster körs som poddar i Kubernetes-kluster som har flera namnrymder och åtkomsten till varje namnområde är begränsad med separata autentiseringsuppgifter.

All etablering av infrastruktur görs med hjälp av kod – inga manuella steg – och ingen av autentiseringsuppgifterna kan nås manuellt.

Det finns ett centralt arkiv med specifika sökvägar konfigurerade för en specifik uppsättning tjänster/team och åtkomsten till själva arkivet för autentiseringsuppgifter är begränsad och konfigurerad som hemligheter i bygg- och distributionssystemen.

Ingen av infrastrukturkomponenterna/tjänsterna är direkt exponerade utanför AWS VPC och endast offentligt exponerade gränssnitt är API:er och WebSocket-servrar som styrs och hanteras med hjälp av api-gateway,

Bortsett från detta finns det vissa interna system och gränssnitt som används av utvecklare som används för att visa loggar, mätvärden, distributionsdetaljer, byggstatus och testresultat, som är säkrade med roller och grupper och integrerade med Ciscos interna autentiseringssystem.

Autentisering och auktorisering för användargränssnitt

Alla användargränssnitt som används av olika kontaktcenteranvändare (agenter, arbetsledare, administratörer, analytiker) skyddas av OAuth-flöden (Cisco Common Identity-baserad autentisering med innehavartoken).

Auktoriseringen görs med hjälp av roller för den användare som hämtade token och omfång som tilldelats token.

Data under överföring

Inget av gränssnitten för den distribuerade tjänste-/infrastrukturkomponenten exponeras direkt för extern inkommande trafik.

Välj tjänster, med http-API:er exponerar dessa gränssnitt via en gateway och alla inkommande https (inklusive WebSocket) avslutas i ALB och intern trafik över http dirigeras till tjänsterna.

Alla utgående interaktioner är över https / TLS (för icke-http-protokoll).

Inuti VPC är den interna kommunikationen mellan tjänster – över http / custom TCP protokoll - över vanligt TCP uttag.

Vilande data

All data som lagras krypteras på lagringslagret. Vidare är de datalager som ligger utanför VPC skyddade och åtkomstkontroll och behörigheter med autentiseringsuppgifter säkert lagrade och hanterade i ett hemligt arkiv.

Figur 1 illustrerar dataflödes- och säkerhetsmodellen för överföring och i vila.

PII-data för slutanvändare

Webex CC Flow, som är den programmatiska styrenheten för hantering av interaktioner, kan användas för att samla in användardata, som kan tilldelas flödesvariabler som är särskilt märkta som "Innehåller känsliga data". Värdena för sådana data är krypterade och inga tjänster i överföringsvägen för data kommer att ha åtkomst till dessa data.

Vidare bevaras aldrig sådana data i Webex CC-rapporteringsdatalager och loggarna / meddelandeinfrastrukturen kommer att ha krypterade data och klartextdata lagras inte någonstans inom Webex CC.

PII-data för kontaktcenteragent/arbetsledare

Kontaktcentrets användarrelaterade data redigeras i loggar men är tillgängliga för dataanalys och visualisering i Webex CC-datalagret.

Faktorer för skala

För Webex CC är de faktorer som påverkar skalan:

• Samtidiga antal inloggade agenter

• Samtidig antal pågående interaktioner

  • Åtgärder som utförts på dessa interaktioner

• Samtidig antal åtgärder som arbetsledare/agenter utför, utöver hanteringen av interaktionerna

• Mängden data som genererats och bevarats

Arkitektoniska aspekter som möjliggör skalbarhet

De principer som Webex CC bygger på och utformas gör att lösningen kan skalas dynamiskt efter behov inom de gränser som tillämpas av den infrastruktur som tillhandahålls för de olika tjänsterna och plattformskomponenterna.

Händelsedriven arkitektur

Tjänsterna i Webex CC kommunicerar med hjälp av meddelanden och de kritiska meddelandebearbetningsflödena innebär inte några blockerande I/O-åtgärder och det tillstånd som krävs för bearbetning av meddelanden lokaliseras till instansen av tjänsten som bearbetar meddelandet.

Tillståndslösa tjänster (eller externt tillstånd)

Tillståndslösa tjänster möjliggör elasticitet genom att enkelt lägga till/ta bort ytterligare instanser av tjänsterna. Det finns vissa tjänster som i sig är tillståndsfulla till sin natur och de har externaliserat tillståndslager och infrastrukturen stöder dynamiska förändringar av antalet instanser av sådana tjänster också med automatisk ombalansering / tillståndsöverföring / lokalisering av tillståndet till den instans som behöver tillståndet.

Elastisk infrastruktur

Alla tjänster körs i Kubernetes och infrastrukturen, även kallad Kubernetes-noder, skalas automatiskt baserat på användningen och detta gör det möjligt att dynamiskt lägga till fler beräkningsnoder upp till ett maximalt högt tröskelvärde som är förkonfigurerat.

Laddningsprojektion och regelbunden validering

Alla tjänster jämförs för prestandaegenskaper och skalningsmönster valideras på servicenivå.

Ytterligare kontinuerliga validerings-, toppbelastnings- och uthållighetstester utförs med testparametrar justerade för beräknad tillväxt i skalan som påverkar attribut, vilket gör det möjligt att identifiera flaskhalsar, planera att uppdatera den höga tröskeln för infrastrukturresursanvändning och vara redo för speldagen.

Telefoni

För telefoni bestäms hanteringen av inkommande röstsamtal av hur samtalet kom in i kontaktcentret (se Ingressmekanismer nedan) och det Webex CC-flöde som är associerat med startpunkten.

Samtalet besvaras och ytterligare åtgärder utförs enligt Webex CC Flow-definitionen - vilket är en programmatisk representation av de åtgärder som ska utföras vid hantering av samtalet, antingen före kö och dirigering till en agent eller själva flödet kan hantera samtalet utan överföring till en agent.

Med Flow Builder i Webex CC kan utvecklare definiera flödet och tilldela det till startpunkten via vilken samtalet tas emot i Webex CC.

Dessa konfigurationsentiteter och deras användning omfattas av konfigurationsentiteter.

Mer information om Flow Builder finns i det kommande avsnittet om IVR System.

E-post och meddelanden

Ur Webex CC-perspektiv tillhandahåller Webex Connect in- och utgångsfunktioner för alla digitala kanaler - e-post, meddelandekanaler, som slutanvändare kan använda för att kontakta kontaktcenter.

Webex Connect Flow

• Bestämmer hanteringen av sådana interaktioner tills interaktionerna köas och dirigeras till agenter. Detta inkluderar automatisk hantering och BOT-behandlingar för alla former av meddelanden och e-postinteraktioner.

• Tillämpar affärslogik på inkommande interaktion.

• Hanterar kontakt före kö.

• Flow själv kan hantera interaktionen utan överföring till live-agent.

De meddelandekanaler som stöds av Webex CC är:

• Web App / Chatt med mobilapp

• WhatsApp

• Facebook Messenger

• SMS

De e-postkanaler som stöds av Webex CC är:

• Gmail

• Office365

Ingressmekanismer

Det här avsnittet beskriver de mekanismer genom vilka en interaktion kan komma in Webex CC. Baserat på medietypen är mekanismerna genom vilka en interaktion når Webex CC olika.

Inom telefoni krävs till exempel etablering av fysisk infrastruktur för att aktivera PSTN-anslutning, konfiguration av telefonnummer och dirigering av samtalen till Webex CC.

För e-post-/meddelandekanaler måste ingresskonfigurationen göras i Webex Connect och det omfattar etablering av e-post-/meddelandekonto och Webex Connect-flödeskonfiguration.

Inkommande röst

För röstsamtal är ett typiskt scenario där användare ringer ett PSTN-telefonnummer som sedan ansluts till kontaktcentret. Ur ett ingångsperspektiv behöver detta en mekanism för att dirigera samtal från PSTN till Webex CC.

Följande bild illustrerar inmatningen av röstsamtal till Webex kopia.

Voice Ingress Services i Webex CC utför samtalskontroll från tredje part med SIP och besvarar det inkommande samtalet samt utför överförings-, konferens- och andra samtalskontrollåtgärder.

Den logiska startpunkten för samtal i Webex CC är konfigurationsenheten med namnet "Entrypoint". För röstingress är nyckelkonfigurationen för Entrypoint det telefonnummer som är associerat med den, vilket vanligtvis är ett giltigt PSTN-telefonnummer som hämtas från den valda PSTN-leverantören.

Detta gör det möjligt att upptäcka inkommande samtal på telefonnumret, associera samtalet till startpunkten och använda andra konfigurationsparametrar för startpunkten för att hantera samtalet enligt Webex CC-flödesdefinitionen som ska utlösas för interaktionen.

Obs:

Mer information om PSTN-anslutningsalternativen finns i https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/webexcc/Voiceonboarding2/wcc-voice-onboarding-2-book/wcc_b__voiceonboarding_private_conn.html.

Skalbarhet och tillgänglighet för röstkantsinfrastruktur

Webex CC VPOP-infrastrukturen innehåller redundanta par SIP-SBC:er som säkerställer hög tillgänglighet och fler SBC:er kan läggas till för att skala de samtidiga samtalsvolymer som ska stödjas.

Det maximala antalet samtidiga samtal som VPOP kan hantera beror på antalet SBC:er som körs och till vilka samtal som skickas.

För geografisk redundans stöds ett nät av VPOP SBC med sammankopplingar över flera par mellan regioner.

För röstingresstjänster är de horisontellt skalbara för att hantera ett ökande antal samtidiga röstsamtal som ska matas in till Webex CC.

Säkerhetsöverväganden med röstgränsinfrastruktur

Tabellen nedan innehåller information om anslutningsalternativen till Voice Edge Infrastructure.

För mer information, besök https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/webexcc/Voiceonboarding2/wcc-voice-onboarding-2-book/wcc_b__voiceonboarding_private_conn.html.

IVR-systemet

Varje röstsamtal som kommer in till ett telefonnummer som är kopplat till en startpunkt, besvaras av Webex kopia och körning av ett Webex CC-flöde som är associerat med startpunkten startas.

Webex CC Flow Builder tillhandahåller programmeringskonstruktioner/operatorer och funktionsblock, så kallade aktiviteter, så att administratörer eller någon som utformar och implementerar den IVR logiken kan kombinera dessa byggstenar och skapa Flow-definitionen.

Programmeringskonstruktionerna som Flow stöder är:

• Deklarations- och inställningsvariabler – tillstånd som är associerat med en flödeskörning

  • Pebble-uttryck för att ange värde för variabler

• Villkorliga kontroller

• Looping - med hjälp av villkor och gå till (möjlighet att länka aktiviteter tillsammans)

• Anropa REST-API:er

• Parsa data – JSON, TOML XML används vanligtvis för att parsa API svar.

• Komponera aktiviteter

En representativ uppsättning aktiviteter som Flow levererar är: Spela upp meddelanden Samla in användardata Överföra samtalet till en annan destination/ett annat telefonnummer Skicka samtalet till en virtuell agent Ställ samtalet i kö så att det kan besvaras av en agent.

För varje samtal som är aktivt är även en instans av flödeskörning aktiv tills samtalet avslutas, vilket resulterar i samtidiga körningar av flöden.

Varje instans av flödeskörning ger isolerad miljö för data / tillstånd som är associerat med flödet och där av samtalet.

Under samtalets hela livscykel gör flödet det också möjligt att svara på vissa händelser som inträffar och hantera dem – till exempel när ett samtal besvaras av en agent kan en händelsehanterare utlösa en skärmfönster i agentens skrivbordsgränssnitt.

Mer information om Webex CC Flow finns ihttps://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/webexcc/SetupandAdministrationGuide_2/b_mp-release-2/b_cc-release-2_chapter_0100.html#Cisco_Generic_Topic.dita_e338e055-64b0-4973-bd52-8a5581dcb0ee.

Stöd för virtuell agent

Flow tillhandahåller en aktivitet för att överföra interaktionen till en virtuell agent som är förkonfigurerad i Webex Control Hub.

När samtalet är kopplat till en virtuell agent ger det användaren en konversations- IVR upplevelse och aktiviteten slutar antingen med att samtalet avslutas eller med att samtalet eskaleras till en agent.

Vid eskalering kan flödet konfigureras för att köa samtalet som sedan besvaras av en agent.

Inkommande digitala interaktioner

För e-post och meddelandekanal för inkommande interaktioner använder Webex CC Webex Connect för etablering av tillgångarna, flöde för att hantera inkommande interaktioner och dirigerar sedan interaktionen till Webex CC när Webex Connect-flödet uttryckligen köar interaktionen så att den kan hanteras av en agent.

Följande bild illustrerar inmatning av e-post och meddelandeinteraktioner i Webex kopia.

Virtuell agent / BOT-integrationer

För interaktion via e-post och meddelanden/sociala kanaler konfigureras den virtuella agenten/BOT-behandlingarna i Webex Connect-flödet.

Precis som med Virtual Agents for Voice köas interaktionen och dirigeras till en agent om BOT-behandlingen slutar med eskalering som resultat.

Val av agent

Köer i Webex CC stöder följande algoritmer för agentval:

• Längsta tillgängliga agentroutning

• Kompetent baserad routing

  • Agent som är tillgänglig längst (LAA)

  • Bästa tillgängliga agent (BAA)

Agenter associeras med köer via team.

En kö kan tilldelas flera samtalsdistributionsgrupper (där varje grupp har ett eller flera team) på ett sekventiellt sätt med konfigurerad väntan på att samtalsdistributionsgruppen ska läggas till i kön, så att sökutrymmet för en matchande agent utökas till ytterligare samtalsdistributionsgrupper med tiden.

För färdighetsbaserad routning väljs en agent baserat på LAA- eller BAA-konfigurationer bland de kunskapskrav som matchar agenter som är associerade med kön.

Specifika extrafunktioner för röst-/telefoni

Agentbaserad routning (endast för röst-/telefonikanal)

Webex CC Flow kan med aktiviteten QueueToAgent dirigera interaktioner direkt till den valda agenten baserat på agentens ID.

Om agenten inte är tillgänglig för att hantera interaktioner kan interaktionen parkeras i en agentspecifik kö i väntan på att agenten blir tillgänglig

Avancerad köinformation

Webex CC Flow kan med hjälp av aktiviteten GetQueueInfo hämta realtidsinformation för en kö som Position in Queue (PIQ), Estimated Wait Time (EWT), antal agenter som är tillgängliga i kön och kan användas för att avgöra om kontakten ska placeras i kö eller inte.

Återuppringning med tillstånd

Webex CC Flow, som använder aktiviteten Återuppringning, låter kunden koppla bort samtalet med bibehållen position i kön och få en återuppringning när den virtuella interaktionen i kön dirigeras till en agent.

Hantering av spill

Webex CC stöder spillhantering med hjälp av kapacitetsbaserade team (CBT).

KBT är som ett vanligt team med en kapacitet och ett tillhörande externt DN som tjänar den kapaciteten. Den kan konfigureras tillsammans med andra team i distributionscyklerna för kösamtal.

Vanligtvis konfigureras detta som den senaste cykeln så att den fungerar som ett spill om ingen agent är tillgänglig även om alla konfigurerade samtalsdistributionsgrupper inte hittar en tillgänglig matchande agent för att hantera interaktionen.

Agent Desktop operationer

När en agent loggar in Webex CC Agent Desktop anger agenten ett telefonnummer som inkommande samtal till agenten kan kopplas till. Det kan vara en PSTN-telefon, mobiltelefon eller en anknytning om agenten är en Cisco Webex Calling användare.

Observera att detta nummer måste vara ett giltigt telefonnummer som samtal kan kopplas till. Om den inte är det kan agenten inte ta emot inkommande samtal.

Beroende på vilken typ av interaktion agenten hanterar kan widgetarna på agentskrivbordet utföra vissa mediekontrollåtgärder.

När ett samtal har besvarats kan agenten till exempel utföra följande åtgärder i samband med samtalet.

• Parkera samtalet

• Starta konsultsamtal och

  • Överför samtalet till ett annat telefonnummer (t.ex. agentens telefonnummer) / startpunkt

  • Ge en annan agent konferenssamtal

• Överföra samtalet till en annan kö

• Avsluta samtalet

Med Agent Desktop kan administratörer lägga till anpassade widgetar där genom att utöka skrivbordsfunktionerna och göra det till en enhetlig samling widgetar som agenter behöver för att få jobbet gjort på ett effektivt sätt.

Skrivbordsarkitektur

Agent Desktop är ett micro frontend-baserat ensidesprogram som är värd för widgetar byggda baserat på arkitektur för webbkomponenter. Alla standard- / lagerwidgets drivs av data som hämtas av API: er eller push-mekanismer på serversidan.

Dessa är vanligtvis asynkrona API:er, där svaret för ett anrop kommer till skrivbordet via en WebSocket-anslutning.

Webex CC autentiserar Agent Desktop användare med Cisco Common Identity (CI) och token skickas vidare till alla API anrop. Även för anpassade widgetar, baserat på autentiseringsmodellen, ger det agenter enkel inloggning om den anpassade widgetens autentiseringsmodell är integrerad med CI.

När en agent är en del av en interaktion skickas alla uppdateringar av interaktionstillståndet eller associerade data till skrivbordet via WebSocket-anslutningen.

Skrivbordets motståndskraft mot anslutning och svarstid

Den asynkrona API- och serversidans push möjliggör skalning och eventuella anslutningsförluster till WebSocket-gränssnittet identifieras och skrivbordet försöker återansluta och logga in igen.

Följande bild illustrerar agentskrivbordsarkitekturen i Webex CC.

Onboarding av kunder

Webex Control Hub är det primära gränssnittet som används av partner och kunder för att registrera kunder och aktivera eller konfigurera funktioner.

När organisationen och kontaktcenterfunktionerna har etablerats i Control Hub utlöser det ett arbetsflöde i Webex CC som gör resten av stegen i etableringen av alla kontaktcenterfunktioner enligt de erbjudanden som kunden valt.

All etablering av kontaktcenter görs med hjälp av en BPM-arbetsflödesmotor som möjliggör ett deklarativt sätt att definiera de steg som ingår och gör hela etableringsstegen motståndskraftiga mot fel och säkerställer dataintegritet.

Följande bild illustrerar etableringsarbetsflödet i Webex kopia.

Konfigurationsentiteter

De viktigaste konfigurationsentiteterna i Webex CC, som är begränsade inom en organisation, är:

Plats

Plats betyder en plats där ett eller flera team, användare (agenter / arbetsledare) finns.

Varje användare och team måste tillhöra en webbplats.

Team

En grupp användare. Team används för att distribuera interaktioner till agenter via köer.

Varje team måste tillhöra en webbplats.

Agenter

Användare som kan logga in i Agent Desktop och hantera interaktioner mellan de medietyper som konfigureras i Webex CC.

Arbetsledare

Arbetsledare tilldelas team och kan övervaka/coacha agenten och har tillgång till status på teamnivå och agentstatistik för de som tillhör de team som arbetsledaren är tilldelad till.

Kö

En kö är en logisk enhet där interaktioner kan hållas i väntan på att agenter ska bli tillgängliga, som sedan dirigeras till agenten.

Köer mappas till team, som sökutrymme för agenter, med möjlighet att utöka sökutrymmet baserat på tröskeln för förfluten tid genom att lägga till andra team i sökutrymmet.

Startpunkt

Startpunkt är en logisk entitet som representerar ingångspunkten för interaktioner som ska komma in i Webex kopia. För telefoni mappas detta främst till telefonnumret som samtalen kommer till och för e-post-/meddelandekanaler pekar startpunkten på resurskonfigurationen i Webex Connect.

Flöde

Det flöde som är associerat med startpunkten (via routningsstrategin), som bestämmer vilka steg som ska ingå i hanteringen av interaktioner.

För icke-telefonikanaler (e-post, meddelanden/sociala medier) väljs Flow som en del av resurskonfigurationen i Webex Connect.

Åtkomstkontroll för kontaktcenter på flera platser

Webex CC-administratörer kan konfigurera användarprofiler med åtkomsträttigheter till specifika platser, team, köer och startpunkter. På grund av webbplatsernas och teamens hierarkiska karaktär kan användaren dessutom komma åt endast de team eller det datum som hör till teamen, som tillhör dessa webbplatser eller en uttryckligen angiven delmängd av sådana team, när åtkomst till specifika webbplatser har tillhandahållits.

För köer och startpunkter är de globala på organisationsnivå, så för olika geografiska platser (platser där specifika agenter och team finns) kan separata startpunkter och köer konfigureras, och arbetsledare / användare kan ha åtkomst till de enheter som är tillämpliga för specifika platser.

Följande bild illustrerar de viktigaste konfigurationsentiteterna och användarprofilen som refererar till dessa entiteter.

Förutom att begränsa åtkomsten till dessa enheter kan Webex CC-administratörer styra de specifika funktioner/moduler som en användare kan komma åt i administrationsgränssnittet och därigenom ha användare med administrations-/konfigurationsbehörighet till specifika enheter samt sektioner/funktioner i Webex CC-administrationsgränssnittet.

Skrivbordsinbäddade anslutningar: CRM-program som primärt gränssnitt

I det här läget loggar agenten in på CRM-konsolen som primärt program.

Webex CC är ett inbäddat program (även kallat ett inbäddat skrivbordsprogram eller inbäddad softphone) som främst används för att logga in på kontaktcentret och ta emot Webex CC-dirigerade kontaktcenterinteraktioner.

När du tar emot ett samtal eller en konversationsförfrågan utför CRM-integreringen följande åtgärder på CRM-konsolen

• Skärma upp kundposten som är knuten till ANI eller andra samtalsrelaterade data.

• Metadata efter samtal som aktivitetsanteckningar i kundposten

• Låt agenten "Click to Call" genom att klicka på kontakten i CRM och initiera ett utgående samtal till kunden

• Bokföra samtalsposter i CRM-rapporteringstabellerna för primär rapportering på CRM.

• Ger alla funktioner i Agent Desktop- och samtalskontrollerna (inbäddad och minifierad version av skrivbordsappen)

Det primära sättet att integrera med CRM: erna är genom att bädda in Webex CC Desktop-applikation i en separat iFrame.

Dessutom kör Webex CC Desktop-programmet en anpassad headless-widget (inget användargränssnitt) som körs i bakgrunden och interagerar med det underliggande CRM-systemet för att utföra automatiserade åtgärder på uppdrag av agenten.

Interaktionerna drivs av två SDK: er som den headless-widgeten använder.

• Webex CC Desktop JS SDK: Detta är JavaScript SDK som tillhandahålls av Webex CC för att registrera händelseavlyssnare för agent- och kontaktåtgärder.

• CRM JS SDK: Det här är CRM-klient-SDK:n som gäller per CRM och som abstraherar REST-API-anrop med CRM. Till exempel för salesforce används CTI JS-biblioteket som tillhandahålls av Salesforce för att utföra åtgärder och lyssna efter händelser i CRM.

Följande bild illustrerar CRM inbäddad Webex CC skrivbords- och anslutningsarkitektur

Webex CC stöder följande CRM-lösningar för ovan nämnda integration:

• Salesforce

• ServiceNu

• Microsoft Dynamics 365

• Zendesk

• Freshdesk

Mer information finns i https://help.webex.com/en-us/result/integrate%20with%20webex%20contact%20center?offset=10.

Mer information om hur du konfigurerar Webex CC-skrivbordslayouter för aktivering av CRM-anslutning, funktionsuppsättningar och ändringsloggar finns på https://github.com/Ciscodevnet/webex-contact-center-crm-integrations.

Global tillgänglighet för CRM-kopplingar

CRM-anslutningsapparna är tillgängliga i alla geografiska områden och regioner där Webex CC används.

Elastisk skala och prestanda

Webex CC är värd för den anpassade widgeten som möjliggör dubbelriktad kommunikation mellan CRM-applikationen och Webex CC-skrivbordet i AWS CloudFront CDN, vilket säkerställer hög tillgänglighet för widgeten AWS över tillgänglighetszoner och regioner.

All CRM-integrationsspecifik beräkning sker i webbläsaren där agenter använder CRM-programmet med Webex CC-skrivbord inbäddat i CRM-programmet.

Säkerhet

CRM-kopplingarna anropas via Webex CC-agentskrivbordslayouten och valfria parametrar skickas via skrivbordslayouten till widgeten för att aktivera och inaktivera funktioner.

Om du till exempel vill aktivera widgeten Salesforce-åtgärder kan administratören aktivera skrivbordslayoutparameterinställningen sfdcWidgetEnabled till true.

Installation av paket

För att integreringen ska fungera dubbelriktat måste CRM-konsolen ha det inbäddade programmet installerat. Detta för att stödja laddning av skrivbordsprogrammet inuti en iFrame.

Alla Desktop Embedded-kopplingar är tillgängliga på CRM-marknadsplatsen.

Till exempel,

ServiceNow: https://store.servicenow.com/sn_appstore_store.do#!/store/application/6c8e2a4edbc73410e1c75e25ca961947/1.0.5?

Zendesk: https://www.zendesk.com/marketplace/apps/support/202570/webex-contact-center/

Installationen av Marketplace-programmet aktiverar nödvändiga plugin-program och importerar de nödvändiga XML filerna till CRM-konsolen för att stödja rapportering av samtalsposter på CRM.

Flödesintegreringar via HTTPs-anslutningsappar i IVR

Webex CC Flow-byggaren stöder dubbelriktade dataflöden mellan Webex CC och CRM-systemet med HTTPs-anslutningar som konfigurerats i Webex Control Hub och används på Webex CC Flow.

Dessa används främst för personalisering inom röstinteraktioner och anpassad routing inom IVR.

Som standard stöder Webex CC Salesforce HTTP Connector på Control Hub. De andra CRM-kopplingarna kan läggas till som anpassade anslutningsprogram i Webex Control Hub.

Mer information om HTTP-anslutningsappar finns i https://github.com/CiscoDevNet/webex-contact-center-crm-integrations.

IVR HTTP-anslutningar:

• Salesforce IVR HTTP-anslutning (inbyggd): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/Salesforce/salesforce-ivr-http-connector

• Zendesk IVR HTTP-anslutning (anpassad): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/Zendesk/zendesk-ivr-http-connector

• ServiceNow IVR HTTP-anslutning (anpassad): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/ServiceNow/servicenow-ivr-http-connector

Röstinfrastruktur på Edge

Voice Edge-komponenterna gör det möjligt för SIP-trunkar från kundnätverk / PSTN-operatörer att avslutas, och detta aktiveras baserat på vitlistade IP-adresser som får ansluta till gränskomponenterna.

Säkerhet för beräkningsinfrastruktur

Webex CC-beräkningsinstanser etableras i AWS och tjänster körs som poddar i Kubernetes-kluster som har flera namnrymder och åtkomsten till varje namnområde är begränsad med separata autentiseringsuppgifter.

All etablering av infrastruktur görs med hjälp av kod – inga manuella steg – och ingen av autentiseringsuppgifterna kan nås manuellt.

Det finns ett centralt arkiv med specifika sökvägar konfigurerade för en specifik uppsättning tjänster/team och åtkomsten till själva arkivet för autentiseringsuppgifter är begränsad och konfigurerad som hemligheter i bygg- och distributionssystemen.

Ingen av infrastrukturkomponenterna/tjänsterna är direkt exponerade utanför AWS VPC och endast offentligt exponerade gränssnitt är API:er och WebSocket-servrar som styrs och hanteras med hjälp av api-gateway,

Bortsett från detta finns det vissa interna system och gränssnitt som används av utvecklare som används för att visa loggar, mätvärden, distributionsdetaljer, byggstatus och testresultat, som är säkrade med roller och grupper och integrerade med Ciscos interna autentiseringssystem.

Autentisering och auktorisering för användargränssnitt

Alla användargränssnitt som används av olika kontaktcenteranvändare (agenter, arbetsledare, administratörer, analytiker) skyddas av OAuth-flöden (Cisco Common Identity-baserad autentisering med innehavartoken).

Auktoriseringen görs med hjälp av roller för den användare som hämtade token och omfång som tilldelats token.

Data under överföring

Inget av gränssnitten för den distribuerade tjänste-/infrastrukturkomponenten exponeras direkt för extern inkommande trafik.

Välj tjänster, med http-API:er exponerar dessa gränssnitt via en gateway och alla inkommande https (inklusive WebSocket) avslutas i ALB och intern trafik över http dirigeras till tjänsterna.

Alla utgående interaktioner är över https / TLS (för icke-http-protokoll).

Inuti VPC är den interna kommunikationen mellan tjänster – över http / custom TCP protokoll - över vanligt TCP uttag.

Vilande data

All data som lagras krypteras på lagringslagret. Vidare är de datalager som ligger utanför VPC skyddade och åtkomstkontroll och behörigheter med autentiseringsuppgifter säkert lagrade och hanterade i ett hemligt arkiv.

Följande bild illustrerar dataflödes- och säkerhetsmodellen för överföring och i vila.

PII-data för slutanvändare

Webex CC Flow, som är den programmatiska styrenheten för hantering av interaktioner, kan användas för att samla in användardata, som kan tilldelas flödesvariabler som är särskilt märkta som "Innehåller känsliga data". Värdena för sådana data är krypterade och inga tjänster i överföringsvägen för data kommer att ha åtkomst till dessa data.

Vidare bevaras aldrig sådana data i Webex CC-rapporteringsdatalager och loggarna / meddelandeinfrastrukturen kommer att ha krypterade data och klartextdata lagras inte någonstans inom Webex CC.

PII-data för kontaktcenteragent/arbetsledare

Kontaktcentrets användarrelaterade data redigeras i loggar men är tillgängliga för dataanalys och visualisering i Webex CC-datalagret.

Faktorer för skala

För Webex CC är de faktorer som påverkar skalan:

• Samtidiga antal inloggade agenter

• Samtidig antal pågående interaktioner

  • Åtgärder som utförts på dessa interaktioner

• Samtidig antal åtgärder som arbetsledare/agenter utför, utöver hanteringen av interaktionerna

• Mängden data som genererats och bevarats

Arkitektoniska aspekter som möjliggör skalbarhet

De principer som Webex CC bygger på och utformas gör att lösningen kan skalas dynamiskt efter behov inom de gränser som tillämpas av den infrastruktur som tillhandahålls för de olika tjänsterna och plattformskomponenterna.

Händelsedriven arkitektur

Tjänsterna i Webex CC kommunicerar med hjälp av meddelanden och de kritiska meddelandebearbetningsflödena innebär inte några blockerande I/O-åtgärder och det tillstånd som krävs för bearbetning av meddelanden lokaliseras till instansen av tjänsten som bearbetar meddelandet.

Tillståndslösa tjänster (eller externt tillstånd)

Tillståndslösa tjänster möjliggör elasticitet genom att enkelt lägga till/ta bort ytterligare instanser av tjänsterna. Det finns vissa tjänster som i sig är tillståndsfulla till sin natur och de har externaliserat tillståndslager och infrastrukturen stöder dynamiska förändringar av antalet instanser av sådana tjänster också med automatisk ombalansering / tillståndsöverföring / lokalisering av tillståndet till den instans som behöver tillståndet.

Elastisk infrastruktur

Alla tjänster körs i Kubernetes och infrastrukturen, även kallad Kubernetes-noder, skalas automatiskt baserat på användningen och detta gör det möjligt att dynamiskt lägga till fler beräkningsnoder upp till ett maximalt högt tröskelvärde som är förkonfigurerat.

Laddningsprojektion och regelbunden validering

Alla tjänster jämförs för prestandaegenskaper och skalningsmönster valideras på servicenivå.

Ytterligare kontinuerliga validerings-, toppbelastnings- och uthållighetstester utförs med testparametrar justerade för beräknad tillväxt i skalan som påverkar attribut, vilket gör det möjligt att identifiera flaskhalsar, planera att uppdatera den höga tröskeln för infrastrukturresursanvändning och vara redo för speldagen.

Telefoni

För telefoni bestäms hanteringen av inkommande röstsamtal av hur samtalet kom in i kontaktcentret (se Ingressmekanismer nedan) och det Webex CC-flöde som är associerat med startpunkten.

Samtalet besvaras och ytterligare åtgärder utförs enligt Webex CC Flow-definitionen - vilket är en programmatisk representation av de åtgärder som ska utföras vid hantering av samtalet, antingen före kö och dirigering till en agent eller själva flödet kan hantera samtalet utan överföring till en agent.

Med Flow Builder i Webex CC kan utvecklare definiera flödet och tilldela det till startpunkten via vilken samtalet tas emot i Webex CC.

Dessa konfigurationsentiteter och deras användning omfattas av konfigurationsentiteter.

Mer information om Flow Builder finns i det kommande avsnittet om IVR System.

E-post och meddelanden

Ur Webex CC-perspektiv tillhandahåller Webex Connect in- och utgångsfunktioner för alla digitala kanaler - e-post, meddelandekanaler, som slutanvändare kan använda för att kontakta kontaktcenter.

Webex Connect Flow

• Bestämmer hanteringen av sådana interaktioner tills interaktionerna köas och dirigeras till agenter. Detta inkluderar automatisk hantering och BOT-behandlingar för alla former av meddelanden och e-postinteraktioner.

• Tillämpar affärslogik på inkommande interaktion.

• Hanterar kontakt före kö.

• Flow själv kan hantera interaktionen utan överföring till live-agent.

De meddelandekanaler som stöds av Webex CC är:

• Web App / Chatt med mobilapp

• WhatsApp

• Facebook Messenger

• SMS

De e-postkanaler som stöds av Webex CC är:

• Gmail

• Office365

Ingressmekanismer

Det här avsnittet beskriver de mekanismer genom vilka en interaktion kan komma in Webex CC. Baserat på medietypen är mekanismerna genom vilka en interaktion når Webex CC olika.

Inom telefoni krävs till exempel etablering av fysisk infrastruktur för att aktivera PSTN-anslutning, konfiguration av telefonnummer och dirigering av samtalen till Webex CC.

För e-post-/meddelandekanaler måste ingresskonfigurationen göras i Webex Connect och det omfattar etablering av e-post-/meddelandekonto och Webex Connect-flödeskonfiguration.

Inkommande röst

För röstsamtal är ett typiskt scenario där användare ringer ett PSTN-telefonnummer som sedan ansluts till kontaktcentret. Ur ett ingångsperspektiv behöver detta en mekanism för att dirigera samtal från PSTN till Webex CC.

Följande bild illustrerar inmatningen av röstsamtal till Webex kopia.

Voice Ingress Services i Webex CC utför samtalskontroll från tredje part med SIP och besvarar det inkommande samtalet samt utför överförings-, konferens- och andra samtalskontrollåtgärder.

Den logiska startpunkten för samtal i Webex CC är konfigurationsenheten med namnet "Entrypoint". För röstingress är nyckelkonfigurationen för Entrypoint det telefonnummer som är associerat med den, vilket vanligtvis är ett giltigt PSTN-telefonnummer som hämtas från den valda PSTN-leverantören.

Detta gör det möjligt att upptäcka inkommande samtal på telefonnumret, associera samtalet till startpunkten och använda andra konfigurationsparametrar för startpunkten för att hantera samtalet enligt Webex CC-flödesdefinitionen som ska utlösas för interaktionen.

Obs:

Mer information om PSTN-anslutningsalternativen finns i https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/webexcc/Voiceonboarding2/wcc-voice-onboarding-2-book/wcc_b__voiceonboarding_private_conn.html.

Skalbarhet och tillgänglighet för röstkantsinfrastruktur

Webex CC VPOP-infrastrukturen innehåller redundanta par SIP-SBC:er som säkerställer hög tillgänglighet och fler SBC:er kan läggas till för att skala de samtidiga samtalsvolymer som ska stödjas.

Det maximala antalet samtidiga samtal som VPOP kan hantera beror på antalet SBC:er som körs och till vilka samtal som skickas.

För geografisk redundans stöds ett nät av VPOP SBC med sammankopplingar över flera par mellan regioner.

För röstingresstjänster är de horisontellt skalbara för att hantera ett ökande antal samtidiga röstsamtal som ska matas in till Webex CC.

Säkerhetsöverväganden med röstgränsinfrastruktur

Tabellen nedan innehåller information om anslutningsalternativen till Voice Edge Infrastructure.

För mer information, besök https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/webexcc/Voiceonboarding2/wcc-voice-onboarding-2-book/wcc_b__voiceonboarding_private_conn.html.

IVR-systemet

Varje röstsamtal som kommer in till ett telefonnummer som är kopplat till en startpunkt, besvaras av Webex kopia och körning av ett Webex CC-flöde som är associerat med startpunkten startas.

Webex CC Flow Builder tillhandahåller programmeringskonstruktioner/operatorer och funktionsblock, så kallade aktiviteter, så att administratörer eller någon som utformar och implementerar den IVR logiken kan kombinera dessa byggstenar och skapa Flow-definitionen.

Programmeringskonstruktionerna som Flow stöder är:

• Deklarations- och inställningsvariabler – tillstånd som är associerat med en flödeskörning

  • Pebble-uttryck för att ange värde för variabler

• Villkorliga kontroller

• Looping - med hjälp av villkor och gå till (möjlighet att länka aktiviteter tillsammans)

• Anropa REST-API:er

• Parsa data – JSON, TOML XML används vanligtvis för att parsa API svar.

• Komponera aktiviteter

En representativ uppsättning aktiviteter som Flow levererar är: Spela upp meddelanden Samla in användardata Överföra samtalet till en annan destination/ett annat telefonnummer Skicka samtalet till en virtuell agent Ställ samtalet i kö så att det kan besvaras av en agent.

För varje samtal som är aktivt är även en instans av flödeskörning aktiv tills samtalet avslutas, vilket resulterar i samtidiga körningar av flöden.

Varje instans av flödeskörning ger isolerad miljö för data / tillstånd som är associerat med flödet och där av samtalet.

Under samtalets hela livscykel gör flödet det också möjligt att svara på vissa händelser som inträffar och hantera dem – till exempel när ett samtal besvaras av en agent kan en händelsehanterare utlösa en skärmfönster i agentens skrivbordsgränssnitt.

Mer information om Webex CC Flow finns ihttps://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/webexcc/SetupandAdministrationGuide_2/b_mp-release-2/b_cc-release-2_chapter_0100.html#Cisco_Generic_Topic.dita_e338e055-64b0-4973-bd52-8a5581dcb0ee.

Stöd för virtuell agent

Flow tillhandahåller en aktivitet för att överföra interaktionen till en virtuell agent som är förkonfigurerad i Webex Control Hub.

När samtalet är kopplat till en virtuell agent ger det användaren en konversations- IVR upplevelse och aktiviteten slutar antingen med att samtalet avslutas eller med att samtalet eskaleras till en agent.

Vid eskalering kan flödet konfigureras för att köa samtalet som sedan besvaras av en agent.

Inkommande digitala interaktioner

För e-post och meddelandekanal för inkommande interaktioner använder Webex CC Webex Connect för etablering av tillgångarna, flöde för att hantera inkommande interaktioner och dirigerar sedan interaktionen till Webex CC när Webex Connect-flödet uttryckligen köar interaktionen så att den kan hanteras av en agent.

Följande bild illustrerar inmatning av e-post och meddelandeinteraktioner i Webex kopia.

Virtuell agent / BOT-integrationer

För interaktion via e-post och meddelanden/sociala kanaler konfigureras den virtuella agenten/BOT-behandlingarna i Webex Connect-flödet.

Precis som med Virtual Agents for Voice köas interaktionen och dirigeras till en agent om BOT-behandlingen slutar med eskalering som resultat.

Val av agent

Köer i Webex CC stöder följande algoritmer för agentval:

• Längsta tillgängliga agentroutning

• Kompetent baserad routing

  • Agent som är tillgänglig längst (LAA)

  • Bästa tillgängliga agent (BAA)

Agenter associeras med köer via team.

En kö kan tilldelas flera samtalsdistributionsgrupper (där varje grupp har ett eller flera team) på ett sekventiellt sätt med konfigurerad väntan på att samtalsdistributionsgruppen ska läggas till i kön, så att sökutrymmet för en matchande agent utökas till ytterligare samtalsdistributionsgrupper med tiden.

För färdighetsbaserad routning väljs en agent baserat på LAA- eller BAA-konfigurationer bland de kunskapskrav som matchar agenter som är associerade med kön.

Specifika extrafunktioner för röst-/telefoni

Agentbaserad routning (endast för röst-/telefonikanal)

Webex CC Flow kan med aktiviteten QueueToAgent dirigera interaktioner direkt till den valda agenten baserat på agentens ID.

Om agenten inte är tillgänglig för att hantera interaktioner kan interaktionen parkeras i en agentspecifik kö i väntan på att agenten blir tillgänglig

Avancerad köinformation

Webex CC Flow kan med hjälp av aktiviteten GetQueueInfo hämta realtidsinformation för en kö som Position in Queue (PIQ), Estimated Wait Time (EWT), antal agenter som är tillgängliga i kön och kan användas för att avgöra om kontakten ska placeras i kö eller inte.

Återuppringning med tillstånd

Webex CC Flow, som använder aktiviteten Återuppringning, låter kunden koppla bort samtalet med bibehållen position i kön och få en återuppringning när den virtuella interaktionen i kön dirigeras till en agent.

Hantering av spill

Webex CC stöder spillhantering med hjälp av kapacitetsbaserade team (CBT).

KBT är som ett vanligt team med en kapacitet och ett tillhörande externt DN som tjänar den kapaciteten. Den kan konfigureras tillsammans med andra team i distributionscyklerna för kösamtal.

Vanligtvis konfigureras detta som den senaste cykeln så att den fungerar som ett spill om ingen agent är tillgänglig även om alla konfigurerade samtalsdistributionsgrupper inte hittar en tillgänglig matchande agent för att hantera interaktionen.

Agent Desktop operationer

När en agent loggar in Webex CC Agent Desktop anger agenten ett telefonnummer som inkommande samtal till agenten kan kopplas till. Det kan vara en PSTN-telefon, mobiltelefon eller en anknytning om agenten är en Cisco Webex Calling användare.

Observera att detta nummer måste vara ett giltigt telefonnummer som samtal kan kopplas till. Om den inte är det kan agenten inte ta emot inkommande samtal.

Beroende på vilken typ av interaktion agenten hanterar kan widgetarna på agentskrivbordet utföra vissa mediekontrollåtgärder.

När ett samtal har besvarats kan agenten till exempel utföra följande åtgärder i samband med samtalet.

• Parkera samtalet

• Starta konsultsamtal och

  • Överför samtalet till ett annat telefonnummer (t.ex. agentens telefonnummer) / startpunkt

  • Ge en annan agent konferenssamtal

• Överföra samtalet till en annan kö

• Avsluta samtalet

Med Agent Desktop kan administratörer lägga till anpassade widgetar där genom att utöka skrivbordsfunktionerna och göra det till en enhetlig samling widgetar som agenter behöver för att få jobbet gjort på ett effektivt sätt.

Skrivbordsarkitektur

Agent Desktop är ett micro frontend-baserat ensidesprogram som är värd för widgetar byggda baserat på arkitektur för webbkomponenter. Alla standard- / lagerwidgets drivs av data som hämtas av API: er eller push-mekanismer på serversidan.

Dessa är vanligtvis asynkrona API:er, där svaret för ett anrop kommer till skrivbordet via en WebSocket-anslutning.

Webex CC autentiserar Agent Desktop användare med Cisco Common Identity (CI) och token skickas vidare till alla API anrop. Även för anpassade widgetar, baserat på autentiseringsmodellen, ger det agenter enkel inloggning om den anpassade widgetens autentiseringsmodell är integrerad med CI.

När en agent är en del av en interaktion skickas alla uppdateringar av interaktionstillståndet eller associerade data till skrivbordet via WebSocket-anslutningen.

Skrivbordets motståndskraft mot anslutning och svarstid

Den asynkrona API- och serversidans push möjliggör skalning och eventuella anslutningsförluster till WebSocket-gränssnittet identifieras och skrivbordet försöker återansluta och logga in igen.

Följande bild illustrerar agentskrivbordsarkitekturen i Webex CC.

Onboarding av kunder

Webex Control Hub är det primära gränssnittet som används av partner och kunder för att registrera kunder och aktivera eller konfigurera funktioner.

När organisationen och kontaktcenterfunktionerna har etablerats i Control Hub utlöser det ett arbetsflöde i Webex CC som gör resten av stegen i etableringen av alla kontaktcenterfunktioner enligt de erbjudanden som kunden valt.

All etablering av kontaktcenter görs med hjälp av en BPM-arbetsflödesmotor som möjliggör ett deklarativt sätt att definiera de steg som ingår och gör hela etableringsstegen motståndskraftiga mot fel och säkerställer dataintegritet.

Följande bild illustrerar etableringsarbetsflödet i Webex kopia.

Konfigurationsentiteter

De viktigaste konfigurationsentiteterna i Webex CC, som är begränsade inom en organisation, är:

Plats

Plats betyder en plats där ett eller flera team, användare (agenter / arbetsledare) finns.

Varje användare och team måste tillhöra en webbplats.

Team

En grupp användare. Team används för att distribuera interaktioner till agenter via köer.

Varje team måste tillhöra en webbplats.

Agenter

Användare som kan logga in i Agent Desktop och hantera interaktioner mellan de medietyper som konfigureras i Webex CC.

Arbetsledare

Arbetsledare tilldelas team och kan övervaka/coacha agenten och har tillgång till status på teamnivå och agentstatistik för de som tillhör de team som arbetsledaren är tilldelad till.

Kö

En kö är en logisk enhet där interaktioner kan hållas i väntan på att agenter ska bli tillgängliga, som sedan dirigeras till agenten.

Köer mappas till team, som sökutrymme för agenter, med möjlighet att utöka sökutrymmet baserat på tröskeln för förfluten tid genom att lägga till andra team i sökutrymmet.

Startpunkt

Startpunkt är en logisk entitet som representerar ingångspunkten för interaktioner som ska komma in i Webex kopia. För telefoni mappas detta främst till telefonnumret som samtalen kommer till och för e-post-/meddelandekanaler pekar startpunkten på resurskonfigurationen i Webex Connect.

Flöde

Det flöde som är associerat med startpunkten (via routningsstrategin), som bestämmer vilka steg som ska ingå i hanteringen av interaktioner.

För icke-telefonikanaler (e-post, meddelanden/sociala medier) väljs Flow som en del av resurskonfigurationen i Webex Connect.

Åtkomstkontroll för kontaktcenter på flera platser

Webex CC-administratörer kan konfigurera användarprofiler med åtkomsträttigheter till specifika platser, team, köer och startpunkter. På grund av webbplatsernas och teamens hierarkiska karaktär kan användaren dessutom komma åt endast de team eller det datum som hör till teamen, som tillhör dessa webbplatser eller en uttryckligen angiven delmängd av sådana team, när åtkomst till specifika webbplatser har tillhandahållits.

För köer och startpunkter är de globala på organisationsnivå, så för olika geografiska platser (platser där specifika agenter och team finns) kan separata startpunkter och köer konfigureras, och arbetsledare / användare kan ha åtkomst till de enheter som är tillämpliga för specifika platser.

Följande bild illustrerar de viktigaste konfigurationsentiteterna och användarprofilen som refererar till dessa entiteter.

Förutom att begränsa åtkomsten till dessa enheter kan Webex CC-administratörer styra de specifika funktioner/moduler som en användare kan komma åt i administrationsgränssnittet och därigenom ha användare med administrations-/konfigurationsbehörighet till specifika enheter samt sektioner/funktioner i Webex CC-administrationsgränssnittet.

Skrivbordsinbäddade anslutningar: CRM-program som primärt gränssnitt

I det här läget loggar agenten in på CRM-konsolen som primärt program.

Webex CC är ett inbäddat program (även kallat ett inbäddat skrivbordsprogram eller inbäddad softphone) som främst används för att logga in på kontaktcentret och ta emot Webex CC-dirigerade kontaktcenterinteraktioner.

När du tar emot ett samtal eller en konversationsförfrågan utför CRM-integreringen följande åtgärder på CRM-konsolen

• Skärma upp kundposten som är knuten till ANI eller andra samtalsrelaterade data.

• Metadata efter samtal som aktivitetsanteckningar i kundposten

• Låt agenten "Click to Call" genom att klicka på kontakten i CRM och initiera ett utgående samtal till kunden

• Bokföra samtalsposter i CRM-rapporteringstabellerna för primär rapportering på CRM.

• Ger alla funktioner i Agent Desktop- och samtalskontrollerna (inbäddad och minifierad version av skrivbordsappen)

Det primära sättet att integrera med CRM: erna är genom att bädda in Webex CC Desktop-applikation i en separat iFrame.

Dessutom kör Webex CC Desktop-programmet en anpassad headless-widget (inget användargränssnitt) som körs i bakgrunden och interagerar med det underliggande CRM-systemet för att utföra automatiserade åtgärder på uppdrag av agenten.

Interaktionerna drivs av två SDK: er som den headless-widgeten använder.

• Webex CC Desktop JS SDK: Detta är JavaScript SDK som tillhandahålls av Webex CC för att registrera händelseavlyssnare för agent- och kontaktåtgärder.

• CRM JS SDK: Det här är CRM-klient-SDK:n som gäller per CRM och som abstraherar REST-API-anrop med CRM. Till exempel för salesforce används CTI JS-biblioteket som tillhandahålls av Salesforce för att utföra åtgärder och lyssna efter händelser i CRM.

Följande bild illustrerar CRM inbäddad Webex CC skrivbords- och anslutningsarkitektur

Webex CC stöder följande CRM-lösningar för ovan nämnda integration:

• Salesforce

• ServiceNu

• Microsoft Dynamics 365

• Zendesk

• Freshdesk

Mer information finns i https://help.webex.com/en-us/result/integrate%20with%20webex%20contact%20center?offset=10.

Mer information om hur du konfigurerar Webex CC-skrivbordslayouter för aktivering av CRM-anslutning, funktionsuppsättningar och ändringsloggar finns på https://github.com/Ciscodevnet/webex-contact-center-crm-integrations.

Global tillgänglighet för CRM-kopplingar

CRM-anslutningsapparna är tillgängliga i alla geografiska områden och regioner där Webex CC används.

Elastisk skala och prestanda

Webex CC är värd för den anpassade widgeten som möjliggör dubbelriktad kommunikation mellan CRM-applikationen och Webex CC-skrivbordet i AWS CloudFront CDN, vilket säkerställer hög tillgänglighet för widgeten AWS över tillgänglighetszoner och regioner.

All CRM-integrationsspecifik beräkning sker i webbläsaren där agenter använder CRM-programmet med Webex CC-skrivbord inbäddat i CRM-programmet.

Säkerhet

CRM-kopplingarna anropas via Webex CC-agentskrivbordslayouten och valfria parametrar skickas via skrivbordslayouten till widgeten för att aktivera och inaktivera funktioner.

Om du till exempel vill aktivera widgeten Salesforce-åtgärder kan administratören aktivera skrivbordslayoutparameterinställningen sfdcWidgetEnabled till true.

Installation av paket

För att integreringen ska fungera dubbelriktat måste CRM-konsolen ha det inbäddade programmet installerat. Detta för att stödja laddning av skrivbordsprogrammet inuti en iFrame.

Alla Desktop Embedded-kopplingar är tillgängliga på CRM-marknadsplatsen.

Till exempel,

ServiceNow: https://store.servicenow.com/sn_appstore_store.do#!/store/application/6c8e2a4edbc73410e1c75e25ca961947/1.0.5?

Zendesk: https://www.zendesk.com/marketplace/apps/support/202570/webex-contact-center/

Installationen av Marketplace-programmet aktiverar nödvändiga plugin-program och importerar de nödvändiga XML filerna till CRM-konsolen för att stödja rapportering av samtalsposter på CRM.

Flödesintegreringar via HTTPs-anslutningsappar i IVR

Webex CC Flow-byggaren stöder dubbelriktade dataflöden mellan Webex CC och CRM-systemet med HTTPs-anslutningar som konfigurerats i Webex Control Hub och används på Webex CC Flow.

Dessa används främst för personalisering inom röstinteraktioner och anpassad routing inom IVR.

Som standard stöder Webex CC Salesforce HTTP Connector på Control Hub. De andra CRM-kopplingarna kan läggas till som anpassade anslutningsprogram i Webex Control Hub.

Mer information om HTTP-anslutningsappar finns i https://github.com/CiscoDevNet/webex-contact-center-crm-integrations.

IVR HTTP-anslutningar:

• Salesforce IVR HTTP-anslutning (inbyggd): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/Salesforce/salesforce-ivr-http-connector

• Zendesk IVR HTTP-anslutning (anpassad): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/Zendesk/zendesk-ivr-http-connector

• ServiceNow IVR HTTP-anslutning (anpassad): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/ServiceNow/servicenow-ivr-http-connector

Röstinfrastruktur på Edge

Voice Edge-komponenterna gör det möjligt för SIP-trunkar från kundnätverk / PSTN-operatörer att avslutas, och detta aktiveras baserat på vitlistade IP-adresser som får ansluta till gränskomponenterna.

Säkerhet för beräkningsinfrastruktur

Webex CC-beräkningsinstanser etableras i AWS och tjänster körs som poddar i Kubernetes-kluster som har flera namnrymder och åtkomsten till varje namnområde är begränsad med separata autentiseringsuppgifter.

All etablering av infrastruktur görs med hjälp av kod – inga manuella steg – och ingen av autentiseringsuppgifterna kan nås manuellt.

Det finns ett centralt arkiv med specifika sökvägar konfigurerade för en specifik uppsättning tjänster/team och åtkomsten till själva arkivet för autentiseringsuppgifter är begränsad och konfigurerad som hemligheter i bygg- och distributionssystemen.

Ingen av infrastrukturkomponenterna/tjänsterna är direkt exponerade utanför AWS VPC och endast offentligt exponerade gränssnitt är API:er och WebSocket-servrar som styrs och hanteras med hjälp av api-gateway,

Bortsett från detta finns det vissa interna system och gränssnitt som används av utvecklare som används för att visa loggar, mätvärden, distributionsdetaljer, byggstatus och testresultat, som är säkrade med roller och grupper och integrerade med Ciscos interna autentiseringssystem.

Autentisering och auktorisering för användargränssnitt

Alla användargränssnitt som används av olika kontaktcenteranvändare (agenter, arbetsledare, administratörer, analytiker) skyddas av OAuth-flöden (Cisco Common Identity-baserad autentisering med innehavartoken).

Auktoriseringen görs med hjälp av roller för den användare som hämtade token och omfång som tilldelats token.

Data under överföring

Inget av gränssnitten för den distribuerade tjänste-/infrastrukturkomponenten exponeras direkt för extern inkommande trafik.

Välj tjänster, med http-API:er exponerar dessa gränssnitt via en gateway och alla inkommande https (inklusive WebSocket) avslutas i ALB och intern trafik över http dirigeras till tjänsterna.

Alla utgående interaktioner är över https / TLS (för icke-http-protokoll).

Inuti VPC är den interna kommunikationen mellan tjänster – över http / custom TCP protokoll - över vanligt TCP uttag.

Vilande data

All data som lagras krypteras på lagringslagret. Vidare är de datalager som ligger utanför VPC skyddade och åtkomstkontroll och behörigheter med autentiseringsuppgifter säkert lagrade och hanterade i ett hemligt arkiv.

Följande bild illustrerar dataflödes- och säkerhetsmodellen för överföring och i vila.

PII-data för slutanvändare

Webex CC Flow, som är den programmatiska styrenheten för hantering av interaktioner, kan användas för att samla in användardata, som kan tilldelas flödesvariabler som är särskilt märkta som "Innehåller känsliga data". Värdena för sådana data är krypterade och inga tjänster i överföringsvägen för data kommer att ha åtkomst till dessa data.

Vidare bevaras aldrig sådana data i Webex CC-rapporteringsdatalager och loggarna / meddelandeinfrastrukturen kommer att ha krypterade data och klartextdata lagras inte någonstans inom Webex CC.

PII-data för kontaktcenteragent/arbetsledare

Kontaktcentrets användarrelaterade data redigeras i loggar men är tillgängliga för dataanalys och visualisering i Webex CC-datalagret.

Faktorer för skala

För Webex CC är de faktorer som påverkar skalan:

• Samtidiga antal inloggade agenter

• Samtidig antal pågående interaktioner

  • Åtgärder som utförts på dessa interaktioner

• Samtidig antal åtgärder som arbetsledare/agenter utför, utöver hanteringen av interaktionerna

• Mängden data som genererats och bevarats

Arkitektoniska aspekter som möjliggör skalbarhet

De principer som Webex CC bygger på och utformas gör att lösningen kan skalas dynamiskt efter behov inom de gränser som tillämpas av den infrastruktur som tillhandahålls för de olika tjänsterna och plattformskomponenterna.

Händelsedriven arkitektur

Tjänsterna i Webex CC kommunicerar med hjälp av meddelanden och de kritiska meddelandebearbetningsflödena innebär inte några blockerande I/O-åtgärder och det tillstånd som krävs för bearbetning av meddelanden lokaliseras till instansen av tjänsten som bearbetar meddelandet.

Tillståndslösa tjänster (eller externt tillstånd)

Tillståndslösa tjänster möjliggör elasticitet genom att enkelt lägga till/ta bort ytterligare instanser av tjänsterna. Det finns vissa tjänster som i sig är tillståndsfulla till sin natur och de har externaliserat tillståndslager och infrastrukturen stöder dynamiska förändringar av antalet instanser av sådana tjänster också med automatisk ombalansering / tillståndsöverföring / lokalisering av tillståndet till den instans som behöver tillståndet.

Elastisk infrastruktur

Alla tjänster körs i Kubernetes och infrastrukturen, även kallad Kubernetes-noder, skalas automatiskt baserat på användningen och detta gör det möjligt att dynamiskt lägga till fler beräkningsnoder upp till ett maximalt högt tröskelvärde som är förkonfigurerat.

Laddningsprojektion och regelbunden validering

Alla tjänster jämförs för prestandaegenskaper och skalningsmönster valideras på servicenivå.

Ytterligare kontinuerliga validerings-, toppbelastnings- och uthållighetstester utförs med testparametrar justerade för beräknad tillväxt i skalan som påverkar attribut, vilket gör det möjligt att identifiera flaskhalsar, planera att uppdatera den höga tröskeln för infrastrukturresursanvändning och vara redo för speldagen.