Telefoni-

For telefoni bestemmes håndteringen af indgående taleopkald af, hvordan opkaldet er kommet ind i kontaktcenteret (se Indtrængningsmekanismer nedenfor) og af det Webex CC-flow, der er knyttet til indgangspunktet.

Opkaldet besvares, og der udføres yderligere handlinger i henhold til Webex CC Flow-definitionen – som er en programmatisk repræsentation af de handlinger, der skal udføres, mens opkaldet håndteres, enten før det sættes i kø og dirigeres til en agent, eller selve flowet kan håndtere opkaldet uden overførsel til en agent.

Flow Builder i Webex CC giver udviklere mulighed for at definere flowet og tildele det til det indgangspunkt, via hvilket opkaldet ankommer til Webex CC.

Disse konfigurationsobjekter og deres anvendelse er dækket i Konfigurationsenheder.

Flere oplysninger om Flow Builder er dækket i det kommende afsnit om IVR System.

E-mail og beskeder

Fra Webex CC-perspektiv leverer Webex Connect indgående og udgående funktioner til alle digitale kanaler - e-mail, meddelelseskanaler, som slutbrugere kan bruge til at kontakte kontaktcenter.

Webex Connect Flow

• Bestemmer håndteringen af sådanne interaktioner, indtil interaktionerne er sat i kø og distribueret til agenter. Dette omfatter automatisk håndtering og BOT-behandlinger for alle former for messaging og e-mail-interaktioner.

• Anvender forretningslogik på indgående interaktion.

• Håndterer kontakt før kø.

• Flow selv kan håndtere interaktionen uden overførsel til live agent.

De meddelelseskanaler, der understøttes af Webex CC, er:

• Web App / Mobil App Chat

• WhatsApp

• Facebook Messenger

• Sms

De e-mailkanaler, der understøttes af Webex CC, er:

• Gmail

• Office365

Indtrængningsmekanismer

Dette afsnit dækker de mekanismer, hvormed en interaktion kan komme ind i Webex CC. Baseret på medietypen er de mekanismer, hvormed en interaktion når Webex CC, forskellige.

Inden for telefoni er der f.eks. behov for fysisk infrastrukturprovisionering for at aktivere PSTN-forbindelse, konfiguration af telefonnumre og routing af opkald til Webex CC.

For e-mail-/meddelelseskanaler skal indgående konfiguration udføres i Webex Connect, og det involverer klargøring af e-mail-/messaging-konto og konfiguration af Webex Connect-flow.

Indgående stemme

I forbindelse med taleopkald er det typisk sådan, at brugerne ringer til et PSTN-telefonnummer, som derefter forbindes til kontaktcentret. Fra et indgående perspektiv kræver dette en mekanisme til at dirigere opkald fra PSTN til Webex CC.

Figur 1 viser indtagelse af taleopkald til Webex CC.

Voice Ingress Services i Webex CC udfører tredjepartsopkaldsstyring ved hjælp af SIP og besvarer det indgående opkald samt udfører overførsels-, konference- og andre opkaldskontrolhandlinger.

Det logiske indgangspunkt for opkald i Webex CC er konfigurationsenheden med navnet "Indgangspunkt". I forbindelse med taleindtrængning er nøglekonfigurationen for indgangspunktet det telefonnummer, der er knyttet til det, hvilket typisk er et gyldigt PSTN-telefonnummer, der er hentet fra den valgte PSTN-udbyder.

Dette gør det muligt at registrere indgående opkald på telefonnummeret, knytte opkaldet til indgangspunktet og bruge andre konfigurationsparametre for indgangspunktet til at håndtere opkaldet i henhold til den Webex CC Flow-definition, der skal udløses for interaktionen.

Bemærk:

Du kan finde flere oplysninger om PSTN-forbindelsesindstillingerne på 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.

Skalerbarhed og tilgængelighed af Voice Edge-infrastruktur

Webex CC VPOP-infrastrukturen omfatter redundante par SIP SBC'er, der sikrer høj tilgængelighed, og flere SBC'er kan tilføjes for at skalere de samtidige opkaldsmængder, der skal understøttes.

Det maksimale antal samtidige opkald, som VPOP kan håndtere, afhænger af antallet af SBC'er, der kører, og som opkald sendes til.

For geografisk redundans – et net af VPOP SBC med sammenkoblinger på tværs af flere par på tværs af regioner understøttes.

For taleindtrængningstjenester er de horisontalt skalerbare til at håndtere et stigende antal samtidige taleopkald, der skal indtages til Webex CC.

Sikkerhedsovervejelser i forbindelse med voice edge-infrastruktur

Nedenstående tabel indeholder oplysninger om tilslutningsmulighederne til Voice Edge-infrastrukturen.

For flere detaljer, besøg 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-system

Alle taleopkald, der kommer til et telefonnummer, der er tilknyttet et indgangspunkt, bliver besvaret af Webex CC, og udførelse af et Webex CC-flow, der er knyttet til indgangspunktet, går i gang.

Webex CC Flow Builder leverer programmeringskonstruktioner/operatorer og funktionelle blokke, kaldet aktiviteter, så administratorer eller andre, der designer og implementerer den IVR logik, kan kombinere disse byggesten og oprette Flow-definitionen.

De programmeringskonstruktioner, som Flow understøtter, er:

• Rapporterings- og indstillingsvariabler – tilstand, der er knyttet til en flowudførelse

  • Pebble Expressions for at indstille værdien af variabler

• Betinget kontrol

• Looping - ved hjælp af Conditionals og Go To (evne til at kæde aktiviteter sammen)

• Kald REST-API'er

• Parse Data - JSON, TOML, XML bruges typisk til at analysere API svar.

• Komponere aktiviteter

Et repræsentativt sæt aktiviteter, som Flow leverer, er: Afspil beskeder Indsaml brugerdata Omstille opkaldet til en anden destination/et andet telefonnummer Send opkaldet til en virtuel agent Sæt opkaldet i kø, så det kan blive besvaret af en agent.

For hvert opkald, der er aktivt, er en forekomst af flowkørsel også aktiv, indtil opkaldet afsluttes, hvilket resulterer i samtidige udførelser af flows.

Hver forekomst af flowudførelse giver isoleret miljø for data / tilstand, der er knyttet til flowet og der ved opkaldet.

I hele opkaldets livscyklus gør flow det også muligt at reagere på bestemte hændelser, der sker, og håndtere dem – f.eks. når et opkald bliver besvaret af en agent, kan en hændelseshandler udløse et pop-op-vindue på skærmen i grænsefladen på agentskrivebordet.

Du kan finde flere oplysninger om Webex CC Flow under 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.

Understøttelse af virtuel agent

Flow leverer en aktivitet til overdragelse af interaktionen til en virtuel agent, der er forudkonfigureret i Webex Control Hub.

Når opkaldet er forbundet til en virtuel agent, giver det brugeren en samtalebaseret IVR oplevelse, og aktiviteten afsluttes enten med, at opkaldet afsluttes, eller med at opkaldet eskaleres til en agent.

I tilfælde af eskalering kan flowet konfigureres til at sætte opkaldet i kø, som derefter besvares af en agent.

Indgående digitale interaktioner

Til e-mail- og meddelelseskanaler for indgående interaktioner bruger Webex CC Webex Connect til klargøring af aktiverne, flow til at håndtere de indgående interaktioner og derefter dirigere interaktionen til Webex CC, når Webex Connect-flowet eksplicit sætter interaktionen i kø, så den kan håndteres af en agent.

Figur 2 illustrerer indtagelsen af e-mail, meddelelsesinteraktioner i Webex CC.

Virtual Agent / BOT-integrationer

For interaktioner med e-mail og messaging / sociale kanaler konfigureres de virtuelle agent/BOT-behandlinger i Webex Connect-flowet.

Som det er tilfældet med Virtual Agents for Voice, sættes interaktionen i kø og distribueres til en agent, hvis BOT-behandlingen ender med at eskalere som resultat.

Valg af agent

Køer i Webex CC understøtter følgende agentudvælgelsesalgoritmer:

• Agentruter, der har været længst tilgængelig

• Fagbaseret routing

  • Længst tilgængelig agent (LAA)

  • Bedste tilgængelige agent (BAA)

Agenter er knyttet til køerne gennem Teams.

En kø kan tildeles flere opkaldsdistributionsgrupper (hvor hver gruppe har et eller flere teams) på en sekventiel måde med konfigureret ventetid på, at opkaldsdistributionsgruppen føjes til køen, så søgeområdet for en matchende agent udvides til flere opkaldsdistributionsgrupper, efterhånden som tiden skrider frem.

For fagbaseret distribution vælges en agent blandt de fagkrav, der matcher agenter, der er knyttet til køen, baseret på LAA- eller BAA-konfiguration.

Tale-/telefonispecifikke ekstra funktioner

Agentbaseret routing (kun for tale-/telefonikanaler)

Webex CC Flow kan ved hjælp af aktiviteten QueueToAgent distribuere interaktioner direkte til den valgte agent baseret på agent-id'et.

Hvis agenten ikke er tilgængelig til at håndtere interaktioner, kan interaktionen parkeres i en agentspecifik kø og vente på, at agenten bliver tilgængelig

Avancerede køoplysninger

Webex CC Flow kan ved hjælp af aktiviteten GetQueueInfo hente oplysninger i realtid for en kø, f.eks. position i kø (PIQ), estimeret ventetid (EWT), antal agenter, der er tilgængelige i køen, og kan bruges til at beslutte, om kontakten skal sættes i kø eller ej.

Hilsen tilbagekald

Webex CC Flow giver ved hjælp af aktivitetstilbagekald kunden mulighed for at afbryde forbindelsen til opkaldet, samtidig med at positionen i køen bevares, og modtage et tilbagekald, når den virtuelle interaktion i køen dirigeres til en agent.

Håndtering af overløb

Webex CC understøtter håndtering af overløb ved hjælp af kapacitetsbaserede teams (CBT).

CBT er som et almindeligt team med en kapacitet og et tilknyttet eksternt DN, der betjener denne kapacitet. Det kan konfigureres sammen med andre teams i køopkaldsdistributionscyklusserne.

Normalt konfigureres dette som den sidste cyklus, så den fungerer som et overløb, hvis der ikke er nogen agent tilgængelig, selv efter at alle de konfigurerede opkaldsdistributionsgrupper ikke kan finde en tilgængelig matchende agent til håndtering af interaktionen.

Agent Desktop Operations

Når en agent logger på Webex CC Agent Desktop, angiver agenten et telefonnummer, som indgående opkald til agenten kan forbindes til. Det kan være en PSTN-telefon, en mobiltelefon eller et lokalnummer, hvis agenten er en Cisco Webex Calling bruger.

Bemærk, at dette nummer skal være et gyldigt telefonnummer, som opkald kan viderestilles til. Hvis dette ikke er tilfældet, kan agenten ikke modtage indgående opkald.

Baseret på den type interaktion, som agenten håndterer, giver widgets på agentskrivebordet mulighed for at udføre bestemte mediekontrolhandlinger.

Når et opkald f.eks. er besvaret, kan agenten udføre følgende handlinger i forbindelse med opkaldet.

• Sæt opkaldet på hold

• Initiere konsulentopkald og

  • Omstille opkaldet til et andet telefonnummer (f.eks. agentens telefonnummer)/indgangspunkt

  • Sæt en anden agent i konference for opkaldet

• Omstil opkaldet til en anden kø

• Afslutte opkaldet

Agentcomputer giver administratorer mulighed for at tilføje brugerdefinerede widgets der ved at udvide skrivebordsfunktionerne og gøre det til en samlet samling widgets, som agenter skal bruge for at få deres arbejde udført på en effektiv måde.

Skrivebordsarkitektur

Agentskrivebord er et mikrofrontend-baseret enkeltsidet program, der er vært for widgets, der er bygget på basis af webkomponentarkitektur. Alle standard / lager widgets er drevet af data, der hentes af API'er eller server side push mekanismer.

Disse er typisk asynkrone API'er, hvor svaret på en aktivering kommer til skrivebordet via en WebSocket-forbindelse.

Webex CC-Agent Desktop godkender brugere med Cisco Common Identity (CI), og tokenet sendes videre til alle API aktiveringer. Også for brugerdefinerede widgets, baseret på godkendelsesmodellen, giver det en single sign-on-oplevelse til agenter, hvis den brugerdefinerede widgets godkendelsesmodel er integreret med CI.

Når en agent er en del af en interaktion, sendes alle opdateringer til denne interaktionstilstand eller tilknyttede data til skrivebordet via WebSocket-forbindelsen.

Skrivebordets robusthed over for tilslutningsmuligheder og ventetid

Det asynkrone API- og serverside-push muliggør skalering og ethvert forbindelsestab til WebSocket-grænsefladen registreres, og skrivebordet forsøger at oprette forbindelse igen og logge på igen.

Figur 2 illustrerer agentskrivebordsarkitekturen i Webex CC.

Onboarding af kunder

Webex Control Hub er den primære grænseflade, der bruges af partnere og kunder til at onboarde kunder og aktivere eller konfigurere funktioner.

Når organisations- og kontaktcenterfunktionerne er klargjort i Control Hub, udløser det et workflow i Webex CC, som udfører resten af trinnene i klargøringen af alle kontaktcenterfunktioner i henhold til de tilbud, kunden har valgt.

Al klargøring af kontaktcentre udføres ved hjælp af et BPM-arbejdsprocesprogram, der muliggør en deklarativ måde at definere de involverede trin på og gør hele provisioneringstrinnene modstandsdygtige over for fejl og sikrer dataintegriteten.

