Det första steget i övergången till är att säkerställa en pålitlig och säker internetanslutning mellan det lokala nätverket och molnet.

Eftersom de flesta organisationer ansluter till internet via en eller flera brandväggar eller säkerhetsenheterär det viktigt att validera att de nödvändiga trafikflödena stöds.

Nätverks- och säkerhetsadministratörer måste förstå dessa flöden vad gäller:

• Riktning (inkommande vs utgående)

• Protokoll (Exempel - SIP TLS, SRTP, HTTPS)

• IP-adressintervall som används av tjänster

• Portnummer som måste öppnas eller tillåtas.

Detta säkerställer att företagets brandväggar, NAT-enheter och annan nätverksinfrastruktur är korrekt konfigurerad för att hantera trafik samtidigt som företagets säkerhetspolicyer upprätthålls.

För information om nödvändiga flöden, inklusive IP-adress, portar och protokoll, se Portreferensinformation för Webex Calling. Använd den här informationen för att konfigurera brandväggen, proxyservrar och annan nätverksinfrastruktur i den befintliga distributionen för att aktivera nätverksflöden.

Decentraliserad internetuppkoppling från varje filial eller plats är den rekommenderade metoden för molnbaserade samarbetstjänster som . Genom att tillåta trafik att lämna lokalt, gör den här modellen följande:

• Minskar tur- och returfördröjningar och jitter, vilket förbättrar den totala samtalskvaliteten

• Skalas effektivt i takt med att fler användare och webbplatser övergår till

• Fungerar sömlöst med SD-WAN, som dynamiskt kan dirigera sessioner till närmaste molningångspunkt för optimal prestanda

• Gör det möjligt att spåra användarnas plats baserat på deras offentliga IP-adress, vilket hjälper till med analys av mediesökvägar och felsökning.

Dessutom måste organisationer säkerställa tillräcklig internetbandbredd på varje plats. Bandbredden bör dimensioneras baserat på det förväntade antalet samtidiga samtal, den valda kodeken (t.ex. Opus eller G.711), plus overhead för signalering, återutsändningar och tillväxt. Detta överensstämmer med förberedelsefasen i PPDIO-livscykeln och skapar en solid grund för migrering.

Det inledande installationsavsnittet i implementeringsfasen av distributionen är grundläggande för att etablera en välstrukturerad och hanterbar molnanropsmiljö. Det här steget omfattar kritiska uppgifter som att konfigurera organisationen, anskaffa och tilldela licenser samt verifiera och göra anspråk på företagets domäner för att säkerställa korrekt användarhantering och säkerhet. Dessutom inkluderar det etablering av licensmalla för att automatisera tilldelning av användarlicenser, konfigurering av enkel inloggning (SSO) för att effektivisera användarautentisering och förbättra säkerheten, samt justering av tjänst- och klientinställningar så att de överensstämmer med organisationens policyer och användarbehov. Genom att slutföra dessa initiala installationsaktiviteter säkerställs att miljön är korrekt konfigurerad för skalbarhet, säkerhet och en sömlös användarupplevelse, vilket banar väg för efterföljande distributions- och driftsfaser.

Under implementeringsfasen representerar genomförandet av en pilotmigrering en kritisk milstolpe i valideringen av övergången från till . Detta pilotprojekt innebär att en representativ delmängd av användare på en eller flera platser etableras på plattformen, vilket säkerställer att den valda populationen återspeglar olika användningsfall och organisatoriska roller. Parallellt med användarmigreringen måste viktiga samarbetstjänster, inklusive röstbrevlåda, automatiska svarstjänster, samtalsköer och sökgrupper, överföras till sina motsvarigheter för att upprätthålla affärskontinuitet och tjänstefunktionalitet.

Pilotmigreringen bör utnyttja samma kombination av Cisco-baserade verktyg och tredjepartsmigreringsverktyg som planeras för den bredare organisationsdistributionen, vilket säkerställer att processerna, automatiseringsarbetsflödena och integrationspunkterna valideras noggrant under representativa förhållanden.

