Telefoni

For telefoni avgjøres håndteringen av innkommende taleanrop av hvordan anropet kom inn i kontaktsenteret (se Inngående mekanismer nedenfor) og Webex CC-flyten som er knyttet til inngangspunktet.

Anropet blir besvart, og ytterligere handlinger utføres i henhold til CC Flow Webex definisjonen – som er en programmatisk representasjon av handlingene som skal utføres under håndtering av anropet, enten før kø og ruting til en agent, eller selve flyten kan håndtere samtalen uten overføring til en agent.

Flow Builder i Webex CC lar utviklere definere flyten og tilordne den til inngangspunktet som anropet ankommer via i Webex CC.

Disse konfigurasjonsenhetene og bruken av dem dekkes i konfigurasjonsenheter.

Mer informasjon om Flow Builder er dekket i den kommende delen om IVR System.

E-post og meldinger

Fra Webex CC-perspektiv gir Webex Connect inngående og utgående funksjoner for alle digitale kanaler – e-post, meldingskanaler, som sluttbrukere kan bruke til å kontakte kontaktsenteret.

Webex Connect-flyt

• Bestemmer håndteringen av slike samhandlinger til samhandlingene er satt i kø og rutet til agenter. Dette inkluderer automatisk håndtering og BOT-behandlinger for alle former for meldings- og e-postinteraksjoner.

• Bruker forretningslogikk på innkommende samhandling.

• Håndterer kontakt før du setter deg i kø.

• Flow selv kan håndtere samhandlingen uten overføring til live agent.

Meldingskanalene som støttes av Webex CC er:

• Web App / Mobil App Chat

• Whatsapp

• Facebook Messenger

• SMS

E-postkanalene som støttes av Webex CC er:

• Gmail

• Office365

Inntrengningsmekanismer

Denne delen dekker mekanismene som en interaksjon kan komme inn i Webex CC. Basert på medietypen er mekanismene som en interaksjon når Webex CC forskjellige.

I telefoni er det for eksempel nødvendig med klargjøring av fysisk infrastruktur for å aktivere PSTN-tilkobling, konfigurasjon av telefonnumre og ruting av anropene til Webex CC.

For e-post-/meldingskanaler må inngangskonfigurasjonen gjøres i Webex Koble til, og den involverer klargjøring av e-post-/meldingskonto og Webex Connect-flytkonfigurasjon.

Innkommende tale

For taleanrop er et typisk scenario der brukere ringer et PSTN-telefonnummer som deretter kobles til kontaktsenteret. Fra et inngangsperspektiv trenger dette en mekanisme for å rute anrop fra PSTN til Webex CC.

Figur 1 illustrerer inntaket av taleanrop til Webex CC.

Voice Ingress Services i Webex CC utfører tredjeparts samtalekontroll ved hjelp av SIP og svarer på det innkommende anropet, samt utfører overførings-, konferanse- og andre samtalekontrolloperasjoner.

Det logiske inngangspunktet for anrop i Webex CC er konfigurasjonsenheten kalt Entrypoint. For taleinngang er nøkkelkonfigurasjonen for Entrypoint telefonnummeret som er knyttet til det, som vanligvis er et gyldig PSTN-telefonnummer hentet fra valgt PSTN-leverandør.

Dette gjør det mulig å oppdage innkommende anrop på telefonnummeret, knytte anropet til Entrypoint og bruke andre konfigurasjonsparametere for inngangspunktet til å håndtere anropet i henhold til definisjonen for Webex CC-flyt som skal utløses for samhandlingen.

Merk:

Hvis du vil ha mer informasjon om alternativene for PSTN-tilkobling, kan du gå til 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.

Skalerbarhet og tilgjengelighet for infrastruktur for talekant

Webex CC VPOP-infrastrukturen inkluderer redundante SIP SBC-par, noe som sikrer høy tilgjengelighet og flere SBC-er kan legges til for å skalere de samtidige anropsvolumene som skal støttes.

Maks samtidige anrop som VPOP kan håndtere, avhenger av antall SBC-er som kjører, og som anrop sendes til.

For geografisk redundans – et nett av VPOP SBC med sammenkoblinger på tvers av flere par på tvers av regioner støttes.

For taleinngangstjenester er de horisontalt skalerbare for å håndtere et økende antall samtidige taleanrop som skal inntas til Webex CC.

Sikkerhetshensyn med talekantinfrastruktur

Tabellen nedenfor inneholder detaljer om tilkoblingsalternativene til Voice Edge-infrastrukturen.

For mer informasjon, 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

Hvert taleanrop som kommer inn i et telefonnummer som er tilknyttet et inngangspunkt, blir besvart av Webex CC, og kjøring av en Webex CC-flyt tilknyttet inngangspunktet, starter.

Webex CC Flow Builder leverer programmeringskonstruksjoner/operatorer og funksjonelle blokker, kalt aktiviteter, slik at administratorer eller andre som utformer og implementerer den IVR logikken, kan kombinere disse byggeklossene og opprette flytdefinisjonen.

Programmeringskonstruksjonene som Flow støtter, er:

• Deklarasjons- og innstillingsvariabler – tilstand knyttet til en flytkjøring

  • Pebble-uttrykk for å angi verdien av variabler

• Betingede kontroller

• Looping - bruk av Conditionals og Go To (evne til å kjede aktiviteter sammen)

• Aktivere REST API-er

• Analyseringsdata - JSON, TOML, XML vanligvis brukt til å analysere API svar.

• Komponere aktiviteter

Et representativt sett med aktiviteter som Flow-forsyninger er: Spill av meldinger Samle inn brukerdata Overføre samtalen til en annen destinasjon/et annet telefonnummer Send samtalen til en virtuell agent Sett anropet i kø slik at det kan besvares av en agent.

For hvert anrop som er aktivt, er en forekomst av flytkjøring også aktiv til samtalen avsluttes, noe som resulterer i samtidige kjøringer av flyter.

Hver forekomst av flytkjøring gir isolert miljø for data / tilstand knyttet til flyten og der av anropet.

I løpet av hele anropets livssyklus gjør flyt det også mulig å svare på bestemte hendelser som skjer, og håndtere dem – når et anrop for eksempel besvares av en agent, kan en hendelsesbehandling utløse et skjermvindu i grensesnittet for agentskrivebordet.

Hvis du vil ha mer informasjon om Webex CC Flow, kan du se https://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øtte for virtuell agent

Flow leverer en aktivitet for å levere samhandlingen til en virtuell agent, som er forhåndskonfigurert i Webex Control Hub.

Når samtalen er koblet til en virtuell agent, gir den en samtaleopplevelse IVR brukeren og aktiviteten avsluttes enten med avslutning av samtalen eller med eskalering av anropet til en agent.

Ved eskalering kan flyten konfigureres til å sette anropet i kø, som deretter blir besvart av en agent.

Innkommende digitale interaksjoner

For e-post og meldingskanal for innkommende samhandlinger bruker Webex CC Webex Connect til klargjøring av aktiva, flyt for å håndtere innkommende samhandlinger og deretter rute samhandlingen til Webex CC når Webex Connect-flyten eksplisitt setter samhandlingen i kø slik at den kan håndteres av en agent.

Figur 2 illustrerer inntak av e-post, meldingsinteraksjoner i Webex CC.

Virtual Agent / BOT-integrasjoner

For samhandlinger med e-post og meldinger eller sosiale kanaler konfigureres de virtuelle agent-/BOT-behandlingene i Webex Connect-flyten.

På samme måte som med Virtual Agents for Voice, hvis BOT-behandlingen ender med eskalering som resultat, blir samhandlingen lagt i kø og rutet til en agent.

Valg av agent

Køer i Webex CC støtter følgende algoritmer for agentvalg:

• Lengste tilgjengelige agentruting

• Dyktig basert ruting

  • Lengste tilgjengelige agent (LAA)

  • Beste tilgjengelige agent (BAA)

Agenter er knyttet til køer gjennom Teams.

En kø kan tilordnes flere anropsdistribusjonsgrupper (der hver gruppe har ett eller flere team), på en sekvensiell måte med konfigurert venting på at anropsdistribusjonsgruppe skal legges til i køen, slik at søkeområdet for en samsvarende agent utvides til flere anropsdistribusjonsgrupper etter hvert som tiden går.

For ferdighetsbasert ruting, blant kompetansekravene som samsvarer med agenter som er knyttet til køen, velges en agent basert på LAA- eller BAA-konfigurasjon.

Spesifikke tilleggsfunksjoner for tale/telefoni

Agentbasert ruting (kun for tale-/telefonikanaler)

Webex CC Flow kan ved hjelp av aktiviteten QueueToAgent rute samhandlinger direkte til den valgte agenten basert på agent-ID-en.

Hvis agenten ikke er tilgjengelig for å håndtere samhandlinger, kan samhandlingen parkeres i en agentspesifikk kø og vente på at agenten blir tilgjengelig

Avansert køinformasjon

Webex CC Flow kan ved hjelp av aktiviteten GetQueueInfo hente sanntidsinformasjon for en kø som Posisjon i kø (PIQ), Estimert ventetid (EWT), antall agenter som er tilgjengelige i køen, og kan brukes til å avgjøre om kontakten skal settes i kø eller ikke.

Høflighet tilbakeringing

Webex CC Flow, ved hjelp av aktiviteten Tilbakeringing, lar kunden koble fra samtalen mens posisjonen i køen opprettholdes, og motta en tilbakeringing når den virtuelle samhandlingen i køen rutes til en agent.

Håndtering av overløp

Webex CC støtter overflythåndtering ved hjelp av kapasitetsbaserte team (CBT).

CBT er som et vanlig team med en kapasitet og en tilknyttet ekstern DN som tjener den kapasiteten. Den kan konfigureres sammen med andre team i distribusjonssyklusene for køanrop.

Vanligvis konfigureres dette som den siste syklusen, slik at det fungerer som en overflyt hvis ingen agent er tilgjengelig, selv etter at alle de konfigurerte anropsdistribusjonsgruppene ikke finner en tilgjengelig samsvarende agent for håndtering av samhandlingen.

Agent Desktop Operasjoner

Når en agent logger på Webex CC Agent Desktop, angir agenten et telefonnummer som innkommende anrop til agenten kan kobles til. Dette kan være en PSTN-telefon, mobiltelefon eller et internnummer hvis agenten er en Cisco Webex Calling bruker.

Vær oppmerksom på at dette nummeret må være et gyldig telefonnummer som anrop kan rutes til. Hvis ikke, kan ikke agenten motta innkommende anrop.

Basert på typen samhandling som agenten håndterer, gir widgetene i agentskrivebordet muligheten til å utføre bestemte mediekontrolloperasjoner.

Når et anrop er besvart, kan agenten for eksempel utføre følgende operasjoner knyttet til anropet.

• Sett samtalen på vent

• Start konsultasjonssamtale og

  • Overfør samtalen til et annet telefonnummer (si agenttelefonnummer) / inngangspunkt

  • Sende en annen agent til samtalen i konferanse

• Overføre samtalen til en annen kø

• Avslutte samtalen

Med Agent Desktop kan administratorer legge til egendefinerte widgeter der ved å utvide skrivebordsfunksjonene og gjøre det til en enhetlig samling av widgeter som agenter trenger for å få arbeidet gjort på en effektiv måte.

Skrivebordsarkitektur

Agent desktop er en mikro frontend basert enkeltside program som er vert for widgets bygget basert på webkomponenter arkitektur. Alle standard-/lagerwidgetene drives av data som hentes av API-er eller push-mekanismer på serversiden.

Dette er vanligvis asynkrone API-er, der svaret på en påkallelse kommer til skrivebordet via en WebSocket-tilkobling.

Webex CC-Agent Desktop godkjenner brukere med Cisco Common Identity (CI), og tokenet sendes videre til alle API aktiveringer. Også for egendefinerte widgeter, basert på godkjenningsmodellen, gir den en enkel påloggingsopplevelse til agenter hvis godkjenningsmodellen til den egendefinerte widgeten er integrert med CI.

Når en agent er en del av en samhandling, sendes alle oppdateringer til samhandlingstilstanden eller tilknyttede data også til skrivebordet via WebSocket-tilkoblingen.

Robusthet fra skrivebordet til tilkobling og ventetid

Den asynkrone API og push-en på serversiden muliggjør skalering, og eventuelle tilkoblingstap til WebSocket-grensesnittet oppdages, og skrivebordet forsøker å koble til på nytt og logge på på nytt.

Figur 2 illustrerer agentskrivebordsarkitekturen i Webex CC.

Onboarding av kunder

Webex Control Hub er det primære grensesnittet som brukes av partnere og kunder for å introdusere kunder og aktivere eller konfigurere funksjoner.

Når organisasjons- og kontaktsenterfunksjonene er klargjort i Control Hub, vil det utløse en arbeidsflyt i Webex CC som utfører resten av trinnene i klargjøringen av alle kontaktsenterfunksjoner i henhold til tilbudene valgt av kunden.

All klargjøring av kontaktsenteret gjøres ved hjelp av en BPM-arbeidsflytmotor som muliggjør en deklarativ måte å definere de involverte trinnene på, og gjør hele klargjøringstrinnene motstandsdyktige mot feil og sikrer dataintegritet.

Figur 1 illustrerer klargjøringsarbeidsflyten i Webex CC.

Konfigurasjonsenheter

De viktigste konfigurasjonsenhetene i Webex CC, omfang i en organisasjon, er:

Nettstedet

Sted betyr et sted hvor ett eller flere team, brukere (agenter/veiledere) er lokalisert.

Hver bruker og gruppe må tilhøre et område.

Gruppe

En gruppe brukere. Team brukes til å distribuere samhandlinger til agenter via køer.

Hvert lag må tilhøre et nettsted.

Agenter

Brukere som kan logge på Agent Desktop og håndtere samhandlinger på tvers av medietypene som er konfigurert i Webex CC.

Tilsynspersoner

Veiledere er tildelt team og kan overvåke/coache agenten og ha tilgang til status på teamnivå og agentstatistikk for de som tilhører teamene som veilederen er tildelt.

Kø

En kø er en logisk enhet der samhandlinger kan holdes mens du venter på at agenter skal være tilgjengelige, som deretter rutes til agenten.

Køer tilordnes til team, som søkeområdet for agenter, med mulighet til å utvide søkeområdet basert på medgått tidsterskel, ved å legge til andre team i søkeområdet.

Entrypoint

Entrypoint er en logisk enhet som representerer inngangspunktet for samhandlinger for å komme inn i Webex CC. For telefoni kartlegges dette primært telefonnummeret som anropene kommer til, og for e-post-/meldingskanaler peker Entrypoint til ressurskonfigurasjonen i Webex Connect.

Flyt

Flyten knyttet til inngangspunktet (via rutingsstrategi), som bestemmer trinnene som er involvert i håndtering av samhandlinger.

For ikke-telefonikanaler (e-post, meldinger/sosiale medier) velges Flow som en del av ressurskonfigurasjonen i Webex Connect.

Tilgangskontroll for kontaktsentre på flere steder

Webex CC-administratorer kan konfigurere brukerprofiler med tilgangsrettigheter til bestemte områder, grupper, køer og inngangspunkter. Videre, på grunn av den hierarkiske naturen til steder og team, når tilgang til bestemte nettsteder er gitt, kan bare lagene eller datoen som gjelder teamene, som tilhører disse nettstedene eller et eksplisitt spesifisert delsett av slike team, nås av brukeren.

For køer og inngangspunkter er de globale på organisasjonsnivå, så for forskjellige geografiske steder (steder der bestemte agenter og team er plassert) kan separate inngangspunkter og køer konfigureres, og veiledere / brukere kan ha tilgang til de enhetene som gjelder for bestemte nettsteder.

Figur 2 illustrerer nøkkelkonfigurasjonsenhetene og brukerprofilen som refererer til disse enhetene.

I tillegg til å begrense tilgangen til disse enhetene, kan Webex CC-administratorer kontrollere de spesifikke egenskapene/modulene som en bruker kan få tilgang til i administrasjonsgrensesnittet, og dermed ha brukere med administrasjons-/konfigurasjonsrettigheter til bestemte enheter samt deler/muligheter i administrasjonsgrensesnittet for Webex CC.

Innebygde skrivebordskoblinger: CRM-program som primært grensesnitt

I denne driftsmodusen logger agenten på CRM-konsollen som det primære programmet.

Webex CC er et innebygd program (også kalt et innebygd skrivebordsprogram eller innebygd softphone) som primært brukes til å logge på kontaktsenteret og motta Webex CC-rutede kontaktsentersamhandlinger.

Når CRM-integreringen mottar et anrop eller en samtaleforespørsel, utfører den følgende handlinger på CRM-konsollen

• Skjermbilde viser kundeoppføringen som er knyttet til ANI eller andre anropstilknyttede data.

• Postere samtalemetadata som aktivitetsnotater i kundeoppføringen

• La agenten "klikke for å ringe" ved å klikke på kontakten i CRM og starte et utgående anrop til kunden

• Postering av anropsoppføringer i CRM-rapporteringstabellene for primærrapportering om CRM.

• Gir full funksjonalitet for Agent Desktop- og samtalekontroller (innebygd og minifisert versjon av skrivebordsappen)

Den primære integreringsmodusen med CRM-ene er å bygge inn CC Desktop Webex programmet i en separat iFrame.

Videre kjører Webex CC Desktop-programmet en egendefinert hodeløs widget (ingen brukergrensesnitt) i bakgrunnen, og samhandler med det underliggende CRM-systemet for å utføre automatiserte handlinger på vegne av agenten.

Samhandlingene drives av to SDK-er som den hodeløse widgeten bruker.

• Webex CC Desktop JS SDK: Dette er JavaScript SDK levert av Webex CC for å registrere hendelseslyttere for agent- og kontakthandlinger.

• CRM JS SDK: Dette er CRM-klient-SDK-en som gjelder per CRM som abstraherer REST API-anrop med CRM. For salesforce brukes for eksempel det CTI JS-biblioteket fra Salesforce til å utføre handlinger og lytte etter hendelser i CRM.

Figur 1 illustrerer CRM-arkitekturen for innebygd Webex CC-skrivebord og tilkobling

Webex CC støtter følgende CRM-løsninger for ovennevnte integrasjon:

• Salesforce

• ServiceNow

• Microsoft Dynamics 365

• Zendesk

• Freshdesk

For mer informasjon, besøk https://help.webex.com/en-us/result/integrate%20with%20webex%20contact%20center?offset=10.

Hvis du vil ha mer informasjon om hvordan du konfigurerer Webex CC-skrivebordsoppsett for aktivering av CRM-kobling, funksjonssett og endringslogger, kan du gå til https://github.com/CiscoDevNet/webex-contact-center-crm-integrationshttps://github.com/CiscoDevNet/webex-contact-center-crm-integrations.

Global tilgjengelighet av CRM-koblinger

CRM-koblingene er tilgjengelige i alle geografiske områder og områder der Webex CC er i drift.

Elastisk skalering og ytelse

Webex CC er vert for den tilpassede widgeten som muliggjør toveiskommunikasjon mellom CRM-applikasjonen og Webex CC-skrivebordet i AWS CloudFront CDN, noe som sikrer høy tilgjengelighet av widgeten AWS på tvers av tilgjengelighetssoner og regioner.

All CRM-integreringsspesifikk databehandling skjer i nettleseren der agenter bruker CRM-programmet med Webex CC-skrivebord innebygd i CRM-programmet.

Sikkerhet

CRM-koblingene startes via skrivebordsoppsettet for Webex CC-agent, og valgfrie parametere sendes via skrivebordsoppsettet til widgeten for å slå funksjoner på og av.

Hvis du for eksempel vil aktivere widgeten Salesforce-handlinger, kan administratoren slå på parameterinnstillingen sfdcWidgetEnabled til sann.

Installasjon av pakke

For at integreringen skal fungere toveis, må CRM-konsollen ha det innebygde programmet installert. Dette er for å støtte lasting av skrivebordsprogrammet inne i en iFrame.

Alle Desktop Embedded-koblingene er tilgjengelige på CRM-markedsplassen.

For eksempel,

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/

Installasjonen av markedsplassprogrammet aktiverer de nødvendige plugin-modulene og importerer de nødvendige XML-filene til CRM-konsollen for å støtte rapportering av anropsoppføringer i CRM.

Flytintegreringer via HTTP-koblinger i IVR

Webex CC Flow-byggherren støtter toveis dataflyter mellom Webex CC og CRM-systemet ved hjelp av HTTPs-koblinger konfigurert i Webex Control Hub og brukt på Webex CC Flow.

Disse brukes primært til tilpassing i talesamhandlinger og tilpasset ruting i IVR.

Som standard støtter Webex CC HTTP-koblingen Salesforce på Control Hub. De andre CRM-koblingene kan legges til som egendefinerte koblinger i Webex Control Hub.

Hvis du vil ha mer informasjon om HTTP-koblinger, kan du gå til https://github.com/CiscoDevNet/webex-contact-center-crm-integrations.

IVR HTTP-kontakter:

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

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

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

Taleinfrastruktur på Edge

Voice Edge-komponentene tillater SIP-trunker fra kundenettverk / PSTN-bærere å avslutte, og dette aktiveres basert på hvitelistede IP-er som har lov til å koble til kantkomponentene.

Beregn infrastruktursikkerhet

Webex CC-databehandlingsforekomster klargjøres i AWS, og tjenester kjører som pods i Kubernetes-klynge, som har flere navneområder og tilgang til hvert navneområde er begrenset med separat legitimasjon.

All klargjøring av infrastrukturen gjøres ved hjelp av kode – ingen manuelle trinn – og ingen av legitimasjonene kan nås manuelt.

Det er et sentralt legitimasjonslager med spesifikke baner konfigurert for spesifikt sett med tjenester / team, og tilgangen til selve legitimasjonslageret er begrenset og konfigurert som hemmeligheter i bygge- og distribusjonssystemene.

Ingen av infrastrukturkomponentene/tjenestene er direkte eksponert utenfor AWS VPC, og kun offentlig eksponerte grensesnitt er API-er og WebSocket-servere som styres og administreres ved hjelp av API-gateway,

Bortsett fra dette er det visse interne systemer og grensesnitt som brukes av utviklere som brukes til å vise logger, målestokker, distribusjonsdetaljer, byggestatus og testresultater, som er sikret ved hjelp av roller og grupper og integrert med Ciscos interne autentiseringssystemer.

Autentisering og autorisasjon for brukergrensesnitt

Alle brukergrensesnittene som brukes av ulike kontaktsenterbrukere (agenter, ledere, administratorer, analytikere), er beskyttet av Ciscos OAuth-flyter (Common Identity Based Bearer Token).

Autorisasjonen gjøres ved hjelp av roller for brukeren som fikk tokenet og omfangene som er tilordnet tokenet.

Data under overføring

Ingen av grensesnittene til tjenestene / infrastrukturkomponenten som er distribuert, er direkte eksponert for ekstern innkommende trafikk.

Utvalgte tjenester, med http APIer, eksponerer disse grensesnittene via en gateway, og all innkommende https (inkludert WebSocket) avsluttes i ALB og intern trafikk over http rutes til tjenestene.

Alle utgående interaksjoner er over https / TLS (for ikke http-protokoller).

Inne i VPC er den interne kommunikasjonen mellom tjenester - over http / custom TCP protocol - over vanlig TCP socket.

Data i hvile

Alle data som blir lagret, krypteres på lagringslaget. Videre er de datalagrene som er utenfor VPC, beskyttet og tilgangskontroll og autorisasjoner med legitimasjon sikkert lagret og administrert i et hemmelig lager.

Figur 1 illustrerer dataflyt og sikkerhetsmodell for transitt og hvile.

PII-data for sluttbruker

Webex CC Flow, som er den programmatiske kontrolleren for håndtering av samhandlinger, kan brukes til å samle inn brukerdata, som kan tilordnes flytvariabler som er spesielt merket som "Inneholder sensitive data". Verdiene for slike data er kryptert, og ingen tjenester i transittbanen til dataene vil ha tilgang til disse dataene.

Videre blir slike data aldri lagret i CC Webex rapporteringsdatalageret, og loggene/meldingsinfrastrukturen vil ha krypterte data og klartekstdata lagres ikke noe sted i Webex CC.

PII-data for kontaktsenteragent/-leder

Kontaktsenterets brukerrelaterte data redigeres i logger, men er tilgjengelige for dataanalyse og visualisering i Webex CC-datalageret.

Faktorer for skala

For Webex CC er faktorene som påvirker skalaen:

• Samtidig antall agenter logget på

• Samtidig antall interaksjoner pågår

  • Handlinger utført på disse samhandlingene

• Samtidig antall handlinger som veiledere / agenter utfører, utenfor håndtering av interaksjonene

• Volumet av dataene som genereres og vedvarer

Arkitektoniske aspekter som muliggjør skala

Prinsippene som Webex CC er bygget og designet etter, gjør at løsningen kan skaleres dynamisk etter behov innenfor rammene som håndheves av infrastrukturen som tilbys for de ulike tjenestene og plattformkomponentene.

Hendelsesdrevet arkitektur

Tjenestene i Webex CC kommuniserer ved hjelp av meldinger, og de kritiske meldingsbehandlingsflytene innebærer ingen blokkering av IO-operasjoner, og tilstanden som kreves for å behandle meldinger, er lokalisert til forekomsten av tjenesten som behandler meldingen.

Statsløse tjenester (eller eksternalisert tilstand)

Tilstandsløse tjenester muliggjør elastisitet ved enkelt å legge til/fjerne flere forekomster av tjenestene. Det er visse tjenester som er iboende stateful i naturen, og de har eksternalisert statlig butikk og infrastrukturen støtter dynamiske endringer i antall forekomster av slike tjenester også med automatisk rebalansering / statlig overføring / lokalisering av staten til forekomsten som trenger staten.

Elastisk infrastruktur

Alle tjenestene kjører i Kubernetes, og infrastrukturen, også kjent som Kubernetes-noder, skaleres automatisk basert på bruken, og dette gjør det mulig å legge til flere databehandlingsnoder dynamisk opp til en maksimal høy terskel som er forhåndskonfigurert.

Lastprojeksjon og regelmessig validering

Alle tjenestene er benchmarked for ytelsesegenskaper og skaleringsmønster er validert på tjenestenivå.

Ytterligere kontinuerlig validering, toppbelastning og utholdenhetstester utføres med testparametere justert for forventet vekst i skalaen som påvirker attributter, noe som gjør det mulig å identifisere flaskehalser, planlegge å oppdatere den høye terskelen for ressursbruk i infrastrukturen og være klar for spilldagen.

