Det første trinnet i overgangen til er å sikre pålitelig og sikker internettforbindelse mellom det lokale nettverket og skyen.

Siden de fleste organisasjoner kobler seg til internett gjennom én eller flere brannmurer eller sikkerhetsenheter, er det viktig å validere at de nødvendige trafikkflytene støttes.

Nettverks- og sikkerhetsadministratorer må forstå disse flytene med tanke på:

• Retning (inngående vs. utgående)

• Protokoller (Eksempel - SIP TLS, SRTP, HTTPS)

• IP-adresseområder brukt av tjenester

• Portnumre som må åpnes eller tillates.

Dette sikrer at bedriftens brannmurer, NAT-enheter og annen nettverksinfrastruktur er riktig konfigurert for å håndtere trafikk, samtidig som bedriftens sikkerhetspolicyer opprettholdes.

For informasjon om nødvendige flyter, inkludert IP-adresse, porter og protokoller, se Portreferanseinformasjon for Webex Calling. Bruk denne informasjonen til å konfigurere brannmuren, proxy-tjenere og annen nettverksinfrastruktur i den eksisterende distribusjonen for å aktivere nettverksflyter.

Desentralisert internettutbrudd fra hver filial eller lokasjon er den anbefalte tilnærmingen for skybaserte samarbeidstjenester som . Ved å tillate trafikk å gå ut lokalt, gjør denne modellen følgende:

• Reduserer tur-retur-forsinkelse og jitter, noe som forbedrer den generelle samtalekvaliteten

• Skalerer effektivt etter hvert som flere brukere og nettsteder går over til

• Fungerer sømløst med SD-WAN, som dynamisk kan rute økter til nærmeste skytilkoblingspunkt for optimal ytelse

• Lar sporing av brukerposisjon basert på deres offentlige IP-adresse, noe som hjelper med analyse av mediebaner og feilsøking.

I tillegg må organisasjoner sørge for tilstrekkelig internettbåndbredde på hvert sted. Båndbredden bør dimensjoneres basert på forventet antall samtidige samtaler, den valgte kodeken (f.eks. Opus eller G.711), pluss overhead for signalering, retransmisjoner og vekst. Dette samsvarer med forberedelsesfasen i PPDIO-livssyklusen og etablerer et solid grunnlag for migrering.

Den innledende oppsettdelen i implementeringsfasen av utrullingen er grunnleggende for å etablere et godt strukturert og håndterbart skyanropsmiljø. Denne fasen omfatter kritiske oppgaver som å sette opp organisasjonen, anskaffe og tildele lisenser, og verifisere og gjøre krav på bedriftens domener for å sikre riktig brukeradministrasjon og sikkerhet. I tillegg inkluderer den klargjøring av lisensmaler for å automatisere tildeling av brukerlisenser, konfigurering av enkel pålogging (SSO) for å effektivisere brukerautentisering og forbedre sikkerheten, og justering av tjeneste- og klientinnstillinger for å samsvare med organisasjonens retningslinjer og brukerbehov. Ved å fullføre disse innledende oppsettaktivitetene sikrer du at miljøet er riktig konfigurert for skalerbarhet, sikkerhet og en sømløs brukeropplevelse, noe som legger grunnlaget for påfølgende utrullings- og driftsfaser.

I implementeringsfasen representerer det å gjennomføre en pilotmigrering en kritisk milepæl i valideringen av overgangen fra til . Denne piloten innebærer å klargjøre et representativt delsett av brukere på tvers av ett eller flere steder på plattformen, og sikre at den valgte populasjonen gjenspeiler ulike brukstilfeller og organisasjonsroller. Parallelt med brukermigrering må viktige samarbeidstjenester, inkludert telefonsvarer, automatiske svarere, anropskøer og søkegrupper, overføres til tilsvarende tjenester for å opprettholde forretningskontinuitet og tjenestefunksjonalitet.

Pilotmigreringen bør utnytte den samme kombinasjonen av Cisco-leverte verktøy og tredjeparts migreringsverktøy som er planlagt for den bredere organisasjonsdistribusjonen, og sikre at prosessene, automatiseringsarbeidsflytene og integrasjonspunktene valideres grundig under representative forhold.