De primära målen med denna pilotutplacering är tvåfaldiga: för det första, att validera och förfina de heltäckande övergångsprocesserna, inklusive arbetsflöden för användarprovisionering, datamigreringsprocedurer och slutpunktskonfigurationer; och för det andra, att heltäckande verifiera funktionaliteten hos migrerade tjänster under verkliga driftsförhållanden.

Denna etappvisa metod gör det möjligt för projektgruppen att identifiera och åtgärda eventuella tekniska eller procedurmässiga problem i en kontrollerad miljö, samla in användarfeedback om den nya plattformsupplevelsen, bedöma effektiviteten hos valda migreringsverktyg och skapa förtroende för migreringsmetodiken innan de fortsätter med en bredare organisatorisk implementering.

Insikterna som erhållits under denna pilotfas är avgörande för att optimera efterföljande migreringsvågor och säkerställa en smidig och riskreducerad övergång för hela företaget.

För att upphandla PSTN-tjänster för , välj först ett PSTN-anslutningsalternativ i .

Om en organisation planerar att upprätthålla hybrid dubbel samtalskontroll ( fas 1 i figur Fasvis övergång till samtal: Hybrid och moln) antingen tillfälligt eller på obestämd tid, kommer de att behöva distribuera en eller flera lokala gateways för lokala PSTN för att tillåta samtal mellan och slutpunkter.

Om en fullständig övergång ( fas 2) till molnet är slutmålet, inklusive PSTN, krävs antingen ett Cisco-samtalsplan eller ett Cloud Connect-alternativ för PSTN.

Samarbeta med din valda leverantör för att beställa och portera telefonnummer innan du konfigurerar dem i . Att beställa telefonnummer eller initiera portordrar är endast required/possible för lokal PSTN och Cloud Connect för . För Cisco Calling Plans initieras beställning och portering inifrån Control Hub så snart platsen har skapats, och i länder där Cisco Calling Plan är tillgängligt. För mer information om Cisco Calling-abonnemang, se Komma igång med Cisco-abonnemangen.

Som en del av PSTN-implementeringen, se till att din leverantör har aktiverat både inkommande och utgående PSTN-tjänster för din plats. Utför dessutom testsamtal för att verifiera att samtal dirigeras korrekt via din valda PSTN-anslutning.

Innan du lägger till användare och enheter till måste du etablera samtalsplatser. För varje plats måste en giltig gatuadress anges. I USA och Kanada valideras och används denna adress av plattformen för att skicka PIDF-LO-platsinformation för nödsamtal.

När du konfigurerar platser som använder lokalt PSTN måste du konfigurera de lokala gatewayerna därefter. I måste en trunk och en ruttgrupp skapas för varje lokal gateway, och ruttgruppen tilldelas sedan som PSTN-val för platsen. Cisco rekommenderar starkt att alltid välja en ruttgrupp som PSTN-val, eftersom den här metoden gör att du enkelt kan lägga till ytterligare trunkar i framtiden, vilket stöder både skalbarhet och redundans. Cisco rekommenderar också att aktivera dubbel identitet och stöd för P-Charge-Info på varje PSTN-trunk, eftersom detta förenklar identifieringen av den fakturerbara parten för utgående direkta eller vidarekopplade samtal. Om din PSTN-leverantör använder en annan rubrik för fakturering kan du kopiera informationen från P-Charge-Info-rubriken på den lokala gatewayen till den faktureringsrubriken som krävs.

För platser som använder Cloud Connect eller Cisco Calling Plan som PSTN-alternativ, välj helt enkelt respektive PSTN-alternativ för platsen under installationen. Om platsen använder antingen Cloud Connect för eller lokalt PSTN måste du lägga till telefonnumren som beställdes i föregående steg. Nummer kan läggas till som inaktiva om du inte vill att de ska inkluderas i samtalsdirigering direkt; du kan aktivera dessa nummer senare när de tilldelas användare eller funktioner.