Telefoni

For telefoni avgjøres håndteringen av innkommende taleanrop av hvordan anropet kom inn i kontaktsenteret (se Inngående mekanismer nedenfor) og Webex CC-flyten som er knyttet til inngangspunktet.

Anropet blir besvart, og ytterligere handlinger utføres i henhold til CC Flow Webex definisjonen – som er en programmatisk representasjon av handlingene som skal utføres under håndtering av anropet, enten før kø og ruting til en agent, eller selve flyten kan håndtere samtalen uten overføring til en agent.

Flow Builder i Webex CC lar utviklere definere flyten og tilordne den til inngangspunktet som anropet ankommer via i Webex CC.

Disse konfigurasjonsenhetene og bruken av dem dekkes i konfigurasjonsenheter.

Mer informasjon om Flow Builder er dekket i den kommende delen om IVR System.

E-post og meldinger

Fra Webex CC-perspektiv gir Webex Connect inngående og utgående funksjoner for alle digitale kanaler – e-post, meldingskanaler, som sluttbrukere kan bruke til å kontakte kontaktsenteret.

Webex Connect-flyt

• Bestemmer håndteringen av slike samhandlinger til samhandlingene er satt i kø og rutet til agenter. Dette inkluderer automatisk håndtering og BOT-behandlinger for alle former for meldings- og e-postinteraksjoner.

• Bruker forretningslogikk på innkommende samhandling.

• Håndterer kontakt før du setter deg i kø.

• Flow selv kan håndtere samhandlingen uten overføring til live agent.

Meldingskanalene som støttes av Webex CC er:

• Web App / Mobil App Chat

• Whatsapp

• Facebook Messenger

• SMS

E-postkanalene som støttes av Webex CC er:

• Gmail

• Office365

Inntrengningsmekanismer

Denne delen dekker mekanismene som en interaksjon kan komme inn i Webex CC. Basert på medietypen er mekanismene som en interaksjon når Webex CC forskjellige.

I telefoni er det for eksempel nødvendig med klargjøring av fysisk infrastruktur for å aktivere PSTN-tilkobling, konfigurasjon av telefonnumre og ruting av anropene til Webex CC.

For e-post-/meldingskanaler må inngangskonfigurasjonen gjøres i Webex Koble til, og den involverer klargjøring av e-post-/meldingskonto og Webex Connect-flytkonfigurasjon.

Innkommende tale

For taleanrop er et typisk scenario der brukere ringer et PSTN-telefonnummer som deretter kobles til kontaktsenteret. Fra et inngangsperspektiv trenger dette en mekanisme for å rute anrop fra PSTN til Webex CC.

Figur 1 illustrerer inntaket av taleanrop til Webex CC.

Voice Ingress Services i Webex CC utfører tredjeparts samtalekontroll ved hjelp av SIP og svarer på det innkommende anropet, samt utfører overførings-, konferanse- og andre samtalekontrolloperasjoner.

Det logiske inngangspunktet for anrop i Webex CC er konfigurasjonsenheten kalt Entrypoint. For taleinngang er nøkkelkonfigurasjonen for Entrypoint telefonnummeret som er knyttet til det, som vanligvis er et gyldig PSTN-telefonnummer hentet fra valgt PSTN-leverandør.

Dette gjør det mulig å oppdage innkommende anrop på telefonnummeret, knytte anropet til Entrypoint og bruke andre konfigurasjonsparametere for inngangspunktet til å håndtere anropet i henhold til definisjonen for Webex CC-flyt som skal utløses for samhandlingen.

Merk:

Hvis du vil ha mer informasjon om alternativene for PSTN-tilkobling, kan du gå til 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.

Skalerbarhet og tilgjengelighet for infrastruktur for talekant

Webex CC VPOP-infrastrukturen inkluderer redundante SIP SBC-par, noe som sikrer høy tilgjengelighet og flere SBC-er kan legges til for å skalere de samtidige anropsvolumene som skal støttes.

Maks samtidige anrop som VPOP kan håndtere, avhenger av antall SBC-er som kjører, og som anrop sendes til.

For geografisk redundans – et nett av VPOP SBC med sammenkoblinger på tvers av flere par på tvers av regioner støttes.

For taleinngangstjenester er de horisontalt skalerbare for å håndtere et økende antall samtidige taleanrop som skal inntas til Webex CC.

Sikkerhetshensyn med talekantinfrastruktur

Tabellen nedenfor inneholder detaljer om tilkoblingsalternativene til Voice Edge-infrastrukturen.

For mer informasjon, 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

Hvert taleanrop som kommer inn i et telefonnummer som er tilknyttet et inngangspunkt, blir besvart av Webex CC, og kjøring av en Webex CC-flyt tilknyttet inngangspunktet, starter.

Webex CC Flow Builder leverer programmeringskonstruksjoner/operatorer og funksjonelle blokker, kalt aktiviteter, slik at administratorer eller andre som utformer og implementerer den IVR logikken, kan kombinere disse byggeklossene og opprette flytdefinisjonen.

Programmeringskonstruksjonene som Flow støtter, er:

• Deklarasjons- og innstillingsvariabler – tilstand knyttet til en flytkjøring

  • Pebble-uttrykk for å angi verdien av variabler

• Betingede kontroller

• Looping - bruk av Conditionals og Go To (evne til å kjede aktiviteter sammen)

• Aktivere REST API-er

• Analyseringsdata - JSON, TOML, XML vanligvis brukt til å analysere API svar.

• Komponere aktiviteter

Et representativt sett med aktiviteter som Flow-forsyninger er: Spill av meldinger Samle inn brukerdata Overføre samtalen til en annen destinasjon/et annet telefonnummer Send samtalen til en virtuell agent Sett anropet i kø slik at det kan besvares av en agent.

For hvert anrop som er aktivt, er en forekomst av flytkjøring også aktiv til samtalen avsluttes, noe som resulterer i samtidige kjøringer av flyter.

Hver forekomst av flytkjøring gir isolert miljø for data / tilstand knyttet til flyten og der av anropet.

I løpet av hele anropets livssyklus gjør flyt det også mulig å svare på bestemte hendelser som skjer, og håndtere dem – når et anrop for eksempel besvares av en agent, kan en hendelsesbehandling utløse et skjermvindu i grensesnittet for agentskrivebordet.

Hvis du vil ha mer informasjon om Webex CC Flow, kan du se https://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øtte for virtuell agent

Flow leverer en aktivitet for å levere samhandlingen til en virtuell agent, som er forhåndskonfigurert i Webex Control Hub.

Når samtalen er koblet til en virtuell agent, gir den en samtaleopplevelse IVR brukeren og aktiviteten avsluttes enten med avslutning av samtalen eller med eskalering av anropet til en agent.

Ved eskalering kan flyten konfigureres til å sette anropet i kø, som deretter blir besvart av en agent.

Innkommende digitale interaksjoner

For e-post og meldingskanal for innkommende samhandlinger bruker Webex CC Webex Connect til klargjøring av aktiva, flyt for å håndtere innkommende samhandlinger og deretter rute samhandlingen til Webex CC når Webex Connect-flyten eksplisitt setter samhandlingen i kø slik at den kan håndteres av en agent.

Figur 2 illustrerer inntak av e-post, meldingsinteraksjoner i Webex CC.

Virtual Agent / BOT-integrasjoner

For samhandlinger med e-post og meldinger eller sosiale kanaler konfigureres de virtuelle agent-/BOT-behandlingene i Webex Connect-flyten.

På samme måte som med Virtual Agents for Voice, hvis BOT-behandlingen ender med eskalering som resultat, blir samhandlingen lagt i kø og rutet til en agent.

Valg av agent

Køer i Webex CC støtter følgende algoritmer for agentvalg:

• Lengste tilgjengelige agentruting

• Dyktig basert ruting

  • Lengste tilgjengelige agent (LAA)

  • Beste tilgjengelige agent (BAA)

Agenter er knyttet til køer gjennom Teams.

En kø kan tilordnes flere anropsdistribusjonsgrupper (der hver gruppe har ett eller flere team), på en sekvensiell måte med konfigurert venting på at anropsdistribusjonsgruppe skal legges til i køen, slik at søkeområdet for en samsvarende agent utvides til flere anropsdistribusjonsgrupper etter hvert som tiden går.

For ferdighetsbasert ruting, blant kompetansekravene som samsvarer med agenter som er knyttet til køen, velges en agent basert på LAA- eller BAA-konfigurasjon.

Spesifikke tilleggsfunksjoner for tale/telefoni

Agentbasert ruting (kun for tale-/telefonikanaler)

Webex CC Flow kan ved hjelp av aktiviteten QueueToAgent rute samhandlinger direkte til den valgte agenten basert på agent-ID-en.

Hvis agenten ikke er tilgjengelig for å håndtere samhandlinger, kan samhandlingen parkeres i en agentspesifikk kø og vente på at agenten blir tilgjengelig

Avansert køinformasjon

Webex CC Flow kan ved hjelp av aktiviteten GetQueueInfo hente sanntidsinformasjon for en kø som Posisjon i kø (PIQ), Estimert ventetid (EWT), antall agenter som er tilgjengelige i køen, og kan brukes til å avgjøre om kontakten skal settes i kø eller ikke.

Høflighet tilbakeringing

Webex CC Flow, ved hjelp av aktiviteten Tilbakeringing, lar kunden koble fra samtalen mens posisjonen i køen opprettholdes, og motta en tilbakeringing når den virtuelle samhandlingen i køen rutes til en agent.

Håndtering av overløp

Webex CC støtter overflythåndtering ved hjelp av kapasitetsbaserte team (CBT).

CBT er som et vanlig team med en kapasitet og en tilknyttet ekstern DN som tjener den kapasiteten. Den kan konfigureres sammen med andre team i distribusjonssyklusene for køanrop.

Vanligvis konfigureres dette som den siste syklusen, slik at det fungerer som en overflyt hvis ingen agent er tilgjengelig, selv etter at alle de konfigurerte anropsdistribusjonsgruppene ikke finner en tilgjengelig samsvarende agent for håndtering av samhandlingen.

Agent Desktop Operasjoner

Når en agent logger på Webex CC Agent Desktop, angir agenten et telefonnummer som innkommende anrop til agenten kan kobles til. Dette kan være en PSTN-telefon, mobiltelefon eller et internnummer hvis agenten er en Cisco Webex Calling bruker.

Vær oppmerksom på at dette nummeret må være et gyldig telefonnummer som anrop kan rutes til. Hvis ikke, kan ikke agenten motta innkommende anrop.

Basert på typen samhandling som agenten håndterer, gir widgetene i agentskrivebordet muligheten til å utføre bestemte mediekontrolloperasjoner.

Når et anrop er besvart, kan agenten for eksempel utføre følgende operasjoner knyttet til anropet.

• Sett samtalen på vent

• Start konsultasjonssamtale og

  • Overfør samtalen til et annet telefonnummer (si agenttelefonnummer) / inngangspunkt

  • Sende en annen agent til samtalen i konferanse

• Overføre samtalen til en annen kø

• Avslutte samtalen

Med Agent Desktop kan administratorer legge til egendefinerte widgeter der ved å utvide skrivebordsfunksjonene og gjøre det til en enhetlig samling av widgeter som agenter trenger for å få arbeidet gjort på en effektiv måte.

Skrivebordsarkitektur

Agent desktop er en mikro frontend basert enkeltside program som er vert for widgets bygget basert på webkomponenter arkitektur. Alle standard-/lagerwidgetene drives av data som hentes av API-er eller push-mekanismer på serversiden.

Dette er vanligvis asynkrone API-er, der svaret på en påkallelse kommer til skrivebordet via en WebSocket-tilkobling.

Webex CC-Agent Desktop godkjenner brukere med Cisco Common Identity (CI), og tokenet sendes videre til alle API aktiveringer. Også for egendefinerte widgeter, basert på godkjenningsmodellen, gir den en enkel påloggingsopplevelse til agenter hvis godkjenningsmodellen til den egendefinerte widgeten er integrert med CI.

Når en agent er en del av en samhandling, sendes alle oppdateringer til samhandlingstilstanden eller tilknyttede data også til skrivebordet via WebSocket-tilkoblingen.

Robusthet fra skrivebordet til tilkobling og ventetid

Den asynkrone API og push-en på serversiden muliggjør skalering, og eventuelle tilkoblingstap til WebSocket-grensesnittet oppdages, og skrivebordet forsøker å koble til på nytt og logge på på nytt.

Figur 2 illustrerer agentskrivebordsarkitekturen i Webex CC.

Onboarding av kunder

Webex Control Hub er det primære grensesnittet som brukes av partnere og kunder for å introdusere kunder og aktivere eller konfigurere funksjoner.

Når organisasjons- og kontaktsenterfunksjonene er klargjort i Control Hub, vil det utløse en arbeidsflyt i Webex CC som utfører resten av trinnene i klargjøringen av alle kontaktsenterfunksjoner i henhold til tilbudene valgt av kunden.

All klargjøring av kontaktsenteret gjøres ved hjelp av en BPM-arbeidsflytmotor som muliggjør en deklarativ måte å definere de involverte trinnene på, og gjør hele klargjøringstrinnene motstandsdyktige mot feil og sikrer dataintegritet.

Figur 1 illustrerer klargjøringsarbeidsflyten i Webex CC.

Konfigurasjonsenheter

De viktigste konfigurasjonsenhetene i Webex CC, omfang i en organisasjon, er:

Nettstedet

Sted betyr et sted hvor ett eller flere team, brukere (agenter/veiledere) er lokalisert.

Hver bruker og gruppe må tilhøre et område.

Gruppe

En gruppe brukere. Team brukes til å distribuere samhandlinger til agenter via køer.

Hvert lag må tilhøre et nettsted.

Agenter

Brukere som kan logge på Agent Desktop og håndtere samhandlinger på tvers av medietypene som er konfigurert i Webex CC.

Tilsynspersoner

Veiledere er tildelt team og kan overvåke/coache agenten og ha tilgang til status på teamnivå og agentstatistikk for de som tilhører teamene som veilederen er tildelt.

Kø

En kø er en logisk enhet der samhandlinger kan holdes mens du venter på at agenter skal være tilgjengelige, som deretter rutes til agenten.

Køer tilordnes til team, som søkeområdet for agenter, med mulighet til å utvide søkeområdet basert på medgått tidsterskel, ved å legge til andre team i søkeområdet.

Entrypoint

Entrypoint er en logisk enhet som representerer inngangspunktet for samhandlinger for å komme inn i Webex CC. For telefoni kartlegges dette primært telefonnummeret som anropene kommer til, og for e-post-/meldingskanaler peker Entrypoint til ressurskonfigurasjonen i Webex Connect.

Flyt

Flyten knyttet til inngangspunktet (via rutingsstrategi), som bestemmer trinnene som er involvert i håndtering av samhandlinger.

For ikke-telefonikanaler (e-post, meldinger/sosiale medier) velges Flow som en del av ressurskonfigurasjonen i Webex Connect.

Tilgangskontroll for kontaktsentre på flere steder

Webex CC-administratorer kan konfigurere brukerprofiler med tilgangsrettigheter til bestemte områder, grupper, køer og inngangspunkter. Videre, på grunn av den hierarkiske naturen til steder og team, når tilgang til bestemte nettsteder er gitt, kan bare lagene eller datoen som gjelder teamene, som tilhører disse nettstedene eller et eksplisitt spesifisert delsett av slike team, nås av brukeren.

For køer og inngangspunkter er de globale på organisasjonsnivå, så for forskjellige geografiske steder (steder der bestemte agenter og team er plassert) kan separate inngangspunkter og køer konfigureres, og veiledere / brukere kan ha tilgang til de enhetene som gjelder for bestemte nettsteder.

Figur 2 illustrerer nøkkelkonfigurasjonsenhetene og brukerprofilen som refererer til disse enhetene.

I tillegg til å begrense tilgangen til disse enhetene, kan Webex CC-administratorer kontrollere de spesifikke egenskapene/modulene som en bruker kan få tilgang til i administrasjonsgrensesnittet, og dermed ha brukere med administrasjons-/konfigurasjonsrettigheter til bestemte enheter samt deler/muligheter i administrasjonsgrensesnittet for Webex CC.

Innebygde skrivebordskoblinger: CRM-program som primært grensesnitt

I denne driftsmodusen logger agenten på CRM-konsollen som det primære programmet.

Webex CC er et innebygd program (også kalt et innebygd skrivebordsprogram eller innebygd softphone) som primært brukes til å logge på kontaktsenteret og motta Webex CC-rutede kontaktsentersamhandlinger.

Når CRM-integreringen mottar et anrop eller en samtaleforespørsel, utfører den følgende handlinger på CRM-konsollen

• Skjermbilde viser kundeoppføringen som er knyttet til ANI eller andre anropstilknyttede data.

• Postere samtalemetadata som aktivitetsnotater i kundeoppføringen

• La agenten "klikke for å ringe" ved å klikke på kontakten i CRM og starte et utgående anrop til kunden

• Postering av anropsoppføringer i CRM-rapporteringstabellene for primærrapportering om CRM.

• Gir full funksjonalitet for Agent Desktop- og samtalekontroller (innebygd og minifisert versjon av skrivebordsappen)

Den primære integreringsmodusen med CRM-ene er å bygge inn CC Desktop Webex programmet i en separat iFrame.

Videre kjører Webex CC Desktop-programmet en egendefinert hodeløs widget (ingen brukergrensesnitt) i bakgrunnen, og samhandler med det underliggende CRM-systemet for å utføre automatiserte handlinger på vegne av agenten.

Samhandlingene drives av to SDK-er som den hodeløse widgeten bruker.

• Webex CC Desktop JS SDK: Dette er JavaScript SDK levert av Webex CC for å registrere hendelseslyttere for agent- og kontakthandlinger.

• CRM JS SDK: Dette er CRM-klient-SDK-en som gjelder per CRM som abstraherer REST API-anrop med CRM. For salesforce brukes for eksempel det CTI JS-biblioteket fra Salesforce til å utføre handlinger og lytte etter hendelser i CRM.

Figur 1 illustrerer CRM-arkitekturen for innebygd Webex CC-skrivebord og tilkobling

Webex CC støtter følgende CRM-løsninger for ovennevnte integrasjon:

• Salesforce

• ServiceNow

• Microsoft Dynamics 365

• Zendesk

• Freshdesk

For mer informasjon, besøk https://help.webex.com/en-us/result/integrate%20with%20webex%20contact%20center?offset=10.

Hvis du vil ha mer informasjon om hvordan du konfigurerer Webex CC-skrivebordsoppsett for aktivering av CRM-kobling, funksjonssett og endringslogger, kan du gå til https://github.com/CiscoDevNet/webex-contact-center-crm-integrationshttps://github.com/CiscoDevNet/webex-contact-center-crm-integrations.

Global tilgjengelighet av CRM-koblinger

CRM-koblingene er tilgjengelige i alle geografiske områder og områder der Webex CC er i drift.

Elastisk skalering og ytelse

Webex CC er vert for den tilpassede widgeten som muliggjør toveiskommunikasjon mellom CRM-applikasjonen og Webex CC-skrivebordet i AWS CloudFront CDN, noe som sikrer høy tilgjengelighet av widgeten AWS på tvers av tilgjengelighetssoner og regioner.

All CRM-integreringsspesifikk databehandling skjer i nettleseren der agenter bruker CRM-programmet med Webex CC-skrivebord innebygd i CRM-programmet.

Sikkerhet

CRM-koblingene startes via skrivebordsoppsettet for Webex CC-agent, og valgfrie parametere sendes via skrivebordsoppsettet til widgeten for å slå funksjoner på og av.

Hvis du for eksempel vil aktivere widgeten Salesforce-handlinger, kan administratoren slå på parameterinnstillingen sfdcWidgetEnabled til sann.

Installasjon av pakke

For at integreringen skal fungere toveis, må CRM-konsollen ha det innebygde programmet installert. Dette er for å støtte lasting av skrivebordsprogrammet inne i en iFrame.

Alle Desktop Embedded-koblingene er tilgjengelige på CRM-markedsplassen.

For eksempel,

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/

Installasjonen av markedsplassprogrammet aktiverer de nødvendige plugin-modulene og importerer de nødvendige XML-filene til CRM-konsollen for å støtte rapportering av anropsoppføringer i CRM.

Flytintegreringer via HTTP-koblinger i IVR

Webex CC Flow-byggherren støtter toveis dataflyter mellom Webex CC og CRM-systemet ved hjelp av HTTPs-koblinger konfigurert i Webex Control Hub og brukt på Webex CC Flow.

Disse brukes primært til tilpassing i talesamhandlinger og tilpasset ruting i IVR.

Som standard støtter Webex CC HTTP-koblingen Salesforce på Control Hub. De andre CRM-koblingene kan legges til som egendefinerte koblinger i Webex Control Hub.

Hvis du vil ha mer informasjon om HTTP-koblinger, kan du gå til https://github.com/CiscoDevNet/webex-contact-center-crm-integrations.

IVR HTTP-kontakter:

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

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

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

Taleinfrastruktur på Edge

Voice Edge-komponentene tillater SIP-trunker fra kundenettverk / PSTN-bærere å avslutte, og dette aktiveres basert på hvitelistede IP-er som har lov til å koble til kantkomponentene.

Beregn infrastruktursikkerhet

Webex CC-databehandlingsforekomster klargjøres i AWS, og tjenester kjører som pods i Kubernetes-klynge, som har flere navneområder og tilgang til hvert navneområde er begrenset med separat legitimasjon.

All klargjøring av infrastrukturen gjøres ved hjelp av kode – ingen manuelle trinn – og ingen av legitimasjonene kan nås manuelt.

Det er et sentralt legitimasjonslager med spesifikke baner konfigurert for spesifikt sett med tjenester / team, og tilgangen til selve legitimasjonslageret er begrenset og konfigurert som hemmeligheter i bygge- og distribusjonssystemene.

Ingen av infrastrukturkomponentene/tjenestene er direkte eksponert utenfor AWS VPC, og kun offentlig eksponerte grensesnitt er API-er og WebSocket-servere som styres og administreres ved hjelp av API-gateway,

Bortsett fra dette er det visse interne systemer og grensesnitt som brukes av utviklere som brukes til å vise logger, målestokker, distribusjonsdetaljer, byggestatus og testresultater, som er sikret ved hjelp av roller og grupper og integrert med Ciscos interne autentiseringssystemer.

Autentisering og autorisasjon for brukergrensesnitt

Alle brukergrensesnittene som brukes av ulike kontaktsenterbrukere (agenter, ledere, administratorer, analytikere), er beskyttet av Ciscos OAuth-flyter (Common Identity Based Bearer Token).

Autorisasjonen gjøres ved hjelp av roller for brukeren som fikk tokenet og omfangene som er tilordnet tokenet.

Data under overføring

Ingen av grensesnittene til tjenestene / infrastrukturkomponenten som er distribuert, er direkte eksponert for ekstern innkommende trafikk.

Utvalgte tjenester, med http APIer, eksponerer disse grensesnittene via en gateway, og all innkommende https (inkludert WebSocket) avsluttes i ALB og intern trafikk over http rutes til tjenestene.

Alle utgående interaksjoner er over https / TLS (for ikke http-protokoller).

Inne i VPC er den interne kommunikasjonen mellom tjenester - over http / custom TCP protocol - over vanlig TCP socket.

Data i hvile

Alle data som blir lagret, krypteres på lagringslaget. Videre er de datalagrene som er utenfor VPC, beskyttet og tilgangskontroll og autorisasjoner med legitimasjon sikkert lagret og administrert i et hemmelig lager.

Figur 1 illustrerer dataflyt og sikkerhetsmodell for transitt og hvile.

PII-data for sluttbruker

Webex CC Flow, som er den programmatiske kontrolleren for håndtering av samhandlinger, kan brukes til å samle inn brukerdata, som kan tilordnes flytvariabler som er spesielt merket som "Inneholder sensitive data". Verdiene for slike data er kryptert, og ingen tjenester i transittbanen til dataene vil ha tilgang til disse dataene.

Videre blir slike data aldri lagret i CC Webex rapporteringsdatalageret, og loggene/meldingsinfrastrukturen vil ha krypterte data og klartekstdata lagres ikke noe sted i Webex CC.

PII-data for kontaktsenteragent/-leder

Kontaktsenterets brukerrelaterte data redigeres i logger, men er tilgjengelige for dataanalyse og visualisering i Webex CC-datalageret.

Faktorer for skala

For Webex CC er faktorene som påvirker skalaen:

• Samtidig antall agenter logget på

• Samtidig antall interaksjoner pågår

  • Handlinger utført på disse samhandlingene

• Samtidig antall handlinger som veiledere / agenter utfører, utenfor håndtering av interaksjonene

• Volumet av dataene som genereres og vedvarer

Arkitektoniske aspekter som muliggjør skala

Prinsippene som Webex CC er bygget og designet etter, gjør at løsningen kan skaleres dynamisk etter behov innenfor rammene som håndheves av infrastrukturen som tilbys for de ulike tjenestene og plattformkomponentene.

Hendelsesdrevet arkitektur

Tjenestene i Webex CC kommuniserer ved hjelp av meldinger, og de kritiske meldingsbehandlingsflytene innebærer ingen blokkering av IO-operasjoner, og tilstanden som kreves for å behandle meldinger, er lokalisert til forekomsten av tjenesten som behandler meldingen.

Statsløse tjenester (eller eksternalisert tilstand)

Tilstandsløse tjenester muliggjør elastisitet ved enkelt å legge til/fjerne flere forekomster av tjenestene. Det er visse tjenester som er iboende stateful i naturen, og de har eksternalisert statlig butikk og infrastrukturen støtter dynamiske endringer i antall forekomster av slike tjenester også med automatisk rebalansering / statlig overføring / lokalisering av staten til forekomsten som trenger staten.

Elastisk infrastruktur

Alle tjenestene kjører i Kubernetes, og infrastrukturen, også kjent som Kubernetes-noder, skaleres automatisk basert på bruken, og dette gjør det mulig å legge til flere databehandlingsnoder dynamisk opp til en maksimal høy terskel som er forhåndskonfigurert.

Lastprojeksjon og regelmessig validering

Alle tjenestene er benchmarked for ytelsesegenskaper og skaleringsmønster er validert på tjenestenivå.

Ytterligere kontinuerlig validering, toppbelastning og utholdenhetstester utføres med testparametere justert for forventet vekst i skalaen som påvirker attributter, noe som gjør det mulig å identifisere flaskehalser, planlegge å oppdatere den høye terskelen for ressursbruk i infrastrukturen og være klar for spilldagen.

