Prvi korak u prelasku na [] je osigurati pouzdanu i sigurnu internetsku povezivost između lokalne mreže i oblaka.

Budući da se većina organizacija spaja na internet putem jednog ili više vatrozidova ili sigurnosnih uređaja, bitno je provjeriti jesu li podržani potrebni tokovi prometa.

Mrežni i sigurnosni administratori moraju razumjeti ove tokove u smislu:

• Smjer (dolazni vs. odlazni)

• Protokoli (Primjer - SIP TLS, SRTP, HTTPS)

• Rasponi IP adresa koje koriste usluge

• Brojevi portova koji moraju biti otvoreni ili dopušteni.

To osigurava da su korporativni vatrozidovi, NAT uređaji i ostala mrežna infrastruktura pravilno konfigurirani za smještaj prometa uz održavanje sigurnosnih politika poduzeća.

Za informacije o potrebnim tokovima, uključujući IP adresu, portove i protokole, pogledajte informacije o referentnim portovima za Webex pozive. Pomoću ovih informacija konfigurirajte vatrozid, proxyje i drugu mrežnu infrastrukturu u postojećem raspoređivanju kako biste omogućili mrežne tokove.

Decentralizirani pristup internetskoj vezi iz svake podružnice ili lokacije preporučeni je pristup za usluge suradnje u oblaku kao što je . Omogućavanjem lokalnog izlaza prometa, ovaj model:

• Smanjuje kašnjenje i podrhtavanje u povratnom toku, poboljšavajući ukupnu kvalitetu poziva

• Učinkovito se skalira kako sve više korisnika i web-mjesta prelazi na

• Besprijekorno radi sa SD-WAN-om, koji može dinamički usmjeravati sesije do najbliže ulazne točke u oblak za optimalne performanse

• Omogućuje praćenje lokacije korisnika na temelju njihove javne IP adrese što pomaže u analizi medijskog puta i rješavanju problema.

Osim toga, organizacije moraju osigurati odgovarajuću propusnost interneta na svakoj lokaciji. Propusnost treba odrediti na temelju očekivanog broja istovremenih poziva, odabranog kodeka (npr. Opus ili G.711), plus dodatnog opterećenja za signalizaciju, ponovne prijenose i rast. To je usklađeno s fazom pripreme životnog ciklusa PPPIO-a i uspostavlja čvrste temelje za migraciju.

Početni pododjeljak postavljanja unutar faze implementacije ključan je za uspostavljanje dobro strukturiranog i upravljivog okruženja za pozivanje u oblaku. Ova faza obuhvaća ključne zadatke poput osnivanja organizacije, nabave i dodjele licenci te provjere i polaganja prava na domene vaše tvrtke kako bi se osiguralo pravilno upravljanje korisnicima i sigurnost. Osim toga, uključuje pružanje predložaka licenci za automatizaciju dodjele korisničkih licenci, konfiguriranje jednokratne prijave (SSO) za pojednostavljenje provjere autentičnosti korisnika i poboljšanje sigurnosti te prilagođavanje postavki usluga i klijenata kako bi se uskladile s organizacijskim pravilima i potrebama korisnika. Dovršetak ovih početnih aktivnosti postavljanja osigurava da je okruženje pravilno konfigurirano za skalabilnost, sigurnost i besprijekorno korisničko iskustvo, postavljajući temelje za sljedeće faze implementacije i rada.

Tijekom faze implementacije, izvršavanje pilot migracije predstavlja ključnu prekretnicu u validaciji prijelaza s na . Ovaj pilotni projekt uključuje pružanje usluge reprezentativnom podskupu korisnika na jednoj ili više lokacija na platformi, osiguravajući da odabrana populacija odražava različite slučajeve upotrebe i organizacijske uloge. Paralelno s migracijom korisnika, bitne usluge suradnje, uključujući govornu poštu, automatske telefonske sekretare, redove poziva i grupe za pretraživanje, moraju se prebaciti na njihove ekvivalente kako bi se održao kontinuitet poslovanja i funkcionalnost usluge.

Pilot migracija trebala bi iskoristiti istu kombinaciju alata koje pruža Cisco i uslužnih programa za migraciju trećih strana koji su planirani za širu organizacijsku implementaciju, osiguravajući da su procesi, tijekovi rada automatizacije i točke integracije temeljito validirani u reprezentativnim uvjetima.