Det är viktigt att alltid ange huvudnumret för varje plats. Huvudnumret kan tilldelas antingen en användare eller en funktion, till exempel en automatisk svarare. För att aktivera röstbrevlåda på platsen, se till att ange pilotnumret för röstbrevlådan, även känt som röstportalnumret.

Ytterligare inställningar för att ringa platser inkluderar konfigurering av nödsamtal, till exempel nödnummer för återuppringning, aviseringsalternativ och förbättrade funktioner för nödsamtal. Du bör också granska och justera inspelningsinställningar, språkinställningar och enhetskonfigurationer efter behov för varje plats. Om din organisation använder förkortad intern uppringning på nätet med företagsnummer (significant numbers), kom ihåg att konfigurera en unik platskod för platsen i de interna uppringningsinställningarna. Slutligen, om extern uppringning kräver en utgående siffra, se till att ställa in detta i inställningarna för extern uppringning. När en utgående uppringningssiffra har konfigurerats rekommenderar Cisco att aktivera tillämpning av utgående uppringningssiffror för att säkerställa konsekvens.

För att integrera med lokal samtalskontroll är det nödvändigt att konfigurera trunkar, ruttgrupper, företagsuppringningsplaner och både plats- och globala inställningar. Börja med att konfigurera trunkarna och lokala gateways som är avsedda för sammankoppling med det lokala samtalskontrollsystemet; detta steg krävs endast om dedikerade trunkar behövs. Om befintliga trunkar och ruttgrupper är tillräckliga för din distribution kan de återanvändas för den lokala sammankopplingen utan ytterligare konfiguration.

När trunkarna och ruttgrupperna har upprättats, fortsätt med att skapa företagets uppringningsplaner och tilldela lämplig ruttgrupp som destination för varje uppringningsplan. När integrationen involverar flera lokala samtalskontrollsystem som är anslutna via olika trunkar, krävs flera uppringningsplaner. Det är viktigt att säkerställa att dessa uppringningsplaner endast innehåller de mönster som krävs för att dirigera samtal till lokala destinationer.

Om din distribution kräver stöd för routning av okända tillägg bör den här funktionen aktiveras på platsnivå. Dessutom, när routning av okänd anknytning är aktiverad, måste du ange den maximala okända anknytningslängden i avsnittet Samtalsrouting mellan och lokaler i inställningarna för samtalstjänster i . Detta säkerställer sömlös samtalsdirigering och korrekt hantering av anknytningsbaserade uppringningsscenarier i din integrerade miljö.

När du migrerar användare från till kanske du inte kan flytta alla användare samtidigt. Detta kan bero på flera orsaker, inklusive men inte begränsat till antalet webbplatser eller användare, hur lång tid det tar att överföra en webbplats and/or grupp av användare samtidigt, begränsade IT- eller webbplatsresurser för att stödja ändringsfönstret, ändringsfönstrets varaktighet, ändringens komplexitet etc.

När du migrerar användare i faser är det viktigt att identifiera vilka användare som behöver migrera tillsammans i samma batch. Det primära målet är att migrera samman användare som har beroenden av varandra för sina samtalstjänster och funktioner. Du vill se till att alla deras samtalsfunktioner (exempel - samtalsköer) är fullt fungerande precis som de var före övergången.

Även om du implementerar samtalskommunikation mellan och med lokala gateways kan du inte dela delade tjänster eller funktioner över den här anslutningen. Därför behöver du identifiera beroenden mellan användare genom att titta på funktioner som:

• Övervaka andra användare med hjälp av BLF:er

• I samma pilotsökning, anropskö osv.

• Delad linje

• Använda samtalshämtning

• Använda samma samtalsparkeringsnummer

• Snabbtelefon

• Executive/Admin.