Telefoni

For telefoni avgjøres håndteringen av innkommende taleanrop av hvordan anropet kom inn i kontaktsenteret (se Inngående mekanismer nedenfor) og Webex CC-flyten som er knyttet til inngangspunktet.

Anropet blir besvart, og ytterligere handlinger utføres i henhold til CC Flow Webex definisjonen – som er en programmatisk representasjon av handlingene som skal utføres under håndtering av anropet, enten før kø og ruting til en agent, eller selve flyten kan håndtere samtalen uten overføring til en agent.

Flow Builder i Webex CC lar utviklere definere flyten og tilordne den til inngangspunktet som anropet ankommer via i Webex CC.

Disse konfigurasjonsenhetene og bruken av dem dekkes i konfigurasjonsenheter.

Mer informasjon om Flow Builder er dekket i den kommende delen om IVR System.

E-post og meldinger

Fra Webex CC-perspektiv gir Webex Connect inngående og utgående funksjoner for alle digitale kanaler – e-post, meldingskanaler, som sluttbrukere kan bruke til å kontakte kontaktsenteret.

Webex Connect-flyt

• Bestemmer håndteringen av slike samhandlinger til samhandlingene er satt i kø og rutet til agenter. Dette inkluderer automatisk håndtering og BOT-behandlinger for alle former for meldings- og e-postinteraksjoner.

• Bruker forretningslogikk på innkommende samhandling.

• Håndterer kontakt før du setter deg i kø.

• Flow selv kan håndtere samhandlingen uten overføring til live agent.

Meldingskanalene som støttes av Webex CC er:

• Web App / Mobil App Chat

• Whatsapp

• Facebook Messenger

• SMS

E-postkanalene som støttes av Webex CC er:

• Gmail

• Office365

Inntrengningsmekanismer

Denne delen dekker mekanismene som en interaksjon kan komme inn i Webex CC. Basert på medietypen er mekanismene som en interaksjon når Webex CC forskjellige.

I telefoni er det for eksempel nødvendig med klargjøring av fysisk infrastruktur for å aktivere PSTN-tilkobling, konfigurasjon av telefonnumre og ruting av anropene til Webex CC.

For e-post-/meldingskanaler må inngangskonfigurasjonen gjøres i Webex Koble til, og den involverer klargjøring av e-post-/meldingskonto og Webex Connect-flytkonfigurasjon.

Innkommende tale

For taleanrop er et typisk scenario der brukere ringer et PSTN-telefonnummer som deretter kobles til kontaktsenteret. Fra et inngangsperspektiv trenger dette en mekanisme for å rute anrop fra PSTN til Webex CC.

Figuren nedenfor illustrerer inntaket av taleanrop til Webex CC.

Voice Ingress Services i Webex CC utfører tredjeparts samtalekontroll ved hjelp av SIP og svarer på det innkommende anropet, samt utfører overførings-, konferanse- og andre samtalekontrolloperasjoner.

Det logiske inngangspunktet for anrop i Webex CC er konfigurasjonsenheten kalt Entrypoint. For taleinngang er nøkkelkonfigurasjonen for Entrypoint telefonnummeret som er knyttet til det, som vanligvis er et gyldig PSTN-telefonnummer hentet fra valgt PSTN-leverandør.

Dette gjør det mulig å oppdage innkommende anrop på telefonnummeret, knytte anropet til Entrypoint og bruke andre konfigurasjonsparametere for inngangspunktet til å håndtere anropet i henhold til definisjonen for Webex CC-flyt som skal utløses for samhandlingen.

Merk:

Hvis du vil ha mer informasjon om alternativene for PSTN-tilkobling, kan du gå til 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.

Skalerbarhet og tilgjengelighet for infrastruktur for talekant

Webex CC VPOP-infrastrukturen inkluderer redundante SIP SBC-par, noe som sikrer høy tilgjengelighet og flere SBC-er kan legges til for å skalere de samtidige anropsvolumene som skal støttes.

Maks samtidige anrop som VPOP kan håndtere, avhenger av antall SBC-er som kjører, og som anrop sendes til.

For geografisk redundans – et nett av VPOP SBC med sammenkoblinger på tvers av flere par på tvers av regioner støttes.

For taleinngangstjenester er de horisontalt skalerbare for å håndtere et økende antall samtidige taleanrop som skal inntas til Webex CC.

Sikkerhetshensyn med talekantinfrastruktur

Tabellen nedenfor inneholder detaljer om tilkoblingsalternativene til Voice Edge-infrastrukturen.

For mer informasjon, 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

Hvert taleanrop som kommer inn i et telefonnummer som er tilknyttet et inngangspunkt, blir besvart av Webex CC, og kjøring av en Webex CC-flyt tilknyttet inngangspunktet, starter.

Webex CC Flow Builder leverer programmeringskonstruksjoner/operatorer og funksjonelle blokker, kalt aktiviteter, slik at administratorer eller andre som utformer og implementerer den IVR logikken, kan kombinere disse byggeklossene og opprette flytdefinisjonen.

Programmeringskonstruksjonene som Flow støtter, er:

• Deklarasjons- og innstillingsvariabler – tilstand knyttet til en flytkjøring

  • Pebble-uttrykk for å angi verdien av variabler

• Betingede kontroller

• Looping - bruk av Conditionals og Go To (evne til å kjede aktiviteter sammen)

• Aktivere REST API-er

• Analyseringsdata - JSON, TOML, XML vanligvis brukt til å analysere API svar.

• Komponere aktiviteter

Et representativt sett med aktiviteter som Flow-forsyninger er: Spill av meldinger Samle inn brukerdata Overføre samtalen til en annen destinasjon/et annet telefonnummer Send samtalen til en virtuell agent Sett anropet i kø slik at det kan besvares av en agent.

For hvert anrop som er aktivt, er en forekomst av flytkjøring også aktiv til samtalen avsluttes, noe som resulterer i samtidige kjøringer av flyter.

Hver forekomst av flytkjøring gir isolert miljø for data / tilstand knyttet til flyten og der av anropet.

I løpet av hele anropets livssyklus gjør flyt det også mulig å svare på bestemte hendelser som skjer, og håndtere dem – når et anrop for eksempel besvares av en agent, kan en hendelsesbehandling utløse et skjermvindu i grensesnittet for agentskrivebordet.

Hvis du vil ha mer informasjon om Webex CC Flow, kan du se https://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øtte for virtuell agent

Flow leverer en aktivitet for å levere samhandlingen til en virtuell agent, som er forhåndskonfigurert i Webex Control Hub.

Når samtalen er koblet til en virtuell agent, gir den en samtaleopplevelse IVR brukeren og aktiviteten avsluttes enten med avslutning av samtalen eller med eskalering av anropet til en agent.

Ved eskalering kan flyten konfigureres til å sette anropet i kø, som deretter blir besvart av en agent.

Innkommende digitale interaksjoner

For e-post og meldingskanal for innkommende samhandlinger bruker Webex CC Webex Connect til klargjøring av aktiva, flyt for å håndtere innkommende samhandlinger og deretter rute samhandlingen til Webex CC når Webex Connect-flyten eksplisitt setter samhandlingen i kø slik at den kan håndteres av en agent.

Figuren nedenfor illustrerer inntak av e-post, meldingsinteraksjoner i Webex CC.

Virtual Agent / BOT-integrasjoner

For samhandlinger med e-post og meldinger eller sosiale kanaler konfigureres de virtuelle agent-/BOT-behandlingene i Webex Connect-flyten.

På samme måte som med Virtual Agents for Voice, hvis BOT-behandlingen ender med eskalering som resultat, blir samhandlingen lagt i kø og rutet til en agent.

Valg av agent

Køer i Webex CC støtter følgende algoritmer for agentvalg:

• Lengste tilgjengelige agentruting

• Dyktig basert ruting

  • Lengste tilgjengelige agent (LAA)

  • Beste tilgjengelige agent (BAA)

Agenter er knyttet til køer gjennom Teams.

En kø kan tilordnes flere anropsdistribusjonsgrupper (der hver gruppe har ett eller flere team), på en sekvensiell måte med konfigurert venting på at anropsdistribusjonsgruppe skal legges til i køen, slik at søkeområdet for en samsvarende agent utvides til flere anropsdistribusjonsgrupper etter hvert som tiden går.

For ferdighetsbasert ruting, blant kompetansekravene som samsvarer med agenter som er knyttet til køen, velges en agent basert på LAA- eller BAA-konfigurasjon.

Spesifikke tilleggsfunksjoner for tale/telefoni

Agentbasert ruting (kun for tale-/telefonikanaler)

Webex CC Flow kan ved hjelp av aktiviteten QueueToAgent rute samhandlinger direkte til den valgte agenten basert på agent-ID-en.

Hvis agenten ikke er tilgjengelig for å håndtere samhandlinger, kan samhandlingen parkeres i en agentspesifikk kø og vente på at agenten blir tilgjengelig

Avansert køinformasjon

Webex CC Flow kan ved hjelp av aktiviteten GetQueueInfo hente sanntidsinformasjon for en kø som Posisjon i kø (PIQ), Estimert ventetid (EWT), antall agenter som er tilgjengelige i køen, og kan brukes til å avgjøre om kontakten skal settes i kø eller ikke.

Høflighet tilbakeringing

Webex CC Flow, ved hjelp av aktiviteten Tilbakeringing, lar kunden koble fra samtalen mens posisjonen i køen opprettholdes, og motta en tilbakeringing når den virtuelle samhandlingen i køen rutes til en agent.

Håndtering av overløp

Webex CC støtter overflythåndtering ved hjelp av kapasitetsbaserte team (CBT).

CBT er som et vanlig team med en kapasitet og en tilknyttet ekstern DN som tjener den kapasiteten. Den kan konfigureres sammen med andre team i distribusjonssyklusene for køanrop.

Vanligvis konfigureres dette som den siste syklusen, slik at det fungerer som en overflyt hvis ingen agent er tilgjengelig, selv etter at alle de konfigurerte anropsdistribusjonsgruppene ikke finner en tilgjengelig samsvarende agent for håndtering av samhandlingen.

Agent Desktop Operasjoner

Når en agent logger på Webex CC Agent Desktop, angir agenten et telefonnummer som innkommende anrop til agenten kan kobles til. Dette kan være en PSTN-telefon, mobiltelefon eller et internnummer hvis agenten er en Cisco Webex Calling bruker.

Vær oppmerksom på at dette nummeret må være et gyldig telefonnummer som anrop kan rutes til. Hvis ikke, kan ikke agenten motta innkommende anrop.

Basert på typen samhandling som agenten håndterer, gir widgetene i agentskrivebordet muligheten til å utføre bestemte mediekontrolloperasjoner.

Når et anrop er besvart, kan agenten for eksempel utføre følgende operasjoner knyttet til anropet.

• Sett samtalen på vent

• Start konsultasjonssamtale og

  • Overfør samtalen til et annet telefonnummer (si agenttelefonnummer) / inngangspunkt

  • Sende en annen agent til samtalen i konferanse

• Overføre samtalen til en annen kø

• Avslutte samtalen

Med Agent Desktop kan administratorer legge til egendefinerte widgeter der ved å utvide skrivebordsfunksjonene og gjøre det til en enhetlig samling av widgeter som agenter trenger for å få arbeidet gjort på en effektiv måte.

Skrivebordsarkitektur

Agent desktop er en mikro frontend basert enkeltside program som er vert for widgets bygget basert på webkomponenter arkitektur. Alle standard-/lagerwidgetene drives av data som hentes av API-er eller push-mekanismer på serversiden.

Dette er vanligvis asynkrone API-er, der svaret på en påkallelse kommer til skrivebordet via en WebSocket-tilkobling.

Webex CC-Agent Desktop godkjenner brukere med Cisco Common Identity (CI), og tokenet sendes videre til alle API aktiveringer. Også for egendefinerte widgeter, basert på godkjenningsmodellen, gir den en enkel påloggingsopplevelse til agenter hvis godkjenningsmodellen til den egendefinerte widgeten er integrert med CI.

Når en agent er en del av en samhandling, sendes alle oppdateringer til samhandlingstilstanden eller tilknyttede data også til skrivebordet via WebSocket-tilkoblingen.

Robusthet fra skrivebordet til tilkobling og ventetid

Den asynkrone API og push-en på serversiden muliggjør skalering, og eventuelle tilkoblingstap til WebSocket-grensesnittet oppdages, og skrivebordet forsøker å koble til på nytt og logge på på nytt.

Figuren nedenfor illustrerer agentskrivebordsarkitekturen i Webex CC.

Onboarding av kunder

Webex Control Hub er det primære grensesnittet som brukes av partnere og kunder for å introdusere kunder og aktivere eller konfigurere funksjoner.

Når organisasjons- og kontaktsenterfunksjonene er klargjort i Control Hub, vil det utløse en arbeidsflyt i Webex CC som utfører resten av trinnene i klargjøringen av alle kontaktsenterfunksjoner i henhold til tilbudene valgt av kunden.

All klargjøring av kontaktsenteret gjøres ved hjelp av en BPM-arbeidsflytmotor som muliggjør en deklarativ måte å definere de involverte trinnene på, og gjør hele klargjøringstrinnene motstandsdyktige mot feil og sikrer dataintegritet.

Figuren nedenfor illustrerer klargjøringsarbeidsflyten i Webex CC.

Konfigurasjonsenheter

De viktigste konfigurasjonsenhetene i Webex CC, omfang i en organisasjon, er:

Nettstedet

Sted betyr et sted hvor ett eller flere team, brukere (agenter/veiledere) er lokalisert.

Hver bruker og gruppe må tilhøre et område.

Gruppe

En gruppe brukere. Team brukes til å distribuere samhandlinger til agenter via køer.

Hvert lag må tilhøre et nettsted.

Agenter

Brukere som kan logge på Agent Desktop og håndtere samhandlinger på tvers av medietypene som er konfigurert i Webex CC.

Tilsynspersoner

Veiledere er tildelt team og kan overvåke/coache agenten og ha tilgang til status på teamnivå og agentstatistikk for de som tilhører teamene som veilederen er tildelt.

Kø

En kø er en logisk enhet der samhandlinger kan holdes mens du venter på at agenter skal være tilgjengelige, som deretter rutes til agenten.

Køer tilordnes til team, som søkeområdet for agenter, med mulighet til å utvide søkeområdet basert på medgått tidsterskel, ved å legge til andre team i søkeområdet.

Entrypoint

Entrypoint er en logisk enhet som representerer inngangspunktet for samhandlinger for å komme inn i Webex CC. For telefoni kartlegges dette primært telefonnummeret som anropene kommer til, og for e-post-/meldingskanaler peker Entrypoint til ressurskonfigurasjonen i Webex Connect.

Flyt

Flyten knyttet til inngangspunktet (via rutingsstrategi), som bestemmer trinnene som er involvert i håndtering av samhandlinger.

For ikke-telefonikanaler (e-post, meldinger/sosiale medier) velges Flow som en del av ressurskonfigurasjonen i Webex Connect.

Tilgangskontroll for kontaktsentre på flere steder

Webex CC-administratorer kan konfigurere brukerprofiler med tilgangsrettigheter til bestemte områder, grupper, køer og inngangspunkter. Videre, på grunn av den hierarkiske naturen til steder og team, når tilgang til bestemte nettsteder er gitt, kan bare lagene eller datoen som gjelder teamene, som tilhører disse nettstedene eller et eksplisitt spesifisert delsett av slike team, nås av brukeren.

For køer og inngangspunkter er de globale på organisasjonsnivå, så for forskjellige geografiske steder (steder der bestemte agenter og team er plassert) kan separate inngangspunkter og køer konfigureres, og veiledere / brukere kan ha tilgang til de enhetene som gjelder for bestemte nettsteder.

Figuren nedenfor illustrerer de viktigste konfigurasjonsenhetene og brukerprofilen som refererer til disse enhetene.

I tillegg til å begrense tilgangen til disse enhetene, kan Webex CC-administratorer kontrollere de spesifikke egenskapene/modulene som en bruker kan få tilgang til i administrasjonsgrensesnittet, og dermed ha brukere med administrasjons-/konfigurasjonsrettigheter til bestemte enheter samt deler/muligheter i administrasjonsgrensesnittet for Webex CC.

Innebygde skrivebordskoblinger: CRM-program som primært grensesnitt

I denne driftsmodusen logger agenten på CRM-konsollen som det primære programmet.

Webex CC er et innebygd program (også kalt et innebygd skrivebordsprogram eller innebygd softphone) som primært brukes til å logge på kontaktsenteret og motta Webex CC-rutede kontaktsentersamhandlinger.

Når CRM-integreringen mottar et anrop eller en samtaleforespørsel, utfører den følgende handlinger på CRM-konsollen

• Skjermbilde viser kundeoppføringen som er knyttet til ANI eller andre anropstilknyttede data.

• Postere samtalemetadata som aktivitetsnotater i kundeoppføringen

• La agenten "klikke for å ringe" ved å klikke på kontakten i CRM og starte et utgående anrop til kunden

• Postering av anropsoppføringer i CRM-rapporteringstabellene for primærrapportering om CRM.

• Gir full funksjonalitet for Agent Desktop- og samtalekontroller (innebygd og minifisert versjon av skrivebordsappen)

Den primære integreringsmodusen med CRM-ene er å bygge inn CC Desktop Webex programmet i en separat iFrame.

Videre kjører Webex CC Desktop-programmet en egendefinert hodeløs widget (ingen brukergrensesnitt) i bakgrunnen, og samhandler med det underliggende CRM-systemet for å utføre automatiserte handlinger på vegne av agenten.

Samhandlingene drives av to SDK-er som den hodeløse widgeten bruker.

• Webex CC Desktop JS SDK: Dette er JavaScript SDK levert av Webex CC for å registrere hendelseslyttere for agent- og kontakthandlinger.

• CRM JS SDK: Dette er CRM-klient-SDK-en som gjelder per CRM som abstraherer REST API-anrop med CRM. For salesforce brukes for eksempel det CTI JS-biblioteket fra Salesforce til å utføre handlinger og lytte etter hendelser i CRM.

Figuren nedenfor illustrerer CRM-arkitekturen for innebygd Webex CC-skrivebord og koblinger

Webex CC støtter følgende CRM-løsninger for ovennevnte integrasjon:

• Salesforce

• ServiceNow

• Microsoft Dynamics 365

• Zendesk

• Freshdesk

For mer informasjon, besøk https://help.webex.com/en-us/result/integrate%20with%20webex%20contact%20center?offset=10.

Hvis du vil ha mer informasjon om hvordan du konfigurerer Webex CC-skrivebordsoppsett for aktivering av CRM-kobling, funksjonssett og endringslogger, kan du gå til https://github.com/Ciscodevnet/webex-contact-center-crm-integrations.

Global tilgjengelighet av CRM-koblinger

CRM-koblingene er tilgjengelige i alle geografiske områder og områder der Webex CC er i drift.

Elastisk skalering og ytelse

Webex CC er vert for den tilpassede widgeten som muliggjør toveiskommunikasjon mellom CRM-applikasjonen og Webex CC-skrivebordet i AWS CloudFront CDN, noe som sikrer høy tilgjengelighet av widgeten AWS på tvers av tilgjengelighetssoner og regioner.

All CRM-integreringsspesifikk databehandling skjer i nettleseren der agenter bruker CRM-programmet med Webex CC-skrivebord innebygd i CRM-programmet.

Sikkerhet

CRM-koblingene startes via skrivebordsoppsettet for Webex CC-agent, og valgfrie parametere sendes via skrivebordsoppsettet til widgeten for å slå funksjoner på og av.

Hvis du for eksempel vil aktivere widgeten Salesforce-handlinger, kan administratoren slå på parameterinnstillingen sfdcWidgetEnabled til sann.

Installasjon av pakke

For at integreringen skal fungere toveis, må CRM-konsollen ha det innebygde programmet installert. Dette er for å støtte lasting av skrivebordsprogrammet inne i en iFrame.

Alle Desktop Embedded-koblingene er tilgjengelige på CRM-markedsplassen.

For eksempel,

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/

Installasjonen av markedsplassprogrammet aktiverer de nødvendige plugin-modulene og importerer de nødvendige XML-filene til CRM-konsollen for å støtte rapportering av anropsoppføringer i CRM.

Flytintegreringer via HTTP-koblinger i IVR

Webex CC Flow-byggherren støtter toveis dataflyter mellom Webex CC og CRM-systemet ved hjelp av HTTPs-koblinger konfigurert i Webex Control Hub og brukt på Webex CC Flow.

Disse brukes primært til tilpassing i talesamhandlinger og tilpasset ruting i IVR.

Som standard støtter Webex CC HTTP-koblingen Salesforce på Control Hub. De andre CRM-koblingene kan legges til som egendefinerte koblinger i Webex Control Hub.

Hvis du vil ha mer informasjon om HTTP-koblinger, kan du gå til https://github.com/CiscoDevNet/webex-contact-center-crm-integrations.

IVR HTTP-kontakter:

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

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

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

Taleinfrastruktur på Edge

Voice Edge-komponentene tillater SIP-trunker fra kundenettverk / PSTN-bærere å avslutte, og dette aktiveres basert på hvitelistede IP-er som har lov til å koble til kantkomponentene.

Beregn infrastruktursikkerhet

Webex CC-databehandlingsforekomster klargjøres i AWS, og tjenester kjører som pods i Kubernetes-klynge, som har flere navneområder og tilgang til hvert navneområde er begrenset med separat legitimasjon.

All klargjøring av infrastrukturen gjøres ved hjelp av kode – ingen manuelle trinn – og ingen av legitimasjonene kan nås manuelt.

Det er et sentralt legitimasjonslager med spesifikke baner konfigurert for spesifikt sett med tjenester / team, og tilgangen til selve legitimasjonslageret er begrenset og konfigurert som hemmeligheter i bygge- og distribusjonssystemene.

Ingen av infrastrukturkomponentene/tjenestene er direkte eksponert utenfor AWS VPC, og kun offentlig eksponerte grensesnitt er API-er og WebSocket-servere som styres og administreres ved hjelp av API-gateway,

Bortsett fra dette er det visse interne systemer og grensesnitt som brukes av utviklere som brukes til å vise logger, målestokker, distribusjonsdetaljer, byggestatus og testresultater, som er sikret ved hjelp av roller og grupper og integrert med Ciscos interne autentiseringssystemer.

Autentisering og autorisasjon for brukergrensesnitt

Alle brukergrensesnittene som brukes av ulike kontaktsenterbrukere (agenter, ledere, administratorer, analytikere), er beskyttet av Ciscos OAuth-flyter (Common Identity Based Bearer Token).

Autorisasjonen gjøres ved hjelp av roller for brukeren som fikk tokenet og omfangene som er tilordnet tokenet.

Data under overføring

Ingen av grensesnittene til tjenestene / infrastrukturkomponenten som er distribuert, er direkte eksponert for ekstern innkommende trafikk.

Utvalgte tjenester, med http APIer, eksponerer disse grensesnittene via en gateway, og all innkommende https (inkludert WebSocket) avsluttes i ALB og intern trafikk over http rutes til tjenestene.

Alle utgående interaksjoner er over https / TLS (for ikke http-protokoller).

Inne i VPC er den interne kommunikasjonen mellom tjenester - over http / custom TCP protocol - over vanlig TCP socket.

Data i hvile

Alle data som blir lagret, krypteres på lagringslaget. Videre er de datalagrene som er utenfor VPC, beskyttet og tilgangskontroll og autorisasjoner med legitimasjon sikkert lagret og administrert i et hemmelig lager.

Figuren nedenfor illustrerer dataflyten og sikkerhetsmodellen for både transitt og hvile.

PII-data for sluttbruker

Webex CC Flow, som er den programmatiske kontrolleren for håndtering av samhandlinger, kan brukes til å samle inn brukerdata, som kan tilordnes flytvariabler som er spesielt merket som "Inneholder sensitive data". Verdiene for slike data er kryptert, og ingen tjenester i transittbanen til dataene vil ha tilgang til disse dataene.

Videre blir slike data aldri lagret i CC Webex rapporteringsdatalageret, og loggene/meldingsinfrastrukturen vil ha krypterte data og klartekstdata lagres ikke noe sted i Webex CC.

PII-data for kontaktsenteragent/-leder

Kontaktsenterets brukerrelaterte data redigeres i logger, men er tilgjengelige for dataanalyse og visualisering i Webex CC-datalageret.

Faktorer for skala

For Webex CC er faktorene som påvirker skalaen:

• Samtidig antall agenter logget på

• Samtidig antall interaksjoner pågår

  • Handlinger utført på disse samhandlingene

• Samtidig antall handlinger som veiledere / agenter utfører, utenfor håndtering av interaksjonene

• Volumet av dataene som genereres og vedvarer

Arkitektoniske aspekter som muliggjør skala

Prinsippene som Webex CC er bygget og designet etter, gjør at løsningen kan skaleres dynamisk etter behov innenfor rammene som håndheves av infrastrukturen som tilbys for de ulike tjenestene og plattformkomponentene.

Hendelsesdrevet arkitektur

Tjenestene i Webex CC kommuniserer ved hjelp av meldinger, og de kritiske meldingsbehandlingsflytene innebærer ingen blokkering av IO-operasjoner, og tilstanden som kreves for å behandle meldinger, er lokalisert til forekomsten av tjenesten som behandler meldingen.

Statsløse tjenester (eller eksternalisert tilstand)

Tilstandsløse tjenester muliggjør elastisitet ved enkelt å legge til/fjerne flere forekomster av tjenestene. Det er visse tjenester som er iboende stateful i naturen, og de har eksternalisert statlig butikk og infrastrukturen støtter dynamiske endringer i antall forekomster av slike tjenester også med automatisk rebalansering / statlig overføring / lokalisering av staten til forekomsten som trenger staten.

Elastisk infrastruktur

Alle tjenestene kjører i Kubernetes, og infrastrukturen, også kjent som Kubernetes-noder, skaleres automatisk basert på bruken, og dette gjør det mulig å legge til flere databehandlingsnoder dynamisk opp til en maksimal høy terskel som er forhåndskonfigurert.

Lastprojeksjon og regelmessig validering

Alle tjenestene er benchmarked for ytelsesegenskaper og skaleringsmønster er validert på tjenestenivå.

Ytterligere kontinuerlig validering, toppbelastning og utholdenhetstester utføres med testparametere justert for forventet vekst i skalaen som påvirker attributter, noe som gjør det mulig å identifisere flaskehalser, planlegge å oppdatere den høye terskelen for ressursbruk i infrastrukturen og være klar for spilldagen.

Telefoni