Hovedmålene med denne pilotutplasseringen er todelt: for det første å validere og forbedre de komplette overgangsprosessene, inkludert arbeidsflyter for brukerklargjøring, prosedyrer for datamigrering og konfigurasjoner av endepunkter; og for det andre å verifisere funksjonaliteten til migrerte tjenester under reelle driftsforhold.

Denne faseinndelte tilnærmingen lar prosjektteamet identifisere og utbedre eventuelle tekniske eller prosedyremessige problemer i et kontrollert miljø, samle tilbakemeldinger fra brukere om den nye plattformopplevelsen, vurdere effektiviteten til utvalgte migreringsverktøy og etablere tillit til migreringsmetodikken før de fortsetter med bredere organisatorisk utrulling.

Innsikten som er oppnådd i løpet av denne pilotfasen er avgjørende for å optimalisere påfølgende migreringsbølger og sikre en smidig og risikoredusert overgang for hele bedriften.

For å anskaffe PSTN-tjenester for , velg først et PSTN-tilkoblingsalternativ i .

Hvis en organisasjon planlegger å opprettholde hybrid dobbel samtalekontroll ( fase 1 i figur Faset overgang til samtale: Hybrid og sky) enten midlertidig eller på ubestemt tid, må de distribuere én eller flere lokale gatewayer for lokale PSTN for å tillate anrop mellom og endepunkter.

Hvis en fullstendig overgang ( fase 2) til skyen er det endelige målet, inkludert PSTN, vil enten en Cisco-anropsavtale eller et Cloud Connect-alternativ være nødvendig for PSTN.

Samarbeid med den valgte leverandøren for å bestille og portere telefonnumre før du konfigurerer dem i . Det er kun mulig å bestille telefonnumre eller igangsette portbestillinger required/possible for lokale PSTN og Cloud Connect for . For Cisco Calling Plans startes bestilling og portering fra Control Hub så snart plasseringen er opprettet, og i land der Cisco Calling Plan er tilgjengelig. Hvis du vil ha mer informasjon om Cisco Calling-abonnementer, kan du se Komme i gang med Cisco-abonnementene.

Som en del av PSTN-implementeringen må du sørge for at leverandøren din har aktivert både innkommende og utgående PSTN-tjenester for din lokasjon. I tillegg bør du utføre testanrop for å bekrefte at anropene rutes riktig gjennom den valgte PSTN-tilkoblingen.

Før du legger til brukere og enheter i , må du klargjøre anropssteder. For hvert sted må det oppgis en gyldig gateadresse. I USA og Canada valideres og brukes denne adressen av plattformen til å sende PIDF-LO-posisjonsinformasjon for nødanrop.

Når du konfigurerer steder som bruker lokalt PSTN, må du konfigurere de lokale gatewayene deretter. I må en trunk og en rutegruppe opprettes for hver lokale gateway, og rutegruppen tilordnes deretter som PSTN-valg for lokasjonen. Cisco anbefaler på det sterkeste at du alltid velger en rutegruppe som PSTN-valg, da denne tilnærmingen lar deg enkelt legge til flere trunker i fremtiden, noe som støtter både skalerbarhet og redundans. Cisco anbefaler også å aktivere dobbel identitet og P-Charge-Info-støtte på alle PSTN-trunker, siden dette forenkler identifiseringen av den fakturerbare parten for utgående direkte eller viderekoblede anrop. Hvis PSTN-leverandøren din bruker en annen faktureringshode, kan du kopiere informasjonen fra P-Charge-Info-hodet på den lokale gatewayen til det nødvendige faktureringshodet.

For steder som bruker Cloud Connect for eller Cisco-anropsabonnementet som PSTN-alternativ, velger du ganske enkelt det respektive PSTN-valget for stedet under oppsettet. Hvis lokasjonen bruker enten Cloud Connect for eller lokal PSTN, må du legge til telefonnumrene som ble bestilt i forrige trinn. Numre kan legges til som inaktive hvis du ikke vil at de skal inkluderes i samtalerutingen med en gang. Du kan aktivere disse numrene senere når de tilordnes brukere eller funksjoner.

