- Hjem
- /
- Artikkel
Konfigurer Webex Contact Center i India
Denne artikkelen hjelper deg med å sette opp Webex Contact Center for India Data Center (DC).
Oversikt
Cisco Webex Contact Centerer nå tilgjengelig som en regulert tjeneste i India, noe som gjør det mulig for både multinasjonale og innenlandske organisasjoner å drive BPO- og kontaktsentertjenester i full overensstemmelse med Department of Telecommunications (DoT), Government of India forskrifter.
Webex Contact Center i India er bygget på Webex Calling grunnlaget. Denne integrerte tilnærmingen gjør det mulig for organisasjoner å utnytte en enhetlig skyarkitektur for både bedriftstel efoni og avansert kundeengasjement. Før du aktiverer Contact Center-funksjoner, er det viktig å sørge for at basemil Webex Calling jøet ditt er konfigurert spesielt for India Data Center for å oppfylle myndighetskrav.
For informasjon om tariffplaner, se Webex Contact Center India Tariff Plan artikkel.
Viktig samsvarserklæring
Overholdelse av Indias Department of Telecommunications (DoT) forskrifter er et delt ansvar mellom Cisco og kundene. For å sikre at din spesifikke distribusjon er i samsvar med alle lokale juridiske krav, anbefaler vi at du konsulterer din juridiske eller regulatoriske rådgiver.
India wxCC-distribusjonsmodeller
For å komme i gang med India-oppsettet ditt, er det best å først forstå det tekniske standardgrunnlaget for Webex Contact Center. Vi anbefaler å gå gjennom artikkelen Konfigurer talekanaler for Webex Contact Center, som forklarer trelagsarkitekturen vi bruker globalt:
-
Tilgangslag: Dette er kanten der PSTN eller lokale gateways kobles til Webex.
-
Mediebehandlingslag: Det er her den faktiske lyden (media) håndteres og avsluttes.
-
Applikasjonslag: Dette er hjernen som administrerer samtaleruting, ledetekster og agenttildelinger.
I India DC hjelper disse lagene deg med å overholde DoT-forskriftene. Avhengig av hvor dine agenter og kunder er, velger du en av tre modeller: International BPO, Indian Tenant eller Multinational Tenant.
Modell 1: Internasjonal BPO
Oversikt
Følg disse retningslinjene for internasjonal forretningsprosess outsourcet (BPO) der leietaker og telefoniressurser er registrert utenfor India:
-
Leietaker er registrert fra et land utenfor India.
-
Entry Point Dialed Number (EPDN) er knyttet til et sted utenfor India.
-
Agenter og telefonene deres (Webex Callingutvidelser eller lokale Call Manager-utvidelser) er konfigurert for et utenlandsk sted.
-
Agenter er fysisk lokalisert i India, men håndterer samtaler som kommer fra fremmedlandets inngangspunkt (EP) -nummer.
Administrasjon og konfigurasjon
-
Agenter i India må ikke være koblet til India PSTN-tjenester (det vil si at telefonitjenesten deres skal konfigureres som et sted utenfor India).
-
India PSTN må ikke brukes til noen Bridge DN, Blind Transfer Flow-hendelser eller noen Webex Contact Center-operasjoner innenfor en interaksjon.
-
Agenter kan bruke WebRTC for tilkobling.
-
Det kreves ingen spesielle begrensninger på køer eller lag.
Overholdelse
Følg disse nøkkelkravene innenfor den valgte distribusjonsmodellen for å overholde lokale forskrifter:
-
Kontortilkobling: Hvis agentene dine jobber fra kontoret, må mediene flyte over en dedikert nettverkstilkobling.
-
Arbeid hjemmefra: Agenter som jobber hjemmefra kan bruke Internett direkte. De trenger ikke å koble seg til kontornettverket sitt i India ved hjelp av en VPN.
-
Oppbevaring av data: Du er ansvarlig for å laste ned samtaledetaljer (CDR) og revisjonslogger. Disse må lagres på en server i India i minst ett år.
Modell 2: Indisk leietaker med kontaktsenter kun for India-kunder
Oversikt
Bruk denne modellen hvis organisasjonen din driver et innenlandsk kontaktsenter i India og kun betjener indiske kunder. I dette scenariet må både agenter og telefonressurser være tilknyttet lokasjoner i India.
Administrasjon og konfigurasjon
-
Opprett et hovedkvarter (HQ) i India. Den første plasseringen du oppretter, bestemmer Webex Calling datasenteret for organisasjonen.
-
Opprett soner og konfigurer Trusted Network Edge i henhold til Webex Calling retningslinjene for indiske lokasjoner.
-
Fullfør KYC (Know Your Customer) prosedyrer for å aktivere plasseringen.
-
Sørg for at all Bring Your Own AI (BYOAI) knyttet til strømmer med indiske numre bare kobles til tjenester i India.
-
Etabler en dedikert kø og et team av agenter for å betjene India EP-er; ikke bland disse agentene med de som håndterer samtaler fra EP utenfor India.
-
For hver sone:
-
Opprett en ANI-liste (Outdial Automated Number Identification) og angi standard ANI til et nummer innenfor den sonen.
-
Knytt Outdial ANI-listen til teamet av agenter som betjener EP-en fra den sonen.
-
Dette unngår anropsfeil under utoppringing når agenter bruker standard ANI.
-
Når du setter opp høflige tilbakeringinger, sørg for at ANI samsvarer med den spesifikke indiske sonen der agentene i den køen befinner seg.
-
-
Når du oppretter kampanjer, reserver agenter fra en bestemt sone og bruker ANI fra samme sone.
Overholdelse
Følg disse nøkkelkravene innenfor den valgte distribusjonsmodellen for å overholde lokale forskrifter:
-
Kontortilkobling: Hvis agentene dine jobber fra kontoret, må mediene flyte over en dedikert nettverkstilkobling.
-
Arbeid hjemmefra: Agenter som jobber hjemmefra kan bruke Internett direkte. De trenger ikke å koble seg til kontornettverket sitt i India ved hjelp av en VPN.
-
Oppbevaring av data: Du er ansvarlig for å laste ned samtaledetaljer (CDR) og revisjonslogger. Disse må lagres på en server i India i minst ett år.
Modell 3: Multinasjonell leietaker med India innenlands kontaktsenter
Oversikt
Følgende retningslinjer gjelder for multinasjonale leietakere som er vert utenfor India, men med et innenlandsk kontaktsenter som betjener India EP-er:
-
Leietaker er registrert utenfor India og har et team av agenter for å betjene EPDN fra flere land, inkludert India.
-
EPDN-nummeret for India er knyttet til et sted i India.
-
Agenter som betjener India EpDNS er fysisk lokalisert i India.
-
Agenter og telefonene deres (enten ut Webex Calling videlsestelefoner eller lokale utvidelser) er koblet til India-lokasjonen.
Administrasjon og konfigurasjon
-
Opprett soner og konfigurer Trusted Network Edge i henhold til Webex Calling retningslinjene for indiske lokasjoner.
-
Fullfør Webex Calling KYC (Know Your Customer) -prosessen for å aktivere plassering i India.
-
Sørg for at alle BYOAI-løsninger knyttet til indiske nummerstrømmer bare kobles til tjenester i India.
-
Etabler en dedikert kø og et team av agenter for å betjene India EP; ikke bland disse agentene med de som håndterer samtaler fra EP-er utenfor India. Denne konfigurasjonen kan oppnås ved å bruke team eller ferdigheter for kontaktsenteragenter.
-
For hver sone:
-
Opprett en Outdial ANI-liste og sett standard ANI til et nummer innenfor den sonen.
-
Knytt Outdial ANI-listen til teamet av agenter som betjener EP-en fra den sonen.
-
Dette oppsettet bidrar til å unngå anropsfeil under utoppringing når agenter bruker standard ANI.
-
Under høflige tilbakeringinger, sørg for at ANI samsvarer med sonen til agenttelefonen i køen.
-
-
Når du oppretter kampanjer, reserver agenter fra en bestemt sone og bruker ANI fra den sonen.
Overholdelse
Følg disse nøkkelkravene innenfor den valgte distribusjonsmodellen for å overholde lokale forskrifter:
-
Kontortilkobling: Hvis agentene dine jobber fra kontoret, må mediene flyte over en dedikert nettverkstilkobling.
-
Arbeid hjemmefra: Agenter som jobber hjemmefra kan bruke Internett direkte. De trenger ikke å koble seg til kontornettverket sitt i India ved hjelp av en VPN.
-
Oppbevaring av data: Du er ansvarlig for å laste ned samtaledetaljer (CDR) og revisjonslogger. Disse må lagres på en server i India i minst ett år.
Konfigurer Webex Contact Center for India-lokasjoner
Forutsetninger
Før du starter oppsettet, må du kontrollere at du oppfyller følgende krav:
-
Regulatorisk dokumentasjon: Du må sende inn Know Your Customer (KYC) og Kundesøk nadsskjema (CAF). Se O versikt over forskrifter for å vite mer om KYC og CAF.
Selv om du allerede har fullført KYC forWebex Calling, kan det være nødvendig med en egen innsending for at Contact Center-tjenester skal overholde Unified Telecom License. -
Plattform: Webex Contact Center India støtter Webex Calling bare. Eldre VPOP eller andre telefonforbindelser støttes ikke.
Konfigurere anrop
Du må først konfigurere telefonimiljøet. For å unngå duplisering av trinn, se følgende Webex Calling artikler for å fullføre basisoppsettet:
-
Soner og klarert kant: Definer nettverkssonene dine for å sikre samsvar med medieopphold. Se avsnittet Opprettet klarert nettverk og Opprett en sone og kant for detaljert informasjon.
Anropsoperasjoner og kontroll over bompengeomkjøring
For å sikre at driften din forblir kompatibel, håndhever Webex Contact Center følgende regler for Toll Bypass:
-
Inngående ruting: Agenter i India kan rådføre seg med en agent utenfor India om et innkommende PSTN-anrop, men de kan ikke overføre eller konferere samtalen.
-
Utgående oppringing: For alle PSTN-samtaler (innenlandske eller internasjonale) må agenter bruke en verifisert India PSTN Caller Line Identification (CLI). De er pålagt å bruke ANI tilknyttet sonen telefonen tilhører, selv om de er konfigurert til å ringe internasjonale samtaler av en administrator.
-
Retningslinjeunntak: Hvis en anropsflyt bryter DoT-forskrifter, vil agenten se en policy unntaksfeil påAgent Desktop, og samtalen avsluttes.
For detaljert informasjon, se Bruk policykonfigurasjon for bompengeom kjøring i Webex Calling seksjonen.
Konfigurer kontaktsenterinnstillinger
Når Calling Foundation er klar, utfører du følgende i Control Hub:
-
Operasjonsland: Gå til Kontaktsenter> Innstillinger> Generelt og sørg for at driftslandet er satt til India
-
Stedskartlegging: Kontroller at kontaktsenterlokasjonene samsvarer med sonene som ble opprettet under oppsettet for samtale.
Konfigurasjonsanbefalinger
Ideelle konfigurasjonsmodeller
For å holde oppsettet kompatibelt og unngå feil, bør du følge en geografisk basert konfigurasjonsmodell.
-
Geografiske team: For å unngå policyfeil anbefaler vi at du konfigurerer konfigurasjonen din ved hjelp av geografiske team. For eksempel, opprett et Bangalore-team og et Chennai-team. Ved å tilordne disse teamene til køer i samme region, vil du sikre at systemet oppfører seg som forventet, og at agenter ikke utløser unødvendige bompengebegrensninger.
-
Køtilordning: Ikke tilordne et team fra en region til en kø i en annen region hvis det bryter DoT-regler. For eksempel, ikke tilordne et USA-basert team til en indisk kø.
-
Logikken: Ved å koble team til bestemte områder og køer i samme region, er det mindre sannsynlig at du utløser en policyfeil. Systemet er designet for å beskytte seg selv, men en smart design gjør administratorens jobb mye enklere.
ANI-ruting og konfigurasjon
Administrering av automatisk nummeridentifikasjon (ANI) er avgjørende. Hvert nummer må tilordnes en inngående EP. For multinasjonale leietakere har vi forbedret Outdial ANI-listen slik at du kan angi en regional standard. Dette sikrer at agenter i India ikke ved et uhell bruker en global leietakerstandard som bryter med lokale regler.
-
Kartleggingsnumre: For å bruke et tall som ANI, må det først tilordnes en inngående EP.
-
Utgående EP: Agenter tildeles en utgående EP og en ANI-liste (eller de kan bruke en standard ANI).
-
Regionale begrensninger: ANI er tilordnet en innkommende EP, som gir RTMS-regionen (Real-Time Media Service) og plasseringen. Webex Calling Denne plasseringen definerer standard PSTN for den regionen.
-
Administratorkontroll: Administratorer bør kontrollere tilgangen til utgående ANI-er for å sikre at agenter i India ikke bruker en standard ANI utenfor regionen.
Eksempel på flyt for innkommende anrop
Anrop på nettet
Når et internt anrop på nettet kommer inn (for eksempel til en IT-støttelinje), følger systemet en bestemt vei for å forbli kompatibel.
-
Stien: Samtalen går inn gjennom et bestemt sted (som Bangalore Zone) og beveger seg gjennom EP til køen.
-
Teamlevering: Anropet blir deretter dirigert til et team. Interne nett-samtaler er fleksible og kan leveres til en agent i India, en agent som roaming utenfor India, eller til og med en agent konfigurert utenfor India — så lenge de bruker en Webex Calling (wxC) utvidelse og ikke en PSTN-telefon (Public Switched Telephone Network).
-
PSTN-begrensninger: Merk at disse interne samtalene ikke kan rutes til PSTN-destinasjoner eller MS-team, da de anses utenfor omfanget for dette spesifikke oppsettet.
Off-net-samtale
Når et anrop kommer inn fra PSTN, håndhever systemet strenge kontroller for omkjøring av bompenger for å sikre samsvar.
-
Stien: Anropet går gjennom en bestemt PSTN-sone (som Bangalore Zone) og beveger seg gjennom EP til køen.
-
Teamlevering: Systemet validerer agentens plassering mot PSTN-sonen. Hvis agenten er i riktig sone (f.eks. Bangalore) og ikke roamerer, er samtalen tillatt. Hvis systemet oppdager at agenten befinner seg på et ugyldig sted eller et sted utenfor sonen (f.eks. New York), er samtalen begrenset.
-
Systemhandling: Når en samtale blokkeres på grunn av et policybrudd, returnerer systemet automatisk den som ringer til køen og viser en policyfeilmelding på agentens skrivebord.
-
Beste praksis: For å unngå disse blokkeringene, bruk Teams i Webex Contact Center for å tildele agenter strengt til de riktige nettstedene og køene.
Agentatferd og policyunntak
Forstå bompengebegrensninger og atferd på skrivebordet
Når en samtale eller operasjon bryter Indias DoT-regler, utløser systemet en bompengebegrensning. Slik opp Agent Desktop fører de seg i forskjellige scenarier.
Avvisning av innkommende anrop
Hvis et innkommende anrop bryter en policy, ser agenten en feil, og tilstanden endres til Anropsbegrensning. For utadvendte eller konsultasjonsavslag endres imidlertid ikke tilstanden deres. Dette skjer hvis de bruker en PSTN-telefon (Public Switched Telephone Network), WebRTC, eller er på roaming utenfor India.
-
Hvorfor det skjer:
-
Agenten bruker et PSTN-telefonnummer.
-
Agenten bruker WebRTC til å håndtere en India-basert samtale.
-
Agenten bruker en Webex-utvidelse, men streifer utenfor India. (Systemet utfører et Geo-IP-oppslag for å avgjøre om telefonen er fysisk i eller utenfor landet).
-
Agenten som bruker en PSTN-telefon konsulteres av en annen agent.
-
Utgående (utgående) avslag
Hvis et utgående anrop avvises, ser agenten en policyfeil, men tilstanden endres ikke.
-
Hvorfor det skjer:
-
Agenten prøver å bruke en ANI fra en annen sone.
-
Agenten bruker en PSTN-telefon.
-
Agenten bruker WebRTC mens han prøver å ringe en kunde i India.
-
Konsultasjons- og overføringsfeil
Hvis en konsultasjon eller overføring til en DN eller en annen agent mislykkes, ser agenten en policyfeil, men tilstanden endres ikke.
-
Hvorfor det skjer:
-
Personen som blir konsultert bruker en PSTN-telefon.
-
Personen som blir konsultert bruker WebRTC.
-
Agenten som mottar overføringen er fysisk lokalisert utenfor India.
-
Skrivebord: Deaktiverte knapper og verktøytips
For å forhindre feil, deaktiverer skrivebordet ofte overførings- og sammenslåingsknappene hvis systemet bestemmer at operasjonen ikke er tillatt.
-
Hvis du holder musepekeren over en deaktivert knapp, vises et verktøytips som forklarer årsaken.
-
I sjeldne tilfeller kan tilstanden til en samtale endres mens en konsultasjon allerede pågår. Hvis denne endringen fører til at samtalen bryter med India Toll Restriction-regler, vil systemet ikke tillate tilkoblingen å fortsette. Når dette skjer, kan anropsbenene bli droppet, eller operasjoner som Overføring eller Konferanse mislykkes - selv om knappene på skrivebordet ikke er deaktivert ennå.
Veilederovervåking
En veileders forespørsel om å overvåke et anrop vil bli avvist hvis en bompengebegrensning utløses.
-
Hvorfor det skjer:
-
Veilederen bruker en PSTN-telefon.
-
Veilederen bruker en Webex-utvidelse fra et sted utenfor India.
-
| Operasjon | Scenario | Systemhandling | Agentopplevelse |
|---|---|---|---|
| Innkommende anrop | Ring fra India-regionen til en agent i New York. | Blokkert. Systemet oppdager et sonebrudd. | Agent mottar en feilmelding; anropet går tilbake til køen. |
| Konsultasjon | India-basert agent konsulterer en ikke-India-agent. | Tillatt. Du kan snakke med den andre agenten. | Normal konsultasjonsatferd. |
| Overføring | India-basert agent prøver å overføre en indisk samtale til en amerikansk agent. | Blokkert. Dette ville bryte DoT-reglene. | Overføring mislykkes; agenten ser en samsvarsfeil. |
| Roaming | Agent i et indisk team prøver å ta en samtale mens han streifer i utlandet. | Blokkert. Systemet sjekker agentens plassering. | Anropet vil ikke gå gjennom; feilmelding vises. |
| Outbound/Kampanje | Agent prøver å bruke en ANI fra en annen region. | Blokkert. | Anropet vil ikke gå gjennom; feilmelding vises. |
Feilhåndtering og Aux-koder
Teknisk feil og AUX-kodehåndtering
Når en samtale blir avvist på grunn av en India-bompengebegrensning, bruker systemet spesifikke tekniske koder for å identifisere problemet. Dette hjelper med feilsøking i loggene og lar deg bygge smartere logikk i samtaleflytene dine.
SIP og systemidentifikatorer
Hvis du ser på de tekniske loggene eller SIP-overskriftene (Session Initiation Protocol) (spesielt i SIP BYE- eller SIP 403-meldinger), vil du se anropet merket som:
-
SIP-topptekst: x-cisco-RTMS: sonebegrenset feil
-
Systemårsak: CALLING_RESTRICTION
-
Årsakskode: 119
Ny agent AUX-kode
Vi har lagt til en ny systemdefinert Idle AUX-kode for agenter som får en bompengebegrensningsfeil. Hvis en agent blokkeres fra et anrop på grunn av samsvarsregler, endres tilstanden automatisk til denne nye koden:
-
AUX-kode: calling_restriksi
Bruke Code 119 i Flow Designer
Du kan bruke den nye årsakskoden 119 (CALLING_RESTRICTION) til å håndtere feil automatisk i anropsflytene dine. Ved å se etter denne spesifikke feilkoden, kan du bestemme den neste beste handlingen i ulike Flow-aktiviteter, for eksempel:
-
BridgeTransfer eller BlindTransfer: Hvis en overføring mislykkes med kode 119, kan du skripte flyten for å prøve en annen rute eller spille av en bestemt kunngjøring til den som ringer.
-
Utgående kampanjer: Bruk denne koden til å finne ut om et kampanjeanrop ble blokkert av en policybegrensning, og håndter oppføringen deretter.
Begrensninger
ANI og Outdial Management
-
Sonejustering: Bruk alltid ANI og agenter fra samme sone for:
-
Høflig tilbakeringing: ANI for tilbakeringing må samsvare med agentens reguleringssone.
-
Utgående ANI-lister: ANI-er i en utløpsliste må samsvare med sonen til agentene som er tilordnet den skrivebordsprofilen.
-
Kampanjer: Sørg for at kampanjen ANI og tildelte agenter befinner seg i samme sone.
-
-
Standard ANI: Du må velge en ANI i outdial-listen som standard ANI.
-
Ingen tilpassede ANI: Bruk av tilpassede ANI er forbudt i India. Bruk av egendefinerte ANI-er vil forårsake uttaksfeil og skape revisjonsforvirring i Webex Calling samtaledetaljeposter (CDR).
Agenttilkobling og verktøy
-
WebRTC: Dette støttes for BPO-agenter, men det støttes ikke hvis en agent har tilgang til India PSTN.
-
Utvidelser: Agenter må alltid bruke sin tildelte Webex Calling utvidelse for alle kontaktsenteraktiviteter.
-
Arbeid hjemmefra (WFH): Hvis agenter jobber hjemmefra, ber du dem om å bruke en VPN-tilkobling til det konfigurerte kontorstedet for å opprettholde samsvar med den tildelte reguleringssonen.
-
Flere kontorer: Organisasjoner med flere kontorer må ha en PSTN-stamme i hver sone hvis agenter i den spesifikke sonen krever eksterne funksjoner.
Teknisk og feilhåndtering
-
Lokale konfigurasjoner: For lokale agentkonfigurasjoner er leietakeradministratoren ansvarlig for å sikre at den lokale PBX-en overholder India Toll-begrensninger.
-
Agent Idle Codes: En ny systemverdi for Agent Idle Codes er introdusert for India-regionen for å spore tilstander for overholdelse av forskrifter.
-
Overføringsfeilkoder: Aktiviteter som Bridge Transfer eller Blind Transfer vil returnere nye feilsvarskoder hvis en bompengebegrensning brytes.
-
Referanse: Hvis du vil ha et sammendrag av feilkoder, kan du se Flow Designer Guide: Bridge and Blind Transfer Activities.
-
Dataopphold og revisjon
-
Medieforankring: Media for innenlandske samtaler er forankret i India og kan ikke forlate landet .
-
Lagring: Samtaleopptak og transkripsjoner for India-baserte leietakere lagres i India Data Center.
-
CDR-revisjon: Webex Calling CDR-er fanger opp all informasjon om innringere. Sørg for at ANI-er er konfigurert riktig for å unngå avvik under DoT-revisjoner.