For telefoni avgjøres håndteringen av innkommende taleanrop av hvordan anropet kom inn i kontaktsenteret (se Inngående mekanismer nedenfor) og Webex CC-flyten som er knyttet til inngangspunktet.

Anropet blir besvart, og ytterligere handlinger utføres i henhold til CC Flow Webex definisjonen – som er en programmatisk representasjon av handlingene som skal utføres under håndtering av anropet, enten før kø og ruting til en agent, eller selve flyten kan håndtere samtalen uten overføring til en agent.

Flow Builder i Webex CC lar utviklere definere flyten og tilordne den til inngangspunktet som anropet ankommer via i Webex CC.

Disse konfigurasjonsenhetene og bruken av dem dekkes i konfigurasjonsenheter.

Mer informasjon om Flow Builder er dekket i den kommende delen om IVR System.

E-post og meldinger

Fra Webex CC-perspektiv gir Webex Connect inngående og utgående funksjoner for alle digitale kanaler – e-post, meldingskanaler, som sluttbrukere kan bruke til å kontakte kontaktsenteret.

Webex Connect-flyt

• Bestemmer håndteringen av slike samhandlinger til samhandlingene er satt i kø og rutet til agenter. Dette inkluderer automatisk håndtering og BOT-behandlinger for alle former for meldings- og e-postinteraksjoner.

• Bruker forretningslogikk på innkommende samhandling.

• Håndterer kontakt før du setter deg i kø.

• Flow selv kan håndtere samhandlingen uten overføring til live agent.

Meldingskanalene som støttes av Webex CC er:

• Web App / Mobil App Chat

• Whatsapp

• Facebook Messenger

• SMS

E-postkanalene som støttes av Webex CC er:

• Gmail

• Office365

Inntrengningsmekanismer

Denne delen dekker mekanismene som en interaksjon kan komme inn i Webex CC. Basert på medietypen er mekanismene som en interaksjon når Webex CC forskjellige.

I telefoni er det for eksempel nødvendig med klargjøring av fysisk infrastruktur for å aktivere PSTN-tilkobling, konfigurasjon av telefonnumre og ruting av anropene til Webex CC.

For e-post-/meldingskanaler må inngangskonfigurasjonen gjøres i Webex Koble til, og den involverer klargjøring av e-post-/meldingskonto og Webex Connect-flytkonfigurasjon.

Innkommende tale

For taleanrop er et typisk scenario der brukere ringer et PSTN-telefonnummer som deretter kobles til kontaktsenteret. Fra et inngangsperspektiv trenger dette en mekanisme for å rute anrop fra PSTN til Webex CC.

Figuren nedenfor illustrerer inntaket av taleanrop til Webex CC.

Voice Ingress Services i Webex CC utfører tredjeparts samtalekontroll ved hjelp av SIP og svarer på det innkommende anropet, samt utfører overførings-, konferanse- og andre samtalekontrolloperasjoner.

Det logiske inngangspunktet for anrop i Webex CC er konfigurasjonsenheten kalt Entrypoint. For taleinngang er nøkkelkonfigurasjonen for Entrypoint telefonnummeret som er knyttet til det, som vanligvis er et gyldig PSTN-telefonnummer hentet fra valgt PSTN-leverandør.

Dette gjør det mulig å oppdage innkommende anrop på telefonnummeret, knytte anropet til Entrypoint og bruke andre konfigurasjonsparametere for inngangspunktet til å håndtere anropet i henhold til definisjonen for Webex CC-flyt som skal utløses for samhandlingen.

Merk:

Hvis du vil ha mer informasjon om alternativene for PSTN-tilkobling, kan du gå til 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.

Skalerbarhet og tilgjengelighet for infrastruktur for talekant

Webex CC VPOP-infrastrukturen inkluderer redundante SIP SBC-par, noe som sikrer høy tilgjengelighet og flere SBC-er kan legges til for å skalere de samtidige anropsvolumene som skal støttes.

Maks samtidige anrop som VPOP kan håndtere, avhenger av antall SBC-er som kjører, og som anrop sendes til.

For geografisk redundans – et nett av VPOP SBC med sammenkoblinger på tvers av flere par på tvers av regioner støttes.

For taleinngangstjenester er de horisontalt skalerbare for å håndtere et økende antall samtidige taleanrop som skal inntas til Webex CC.

Sikkerhetshensyn med talekantinfrastruktur

Tabellen nedenfor inneholder detaljer om tilkoblingsalternativene til Voice Edge-infrastrukturen.

For mer informasjon, 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

Hvert taleanrop som kommer inn i et telefonnummer som er tilknyttet et inngangspunkt, blir besvart av Webex CC, og kjøring av en Webex CC-flyt tilknyttet inngangspunktet, starter.

Webex CC Flow Builder leverer programmeringskonstruksjoner/operatorer og funksjonelle blokker, kalt aktiviteter, slik at administratorer eller andre som utformer og implementerer den IVR logikken, kan kombinere disse byggeklossene og opprette flytdefinisjonen.

Programmeringskonstruksjonene som Flow støtter, er:

• Deklarasjons- og innstillingsvariabler – tilstand knyttet til en flytkjøring

  • Pebble-uttrykk for å angi verdien av variabler

• Betingede kontroller

• Looping - bruk av Conditionals og Go To (evne til å kjede aktiviteter sammen)

• Aktivere REST API-er

• Analyseringsdata - JSON, TOML, XML vanligvis brukt til å analysere API svar.

• Komponere aktiviteter

Et representativt sett med aktiviteter som Flow-forsyninger er: Spill av meldinger Samle inn brukerdata Overføre samtalen til en annen destinasjon/et annet telefonnummer Send samtalen til en virtuell agent Sett anropet i kø slik at det kan besvares av en agent.

For hvert anrop som er aktivt, er en forekomst av flytkjøring også aktiv til samtalen avsluttes, noe som resulterer i samtidige kjøringer av flyter.

Hver forekomst av flytkjøring gir isolert miljø for data / tilstand knyttet til flyten og der av anropet.

I løpet av hele anropets livssyklus gjør flyt det også mulig å svare på bestemte hendelser som skjer, og håndtere dem – når et anrop for eksempel besvares av en agent, kan en hendelsesbehandling utløse et skjermvindu i grensesnittet for agentskrivebordet.

Hvis du vil ha mer informasjon om Webex CC Flow, kan du se https://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øtte for virtuell agent

Flow leverer en aktivitet for å levere samhandlingen til en virtuell agent, som er forhåndskonfigurert i Webex Control Hub.

Når samtalen er koblet til en virtuell agent, gir den en samtaleopplevelse IVR brukeren og aktiviteten avsluttes enten med avslutning av samtalen eller med eskalering av anropet til en agent.

Ved eskalering kan flyten konfigureres til å sette anropet i kø, som deretter blir besvart av en agent.

Innkommende digitale interaksjoner

For e-post og meldingskanal for innkommende samhandlinger bruker Webex CC Webex Connect til klargjøring av aktiva, flyt for å håndtere innkommende samhandlinger og deretter rute samhandlingen til Webex CC når Webex Connect-flyten eksplisitt setter samhandlingen i kø slik at den kan håndteres av en agent.

Figuren nedenfor illustrerer inntak av e-post, meldingsinteraksjoner i Webex CC.

Virtual Agent / BOT-integrasjoner

For samhandlinger med e-post og meldinger eller sosiale kanaler konfigureres de virtuelle agent-/BOT-behandlingene i Webex Connect-flyten.

På samme måte som med Virtual Agents for Voice, hvis BOT-behandlingen ender med eskalering som resultat, blir samhandlingen lagt i kø og rutet til en agent.

Valg av agent

Køer i Webex CC støtter følgende algoritmer for agentvalg:

• Lengste tilgjengelige agentruting

• Dyktig basert ruting

  • Lengste tilgjengelige agent (LAA)

  • Beste tilgjengelige agent (BAA)

Agenter er knyttet til køer gjennom Teams.

En kø kan tilordnes flere anropsdistribusjonsgrupper (der hver gruppe har ett eller flere team), på en sekvensiell måte med konfigurert venting på at anropsdistribusjonsgruppe skal legges til i køen, slik at søkeområdet for en samsvarende agent utvides til flere anropsdistribusjonsgrupper etter hvert som tiden går.

For ferdighetsbasert ruting, blant kompetansekravene som samsvarer med agenter som er knyttet til køen, velges en agent basert på LAA- eller BAA-konfigurasjon.

Spesifikke tilleggsfunksjoner for tale/telefoni

Agentbasert ruting (kun for tale-/telefonikanaler)

Webex CC Flow kan ved hjelp av aktiviteten QueueToAgent rute samhandlinger direkte til den valgte agenten basert på agent-ID-en.

Hvis agenten ikke er tilgjengelig for å håndtere samhandlinger, kan samhandlingen parkeres i en agentspesifikk kø og vente på at agenten blir tilgjengelig

Avansert køinformasjon

Webex CC Flow kan ved hjelp av aktiviteten GetQueueInfo hente sanntidsinformasjon for en kø som Posisjon i kø (PIQ), Estimert ventetid (EWT), antall agenter som er tilgjengelige i køen, og kan brukes til å avgjøre om kontakten skal settes i kø eller ikke.

Høflighet tilbakeringing

Webex CC Flow, ved hjelp av aktiviteten Tilbakeringing, lar kunden koble fra samtalen mens posisjonen i køen opprettholdes, og motta en tilbakeringing når den virtuelle samhandlingen i køen rutes til en agent.

Håndtering av overløp

Webex CC støtter overflythåndtering ved hjelp av kapasitetsbaserte team (CBT).

CBT er som et vanlig team med en kapasitet og en tilknyttet ekstern DN som tjener den kapasiteten. Den kan konfigureres sammen med andre team i distribusjonssyklusene for køanrop.

Vanligvis konfigureres dette som den siste syklusen, slik at det fungerer som en overflyt hvis ingen agent er tilgjengelig, selv etter at alle de konfigurerte anropsdistribusjonsgruppene ikke finner en tilgjengelig samsvarende agent for håndtering av samhandlingen.

Agent Desktop Operasjoner

Når en agent logger på Webex CC Agent Desktop, angir agenten et telefonnummer som innkommende anrop til agenten kan kobles til. Dette kan være en PSTN-telefon, mobiltelefon eller et internnummer hvis agenten er en Cisco Webex Calling bruker.

Vær oppmerksom på at dette nummeret må være et gyldig telefonnummer som anrop kan rutes til. Hvis ikke, kan ikke agenten motta innkommende anrop.

Basert på typen samhandling som agenten håndterer, gir widgetene i agentskrivebordet muligheten til å utføre bestemte mediekontrolloperasjoner.

Når et anrop er besvart, kan agenten for eksempel utføre følgende operasjoner knyttet til anropet.

• Sett samtalen på vent

• Start konsultasjonssamtale og

  • Overfør samtalen til et annet telefonnummer (si agenttelefonnummer) / inngangspunkt

  • Sende en annen agent til samtalen i konferanse

• Overføre samtalen til en annen kø

• Avslutte samtalen

Med Agent Desktop kan administratorer legge til egendefinerte widgeter der ved å utvide skrivebordsfunksjonene og gjøre det til en enhetlig samling av widgeter som agenter trenger for å få arbeidet gjort på en effektiv måte.

Skrivebordsarkitektur

Agent desktop er en mikro frontend basert enkeltside program som er vert for widgets bygget basert på webkomponenter arkitektur. Alle standard-/lagerwidgetene drives av data som hentes av API-er eller push-mekanismer på serversiden.

Dette er vanligvis asynkrone API-er, der svaret på en påkallelse kommer til skrivebordet via en WebSocket-tilkobling.

Webex CC-Agent Desktop godkjenner brukere med Cisco Common Identity (CI), og tokenet sendes videre til alle API aktiveringer. Også for egendefinerte widgeter, basert på godkjenningsmodellen, gir den en enkel påloggingsopplevelse til agenter hvis godkjenningsmodellen til den egendefinerte widgeten er integrert med CI.

Når en agent er en del av en samhandling, sendes alle oppdateringer til samhandlingstilstanden eller tilknyttede data også til skrivebordet via WebSocket-tilkoblingen.

Robusthet fra skrivebordet til tilkobling og ventetid

Den asynkrone API og push-en på serversiden muliggjør skalering, og eventuelle tilkoblingstap til WebSocket-grensesnittet oppdages, og skrivebordet forsøker å koble til på nytt og logge på på nytt.

Figuren nedenfor illustrerer agentskrivebordsarkitekturen i Webex CC.

Onboarding av kunder

Webex Control Hub er det primære grensesnittet som brukes av partnere og kunder for å introdusere kunder og aktivere eller konfigurere funksjoner.

Når organisasjons- og kontaktsenterfunksjonene er klargjort i Control Hub, vil det utløse en arbeidsflyt i Webex CC som utfører resten av trinnene i klargjøringen av alle kontaktsenterfunksjoner i henhold til tilbudene valgt av kunden.

All klargjøring av kontaktsenteret gjøres ved hjelp av en BPM-arbeidsflytmotor som muliggjør en deklarativ måte å definere de involverte trinnene på, og gjør hele klargjøringstrinnene motstandsdyktige mot feil og sikrer dataintegritet.

Figuren nedenfor illustrerer klargjøringsarbeidsflyten i Webex CC.

Konfigurasjonsenheter

De viktigste konfigurasjonsenhetene i Webex CC, omfang i en organisasjon, er:

Nettstedet

Sted betyr et sted hvor ett eller flere team, brukere (agenter/veiledere) er lokalisert.

Hver bruker og gruppe må tilhøre et område.

Gruppe

En gruppe brukere. Team brukes til å distribuere samhandlinger til agenter via køer.

Hvert lag må tilhøre et nettsted.

Agenter

Brukere som kan logge på Agent Desktop og håndtere samhandlinger på tvers av medietypene som er konfigurert i Webex CC.

Tilsynspersoner

Veiledere er tildelt team og kan overvåke/coache agenten og ha tilgang til status på teamnivå og agentstatistikk for de som tilhører teamene som veilederen er tildelt.

Kø

En kø er en logisk enhet der samhandlinger kan holdes mens du venter på at agenter skal være tilgjengelige, som deretter rutes til agenten.

Køer tilordnes til team, som søkeområdet for agenter, med mulighet til å utvide søkeområdet basert på medgått tidsterskel, ved å legge til andre team i søkeområdet.

Entrypoint

Entrypoint er en logisk enhet som representerer inngangspunktet for samhandlinger for å komme inn i Webex CC. For telefoni kartlegges dette primært telefonnummeret som anropene kommer til, og for e-post-/meldingskanaler peker Entrypoint til ressurskonfigurasjonen i Webex Connect.

Flyt

Flyten knyttet til inngangspunktet (via rutingsstrategi), som bestemmer trinnene som er involvert i håndtering av samhandlinger.

For ikke-telefonikanaler (e-post, meldinger/sosiale medier) velges Flow som en del av ressurskonfigurasjonen i Webex Connect.

Tilgangskontroll for kontaktsentre på flere steder

Webex CC-administratorer kan konfigurere brukerprofiler med tilgangsrettigheter til bestemte områder, grupper, køer og inngangspunkter. Videre, på grunn av den hierarkiske naturen til steder og team, når tilgang til bestemte nettsteder er gitt, kan bare lagene eller datoen som gjelder teamene, som tilhører disse nettstedene eller et eksplisitt spesifisert delsett av slike team, nås av brukeren.

For køer og inngangspunkter er de globale på organisasjonsnivå, så for forskjellige geografiske steder (steder der bestemte agenter og team er plassert) kan separate inngangspunkter og køer konfigureres, og veiledere / brukere kan ha tilgang til de enhetene som gjelder for bestemte nettsteder.

Figuren nedenfor illustrerer de viktigste konfigurasjonsenhetene og brukerprofilen som refererer til disse enhetene.

I tillegg til å begrense tilgangen til disse enhetene, kan Webex CC-administratorer kontrollere de spesifikke egenskapene/modulene som en bruker kan få tilgang til i administrasjonsgrensesnittet, og dermed ha brukere med administrasjons-/konfigurasjonsrettigheter til bestemte enheter samt deler/muligheter i administrasjonsgrensesnittet for Webex CC.

Innebygde skrivebordskoblinger: CRM-program som primært grensesnitt

I denne driftsmodusen logger agenten på CRM-konsollen som det primære programmet.

Webex CC er et innebygd program (også kalt et innebygd skrivebordsprogram eller innebygd softphone) som primært brukes til å logge på kontaktsenteret og motta Webex CC-rutede kontaktsentersamhandlinger.

Når CRM-integreringen mottar et anrop eller en samtaleforespørsel, utfører den følgende handlinger på CRM-konsollen

• Skjermbilde viser kundeoppføringen som er knyttet til ANI eller andre anropstilknyttede data.

• Postere samtalemetadata som aktivitetsnotater i kundeoppføringen

• La agenten "klikke for å ringe" ved å klikke på kontakten i CRM og starte et utgående anrop til kunden

• Postering av anropsoppføringer i CRM-rapporteringstabellene for primærrapportering om CRM.

• Gir full funksjonalitet for Agent Desktop- og samtalekontroller (innebygd og minifisert versjon av skrivebordsappen)

Den primære integreringsmodusen med CRM-ene er å bygge inn CC Desktop Webex programmet i en separat iFrame.

Videre kjører Webex CC Desktop-programmet en egendefinert hodeløs widget (ingen brukergrensesnitt) i bakgrunnen, og samhandler med det underliggende CRM-systemet for å utføre automatiserte handlinger på vegne av agenten.

Samhandlingene drives av to SDK-er som den hodeløse widgeten bruker.

• Webex CC Desktop JS SDK: Dette er JavaScript SDK levert av Webex CC for å registrere hendelseslyttere for agent- og kontakthandlinger.

• CRM JS SDK: Dette er CRM-klient-SDK-en som gjelder per CRM som abstraherer REST API-anrop med CRM. For salesforce brukes for eksempel det CTI JS-biblioteket fra Salesforce til å utføre handlinger og lytte etter hendelser i CRM.

Figuren nedenfor illustrerer CRM-arkitekturen for innebygd Webex CC-skrivebord og koblinger

Webex CC støtter følgende CRM-løsninger for ovennevnte integrasjon:

• Salesforce

• ServiceNow

• Microsoft Dynamics 365

• Zendesk

• Freshdesk

For mer informasjon, besøk https://help.webex.com/en-us/result/integrate%20with%20webex%20contact%20center?offset=10.

Hvis du vil ha mer informasjon om hvordan du konfigurerer Webex CC-skrivebordsoppsett for aktivering av CRM-kobling, funksjonssett og endringslogger, kan du gå til https://github.com/Ciscodevnet/webex-contact-center-crm-integrations.

Global tilgjengelighet av CRM-koblinger

CRM-koblingene er tilgjengelige i alle geografiske områder og områder der Webex CC er i drift.

Elastisk skalering og ytelse

Webex CC er vert for den tilpassede widgeten som muliggjør toveiskommunikasjon mellom CRM-applikasjonen og Webex CC-skrivebordet i AWS CloudFront CDN, noe som sikrer høy tilgjengelighet av widgeten AWS på tvers av tilgjengelighetssoner og regioner.

All CRM-integreringsspesifikk databehandling skjer i nettleseren der agenter bruker CRM-programmet med Webex CC-skrivebord innebygd i CRM-programmet.

Sikkerhet

CRM-koblingene startes via skrivebordsoppsettet for Webex CC-agent, og valgfrie parametere sendes via skrivebordsoppsettet til widgeten for å slå funksjoner på og av.

Hvis du for eksempel vil aktivere widgeten Salesforce-handlinger, kan administratoren slå på parameterinnstillingen sfdcWidgetEnabled til sann.

Installasjon av pakke

For at integreringen skal fungere toveis, må CRM-konsollen ha det innebygde programmet installert. Dette er for å støtte lasting av skrivebordsprogrammet inne i en iFrame.

Alle Desktop Embedded-koblingene er tilgjengelige på CRM-markedsplassen.

For eksempel,

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/

Installasjonen av markedsplassprogrammet aktiverer de nødvendige plugin-modulene og importerer de nødvendige XML-filene til CRM-konsollen for å støtte rapportering av anropsoppføringer i CRM.

Flytintegreringer via HTTP-koblinger i IVR

Webex CC Flow-byggherren støtter toveis dataflyter mellom Webex CC og CRM-systemet ved hjelp av HTTPs-koblinger konfigurert i Webex Control Hub og brukt på Webex CC Flow.

Disse brukes primært til tilpassing i talesamhandlinger og tilpasset ruting i IVR.

Som standard støtter Webex CC HTTP-koblingen Salesforce på Control Hub. De andre CRM-koblingene kan legges til som egendefinerte koblinger i Webex Control Hub.

Hvis du vil ha mer informasjon om HTTP-koblinger, kan du gå til https://github.com/CiscoDevNet/webex-contact-center-crm-integrations.

IVR HTTP-kontakter:

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

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

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

Taleinfrastruktur på Edge

Voice Edge-komponentene tillater SIP-trunker fra kundenettverk / PSTN-bærere å avslutte, og dette aktiveres basert på hvitelistede IP-er som har lov til å koble til kantkomponentene.

Beregn infrastruktursikkerhet

Webex CC-databehandlingsforekomster klargjøres i AWS, og tjenester kjører som pods i Kubernetes-klynge, som har flere navneområder og tilgang til hvert navneområde er begrenset med separat legitimasjon.

All klargjøring av infrastrukturen gjøres ved hjelp av kode – ingen manuelle trinn – og ingen av legitimasjonene kan nås manuelt.

Det er et sentralt legitimasjonslager med spesifikke baner konfigurert for spesifikt sett med tjenester / team, og tilgangen til selve legitimasjonslageret er begrenset og konfigurert som hemmeligheter i bygge- og distribusjonssystemene.

Ingen av infrastrukturkomponentene/tjenestene er direkte eksponert utenfor AWS VPC, og kun offentlig eksponerte grensesnitt er API-er og WebSocket-servere som styres og administreres ved hjelp av API-gateway,

Bortsett fra dette er det visse interne systemer og grensesnitt som brukes av utviklere som brukes til å vise logger, målestokker, distribusjonsdetaljer, byggestatus og testresultater, som er sikret ved hjelp av roller og grupper og integrert med Ciscos interne autentiseringssystemer.

Autentisering og autorisasjon for brukergrensesnitt

Alle brukergrensesnittene som brukes av ulike kontaktsenterbrukere (agenter, ledere, administratorer, analytikere), er beskyttet av Ciscos OAuth-flyter (Common Identity Based Bearer Token).

Autorisasjonen gjøres ved hjelp av roller for brukeren som fikk tokenet og omfangene som er tilordnet tokenet.

Data under overføring

Ingen av grensesnittene til tjenestene / infrastrukturkomponenten som er distribuert, er direkte eksponert for ekstern innkommende trafikk.

Utvalgte tjenester, med http APIer, eksponerer disse grensesnittene via en gateway, og all innkommende https (inkludert WebSocket) avsluttes i ALB og intern trafikk over http rutes til tjenestene.

Alle utgående interaksjoner er over https / TLS (for ikke http-protokoller).

Inne i VPC er den interne kommunikasjonen mellom tjenester - over http / custom TCP protocol - over vanlig TCP socket.

Data i hvile

Alle data som blir lagret, krypteres på lagringslaget. Videre er de datalagrene som er utenfor VPC, beskyttet og tilgangskontroll og autorisasjoner med legitimasjon sikkert lagret og administrert i et hemmelig lager.

Figuren nedenfor illustrerer dataflyten og sikkerhetsmodellen for både transitt og hvile.

PII-data for sluttbruker

Webex CC Flow, som er den programmatiske kontrolleren for håndtering av samhandlinger, kan brukes til å samle inn brukerdata, som kan tilordnes flytvariabler som er spesielt merket som "Inneholder sensitive data". Verdiene for slike data er kryptert, og ingen tjenester i transittbanen til dataene vil ha tilgang til disse dataene.

Videre blir slike data aldri lagret i CC Webex rapporteringsdatalageret, og loggene/meldingsinfrastrukturen vil ha krypterte data og klartekstdata lagres ikke noe sted i Webex CC.

PII-data for kontaktsenteragent/-leder

Kontaktsenterets brukerrelaterte data redigeres i logger, men er tilgjengelige for dataanalyse og visualisering i Webex CC-datalageret.

Faktorer for skala

For Webex CC er faktorene som påvirker skalaen:

• Samtidig antall agenter logget på

• Samtidig antall interaksjoner pågår

  • Handlinger utført på disse samhandlingene

• Samtidig antall handlinger som veiledere / agenter utfører, utenfor håndtering av interaksjonene

• Volumet av dataene som genereres og vedvarer

Arkitektoniske aspekter som muliggjør skala

Prinsippene som Webex CC er bygget og designet etter, gjør at løsningen kan skaleres dynamisk etter behov innenfor rammene som håndheves av infrastrukturen som tilbys for de ulike tjenestene og plattformkomponentene.

Hendelsesdrevet arkitektur

Tjenestene i Webex CC kommuniserer ved hjelp av meldinger, og de kritiske meldingsbehandlingsflytene innebærer ingen blokkering av IO-operasjoner, og tilstanden som kreves for å behandle meldinger, er lokalisert til forekomsten av tjenesten som behandler meldingen.

Statsløse tjenester (eller eksternalisert tilstand)

Tilstandsløse tjenester muliggjør elastisitet ved enkelt å legge til/fjerne flere forekomster av tjenestene. Det er visse tjenester som er iboende stateful i naturen, og de har eksternalisert statlig butikk og infrastrukturen støtter dynamiske endringer i antall forekomster av slike tjenester også med automatisk rebalansering / statlig overføring / lokalisering av staten til forekomsten som trenger staten.

Elastisk infrastruktur

Alle tjenestene kjører i Kubernetes, og infrastrukturen, også kjent som Kubernetes-noder, skaleres automatisk basert på bruken, og dette gjør det mulig å legge til flere databehandlingsnoder dynamisk opp til en maksimal høy terskel som er forhåndskonfigurert.

Lastprojeksjon og regelmessig validering

Alle tjenestene er benchmarked for ytelsesegenskaper og skaleringsmønster er validert på tjenestenivå.

Ytterligere kontinuerlig validering, toppbelastning og utholdenhetstester utføres med testparametere justert for forventet vekst i skalaen som påvirker attributter, noe som gjør det mulig å identifisere flaskehalser, planlegge å oppdatere den høye terskelen for ressursbruk i infrastrukturen og være klar for spilldagen.

Telefoni