Det er viktig å alltid angi hovednummeret for hvert sted. Hovednummeret kan tilordnes enten en bruker eller en funksjon, for eksempel en automatisk svarer. For å aktivere telefonsvarer på stedet, sørg for å angi pilotnummeret for telefonsvarer, også kjent som taleportalnummeret.

Ytterligere innstillinger for å ringe til steder inkluderer konfigurering av detaljer for nødanrop, for eksempel nødnummeret for tilbakeringing, varslingsalternativer og forbedrede funksjoner for nødanrop. Du bør også gjennomgå og justere opptaksinnstillinger, språkpreferanser og enhetskonfigurasjoner etter behov for hvert sted. Hvis organisasjonen din bruker forkortet internoppringing på nettet med signifikante numre i bedriften, husk å konfigurere en unik stedskode for stedet i de interne oppringingsinnstillingene. Til slutt, hvis ekstern oppringing krever et utgående siffer, må du sørge for å angi dette i innstillingene for ekstern oppringing. Når et utgående oppringingssiffer er konfigurert, anbefaler Cisco at man aktiverer håndheving av utgående oppringingssiffer for å sikre konsistens.

For å integrere med lokal samtalekontroll er det nødvendig å konfigurere trunker, rutegrupper, oppringingsplaner for bedrifter og både lokasjons- og globale innstillinger. Begynn med å sette opp trunkene og lokale gatewayene som er beregnet for sammenkobling med det lokale samtalekontrollsystemet. Dette trinnet er bare nødvendig hvis dedikerte trunker er nødvendige. Hvis eksisterende trunker og rutegrupper er tilstrekkelige for utrullingen din, kan de brukes på nytt for den lokale sammenkoblingen uten ytterligere konfigurasjon.

Når trunkene og rutegruppene er etablert, fortsett med å opprette bedriftens oppringingsplaner og tilordne riktig rutegruppe som destinasjon for hver oppringingsplan. Når integrering involverer flere lokale samtalekontrollsystemer koblet til via forskjellige trunker, vil det være nødvendig med flere oppringingsplaner. Det er viktig å sørge for at disse oppringingsplanene bare inneholder mønstrene som er nødvendige for å rute samtaler til lokale destinasjoner.

Hvis utrullingen din krever støtte for ruting av ukjente utvidelser, bør denne funksjonen aktiveres på lokasjonsnivå. I tillegg, når ruting av ukjent internnummer er aktivert, må du angi maksimal ukjent internnummerlengde i delen Samtaleruting mellom og lokaler i innstillingene for anropstjenester i . Dette sikrer sømløs samtaleruting og riktig håndtering av internnummerbaserte oppringingsscenarioer i ditt integrerte miljø.

Når du migrerer brukere fra til, kan det hende at du ikke kan flytte alle brukerne samtidig. Dette kan skyldes flere årsaker, inkludert, men ikke begrenset til, antall nettsteder eller brukere, hvor lang tid det tar å overføre et nettsted and/or gruppe brukere samtidig, begrensede IT- eller nettstedsressurser til å støtte endringsvinduet, varighet av endringsvinduet, endringens kompleksitet osv.

Når du migrerer brukere i faser, er det viktig å identifisere hvilke brukere som må migrere sammen i samme batch. Hovedmålet er å migrere brukere som er avhengige av hverandre for sine ringetjenester og -funksjoner, sammen. Du vil sørge for at alle ringefunksjonene deres (eksempel - samtalekøer) er fullt funksjonelle slik de var før overgangen.

Selv om du implementerer kallingssamarbeid mellom og med lokale gatewayer, kan du ikke dele delte tjenester eller funksjoner på tvers av denne forbindelsen. Derfor må du identifisere avhengighetene mellom brukere ved å se på funksjoner som:

• Overvåking av andre brukere ved hjelp av BLF-er

• I samme jaktpilot, anropskø osv.

• Delte linjer