Ett exempel skulle vara en användare som är en del av en jaktgrupp som övergår till . Den här användaren kommer att övergå till med jaktgruppen och med alla andra medlemmar i jaktgruppen. Därför kan Hunt Group och dess medlemmar efter övergången framgångsrikt svara på samtal på den nya plattformen.

Detta blir mer utmanande när användare är anslutna till olika användargrupper för olika samtalstjänster och funktioner. Detta kommer att kräva att mer än en grupp användare och en anropstjänst överförs samtidigt.

Använd utdata från Migration Insights-verktyget eller ett tredjepartsverktyg som du använde i förberedelsefasen för att avgöra vilka användare och funktioner som ska grupperas tillsammans. Denna utdata borde ha använts för att utveckla din migreringsplan och kommer att ge dig insikter i hur du grupperar användare och funktioner som behöver övergå tillsammans.

De viktigaste stegen vid överföring av en grupp användare är:

• Identifiera användare som ska migreras tillsammans

• Verifiera att alla användare är inne

• Verifiera att alla TN:er för användarna finns i

• Kontrollera korrekt telefonnummerformat i katalogen

• Se till att licens- och inställningsmallen för användargrupperna är korrekt konfigurerad.

• Verifiera eller konfigurera alla samtalstjänster och funktioner för användargruppen (före eller under övergången, beroende på vad som är lämpligt)

• Lägg till användare i gruppen med samtalsaktiverade användare i företagskatalogen

• Utnyttja verktyg – verktyg för migrering av användare och funktioner and/or verktyg från tredje part

• Disable/Delete user/device katalognummer och uppringning features/services efter övergången.

Efter migrering av en grupp användare, testa en delmängd av användarna för att bekräfta att alla deras samtalsfunktioner och tjänster fungerar korrekt. Om samtalsfunktioner som samtalskö, sökgrupper etc. övergår med användargruppen, testa då dessa samtalstjänster för att se till att de fungerar korrekt.

I [engelsk text] avser en arbetsyta en delad plats (som ett konferensrum, ett mötesrum eller en hot desk) som kan tilldelas enheter, anknytningar och användare. Till skillnad från traditionella Unifed CM-telefoner är arbetsytor:

• Platscentrerad: knutna till fysiska utrymmen.

• Enhetsflexibel: kan ha en eller flera enheter (bordstelefoner, kort, etc.).

När arbetsytor har identifierats som en del av övergången till , kan de läggas till under Enheter. Varje arbetsyta behöver en enhetstilldelning, och om de redan finns i Unified CM måste de återställas eller omprovisioneras. Funktioner som röstbrevlåda, vidarekoppling av samtal och samtalssvar kan aktiveras eller inaktiveras, och principer kan tillämpas för videosamtal, samtalsparkering och mobilitet efter behov. Testa varje arbetsyta genom att ringa interna och externa samtal, testa video-, konferens- och mobilitetsfunktioner. Slutligen, informera användarna om eventuella tillämpliga processer för arbetsyteenheter och bokningar.

För mer information om arbetsytor i , se Arbetsytor.

Telefoner som för närvarande är registrerade till måste migreras till som en del av molnövergången. För att göra migreringen så enkel som möjligt med minimal risk för misslyckande rekommenderar Cisco att man migrerar fysiska platser eller avdelningar samtidigt. Du kan dock behöva migrera användare i omgångar på grund av funktionsberoenden. Se avsnittet Migrera användare i omgångar för mer information.

Alla telefoner som stöds och som du behöver övergå från måste konfigureras som en användare eller arbetsyta och den fysiska telefonen måste konfigureras om för att registreras hos . Dessutom behöver telefonerna i 7800- och 8800-seriens firmware uppgraderas från Enterprise-firmware till Multiplatform Phone (MPP). Den här processen inkluderar att ladda övergångs-firmware innan man laddar den MPP-firmware som krävs för registrering. Det kräver också lämplig migrationslicens. Cisco har förbättrat den här processen under de senaste åren för att göra det enklare för dig att uppgradera dina företagstelefoner med firmware till MPP-firmware. För mer information om stegen för att slutföra uppgraderingen av den inbyggda programvaran, se Konvertera Cisco 7800- och 8800-seriens IP-telefoner mellan Enterprise- och MPP-firmware.