For telefoni avgjøres håndteringen av innkommende taleanrop av hvordan anropet kom inn i kontaktsenteret (se Inngående mekanismer nedenfor) og Webex CC-flyten som er knyttet til inngangspunktet.

Anropet blir besvart, og ytterligere handlinger utføres i henhold til CC Flow Webex definisjonen – som er en programmatisk representasjon av handlingene som skal utføres under håndtering av anropet, enten før kø og ruting til en agent, eller selve flyten kan håndtere samtalen uten overføring til en agent.

Flow Builder i Webex CC lar utviklere definere flyten og tilordne den til inngangspunktet som anropet ankommer via i Webex CC.

Disse konfigurasjonsenhetene og bruken av dem dekkes i konfigurasjonsenheter.

Mer informasjon om Flow Builder er dekket i den kommende delen om IVR System.

E-post og meldinger

Fra Webex CC-perspektiv gir Webex Connect inngående og utgående funksjoner for alle digitale kanaler – e-post, meldingskanaler, som sluttbrukere kan bruke til å kontakte kontaktsenteret.

Webex Connect-flyt

• Bestemmer håndteringen av slike samhandlinger til samhandlingene er satt i kø og rutet til agenter. Dette inkluderer automatisk håndtering og BOT-behandlinger for alle former for meldings- og e-postinteraksjoner.

• Bruker forretningslogikk på innkommende samhandling.

• Håndterer kontakt før du setter deg i kø.

• Flow selv kan håndtere samhandlingen uten overføring til live agent.

Meldingskanalene som støttes av Webex CC er:

• Web App / Mobil App Chat

• Whatsapp

• Facebook Messenger

• SMS

E-postkanalene som støttes av Webex CC er:

• Gmail

• Office365

Inntrengningsmekanismer

Denne delen dekker mekanismene som en interaksjon kan komme inn i Webex CC. Basert på medietypen er mekanismene som en interaksjon når Webex CC forskjellige.

I telefoni er det for eksempel nødvendig med klargjøring av fysisk infrastruktur for å aktivere PSTN-tilkobling, konfigurasjon av telefonnumre og ruting av anropene til Webex CC.

For e-post-/meldingskanaler må inngangskonfigurasjonen gjøres i Webex Koble til, og den involverer klargjøring av e-post-/meldingskonto og Webex Connect-flytkonfigurasjon.

Innkommende tale

For taleanrop er et typisk scenario der brukere ringer et PSTN-telefonnummer som deretter kobles til kontaktsenteret. Fra et inngangsperspektiv trenger dette en mekanisme for å rute anrop fra PSTN til Webex CC.

Figuren nedenfor illustrerer inntaket av taleanrop til Webex CC.

Voice Ingress Services i Webex CC utfører tredjeparts samtalekontroll ved hjelp av SIP og svarer på det innkommende anropet, samt utfører overførings-, konferanse- og andre samtalekontrolloperasjoner.

Det logiske inngangspunktet for anrop i Webex CC er konfigurasjonsenheten kalt Entrypoint. For taleinngang er nøkkelkonfigurasjonen for Entrypoint telefonnummeret som er knyttet til det, som vanligvis er et gyldig PSTN-telefonnummer hentet fra valgt PSTN-leverandør.

Dette gjør det mulig å oppdage innkommende anrop på telefonnummeret, knytte anropet til Entrypoint og bruke andre konfigurasjonsparametere for inngangspunktet til å håndtere anropet i henhold til definisjonen for Webex CC-flyt som skal utløses for samhandlingen.

Merk:

Hvis du vil ha mer informasjon om alternativene for PSTN-tilkobling, kan du gå til 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.

Skalerbarhet og tilgjengelighet for infrastruktur for talekant

Webex CC VPOP-infrastrukturen inkluderer redundante SIP SBC-par, noe som sikrer høy tilgjengelighet og flere SBC-er kan legges til for å skalere de samtidige anropsvolumene som skal støttes.

Maks samtidige anrop som VPOP kan håndtere, avhenger av antall SBC-er som kjører, og som anrop sendes til.

For geografisk redundans – et nett av VPOP SBC med sammenkoblinger på tvers av flere par på tvers av regioner støttes.

For taleinngangstjenester er de horisontalt skalerbare for å håndtere et økende antall samtidige taleanrop som skal inntas til Webex CC.

Sikkerhetshensyn med talekantinfrastruktur

Tabellen nedenfor inneholder detaljer om tilkoblingsalternativene til Voice Edge-infrastrukturen.

For mer informasjon, 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

Hvert taleanrop som kommer inn i et telefonnummer som er tilknyttet et inngangspunkt, blir besvart av Webex CC, og kjøring av en Webex CC-flyt tilknyttet inngangspunktet, starter.

Webex CC Flow Builder leverer programmeringskonstruksjoner/operatorer og funksjonelle blokker, kalt aktiviteter, slik at administratorer eller andre som utformer og implementerer den IVR logikken, kan kombinere disse byggeklossene og opprette flytdefinisjonen.

Programmeringskonstruksjonene som Flow støtter, er:

• Deklarasjons- og innstillingsvariabler – tilstand knyttet til en flytkjøring

  • Pebble-uttrykk for å angi verdien av variabler

• Betingede kontroller

• Looping - bruk av Conditionals og Go To (evne til å kjede aktiviteter sammen)

• Aktivere REST API-er

• Analyseringsdata - JSON, TOML, XML vanligvis brukt til å analysere API svar.

• Komponere aktiviteter

Et representativt sett med aktiviteter som Flow-forsyninger er: Spill av meldinger Samle inn brukerdata Overføre samtalen til en annen destinasjon/et annet telefonnummer Send samtalen til en virtuell agent Sett anropet i kø slik at det kan besvares av en agent.

For hvert anrop som er aktivt, er en forekomst av flytkjøring også aktiv til samtalen avsluttes, noe som resulterer i samtidige kjøringer av flyter.

Hver forekomst av flytkjøring gir isolert miljø for data / tilstand knyttet til flyten og der av anropet.

I løpet av hele anropets livssyklus gjør flyt det også mulig å svare på bestemte hendelser som skjer, og håndtere dem – når et anrop for eksempel besvares av en agent, kan en hendelsesbehandling utløse et skjermvindu i grensesnittet for agentskrivebordet.

Hvis du vil ha mer informasjon om Webex CC Flow, kan du se https://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øtte for virtuell agent

Flow leverer en aktivitet for å levere samhandlingen til en virtuell agent, som er forhåndskonfigurert i Webex Control Hub.

Når samtalen er koblet til en virtuell agent, gir den en samtaleopplevelse IVR brukeren og aktiviteten avsluttes enten med avslutning av samtalen eller med eskalering av anropet til en agent.

Ved eskalering kan flyten konfigureres til å sette anropet i kø, som deretter blir besvart av en agent.

Innkommende digitale interaksjoner

For e-post og meldingskanal for innkommende samhandlinger bruker Webex CC Webex Connect til klargjøring av aktiva, flyt for å håndtere innkommende samhandlinger og deretter rute samhandlingen til Webex CC når Webex Connect-flyten eksplisitt setter samhandlingen i kø slik at den kan håndteres av en agent.

Figuren nedenfor illustrerer inntak av e-post, meldingsinteraksjoner i Webex CC.

Virtual Agent / BOT-integrasjoner

For samhandlinger med e-post og meldinger eller sosiale kanaler konfigureres de virtuelle agent-/BOT-behandlingene i Webex Connect-flyten.

På samme måte som med Virtual Agents for Voice, hvis BOT-behandlingen ender med eskalering som resultat, blir samhandlingen lagt i kø og rutet til en agent.

Valg av agent

Køer i Webex CC støtter følgende algoritmer for agentvalg:

• Lengste tilgjengelige agentruting

• Dyktig basert ruting

  • Lengste tilgjengelige agent (LAA)

  • Beste tilgjengelige agent (BAA)

Agenter er knyttet til køer gjennom Teams.

En kø kan tilordnes flere anropsdistribusjonsgrupper (der hver gruppe har ett eller flere team), på en sekvensiell måte med konfigurert venting på at anropsdistribusjonsgruppe skal legges til i køen, slik at søkeområdet for en samsvarende agent utvides til flere anropsdistribusjonsgrupper etter hvert som tiden går.

For ferdighetsbasert ruting, blant kompetansekravene som samsvarer med agenter som er knyttet til køen, velges en agent basert på LAA- eller BAA-konfigurasjon.

Spesifikke tilleggsfunksjoner for tale/telefoni

Agentbasert ruting (kun for tale-/telefonikanaler)

Webex CC Flow kan ved hjelp av aktiviteten QueueToAgent rute samhandlinger direkte til den valgte agenten basert på agent-ID-en.

Hvis agenten ikke er tilgjengelig for å håndtere samhandlinger, kan samhandlingen parkeres i en agentspesifikk kø og vente på at agenten blir tilgjengelig

Avansert køinformasjon

Webex CC Flow kan ved hjelp av aktiviteten GetQueueInfo hente sanntidsinformasjon for en kø som Posisjon i kø (PIQ), Estimert ventetid (EWT), antall agenter som er tilgjengelige i køen, og kan brukes til å avgjøre om kontakten skal settes i kø eller ikke.

Høflighet tilbakeringing

Webex CC Flow, ved hjelp av aktiviteten Tilbakeringing, lar kunden koble fra samtalen mens posisjonen i køen opprettholdes, og motta en tilbakeringing når den virtuelle samhandlingen i køen rutes til en agent.

Håndtering av overløp

Webex CC støtter overflythåndtering ved hjelp av kapasitetsbaserte team (CBT).

CBT er som et vanlig team med en kapasitet og en tilknyttet ekstern DN som tjener den kapasiteten. Den kan konfigureres sammen med andre team i distribusjonssyklusene for køanrop.

Vanligvis konfigureres dette som den siste syklusen, slik at det fungerer som en overflyt hvis ingen agent er tilgjengelig, selv etter at alle de konfigurerte anropsdistribusjonsgruppene ikke finner en tilgjengelig samsvarende agent for håndtering av samhandlingen.

Agent Desktop Operasjoner

Når en agent logger på Webex CC Agent Desktop, angir agenten et telefonnummer som innkommende anrop til agenten kan kobles til. Dette kan være en PSTN-telefon, mobiltelefon eller et internnummer hvis agenten er en Cisco Webex Calling bruker.

Vær oppmerksom på at dette nummeret må være et gyldig telefonnummer som anrop kan rutes til. Hvis ikke, kan ikke agenten motta innkommende anrop.

Basert på typen samhandling som agenten håndterer, gir widgetene i agentskrivebordet muligheten til å utføre bestemte mediekontrolloperasjoner.

Når et anrop er besvart, kan agenten for eksempel utføre følgende operasjoner knyttet til anropet.

• Sett samtalen på vent

• Start konsultasjonssamtale og

  • Overfør samtalen til et annet telefonnummer (si agenttelefonnummer) / inngangspunkt

  • Sende en annen agent til samtalen i konferanse

• Overføre samtalen til en annen kø

• Avslutte samtalen

Med Agent Desktop kan administratorer legge til egendefinerte widgeter der ved å utvide skrivebordsfunksjonene og gjøre det til en enhetlig samling av widgeter som agenter trenger for å få arbeidet gjort på en effektiv måte.

Skrivebordsarkitektur

Agent desktop er en mikro frontend basert enkeltside program som er vert for widgets bygget basert på webkomponenter arkitektur. Alle standard-/lagerwidgetene drives av data som hentes av API-er eller push-mekanismer på serversiden.

Dette er vanligvis asynkrone API-er, der svaret på en påkallelse kommer til skrivebordet via en WebSocket-tilkobling.

Webex CC-Agent Desktop godkjenner brukere med Cisco Common Identity (CI), og tokenet sendes videre til alle API aktiveringer. Også for egendefinerte widgeter, basert på godkjenningsmodellen, gir den en enkel påloggingsopplevelse til agenter hvis godkjenningsmodellen til den egendefinerte widgeten er integrert med CI.

Når en agent er en del av en samhandling, sendes alle oppdateringer til samhandlingstilstanden eller tilknyttede data også til skrivebordet via WebSocket-tilkoblingen.

Robusthet fra skrivebordet til tilkobling og ventetid

Den asynkrone API og push-en på serversiden muliggjør skalering, og eventuelle tilkoblingstap til WebSocket-grensesnittet oppdages, og skrivebordet forsøker å koble til på nytt og logge på på nytt.

Figuren nedenfor illustrerer agentskrivebordsarkitekturen i Webex CC.

Onboarding av kunder

Webex Control Hub er det primære grensesnittet som brukes av partnere og kunder for å introdusere kunder og aktivere eller konfigurere funksjoner.

Når organisasjons- og kontaktsenterfunksjonene er klargjort i Control Hub, vil det utløse en arbeidsflyt i Webex CC som utfører resten av trinnene i klargjøringen av alle kontaktsenterfunksjoner i henhold til tilbudene valgt av kunden.

All klargjøring av kontaktsenteret gjøres ved hjelp av en BPM-arbeidsflytmotor som muliggjør en deklarativ måte å definere de involverte trinnene på, og gjør hele klargjøringstrinnene motstandsdyktige mot feil og sikrer dataintegritet.

Figuren nedenfor illustrerer klargjøringsarbeidsflyten i Webex CC.

Konfigurasjonsenheter

De viktigste konfigurasjonsenhetene i Webex CC, omfang i en organisasjon, er:

Nettstedet

Sted betyr et sted hvor ett eller flere team, brukere (agenter/veiledere) er lokalisert.

Hver bruker og gruppe må tilhøre et område.

Gruppe

En gruppe brukere. Team brukes til å distribuere samhandlinger til agenter via køer.

Hvert lag må tilhøre et nettsted.

Agenter

Brukere som kan logge på Agent Desktop og håndtere samhandlinger på tvers av medietypene som er konfigurert i Webex CC.

Tilsynspersoner

Veiledere er tildelt team og kan overvåke/coache agenten og ha tilgang til status på teamnivå og agentstatistikk for de som tilhører teamene som veilederen er tildelt.

Kø

En kø er en logisk enhet der samhandlinger kan holdes mens du venter på at agenter skal være tilgjengelige, som deretter rutes til agenten.

Køer tilordnes til team, som søkeområdet for agenter, med mulighet til å utvide søkeområdet basert på medgått tidsterskel, ved å legge til andre team i søkeområdet.

Entrypoint

Entrypoint er en logisk enhet som representerer inngangspunktet for samhandlinger for å komme inn i Webex CC. For telefoni kartlegges dette primært telefonnummeret som anropene kommer til, og for e-post-/meldingskanaler peker Entrypoint til ressurskonfigurasjonen i Webex Connect.

Flyt

Flyten knyttet til inngangspunktet (via rutingsstrategi), som bestemmer trinnene som er involvert i håndtering av samhandlinger.

For ikke-telefonikanaler (e-post, meldinger/sosiale medier) velges Flow som en del av ressurskonfigurasjonen i Webex Connect.

Tilgangskontroll for kontaktsentre på flere steder

Webex CC-administratorer kan konfigurere brukerprofiler med tilgangsrettigheter til bestemte områder, grupper, køer og inngangspunkter. Videre, på grunn av den hierarkiske naturen til steder og team, når tilgang til bestemte nettsteder er gitt, kan bare lagene eller datoen som gjelder teamene, som tilhører disse nettstedene eller et eksplisitt spesifisert delsett av slike team, nås av brukeren.

For køer og inngangspunkter er de globale på organisasjonsnivå, så for forskjellige geografiske steder (steder der bestemte agenter og team er plassert) kan separate inngangspunkter og køer konfigureres, og veiledere / brukere kan ha tilgang til de enhetene som gjelder for bestemte nettsteder.

Figuren nedenfor illustrerer de viktigste konfigurasjonsenhetene og brukerprofilen som refererer til disse enhetene.

I tillegg til å begrense tilgangen til disse enhetene, kan Webex CC-administratorer kontrollere de spesifikke egenskapene/modulene som en bruker kan få tilgang til i administrasjonsgrensesnittet, og dermed ha brukere med administrasjons-/konfigurasjonsrettigheter til bestemte enheter samt deler/muligheter i administrasjonsgrensesnittet for Webex CC.

Innebygde skrivebordskoblinger: CRM-program som primært grensesnitt

I denne driftsmodusen logger agenten på CRM-konsollen som det primære programmet.

Webex CC er et innebygd program (også kalt et innebygd skrivebordsprogram eller innebygd softphone) som primært brukes til å logge på kontaktsenteret og motta Webex CC-rutede kontaktsentersamhandlinger.

Når CRM-integreringen mottar et anrop eller en samtaleforespørsel, utfører den følgende handlinger på CRM-konsollen

• Skjermbilde viser kundeoppføringen som er knyttet til ANI eller andre anropstilknyttede data.

• Postere samtalemetadata som aktivitetsnotater i kundeoppføringen

• La agenten "klikke for å ringe" ved å klikke på kontakten i CRM og starte et utgående anrop til kunden

• Postering av anropsoppføringer i CRM-rapporteringstabellene for primærrapportering om CRM.

• Gir full funksjonalitet for Agent Desktop- og samtalekontroller (innebygd og minifisert versjon av skrivebordsappen)

Den primære integreringsmodusen med CRM-ene er å bygge inn CC Desktop Webex programmet i en separat iFrame.

Videre kjører Webex CC Desktop-programmet en egendefinert hodeløs widget (ingen brukergrensesnitt) i bakgrunnen, og samhandler med det underliggende CRM-systemet for å utføre automatiserte handlinger på vegne av agenten.

Samhandlingene drives av to SDK-er som den hodeløse widgeten bruker.

• Webex CC Desktop JS SDK: Dette er JavaScript SDK levert av Webex CC for å registrere hendelseslyttere for agent- og kontakthandlinger.

• CRM JS SDK: Dette er CRM-klient-SDK-en som gjelder per CRM som abstraherer REST API-anrop med CRM. For salesforce brukes for eksempel CTI JS-biblioteket fra Salesforce til å utføre handlinger og lytte etter hendelser i CRM.

Figuren nedenfor illustrerer den innebygde skrivebords- og koblingsarkitekturen for CRM Webex CC

Webex CC støtter følgende CRM-løsninger for ovennevnte integrasjon:

• Salesforce

• ServiceNow

• Microsoft Dynamics 365

• Zendesk

• Freshdesk

For mer informasjon, besøk https://help.webex.com/en-us/result/integrate%20with%20webex%20contact%20center?offset=10.

Hvis du vil ha mer informasjon om hvordan du konfigurerer Webex CC-skrivebordsoppsettene for aktivering av CRM-kobling, funksjonssett og endringslogger, kan du gå til https://github.com/Ciscodevnet/webex-contact-center-crm-integrations.

Global tilgjengelighet av CRM-koblinger

CRM-koblingene er tilgjengelige i alle geografiske områder og områder der Webex CC er i drift.

Elastisk skalering og ytelse

Webex CC er vert for den tilpassede widgeten som muliggjør toveiskommunikasjon mellom CRM-applikasjonen og Webex CC-skrivebordet i AWS CloudFront CDN, noe som sikrer høy tilgjengelighet av widgeten AWS på tvers av tilgjengelighetssoner og regioner.

All CRM-integrasjonsspesifikk databehandling skjer i nettleseren der agenter bruker CRM-applikasjonen med Webex CC-skrivebord innebygd i CRM-applikasjonen.

Sikkerhet

CRM-koblingene startes via skrivebordsoppsettet for Webex CC-agenten, og valgfrie parametere sendes via skrivebordsoppsettet til widgeten for å slå funksjoner på og av.

Hvis du for eksempel vil aktivere widgeten Salesforce-handlinger, kan administratoren slå på parameterinnstillingen sfdcWidgetEnabled til sann.

Installasjon av pakke

For at integreringen skal fungere toveis, må CRM-konsollen ha det innebygde programmet installert. Dette er for å støtte lasting av skrivebordsprogrammet inne i en iFrame.

Alle Desktop Embedded-koblingene er tilgjengelige på CRM-markedsplassen.

For eksempel,

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/

Installasjonen av markedsplassprogrammet aktiverer de nødvendige plugin-modulene og importerer de nødvendige XML-filene til CRM-konsollen for å støtte rapportering av anropsoppføringer i CRM.

Flytintegreringer via HTTP(S)-koblinger i IVR

Webex CC Flow-byggherren støtter toveis datastrømmer mellom Webex CC og CRM-systemet ved hjelp av HTTP(S)-koblinger konfigurert i Webex Control Hub og brukt på Webex CC Flow.

Disse brukes primært til personalisering i taleinteraksjonene og tilpasset ruting i IVR.

Som standard støtter Webex CC Salesforce HTTP Connector på Control Hub. De andre CRM-koblingene kan legges til som egendefinerte koblinger på Webex Control Hub.

Hvis du vil ha mer informasjon om HTTP-koblinger, kan du gå til https://github.com/CiscoDevNet/webex-contact-center-crm-integrations.

IVR HTTP-kontakter:

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

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

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

Taleinfrastruktur på Edge

Voice Edge-komponentene tillater SIP-trunker fra kundenettverk / PSTN-bærere å avslutte, og dette aktiveres basert på hvitelistede IP-er som har lov til å koble til kantkomponentene.

Beregn infrastruktursikkerhet

Webex CC-databehandlingsforekomster klargjøres i AWS, og tjenester kjører som pods i Kubernetes-klynge som har flere navneområder og tilgang til hvert navneområde er begrenset med separat legitimasjon.

All klargjøring av infrastrukturen gjøres ved hjelp av kode – ingen manuelle trinn – og ingen av legitimasjonene kan nås manuelt.

Det er et sentralt legitimasjonslager med spesifikke baner konfigurert for spesifikt sett med tjenester / team, og tilgangen til selve legitimasjonslageret er begrenset og konfigurert som hemmeligheter i bygge- og distribusjonssystemene.

Ingen av infrastrukturkomponentene/tjenestene er direkte eksponert utenfor AWS VPC, og kun offentlig eksponerte grensesnitt er API-er og WebSocket-servere som styres og administreres ved hjelp av API-gateway,

Bortsett fra dette er det visse interne systemer og grensesnitt som brukes av utviklere som brukes til å vise logger, målestokker, distribusjonsdetaljer, byggestatus og testresultater, som er sikret ved hjelp av roller og grupper og integrert med Ciscos interne autentiseringssystemer.

Autentisering og autorisasjon for brukergrensesnitt

Alle brukergrensesnittene som brukes av ulike kontaktsenterbrukere (agenter, ledere, administratorer, analytikere), er beskyttet av Ciscos OAuth-flyter (Common Identity Based Bearer Token).

Autorisasjonen gjøres ved hjelp av roller for brukeren som fikk tokenet og omfangene som er tilordnet tokenet.

Data under overføring

Ingen av grensesnittene til tjenestene / infrastrukturkomponenten som er distribuert, er direkte eksponert for ekstern innkommende trafikk.

Utvalgte tjenester, med http APIer, eksponerer disse grensesnittene via en gateway, og all innkommende https (inkludert WebSocket) avsluttes i ALB og intern trafikk over http rutes til tjenestene.

Alle utgående interaksjoner er over https / TLS (for ikke http-protokoller).

Inne i VPC er den interne kommunikasjonen mellom tjenester - over http / tilpasset TCP-protokoll - over vanlig TCP-kontakt.

Data i hvile

Alle data som blir lagret, krypteres på lagringslaget. Videre er de datalagrene som er utenfor VPC, beskyttet og tilgangskontroll og autorisasjoner med legitimasjon sikkert lagret og administrert i et hemmelig lager.

Figuren nedenfor illustrerer dataflyten og sikkerhetsmodellen for både transitt og hvile.

PII-data for sluttbruker

Webex CC Flow, som er den programmatiske kontrolleren for håndtering av samhandlinger, kan brukes til å samle inn brukerdata, som kan tilordnes flytvariabler som er spesielt merket som "Inneholder sensitive data". Verdiene for slike data er kryptert, og ingen tjenester i transittbanen til dataene vil ha tilgang til disse dataene.

Videre blir slike data aldri lagret i CC Webex rapporteringsdatalageret, og loggene/meldingsinfrastrukturen vil ha krypterte data og klartekstdata lagres ikke noe sted i Webex CC.

PII-data for kontaktsenteragent/-leder

Kontaktsenterets brukerrelaterte data redigeres i logger, men er tilgjengelige for dataanalyse og visualisering i Webex CC-datalageret.

Faktorer for skala

For Webex CC er faktorene som påvirker skalaen:

• Samtidig antall agenter logget på

• Samtidig antall interaksjoner pågår

  • Handlinger utført på disse samhandlingene

• Samtidig antall handlinger som veiledere / agenter utfører, utenfor håndtering av interaksjonene

• Volumet av dataene som genereres og vedvarer

Arkitektoniske aspekter som muliggjør skala

Prinsippene som Webex CC er bygget og designet etter, gjør at løsningen kan skaleres dynamisk etter behov innenfor rammene som håndheves av infrastrukturen som tilbys for de ulike tjenestene og plattformkomponentene.

Hendelsesdrevet arkitektur

Tjenestene i Webex CC kommuniserer ved hjelp av meldinger, og de kritiske meldingsbehandlingsflytene innebærer ingen blokkering av IO-operasjoner, og tilstanden som kreves for å behandle meldinger, er lokalisert til forekomsten av tjenesten som behandler meldingen.

Statsløse tjenester (eller eksternalisert tilstand)

Tilstandsløse tjenester muliggjør elastisitet ved enkelt å legge til/fjerne flere forekomster av tjenestene. Det er visse tjenester som er iboende stateful i naturen, og de har eksternalisert statlig butikk og infrastrukturen støtter dynamiske endringer i antall forekomster av slike tjenester også med automatisk rebalansering / statlig overføring / lokalisering av staten til forekomsten som trenger staten.

Elastisk infrastruktur

Alle tjenestene kjører i Kubernetes, og infrastrukturen, også kjent som Kubernetes-noder, skaleres automatisk basert på bruken, og dette gjør det mulig å legge til flere databehandlingsnoder dynamisk opp til en maksimal høy terskel som er forhåndskonfigurert.

Lastprojeksjon og regelmessig validering

Alle tjenestene er benchmarked for ytelsesegenskaper og skaleringsmønster er validert på tjenestenivå.

Ytterligere kontinuerlig validering, toppbelastning og utholdenhetstester utføres med testparametere justert for forventet vekst i skalaen som påvirker attributter, noe som gjør det mulig å identifisere flaskehalser, planlegge å oppdatere den høye terskelen for ressursbruk i infrastrukturen og være klar for spilldagen.

Telefoni