Figur 1 illustrerer provisioneringsarbejdsgangen i Webex CC.

Konfigurationsobjekter

De vigtigste konfigurationsobjekter i Webex CC, der er omfattet af en organisation, er:

Sted

Sted betyder en placering, hvor et eller flere teams, brugere (agenter/supervisorer) er placeret.

Alle brugere og teams skal tilhøre et websted.

Team

En gruppe brugere. Teams bruges til at distribuere interaktioner til agenter via køer.

Hvert team skal tilhøre et websted.

Agenter

Brugere, der kan logge på Agent Desktop og håndtere interaktioner på tværs af medietyper, der er konfigureret i Webex CC.

Supervisorer

Supervisorer tildeles teams og kan overvåge/coache agenten og have adgang til teamniveaustatus og agentstatistikker for dem, der hører til de teams, som supervisoren er tildelt.

Kø

En kø er en logisk enhed, hvor interaktioner kan ventes på, at agenter er tilgængelige, som derefter distribueres til agenten.

Køer knyttes til teams som søgeområdet for agenter med mulighed for at udvide søgeområdet baseret på den forløbne tidsgrænse ved at føje andre teams til søgeområdet.

Entrypoint

Indgangspunkt er en logisk enhed, der repræsenterer indgangspunktet for interaktioner, der kommer ind i Webex CC. For telefoni er dette primært knyttet til det telefonnummer, som opkald ankommer til, og for e-mail/messaging-kanaler peger indgangspunktet på aktivkonfiguration i Webex Connect.

Flow

Det flow, der er knyttet til indgangspunktet (via distributionsstrategi), som bestemmer de trin, der er involveret i håndtering af interaktioner.

For ikke-telefonikanaler (e-mail, beskeder/sociale medier) vælges Flow som en del af aktivkonfigurationen i Webex Connect.

Adgangskontrol for kontaktcentre med flere steder

Webex CC-administratorer kan konfigurere brugerprofiler med adgangsrettigheder til bestemte steder, teams, køer og indgangspunkter. På grund af webstedernes og holdenes hierarkiske karakter er det desuden kun de teams eller den dato, der vedrører holdene, der tilhører disse websteder eller en eksplicit specificeret delmængde af sådanne teams, der kan tilgås af brugeren, når der er givet adgang til bestemte websteder.

For køer og indgangspunkter er de globale på organisationsniveau, så for forskellige geografiske placeringer (steder, hvor bestemte agenter og teams er placeret) kan der konfigureres separate indgangspunkter og køer, og supervisorer/brugere kan få adgang til de objekter, der er relevante for bestemte websteder.

Figur 2 illustrerer de centrale konfigurationsobjekter og den brugerprofil, der refererer til disse objekter.

Ud over at begrænse adgangen til disse enheder kan Webex CC-administratorer styre de specifikke funktioner/moduler, som en bruger kan få adgang til i administrationsgrænsefladen, og derved have brugere med administrations-/konfigurationsrettigheder til bestemte enheder samt sektioner/funktioner i Webex CC-administrationsgrænsefladen.

Integrerede skrivebordsconnectorer: CRM-program som den primære grænseflade

I denne driftstilstand logger agenten på CRM-konsollen som det primære program.

Webex CC er et integreret program (også kaldet et integreret skrivebordsprogram eller en integreret softphone), som primært bruges til at logge på kontaktcentret og modtage Webex CC-dirigerede kontaktcenterinteraktioner.

Ved modtagelse af et opkald eller en samtaleanmodning udfører CRM-integrationen følgende handlinger på CRM-konsollen

• Pop op-skærmbilledet til kundeposten, der er knyttet til ANI, eller andre tilknyttede opkaldsdata.

• Bogfør opkaldsmetadata som aktivitetsnoter i kundeposten

• Tillad agenten at "klikke for at ringe" ved at klikke på kontakten i CRM og starte et udgående opkald til kunden

• Bogføring af opkaldsposter i CRM-rapporteringstabellerne for primær rapportering på CRM.

• Indeholder den fulde funktionalitet af kontrolelementerne Agent Desktop og opkald (integreret og minificeret version af skrivebordsappen)

Den primære integrationstilstand med CRM'erne er ved at integrere Webex CC Desktop-program i en separat iFrame.

Desuden kører Webex CC Desktop-programmet en brugerdefineret konsolløs widget (ingen brugergrænseflade) kører i baggrunden, som interagerer med det underliggende CRM-system for at udføre automatiserede handlinger på vegne af agenten.

Interaktionerne drives af to SDK'er, som den konsolløse widget bruger.

• Webex CC Desktop JS SDK: Dette er JavaScript SDK'et, der leveres af Webex CC til registrering af hændelseslyttere til agent- og kontakthandlinger.

• CRM JS SDK: Dette er det CRM-klient-SDK, der gælder pr. CRM, der abstraherer REST API opkald med CRM. For eksempel bruges det CTI JS-bibliotek, der leveres af Salesforce, til salgsstyrke til at udføre handlinger og lytte efter hændelser inde i CRM.

Figur 1 illustrerer CRM-integrerede Webex CC-skrivebords- og connectorarkitektur

Webex CC understøtter følgende CRM-løsninger til ovennævnte integration:

• Salesforce

• ServiceNu

• Microsoft Dynamics 365

• Zendesk

• Freshdesk

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

Du kan finde flere oplysninger om konfiguration af Webex CC-skrivebordslayouts til aktivering af CRM-connectoren, funktionssæt og ændringslogfiler ved at besøge https://github.com/CiscoDevNet/webex-contact-center-crm-integrationshttps://github.com/CiscoDevNet/webex-contact-center-crm-integrations.

Global tilgængelighed af CRM-connectorer

CRM Connectors er tilgængelige i alle geografiske områder og områder, hvor Webex CC fungerer.

Elastisk skala og ydeevne

Webex CC er vært for den brugerdefinerede widget, der muliggør tovejskommunikation mellem CRM-applikationen og Webex CC-skrivebordet i AWS CloudFront CDN, hvilket sikrer høj tilgængelighed af widget-AWS på tværs af tilgængelighedszoner og regioner.

Al CRM-integrationsspecifik beregning sker i den browser, hvor agenter bruger CRM-programmet med Webex CC Desktop integreret i CRM-programmet.

Sikkerhed

CRM-connectorerne aktiveres via Webex CC-agentskrivebordslayoutet, og valgfrie parametre overføres via skrivebordslayoutet til widgetten for at slå funktioner til og fra.

Hvis du f.eks. vil aktivere widgetten Salesforce-handlinger, kan administratoren aktivere parameterindstillingen for skrivebordslayoutparameteren sfdcWidgetEnabled til true.

Installation af pakke

Hvis integrationen skal fungere tovejs, skal CRM-konsollen have det integrerede program installeret. Dette er for at understøtte indlæsning af Desktop-applikationen inde i en iFrame.

Alle Desktop Embedded-connectorer er tilgængelige på CRM-markedspladsen.

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/

Installationen af markedspladsprogrammet aktiverer de nødvendige plug-ins og importerer de nødvendige XML-filer til CRM-konsollen for at understøtte rapportering af opkaldsposter på CRM-systemet.

Flowintegrationer via HTTP-connectorer i IVR

Webex CC Flow builder understøtter tovejsdatastrømme mellem Webex CC og CRM-systemet ved hjælp af HTTP-connectorer Webex, der er konfigureret i Control Hub og brugt på Webex CC Flow.

Disse bruges primært til personalisering inden for stemmeinteraktioner og tilpasset routing inden for IVR.

Som standard understøtter Webex CC Salesforce HTTP Connector på Control Hub. De andre CRM-connectorer kan tilføjes som brugerdefinerede connectorer på Webex Control Hub.

Du kan finde flere oplysninger om HTTP-connectorerne på https://github.com/CiscoDevNet/webex-contact-center-crm-integrations.

IVR HTTP-forbindelser:

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

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

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

Stemmeinfrastruktur på Edge

Voice Edge-komponenterne gør det muligt for SIP-trunks fra kundenetværk/PSTN-operatører at terminere, og dette er aktiveret baseret på hvidlistede IP'er, der har tilladelse til at oprette forbindelse til edge-komponenterne.

Beregn infrastruktursikkerhed

Webex CC-beregningsinstanser klargøres i AWS, og tjenester kører som pods i Kubernetes-klyngen, som har flere navneområder, og adgangen til hvert navneområde er begrænset med separate legitimationsoplysninger.

Al klargøring af infrastruktur udføres ved hjælp af kode - ingen manuelle trin - og ingen af legitimationsoplysningerne kan tilgås manuelt.

Der er et centralt legitimationslager med specifikke stier konfigureret til specifikt sæt tjenester / teams, og adgangen til selve legitimationslageret er begrænset og konfigureret som hemmeligheder i build- og implementeringssystemerne.

Ingen af infrastrukturkomponenterne / tjenesterne er direkte eksponeret uden for AWS VPC, og kun offentligt eksponerede grænseflader er API'er og WebSocket-servere, der styres og administreres ved hjælp af api-gateway,

Derudover er der visse interne systemer og grænseflader, der bruges af udviklere, og som bruges til visning af logfiler, målepunkter, implementeringsoplysninger, buildstatus og testresultater, som er sikret ved hjælp af roller og grupper og integreret med Ciscos interne godkendelsessystemer.

Godkendelse og autorisation af brugergrænseflader

Alle brugergrænseflader, der bruges af forskellige kontaktcenterbrugere (agenter, supervisorer, administratorer, analytikere), er beskyttet af Cisco Common Identity-baserede OAuth-flows (ihændehavertokengodkendelse).

Godkendelsen udføres ved hjælp af roller for den bruger, der har hentet tokenet, og områder, der er tildelt tokenet.

Data i transit

Ingen af grænsefladerne i den anvendte tjeneste-/infrastrukturkomponent er direkte eksponeret for ekstern indgående trafik.

Vælg tjenester med http-API'er eksponerer disse grænseflader via en gateway, og al indgående https (inklusive dem fra WebSocket) afsluttes i ALB, og intern trafik via http dirigeres til tjenesterne.

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

Inde i VPC er den interne kommunikation mellem tjenester - over http / brugerdefineret TCP-protokol - over almindelig TCP stikkontakt.

Inaktive data

Alle data, der gemmes, krypteres på lagerlaget. Desuden er de datalagre, der er uden for VPC, beskyttet og adgangskontrol og autorisationer med legitimationsoplysninger sikkert gemt og administreret i et hemmeligt lager.

Figur 1 illustrerer datastrøms- og sikkerhedsmodellen for transit såvel som i hvile.

Slutbrugerens PII-data

Webex CC Flow, som er den programmatiske controller til håndtering af interaktioner, kan bruges til at indsamle brugerdata, som kan tildeles flowvariabler, der er specielt mærket som 'Indeholder følsomme data'. Værdierne for sådanne data krypteres, og ingen tjenester i transitstien for dataene har adgang til disse data.

Desuden bevares sådanne data aldrig i Webex CC-rapporteringsdatalager, og logfilerne / messaging-infrastrukturen vil have krypterede data, og klare tekstdata gemmes ikke nogen steder i Webex CC.

Kontaktcenteragent/supervisor-PII-data

De brugerrelaterede data for kontaktcentret redigeres i logfiler, men er tilgængelige for dataanalyse og visualisering i Webex CC-datalageret.

Faktorer for skala

For Webex CC er de faktorer, der påvirker skalaen:

• Samtidig antal agenter logget på

• Samtidig antal igangværende interaktioner

  • Handlinger, der udføres på disse interaktioner

• Samtidig antal handlinger, som supervisorer/agenter udfører uden for håndteringen af interaktionerne

• Mængden af genererede og vedvarende data

Arkitektoniske aspekter, der muliggør skalering

De principper, som Webex CC er baseret på, gør det muligt for løsningen at skalere dynamisk efter behov inden for de grænser, der håndhæves af den infrastruktur, der leveres til de forskellige tjenester og platformskomponenter.

Hændelsesdrevet arkitektur

Tjenesterne i Webex CC kommunikerer ved hjælp af meddelelser, og processen til behandling af kritiske meddelelser involverer ingen blokerende IO-handlinger, og den tilstand, der kræves til behandling af meddelelser, er lokaliseret til forekomsten af den tjeneste, der behandler meddelelsen.

Statsløse tjenester (eller eksternaliseret stat)

Statsløse tjenester muliggør elasticitet ved nemt at tilføje/fjerne yderligere forekomster af tjenesterne. Der er visse tjenester, der i sagens natur er statslige, og de har eksternaliseret statsbutik, og infrastrukturen understøtter også dynamiske ændringer i antallet af forekomster af sådanne tjenester med automatisk rebalancering / statsoverførsel / lokalisering af staten til den instans, der har brug for staten.

Elastisk infrastruktur

Alle tjenester kører i Kubernetes, og infrastrukturen aka Kubernetes-noder skaleres automatisk baseret på brugen, og dette muliggør dynamisk tilføjelse af flere beregningsnoder op til en maksimal høj tærskel, der er forudkonfigureret.

Belastningsprojektion og regelmæssig validering

Alle tjenester benchmarkes for ydeevneegenskaberne, og skaleringsmønsteret valideres på serviceniveau.

Yderligere kontinuerlig validering, spidsbelastning og udholdenhedstest udføres med testparametre, der er indstillet til forventet vækst i de skalapåvirkende attributter, hvilket gør det muligt at identificere flaskehalse, planlægge at opdatere den høje tærskel for infrastrukturressourceforbrug og være klar til spildagen.