Utöver stegen som beskrivs i den här artikeln finns det ett inbyggt verktyg, Migrera din telefon till Webex Calling, som du kan använda för att migrera dina 7800- och 8800-telefoner från Enterprise till MPP-firmware. Det här verktyget låter dig också lägga till telefonerna och tilldela dem till lämpliga användare eller arbetsytor. För mer information om verktygsanvändning, se Migrera din telefon.

För telefoner i 9800-serien som är registrerade med ovanstående krav på migrering av firmware gäller inte. Dessa telefoner kör PhoneOS, som stöds av både och . För att överföra dessa telefoner till dig måste du lägga till dem i Webex Calling, tilldela dem till en användare eller arbetsyta och sedan fabriksåterställa telefonerna. PhoneOS-startsekvens för registrering Figuren nedan visar PhoneOS-startsekvensen och hur telefonen registreras när den har lagts till, även om telefonen fortfarande är provisionerad. and/or DHCP-alternativ (exempel - 150) används.

stöder fabriksåterställning av PhoneOS-enheter för att möjliggöra Zero-Touch-onboarding till . administratörer kan fjärråterställa fabriksinställningarna för 9800- och 8875-telefonerna via CUCM-administrationssidorna, vilket eliminerar behovet av fysisk åtkomst till telefonerna för att onboarda dem till . Den här funktionen stöds med enhetspaketen från och med 9 september 2025:

• CUCM v15 - Unified Communications Manager version 15

• CUCM v14 - Unified Communications Manager version 14.

För mer information om registreringsprocessen för 9800-serien, se Registreringsprocess.

Förutom Cisco IP-telefoner kan det krävas att andra enheter tillhandahålls, såsom analoga telefonadaptrar (ATA), trådlösa telefoner (Wifi, DECT), videoenheter, röstgateways och enheter och telefoner från^tredje part . Många av dessa enheter har ingen uppgraderingsväg för firmware, som IP-telefoner, för att övergå från företagsfirmware till molnfirmware. Därför kommer du att etablera var och en av dessa enheter i Control Hub. Vissa av dessa kan inte övergå till och motsvarande modell kommer att behöva ersätta den (t.ex. ATA 191/192) och andra kommer att kräva manuell omkonfiguration and/or programvaruändringar.

• Röstgateways – För att migrera din lokala gateway, se Migrera lokal gateway.

  För mer information om hur du konfigurerar din röstgateway VG400, VG410 eller VG420 i Control Hub, se Lokal gateway

• Analog telefonadapter (ATA) – För att komma igång med din Cisco ATA 191 och 192, se Cisco ATA.

• Trådlös Wifi-telefon – För att integrera trådlös telefon 840 och 860, se Integrera trådlös Webex-telefon.

• Trådlösa DECT-telefoner – För att komma igång med din nya Cisco IP DECT 6800-serie, se Cisco IP DECT.

  För att bygga och hantera ett digitalt DECT-nätverk i Control Hub, se Hantera DECT-nätverk

  För mer information om Cisco IP DECT 6800, se Implementeringsguide

• ^{Tredjepartsenheter och telefoner} - Arbeta med^{tredjepartsleverantörer} på device/phone krav och processen för att migrera eller ersätta dem för att stödja .

Alla samtalsfunktioner som krävs måste etableras före eller under övergången. Som diskuterats i avsnittet Migrera användare i batchar måste anropsfunktionerna konfigureras och överföras när de användare som använder dem överförs.

För mer information om hur du konfigurerar varje funktion, se motsvarande konfigurationshjälpartiklar.