For telefoni avgjøres håndteringen av innkommende taleanrop av hvordan anropet kom inn i kontaktsenteret (se Inngående mekanismer nedenfor) og Webex CC-flyten som er knyttet til inngangspunktet.

Anropet blir besvart, og ytterligere handlinger utføres i henhold til CC Flow Webex definisjonen – som er en programmatisk representasjon av handlingene som skal utføres under håndtering av anropet, enten før kø og ruting til en agent, eller selve flyten kan håndtere samtalen uten overføring til en agent.

Flow Builder i Webex CC lar utviklere definere flyten og tilordne den til inngangspunktet som anropet ankommer via i Webex CC.

Disse konfigurasjonsenhetene og bruken av dem dekkes i konfigurasjonsenheter.

Mer informasjon om Flow Builder er dekket i den kommende delen om IVR System.

E-post og meldinger

Fra Webex CC-perspektiv gir Webex Connect inngående og utgående funksjoner for alle digitale kanaler – e-post, meldingskanaler, som sluttbrukere kan bruke til å kontakte kontaktsenteret.

Webex Connect-flyt

• Bestemmer håndteringen av slike samhandlinger til samhandlingene er satt i kø og rutet til agenter. Dette inkluderer automatisk håndtering og BOT-behandlinger for alle former for meldings- og e-postinteraksjoner.

• Bruker forretningslogikk på innkommende samhandling.

• Håndterer kontakt før du setter deg i kø.

• Flow selv kan håndtere samhandlingen uten overføring til live agent.

Meldingskanalene som støttes av Webex CC er:

• Web App / Mobil App Chat

• Whatsapp

• Facebook Messenger

• SMS

E-postkanalene som støttes av Webex CC er:

• Gmail

• Office365

Inntrengningsmekanismer

Denne delen dekker mekanismene som en interaksjon kan komme inn i Webex CC. Basert på medietypen er mekanismene som en interaksjon når Webex CC forskjellige.

I telefoni er det for eksempel nødvendig med klargjøring av fysisk infrastruktur for å aktivere PSTN-tilkobling, konfigurasjon av telefonnumre og ruting av anropene til Webex CC.

For e-post-/meldingskanaler må inngangskonfigurasjonen gjøres i Webex Koble til, og den involverer klargjøring av e-post-/meldingskonto og Webex Connect-flytkonfigurasjon.

Innkommende tale

For taleanrop er et typisk scenario der brukere ringer et PSTN-telefonnummer som deretter kobles til kontaktsenteret. Fra et inngangsperspektiv trenger dette en mekanisme for å rute anrop fra PSTN til Webex CC.

Figuren nedenfor illustrerer inntaket av taleanrop til Webex CC.

Voice Ingress Services i Webex CC utfører tredjeparts samtalekontroll ved hjelp av SIP og svarer på det innkommende anropet, samt utfører overførings-, konferanse- og andre samtalekontrolloperasjoner.

Det logiske inngangspunktet for anrop i Webex CC er konfigurasjonsenheten kalt Entrypoint. For taleinngang er nøkkelkonfigurasjonen for Entrypoint telefonnummeret som er knyttet til det, som vanligvis er et gyldig PSTN-telefonnummer hentet fra valgt PSTN-leverandør.

Dette gjør det mulig å oppdage innkommende anrop på telefonnummeret, knytte anropet til Entrypoint og bruke andre konfigurasjonsparametere for inngangspunktet til å håndtere anropet i henhold til definisjonen for Webex CC-flyt som skal utløses for samhandlingen.

Merk:

Hvis du vil ha mer informasjon om alternativene for PSTN-tilkobling, kan du gå til 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.

Skalerbarhet og tilgjengelighet for infrastruktur for talekant

Webex CC VPOP-infrastrukturen inkluderer redundante SIP SBC-par, noe som sikrer høy tilgjengelighet og flere SBC-er kan legges til for å skalere de samtidige anropsvolumene som skal støttes.

Maks samtidige anrop som VPOP kan håndtere, avhenger av antall SBC-er som kjører, og som anrop sendes til.

For geografisk redundans – et nett av VPOP SBC med sammenkoblinger på tvers av flere par på tvers av regioner støttes.

For taleinngangstjenester er de horisontalt skalerbare for å håndtere et økende antall samtidige taleanrop som skal inntas til Webex CC.

Sikkerhetshensyn med talekantinfrastruktur

Tabellen nedenfor inneholder detaljer om tilkoblingsalternativene til Voice Edge-infrastrukturen.

For mer informasjon, 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

Hvert taleanrop som kommer inn i et telefonnummer som er tilknyttet et inngangspunkt, blir besvart av Webex CC, og kjøring av en Webex CC-flyt tilknyttet inngangspunktet, starter.

Webex CC Flow Builder leverer programmeringskonstruksjoner/operatorer og funksjonelle blokker, kalt aktiviteter, slik at administratorer eller andre som utformer og implementerer den IVR logikken, kan kombinere disse byggeklossene og opprette flytdefinisjonen.

Programmeringskonstruksjonene som Flow støtter, er:

• Deklarasjons- og innstillingsvariabler – tilstand knyttet til en flytkjøring

  • Pebble-uttrykk for å angi verdien av variabler

• Betingede kontroller

• Looping - bruk av Conditionals og Go To (evne til å kjede aktiviteter sammen)

• Aktivere REST API-er

• Analyseringsdata - JSON, TOML, XML vanligvis brukt til å analysere API svar.

• Komponere aktiviteter

Et representativt sett med aktiviteter som Flow-forsyninger er: Spill av meldinger Samle inn brukerdata Overføre samtalen til en annen destinasjon/et annet telefonnummer Send samtalen til en virtuell agent Sett anropet i kø slik at det kan besvares av en agent.

For hvert anrop som er aktivt, er en forekomst av flytkjøring også aktiv til samtalen avsluttes, noe som resulterer i samtidige kjøringer av flyter.

Hver forekomst av flytkjøring gir isolert miljø for data / tilstand knyttet til flyten og der av anropet.

I løpet av hele anropets livssyklus gjør flyt det også mulig å svare på bestemte hendelser som skjer, og håndtere dem – når et anrop for eksempel besvares av en agent, kan en hendelsesbehandling utløse et skjermvindu i grensesnittet for agentskrivebordet.

Hvis du vil ha mer informasjon om Webex CC Flow, kan du se https://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øtte for virtuell agent

Flow leverer en aktivitet for å levere samhandlingen til en virtuell agent, som er forhåndskonfigurert i Webex Control Hub.

Når samtalen er koblet til en virtuell agent, gir den en samtaleopplevelse IVR brukeren og aktiviteten avsluttes enten med avslutning av samtalen eller med eskalering av anropet til en agent.

Ved eskalering kan flyten konfigureres til å sette anropet i kø, som deretter blir besvart av en agent.

Innkommende digitale interaksjoner

For e-post og meldingskanal for innkommende samhandlinger bruker Webex CC Webex Connect til klargjøring av aktiva, flyt for å håndtere innkommende samhandlinger og deretter rute samhandlingen til Webex CC når Webex Connect-flyten eksplisitt setter samhandlingen i kø slik at den kan håndteres av en agent.

Figuren nedenfor illustrerer inntak av e-post, meldingsinteraksjoner i Webex CC.

Virtual Agent / BOT-integrasjoner

For samhandlinger med e-post og meldinger eller sosiale kanaler konfigureres de virtuelle agent-/BOT-behandlingene i Webex Connect-flyten.

På samme måte som med Virtual Agents for Voice, hvis BOT-behandlingen ender med eskalering som resultat, blir samhandlingen lagt i kø og rutet til en agent.

Valg av agent

Køer i Webex CC støtter følgende algoritmer for agentvalg:

• Lengste tilgjengelige agentruting

• Dyktig basert ruting

  • Lengste tilgjengelige agent (LAA)

  • Beste tilgjengelige agent (BAA)

Agenter er knyttet til køer gjennom Teams.

En kø kan tilordnes flere anropsdistribusjonsgrupper (der hver gruppe har ett eller flere team), på en sekvensiell måte med konfigurert venting på at anropsdistribusjonsgruppe skal legges til i køen, slik at søkeområdet for en samsvarende agent utvides til flere anropsdistribusjonsgrupper etter hvert som tiden går.

For ferdighetsbasert ruting, blant kompetansekravene som samsvarer med agenter som er knyttet til køen, velges en agent basert på LAA- eller BAA-konfigurasjon.

Spesifikke tilleggsfunksjoner for tale/telefoni

Agentbasert ruting (kun for tale-/telefonikanaler)

Webex CC Flow kan ved hjelp av aktiviteten QueueToAgent rute samhandlinger direkte til den valgte agenten basert på agent-ID-en.

Hvis agenten ikke er tilgjengelig for å håndtere samhandlinger, kan samhandlingen parkeres i en agentspesifikk kø og vente på at agenten blir tilgjengelig

Avansert køinformasjon

Webex CC Flow kan ved hjelp av aktiviteten GetQueueInfo hente sanntidsinformasjon for en kø som Posisjon i kø (PIQ), Estimert ventetid (EWT), antall agenter som er tilgjengelige i køen, og kan brukes til å avgjøre om kontakten skal settes i kø eller ikke.

Høflighet tilbakeringing

Webex CC Flow, ved hjelp av aktiviteten Tilbakeringing, lar kunden koble fra samtalen mens posisjonen i køen opprettholdes, og motta en tilbakeringing når den virtuelle samhandlingen i køen rutes til en agent.

Håndtering av overløp

Webex CC støtter overflythåndtering ved hjelp av kapasitetsbaserte team (CBT).

CBT er som et vanlig team med en kapasitet og en tilknyttet ekstern DN som tjener den kapasiteten. Den kan konfigureres sammen med andre team i distribusjonssyklusene for køanrop.

Vanligvis konfigureres dette som den siste syklusen, slik at det fungerer som en overflyt hvis ingen agent er tilgjengelig, selv etter at alle de konfigurerte anropsdistribusjonsgruppene ikke finner en tilgjengelig samsvarende agent for håndtering av samhandlingen.

Agent Desktop Operasjoner

Når en agent logger på Webex CC Agent Desktop, angir agenten et telefonnummer som innkommende anrop til agenten kan kobles til. Dette kan være en PSTN-telefon, mobiltelefon eller et internnummer hvis agenten er en Cisco Webex Calling bruker.

Vær oppmerksom på at dette nummeret må være et gyldig telefonnummer som anrop kan rutes til. Hvis ikke, kan ikke agenten motta innkommende anrop.

Basert på typen samhandling som agenten håndterer, gir widgetene i agentskrivebordet muligheten til å utføre bestemte mediekontrolloperasjoner.

Når et anrop er besvart, kan agenten for eksempel utføre følgende operasjoner knyttet til anropet.

• Sett samtalen på vent

• Start konsultasjonssamtale og

  • Overfør samtalen til et annet telefonnummer (si agenttelefonnummer) / inngangspunkt

  • Sende en annen agent til samtalen i konferanse

• Overføre samtalen til en annen kø

• Avslutte samtalen

Med Agent Desktop kan administratorer legge til egendefinerte widgeter der ved å utvide skrivebordsfunksjonene og gjøre det til en enhetlig samling av widgeter som agenter trenger for å få arbeidet gjort på en effektiv måte.

Skrivebordsarkitektur

Agent desktop er en mikro frontend basert enkeltside program som er vert for widgets bygget basert på webkomponenter arkitektur. Alle standard-/lagerwidgetene drives av data som hentes av API-er eller push-mekanismer på serversiden.

Dette er vanligvis asynkrone API-er, der svaret på en påkallelse kommer til skrivebordet via en WebSocket-tilkobling.

Webex CC-Agent Desktop godkjenner brukere med Cisco Common Identity (CI), og tokenet sendes videre til alle API aktiveringer. Også for egendefinerte widgeter, basert på godkjenningsmodellen, gir den en enkel påloggingsopplevelse til agenter hvis godkjenningsmodellen til den egendefinerte widgeten er integrert med CI.

Når en agent er en del av en samhandling, sendes alle oppdateringer til samhandlingstilstanden eller tilknyttede data også til skrivebordet via WebSocket-tilkoblingen.

Robusthet fra skrivebordet til tilkobling og ventetid

Den asynkrone API og push-en på serversiden muliggjør skalering, og eventuelle tilkoblingstap til WebSocket-grensesnittet oppdages, og skrivebordet forsøker å koble til på nytt og logge på på nytt.

Figuren nedenfor illustrerer agentskrivebordsarkitekturen i Webex CC.

Onboarding av kunder

Webex Control Hub er det primære grensesnittet som brukes av partnere og kunder for å introdusere kunder og aktivere eller konfigurere funksjoner.

Når organisasjons- og kontaktsenterfunksjonene er klargjort i Control Hub, vil det utløse en arbeidsflyt i Webex CC som utfører resten av trinnene i klargjøringen av alle kontaktsenterfunksjoner i henhold til tilbudene valgt av kunden.

All klargjøring av kontaktsenteret gjøres ved hjelp av en BPM-arbeidsflytmotor som muliggjør en deklarativ måte å definere de involverte trinnene på, og gjør hele klargjøringstrinnene motstandsdyktige mot feil og sikrer dataintegritet.

Figuren nedenfor illustrerer klargjøringsarbeidsflyten i Webex CC.

Konfigurasjonsenheter

De viktigste konfigurasjonsenhetene i Webex CC, omfang i en organisasjon, er:

Nettstedet

Sted betyr et sted hvor ett eller flere team, brukere (agenter/veiledere) er lokalisert.

Hver bruker og gruppe må tilhøre et område.

Gruppe

En gruppe brukere. Team brukes til å distribuere samhandlinger til agenter via køer.

Hvert lag må tilhøre et nettsted.

Agenter

Brukere som kan logge på Agent Desktop og håndtere samhandlinger på tvers av medietypene som er konfigurert i Webex CC.

Tilsynspersoner

Veiledere er tildelt team og kan overvåke/coache agenten og ha tilgang til status på teamnivå og agentstatistikk for de som tilhører teamene som veilederen er tildelt.

Kø

En kø er en logisk enhet der samhandlinger kan holdes mens du venter på at agenter skal være tilgjengelige, som deretter rutes til agenten.

Køer tilordnes til team, som søkeområdet for agenter, med mulighet til å utvide søkeområdet basert på medgått tidsterskel, ved å legge til andre team i søkeområdet.

Entrypoint

Entrypoint er en logisk enhet som representerer inngangspunktet for samhandlinger for å komme inn i Webex CC. For telefoni kartlegges dette primært telefonnummeret som anropene kommer til, og for e-post-/meldingskanaler peker Entrypoint til ressurskonfigurasjonen i Webex Connect.

Flyt

Flyten knyttet til inngangspunktet (via rutingsstrategi), som bestemmer trinnene som er involvert i håndtering av samhandlinger.

For ikke-telefonikanaler (e-post, meldinger/sosiale medier) velges Flow som en del av ressurskonfigurasjonen i Webex Connect.

Tilgangskontroll for kontaktsentre på flere steder

Webex CC-administratorer kan konfigurere brukerprofiler med tilgangsrettigheter til bestemte områder, grupper, køer og inngangspunkter. Videre, på grunn av den hierarkiske naturen til steder og team, når tilgang til bestemte nettsteder er gitt, kan bare lagene eller datoen som gjelder teamene, som tilhører disse nettstedene eller et eksplisitt spesifisert delsett av slike team, nås av brukeren.

For køer og inngangspunkter er de globale på organisasjonsnivå, så for forskjellige geografiske steder (steder der bestemte agenter og team er plassert) kan separate inngangspunkter og køer konfigureres, og veiledere / brukere kan ha tilgang til de enhetene som gjelder for bestemte nettsteder.

Figuren nedenfor illustrerer de viktigste konfigurasjonsenhetene og brukerprofilen som refererer til disse enhetene.

I tillegg til å begrense tilgangen til disse enhetene, kan Webex CC-administratorer kontrollere de spesifikke egenskapene/modulene som en bruker kan få tilgang til i administrasjonsgrensesnittet, og dermed ha brukere med administrasjons-/konfigurasjonsrettigheter til bestemte enheter samt deler/muligheter i administrasjonsgrensesnittet for Webex CC.

Innebygde skrivebordskoblinger: CRM-program som primært grensesnitt

I denne driftsmodusen logger agenten på CRM-konsollen som det primære programmet.

Webex CC er et innebygd program (også kalt et innebygd skrivebordsprogram eller innebygd softphone) som primært brukes til å logge på kontaktsenteret og motta Webex CC-rutede kontaktsentersamhandlinger.

Når CRM-integreringen mottar et anrop eller en samtaleforespørsel, utfører den følgende handlinger på CRM-konsollen

• Skjermbilde viser kundeoppføringen som er knyttet til ANI eller andre anropstilknyttede data.

• Postere samtalemetadata som aktivitetsnotater i kundeoppføringen

• La agenten "klikke for å ringe" ved å klikke på kontakten i CRM og starte et utgående anrop til kunden

• Postering av anropsoppføringer i CRM-rapporteringstabellene for primærrapportering om CRM.

• Gir full funksjonalitet for Agent Desktop- og samtalekontroller (innebygd og minifisert versjon av skrivebordsappen)

Den primære integreringsmodusen med CRM-ene er å bygge inn CC Desktop Webex programmet i en separat iFrame.

Videre kjører Webex CC Desktop-programmet en egendefinert hodeløs widget (ingen brukergrensesnitt) i bakgrunnen, og samhandler med det underliggende CRM-systemet for å utføre automatiserte handlinger på vegne av agenten.

Samhandlingene drives av to SDK-er som den hodeløse widgeten bruker.

• Webex CC Desktop JS SDK: Dette er JavaScript SDK levert av Webex CC for å registrere hendelseslyttere for agent- og kontakthandlinger.

• CRM JS SDK: Dette er CRM-klient-SDK-en som gjelder per CRM som abstraherer REST API-anrop med CRM. For salesforce brukes for eksempel CTI JS-biblioteket fra Salesforce til å utføre handlinger og lytte etter hendelser i CRM.

Figuren nedenfor illustrerer den innebygde skrivebords- og koblingsarkitekturen for CRM Webex CC

Webex CC støtter følgende CRM-løsninger for ovennevnte integrasjon:

• Salesforce

• ServiceNow

• Microsoft Dynamics 365

• Zendesk

• Freshdesk

For mer informasjon, besøk https://help.webex.com/en-us/result/integrate%20with%20webex%20contact%20center?offset=10.

Hvis du vil ha mer informasjon om hvordan du konfigurerer Webex CC-skrivebordsoppsettene for aktivering av CRM-kobling, funksjonssett og endringslogger, kan du gå til https://github.com/Ciscodevnet/webex-contact-center-crm-integrations.

Global tilgjengelighet av CRM-koblinger

CRM-koblingene er tilgjengelige i alle geografiske områder og områder der Webex CC er i drift.

Elastisk skalering og ytelse

Webex CC er vert for den tilpassede widgeten som muliggjør toveiskommunikasjon mellom CRM-applikasjonen og Webex CC-skrivebordet i AWS CloudFront CDN, noe som sikrer høy tilgjengelighet av widgeten AWS på tvers av tilgjengelighetssoner og regioner.

All CRM-integrasjonsspesifikk databehandling skjer i nettleseren der agenter bruker CRM-applikasjonen med Webex CC-skrivebord innebygd i CRM-applikasjonen.

Sikkerhet

CRM-koblingene startes via skrivebordsoppsettet for Webex CC-agenten, og valgfrie parametere sendes via skrivebordsoppsettet til widgeten for å slå funksjoner på og av.

Hvis du for eksempel vil aktivere widgeten Salesforce-handlinger, kan administratoren slå på parameterinnstillingen sfdcWidgetEnabled til sann.

Installasjon av pakke

For at integreringen skal fungere toveis, må CRM-konsollen ha det innebygde programmet installert. Dette er for å støtte lasting av skrivebordsprogrammet inne i en iFrame.

Alle Desktop Embedded-koblingene er tilgjengelige på CRM-markedsplassen.

For eksempel,

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/

Installasjonen av markedsplassprogrammet aktiverer de nødvendige plugin-modulene og importerer de nødvendige XML-filene til CRM-konsollen for å støtte rapportering av anropsoppføringer i CRM.

Flytintegreringer via HTTP(S)-koblinger i IVR

Webex CC Flow-byggherren støtter toveis datastrømmer mellom Webex CC og CRM-systemet ved hjelp av HTTP(S)-koblinger konfigurert i Webex Control Hub og brukt på Webex CC Flow.

Disse brukes primært til personalisering i taleinteraksjonene og tilpasset ruting i IVR.

Som standard støtter Webex CC Salesforce HTTP Connector på Control Hub. De andre CRM-koblingene kan legges til som egendefinerte koblinger på Webex Control Hub.

Hvis du vil ha mer informasjon om HTTP-koblinger, kan du gå til https://github.com/CiscoDevNet/webex-contact-center-crm-integrations.

IVR HTTP-kontakter:

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

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

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

Taleinfrastruktur på Edge

Voice Edge-komponentene tillater SIP-trunker fra kundenettverk / PSTN-bærere å avslutte, og dette aktiveres basert på hvitelistede IP-er som har lov til å koble til kantkomponentene.

Beregn infrastruktursikkerhet

Webex CC-databehandlingsforekomster klargjøres i AWS, og tjenester kjører som pods i Kubernetes-klynge som har flere navneområder og tilgang til hvert navneområde er begrenset med separat legitimasjon.

All klargjøring av infrastrukturen gjøres ved hjelp av kode – ingen manuelle trinn – og ingen av legitimasjonene kan nås manuelt.

Det er et sentralt legitimasjonslager med spesifikke baner konfigurert for spesifikt sett med tjenester / team, og tilgangen til selve legitimasjonslageret er begrenset og konfigurert som hemmeligheter i bygge- og distribusjonssystemene.

Ingen av infrastrukturkomponentene/tjenestene er direkte eksponert utenfor AWS VPC, og kun offentlig eksponerte grensesnitt er API-er og WebSocket-servere som styres og administreres ved hjelp av API-gateway,

Bortsett fra dette er det visse interne systemer og grensesnitt som brukes av utviklere som brukes til å vise logger, målestokker, distribusjonsdetaljer, byggestatus og testresultater, som er sikret ved hjelp av roller og grupper og integrert med Ciscos interne autentiseringssystemer.

Autentisering og autorisasjon for brukergrensesnitt

Alle brukergrensesnittene som brukes av ulike kontaktsenterbrukere (agenter, ledere, administratorer, analytikere), er beskyttet av Ciscos OAuth-flyter (Common Identity Based Bearer Token).

Autorisasjonen gjøres ved hjelp av roller for brukeren som fikk tokenet og omfangene som er tilordnet tokenet.

Data under overføring

Ingen av grensesnittene til tjenestene / infrastrukturkomponenten som er distribuert, er direkte eksponert for ekstern innkommende trafikk.

Utvalgte tjenester, med http APIer, eksponerer disse grensesnittene via en gateway, og all innkommende https (inkludert WebSocket) avsluttes i ALB og intern trafikk over http rutes til tjenestene.

Alle utgående interaksjoner er over https / TLS (for ikke http-protokoller).

Inne i VPC er den interne kommunikasjonen mellom tjenester - over http / tilpasset TCP-protokoll - over vanlig TCP-kontakt.

Data i hvile

Alle data som blir lagret, krypteres på lagringslaget. Videre er de datalagrene som er utenfor VPC, beskyttet og tilgangskontroll og autorisasjoner med legitimasjon sikkert lagret og administrert i et hemmelig lager.

Figuren nedenfor illustrerer dataflyten og sikkerhetsmodellen for både transitt og hvile.

PII-data for sluttbruker

Webex CC Flow, som er den programmatiske kontrolleren for håndtering av samhandlinger, kan brukes til å samle inn brukerdata, som kan tilordnes flytvariabler som er spesielt merket som "Inneholder sensitive data". Verdiene for slike data er kryptert, og ingen tjenester i transittbanen til dataene vil ha tilgang til disse dataene.

Videre blir slike data aldri lagret i CC Webex rapporteringsdatalageret, og loggene/meldingsinfrastrukturen vil ha krypterte data og klartekstdata lagres ikke noe sted i Webex CC.

PII-data for kontaktsenteragent/-leder

Kontaktsenterets brukerrelaterte data redigeres i logger, men er tilgjengelige for dataanalyse og visualisering i Webex CC-datalageret.

Faktorer for skala

For Webex CC er faktorene som påvirker skalaen:

• Samtidig antall agenter logget på

• Samtidig antall interaksjoner pågår

  • Handlinger utført på disse samhandlingene

• Samtidig antall handlinger som veiledere / agenter utfører, utenfor håndtering av interaksjonene

• Volumet av dataene som genereres og vedvarer

Arkitektoniske aspekter som muliggjør skala

Prinsippene som Webex CC er bygget og designet etter, gjør at løsningen kan skaleres dynamisk etter behov innenfor rammene som håndheves av infrastrukturen som tilbys for de ulike tjenestene og plattformkomponentene.

Hendelsesdrevet arkitektur

Tjenestene i Webex CC kommuniserer ved hjelp av meldinger, og de kritiske meldingsbehandlingsflytene innebærer ingen blokkering av IO-operasjoner, og tilstanden som kreves for å behandle meldinger, er lokalisert til forekomsten av tjenesten som behandler meldingen.

Statsløse tjenester (eller eksternalisert tilstand)

Tilstandsløse tjenester muliggjør elastisitet ved enkelt å legge til/fjerne flere forekomster av tjenestene. Det er visse tjenester som er iboende stateful i naturen, og de har eksternalisert statlig butikk og infrastrukturen støtter dynamiske endringer i antall forekomster av slike tjenester også med automatisk rebalansering / statlig overføring / lokalisering av staten til forekomsten som trenger staten.

Elastisk infrastruktur

Alle tjenestene kjører i Kubernetes, og infrastrukturen, også kjent som Kubernetes-noder, skaleres automatisk basert på bruken, og dette gjør det mulig å legge til flere databehandlingsnoder dynamisk opp til en maksimal høy terskel som er forhåndskonfigurert.

Lastprojeksjon og regelmessig validering

Alle tjenestene er benchmarked for ytelsesegenskaper og skaleringsmønster er validert på tjenestenivå.

Ytterligere kontinuerlig validering, toppbelastning og utholdenhetstester utføres med testparametere justert for forventet vekst i skalaen som påvirker attributter, noe som gjør det mulig å identifisere flaskehalser, planlegge å oppdatere den høye terskelen for ressursbruk i infrastrukturen og være klar for spilldagen.