• Bruk av samtalehenting

• Bruker de samme parkeringsnumrene for samtaler

• Intercom

• Executive/Admin.

Et eksempel kan være en bruker som er en del av en jaktgruppe som blir overført til . Denne brukeren vil gå over til med jaktgruppen og med alle andre medlemmer av jaktgruppen. Derfor kan Hunt Group og medlemmene deres svare på anrop på den nye plattformen etter overgangen.

Dette blir mer utfordrende når brukere er koblet til forskjellige brukergrupper for forskjellige ringetjenester og -funksjoner. Dette vil kreve overføring av mer enn én brukergruppe og én anropstjeneste samtidig.

Bruk resultatet fra Migration Insights-verktøyet eller et tredjepartsverktøy du brukte i forberedelsesfasen for å bestemme hvilke brukere og funksjoner som skal grupperes sammen. Dette resultatet burde ha blitt brukt til å utvikle migreringsplanen din, og det vil gi deg innsikt i hvordan du grupperer brukere og funksjoner som må overføres sammen.

De viktigste trinnene når du overfører en gruppe brukere er:

• Identifisere brukere som skal migreres sammen

• Bekreft at alle brukere er inne

• Bekreft at alle TN-er for brukerne finnes i

• Bekreft riktig telefonnummerformat i katalogen

• Sørg for at lisens- og innstillingsmalen for brukergruppene er riktig konfigurert.

• Verifisere eller konfigurere alle anropstjenester og -funksjoner for brukergruppen (før eller under overgangen, etter behov)

• Legg til brukere i gruppen med brukere som er aktivert for anrop i bedriftskatalogen

• Utnytt verktøy – verktøy for migrering av brukere og funksjoner and/or tredjepartsverktøy

• Disable/Delete user/device katalognummer og oppringing features/services på etter overgangen.

Etter at en gruppe brukere er migrert, test et delsett av brukerne for å bekrefte at alle anropsfunksjonene og -tjenestene deres fungerer som de skal. Hvis anropsfunksjoner som anropskø, søkegrupper osv. overføres med brukergruppen, må du teste at disse anropstjenestene fungerer som de skal.

I refererer et arbeidsområde til et delt sted (som et konferanserom, et møterom eller en hot desk) som kan tilordnes enheter, utvidelser og brukere. I motsetning til tradisjonelle Unifed CM-telefoner er arbeidsområdene:

• Stedssentrert: knyttet til fysiske rom.

• Enhetsfleksibel: kan ha én eller flere enheter (bordtelefoner, tavler osv.).

Når arbeidsområder er identifisert som en del av overgangen til , kan de legges til under Enheter. Hvert arbeidsområde trenger en enhetstildeling, og hvis de allerede er i Unified CM, må de tilbakestilles eller klargjøres på nytt. Funksjoner som talepost, viderekobling og henting av anrop kan aktiveres eller deaktiveres, og policyer kan brukes for videosamtaler, samtaleparkering og mobilitet etter behov. Test hvert arbeidsområde ved å foreta interne og eksterne samtaler, og teste video-, konferanse- og mobilitetsfunksjoner. Til slutt, informer brukerne om eventuelle gjeldende prosesser for arbeidsplassenheter og bestillinger.

Hvis du vil ha mer informasjon om arbeidsområder i Arbeidsområder.

Telefoner som for øyeblikket er registrert til, må migreres til som en del av skyovergangen. For å gjøre migreringen så enkel som mulig med minimal sjanse for feil, anbefaler Cisco å migrere fysiske steder eller avdelinger samtidig. Du kan imidlertid bli bedt om å migrere brukere i grupper på grunn av funksjonsavhengigheter. Se avsnittet Migrer brukere i grupper for mer informasjon.