• Automatiska receptionister – För att hantera automatiska receptionister, se Automatiska receptionister

• Samtalsparkering - För att hantera samtalsparkering, se Samtalsparkering

• Samtalsmottagning - För att konfigurera samtalsmottagningsgruppen, se Samtalsmottagning

• Samtalsköer - För att konfigurera samtalskö, se Samtalskö

• Jaktgrupper - För att hantera jaktgrupper, se Hantera jaktgrupp

• Driftlägen - För samtalsdirigering baserad på driftlägen, se Samtalsdirigering baserad på driftlägen

• Personsökargrupper - För att konfigurera en personsökargrupp, se Konfigurera en personsökargrupp

• Inspelningar - För att hantera samtalsinspelning för , se Hantera inspelningar

• Räckhåll för ett enda nummer - För att konfigurera räckhåll för ett enda nummer (kontoret var som helst), se Konfigurera ett enda nummer

• Röstbrevlådagrupp – För att hantera en delad röstbrevlåda och inkommande faxlåda för , se Hantera röstbrevlåda.

Acceptanstestning säkerställer att den migrerade miljön uppfyller de funktionella kraven, fungerar som förväntat och ger en sömlös användarupplevelse i alla kommunikationsarbetsflöden. Denna valideringsprocess är mångfacetterad och omfattar allt från användarprovisionering och nummertilldelningar till den operativa prestandan för avancerade samtalsfunktioner.

Det här avsnittet ger exempel och belyser viktiga aspekter att beakta vid acceptanstestning; det är dock inte avsett att fungera som en uttömmande eller heltäckande checklista.

Användarprovisionering och nummertilldelning

En grundläggande aspekt av acceptanstestning innebär att verifiera att alla användare är korrekt och fullständigt provisionerade inom . Detta kräver en noggrann jämförelse mellan källkatalogen () och den nyligen etablerade användarbasen för att säkerställa att varje användarkonto, tillsammans med tillhörande attribut som anknytningsnummer och DID-tilldelningar (direkt inkommande uppringning), har migrerats korrekt. Fullständig etablering är avgörande, inte bara för driften från första dagen utan även för löpande administration och support.

Validering av nummertilldelning inkluderar att bekräfta att varje användare har tilldelats rätt anknytning och externt nummer, och att dessa nummer dirigeras korrekt i både interna (online) och externa (PSTN) samtalsflöden. Det är viktigt att kontrollera om det finns överlappningar, saknade tilldelningar eller felkonfigurationer som kan leda till fel i samtalsrouting eller avbrott i tjänsten.

PSTN-samtalflöden och presentation av nummerpresentation

En robust acceptanstestningsprocedur måste omfatta end-to-end-validering av PSTN-samtalflöden. Detta inkluderar både inkommande och utgående samtalsscenarier. För inkommande PSTN-samtal bör testteamet bekräfta att samtal levereras till de avsedda slutpunkterna, oavsett om det är enskilda användare, samtalsköer, sökgrupper eller automatiska svarare. Utgående PSTN-samtal måste ringas korrekt, med särskild uppmärksamhet på korrekt leverans och presentation av nummerpresentation. Detta innebär att säkerställa att rätt uppringarnamn och nummer visas för externa mottagare, i enlighet med organisationens policyer och myndighetskrav.

Testning bör också ta itu med redundansscenarier, såsom hantering av oåtkomliga slutpunkter eller nätverksavbrott. Detta hjälper till att bekräfta att reservmekanismer och alternativ routing fungerar korrekt, vilket upprätthåller tjänstens kontinuitet och tillförlitlighet.

Samtalsflöden på nätet

Interna samtalsflöden, eller samtalsflöden på nätet, utgör ryggraden i företagskommunikationen. Acceptanstestning inom detta område verifierar att samtal mellan användare inom organisationen dirigeras korrekt, med funktioner som samtalsöverföring, väntekoppling, vidarekoppling och konferenssamtal som fungerar som avsett. Integriteten hos uppringningsplaner, anslutning mellan anknytningar och stödet för organisationens samtalspolicyer måste bekräftas.