Telefoni

For telefoni avgjøres håndteringen av innkommende taleanrop av hvordan anropet kom inn i kontaktsenteret (se Inngående mekanismer nedenfor) og Webex CC-flyten som er knyttet til inngangspunktet.

Anropet blir besvart, og ytterligere handlinger utføres i henhold til CC Flow Webex definisjonen – som er en programmatisk representasjon av handlingene som skal utføres under håndtering av anropet, enten før kø og ruting til en agent, eller selve flyten kan håndtere samtalen uten overføring til en agent.

Flow Builder i Webex CC lar utviklere definere flyten og tilordne den til inngangspunktet som anropet ankommer via i Webex CC.

Disse konfigurasjonsenhetene og bruken av dem dekkes i konfigurasjonsenheter.

Mer informasjon om Flow Builder er dekket i den kommende delen om IVR System.

E-post og meldinger

Fra Webex CC-perspektiv gir Webex Connect inngående og utgående funksjoner for alle digitale kanaler – e-post, meldingskanaler, som sluttbrukere kan bruke til å kontakte kontaktsenteret.

Webex Connect-flyt

• Bestemmer håndteringen av slike samhandlinger til samhandlingene er satt i kø og rutet til agenter. Dette inkluderer automatisk håndtering og BOT-behandlinger for alle former for meldings- og e-postinteraksjoner.

• Bruker forretningslogikk på innkommende samhandling.

• Håndterer kontakt før du setter deg i kø.

• Flow selv kan håndtere samhandlingen uten overføring til live agent.

Meldingskanalene som støttes av Webex CC er:

• Web App / Mobil App Chat

• Whatsapp

• Facebook Messenger

• SMS

E-postkanalene som støttes av Webex CC er:

• Gmail

• Office365

Inntrengningsmekanismer

Denne delen dekker mekanismene som en interaksjon kan komme inn i Webex CC. Basert på medietypen er mekanismene som en interaksjon når Webex CC forskjellige.

I telefoni er det for eksempel nødvendig med klargjøring av fysisk infrastruktur for å aktivere PSTN-tilkobling, konfigurasjon av telefonnumre og ruting av anropene til Webex CC.

For e-post-/meldingskanaler må inngangskonfigurasjonen gjøres i Webex Koble til, og den involverer klargjøring av e-post-/meldingskonto og Webex Connect-flytkonfigurasjon.

Innkommende tale

For taleanrop er et typisk scenario der brukere ringer et PSTN-telefonnummer som deretter kobles til kontaktsenteret. Fra et inngangsperspektiv trenger dette en mekanisme for å rute anrop fra PSTN til Webex CC.

Figuren nedenfor illustrerer inntaket av taleanrop til Webex CC.

Voice Ingress Services i Webex CC utfører tredjeparts samtalekontroll ved hjelp av SIP og svarer på det innkommende anropet, samt utfører overførings-, konferanse- og andre samtalekontrolloperasjoner.

Det logiske inngangspunktet for anrop i Webex CC er konfigurasjonsenheten kalt Entrypoint. For taleinngang er nøkkelkonfigurasjonen for Entrypoint telefonnummeret som er knyttet til det, som vanligvis er et gyldig PSTN-telefonnummer hentet fra valgt PSTN-leverandør.

Dette gjør det mulig å oppdage innkommende anrop på telefonnummeret, knytte anropet til Entrypoint og bruke andre konfigurasjonsparametere for inngangspunktet til å håndtere anropet i henhold til definisjonen for Webex CC-flyt som skal utløses for samhandlingen.

Merk:

Hvis du vil ha mer informasjon om alternativene for PSTN-tilkobling, kan du gå til 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.

Skalerbarhet og tilgjengelighet for infrastruktur for talekant

Webex CC VPOP-infrastrukturen inkluderer redundante SIP SBC-par, noe som sikrer høy tilgjengelighet og flere SBC-er kan legges til for å skalere de samtidige anropsvolumene som skal støttes.

Maks samtidige anrop som VPOP kan håndtere, avhenger av antall SBC-er som kjører, og som anrop sendes til.

For geografisk redundans – et nett av VPOP SBC med sammenkoblinger på tvers av flere par på tvers av regioner støttes.

For taleinngangstjenester er de horisontalt skalerbare for å håndtere et økende antall samtidige taleanrop som skal inntas til Webex CC.

Sikkerhetshensyn med talekantinfrastruktur

Tabellen nedenfor inneholder detaljer om tilkoblingsalternativene til Voice Edge-infrastrukturen.

For mer informasjon, 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

Hvert taleanrop som kommer inn i et telefonnummer som er tilknyttet et inngangspunkt, blir besvart av Webex CC, og kjøring av en Webex CC-flyt tilknyttet inngangspunktet, starter.

Webex CC Flow Builder leverer programmeringskonstruksjoner/operatorer og funksjonelle blokker, kalt aktiviteter, slik at administratorer eller andre som utformer og implementerer den IVR logikken, kan kombinere disse byggeklossene og opprette flytdefinisjonen.

Programmeringskonstruksjonene som Flow støtter, er:

• Deklarasjons- og innstillingsvariabler – tilstand knyttet til en flytkjøring

  • Pebble-uttrykk for å angi verdien av variabler

• Betingede kontroller

• Looping - bruk av Conditionals og Go To (evne til å kjede aktiviteter sammen)

• Aktivere REST API-er

• Analyseringsdata - JSON, TOML, XML vanligvis brukt til å analysere API svar.

• Komponere aktiviteter

Et representativt sett med aktiviteter som Flow-forsyninger er: Spill av meldinger Samle inn brukerdata Overføre samtalen til en annen destinasjon/et annet telefonnummer Send samtalen til en virtuell agent Sett anropet i kø slik at det kan besvares av en agent.

For hvert anrop som er aktivt, er en forekomst av flytkjøring også aktiv til samtalen avsluttes, noe som resulterer i samtidige kjøringer av flyter.

Hver forekomst av flytkjøring gir isolert miljø for data / tilstand knyttet til flyten og der av anropet.

I løpet av hele anropets livssyklus gjør flyt det også mulig å svare på bestemte hendelser som skjer, og håndtere dem – når et anrop for eksempel besvares av en agent, kan en hendelsesbehandling utløse et skjermvindu i grensesnittet for agentskrivebordet.

Hvis du vil ha mer informasjon om Webex CC Flow, kan du se https://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øtte for virtuell agent

Flow leverer en aktivitet for å levere samhandlingen til en virtuell agent, som er forhåndskonfigurert i Webex Control Hub.

Når samtalen er koblet til en virtuell agent, gir den en samtaleopplevelse IVR brukeren og aktiviteten avsluttes enten med avslutning av samtalen eller med eskalering av anropet til en agent.

Ved eskalering kan flyten konfigureres til å sette anropet i kø, som deretter blir besvart av en agent.

Innkommende digitale interaksjoner

For e-post og meldingskanal for innkommende samhandlinger bruker Webex CC Webex Connect til klargjøring av aktiva, flyt for å håndtere innkommende samhandlinger og deretter rute samhandlingen til Webex CC når Webex Connect-flyten eksplisitt setter samhandlingen i kø slik at den kan håndteres av en agent.

Figuren nedenfor illustrerer inntak av e-post, meldingsinteraksjoner i Webex CC.

Virtual Agent / BOT-integrasjoner

For samhandlinger med e-post og meldinger eller sosiale kanaler konfigureres de virtuelle agent-/BOT-behandlingene i Webex Connect-flyten.

På samme måte som med Virtual Agents for Voice, hvis BOT-behandlingen ender med eskalering som resultat, blir samhandlingen lagt i kø og rutet til en agent.

Valg av agent

Køer i Webex CC støtter følgende algoritmer for agentvalg:

• Lengste tilgjengelige agentruting

• Dyktig basert ruting

  • Lengste tilgjengelige agent (LAA)

  • Beste tilgjengelige agent (BAA)

Agenter er knyttet til køer gjennom Teams.

En kø kan tilordnes flere anropsdistribusjonsgrupper (der hver gruppe har ett eller flere team), på en sekvensiell måte med konfigurert venting på at anropsdistribusjonsgruppe skal legges til i køen, slik at søkeområdet for en samsvarende agent utvides til flere anropsdistribusjonsgrupper etter hvert som tiden går.

For ferdighetsbasert ruting, blant kompetansekravene som samsvarer med agenter som er knyttet til køen, velges en agent basert på LAA- eller BAA-konfigurasjon.

Spesifikke tilleggsfunksjoner for tale/telefoni

Agentbasert ruting (kun for tale-/telefonikanaler)

Webex CC Flow kan ved hjelp av aktiviteten QueueToAgent rute samhandlinger direkte til den valgte agenten basert på agent-ID-en.

Hvis agenten ikke er tilgjengelig for å håndtere samhandlinger, kan samhandlingen parkeres i en agentspesifikk kø og vente på at agenten blir tilgjengelig

Avansert køinformasjon

Webex CC Flow kan ved hjelp av aktiviteten GetQueueInfo hente sanntidsinformasjon for en kø som Posisjon i kø (PIQ), Estimert ventetid (EWT), antall agenter som er tilgjengelige i køen, og kan brukes til å avgjøre om kontakten skal settes i kø eller ikke.

Høflighet tilbakeringing

Webex CC Flow, ved hjelp av aktiviteten Tilbakeringing, lar kunden koble fra samtalen mens posisjonen i køen opprettholdes, og motta en tilbakeringing når den virtuelle samhandlingen i køen rutes til en agent.

Håndtering av overløp

Webex CC støtter overflythåndtering ved hjelp av kapasitetsbaserte team (CBT).

CBT er som et vanlig team med en kapasitet og en tilknyttet ekstern DN som tjener den kapasiteten. Den kan konfigureres sammen med andre team i distribusjonssyklusene for køanrop.

Vanligvis konfigureres dette som den siste syklusen, slik at det fungerer som en overflyt hvis ingen agent er tilgjengelig, selv etter at alle de konfigurerte anropsdistribusjonsgruppene ikke finner en tilgjengelig samsvarende agent for håndtering av samhandlingen.

Agent Desktop Operasjoner

Når en agent logger på Webex CC Agent Desktop, angir agenten et telefonnummer som innkommende anrop til agenten kan kobles til. Dette kan være en PSTN-telefon, mobiltelefon eller et internnummer hvis agenten er en Cisco Webex Calling bruker.

Vær oppmerksom på at dette nummeret må være et gyldig telefonnummer som anrop kan rutes til. Hvis ikke, kan ikke agenten motta innkommende anrop.

Basert på typen samhandling som agenten håndterer, gir widgetene i agentskrivebordet muligheten til å utføre bestemte mediekontrolloperasjoner.

Når et anrop er besvart, kan agenten for eksempel utføre følgende operasjoner knyttet til anropet.

• Sett samtalen på vent

• Start konsultasjonssamtale og

  • Overfør samtalen til et annet telefonnummer (si agenttelefonnummer) / inngangspunkt

  • Sende en annen agent til samtalen i konferanse

• Overføre samtalen til en annen kø

• Avslutte samtalen

Med Agent Desktop kan administratorer legge til egendefinerte widgeter der ved å utvide skrivebordsfunksjonene og gjøre det til en enhetlig samling av widgeter som agenter trenger for å få arbeidet gjort på en effektiv måte.

Skrivebordsarkitektur

Agent desktop er en mikro frontend basert enkeltside program som er vert for widgets bygget basert på webkomponenter arkitektur. Alle standard-/lagerwidgetene drives av data som hentes av API-er eller push-mekanismer på serversiden.

Dette er vanligvis asynkrone API-er, der svaret på en påkallelse kommer til skrivebordet via en WebSocket-tilkobling.

Webex CC-Agent Desktop godkjenner brukere med Cisco Common Identity (CI), og tokenet sendes videre til alle API aktiveringer. Også for egendefinerte widgeter, basert på godkjenningsmodellen, gir den en enkel påloggingsopplevelse til agenter hvis godkjenningsmodellen til den egendefinerte widgeten er integrert med CI.

Når en agent er en del av en samhandling, sendes alle oppdateringer til samhandlingstilstanden eller tilknyttede data også til skrivebordet via WebSocket-tilkoblingen.

Robusthet fra skrivebordet til tilkobling og ventetid

Den asynkrone API og push-en på serversiden muliggjør skalering, og eventuelle tilkoblingstap til WebSocket-grensesnittet oppdages, og skrivebordet forsøker å koble til på nytt og logge på på nytt.

Figuren nedenfor illustrerer agentskrivebordsarkitekturen i Webex CC.

Onboarding av kunder

Webex Control Hub er det primære grensesnittet som brukes av partnere og kunder for å introdusere kunder og aktivere eller konfigurere funksjoner.

Når organisasjons- og kontaktsenterfunksjonene er klargjort i Control Hub, vil det utløse en arbeidsflyt i Webex CC som utfører resten av trinnene i klargjøringen av alle kontaktsenterfunksjoner i henhold til tilbudene valgt av kunden.

All klargjøring av kontaktsenteret gjøres ved hjelp av en BPM-arbeidsflytmotor som muliggjør en deklarativ måte å definere de involverte trinnene på, og gjør hele klargjøringstrinnene motstandsdyktige mot feil og sikrer dataintegritet.

Figuren nedenfor illustrerer klargjøringsarbeidsflyten i Webex CC.

Konfigurasjonsenheter

De viktigste konfigurasjonsenhetene i Webex CC, omfang i en organisasjon, er:

Tomt

Sted betyr et sted hvor ett eller flere team, brukere (agenter/veiledere) er lokalisert.

Hver bruker og gruppe må tilhøre et område.

Gruppe

En gruppe brukere. Team brukes til å distribuere samhandlinger til agenter via køer.

Hvert lag må tilhøre et nettsted.

Agenter

Brukere som kan logge på Agent Desktop og håndtere samhandlinger på tvers av medietypene som er konfigurert i Webex CC.

Tilsynspersoner

Veiledere er tildelt team og kan overvåke/coache agenten og ha tilgang til status på teamnivå og agentstatistikk for de som tilhører teamene som veilederen er tildelt.

Kø

En kø er en logisk enhet der samhandlinger kan holdes mens du venter på at agenter skal være tilgjengelige, som deretter rutes til agenten.

Køer tilordnes til team, som søkeområdet for agenter, med mulighet til å utvide søkeområdet basert på medgått tidsterskel, ved å legge til andre team i søkeområdet.

Inngangspunkt

Entrypoint er en logisk enhet som representerer inngangspunktet for samhandlinger for å komme inn i Webex CC. For telefoni kartlegges dette primært telefonnummeret som anropene kommer til, og for e-post-/meldingskanaler peker Entrypoint til ressurskonfigurasjonen i Webex Connect.

Flyte

Flyten knyttet til inngangspunktet (via rutingsstrategi), som bestemmer trinnene som er involvert i håndtering av samhandlinger.

For ikke-telefonikanaler (e-post, meldinger/sosiale medier) velges Flow som en del av ressurskonfigurasjonen i Webex Connect.

Tilgangskontroll for kontaktsentre på flere steder

Webex CC-administratorer kan konfigurere brukerprofiler med tilgangsrettigheter til bestemte områder, grupper, køer og inngangspunkter. Videre, på grunn av den hierarkiske naturen til steder og team, når tilgang til bestemte nettsteder er gitt, kan bare lagene eller datoen som gjelder teamene, som tilhører disse nettstedene eller et eksplisitt spesifisert delsett av slike team, nås av brukeren.

For køer og inngangspunkter er de globale på organisasjonsnivå, så for forskjellige geografiske steder (steder der bestemte agenter og team er plassert) kan separate inngangspunkter og køer konfigureres, og veiledere / brukere kan ha tilgang til de enhetene som gjelder for bestemte nettsteder.

Figuren nedenfor illustrerer de viktigste konfigurasjonsenhetene og brukerprofilen som refererer til disse enhetene.

I tillegg til å begrense tilgangen til disse enhetene, kan Webex CC-administratorer kontrollere de spesifikke egenskapene/modulene som en bruker kan få tilgang til i administrasjonsgrensesnittet, og dermed ha brukere med administrasjons-/konfigurasjonsrettigheter til bestemte enheter samt deler/muligheter i administrasjonsgrensesnittet for Webex CC.

Innebygde skrivebordskoblinger: CRM-program som primært grensesnitt

I denne driftsmodusen logger agenten på CRM-konsollen som det primære programmet.

Webex CC er et innebygd program (også kalt et innebygd skrivebordsprogram eller innebygd softphone) som primært brukes til å logge på kontaktsenteret og motta Webex CC-rutede kontaktsentersamhandlinger.

Når CRM-integreringen mottar et anrop eller en samtaleforespørsel, utfører den følgende handlinger på CRM-konsollen

• Skjermbilde viser kundeoppføringen som er knyttet til ANI eller andre anropstilknyttede data.

• Postere samtalemetadata som aktivitetsnotater i kundeoppføringen

• La agenten "klikke for å ringe" ved å klikke på kontakten i CRM og starte et utgående anrop til kunden

• Postering av anropsoppføringer i CRM-rapporteringstabellene for primærrapportering om CRM.

• Gir full funksjonalitet for Agent Desktop- og samtalekontroller (innebygd og minifisert versjon av skrivebordsappen)

Den primære integreringsmodusen med CRM-ene er å bygge inn CC Desktop Webex programmet i en separat iFrame.

Videre kjører Webex CC Desktop-programmet en egendefinert hodeløs widget (ingen brukergrensesnitt) i bakgrunnen, og samhandler med det underliggende CRM-systemet for å utføre automatiserte handlinger på vegne av agenten.

Samhandlingene drives av to SDK-er som den hodeløse widgeten bruker.

• Webex CC Desktop JS SDK: Dette er JavaScript SDK levert av Webex CC for å registrere hendelseslyttere for agent- og kontakthandlinger.

• CRM JS SDK: Dette er CRM-klient-SDK-en som gjelder per CRM som abstraherer REST API-anrop med CRM. For salesforce brukes for eksempel det CTI JS-biblioteket fra Salesforce til å utføre handlinger og lytte etter hendelser i CRM.

Figuren nedenfor illustrerer CRM-arkitekturen for innebygd Webex CC-skrivebord og koblinger

Webex CC støtter følgende CRM-løsninger for ovennevnte integrasjon:

• Salgsstyrke

• ServiceNow

• Microsoft Dynamics 365

• Zendesk

• Freshdesk

For mer informasjon, besøk https://help.webex.com/en-us/result/integrate%20with%20webex%20contact%20center?offset=10.

Hvis du vil ha mer informasjon om hvordan du konfigurerer Webex CC-skrivebordsoppsett for aktivering av CRM-kobling, funksjonssett og endringslogger, kan du gå til https://github.com/Ciscodevnet/webex-contact-center-crm-integrations.

Global tilgjengelighet av CRM-koblinger

CRM-koblingene er tilgjengelige i alle geografiske områder og områder der Webex CC er i drift.

Elastisk skalering og ytelse

Webex CC er vert for den tilpassede widgeten som muliggjør toveiskommunikasjon mellom CRM-applikasjonen og Webex CC-skrivebordet i AWS CloudFront CDN, noe som sikrer høy tilgjengelighet av widgeten AWS på tvers av tilgjengelighetssoner og regioner.

All CRM-integreringsspesifikk databehandling skjer i nettleseren der agenter bruker CRM-programmet med Webex CC-skrivebord innebygd i CRM-programmet.

Sikkerhet

CRM-koblingene startes via skrivebordsoppsettet for Webex CC-agent, og valgfrie parametere sendes via skrivebordsoppsettet til widgeten for å slå funksjoner på og av.

Hvis du for eksempel vil aktivere widgeten Salesforce-handlinger, kan administratoren slå på parameterinnstillingen sfdcWidgetEnabled til sann.

Installasjon av pakke

For at integreringen skal fungere toveis, må CRM-konsollen ha det innebygde programmet installert. Dette er for å støtte lasting av skrivebordsprogrammet inne i en iFrame.

Alle Desktop Embedded-koblingene er tilgjengelige på CRM-markedsplassen.

For eksempel

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/

Installasjonen av markedsplassprogrammet aktiverer de nødvendige plugin-modulene og importerer de nødvendige XML-filene til CRM-konsollen for å støtte rapportering av anropsoppføringer i CRM.

Flytintegreringer via HTTP-koblinger i IVR

Webex CC Flow-byggherren støtter toveis dataflyter mellom Webex CC og CRM-systemet ved hjelp av HTTPs-koblinger konfigurert i Webex Control Hub og brukt på Webex CC Flow.

Disse brukes primært til tilpassing i talesamhandlinger og tilpasset ruting i IVR.

Som standard støtter Webex CC HTTP-koblingen Salesforce på Control Hub. De andre CRM-koblingene kan legges til som egendefinerte koblinger i Webex Control Hub.

Hvis du vil ha mer informasjon om HTTP-koblinger, kan du gå til https://github.com/CiscoDevNet/webex-contact-center-crm-integrations.

IVR HTTP-kontakter:

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

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

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

Taleinfrastruktur på Edge

Voice Edge-komponentene tillater SIP-trunker fra kundenettverk / PSTN-bærere å avslutte, og dette aktiveres basert på hvitelistede IP-er som har lov til å koble til kantkomponentene.

Beregn infrastruktursikkerhet

Webex CC-databehandlingsforekomster klargjøres i AWS, og tjenester kjører som pods i Kubernetes-klynge, som har flere navneområder og tilgang til hvert navneområde er begrenset med separat legitimasjon.

All klargjøring av infrastrukturen gjøres ved hjelp av kode – ingen manuelle trinn – og ingen av legitimasjonene kan nås manuelt.

Det er et sentralt legitimasjonslager med spesifikke baner konfigurert for spesifikt sett med tjenester / team, og tilgangen til selve legitimasjonslageret er begrenset og konfigurert som hemmeligheter i bygge- og distribusjonssystemene.

Ingen av infrastrukturkomponentene/tjenestene er direkte eksponert utenfor AWS VPC, og kun offentlig eksponerte grensesnitt er API-er og WebSocket-servere som styres og administreres ved hjelp av API-gateway,

Bortsett fra dette er det visse interne systemer og grensesnitt som brukes av utviklere som brukes til å vise logger, målestokker, distribusjonsdetaljer, byggestatus og testresultater, som er sikret ved hjelp av roller og grupper og integrert med Ciscos interne autentiseringssystemer.

Autentisering og autorisasjon for brukergrensesnitt

Alle brukergrensesnittene som brukes av ulike kontaktsenterbrukere (agenter, ledere, administratorer, analytikere), er beskyttet av Ciscos OAuth-flyter (Common Identity Based Bearer Token).

Autorisasjonen gjøres ved hjelp av roller for brukeren som fikk tokenet og omfangene som er tilordnet tokenet.

Data under overføring

Ingen av grensesnittene til tjenestene / infrastrukturkomponenten som er distribuert, er direkte eksponert for ekstern innkommende trafikk.

Utvalgte tjenester, med http APIer, eksponerer disse grensesnittene via en gateway, og all innkommende https (inkludert WebSocket) avsluttes i ALB og intern trafikk over http rutes til tjenestene.

Alle utgående interaksjoner er over https / TLS (for ikke http-protokoller).

Inne i VPC er den interne kommunikasjonen mellom tjenester - over http / custom TCP protocol - over vanlig TCP socket.

Data i hvile

Alle data som blir lagret, krypteres på lagringslaget. Videre er de datalagrene som er utenfor VPC, beskyttet og tilgangskontroll og autorisasjoner med legitimasjon sikkert lagret og administrert i et hemmelig lager.

Figuren nedenfor illustrerer dataflyten og sikkerhetsmodellen for både transitt og hvile.

PII-data for sluttbruker

Webex CC Flow, som er den programmatiske kontrolleren for håndtering av samhandlinger, kan brukes til å samle inn brukerdata, som kan tilordnes flytvariabler som er spesielt merket som "Inneholder sensitive data". Verdiene for slike data er kryptert, og ingen tjenester i transittbanen til dataene vil ha tilgang til disse dataene.

Videre blir slike data aldri lagret i CC Webex rapporteringsdatalageret, og loggene/meldingsinfrastrukturen vil ha krypterte data og klartekstdata lagres ikke noe sted i Webex CC.

PII-data for kontaktsenteragent/-leder

Kontaktsenterets brukerrelaterte data redigeres i logger, men er tilgjengelige for dataanalyse og visualisering i Webex CC-datalageret.

Faktorer for skala

For Webex CC er faktorene som påvirker skalaen:

• Samtidig antall agenter logget på

• Samtidig antall interaksjoner pågår

  • Handlinger utført på disse samhandlingene

• Samtidig antall handlinger som veiledere / agenter utfører, utenfor håndtering av interaksjonene

• Volumet av dataene som genereres og vedvarer

Arkitektoniske aspekter som muliggjør skala

Prinsippene som Webex CC er bygget og designet etter, gjør at løsningen kan skaleres dynamisk etter behov innenfor rammene som håndheves av infrastrukturen som tilbys for de ulike tjenestene og plattformkomponentene.

Hendelsesdrevet arkitektur

Tjenestene i Webex CC kommuniserer ved hjelp av meldinger, og de kritiske meldingsbehandlingsflytene innebærer ingen blokkering av IO-operasjoner, og tilstanden som kreves for å behandle meldinger, er lokalisert til forekomsten av tjenesten som behandler meldingen.

Statsløse tjenester (eller eksternalisert tilstand)

Tilstandsløse tjenester muliggjør elastisitet ved enkelt å legge til/fjerne flere forekomster av tjenestene. Det er visse tjenester som er iboende stateful i naturen, og de har eksternalisert statlig butikk og infrastrukturen støtter dynamiske endringer i antall forekomster av slike tjenester også med automatisk rebalansering / statlig overføring / lokalisering av staten til forekomsten som trenger staten.

Elastisk infrastruktur

Alle tjenestene kjører i Kubernetes, og infrastrukturen, også kjent som Kubernetes-noder, skaleres automatisk basert på bruken, og dette gjør det mulig å legge til flere databehandlingsnoder dynamisk opp til en maksimal høy terskel som er forhåndskonfigurert.

Lastprojeksjon og regelmessig validering

Alle tjenestene er benchmarked for ytelsesegenskaper og skaleringsmønster er validert på tjenestenivå.

Ytterligere kontinuerlig validering, toppbelastning og utholdenhetstester utføres med testparametere justert for forventet vekst i skalaen som påvirker attributter, noe som gjør det mulig å identifisere flaskehalser, planlegge å oppdatere den høye terskelen for ressursbruk i infrastrukturen og være klar for spilldagen.

Telefoni