Telefoni-

For telefoni bestemmes håndteringen af indgående taleopkald af, hvordan opkaldet er kommet ind i kontaktcenteret (se Indtrængningsmekanismer nedenfor) og af det Webex CC-flow, der er knyttet til indgangspunktet.

Opkaldet besvares, og der udføres yderligere handlinger i henhold til Webex CC Flow-definitionen – som er en programmatisk repræsentation af de handlinger, der skal udføres, mens opkaldet håndteres, enten før det sættes i kø og dirigeres til en agent, eller selve flowet kan håndtere opkaldet uden overførsel til en agent.

Flow Builder i Webex CC giver udviklere mulighed for at definere flowet og tildele det til det indgangspunkt, via hvilket opkaldet ankommer til Webex CC.

Disse konfigurationsobjekter og deres anvendelse er dækket i Konfigurationsenheder.

Flere oplysninger om Flow Builder er dækket i det kommende afsnit om IVR System.

E-mail og beskeder

Fra Webex CC-perspektiv leverer Webex Connect indgående og udgående funktioner til alle digitale kanaler - e-mail, meddelelseskanaler, som slutbrugere kan bruge til at kontakte kontaktcenter.

Webex Connect Flow

• Bestemmer håndteringen af sådanne interaktioner, indtil interaktionerne er sat i kø og distribueret til agenter. Dette omfatter automatisk håndtering og BOT-behandlinger for alle former for messaging og e-mail-interaktioner.

• Anvender forretningslogik på indgående interaktion.

• Håndterer kontakt før kø.

• Flow selv kan håndtere interaktionen uden overførsel til live agent.

De meddelelseskanaler, der understøttes af Webex CC, er:

• Web App / Mobil App Chat

• WhatsApp

• Facebook Messenger

• Sms

De e-mailkanaler, der understøttes af Webex CC, er:

• Gmail

• Office365

Indtrængningsmekanismer

Dette afsnit dækker de mekanismer, hvormed en interaktion kan komme ind i Webex CC. Baseret på medietypen er de mekanismer, hvormed en interaktion når Webex CC, forskellige.

Inden for telefoni er der f.eks. behov for fysisk infrastrukturprovisionering for at aktivere PSTN-forbindelse, konfiguration af telefonnumre og routing af opkald til Webex CC.

For e-mail-/meddelelseskanaler skal indgående konfiguration udføres i Webex Connect, og det involverer klargøring af e-mail-/messaging-konto og konfiguration af Webex Connect-flow.

Indgående stemme

I forbindelse med taleopkald er det typisk sådan, at brugerne ringer til et PSTN-telefonnummer, som derefter forbindes til kontaktcentret. Fra et indgående perspektiv kræver dette en mekanisme til at dirigere opkald fra PSTN til Webex CC.

Figur 1 viser indtagelse af taleopkald til Webex CC.

Voice Ingress Services i Webex CC udfører tredjepartsopkaldsstyring ved hjælp af SIP og besvarer det indgående opkald samt udfører overførsels-, konference- og andre opkaldskontrolhandlinger.

Det logiske indgangspunkt for opkald i Webex CC er konfigurationsenheden med navnet "Indgangspunkt". I forbindelse med taleindtrængning er nøglekonfigurationen for indgangspunktet det telefonnummer, der er knyttet til det, hvilket typisk er et gyldigt PSTN-telefonnummer, der er hentet fra den valgte PSTN-udbyder.

Dette gør det muligt at registrere indgående opkald på telefonnummeret, knytte opkaldet til indgangspunktet og bruge andre konfigurationsparametre for indgangspunktet til at håndtere opkaldet i henhold til den Webex CC Flow-definition, der skal udløses for interaktionen.

Bemærk:

Du kan finde flere oplysninger om PSTN-forbindelsesindstillingerne på 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.

Skalerbarhed og tilgængelighed af Voice Edge-infrastruktur

Webex CC VPOP-infrastrukturen omfatter redundante par SIP SBC'er, der sikrer høj tilgængelighed, og flere SBC'er kan tilføjes for at skalere de samtidige opkaldsmængder, der skal understøttes.

Det maksimale antal samtidige opkald, som VPOP kan håndtere, afhænger af antallet af SBC'er, der kører, og som opkald sendes til.

For geografisk redundans – et net af VPOP SBC med sammenkoblinger på tværs af flere par på tværs af regioner understøttes.

For taleindtrængningstjenester er de horisontalt skalerbare til at håndtere et stigende antal samtidige taleopkald, der skal indtages til Webex CC.

Sikkerhedsovervejelser i forbindelse med voice edge-infrastruktur

Nedenstående tabel indeholder oplysninger om tilslutningsmulighederne til Voice Edge-infrastrukturen.

For flere detaljer, besøg 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-system

Alle taleopkald, der kommer til et telefonnummer, der er tilknyttet et indgangspunkt, bliver besvaret af Webex CC, og udførelse af et Webex CC-flow, der er knyttet til indgangspunktet, går i gang.

Webex CC Flow Builder leverer programmeringskonstruktioner/operatorer og funktionelle blokke, kaldet aktiviteter, så administratorer eller andre, der designer og implementerer den IVR logik, kan kombinere disse byggesten og oprette Flow-definitionen.

De programmeringskonstruktioner, som Flow understøtter, er:

• Rapporterings- og indstillingsvariabler – tilstand, der er knyttet til en flowudførelse

  • Pebble Expressions for at indstille værdien af variabler

• Betinget kontrol

• Looping - ved hjælp af Conditionals og Go To (evne til at kæde aktiviteter sammen)

• Kald REST-API'er

• Parse Data - JSON, TOML, XML bruges typisk til at analysere API svar.

• Komponere aktiviteter

Et repræsentativt sæt aktiviteter, som Flow leverer, er: Afspil beskeder Indsaml brugerdata Omstille opkaldet til en anden destination/et andet telefonnummer Send opkaldet til en virtuel agent Sæt opkaldet i kø, så det kan blive besvaret af en agent.

For hvert opkald, der er aktivt, er en forekomst af flowkørsel også aktiv, indtil opkaldet afsluttes, hvilket resulterer i samtidige udførelser af flows.

Hver forekomst af flowudførelse giver isoleret miljø for data / tilstand, der er knyttet til flowet og der ved opkaldet.

I hele opkaldets livscyklus gør flow det også muligt at reagere på bestemte hændelser, der sker, og håndtere dem – f.eks. når et opkald bliver besvaret af en agent, kan en hændelseshandler udløse et pop-op-vindue på skærmen i grænsefladen på agentskrivebordet.

Du kan finde flere oplysninger om Webex CC Flow under 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.

Understøttelse af virtuel agent

Flow leverer en aktivitet til overdragelse af interaktionen til en virtuel agent, der er forudkonfigureret i Webex Control Hub.

Når opkaldet er forbundet til en virtuel agent, giver det brugeren en samtalebaseret IVR oplevelse, og aktiviteten afsluttes enten med, at opkaldet afsluttes, eller med at opkaldet eskaleres til en agent.

I tilfælde af eskalering kan flowet konfigureres til at sætte opkaldet i kø, som derefter besvares af en agent.

Indgående digitale interaktioner

Til e-mail- og meddelelseskanaler for indgående interaktioner bruger Webex CC Webex Connect til klargøring af aktiverne, flow til at håndtere de indgående interaktioner og derefter dirigere interaktionen til Webex CC, når Webex Connect-flowet eksplicit sætter interaktionen i kø, så den kan håndteres af en agent.

Figur 2 illustrerer indtagelsen af e-mail, meddelelsesinteraktioner i Webex CC.

Virtual Agent / BOT-integrationer

For interaktioner med e-mail og messaging / sociale kanaler konfigureres de virtuelle agent/BOT-behandlinger i Webex Connect-flowet.

Som det er tilfældet med Virtual Agents for Voice, sættes interaktionen i kø og distribueres til en agent, hvis BOT-behandlingen ender med at eskalere som resultat.

Valg af agent

Køer i Webex CC understøtter følgende agentudvælgelsesalgoritmer:

• Agentruter, der har været længst tilgængelig

• Fagbaseret routing

  • Længst tilgængelig agent (LAA)

  • Bedste tilgængelige agent (BAA)

Agenter er knyttet til køerne gennem Teams.

En kø kan tildeles flere opkaldsdistributionsgrupper (hvor hver gruppe har et eller flere teams) på en sekventiel måde med konfigureret ventetid på, at opkaldsdistributionsgruppen føjes til køen, så søgeområdet for en matchende agent udvides til flere opkaldsdistributionsgrupper, efterhånden som tiden skrider frem.

For fagbaseret distribution vælges en agent blandt de fagkrav, der matcher agenter, der er knyttet til køen, baseret på LAA- eller BAA-konfiguration.

Tale-/telefonispecifikke ekstra funktioner

Agentbaseret routing (kun for tale-/telefonikanaler)

Webex CC Flow kan ved hjælp af aktiviteten QueueToAgent distribuere interaktioner direkte til den valgte agent baseret på agent-id'et.

Hvis agenten ikke er tilgængelig til at håndtere interaktioner, kan interaktionen parkeres i en agentspecifik kø og vente på, at agenten bliver tilgængelig

Avancerede køoplysninger

Webex CC Flow kan ved hjælp af aktiviteten GetQueueInfo hente oplysninger i realtid for en kø, f.eks. position i kø (PIQ), estimeret ventetid (EWT), antal agenter, der er tilgængelige i køen, og kan bruges til at beslutte, om kontakten skal sættes i kø eller ej.

Hilsen tilbagekald

Webex CC Flow giver ved hjælp af aktivitetstilbagekald kunden mulighed for at afbryde forbindelsen til opkaldet, samtidig med at positionen i køen bevares, og modtage et tilbagekald, når den virtuelle interaktion i køen dirigeres til en agent.

Håndtering af overløb

Webex CC understøtter håndtering af overløb ved hjælp af kapacitetsbaserede teams (CBT).

CBT er som et almindeligt team med en kapacitet og et tilknyttet eksternt DN, der betjener denne kapacitet. Det kan konfigureres sammen med andre teams i køopkaldsdistributionscyklusserne.

Normalt konfigureres dette som den sidste cyklus, så den fungerer som et overløb, hvis der ikke er nogen agent tilgængelig, selv efter at alle de konfigurerede opkaldsdistributionsgrupper ikke kan finde en tilgængelig matchende agent til håndtering af interaktionen.

Agent Desktop Operations

Når en agent logger på Webex CC Agent Desktop, angiver agenten et telefonnummer, som indgående opkald til agenten kan forbindes til. Det kan være en PSTN-telefon, en mobiltelefon eller et lokalnummer, hvis agenten er en Cisco Webex Calling bruger.

Bemærk, at dette nummer skal være et gyldigt telefonnummer, som opkald kan viderestilles til. Hvis dette ikke er tilfældet, kan agenten ikke modtage indgående opkald.

Baseret på den type interaktion, som agenten håndterer, giver widgets på agentskrivebordet mulighed for at udføre bestemte mediekontrolhandlinger.

Når et opkald f.eks. er besvaret, kan agenten udføre følgende handlinger i forbindelse med opkaldet.

• Sæt opkaldet på hold

• Initiere konsulentopkald og

  • Omstille opkaldet til et andet telefonnummer (f.eks. agentens telefonnummer)/indgangspunkt

  • Sæt en anden agent i konference for opkaldet

• Omstil opkaldet til en anden kø

• Afslutte opkaldet

Agentcomputer giver administratorer mulighed for at tilføje brugerdefinerede widgets der ved at udvide skrivebordsfunktionerne og gøre det til en samlet samling widgets, som agenter skal bruge for at få deres arbejde udført på en effektiv måde.

Skrivebordsarkitektur

Agentskrivebord er et mikrofrontend-baseret enkeltsidet program, der er vært for widgets, der er bygget på basis af webkomponentarkitektur. Alle standard / lager widgets er drevet af data, der hentes af API'er eller server side push mekanismer.

Disse er typisk asynkrone API'er, hvor svaret på en aktivering kommer til skrivebordet via en WebSocket-forbindelse.

Webex CC-Agent Desktop godkender brugere med Cisco Common Identity (CI), og tokenet sendes videre til alle API aktiveringer. Også for brugerdefinerede widgets, baseret på godkendelsesmodellen, giver det en single sign-on-oplevelse til agenter, hvis den brugerdefinerede widgets godkendelsesmodel er integreret med CI.

Når en agent er en del af en interaktion, sendes alle opdateringer til denne interaktionstilstand eller tilknyttede data til skrivebordet via WebSocket-forbindelsen.

Skrivebordets robusthed over for tilslutningsmuligheder og ventetid

Det asynkrone API- og serverside-push muliggør skalering og ethvert forbindelsestab til WebSocket-grænsefladen registreres, og skrivebordet forsøger at oprette forbindelse igen og logge på igen.

Figur 2 illustrerer agentskrivebordsarkitekturen i Webex CC.

Onboarding af kunder

Webex Control Hub er den primære grænseflade, der bruges af partnere og kunder til at onboarde kunder og aktivere eller konfigurere funktioner.

Når organisations- og kontaktcenterfunktionerne er klargjort i Control Hub, udløser det et workflow i Webex CC, som udfører resten af trinnene i klargøringen af alle kontaktcenterfunktioner i henhold til de tilbud, kunden har valgt.

Al klargøring af kontaktcentre udføres ved hjælp af et BPM-arbejdsprocesprogram, der muliggør en deklarativ måde at definere de involverede trin på og gør hele provisioneringstrinnene modstandsdygtige over for fejl og sikrer dataintegriteten.