Alle støttede telefoner du må gå over fra, må konfigureres som en bruker eller et arbeidsområde, og den fysiske telefonen må konfigureres på nytt for å registrere seg hos . I tillegg må fastvaren for telefonene i 7800- og 8800-serien oppgraderes fra Enterprise-fastvare til Multiplatform Phone (MPP)-fastvare. Denne prosessen inkluderer lasting av overgangsfastvare før lasting av MPP-fastvaren som kreves for registrering. Det krever også riktig migrasjonstillatelse. Cisco har forbedret denne prosessen de siste årene for å gjøre det enklere for deg å oppgradere Enterprise-telefonene dine til MPP-firmware. Hvis du vil ha mer informasjon om trinnene for å fullføre fastvareoppgraderingen, kan du se Konverter Cisco 7800- og 8800-seriens IP-telefoner mellom Enterprise- og MPP-fastvare.

I tillegg til trinnene som er beskrevet i denne artikkelen, finnes det et innebygd verktøy, Migrer telefonen din til Webex Calling, som du kan bruke til å migrere 7800- og 8800-telefonene dine fra Enterprise- til MPP-fastvare. Dette verktøyet lar deg også legge til telefonene og tilordne dem til de riktige brukerne eller arbeidsområdene. Hvis du vil ha mer informasjon om bruk av verktøy, kan du se Migrer telefonen din.

For telefoner i 9800-serien som er registrert med ovennevnte krav til fastvaremigrering gjelder ikke. Disse telefonene kjører PhoneOS, som støttes av både og . For å overføre disse telefonene til deg må du legge dem til i Webex Calling, tilordne dem til en bruker eller et arbeidsområde og deretter tilbakestille telefonene til fabrikkinnstillinger. PhoneOS-oppstartssekvens for registrering Figuren nedenfor viser PhoneOS-oppstartssekvensen og hvordan telefonen registreres når den er lagt til, selv om telefonen fortsatt er klargjort på and/or DHCP-alternativer (eksempel - 150) er i bruk.

støtter fabrikktilbakestilling av PhoneOS-enheter for å tillate Zero-Touch-onboarding til. administratorer kan eksternt tilbakestille fabrikkinnstillingene for 9800- og 8875-telefonene via CUCM-administrasjonssidene, noe som eliminerer behovet for fysisk tilgang til telefonene for å logge inn på telefonene til. Denne funksjonen støttes med enhetspakkene fra 9. september 2025:

• CUCM v15 – Unified Communications Manager versjon 15

• CUCM v14 – Unified Communications Manager versjon 14.

Hvis du vil ha mer informasjon om registreringsprosessen for 9800-serien, kan du se Registreringsprosess.

I tillegg til Cisco IP-telefoner kan det være nødvendig med klargjøring av andre enheter som analoge telefonadaptere (ATA-er), trådløse telefoner (WiFi, DECT), videoenheter, talegatewayer og^{tredjepartsenheter og} -telefoner . Mange av disse enhetene har ikke en fastvareoppgraderingsbane som IP-telefoner for å overføre dem fra bedriftsfastvare til skyfastvare. Derfor skal du klargjøre hver av disse enhetene i Control Hub. Noen av disse kan ikke overføres til, og den tilsvarende modellen må erstatte den (f.eks. ATA 191/192) og andre vil kreve manuell omkonfigurering and/or programvareendringer.

• Talegatewayer – Hvis du vil migrere den lokale gatewayen din, kan du se Migrere lokal gateway.

  Hvis du vil ha mer informasjon om hvordan du konfigurerer talegatewayen VG400, VG410 eller VG420 i Control Hub, kan du se Lokal gateway

• Analog telefonadapter (ATA) – For å komme i gang med Cisco ATA 191 og 192, se Cisco ATA.

• Trådløs Wifi-telefon – For å integrere trådløs telefon 840 og 860, se Integrer trådløs Webex-telefon.

• DECT trådløse telefoner – For å komme i gang med den nye Cisco IP DECT 6800-serien, se Cisco IP DECT.

  For å bygge og administrere et digitalt DECT-nettverk i Control Hub, se Administrere DECT-nettverk

  Hvis du vil ha mer informasjon om Cisco IP DECT 6800, kan du se Implementeringsveiledning

• ^{Tredjepartsenheter og -telefoner} – Samarbeid med tredjepartsleverandører^{på device/phone krav og prosessen for å migrere eller erstatte dem for å støtte .}