For telefoni avgjøres håndteringen av innkommende taleanrop av hvordan anropet kom inn i kontaktsenteret (se Inngående mekanismer nedenfor) og Webex CC-flyten som er knyttet til inngangspunktet.

Anropet blir besvart, og ytterligere handlinger utføres i henhold til CC Flow Webex definisjonen – som er en programmatisk representasjon av handlingene som skal utføres under håndtering av anropet, enten før kø og ruting til en agent, eller selve flyten kan håndtere samtalen uten overføring til en agent.

Flow Builder i Webex CC lar utviklere definere flyten og tilordne den til inngangspunktet som anropet ankommer via i Webex CC.

Disse konfigurasjonsenhetene og bruken av dem dekkes i konfigurasjonsenheter.

Mer informasjon om Flow Builder er dekket i den kommende delen om IVR System.

E-post og meldinger

Fra Webex CC-perspektiv gir Webex Connect inngående og utgående funksjoner for alle digitale kanaler – e-post, meldingskanaler, som sluttbrukere kan bruke til å kontakte kontaktsenteret.

Webex Connect-flyt

• Bestemmer håndteringen av slike samhandlinger til samhandlingene er satt i kø og rutet til agenter. Dette inkluderer automatisk håndtering og BOT-behandlinger for alle former for meldings- og e-postinteraksjoner.

• Bruker forretningslogikk på innkommende samhandling.

• Håndterer kontakt før du setter deg i kø.

• Flow selv kan håndtere samhandlingen uten overføring til live agent.

Meldingskanalene som støttes av Webex CC er:

• Web App / Mobil App Chat

• Whatsapp

• Facebook Messenger

• SMS

• Apple Messages for bedrifter

E-postkanalene som støttes av Webex CC er:

• Gmail

• Office365

Inntrengningsmekanismer

Denne delen dekker mekanismene som en interaksjon kan komme inn i Webex CC. Basert på medietypen er mekanismene som en interaksjon når Webex CC forskjellige.

I telefoni er det for eksempel nødvendig med klargjøring av fysisk infrastruktur for å aktivere PSTN-tilkobling, konfigurasjon av telefonnumre og ruting av anropene til Webex CC.

For e-post-/meldingskanaler må inngangskonfigurasjonen gjøres i Webex Koble til, og den involverer klargjøring av e-post-/meldingskonto og Webex Connect-flytkonfigurasjon.

Innkommende tale

For taleanrop er et typisk scenario der brukere ringer et PSTN-telefonnummer som deretter kobles til kontaktsenteret. Fra et inngangsperspektiv trenger dette en mekanisme for å rute anrop fra PSTN til Webex CC.

Figuren nedenfor illustrerer inntaket av taleanrop til Webex CC.

Voice Ingress Services i Webex CC utfører tredjeparts samtalekontroll ved hjelp av SIP og svarer på det innkommende anropet, samt utfører overførings-, konferanse- og andre samtalekontrolloperasjoner.

Det logiske inngangspunktet for anrop i Webex CC er konfigurasjonsenheten kalt Entrypoint. For taleinngang er nøkkelkonfigurasjonen for Entrypoint telefonnummeret som er knyttet til det, som vanligvis er et gyldig PSTN-telefonnummer hentet fra valgt PSTN-leverandør.

Dette gjør det mulig å oppdage innkommende anrop på telefonnummeret, knytte anropet til Entrypoint og bruke andre konfigurasjonsparametere for inngangspunktet til å håndtere anropet i henhold til definisjonen for Webex CC-flyt som skal utløses for samhandlingen.

Merk:

Hvis du vil ha mer informasjon om alternativene for PSTN-tilkobling, kan du gå til 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.

Skalerbarhet og tilgjengelighet for infrastruktur for talekant

Webex CC VPOP-infrastrukturen inkluderer redundante SIP SBC-par, noe som sikrer høy tilgjengelighet og flere SBC-er kan legges til for å skalere de samtidige anropsvolumene som skal støttes.

Maks samtidige anrop som VPOP kan håndtere, avhenger av antall SBC-er som kjører, og som anrop sendes til.

For geografisk redundans – et nett av VPOP SBC med sammenkoblinger på tvers av flere par på tvers av regioner støttes.

For taleinngangstjenester er de horisontalt skalerbare for å håndtere et økende antall samtidige taleanrop som skal inntas til Webex CC.

Sikkerhetshensyn med talekantinfrastruktur

Tabellen nedenfor inneholder detaljer om tilkoblingsalternativene til Voice Edge-infrastrukturen.

For mer informasjon, 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

Hvert taleanrop som kommer inn i et telefonnummer som er tilknyttet et inngangspunkt, blir besvart av Webex CC, og kjøring av en Webex CC-flyt tilknyttet inngangspunktet, starter.

Webex CC Flow Builder leverer programmeringskonstruksjoner/operatorer og funksjonelle blokker, kalt aktiviteter, slik at administratorer eller andre som utformer og implementerer den IVR logikken, kan kombinere disse byggeklossene og opprette flytdefinisjonen.

Programmeringskonstruksjonene som Flow støtter, er:

• Deklarasjons- og innstillingsvariabler – tilstand knyttet til en flytkjøring

  • Pebble-uttrykk for å angi verdien av variabler

• Betingede kontroller

• Looping - bruk av Conditionals og Go To (evne til å kjede aktiviteter sammen)

• Aktivere REST API-er

• Analyseringsdata - JSON, TOML, XML vanligvis brukt til å analysere API svar.

• Komponere aktiviteter

Et representativt sett med aktiviteter som Flow-forsyninger er: Spill av meldinger Samle inn brukerdata Overføre samtalen til en annen destinasjon/et annet telefonnummer Send samtalen til en virtuell agent Sett anropet i kø slik at det kan besvares av en agent.

For hvert anrop som er aktivt, er en forekomst av flytkjøring også aktiv til samtalen avsluttes, noe som resulterer i samtidige kjøringer av flyter.

Hver forekomst av flytkjøring gir isolert miljø for data / tilstand knyttet til flyten og der av anropet.

I løpet av hele anropets livssyklus gjør flyt det også mulig å svare på bestemte hendelser som skjer, og håndtere dem – når et anrop for eksempel besvares av en agent, kan en hendelsesbehandling utløse et skjermvindu i grensesnittet for agentskrivebordet.

Hvis du vil ha mer informasjon om Webex CC Flow, kan du se https://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øtte for virtuell agent

Flow leverer en aktivitet for å levere samhandlingen til en virtuell agent, som er forhåndskonfigurert i Webex Control Hub.

Når samtalen er koblet til en virtuell agent, gir den en samtaleopplevelse IVR brukeren og aktiviteten avsluttes enten med avslutning av samtalen eller med eskalering av anropet til en agent.

Ved eskalering kan flyten konfigureres til å sette anropet i kø, som deretter blir besvart av en agent.

Innkommende digitale interaksjoner

For e-post og meldingskanal for innkommende samhandlinger bruker Webex CC Webex Connect til klargjøring av aktiva, flyt for å håndtere innkommende samhandlinger og deretter rute samhandlingen til Webex CC når Webex Connect-flyten eksplisitt setter samhandlingen i kø slik at den kan håndteres av en agent.

Figuren nedenfor illustrerer inntak av e-post, meldingsinteraksjoner i Webex CC.

Virtual Agent / BOT-integrasjoner

For samhandlinger med e-post og meldinger eller sosiale kanaler konfigureres de virtuelle agent-/BOT-behandlingene i Webex Connect-flyten.

På samme måte som med Virtual Agents for Voice, hvis BOT-behandlingen ender med eskalering som resultat, blir samhandlingen lagt i kø og rutet til en agent.

Valg av agent

Køer i Webex CC støtter følgende algoritmer for agentvalg:

• Lengste tilgjengelige agentruting

• Dyktig basert ruting

  • Lengste tilgjengelige agent (LAA)

  • Beste tilgjengelige agent (BAA)

Agenter er knyttet til køer gjennom Teams.

En kø kan tilordnes flere anropsdistribusjonsgrupper (der hver gruppe har ett eller flere team), på en sekvensiell måte med konfigurert venting på at anropsdistribusjonsgruppe skal legges til i køen, slik at søkeområdet for en samsvarende agent utvides til flere anropsdistribusjonsgrupper etter hvert som tiden går.

For ferdighetsbasert ruting, blant kompetansekravene som samsvarer med agenter som er knyttet til køen, velges en agent basert på LAA- eller BAA-konfigurasjon.

Spesifikke tilleggsfunksjoner for tale/telefoni

Agentbasert ruting (kun for tale-/telefonikanaler)

Webex CC Flow kan ved hjelp av aktiviteten QueueToAgent rute samhandlinger direkte til den valgte agenten basert på agent-ID-en.

Hvis agenten ikke er tilgjengelig for å håndtere samhandlinger, kan samhandlingen parkeres i en agentspesifikk kø og vente på at agenten blir tilgjengelig

Avansert køinformasjon

Webex CC Flow kan ved hjelp av aktiviteten GetQueueInfo hente sanntidsinformasjon for en kø som Posisjon i kø (PIQ), Estimert ventetid (EWT), antall agenter som er tilgjengelige i køen, og kan brukes til å avgjøre om kontakten skal settes i kø eller ikke.

Høflighet tilbakeringing

Webex CC Flow, ved hjelp av aktiviteten Tilbakeringing, lar kunden koble fra samtalen mens posisjonen i køen opprettholdes, og motta en tilbakeringing når den virtuelle samhandlingen i køen rutes til en agent.

Håndtering av overløp

Webex CC støtter overflythåndtering ved hjelp av kapasitetsbaserte team (CBT).

CBT er som et vanlig team med en kapasitet og en tilknyttet ekstern DN som tjener den kapasiteten. Den kan konfigureres sammen med andre team i distribusjonssyklusene for køanrop.

Vanligvis konfigureres dette som den siste syklusen, slik at det fungerer som en overflyt hvis ingen agent er tilgjengelig, selv etter at alle de konfigurerte anropsdistribusjonsgruppene ikke finner en tilgjengelig samsvarende agent for håndtering av samhandlingen.

Agent Desktop Operasjoner

Når en agent logger på Webex CC Agent Desktop, angir agenten et telefonnummer som innkommende anrop til agenten kan kobles til. Dette kan være en PSTN-telefon, mobiltelefon eller et internnummer hvis agenten er en Cisco Webex Calling bruker.

Vær oppmerksom på at dette nummeret må være et gyldig telefonnummer som anrop kan rutes til. Hvis ikke, kan ikke agenten motta innkommende anrop.

Basert på typen samhandling som agenten håndterer, gir widgetene i agentskrivebordet muligheten til å utføre bestemte mediekontrolloperasjoner.

Når et anrop er besvart, kan agenten for eksempel utføre følgende operasjoner knyttet til anropet.

• Sett samtalen på vent

• Start konsultasjonssamtale og

  • Overfør samtalen til et annet telefonnummer (si agenttelefonnummer) / inngangspunkt

  • Sende en annen agent til samtalen i konferanse

• Overføre samtalen til en annen kø

• Avslutte samtalen

Med Agent Desktop kan administratorer legge til egendefinerte widgeter der ved å utvide skrivebordsfunksjonene og gjøre det til en enhetlig samling av widgeter som agenter trenger for å få arbeidet gjort på en effektiv måte.

Skrivebordsarkitektur

Agent desktop er en mikro frontend basert enkeltside program som er vert for widgets bygget basert på webkomponenter arkitektur. Alle standard-/lagerwidgetene drives av data som hentes av API-er eller push-mekanismer på serversiden.

Dette er vanligvis asynkrone API-er, der svaret på en påkallelse kommer til skrivebordet via en WebSocket-tilkobling.

Webex CC-Agent Desktop godkjenner brukere med Cisco Common Identity (CI), og tokenet sendes videre til alle API aktiveringer. Også for egendefinerte widgeter, basert på godkjenningsmodellen, gir den en enkel påloggingsopplevelse til agenter hvis godkjenningsmodellen til den egendefinerte widgeten er integrert med CI.

Når en agent er en del av en samhandling, sendes alle oppdateringer til samhandlingstilstanden eller tilknyttede data også til skrivebordet via WebSocket-tilkoblingen.

Robusthet fra skrivebordet til tilkobling og ventetid

Den asynkrone API og push-en på serversiden muliggjør skalering, og eventuelle tilkoblingstap til WebSocket-grensesnittet oppdages, og skrivebordet forsøker å koble til på nytt og logge på på nytt.

Figuren nedenfor illustrerer agentskrivebordsarkitekturen i Webex CC.

Onboarding av kunder

Webex Control Hub er det primære grensesnittet som brukes av partnere og kunder for å introdusere kunder og aktivere eller konfigurere funksjoner.

Når organisasjons- og kontaktsenterfunksjonene er klargjort i Control Hub, vil det utløse en arbeidsflyt i Webex CC som utfører resten av trinnene i klargjøringen av alle kontaktsenterfunksjoner i henhold til tilbudene valgt av kunden.

All klargjøring av kontaktsenteret gjøres ved hjelp av en BPM-arbeidsflytmotor som muliggjør en deklarativ måte å definere de involverte trinnene på, og gjør hele klargjøringstrinnene motstandsdyktige mot feil og sikrer dataintegritet.

Figuren nedenfor illustrerer klargjøringsarbeidsflyten i Webex CC.

Konfigurasjonsenheter

De viktigste konfigurasjonsenhetene i Webex CC, omfang i en organisasjon, er:

Tomt

Sted betyr et sted hvor ett eller flere team, brukere (agenter/veiledere) er lokalisert.

Hver bruker og gruppe må tilhøre et område.

Gruppe

En gruppe brukere. Team brukes til å distribuere samhandlinger til agenter via køer.

Hvert lag må tilhøre et nettsted.

Agenter

Brukere som kan logge på Agent Desktop og håndtere samhandlinger på tvers av medietypene som er konfigurert i Webex CC.

Tilsynspersoner

Veiledere er tildelt team og kan overvåke/coache agenten og ha tilgang til status på teamnivå og agentstatistikk for de som tilhører teamene som veilederen er tildelt.

Kø

En kø er en logisk enhet der samhandlinger kan holdes mens du venter på at agenter skal være tilgjengelige, som deretter rutes til agenten.

Køer tilordnes til team, som søkeområdet for agenter, med mulighet til å utvide søkeområdet basert på medgått tidsterskel, ved å legge til andre team i søkeområdet.

Inngangspunkt

Entrypoint er en logisk enhet som representerer inngangspunktet for samhandlinger for å komme inn i Webex CC. For telefoni kartlegges dette primært telefonnummeret som anropene kommer til, og for e-post-/meldingskanaler peker Entrypoint til ressurskonfigurasjonen i Webex Connect.

Flyte

Flyten knyttet til inngangspunktet (via rutingsstrategi), som bestemmer trinnene som er involvert i håndtering av samhandlinger.

For ikke-telefonikanaler (e-post, meldinger/sosiale medier) velges Flow som en del av ressurskonfigurasjonen i Webex Connect.

Tilgangskontroll for kontaktsentre på flere steder

Webex CC-administratorer kan konfigurere brukerprofiler med tilgangsrettigheter til bestemte områder, grupper, køer og inngangspunkter. Videre, på grunn av den hierarkiske naturen til steder og team, når tilgang til bestemte nettsteder er gitt, kan bare lagene eller datoen som gjelder teamene, som tilhører disse nettstedene eller et eksplisitt spesifisert delsett av slike team, nås av brukeren.

For køer og inngangspunkter er de globale på organisasjonsnivå, så for forskjellige geografiske steder (steder der bestemte agenter og team er plassert) kan separate inngangspunkter og køer konfigureres, og veiledere / brukere kan ha tilgang til de enhetene som gjelder for bestemte nettsteder.

Figuren nedenfor illustrerer de viktigste konfigurasjonsenhetene og brukerprofilen som refererer til disse enhetene.

I tillegg til å begrense tilgangen til disse enhetene, kan Webex CC-administratorer kontrollere de spesifikke egenskapene/modulene som en bruker kan få tilgang til i administrasjonsgrensesnittet, og dermed ha brukere med administrasjons-/konfigurasjonsrettigheter til bestemte enheter samt deler/muligheter i administrasjonsgrensesnittet for Webex CC.

Innebygde skrivebordskoblinger: CRM-program som primært grensesnitt

I denne driftsmodusen logger agenten på CRM-konsollen som det primære programmet.

Webex CC er et innebygd program (også kalt et innebygd skrivebordsprogram eller innebygd softphone) som primært brukes til å logge på kontaktsenteret og motta Webex CC-rutede kontaktsentersamhandlinger.

Når CRM-integreringen mottar et anrop eller en samtaleforespørsel, utfører den følgende handlinger på CRM-konsollen

• Skjermbilde viser kundeoppføringen som er knyttet til ANI eller andre anropstilknyttede data.

• Postere samtalemetadata som aktivitetsnotater i kundeoppføringen

• La agenten "klikke for å ringe" ved å klikke på kontakten i CRM og starte et utgående anrop til kunden

• Postering av anropsoppføringer i CRM-rapporteringstabellene for primærrapportering om CRM.

• Gir full funksjonalitet for Agent Desktop- og samtalekontroller (innebygd og minifisert versjon av skrivebordsappen)

Den primære integreringsmodusen med CRM-ene er å bygge inn CC Desktop Webex programmet i en separat iFrame.

Videre kjører Webex CC Desktop-programmet en egendefinert hodeløs widget (ingen brukergrensesnitt) i bakgrunnen, og samhandler med det underliggende CRM-systemet for å utføre automatiserte handlinger på vegne av agenten.

Samhandlingene drives av to SDK-er som den hodeløse widgeten bruker.

• Webex CC Desktop JS SDK: Dette er JavaScript SDK levert av Webex CC for å registrere hendelseslyttere for agent- og kontakthandlinger.

• CRM JS SDK: Dette er CRM-klient-SDK-en som gjelder per CRM som abstraherer REST API-anrop med CRM. For salesforce brukes for eksempel det CTI JS-biblioteket fra Salesforce til å utføre handlinger og lytte etter hendelser i CRM.

Figuren nedenfor illustrerer CRM-arkitekturen for innebygd Webex CC-skrivebord og koblinger

Webex CC støtter følgende CRM-løsninger for ovennevnte integrasjon:

• Salgsstyrke

• ServiceNow

• Microsoft Dynamics 365

• Zendesk

• Freshdesk

For mer informasjon, besøk https://help.webex.com/en-us/result/integrate%20with%20webex%20contact%20center?offset=10.

Hvis du vil ha mer informasjon om hvordan du konfigurerer Webex CC-skrivebordsoppsett for aktivering av CRM-kobling, funksjonssett og endringslogger, kan du gå til https://github.com/Ciscodevnet/webex-contact-center-crm-integrations.

Global tilgjengelighet av CRM-koblinger

CRM-koblingene er tilgjengelige i alle geografiske områder og områder der Webex CC er i drift.

Elastisk skalering og ytelse

Webex CC er vert for den tilpassede widgeten som muliggjør toveiskommunikasjon mellom CRM-applikasjonen og Webex CC-skrivebordet i AWS CloudFront CDN, noe som sikrer høy tilgjengelighet av widgeten AWS på tvers av tilgjengelighetssoner og regioner.

All CRM-integreringsspesifikk databehandling skjer i nettleseren der agenter bruker CRM-programmet med Webex CC-skrivebord innebygd i CRM-programmet.

Sikkerhet

CRM-koblingene startes via skrivebordsoppsettet for Webex CC-agent, og valgfrie parametere sendes via skrivebordsoppsettet til widgeten for å slå funksjoner på og av.

Hvis du for eksempel vil aktivere widgeten Salesforce-handlinger, kan administratoren slå på parameterinnstillingen sfdcWidgetEnabled til sann.

Installasjon av pakke

For at integreringen skal fungere toveis, må CRM-konsollen ha det innebygde programmet installert. Dette er for å støtte lasting av skrivebordsprogrammet inne i en iFrame.

Alle Desktop Embedded-koblingene er tilgjengelige på CRM-markedsplassen.

For eksempel

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/

Installasjonen av markedsplassprogrammet aktiverer de nødvendige plugin-modulene og importerer de nødvendige XML-filene til CRM-konsollen for å støtte rapportering av anropsoppføringer i CRM.

Flytintegreringer via HTTP-koblinger i IVR

Webex CC Flow-byggherren støtter toveis dataflyter mellom Webex CC og CRM-systemet ved hjelp av HTTPs-koblinger konfigurert i Webex Control Hub og brukt på Webex CC Flow.

Disse brukes primært til tilpassing i talesamhandlinger og tilpasset ruting i IVR.

Som standard støtter Webex CC HTTP-koblingen Salesforce på Control Hub. De andre CRM-koblingene kan legges til som egendefinerte koblinger i Webex Control Hub.

Hvis du vil ha mer informasjon om HTTP-koblinger, kan du gå til https://github.com/CiscoDevNet/webex-contact-center-crm-integrations.

IVR HTTP-kontakter:

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

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

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

Taleinfrastruktur på Edge

Voice Edge-komponentene tillater SIP-trunker fra kundenettverk / PSTN-bærere å avslutte, og dette aktiveres basert på hvitelistede IP-er som har lov til å koble til kantkomponentene.

Beregn infrastruktursikkerhet

Webex CC-databehandlingsforekomster klargjøres i AWS, og tjenester kjører som pods i Kubernetes-klynge, som har flere navneområder og tilgang til hvert navneområde er begrenset med separat legitimasjon.

All klargjøring av infrastrukturen gjøres ved hjelp av kode – ingen manuelle trinn – og ingen av legitimasjonene kan nås manuelt.

Det er et sentralt legitimasjonslager med spesifikke baner konfigurert for spesifikt sett med tjenester / team, og tilgangen til selve legitimasjonslageret er begrenset og konfigurert som hemmeligheter i bygge- og distribusjonssystemene.

Ingen av infrastrukturkomponentene/tjenestene er direkte eksponert utenfor AWS VPC, og kun offentlig eksponerte grensesnitt er API-er og WebSocket-servere som styres og administreres ved hjelp av API-gateway,

Bortsett fra dette er det visse interne systemer og grensesnitt som brukes av utviklere som brukes til å vise logger, målestokker, distribusjonsdetaljer, byggestatus og testresultater, som er sikret ved hjelp av roller og grupper og integrert med Ciscos interne autentiseringssystemer.

Autentisering og autorisasjon for brukergrensesnitt

Alle brukergrensesnittene som brukes av ulike kontaktsenterbrukere (agenter, ledere, administratorer, analytikere), er beskyttet av Ciscos OAuth-flyter (Common Identity Based Bearer Token).

Autorisasjonen gjøres ved hjelp av roller for brukeren som fikk tokenet og omfangene som er tilordnet tokenet.

Data under overføring

Ingen av grensesnittene til tjenestene / infrastrukturkomponenten som er distribuert, er direkte eksponert for ekstern innkommende trafikk.

Utvalgte tjenester, med http APIer, eksponerer disse grensesnittene via en gateway, og all innkommende https (inkludert WebSocket) avsluttes i ALB og intern trafikk over http rutes til tjenestene.

Alle utgående interaksjoner er over https / TLS (for ikke http-protokoller).

Inne i VPC er den interne kommunikasjonen mellom tjenester - over http / custom TCP protocol - over vanlig TCP socket.

Data i hvile

Alle data som blir lagret, krypteres på lagringslaget. Videre er de datalagrene som er utenfor VPC, beskyttet og tilgangskontroll og autorisasjoner med legitimasjon sikkert lagret og administrert i et hemmelig lager.

Figuren nedenfor illustrerer dataflyten og sikkerhetsmodellen for både transitt og hvile.

PII-data for sluttbruker

Webex CC Flow, som er den programmatiske kontrolleren for håndtering av samhandlinger, kan brukes til å samle inn brukerdata, som kan tilordnes flytvariabler som er spesielt merket som "Inneholder sensitive data". Verdiene for slike data er kryptert, og ingen tjenester i transittbanen til dataene vil ha tilgang til disse dataene.

Videre blir slike data aldri lagret i CC Webex rapporteringsdatalageret, og loggene/meldingsinfrastrukturen vil ha krypterte data og klartekstdata lagres ikke noe sted i Webex CC.

PII-data for kontaktsenteragent/-leder

Kontaktsenterets brukerrelaterte data redigeres i logger, men er tilgjengelige for dataanalyse og visualisering i Webex CC-datalageret.

Faktorer for skala

For Webex CC er faktorene som påvirker skalaen:

• Samtidig antall agenter logget på

• Samtidig antall interaksjoner pågår

  • Handlinger utført på disse samhandlingene

• Samtidig antall handlinger som veiledere / agenter utfører, utenfor håndtering av interaksjonene

• Volumet av dataene som genereres og vedvarer

Arkitektoniske aspekter som muliggjør skala

Prinsippene som Webex CC er bygget og designet etter, gjør at løsningen kan skaleres dynamisk etter behov innenfor rammene som håndheves av infrastrukturen som tilbys for de ulike tjenestene og plattformkomponentene.

Hendelsesdrevet arkitektur

Tjenestene i Webex CC kommuniserer ved hjelp av meldinger, og de kritiske meldingsbehandlingsflytene innebærer ingen blokkering av IO-operasjoner, og tilstanden som kreves for å behandle meldinger, er lokalisert til forekomsten av tjenesten som behandler meldingen.

Statsløse tjenester (eller eksternalisert tilstand)

Tilstandsløse tjenester muliggjør elastisitet ved enkelt å legge til/fjerne flere forekomster av tjenestene. Det er visse tjenester som er iboende stateful i naturen, og de har eksternalisert statlig butikk og infrastrukturen støtter dynamiske endringer i antall forekomster av slike tjenester også med automatisk rebalansering / statlig overføring / lokalisering av staten til forekomsten som trenger staten.

Elastisk infrastruktur

Alle tjenestene kjører i Kubernetes, og infrastrukturen, også kjent som Kubernetes-noder, skaleres automatisk basert på bruken, og dette gjør det mulig å legge til flere databehandlingsnoder dynamisk opp til en maksimal høy terskel som er forhåndskonfigurert.

Lastprojeksjon og regelmessig validering

Alle tjenestene er benchmarked for ytelsesegenskaper og skaleringsmønster er validert på tjenestenivå.

Ytterligere kontinuerlig validering, toppbelastning og utholdenhetstester utføres med testparametere justert for forventet vekst i skalaen som påvirker attributter, noe som gjør det mulig å identifisere flaskehalser, planlegge å oppdatere den høye terskelen for ressursbruk i infrastrukturen og være klar for spilldagen.