Figur 1 illustrerer provisioneringsarbejdsgangen i Webex CC.

Konfigurationsobjekter

De vigtigste konfigurationsobjekter i Webex CC, der er omfattet af en organisation, er:

Sted

Sted betyder en placering, hvor et eller flere teams, brugere (agenter/supervisorer) er placeret.

Alle brugere og teams skal tilhøre et websted.

Team

En gruppe brugere. Teams bruges til at distribuere interaktioner til agenter via køer.

Hvert team skal tilhøre et websted.

Agenter

Brugere, der kan logge på Agent Desktop og håndtere interaktioner på tværs af medietyper, der er konfigureret i Webex CC.

Supervisorer

Supervisorer tildeles teams og kan overvåge/coache agenten og have adgang til teamniveaustatus og agentstatistikker for dem, der hører til de teams, som supervisoren er tildelt.

Kø

En kø er en logisk enhed, hvor interaktioner kan ventes på, at agenter er tilgængelige, som derefter distribueres til agenten.

Køer knyttes til teams som søgeområdet for agenter med mulighed for at udvide søgeområdet baseret på den forløbne tidsgrænse ved at føje andre teams til søgeområdet.

Entrypoint

Indgangspunkt er en logisk enhed, der repræsenterer indgangspunktet for interaktioner, der kommer ind i Webex CC. For telefoni er dette primært knyttet til det telefonnummer, som opkald ankommer til, og for e-mail/messaging-kanaler peger indgangspunktet på aktivkonfiguration i Webex Connect.

Flow

Det flow, der er knyttet til indgangspunktet (via distributionsstrategi), som bestemmer de trin, der er involveret i håndtering af interaktioner.

For ikke-telefonikanaler (e-mail, beskeder/sociale medier) vælges Flow som en del af aktivkonfigurationen i Webex Connect.

Adgangskontrol for kontaktcentre med flere steder

Webex CC-administratorer kan konfigurere brugerprofiler med adgangsrettigheder til bestemte steder, teams, køer og indgangspunkter. På grund af webstedernes og holdenes hierarkiske karakter er det desuden kun de teams eller den dato, der vedrører holdene, der tilhører disse websteder eller en eksplicit specificeret delmængde af sådanne teams, der kan tilgås af brugeren, når der er givet adgang til bestemte websteder.

For køer og indgangspunkter er de globale på organisationsniveau, så for forskellige geografiske placeringer (steder, hvor bestemte agenter og teams er placeret) kan der konfigureres separate indgangspunkter og køer, og supervisorer/brugere kan få adgang til de objekter, der er relevante for bestemte websteder.

Figur 2 illustrerer de centrale konfigurationsobjekter og den brugerprofil, der refererer til disse objekter.

Ud over at begrænse adgangen til disse enheder kan Webex CC-administratorer styre de specifikke funktioner/moduler, som en bruger kan få adgang til i administrationsgrænsefladen, og derved have brugere med administrations-/konfigurationsrettigheder til bestemte enheder samt sektioner/funktioner i Webex CC-administrationsgrænsefladen.

Integrerede skrivebordsconnectorer: CRM-program som den primære grænseflade

I denne driftstilstand logger agenten på CRM-konsollen som det primære program.

Webex CC er et integreret program (også kaldet et integreret skrivebordsprogram eller en integreret softphone), som primært bruges til at logge på kontaktcentret og modtage Webex CC-dirigerede kontaktcenterinteraktioner.

Ved modtagelse af et opkald eller en samtaleanmodning udfører CRM-integrationen følgende handlinger på CRM-konsollen

• Pop op-skærmbilledet til kundeposten, der er knyttet til ANI, eller andre tilknyttede opkaldsdata.

• Bogfør opkaldsmetadata som aktivitetsnoter i kundeposten

• Tillad agenten at "klikke for at ringe" ved at klikke på kontakten i CRM og starte et udgående opkald til kunden

• Bogføring af opkaldsposter i CRM-rapporteringstabellerne for primær rapportering på CRM.

• Indeholder den fulde funktionalitet af kontrolelementerne Agent Desktop og opkald (integreret og minificeret version af skrivebordsappen)

Den primære integrationstilstand med CRM'erne er ved at integrere Webex CC Desktop-program i en separat iFrame.

Desuden kører Webex CC Desktop-programmet en brugerdefineret konsolløs widget (ingen brugergrænseflade) kører i baggrunden, som interagerer med det underliggende CRM-system for at udføre automatiserede handlinger på vegne af agenten.

Interaktionerne drives af to SDK'er, som den konsolløse widget bruger.

• Webex CC Desktop JS SDK: Dette er JavaScript SDK'et, der leveres af Webex CC til registrering af hændelseslyttere til agent- og kontakthandlinger.

• CRM JS SDK: Dette er det CRM-klient-SDK, der gælder pr. CRM, der abstraherer REST API opkald med CRM. For eksempel bruges det CTI JS-bibliotek, der leveres af Salesforce, til salgsstyrke til at udføre handlinger og lytte efter hændelser inde i CRM.

Figur 1 illustrerer CRM-integrerede Webex CC-skrivebords- og connectorarkitektur

Webex CC understøtter følgende CRM-løsninger til ovennævnte integration:

• Salesforce

• ServiceNu

• Microsoft Dynamics 365

• Zendesk

• Freshdesk

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

Du kan finde flere oplysninger om konfiguration af Webex CC-skrivebordslayouts til aktivering af CRM-connectoren, funktionssæt og ændringslogfiler ved at besøge https://github.com/CiscoDevNet/webex-contact-center-crm-integrationshttps://github.com/CiscoDevNet/webex-contact-center-crm-integrations.

Global tilgængelighed af CRM-connectorer

CRM Connectors er tilgængelige i alle geografiske områder og områder, hvor Webex CC fungerer.

Elastisk skala og ydeevne

Webex CC er vært for den brugerdefinerede widget, der muliggør tovejskommunikation mellem CRM-applikationen og Webex CC-skrivebordet i AWS CloudFront CDN, hvilket sikrer høj tilgængelighed af widget-AWS på tværs af tilgængelighedszoner og regioner.

Al CRM-integrationsspecifik beregning sker i den browser, hvor agenter bruger CRM-programmet med Webex CC Desktop integreret i CRM-programmet.

Sikkerhed

CRM-connectorerne aktiveres via Webex CC-agentskrivebordslayoutet, og valgfrie parametre overføres via skrivebordslayoutet til widgetten for at slå funktioner til og fra.

Hvis du f.eks. vil aktivere widgetten Salesforce-handlinger, kan administratoren aktivere parameterindstillingen for skrivebordslayoutparameteren sfdcWidgetEnabled til true.

Installation af pakke

Hvis integrationen skal fungere tovejs, skal CRM-konsollen have det integrerede program installeret. Dette er for at understøtte indlæsning af Desktop-applikationen inde i en iFrame.

Alle Desktop Embedded-connectorer er tilgængelige på CRM-markedspladsen.

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/

Installationen af markedspladsprogrammet aktiverer de nødvendige plug-ins og importerer de nødvendige XML-filer til CRM-konsollen for at understøtte rapportering af opkaldsposter på CRM-systemet.

Flowintegrationer via HTTP-connectorer i IVR

Webex CC Flow builder understøtter tovejsdatastrømme mellem Webex CC og CRM-systemet ved hjælp af HTTP-connectorer Webex, der er konfigureret i Control Hub og brugt på Webex CC Flow.

Disse bruges primært til personalisering inden for stemmeinteraktioner og tilpasset routing inden for IVR.

Som standard understøtter Webex CC Salesforce HTTP Connector på Control Hub. De andre CRM-connectorer kan tilføjes som brugerdefinerede connectorer på Webex Control Hub.

Du kan finde flere oplysninger om HTTP-connectorerne på https://github.com/CiscoDevNet/webex-contact-center-crm-integrations.

IVR HTTP-forbindelser:

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

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

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

Stemmeinfrastruktur på Edge

Voice Edge-komponenterne gør det muligt for SIP-trunks fra kundenetværk/PSTN-operatører at terminere, og dette er aktiveret baseret på hvidlistede IP'er, der har tilladelse til at oprette forbindelse til edge-komponenterne.

Beregn infrastruktursikkerhed

Webex CC-beregningsinstanser klargøres i AWS, og tjenester kører som pods i Kubernetes-klyngen, som har flere navneområder, og adgangen til hvert navneområde er begrænset med separate legitimationsoplysninger.

Al klargøring af infrastruktur udføres ved hjælp af kode - ingen manuelle trin - og ingen af legitimationsoplysningerne kan tilgås manuelt.

Der er et centralt legitimationslager med specifikke stier konfigureret til specifikt sæt tjenester / teams, og adgangen til selve legitimationslageret er begrænset og konfigureret som hemmeligheder i build- og implementeringssystemerne.

Ingen af infrastrukturkomponenterne / tjenesterne er direkte eksponeret uden for AWS VPC, og kun offentligt eksponerede grænseflader er API'er og WebSocket-servere, der styres og administreres ved hjælp af api-gateway,

Derudover er der visse interne systemer og grænseflader, der bruges af udviklere, og som bruges til visning af logfiler, målepunkter, implementeringsoplysninger, buildstatus og testresultater, som er sikret ved hjælp af roller og grupper og integreret med Ciscos interne godkendelsessystemer.

Godkendelse og autorisation af brugergrænseflader

Alle brugergrænseflader, der bruges af forskellige kontaktcenterbrugere (agenter, supervisorer, administratorer, analytikere), er beskyttet af Cisco Common Identity-baserede OAuth-flows (ihændehavertokengodkendelse).

Godkendelsen udføres ved hjælp af roller for den bruger, der har hentet tokenet, og områder, der er tildelt tokenet.

Data i transit

Ingen af grænsefladerne i den anvendte tjeneste-/infrastrukturkomponent er direkte eksponeret for ekstern indgående trafik.

Vælg tjenester med http-API'er eksponerer disse grænseflader via en gateway, og al indgående https (inklusive dem fra WebSocket) afsluttes i ALB, og intern trafik via http dirigeres til tjenesterne.

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

Inde i VPC er den interne kommunikation mellem tjenester - over http / brugerdefineret TCP-protokol - over almindelig TCP stikkontakt.

Inaktive data

Alle data, der gemmes, krypteres på lagerlaget. Desuden er de datalagre, der er uden for VPC, beskyttet og adgangskontrol og autorisationer med legitimationsoplysninger sikkert gemt og administreret i et hemmeligt lager.

Figur 1 illustrerer datastrøms- og sikkerhedsmodellen for transit såvel som i hvile.

Slutbrugerens PII-data

Webex CC Flow, som er den programmatiske controller til håndtering af interaktioner, kan bruges til at indsamle brugerdata, som kan tildeles flowvariabler, der er specielt mærket som 'Indeholder følsomme data'. Værdierne for sådanne data krypteres, og ingen tjenester i transitstien for dataene har adgang til disse data.

Desuden bevares sådanne data aldrig i Webex CC-rapporteringsdatalager, og logfilerne / messaging-infrastrukturen vil have krypterede data, og klare tekstdata gemmes ikke nogen steder i Webex CC.

Kontaktcenteragent/supervisor-PII-data

De brugerrelaterede data for kontaktcentret redigeres i logfiler, men er tilgængelige for dataanalyse og visualisering i Webex CC-datalageret.

Faktorer for skala

For Webex CC er de faktorer, der påvirker skalaen:

• Samtidig antal agenter logget på

• Samtidig antal igangværende interaktioner

  • Handlinger, der udføres på disse interaktioner

• Samtidig antal handlinger, som supervisorer/agenter udfører uden for håndteringen af interaktionerne

• Mængden af genererede og vedvarende data

Arkitektoniske aspekter, der muliggør skalering

De principper, som Webex CC er baseret på, gør det muligt for løsningen at skalere dynamisk efter behov inden for de grænser, der håndhæves af den infrastruktur, der leveres til de forskellige tjenester og platformskomponenter.

Hændelsesdrevet arkitektur

Tjenesterne i Webex CC kommunikerer ved hjælp af meddelelser, og processen til behandling af kritiske meddelelser involverer ingen blokerende IO-handlinger, og den tilstand, der kræves til behandling af meddelelser, er lokaliseret til forekomsten af den tjeneste, der behandler meddelelsen.

Statsløse tjenester (eller eksternaliseret stat)

Statsløse tjenester muliggør elasticitet ved nemt at tilføje/fjerne yderligere forekomster af tjenesterne. Der er visse tjenester, der i sagens natur er statslige, og de har eksternaliseret statsbutik, og infrastrukturen understøtter også dynamiske ændringer i antallet af forekomster af sådanne tjenester med automatisk rebalancering / statsoverførsel / lokalisering af staten til den instans, der har brug for staten.

Elastisk infrastruktur

Alle tjenester kører i Kubernetes, og infrastrukturen aka Kubernetes-noder skaleres automatisk baseret på brugen, og dette muliggør dynamisk tilføjelse af flere beregningsnoder op til en maksimal høj tærskel, der er forudkonfigureret.

Belastningsprojektion og regelmæssig validering

Alle tjenester benchmarkes for ydeevneegenskaberne, og skaleringsmønsteret valideres på serviceniveau.

Yderligere kontinuerlig validering, spidsbelastning og udholdenhedstest udføres med testparametre, der er indstillet til forventet vækst i de skalapåvirkende attributter, hvilket gør det muligt at identificere flaskehalse, planlægge at opdatere den høje tærskel for infrastrukturressourceforbrug og være klar til spildagen.