Eventuelle nødvendige anropsfunksjoner må klargjøres før eller under overgangen. Som omtalt i delen Migrer brukere i grupper, må anropsfunksjonene konfigureres og overføres når brukerne som bruker dem overføres.

Hvis du vil ha mer informasjon om hvordan du konfigurerer hver av funksjonene, kan du se de tilhørende hjelpeartiklene for konfigurasjon.

• Automatiske svarere – For å administrere automatiske svarere, se Automatiske svarere

• Samtaleparkering – For å administrere samtaleparkering, se Samtaleparkering

• Samtalehenting – For å konfigurere samtalehentingsgruppen, se Samtalehenting

• Samtalekøer – For å konfigurere samtalekøen, se Samtalekø

• Jaktgrupper – For å administrere jaktgrupper, se Administrer jaktgruppe

• Driftsmoduser – For å se anropsruting basert på driftsmoduser, se Anropsruting basert på driftsmoduser

• Personsøkergrupper – For å konfigurere en personsøkergruppe, se Konfigurer en personsøkergruppe

• Opptak – For å administrere samtaleopptak for , se Administrer opptak

• Enkeltnummerkontakt – For å konfigurere enkeltnummerkontakt (hvor som helst på kontoret), se Konfigurer enkeltnummerkontakt

• Talepostgruppe – Hvis du vil administrere en delt talepost og innkommende faksboks for , se Administrer talepost.

Aksepttesting sikrer at det migrerte miljøet oppfyller de funksjonelle kravene, fungerer som forventet og gir en sømløs brukeropplevelse på tvers av alle kommunikasjonsarbeidsflyter. Denne valideringsprosessen er mangesidig og dekker alt fra brukerklargjøring og nummertildelinger til driftsytelsen til avanserte ringefunksjoner.

Denne delen gir eksempler og fremhever viktige aspekter å vurdere under aksepttesting; den er imidlertid ikke ment å tjene som en uttømmende eller omfattende sjekkliste.

Brukerklargjøring og nummertildeling

Et grunnleggende aspekt ved aksepttesting innebærer å verifisere at alle brukere er klargjort nøyaktig og fullstendig i . Dette krever en grundig sammenligning mellom kildekatalogen () og den nylig etablerte brukerbasen for å sikre at alle brukerkontoer, sammen med tilhørende attributter som internnumre og direkte innringing (DID)-tildelinger, har blitt riktig migrert. Fullstendig klargjøring er avgjørende ikke bare for drift fra dag én, men også for løpende administrasjon og støtte.

Validering av nummertildeling inkluderer å bekrefte at hver bruker er tildelt riktig internnummer og eksternt nummer, og at disse numrene rutes riktig i både interne (på nettet) og eksterne (PSTN) samtaleflyter. Det er viktig å sjekke for eventuelle overlappinger, manglende tildelinger eller feilkonfigurasjoner som kan føre til feil i samtalerutingen eller avbrudd i tjenesten.

PSTN-anropsflyt og presentasjon av nummerpresentasjon

En robust prosedyre for aksepttesting må omfatte ende-til-ende-validering av PSTN-anropsflyter. Dette inkluderer både innkommende og utgående anropsscenarioer. For innkommende PSTN-anrop bør testteamet bekrefte at anropene leveres til de tiltenkte endepunktene, enten det er individuelle brukere, anropskøer, søkegrupper eller automatiske svarere. Utgående PSTN-anrop må foretas på riktig måte, med særlig vekt på korrekt levering og presentasjon av informasjon om innringer-ID. Dette innebærer å sørge for at riktig navn og nummer på den som ringer vises til eksterne mottakere, i samsvar med organisasjonens retningslinjer og regulatoriske krav.

Testing bør også ta for seg failover-scenarioer, som håndtering av utilgjengelige endepunkter eller nettverksforstyrrelser. Dette bidrar til å bekrefte at reservemekanismer og alternativ ruting fungerer som de skal, og opprettholder tjenestekontinuitet og pålitelighet.

Samtaleflyter på nettet