Primarni ciljevi ovog pilotnog projekta su dvostruki: prvo, validirati i poboljšati procese tranzicije od početka do kraja, uključujući tijekove rada za pružanje usluga korisnicima, postupke migracije podataka i konfiguracije krajnjih točaka; i drugo, sveobuhvatno provjeriti funkcionalnost migriranih usluga u stvarnim operativnim uvjetima.

Ovaj fazni pristup omogućuje projektnom timu da identificira i otkloni sve tehničke ili proceduralne probleme u kontroliranom okruženju, prikupi povratne informacije korisnika o novom iskustvu platforme, procijeni učinkovitost odabranih alata za migraciju i uspostavi povjerenje u metodologiju migracije prije nego što nastavi sa širim organizacijskim uvođenjem.

Uvidi stečeni tijekom ove pilotne faze ključni su za optimizaciju sljedećih valova migracije i osiguravanje glatke tranzicije s ublažavanjem rizika za cijelo poduzeće.

Za nabavu PSTN usluga za , prvo odaberite opciju PSTN povezivosti u .

Ako organizacija planira održavati hibridnu dvostruku kontrolu poziva ( faza 1 na slici Fazni prijelaz pozivanja: Hibridni i oblačni) privremeno ili na neodređeno vrijeme, morat će implementirati jedan ili više lokalnih pristupnika za lokalnu PSTN mrežu kako bi omogućili pozive između krajnjih točaka.

Ako je krajnji cilj potpuni prijelaz ( faza 2) u oblak, uključujući PSTN, tada će za PSTN biti potreban Cisco Calling Plan ili opcija Cloud Connect.

Surađujte s odabranim davateljem usluga kako biste naručili i prenijeli telefonske brojeve prije nego što ih konfigurirate u . Naručivanje telefonskih brojeva ili pokretanje narudžbi za prijenos je samo required/possible za lokalnu PSTN mrežu i Cloud Connect za . Za Cisco pozivne planove, naručivanje i prenošenje podataka pokreće se unutar Control Huba čim se lokacija kreira, i to u zemljama u kojima je Cisco pozivni plan dostupan. Za više informacija o Cisco Calling planovima pogledajte Početak rada s Cisco planovima.

Kao dio implementacije PSTN-a, provjerite je li vaš davatelj usluga omogućio i dolazne i odlazne PSTN usluge za vašu lokaciju. Osim toga, izvršite probne pozive kako biste provjerili usmjeravaju li se pozivi ispravno putem odabrane PSTN veze.

Prije dodavanja korisnika i uređaja u , morate osigurati lokacije za pozivanje. Za svaku lokaciju mora se unijeti važeća adresa ulice. U SAD-u i Kanadi, ova adresa se potvrđuje i platforma koristi za slanje PIDF-LO informacija o lokaciji za hitne pozive.

Prilikom konfiguriranja lokacija koje koriste lokalni PSTN, potrebno je u skladu s tim postaviti lokalne pristupnike. U , za svaki lokalni pristupnik moraju se stvoriti trunk i grupa ruta, a grupa ruta se zatim dodjeljuje kao PSTN izbor za lokaciju. Cisco toplo preporučuje da uvijek odaberete grupu ruta kao PSTN izbor, jer vam taj pristup omogućuje jednostavno dodavanje dodatnih trunkova u budućnosti, podržavajući i skalabilnost i redundanciju. Cisco također preporučuje omogućavanje podrške za dvostruki identitet i P-Charge-Info na svakom PSTN trunku, jer to pojednostavljuje identifikaciju naplatne strane za odlazne izravne ili preusmjerene pozive. Ako vaš davatelj PSTN usluga koristi drugačije zaglavlje za naplatu, možete kopirati podatke iz zaglavlja P-Charge-Info na lokalnom pristupniku u potrebno zaglavlje za naplatu.

Za lokacije koje koriste Cloud Connect ili Cisco Calling Plan kao svoju PSTN opciju, jednostavno odaberite odgovarajući PSTN izbor za lokaciju tijekom postavljanja. Ako lokacija koristi Cloud Connect za PSTN ili lokalnu PSTN mrežu, morat ćete dodati telefonske brojeve koji su naručeni u prethodnom koraku. Brojeve možete dodati kao neaktivne ako ih ne želite odmah uključiti u usmjeravanje poziva; te brojeve možete aktivirati kasnije kada budu dodijeljeni korisnicima ili značajkama.