Telefoni-

For telefoni bestemmes håndteringen af indgående taleopkald af, hvordan opkaldet er kommet ind i kontaktcenteret (se Indtrængningsmekanismer nedenfor) og af det Webex CC-flow, der er knyttet til indgangspunktet.

Opkaldet besvares, og der udføres yderligere handlinger i henhold til Webex CC Flow-definitionen – som er en programmatisk repræsentation af de handlinger, der skal udføres, mens opkaldet håndteres, enten før det sættes i kø og dirigeres til en agent, eller selve flowet kan håndtere opkaldet uden overførsel til en agent.

Flow Builder i Webex CC giver udviklere mulighed for at definere flowet og tildele det til det indgangspunkt, via hvilket opkaldet ankommer til Webex CC.

Disse konfigurationsobjekter og deres anvendelse er dækket i Konfigurationsenheder.

Flere oplysninger om Flow Builder er dækket i det kommende afsnit om IVR System.

E-mail og beskeder

Fra Webex CC-perspektiv leverer Webex Connect indgående og udgående funktioner til alle digitale kanaler - e-mail, meddelelseskanaler, som slutbrugere kan bruge til at kontakte kontaktcenter.

Webex Connect Flow

• Bestemmer håndteringen af sådanne interaktioner, indtil interaktionerne er sat i kø og distribueret til agenter. Dette omfatter automatisk håndtering og BOT-behandlinger for alle former for messaging og e-mail-interaktioner.

• Anvender forretningslogik på indgående interaktion.

• Håndterer kontakt før kø.

• Flow selv kan håndtere interaktionen uden overførsel til live agent.

De meddelelseskanaler, der understøttes af Webex CC, er:

• Web App / Mobil App Chat

• WhatsApp

• Facebook Messenger

• Sms

De e-mailkanaler, der understøttes af Webex CC, er:

• Gmail

• Office365

Indtrængningsmekanismer

Dette afsnit dækker de mekanismer, hvormed en interaktion kan komme ind i Webex CC. Baseret på medietypen er de mekanismer, hvormed en interaktion når Webex CC, forskellige.

Inden for telefoni er der f.eks. behov for fysisk infrastrukturprovisionering for at aktivere PSTN-forbindelse, konfiguration af telefonnumre og routing af opkald til Webex CC.

For e-mail-/meddelelseskanaler skal indgående konfiguration udføres i Webex Connect, og det involverer klargøring af e-mail-/messaging-konto og konfiguration af Webex Connect-flow.

Indgående stemme

I forbindelse med taleopkald er det typisk sådan, at brugerne ringer til et PSTN-telefonnummer, som derefter forbindes til kontaktcentret. Fra et indgående perspektiv kræver dette en mekanisme til at dirigere opkald fra PSTN til Webex CC.

Følgende figur illustrerer indtagelsen af taleopkald til Webex CC.

Voice Ingress Services i Webex CC udfører tredjepartsopkaldsstyring ved hjælp af SIP og besvarer det indgående opkald samt udfører overførsels-, konference- og andre opkaldskontrolhandlinger.

Det logiske indgangspunkt for opkald i Webex CC er konfigurationsenheden med navnet "Indgangspunkt". I forbindelse med taleindtrængning er nøglekonfigurationen for indgangspunktet det telefonnummer, der er knyttet til det, hvilket typisk er et gyldigt PSTN-telefonnummer, der er hentet fra den valgte PSTN-udbyder.

Dette gør det muligt at registrere indgående opkald på telefonnummeret, knytte opkaldet til indgangspunktet og bruge andre konfigurationsparametre for indgangspunktet til at håndtere opkaldet i henhold til den Webex CC Flow-definition, der skal udløses for interaktionen.

Bemærk:

Du kan finde flere oplysninger om PSTN-forbindelsesindstillingerne på 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.

Skalerbarhed og tilgængelighed af Voice Edge-infrastruktur

Webex CC VPOP-infrastrukturen omfatter redundante par SIP SBC'er, der sikrer høj tilgængelighed, og flere SBC'er kan tilføjes for at skalere de samtidige opkaldsmængder, der skal understøttes.

Det maksimale antal samtidige opkald, som VPOP kan håndtere, afhænger af antallet af SBC'er, der kører, og som opkald sendes til.

For geografisk redundans – et net af VPOP SBC med sammenkoblinger på tværs af flere par på tværs af regioner understøttes.

For taleindtrængningstjenester er de horisontalt skalerbare til at håndtere et stigende antal samtidige taleopkald, der skal indtages til Webex CC.

Sikkerhedsovervejelser i forbindelse med voice edge-infrastruktur

Nedenstående tabel indeholder oplysninger om tilslutningsmulighederne til Voice Edge-infrastrukturen.

For flere detaljer, besøg 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-system

Alle taleopkald, der kommer til et telefonnummer, der er tilknyttet et indgangspunkt, bliver besvaret af Webex CC, og udførelse af et Webex CC-flow, der er knyttet til indgangspunktet, går i gang.

Webex CC Flow Builder leverer programmeringskonstruktioner/operatorer og funktionelle blokke, kaldet aktiviteter, så administratorer eller andre, der designer og implementerer den IVR logik, kan kombinere disse byggesten og oprette Flow-definitionen.

De programmeringskonstruktioner, som Flow understøtter, er:

• Rapporterings- og indstillingsvariabler – tilstand, der er knyttet til en flowudførelse

  • Pebble Expressions for at indstille værdien af variabler

• Betinget kontrol

• Looping - ved hjælp af Conditionals og Go To (evne til at kæde aktiviteter sammen)

• Kald REST-API'er

• Parse Data - JSON, TOML, XML bruges typisk til at analysere API svar.

• Komponere aktiviteter

Et repræsentativt sæt aktiviteter, som Flow leverer, er: Afspil beskeder Indsaml brugerdata Omstille opkaldet til en anden destination/et andet telefonnummer Send opkaldet til en virtuel agent Sæt opkaldet i kø, så det kan blive besvaret af en agent.

For hvert opkald, der er aktivt, er en forekomst af flowkørsel også aktiv, indtil opkaldet afsluttes, hvilket resulterer i samtidige udførelser af flows.

Hver forekomst af flowudførelse giver isoleret miljø for data / tilstand, der er knyttet til flowet og der ved opkaldet.

I hele opkaldets livscyklus gør flow det også muligt at reagere på bestemte hændelser, der sker, og håndtere dem – f.eks. når et opkald bliver besvaret af en agent, kan en hændelseshandler udløse et pop-op-vindue på skærmen i grænsefladen på agentskrivebordet.

Du kan finde flere oplysninger om Webex CC Flow under 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.

Understøttelse af virtuel agent

Flow leverer en aktivitet til overdragelse af interaktionen til en virtuel agent, der er forudkonfigureret i Webex Control Hub.

Når opkaldet er forbundet til en virtuel agent, giver det brugeren en samtalebaseret IVR oplevelse, og aktiviteten afsluttes enten med, at opkaldet afsluttes, eller med at opkaldet eskaleres til en agent.

I tilfælde af eskalering kan flowet konfigureres til at sætte opkaldet i kø, som derefter besvares af en agent.

Indgående digitale interaktioner

Til e-mail- og meddelelseskanaler for indgående interaktioner bruger Webex CC Webex Connect til klargøring af aktiverne, flow til at håndtere de indgående interaktioner og derefter dirigere interaktionen til Webex CC, når Webex Connect-flowet eksplicit sætter interaktionen i kø, så den kan håndteres af en agent.

Følgende figur illustrerer indtagelsen af e-mail, meddelelsesinteraktioner i Webex CC.

Virtual Agent / BOT-integrationer

For interaktioner med e-mail og messaging / sociale kanaler konfigureres de virtuelle agent/BOT-behandlinger i Webex Connect-flowet.

Som det er tilfældet med Virtual Agents for Voice, sættes interaktionen i kø og distribueres til en agent, hvis BOT-behandlingen ender med at eskalere som resultat.

Valg af agent

Køer i Webex CC understøtter følgende agentudvælgelsesalgoritmer:

• Agentruter, der har været længst tilgængelig

• Fagbaseret routing

  • Længst tilgængelig agent (LAA)

  • Bedste tilgængelige agent (BAA)

Agenter er knyttet til køerne gennem Teams.

En kø kan tildeles flere opkaldsdistributionsgrupper (hvor hver gruppe har et eller flere teams) på en sekventiel måde med konfigureret ventetid på, at opkaldsdistributionsgruppen føjes til køen, så søgeområdet for en matchende agent udvides til flere opkaldsdistributionsgrupper, efterhånden som tiden skrider frem.

For fagbaseret distribution vælges en agent blandt de fagkrav, der matcher agenter, der er knyttet til køen, baseret på LAA- eller BAA-konfiguration.

Tale-/telefonispecifikke ekstra funktioner

Agentbaseret routing (kun for tale-/telefonikanaler)

Webex CC Flow kan ved hjælp af aktiviteten QueueToAgent distribuere interaktioner direkte til den valgte agent baseret på agent-id'et.

Hvis agenten ikke er tilgængelig til at håndtere interaktioner, kan interaktionen parkeres i en agentspecifik kø og vente på, at agenten bliver tilgængelig

Avancerede køoplysninger

Webex CC Flow kan ved hjælp af aktiviteten GetQueueInfo hente oplysninger i realtid for en kø, f.eks. position i kø (PIQ), estimeret ventetid (EWT), antal agenter, der er tilgængelige i køen, og kan bruges til at beslutte, om kontakten skal sættes i kø eller ej.

Hilsen tilbagekald

Webex CC Flow giver ved hjælp af aktivitetstilbagekald kunden mulighed for at afbryde forbindelsen til opkaldet, samtidig med at positionen i køen bevares, og modtage et tilbagekald, når den virtuelle interaktion i køen dirigeres til en agent.

Håndtering af overløb

Webex CC understøtter håndtering af overløb ved hjælp af kapacitetsbaserede teams (CBT).

CBT er som et almindeligt team med en kapacitet og et tilknyttet eksternt DN, der betjener denne kapacitet. Det kan konfigureres sammen med andre teams i køopkaldsdistributionscyklusserne.

Normalt konfigureres dette som den sidste cyklus, så den fungerer som et overløb, hvis der ikke er nogen agent tilgængelig, selv efter at alle de konfigurerede opkaldsdistributionsgrupper ikke kan finde en tilgængelig matchende agent til håndtering af interaktionen.

Agent Desktop Operations

Når en agent logger på Webex CC Agent Desktop, angiver agenten et telefonnummer, som indgående opkald til agenten kan forbindes til. Det kan være en PSTN-telefon, en mobiltelefon eller et lokalnummer, hvis agenten er en Cisco Webex Calling bruger.

Bemærk, at dette nummer skal være et gyldigt telefonnummer, som opkald kan viderestilles til. Hvis dette ikke er tilfældet, kan agenten ikke modtage indgående opkald.

Baseret på den type interaktion, som agenten håndterer, giver widgets på agentskrivebordet mulighed for at udføre bestemte mediekontrolhandlinger.

Når et opkald f.eks. er besvaret, kan agenten udføre følgende handlinger i forbindelse med opkaldet.

• Sæt opkaldet på hold

• Initiere konsulentopkald og

  • Omstille opkaldet til et andet telefonnummer (f.eks. agentens telefonnummer)/indgangspunkt

  • Sæt en anden agent i konference for opkaldet

• Omstil opkaldet til en anden kø

• Afslutte opkaldet

Agentcomputer giver administratorer mulighed for at tilføje brugerdefinerede widgets der ved at udvide skrivebordsfunktionerne og gøre det til en samlet samling widgets, som agenter skal bruge for at få deres arbejde udført på en effektiv måde.

Skrivebordsarkitektur

Agentskrivebord er et mikrofrontend-baseret enkeltsidet program, der er vært for widgets, der er bygget på basis af webkomponentarkitektur. Alle standard / lager widgets er drevet af data, der hentes af API'er eller server side push mekanismer.

Disse er typisk asynkrone API'er, hvor svaret på en aktivering kommer til skrivebordet via en WebSocket-forbindelse.

Webex CC-Agent Desktop godkender brugere med Cisco Common Identity (CI), og tokenet sendes videre til alle API aktiveringer. Også for brugerdefinerede widgets, baseret på godkendelsesmodellen, giver det en single sign-on-oplevelse til agenter, hvis den brugerdefinerede widgets godkendelsesmodel er integreret med CI.

Når en agent er en del af en interaktion, sendes alle opdateringer til denne interaktionstilstand eller tilknyttede data til skrivebordet via WebSocket-forbindelsen.

Skrivebordets robusthed over for tilslutningsmuligheder og ventetid

Det asynkrone API- og serverside-push muliggør skalering og ethvert forbindelsestab til WebSocket-grænsefladen registreres, og skrivebordet forsøger at oprette forbindelse igen og logge på igen.

Følgende figur illustrerer agentskrivebordsarkitekturen i Webex CC.

Onboarding af kunder

Webex Control Hub er den primære grænseflade, der bruges af partnere og kunder til at onboarde kunder og aktivere eller konfigurere funktioner.

Når organisations- og kontaktcenterfunktionerne er klargjort i Control Hub, udløser det et workflow i Webex CC, som udfører resten af trinnene i klargøringen af alle kontaktcenterfunktioner i henhold til de tilbud, kunden har valgt.

Al klargøring af kontaktcentre udføres ved hjælp af et BPM-arbejdsprocesprogram, der muliggør en deklarativ måde at definere de involverede trin på og gør hele provisioneringstrinnene modstandsdygtige over for fejl og sikrer dataintegriteten.