Hantering av användarsamtal och funktionsvalidering

En viktig aspekt av acceptanstestning innebär att validera hur användare hanterar samtal med hjälp av och bordstelefoner som stöds. Denna process fokuserar på att bekräfta att de dagliga samtalsflödena är intuitiva och tillförlitliga, och att användarna har sömlös åtkomst till de kärnfunktioner som krävs för deras roller. Testningen bör bedöma hur enkelt användare kan ringa och ta emot samtal, hantera parkerade och återuppta samtal samt utföra både blinda och konsultativa överföringar. Det är också viktigt att kontrollera att vidarekoppling, konferenser och andra avancerade funktioner, som att parkera och hämta samtal eller aktivera störningsfritt läge, är lättillgängliga och fungerar smidigt.

Upplevelsen bör utvärderas med avseende på tydlighet och respons, med hänsyn till hur användare interagerar med samtalshistorik, röstbrevlåda och integrerade kataloger. Ytterligare uppmärksamhet bör ägnas åt möjligheten att flytta aktiva samtal mellan enheter och att effektivt använda samtalskontroller i appen eller på fysiska telefoner. Det yttersta målet är att säkerställa att slutanvändarupplevelsen är konsekvent, effektiv och fullt ut stöder organisationens kommunikationsbehov efter migreringen.

Samtalsköer: Erfarenhet av agent och handledare

Samtalsköer används ofta för att hantera scenarier med stora inkommande samtal. Acceptanstestning fokuserar här på flera dimensioner. Först bör det verifieras att samtal distribueras till agenter enligt den konfigurerade kölogiken, såsom round robin, längsta inaktivitet eller samtidig ringning. Presentationen av köade samtal på agenternas datorer måste granskas för tydlighet och användarvänlighet, vilket säkerställer att agenterna effektivt kan ta emot, vänta och koppla samtal.

För handledare bör skrivbordsupplevelsen utvärderas med avseende på funktioner som realtidsövervakning, samtalsinbrytning och analyser eller insikter i köprestanda. Detta inkluderar men är inte begränsat till validering av dashboards och rapporteringsverktyg som tillhandahåller användbar data om samtalsfördelning, agentaktivitet och kömatifikationer.

Jaktgrupper: Samtalsfördelning

Sökgrupper är en viktig mekanism för att distribuera samtal till fördefinierade användargrupper. Acceptanstestning måste bekräfta att samtal dirigeras till gruppmedlemmar baserat på den konfigurerade sökalgoritmen, och att scenarier som överflöde, vidarebefordran och inget svar hanteras enligt design. Att säkerställa att gruppmedlemskap och samtalsrutningsbeteenden matchar de som tidigare etablerats i är avgörande för driftskonsekvens och användarnöjdhet.

Automatiska svarare: Meddelanden och menyfunktioner

Automatiska telefonister representerar frontlinjen inom automatiserad samtalshantering. Testningen måste omfatta uppspelning av meddelanden, noggrannheten hos inspelade hälsningar och menyträdens korrekta funktion. Menyvalen bör på ett tillförlitligt sätt dirigera uppringare till rätt avdelningar, individer eller externa nummer. Testning bör också inkludera ogiltiga scenarier eller timeout-scenarier för att bekräfta att uppringare får tydlig vägledning eller omdirigeras som avsett.

Röstbrevlådans funktion

Slutligen är röstbrevlådans funktionalitet avgörande för användarupplevelsen. Acceptanstester bör verifiera att röstbrevlådor är korrekt tilldelade och tillgängliga, både inifrån organisationen och på distans. Möjligheten att spela in, hämta och hantera meddelanden måste bekräftas, tillsammans med leverans av aviseringar.