Važno je uvijek postaviti glavni broj za svaku lokaciju. Glavni broj može se dodijeliti korisniku ili funkciji, kao što je automatski telefonski operater. Da biste omogućili govornu poštu na lokaciji, obavezno postavite pilotni broj govorne pošte, također poznat kao broj govornog portala.

Dodatne postavke za pozivanje lokacija uključuju konfiguriranje detalja za hitne pozive kao što su broj za povratni poziv u hitnim slučajevima, opcije obavijesti i poboljšane značajke hitnih poziva. Također biste trebali pregledati i prilagoditi postavke snimanja, jezične postavke i konfiguracije uređaja prema potrebi za svaku lokaciju. Ako vaša organizacija koristi skraćeno međulokacijsko biranje unutar mreže s brojevima značajnim za poduzeća, ne zaboravite konfigurirati jedinstveni kod lokacije za lokaciju u postavkama internog biranja. Konačno, ako vanjsko biranje zahtijeva znamenku za odlazno biranje, obavezno je postavite u postavkama vanjskog biranja. Kada je konfigurirana odlazna brojka za biranje, Cisco preporučuje omogućavanje primjene odlazne brojke za biranje kako bi se osigurala dosljednost.

Za integraciju s lokalnim upravljanjem pozivima potrebno je konfigurirati operatere, grupe ruta, poslovne planove biranja te postavke lokacije i globalne postavke. Započnite postavljanjem trankova i lokalnih pristupnika namijenjenih za međusobno povezivanje s lokalnim sustavom za kontrolu poziva; ovaj korak je potreban samo ako su potrebni namjenski trankovi. Ako su postojeći kanali i grupe ruta dovoljni za vašu implementaciju, mogu se ponovno upotrijebiti za lokalnu međusobnu vezu bez dodatne konfiguracije.

Nakon što su uspostavljene grupe linija i ruta, nastavite s izradom planova biranja poduzeća i dodijelite odgovarajuću grupu ruta kao odredište za svaki plan biranja. Kada integracija uključuje više lokalnih sustava za kontrolu poziva povezanih putem različitih linija, bit će potrebni višestruki planovi biranja. Važno je osigurati da ovi planovi biranja sadrže samo obrasce potrebne za usmjeravanje poziva na lokalna odredišta.

Ako vaša implementacija zahtijeva podršku za usmjeravanje nepoznatih ekstenzija, ova značajka treba biti omogućena na razini lokacije. Osim toga, kada je aktivirano usmjeravanje nepoznatog ekstenzijskog broja, morate odrediti maksimalnu duljinu nepoznatog ekstenzijskog broja u odjeljku Usmjeravanje poziva između prostorija u postavkama usluga poziva u . To osigurava besprijekorno usmjeravanje poziva i pravilno rukovanje scenarijima biranja temeljenim na ekstenzijama u vašem integriranom okruženju.

Prilikom migracije korisnika iz u , možda nećete moći premjestiti sve korisnike istovremeno. To može biti zbog više razloga, uključujući, ali ne ograničavajući se na broj web-mjesta ili korisnika, koliko je vremena potrebno za tranziciju web-mjesta and/or grupa korisnika istovremeno, ograničeni IT ili resursi lokacije za podršku prozora promjene, trajanje prozora promjene, složenost promjene itd.

Prilikom migracije korisnika u fazama, ključno je identificirati koje korisnike treba migrirati zajedno u istoj seriji. Primarni cilj je migrirati korisnike koji međusobno ovise o svojim uslugama i značajkama poziva. Želite osigurati da su sve njihove značajke poziva (primjer - redovi poziva) u potpunosti funkcionalne kao što su bile prije prijelaza na .

Čak i ako implementirate međusobno djelovanje poziva između i s lokalnim pristupnicima, ne možete podijeliti dijeljene usluge ili značajke preko ove veze. Stoga je potrebno identificirati ovisnosti između korisnika promatrajući značajke poput:

• Praćenje drugih korisnika pomoću BLF-ova

• U istom pilotu za pretraživanje, redu poziva itd.

• Zajednički reci

• Korištenje preuzimanja poziva

• Korištenje istih brojeva za parkiranje poziva

• Interkom

• Executive/Admin.