Følgende figur illustrerer provisioneringsarbejdsgangen i Webex CC.

Konfigurationsobjekter

De vigtigste konfigurationsobjekter i Webex CC, der er omfattet af en organisation, er:

Sted

Sted betyder en placering, hvor et eller flere teams, brugere (agenter/supervisorer) er placeret.

Alle brugere og teams skal tilhøre et websted.

Team

En gruppe brugere. Teams bruges til at distribuere interaktioner til agenter via køer.

Hvert team skal tilhøre et websted.

Agenter

Brugere, der kan logge på Agent Desktop og håndtere interaktioner på tværs af medietyper, der er konfigureret i Webex CC.

Supervisorer

Supervisorer tildeles teams og kan overvåge/coache agenten og have adgang til teamniveaustatus og agentstatistikker for dem, der hører til de teams, som supervisoren er tildelt.

Kø

En kø er en logisk enhed, hvor interaktioner kan ventes på, at agenter er tilgængelige, som derefter distribueres til agenten.

Køer knyttes til teams som søgeområdet for agenter med mulighed for at udvide søgeområdet baseret på den forløbne tidsgrænse ved at føje andre teams til søgeområdet.

Entrypoint

Indgangspunkt er en logisk enhed, der repræsenterer indgangspunktet for interaktioner, der kommer ind i Webex CC. For telefoni er dette primært knyttet til det telefonnummer, som opkald ankommer til, og for e-mail/messaging-kanaler peger indgangspunktet på aktivkonfiguration i Webex Connect.

Flow

Det flow, der er knyttet til indgangspunktet (via distributionsstrategi), som bestemmer de trin, der er involveret i håndtering af interaktioner.

For ikke-telefonikanaler (e-mail, beskeder/sociale medier) vælges Flow som en del af aktivkonfigurationen i Webex Connect.

Adgangskontrol for kontaktcentre med flere steder

Webex CC-administratorer kan konfigurere brugerprofiler med adgangsrettigheder til bestemte steder, teams, køer og indgangspunkter. På grund af webstedernes og holdenes hierarkiske karakter er det desuden kun de teams eller den dato, der vedrører holdene, der tilhører disse websteder eller en eksplicit specificeret delmængde af sådanne teams, der kan tilgås af brugeren, når der er givet adgang til bestemte websteder.

For køer og indgangspunkter er de globale på organisationsniveau, så for forskellige geografiske placeringer (steder, hvor bestemte agenter og teams er placeret) kan der konfigureres separate indgangspunkter og køer, og supervisorer/brugere kan få adgang til de objekter, der er relevante for bestemte websteder.

Følgende figur illustrerer de centrale konfigurationsobjekter og den brugerprofil, der refererer til disse objekter.

Ud over at begrænse adgangen til disse enheder kan Webex CC-administratorer styre de specifikke funktioner/moduler, som en bruger kan få adgang til i administrationsgrænsefladen, og derved have brugere med administrations-/konfigurationsrettigheder til bestemte enheder samt sektioner/funktioner i Webex CC-administrationsgrænsefladen.

Integrerede skrivebordsconnectorer: CRM-program som den primære grænseflade

I denne driftstilstand logger agenten på CRM-konsollen som det primære program.

Webex CC er et integreret program (også kaldet et integreret skrivebordsprogram eller en integreret softphone), som primært bruges til at logge på kontaktcentret og modtage Webex CC-dirigerede kontaktcenterinteraktioner.

Ved modtagelse af et opkald eller en samtaleanmodning udfører CRM-integrationen følgende handlinger på CRM-konsollen

• Pop op-skærmbilledet til kundeposten, der er knyttet til ANI, eller andre tilknyttede opkaldsdata.

• Bogfør opkaldsmetadata som aktivitetsnoter i kundeposten

• Tillad agenten at "klikke for at ringe" ved at klikke på kontakten i CRM og starte et udgående opkald til kunden

• Bogføring af opkaldsposter i CRM-rapporteringstabellerne for primær rapportering på CRM.

• Indeholder den fulde funktionalitet af kontrolelementerne Agent Desktop og opkald (integreret og minificeret version af skrivebordsappen)

Den primære integrationstilstand med CRM'erne er ved at integrere Webex CC Desktop-program i en separat iFrame.

Desuden kører Webex CC Desktop-programmet en brugerdefineret konsolløs widget (ingen brugergrænseflade) kører i baggrunden, som interagerer med det underliggende CRM-system for at udføre automatiserede handlinger på vegne af agenten.

Interaktionerne drives af to SDK'er, som den konsolløse widget bruger.

• Webex CC Desktop JS SDK: Dette er JavaScript SDK'et, der leveres af Webex CC til registrering af hændelseslyttere til agent- og kontakthandlinger.

• CRM JS SDK: Dette er det CRM-klient-SDK, der gælder pr. CRM, der abstraherer REST API opkald med CRM. For eksempel bruges det CTI JS-bibliotek, der leveres af Salesforce, til salgsstyrke til at udføre handlinger og lytte efter hændelser inde i CRM.

Følgende figur illustrerer CRM-integrerede Webex CC-skrivebords- og connectorarkitektur

Webex CC understøtter følgende CRM-løsninger til ovennævnte integration:

• Salesforce

• ServiceNu

• Microsoft Dynamics 365

• Zendesk

• Freshdesk

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

Du kan finde flere oplysninger om konfiguration af Webex CC-skrivebordslayouts til aktivering af CRM-connectoren, funktionssæt og ændringslogfiler ved at besøge https://github.com/Ciscodevnet/webex-contact-center-crm-integrations.

Global tilgængelighed af CRM-connectorer

CRM Connectors er tilgængelige i alle geografiske områder og områder, hvor Webex CC fungerer.

Elastisk skala og ydeevne

Webex CC er vært for den brugerdefinerede widget, der muliggør tovejskommunikation mellem CRM-applikationen og Webex CC-skrivebordet i AWS CloudFront CDN, hvilket sikrer høj tilgængelighed af widget-AWS på tværs af tilgængelighedszoner og regioner.

Al CRM-integrationsspecifik beregning sker i den browser, hvor agenter bruger CRM-programmet med Webex CC Desktop integreret i CRM-programmet.

Sikkerhed

CRM-connectorerne aktiveres via Webex CC-agentskrivebordslayoutet, og valgfrie parametre overføres via skrivebordslayoutet til widgetten for at slå funktioner til og fra.

Hvis du f.eks. vil aktivere widgetten Salesforce-handlinger, kan administratoren aktivere parameterindstillingen for skrivebordslayoutparameteren sfdcWidgetEnabled til true.

Installation af pakke

Hvis integrationen skal fungere tovejs, skal CRM-konsollen have det integrerede program installeret. Dette er for at understøtte indlæsning af Desktop-applikationen inde i en iFrame.

Alle Desktop Embedded-connectorer er tilgængelige på CRM-markedspladsen.

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/

Installationen af markedspladsprogrammet aktiverer de nødvendige plug-ins og importerer de nødvendige XML-filer til CRM-konsollen for at understøtte rapportering af opkaldsposter på CRM-systemet.

Flowintegrationer via HTTP-connectorer i IVR

Webex CC Flow builder understøtter tovejsdatastrømme mellem Webex CC og CRM-systemet ved hjælp af HTTP-connectorer Webex, der er konfigureret i Control Hub og brugt på Webex CC Flow.

Disse bruges primært til personalisering inden for stemmeinteraktioner og tilpasset routing inden for IVR.

Som standard understøtter Webex CC Salesforce HTTP Connector på Control Hub. De andre CRM-connectorer kan tilføjes som brugerdefinerede connectorer på Webex Control Hub.

Du kan finde flere oplysninger om HTTP-connectorerne på https://github.com/CiscoDevNet/webex-contact-center-crm-integrations.

IVR HTTP-forbindelser:

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

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

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

Stemmeinfrastruktur på Edge

Voice Edge-komponenterne gør det muligt for SIP-trunks fra kundenetværk/PSTN-operatører at terminere, og dette er aktiveret baseret på hvidlistede IP'er, der har tilladelse til at oprette forbindelse til edge-komponenterne.

Beregn infrastruktursikkerhed

Webex CC-beregningsinstanser klargøres i AWS, og tjenester kører som pods i Kubernetes-klyngen, som har flere navneområder, og adgangen til hvert navneområde er begrænset med separate legitimationsoplysninger.

Al klargøring af infrastruktur udføres ved hjælp af kode - ingen manuelle trin - og ingen af legitimationsoplysningerne kan tilgås manuelt.

Der er et centralt legitimationslager med specifikke stier konfigureret til specifikt sæt tjenester / teams, og adgangen til selve legitimationslageret er begrænset og konfigureret som hemmeligheder i build- og implementeringssystemerne.

Ingen af infrastrukturkomponenterne / tjenesterne er direkte eksponeret uden for AWS VPC, og kun offentligt eksponerede grænseflader er API'er og WebSocket-servere, der styres og administreres ved hjælp af api-gateway,

Derudover er der visse interne systemer og grænseflader, der bruges af udviklere, og som bruges til visning af logfiler, målepunkter, implementeringsoplysninger, buildstatus og testresultater, som er sikret ved hjælp af roller og grupper og integreret med Ciscos interne godkendelsessystemer.

Godkendelse og autorisation af brugergrænseflader

Alle brugergrænseflader, der bruges af forskellige kontaktcenterbrugere (agenter, supervisorer, administratorer, analytikere), er beskyttet af Cisco Common Identity-baserede OAuth-flows (ihændehavertokengodkendelse).

Godkendelsen udføres ved hjælp af roller for den bruger, der har hentet tokenet, og områder, der er tildelt tokenet.

Data i transit

Ingen af grænsefladerne i den anvendte tjeneste-/infrastrukturkomponent er direkte eksponeret for ekstern indgående trafik.

Vælg tjenester med http-API'er eksponerer disse grænseflader via en gateway, og al indgående https (inklusive dem fra WebSocket) afsluttes i ALB, og intern trafik via http dirigeres til tjenesterne.

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

Inde i VPC er den interne kommunikation mellem tjenester - over http / brugerdefineret TCP-protokol - over almindelig TCP stikkontakt.

Inaktive data

Alle data, der gemmes, krypteres på lagerlaget. Desuden er de datalagre, der er uden for VPC, beskyttet og adgangskontrol og autorisationer med legitimationsoplysninger sikkert gemt og administreret i et hemmeligt lager.

Følgende figur illustrerer datastrøms- og sikkerhedsmodellen for transit såvel som inaktive hændelser.

Slutbrugerens PII-data

Webex CC Flow, som er den programmatiske controller til håndtering af interaktioner, kan bruges til at indsamle brugerdata, som kan tildeles flowvariabler, der er specielt mærket som 'Indeholder følsomme data'. Værdierne for sådanne data krypteres, og ingen tjenester i transitstien for dataene har adgang til disse data.

Desuden bevares sådanne data aldrig i Webex CC-rapporteringsdatalager, og logfilerne / messaging-infrastrukturen vil have krypterede data, og klare tekstdata gemmes ikke nogen steder i Webex CC.

Kontaktcenteragent/supervisor-PII-data

De brugerrelaterede data for kontaktcentret redigeres i logfiler, men er tilgængelige for dataanalyse og visualisering i Webex CC-datalageret.

Faktorer for skala

For Webex CC er de faktorer, der påvirker skalaen:

• Samtidig antal agenter logget på

• Samtidig antal igangværende interaktioner

  • Handlinger, der udføres på disse interaktioner

• Samtidig antal handlinger, som supervisorer/agenter udfører uden for håndteringen af interaktionerne

• Mængden af genererede og vedvarende data

Arkitektoniske aspekter, der muliggør skalering

De principper, som Webex CC er baseret på, gør det muligt for løsningen at skalere dynamisk efter behov inden for de grænser, der håndhæves af den infrastruktur, der leveres til de forskellige tjenester og platformskomponenter.

Hændelsesdrevet arkitektur

Tjenesterne i Webex CC kommunikerer ved hjælp af meddelelser, og processen til behandling af kritiske meddelelser involverer ingen blokerende IO-handlinger, og den tilstand, der kræves til behandling af meddelelser, er lokaliseret til forekomsten af den tjeneste, der behandler meddelelsen.

Statsløse tjenester (eller eksternaliseret stat)

Statsløse tjenester muliggør elasticitet ved nemt at tilføje/fjerne yderligere forekomster af tjenesterne. Der er visse tjenester, der i sagens natur er statslige, og de har eksternaliseret statsbutik, og infrastrukturen understøtter også dynamiske ændringer i antallet af forekomster af sådanne tjenester med automatisk rebalancering / statsoverførsel / lokalisering af staten til den instans, der har brug for staten.

Elastisk infrastruktur

Alle tjenester kører i Kubernetes, og infrastrukturen aka Kubernetes-noder skaleres automatisk baseret på brugen, og dette muliggør dynamisk tilføjelse af flere beregningsnoder op til en maksimal høj tærskel, der er forudkonfigureret.

Belastningsprojektion og regelmæssig validering

Alle tjenester benchmarkes for ydeevneegenskaberne, og skaleringsmønsteret valideres på serviceniveau.

Yderligere kontinuerlig validering, spidsbelastning og udholdenhedstest udføres med testparametre, der er indstillet til forventet vækst i de skalapåvirkende attributter, hvilket gør det muligt at identificere flaskehalse, planlægge at opdatere den høje tærskel for infrastrukturressourceforbrug og være klar til spildagen.