Interne, eller nettverksbaserte, samtaleflyter danner ryggraden i bedriftskommunikasjon. Aksepttesting på dette området bekrefter at samtaler mellom brukere i organisasjonen rutes riktig, med funksjoner som overføring, venting, viderekobling og konferanser som fungerer som tiltenkt. Integriteten til oppringingsplaner, tilkobling mellom internlinjer og støtte for organisasjonens anropsregler må bekreftes.

Håndtering av brukeranrop og funksjonsvalidering

Et viktig aspekt ved aksepttesting innebærer å validere hvordan brukere håndterer samtaler ved hjelp av og støttede bordtelefoner. Denne prosessen fokuserer på å bekrefte at de daglige arbeidsflytene for samtaler er intuitive og pålitelige, og at brukerne har sømløs tilgang til kjernefunksjonene som er nødvendige for rollene deres. Testingen bør vurdere hvor enkelt brukere kan ringe og motta samtaler, administrere vent- og gjenopptaksfunksjoner, og utføre både blinde og konsultative overføringer. Det er også viktig å bekrefte at viderekobling, konferanser og andre avanserte funksjoner, som parkering og henting av samtaler eller aktivering av «ikke forstyrr», er lett tilgjengelige og fungerer problemfritt.

Opplevelsen bør evalueres med tanke på klarhet og respons, med tanke på hvordan brukerne samhandler med samtalehistorikk, talepost og integrerte kataloger. Det bør legges ekstra vekt på muligheten til å flytte aktive samtaler mellom enheter og bruke kontroller under samtaler effektivt i applikasjonen eller på fysiske telefoner. Det endelige målet er å sikre at sluttbrukeropplevelsen er konsistent, effektiv og fullt ut støtter organisasjonens kommunikasjonsbehov etter migreringen.

Samtalekøer: Erfaring med agent og veileder

Anropskøer brukes ofte til å håndtere innkommende anrop med høyt volum. Aksepttesting fokuserer her på flere dimensjoner. Først bør det bekreftes at anrop distribueres til agenter i henhold til den konfigurerte kølogikken, for eksempel Round Robin, lengste inaktiv tid eller samtidig ringing. Presentasjonen av køanrop på agentens skrivebord må undersøkes for klarhet og brukervennlighet, slik at agentene effektivt kan motta, sette på vent og overføre anrop.

For veiledere bør skrivebordsopplevelsen evalueres for funksjoner som sanntidsovervåking, innbrudd i samtaler og analyser eller innsikt i køytelse. Dette inkluderer, men er ikke begrenset til, validering av dashbord og rapporteringsverktøy som gir handlingsrettede data om samtalefordeling, agentaktivitet og kømålinger.

Jaktgrupper: Samtalefordeling

Søkegrupper er en nøkkelmekanisme for å distribuere anrop til forhåndsdefinerte sett med brukere. Aksepttesting må bekrefte at anrop rutes til gruppemedlemmer basert på den konfigurerte søkealgoritmen, og at overløp, videresending og manglende svar håndteres i henhold til designet. Det er avgjørende for driftsmessig konsistens og brukertilfredshet å sørge for at gruppemedlemskap og samtaleruting samsvarer med de som tidligere er etablert i .

Automatiske svarere: Kunngjøringer og menyoperasjoner

Automatiske svarere representerer frontlinjen innen automatisert samtalehåndtering. Testingen må dekke avspilling av kunngjøringer, nøyaktigheten av innspilte hilsener og riktig funksjon av menystrukturer. Menyvalg bør på en pålitelig måte dirigere innringere til riktig avdeling, person eller eksterne numre. Testing bør også inkludere ugyldige eller tidsavbruddsscenarier for å bekrefte at innringere får tydelig veiledning eller blir omdirigert som tiltenkt.

Mobilsvar-operasjon

Til slutt er talepostfunksjonaliteten avgjørende for brukeropplevelsen. Aksepttester bør bekrefte at talepostkasser er riktig tilordnet og tilgjengelige, både internt i organisasjonen og eksternt. Muligheten til å ta opp, hente og administrere meldinger må bekreftes, sammen med levering av varsler.