Primjer bi bio korisnik koji je dio Hunt grupe koja se prelazi na . Ovaj će korisnik prijeći u Hunt Group i sa svim ostalim članovima Hunt Group. Stoga, nakon tranzicije, Hunt Group i njezini članovi mogu uspješno odgovarati na pozive na novoj platformi.

To postaje izazovnije kada su korisnici povezani s različitim grupama korisnika za različite usluge i značajke poziva. To će zahtijevati istovremeni prijelaz više od jedne skupine korisnika i jedne usluge pozivanja.

Pomoću alata Migration Insights ili alata treće strane koji ste koristili u fazi pripreme odredite koje korisnike i značajke treba grupirati. Ovaj rezultat trebao se koristiti za razvoj vašeg plana migracije i dat će vam uvid u to kako ćete grupirati korisnike i značajke koje je potrebno prenijeti zajedno.

Ključni koraci prilikom prelaska grupe korisnika su:

• Identificiranje korisnika za zajedničku migraciju

• Provjerite jesu li svi korisnici unutra

• Provjerite postoje li svi TN-ovi za korisnike u

• Provjerite ispravan format telefonskog broja u imeniku

• Provjerite jesu li predlošci licenciranja i postavki za korisničke grupe ispravno postavljeni

• Provjera ili konfiguriranje svih usluga i značajki poziva za grupu korisnika (prije ili tijekom prijelaza, prema potrebi)

• U korporativnom imeniku dodajte korisnike u grupu korisnika s omogućenim pozivanjem

• Iskoristite alate - alati za migraciju korisnika i značajki and/or alati trećih strana

• Disable/Delete user/device broj u imeniku i pozivanje features/services nakon tranzicije.

Nakon migracije grupe korisnika, testirajte podskup korisnika kako biste provjerili rade li sve njihove značajke i usluge poziva ispravno. Ako se značajke pozivanja poput reda čekanja poziva, grupa za pretraživanje itd. prenose s grupom korisnika, testirajte ispravnost funkcionalnosti tih usluga poziva.

U , radni prostor odnosi se na dijeljenu lokaciju (poput sobe za konferencije, prostora za sastanke ili radnog stola) kojoj se mogu dodijeliti uređaji, ekstenzije i korisnici. Za razliku od tradicionalnih Unifed CM telefona, radni prostori su:

• Usredotočeno na lokaciju: vezani za fizičke prostore.

• Fleksibilno za uređaj: može imati jedan ili više uređaja (stolni telefoni, ploče itd.).

Nakon što su radni prostori identificirani kao dio prijelaza na , mogu se dodati pod Uređaji. Svakom radnom prostoru potreban je dodjela uređaja, a ako su već u Unified CM-u, potrebno ih je resetirati ili ponovno omogućiti. Značajke poput govorne pošte, prosljeđivanja poziva i preuzimanja poziva mogu se omogućiti ili onemogućiti, a pravila se mogu primijeniti za videopozive, parkiranje poziva i mobilnost prema potrebi. Testirajte svaki radni prostor upućivanjem internih i eksternih poziva, testiranjem videopoziva, konferencija i značajki mobilnosti. Na kraju, obavijestite korisnike o svim primjenjivim postupcima za uređaje i rezervacije radnog prostora.

Za više informacija o radnim prostorima u , pogledajte Radni prostori.

Telefoni koji su trenutno registrirani morat će se migrirati kao dio prijelaza u oblak. Kako bi migracija bila što jednostavnija uz minimalnu mogućnost neuspjeha, Cisco preporučuje istovremenu migraciju fizičkih lokacija ili odjela. Međutim, možda ćete morati migrirati korisnike u serijama zbog ovisnosti značajki. Za više detalja pogledajte odjeljak Migriranje korisnika u serijama.

Sve podržane telefone s kojih trebate prijeći morat ćete konfigurirati kao korisnika ili radni prostor, a fizički telefon morat ćete ponovno konfigurirati za registraciju na . Osim toga, telefoni serije 7800 i 8800 trebaju nadograditi firmver s Enterprise firmvera na Multiplatform Phone (MPP) firmver. Ovaj postupak uključuje učitavanje prijelaznog firmvera prije učitavanja MPP firmvera potrebnog za registraciju. Također je potrebna odgovarajuća migracijska dozvola. Cisco je poboljšao ovaj proces tijekom posljednjih nekoliko godina kako bi vam olakšao nadogradnju vaših telefona s Enterprise firmwareom na MPP firmware. Za više informacija o koracima za dovršetak nadogradnje firmvera, pogledajte Pretvaranje IP telefona serije Cisco 7800 i 8800 između Enterprise i MPP firmvera.