Telefoni-

For telefoni bestemmes håndteringen af indgående taleopkald af, hvordan opkaldet er kommet ind i kontaktcenteret (se Indtrængningsmekanismer nedenfor) og af det Webex CC-flow, der er knyttet til indgangspunktet.

Opkaldet besvares, og der udføres yderligere handlinger i henhold til Webex CC Flow-definitionen – som er en programmatisk repræsentation af de handlinger, der skal udføres, mens opkaldet håndteres, enten før det sættes i kø og dirigeres til en agent, eller selve flowet kan håndtere opkaldet uden overførsel til en agent.

Flow Builder i Webex CC giver udviklere mulighed for at definere flowet og tildele det til det indgangspunkt, via hvilket opkaldet ankommer til Webex CC.

Disse konfigurationsobjekter og deres anvendelse er dækket i Konfigurationsenheder.

Flere oplysninger om Flow Builder er dækket i det kommende afsnit om IVR System.

E-mail og beskeder

Fra Webex CC-perspektiv leverer Webex Connect indgående og udgående funktioner til alle digitale kanaler - e-mail, meddelelseskanaler, som slutbrugere kan bruge til at kontakte kontaktcenter.

Webex Connect Flow

• Bestemmer håndteringen af sådanne interaktioner, indtil interaktionerne er sat i kø og distribueret til agenter. Dette omfatter automatisk håndtering og BOT-behandlinger for alle former for messaging og e-mail-interaktioner.

• Anvender forretningslogik på indgående interaktion.

• Håndterer kontakt før kø.

• Flow selv kan håndtere interaktionen uden overførsel til live agent.

De meddelelseskanaler, der understøttes af Webex CC, er:

• Web App / Mobil App Chat

• WhatsApp

• Facebook Messenger

• Sms

De e-mailkanaler, der understøttes af Webex CC, er:

• Gmail

• Office365

Indtrængningsmekanismer

Dette afsnit dækker de mekanismer, hvormed en interaktion kan komme ind i Webex CC. Baseret på medietypen er de mekanismer, hvormed en interaktion når Webex CC, forskellige.

Inden for telefoni er der f.eks. behov for fysisk infrastrukturprovisionering for at aktivere PSTN-forbindelse, konfiguration af telefonnumre og routing af opkald til Webex CC.

For e-mail-/meddelelseskanaler skal indgående konfiguration udføres i Webex Connect, og det involverer klargøring af e-mail-/messaging-konto og konfiguration af Webex Connect-flow.

Indgående stemme

I forbindelse med taleopkald er det typisk sådan, at brugerne ringer til et PSTN-telefonnummer, som derefter forbindes til kontaktcentret. Fra et indgående perspektiv kræver dette en mekanisme til at dirigere opkald fra PSTN til Webex CC.

Følgende figur illustrerer indtagelsen af taleopkald til Webex CC.

Voice Ingress Services i Webex CC udfører tredjepartsopkaldsstyring ved hjælp af SIP og besvarer det indgående opkald samt udfører overførsels-, konference- og andre opkaldskontrolhandlinger.

Det logiske indgangspunkt for opkald i Webex CC er konfigurationsenheden med navnet "Indgangspunkt". I forbindelse med taleindtrængning er nøglekonfigurationen for indgangspunktet det telefonnummer, der er knyttet til det, hvilket typisk er et gyldigt PSTN-telefonnummer, der er hentet fra den valgte PSTN-udbyder.

Dette gør det muligt at registrere indgående opkald på telefonnummeret, knytte opkaldet til indgangspunktet og bruge andre konfigurationsparametre for indgangspunktet til at håndtere opkaldet i henhold til den Webex CC Flow-definition, der skal udløses for interaktionen.

Bemærk:

Du kan finde flere oplysninger om PSTN-forbindelsesindstillingerne på 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.

Skalerbarhed og tilgængelighed af Voice Edge-infrastruktur

Webex CC VPOP-infrastrukturen omfatter redundante par SIP SBC'er, der sikrer høj tilgængelighed, og flere SBC'er kan tilføjes for at skalere de samtidige opkaldsmængder, der skal understøttes.

Det maksimale antal samtidige opkald, som VPOP kan håndtere, afhænger af antallet af SBC'er, der kører, og som opkald sendes til.

For geografisk redundans – et net af VPOP SBC med sammenkoblinger på tværs af flere par på tværs af regioner understøttes.

For taleindtrængningstjenester er de horisontalt skalerbare til at håndtere et stigende antal samtidige taleopkald, der skal indtages til Webex CC.

Sikkerhedsovervejelser i forbindelse med voice edge-infrastruktur

Nedenstående tabel indeholder oplysninger om tilslutningsmulighederne til Voice Edge-infrastrukturen.

For flere detaljer, besøg 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-system

Alle taleopkald, der kommer til et telefonnummer, der er tilknyttet et indgangspunkt, bliver besvaret af Webex CC, og udførelse af et Webex CC-flow, der er knyttet til indgangspunktet, går i gang.

Webex CC Flow Builder leverer programmeringskonstruktioner/operatorer og funktionelle blokke, kaldet aktiviteter, så administratorer eller andre, der designer og implementerer den IVR logik, kan kombinere disse byggesten og oprette Flow-definitionen.

De programmeringskonstruktioner, som Flow understøtter, er:

• Rapporterings- og indstillingsvariabler – tilstand, der er knyttet til en flowudførelse

  • Pebble Expressions for at indstille værdien af variabler

• Betinget kontrol

• Looping - ved hjælp af Conditionals og Go To (evne til at kæde aktiviteter sammen)

• Kald REST-API'er

• Parse Data - JSON, TOML, XML bruges typisk til at analysere API svar.

• Komponere aktiviteter

Et repræsentativt sæt aktiviteter, som Flow leverer, er: Afspil beskeder Indsaml brugerdata Omstille opkaldet til en anden destination/et andet telefonnummer Send opkaldet til en virtuel agent Sæt opkaldet i kø, så det kan blive besvaret af en agent.

For hvert opkald, der er aktivt, er en forekomst af flowkørsel også aktiv, indtil opkaldet afsluttes, hvilket resulterer i samtidige udførelser af flows.

Hver forekomst af flowudførelse giver isoleret miljø for data / tilstand, der er knyttet til flowet og der ved opkaldet.

I hele opkaldets livscyklus gør flow det også muligt at reagere på bestemte hændelser, der sker, og håndtere dem – f.eks. når et opkald bliver besvaret af en agent, kan en hændelseshandler udløse et pop-op-vindue på skærmen i grænsefladen på agentskrivebordet.

Du kan finde flere oplysninger om Webex CC Flow under 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.

Understøttelse af virtuel agent

Flow leverer en aktivitet til overdragelse af interaktionen til en virtuel agent, der er forudkonfigureret i Webex Control Hub.

Når opkaldet er forbundet til en virtuel agent, giver det brugeren en samtalebaseret IVR oplevelse, og aktiviteten afsluttes enten med, at opkaldet afsluttes, eller med at opkaldet eskaleres til en agent.

I tilfælde af eskalering kan flowet konfigureres til at sætte opkaldet i kø, som derefter besvares af en agent.

Indgående digitale interaktioner

Til e-mail- og meddelelseskanaler for indgående interaktioner bruger Webex CC Webex Connect til klargøring af aktiverne, flow til at håndtere de indgående interaktioner og derefter dirigere interaktionen til Webex CC, når Webex Connect-flowet eksplicit sætter interaktionen i kø, så den kan håndteres af en agent.

Følgende figur illustrerer indtagelsen af e-mail, meddelelsesinteraktioner i Webex CC.

Virtual Agent / BOT-integrationer

For interaktioner med e-mail og messaging / sociale kanaler konfigureres de virtuelle agent/BOT-behandlinger i Webex Connect-flowet.

Som det er tilfældet med Virtual Agents for Voice, sættes interaktionen i kø og distribueres til en agent, hvis BOT-behandlingen ender med at eskalere som resultat.

Valg af agent

Køer i Webex CC understøtter følgende agentudvælgelsesalgoritmer:

• Agentruter, der har været længst tilgængelig

• Fagbaseret routing

  • Længst tilgængelig agent (LAA)

  • Bedste tilgængelige agent (BAA)

Agenter er knyttet til køerne gennem Teams.

En kø kan tildeles flere opkaldsdistributionsgrupper (hvor hver gruppe har et eller flere teams) på en sekventiel måde med konfigureret ventetid på, at opkaldsdistributionsgruppen føjes til køen, så søgeområdet for en matchende agent udvides til flere opkaldsdistributionsgrupper, efterhånden som tiden skrider frem.

For fagbaseret distribution vælges en agent blandt de fagkrav, der matcher agenter, der er knyttet til køen, baseret på LAA- eller BAA-konfiguration.

Tale-/telefonispecifikke ekstra funktioner

Agentbaseret routing (kun for tale-/telefonikanaler)

Webex CC Flow kan ved hjælp af aktiviteten QueueToAgent distribuere interaktioner direkte til den valgte agent baseret på agent-id'et.

Hvis agenten ikke er tilgængelig til at håndtere interaktioner, kan interaktionen parkeres i en agentspecifik kø og vente på, at agenten bliver tilgængelig

Avancerede køoplysninger

Webex CC Flow kan ved hjælp af aktiviteten GetQueueInfo hente oplysninger i realtid for en kø, f.eks. position i kø (PIQ), estimeret ventetid (EWT), antal agenter, der er tilgængelige i køen, og kan bruges til at beslutte, om kontakten skal sættes i kø eller ej.

Hilsen tilbagekald

Webex CC Flow giver ved hjælp af aktivitetstilbagekald kunden mulighed for at afbryde forbindelsen til opkaldet, samtidig med at positionen i køen bevares, og modtage et tilbagekald, når den virtuelle interaktion i køen dirigeres til en agent.

Håndtering af overløb

Webex CC understøtter håndtering af overløb ved hjælp af kapacitetsbaserede teams (CBT).

CBT er som et almindeligt team med en kapacitet og et tilknyttet eksternt DN, der betjener denne kapacitet. Det kan konfigureres sammen med andre teams i køopkaldsdistributionscyklusserne.

Normalt konfigureres dette som den sidste cyklus, så den fungerer som et overløb, hvis der ikke er nogen agent tilgængelig, selv efter at alle de konfigurerede opkaldsdistributionsgrupper ikke kan finde en tilgængelig matchende agent til håndtering af interaktionen.

Agent Desktop Operations

Når en agent logger på Webex CC Agent Desktop, angiver agenten et telefonnummer, som indgående opkald til agenten kan forbindes til. Det kan være en PSTN-telefon, en mobiltelefon eller et lokalnummer, hvis agenten er en Cisco Webex Calling bruger.

Bemærk, at dette nummer skal være et gyldigt telefonnummer, som opkald kan viderestilles til. Hvis dette ikke er tilfældet, kan agenten ikke modtage indgående opkald.

Baseret på den type interaktion, som agenten håndterer, giver widgets på agentskrivebordet mulighed for at udføre bestemte mediekontrolhandlinger.

Når et opkald f.eks. er besvaret, kan agenten udføre følgende handlinger i forbindelse med opkaldet.

• Sæt opkaldet på hold

• Initiere konsulentopkald og

  • Omstille opkaldet til et andet telefonnummer (f.eks. agentens telefonnummer)/indgangspunkt

  • Sæt en anden agent i konference for opkaldet

• Omstil opkaldet til en anden kø

• Afslutte opkaldet

Agentcomputer giver administratorer mulighed for at tilføje brugerdefinerede widgets der ved at udvide skrivebordsfunktionerne og gøre det til en samlet samling widgets, som agenter skal bruge for at få deres arbejde udført på en effektiv måde.

Skrivebordsarkitektur

Agentskrivebord er et mikrofrontend-baseret enkeltsidet program, der er vært for widgets, der er bygget på basis af webkomponentarkitektur. Alle standard / lager widgets er drevet af data, der hentes af API'er eller server side push mekanismer.

Disse er typisk asynkrone API'er, hvor svaret på en aktivering kommer til skrivebordet via en WebSocket-forbindelse.

Webex CC-Agent Desktop godkender brugere med Cisco Common Identity (CI), og tokenet sendes videre til alle API aktiveringer. Også for brugerdefinerede widgets, baseret på godkendelsesmodellen, giver det en single sign-on-oplevelse til agenter, hvis den brugerdefinerede widgets godkendelsesmodel er integreret med CI.

Når en agent er en del af en interaktion, sendes alle opdateringer til denne interaktionstilstand eller tilknyttede data til skrivebordet via WebSocket-forbindelsen.

Skrivebordets robusthed over for tilslutningsmuligheder og ventetid

Det asynkrone API- og serverside-push muliggør skalering og ethvert forbindelsestab til WebSocket-grænsefladen registreres, og skrivebordet forsøger at oprette forbindelse igen og logge på igen.

Følgende figur illustrerer agentskrivebordsarkitekturen i Webex CC.

Onboarding af kunder

Webex Control Hub er den primære grænseflade, der bruges af partnere og kunder til at onboarde kunder og aktivere eller konfigurere funktioner.

Når organisations- og kontaktcenterfunktionerne er klargjort i Control Hub, udløser det et workflow i Webex CC, som udfører resten af trinnene i klargøringen af alle kontaktcenterfunktioner i henhold til de tilbud, kunden har valgt.

Al klargøring af kontaktcentre udføres ved hjælp af et BPM-arbejdsprocesprogram, der muliggør en deklarativ måde at definere de involverede trin på og gør hele provisioneringstrinnene modstandsdygtige over for fejl og sikrer dataintegriteten.