Uz korake opisane u ovom članku, ima ugrađeni alat, Migrirajte svoj telefon na Webex Calling, koji možete koristiti za migraciju svojih telefona 7800 i 8800 s Enterprise na MPP firmver. Ovaj alat vam također omogućuje dodavanje telefona i njihovo dodjeljivanje odgovarajućim korisnicima ili radnim prostorima. Za više informacija o korištenju alata pogledajte Migrirajte telefon.

Zahtjev za migraciju firmvera ne primjenjuje se na telefone serije 9800 registrirane s gore navedenim. Ovi telefoni koriste PhoneOS, koji podržavaju i . Za prijenos ovih telefona morat ćete ih dodati u Webex Calling, dodijeliti ih korisniku ili radnom prostoru, a zatim vratiti telefone na tvorničke postavke. Slijed pokretanja PhoneOS-a za registraciju donja slika prikazuje slijed pokretanja PhoneOS-a i kako će se telefon registrirati nakon što je dodan u , čak i ako je telefon još uvijek omogućen na and/or DHCP opcije (primjer - 150) su u upotrebi.

podržava vraćanje PhoneOS uređaja na tvorničke postavke kako bi se omogućila Zero-Touch integracija. Administratori mogu daljinski vratiti telefone 9800 i 8875 na tvorničke postavke putem CUCM administratorskih stranica, što eliminira potrebu za fizičkim pristupom telefonima za njihovu integraciju u . Ova značajka je podržana s paketima uređaja od 9. rujna 2025.:

• CUCM v15 - Unified Communications Manager verzija 15

• CUCM v14 - Unified Communications Manager verzija 14.

Za više informacija o postupku registracije za seriju 9800, pogledajte Postupak registracije.

Uz Cisco IP telefone, možda će biti potrebno osigurati i druge uređaje kao što su analogni telefonski adapteri (ATA), bežični (Wifi, DECT) telefoni, video uređaji, glasovni pristupnici i uređaji i telefoni trećih^strana. Mnogi od ovih uređaja nemaju put nadogradnje firmvera poput IP telefona za prelazak s poslovnog firmvera na firmver u oblaku. Stoga ćete svaki od ovih uređaja osigurati u Control Hubu. Na neke od njih nije moguće preći i morat će ih zamijeniti ekvivalentni model (npr. ATA 191/192) a drugi će zahtijevati ručnu rekonfiguraciju and/or promjene softvera.

• Glasovni pristupnici - Za migraciju lokalnog pristupnika pogledajte Migracija lokalnog pristupnika.

  Za više informacija o konfiguriranju glasovnog pristupnika VG400, VG410 ili VG420 u Control Hubu, pogledajte Lokalni pristupnik

• Analogni telefonski adapter (ATA) - Za početak rada s Cisco ATA 191 i 192, pogledajte Cisco ATA.

• Bežični Wifi telefon - Za integraciju bežičnih telefona 840 i 860, pogledajte Integracija bežičnog telefona Webex.

• Bežični DECT telefoni - Za početak rada s novom Cisco IP DECT serijom 6800, pogledajte Cisco IP DECT.

  Za izgradnju i upravljanje digitalnom DECT mrežom u Control Hubu, pogledajte Upravljanje DECT mrežom

  Za više informacija o Cisco IP DECT 6800, pogledajte Vodič za implementaciju

• uređaji i telefoni trećih^strana - Surađujte s dobavljačima trećih^strana na device/phone zahtjeve i postupak njihove migracije ili zamjene radi podrške.

Sve potrebne funkcije pozivanja potrebno je osigurati prije ili tijekom prijelaza. Kao što je već spomenuto u odjeljku Migracija korisnika u serijama, značajke pozivanja potrebno je konfigurirati i prebaciti kada se prebace i korisnici koji ih koriste.

Za detalje o konfiguriranju svake od značajki pogledajte odgovarajuće članke pomoći za konfiguraciju.

• Automatski telefonski operateri - Za upravljanje automatskim telefonskim operaterima pogledajte Automatski telefonski operateri

• Parkiranje poziva - Za upravljanje parkiranjem poziva pogledajte Parkiranje poziva

• Preuzimanje poziva - Za konfiguriranje grupe za preuzimanje poziva, pogledajte Preuzimanje poziva

• Red poziva - Za konfiguriranje reda poziva, pogledajte Red poziva

• Grupe za lov - Za upravljanje grupama za lov pogledajte Upravljanje grupama za lov

• Načini rada - Za usmjeravanje poziva na temelju načina rada, pogledajte Usmjeravanje poziva na temelju načina rada

• Grupe za straničenje - Za konfiguriranje grupe za straničenje, pogledajte Konfiguriranje grupe za straničenje

• Snimke - Za upravljanje snimanjem poziva za , pogledajte Upravljanje snimkama

• Doseg jednog broja - Za konfiguriranje dosega jednog broja (ured bilo gdje), pogledajte Konfiguriranje jednog broja

• Grupa govorne pošte - Za upravljanje dijeljenom govornom poštom i dolaznim faksom za , pogledajte Upravljanje govornom poštom.

Testiranje prihvatljivosti osigurava da migrirano okruženje ispunjava funkcionalne zahtjeve, radi kako se očekuje i pruža besprijekorno korisničko iskustvo u svim komunikacijskim tijekovima rada. Ovaj proces validacije je višestruk i obuhvaća sve, od dodjeljivanja korisnika i brojeva do operativnih performansi naprednih značajki poziva.

Ovaj odjeljak pruža primjere i ističe ključne aspekte koje treba uzeti u obzir tijekom ispitivanja prihvatljivosti; međutim, nije namijenjen da služi kao iscrpan ili sveobuhvatan popis za provjeru.

Pružanje usluga korisnicima i dodjeljivanje brojeva

Temeljni aspekt testiranja prihvatljivosti uključuje provjeru jesu li svi korisnici točno i potpuno osigurani unutar . To zahtijeva temeljitu usporedbu između izvornog() direktorija i novouspostavljene korisničke baze kako bi se osiguralo da je svaki korisnički račun, zajedno s pripadajućim atributima kao što su interni brojevi i dodjele izravnog dolaznog biranja (DID), ispravno migriran. Potpunost opskrbe ključna je ne samo za operativnost od prvog dana, već i za kontinuiranu administraciju i podršku.

Validacija dodjele broja uključuje potvrdu da je svakom korisniku dodijeljen ispravan ekstenzijski i vanjski broj te da se ti brojevi ispravno usmjeravaju u internim (unutar mreže) i eksternim (PSTN) tokovima poziva. Bitno je provjeriti ima li preklapanja, nedostajućih dodjela ili pogrešnih konfiguracija koje bi mogle dovesti do pogrešaka u usmjeravanju poziva ili prekida usluge.

Tokovi poziva PSTN-a i prikaz identifikacije pozivatelja

Robusni postupak testiranja prihvatljivosti mora obuhvaćati potpunu validaciju tokova poziva PSTN-a. To uključuje scenarije dolaznih i odlaznih poziva. Za dolazne PSTN pozive, tim za testiranje trebao bi potvrditi da se pozivi dostavljaju na predviđene krajnje točke, bilo da se radi o pojedinačnim korisnicima, redovima poziva, grupama za pretraživanje ili automatskim telefonskim operaterima. Odlazni PSTN pozivi moraju se uspješno uputiti, s posebnom pažnjom na ispravnu dostavu i prikaz informacija o identifikaciji pozivatelja. To uključuje osiguravanje da se vanjskim primateljima prikažu ispravno ime i broj pozivatelja, u skladu s organizacijskim politikama i regulatornim zahtjevima.

Testiranje bi također trebalo obuhvatiti scenarije prebacivanja u slučaju kvara, kao što je rukovanje nedostupnim krajnjim točkama ili prekidima u radu mreže. To pomaže potvrditi da rezervni mehanizmi i alternativno usmjeravanje ispravno funkcioniraju, održavajući kontinuitet i pouzdanost usluge.

Tokovi poziva unutar mreže

Interni, ili mrežni, tokovi poziva čine okosnicu poslovne komunikacije. Testiranje prihvatljivosti u ovom području potvrđuje da se pozivi između korisnika unutar organizacije ispravno usmjeravaju, a značajke poput prijenosa poziva, čekanja, prosljeđivanja i konferencija rade kako je predviđeno. Integritet planova biranja, povezivost između ekstenzija i podrška za organizacijske politike poziva moraju biti potvrđeni.