Følgende figur illustrerer provisioneringsarbejdsgangen i Webex CC.

Konfigurationsobjekter

De vigtigste konfigurationsobjekter i Webex CC, der er omfattet af en organisation, er:

Sted

Sted betyder en placering, hvor et eller flere teams, brugere (agenter/supervisorer) er placeret.

Alle brugere og teams skal tilhøre et websted.

Team

En gruppe brugere. Teams bruges til at distribuere interaktioner til agenter via køer.

Hvert team skal tilhøre et websted.

Agenter

Brugere, der kan logge på Agent Desktop og håndtere interaktioner på tværs af medietyper, der er konfigureret i Webex CC.

Supervisorer

Supervisorer tildeles teams og kan overvåge/coache agenten og have adgang til teamniveaustatus og agentstatistikker for dem, der hører til de teams, som supervisoren er tildelt.

Kø

En kø er en logisk enhed, hvor interaktioner kan ventes på, at agenter er tilgængelige, som derefter distribueres til agenten.

Køer knyttes til teams som søgeområdet for agenter med mulighed for at udvide søgeområdet baseret på den forløbne tidsgrænse ved at føje andre teams til søgeområdet.

Entrypoint

Indgangspunkt er en logisk enhed, der repræsenterer indgangspunktet for interaktioner, der kommer ind i Webex CC. For telefoni er dette primært knyttet til det telefonnummer, som opkald ankommer til, og for e-mail/messaging-kanaler peger indgangspunktet på aktivkonfiguration i Webex Connect.

Flow

Det flow, der er knyttet til indgangspunktet (via distributionsstrategi), som bestemmer de trin, der er involveret i håndtering af interaktioner.

For ikke-telefonikanaler (e-mail, beskeder/sociale medier) vælges Flow som en del af aktivkonfigurationen i Webex Connect.

Adgangskontrol for kontaktcentre med flere steder

Webex CC-administratorer kan konfigurere brugerprofiler med adgangsrettigheder til bestemte steder, teams, køer og indgangspunkter. På grund af webstedernes og holdenes hierarkiske karakter er det desuden kun de teams eller den dato, der vedrører holdene, der tilhører disse websteder eller en eksplicit specificeret delmængde af sådanne teams, der kan tilgås af brugeren, når der er givet adgang til bestemte websteder.

For køer og indgangspunkter er de globale på organisationsniveau, så for forskellige geografiske placeringer (steder, hvor bestemte agenter og teams er placeret) kan der konfigureres separate indgangspunkter og køer, og supervisorer/brugere kan få adgang til de objekter, der er relevante for bestemte websteder.

Følgende figur illustrerer de centrale konfigurationsobjekter og den brugerprofil, der refererer til disse objekter.

Ud over at begrænse adgangen til disse enheder kan Webex CC-administratorer styre de specifikke funktioner/moduler, som en bruger kan få adgang til i administrationsgrænsefladen, og derved have brugere med administrations-/konfigurationsrettigheder til bestemte enheder samt sektioner/funktioner i Webex CC-administrationsgrænsefladen.

Integrerede skrivebordsconnectorer: CRM-program som den primære grænseflade

I denne driftstilstand logger agenten på CRM-konsollen som det primære program.

Webex CC er et integreret program (også kaldet et integreret skrivebordsprogram eller en integreret softphone), som primært bruges til at logge på kontaktcentret og modtage Webex CC-dirigerede kontaktcenterinteraktioner.

Ved modtagelse af et opkald eller en samtaleanmodning udfører CRM-integrationen følgende handlinger på CRM-konsollen

• Pop op-skærmbilledet til kundeposten, der er knyttet til ANI, eller andre tilknyttede opkaldsdata.

• Bogfør opkaldsmetadata som aktivitetsnoter i kundeposten

• Tillad agenten at "klikke for at ringe" ved at klikke på kontakten i CRM og starte et udgående opkald til kunden

• Bogføring af opkaldsposter i CRM-rapporteringstabellerne for primær rapportering på CRM.

• Indeholder den fulde funktionalitet af kontrolelementerne Agent Desktop og opkald (integreret og minificeret version af skrivebordsappen)

Den primære integrationstilstand med CRM'erne er ved at integrere Webex CC Desktop-program i en separat iFrame.

Desuden kører Webex CC Desktop-programmet en brugerdefineret konsolløs widget (ingen brugergrænseflade) kører i baggrunden, som interagerer med det underliggende CRM-system for at udføre automatiserede handlinger på vegne af agenten.

Interaktionerne drives af to SDK'er, som den konsolløse widget bruger.

• Webex CC Desktop JS SDK: Dette er JavaScript SDK'et, der leveres af Webex CC til registrering af hændelseslyttere til agent- og kontakthandlinger.

• CRM JS SDK: Dette er det CRM-klient-SDK, der gælder pr. CRM, der abstraherer REST API opkald med CRM. For eksempel bruges det CTI JS-bibliotek, der leveres af Salesforce, til salgsstyrke til at udføre handlinger og lytte efter hændelser inde i CRM.

Følgende figur illustrerer CRM-integrerede Webex CC-skrivebords- og connectorarkitektur

Webex CC understøtter følgende CRM-løsninger til ovennævnte integration:

• Salesforce

• ServiceNu

• Microsoft Dynamics 365

• Zendesk

• Freshdesk

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

Du kan finde flere oplysninger om konfiguration af Webex CC-skrivebordslayouts til aktivering af CRM-connectoren, funktionssæt og ændringslogfiler ved at besøge https://github.com/Ciscodevnet/webex-contact-center-crm-integrations.

Global tilgængelighed af CRM-connectorer

CRM Connectors er tilgængelige i alle geografiske områder og områder, hvor Webex CC fungerer.

Elastisk skala og ydeevne

Webex CC er vært for den brugerdefinerede widget, der muliggør tovejskommunikation mellem CRM-applikationen og Webex CC-skrivebordet i AWS CloudFront CDN, hvilket sikrer høj tilgængelighed af widget-AWS på tværs af tilgængelighedszoner og regioner.

Al CRM-integrationsspecifik beregning sker i den browser, hvor agenter bruger CRM-programmet med Webex CC Desktop integreret i CRM-programmet.

Sikkerhed

CRM-connectorerne aktiveres via Webex CC-agentskrivebordslayoutet, og valgfrie parametre overføres via skrivebordslayoutet til widgetten for at slå funktioner til og fra.

Hvis du f.eks. vil aktivere widgetten Salesforce-handlinger, kan administratoren aktivere parameterindstillingen for skrivebordslayoutparameteren sfdcWidgetEnabled til true.

Installation af pakke

Hvis integrationen skal fungere tovejs, skal CRM-konsollen have det integrerede program installeret. Dette er for at understøtte indlæsning af Desktop-applikationen inde i en iFrame.

Alle Desktop Embedded-connectorer er tilgængelige på CRM-markedspladsen.

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/

Installationen af markedspladsprogrammet aktiverer de nødvendige plug-ins og importerer de nødvendige XML-filer til CRM-konsollen for at understøtte rapportering af opkaldsposter på CRM-systemet.

Flowintegrationer via HTTP-connectorer i IVR

Webex CC Flow builder understøtter tovejsdatastrømme mellem Webex CC og CRM-systemet ved hjælp af HTTP-connectorer Webex, der er konfigureret i Control Hub og brugt på Webex CC Flow.

Disse bruges primært til personalisering inden for stemmeinteraktioner og tilpasset routing inden for IVR.

Som standard understøtter Webex CC Salesforce HTTP Connector på Control Hub. De andre CRM-connectorer kan tilføjes som brugerdefinerede connectorer på Webex Control Hub.

Du kan finde flere oplysninger om HTTP-connectorerne på https://github.com/CiscoDevNet/webex-contact-center-crm-integrations.

IVR HTTP-forbindelser:

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

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

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

Stemmeinfrastruktur på Edge

Voice Edge-komponenterne gør det muligt for SIP-trunks fra kundenetværk/PSTN-operatører at terminere, og dette er aktiveret baseret på hvidlistede IP'er, der har tilladelse til at oprette forbindelse til edge-komponenterne.

Beregn infrastruktursikkerhed

Webex CC-beregningsinstanser klargøres i AWS, og tjenester kører som pods i Kubernetes-klyngen, som har flere navneområder, og adgangen til hvert navneområde er begrænset med separate legitimationsoplysninger.

Al klargøring af infrastruktur udføres ved hjælp af kode - ingen manuelle trin - og ingen af legitimationsoplysningerne kan tilgås manuelt.

Der er et centralt legitimationslager med specifikke stier konfigureret til specifikt sæt tjenester / teams, og adgangen til selve legitimationslageret er begrænset og konfigureret som hemmeligheder i build- og implementeringssystemerne.

Ingen af infrastrukturkomponenterne / tjenesterne er direkte eksponeret uden for AWS VPC, og kun offentligt eksponerede grænseflader er API'er og WebSocket-servere, der styres og administreres ved hjælp af api-gateway,

Derudover er der visse interne systemer og grænseflader, der bruges af udviklere, og som bruges til visning af logfiler, målepunkter, implementeringsoplysninger, buildstatus og testresultater, som er sikret ved hjælp af roller og grupper og integreret med Ciscos interne godkendelsessystemer.

Godkendelse og autorisation af brugergrænseflader

Alle brugergrænseflader, der bruges af forskellige kontaktcenterbrugere (agenter, supervisorer, administratorer, analytikere), er beskyttet af Cisco Common Identity-baserede OAuth-flows (ihændehavertokengodkendelse).

Godkendelsen udføres ved hjælp af roller for den bruger, der har hentet tokenet, og områder, der er tildelt tokenet.

Data i transit

Ingen af grænsefladerne i den anvendte tjeneste-/infrastrukturkomponent er direkte eksponeret for ekstern indgående trafik.

Vælg tjenester med http-API'er eksponerer disse grænseflader via en gateway, og al indgående https (inklusive dem fra WebSocket) afsluttes i ALB, og intern trafik via http dirigeres til tjenesterne.

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

Inde i VPC er den interne kommunikation mellem tjenester - over http / brugerdefineret TCP-protokol - over almindelig TCP stikkontakt.

Inaktive data

Alle data, der gemmes, krypteres på lagerlaget. Desuden er de datalagre, der er uden for VPC, beskyttet og adgangskontrol og autorisationer med legitimationsoplysninger sikkert gemt og administreret i et hemmeligt lager.

Følgende figur illustrerer datastrøms- og sikkerhedsmodellen for transit såvel som inaktive hændelser.

Slutbrugerens PII-data

Webex CC Flow, som er den programmatiske controller til håndtering af interaktioner, kan bruges til at indsamle brugerdata, som kan tildeles flowvariabler, der er specielt mærket som 'Indeholder følsomme data'. Værdierne for sådanne data krypteres, og ingen tjenester i transitstien for dataene har adgang til disse data.

Desuden bevares sådanne data aldrig i Webex CC-rapporteringsdatalager, og logfilerne / messaging-infrastrukturen vil have krypterede data, og klare tekstdata gemmes ikke nogen steder i Webex CC.

Kontaktcenteragent/supervisor-PII-data

De brugerrelaterede data for kontaktcentret redigeres i logfiler, men er tilgængelige for dataanalyse og visualisering i Webex CC-datalageret.

Faktorer for skala

For Webex CC er de faktorer, der påvirker skalaen:

• Samtidig antal agenter logget på

• Samtidig antal igangværende interaktioner

  • Handlinger, der udføres på disse interaktioner

• Samtidig antal handlinger, som supervisorer/agenter udfører uden for håndteringen af interaktionerne

• Mængden af genererede og vedvarende data

Arkitektoniske aspekter, der muliggør skalering

De principper, som Webex CC er baseret på, gør det muligt for løsningen at skalere dynamisk efter behov inden for de grænser, der håndhæves af den infrastruktur, der leveres til de forskellige tjenester og platformskomponenter.

Hændelsesdrevet arkitektur

Tjenesterne i Webex CC kommunikerer ved hjælp af meddelelser, og processen til behandling af kritiske meddelelser involverer ingen blokerende IO-handlinger, og den tilstand, der kræves til behandling af meddelelser, er lokaliseret til forekomsten af den tjeneste, der behandler meddelelsen.

Statsløse tjenester (eller eksternaliseret stat)

Statsløse tjenester muliggør elasticitet ved nemt at tilføje/fjerne yderligere forekomster af tjenesterne. Der er visse tjenester, der i sagens natur er statslige, og de har eksternaliseret statsbutik, og infrastrukturen understøtter også dynamiske ændringer i antallet af forekomster af sådanne tjenester med automatisk rebalancering / statsoverførsel / lokalisering af staten til den instans, der har brug for staten.

Elastisk infrastruktur

Alle tjenester kører i Kubernetes, og infrastrukturen aka Kubernetes-noder skaleres automatisk baseret på brugen, og dette muliggør dynamisk tilføjelse af flere beregningsnoder op til en maksimal høj tærskel, der er forudkonfigureret.

Belastningsprojektion og regelmæssig validering

Alle tjenester benchmarkes for ydeevneegenskaberne, og skaleringsmønsteret valideres på serviceniveau.

Yderligere kontinuerlig validering, spidsbelastning og udholdenhedstest udføres med testparametre, der er indstillet til forventet vækst i de skalapåvirkende attributter, hvilket gør det muligt at identificere flaskehalse, planlægge at opdatere den høje tærskel for infrastrukturressourceforbrug og være klar til spildagen.