Obrada korisničkih poziva i validacija značajki

Važan aspekt testiranja prihvatljivosti uključuje provjeru načina na koji korisnici rukuju pozivima pomoću i podržanih fiksnih telefona. Ovaj proces usmjeren je na potvrdu da su svakodnevni tijekovi rada poziva intuitivni i pouzdani te da korisnici imaju nesmetan pristup ključnim značajkama potrebnim za njihove uloge. Testiranje bi trebalo procijeniti lakoću kojom korisnici mogu upućivati i primati pozive, upravljati funkcijama čekanja i nastavka te obavljati i slijepa i konzultativna prebacivanja. Također je bitno provjeriti jesu li prosljeđivanje poziva, konferencije i druge napredne mogućnosti, poput parkiranja i preuzimanja poziva ili aktiviranja načina "Ne uznemiravaj", lako dostupne i rade li nesmetano.

Iskustvo treba procijeniti s obzirom na jasnoću i brzinu odziva, uzimajući u obzir kako korisnici komuniciraju s povijesti poziva, govornom poštom i integriranim imenicima. Dodatnu pozornost treba posvetiti mogućnosti premještanja aktivnih poziva između uređaja i učinkovitom korištenju kontrola tijekom poziva unutar aplikacije ili na fizičkim telefonima. Krajnji je cilj osigurati da je iskustvo krajnjeg korisnika dosljedno, učinkovito i da u potpunosti podržava komunikacijske potrebe organizacije nakon migracije.

Redovi poziva: Iskustvo agenta i nadzornika

Redovi poziva često se koriste za rukovanje scenarijima s velikim brojem dolaznih poziva. Testiranje prihvatljivosti ovdje se fokusira na nekoliko dimenzija. Prvo, treba provjeriti da se pozivi distribuiraju agentima prema konfiguriranoj logici reda čekanja, kao što su kružni postupak, najdulji neaktivni period ili istovremeno zvonjenje. Prikaz poziva u redu čekanja na radnim površinama agenata mora se provjeriti radi jasnoće i jednostavnosti korištenja, osiguravajući da agenti mogu učinkovito prihvaćati, zadržavati i preusmjeravati pozive.

Za nadzornike, iskustvo na računalu treba procijeniti zbog značajki kao što su praćenje u stvarnom vremenu, uključivanje poziva i analitika ili uvidi u performanse reda čekanja. To uključuje, ali nije ograničeno na, provjeru valjanosti nadzornih ploča i alata za izvještavanje koji pružaju korisne podatke o distribuciji poziva, aktivnosti agenata i metrikama reda čekanja.

Lovačke skupine: Distribucija poziva

Grupe za pretraživanje ključni su mehanizam za distribuciju poziva unaprijed definiranim skupovima korisnika. Testiranje prihvatljivosti treba potvrditi da se pozivi usmjeravaju članovima grupe na temelju konfiguriranog algoritma pretraživanja te da se scenariji prelijevanja, prosljeđivanja i neodgovora rješavaju u skladu s dizajnom. Osiguravanje da se ponašanje članstva u grupi i usmjeravanja poziva podudara s onima prethodno utvrđenima ključno je za operativnu dosljednost i zadovoljstvo korisnika.

Automatski operateri: Obavijesti i rad izbornika

Automatski telefonski operateri predstavljaju prvu liniju automatizirane obrade poziva. Testiranje mora obuhvatiti reprodukciju obavijesti, točnost snimljenih pozdrava i ispravan rad stabala izbornika. Odabiri u izborniku trebali bi pouzdano usmjeravati pozivatelje prema odgovarajućim odjelima, pojedincima ili vanjskim brojevima. Testiranje bi također trebalo uključivati nevažeće scenarije ili scenarije isteka vremena kako bi se potvrdilo da pozivatelji primaju jasne upute ili su preusmjereni kako je predviđeno.

Rad govorne pošte

Konačno, funkcionalnost govorne pošte ključna je za korisničko iskustvo. Testovi prihvatljivosti trebali bi potvrditi da su pretinci govorne pošte ispravno dodijeljeni i dostupni, kako unutar organizacije tako i daljinski. Mogućnost snimanja, dohvaćanja i upravljanja porukama mora biti potvrđena, zajedno s dostavom obavijesti.