I ikke-færdighedsbaserede køer med teamtildeling kan du organisere agenter i teams og kombinere disse teams for at danne opkaldsdistributionsgrupper (CDG). Du kan angive en tidsforsinkelse mellem hver gruppe for at administrere opkaldsflowet.

Opkaldsdistributionsgrupper hjælper med at definere flere niveauer af agenter, der bliver kvalificerede til at arbejde på kontakter i denne kø over konfigurerede tidsintervaller. Kontakter tildeles til agenter baseret på deres teams niveau. Hvis der ikke er nogen tilgængelige agenter, parkeres kontakterne i en forudkonfigureret varighed, før de udvides til at omfatte den næste gruppe teams. Denne proces fortsætter, indtil en agent er tilgængelig, eller alle grupper er blevet kontrolleret.

Du kan oprette disse typer teams:

• Individuelle teams: Agenter kan organiseres i teams, der kan repræsentere en bestemt organisationsfunktion, som derefter kan blive en del af køer, så kontakter kan distribueres til agenter i disse teams. Du kan mærke en agent til flere teams for at håndtere kontakter fra forskellige køer for effektiv distribution.
• Kapacitetsbaserede teams: Kapacitetsbaseret team (CBT) er en funktion, der dirigerer taleopkald til et kapacitetsbaseret direkte nummer (DN), hvor kapaciteten bestemmer, hvor mange opkald der kan håndteres samtidigt. Det gør det muligt at dirigere opkald til telefonnumre, uden at agenter skal logge på systemet, hvilket gør det velegnet til scenarier, hvor opkald besvares af voicemail, telefonsvarer eller viderestillingsgrupper i stedet for traditionelle callcenter-agenter. I denne opsætning er der ingen specifikke agenter tildelt til teamet, og de bruger ikke Webex Contact Center Agent Desktop.

I dette eksempel er der tre opkaldsdistributionsgrupper, som giver mulighed for måludvidelse, hvilket betyder udvidelse til flere agenter på tværs af teams over konfigurerede tidsintervaller.

Den første opkaldsdistributionsgruppe indeholder TEAM 1, som har 3 agenter konfigureret – A1, A2 og A5.

Den anden opkaldsdistributionsgruppe indeholder TEAM 2, som har 3 agenter konfigureret – A2, A3 og A4.

Den tredje (og sidste) opkaldsdistributionsgruppe indeholder TEAM 3, som har 2 agenter konfigureret – A6 og A7.

Når en kontakt er sat i kø, søger systemet først efter en matchende agent i den første opkaldsdistributionsgruppe. Hvis der ikke findes nogen agenter, parkeres kontakten i den konfigurerede varighed, før måludvidelsen foretages til den næste gruppe. Dette tilføjer nye teams til de eksisterende. Denne proces gentages, indtil den finder et match, eller alle grupper udvides.

En funktion kaldet "Kontroller agenttilgængelighed" får kontakten til øjeblikkeligt at udvide sig til den efterfølgende opkaldsdistributionsgruppe, hvis der ikke findes nogen matchende agenter i den aktuelle gruppe. Dette kan aktiveres i Køkontaktaktivitet <LINK TIL sektion 3.1.1> i flowet.

Denne opsætning resulterer i følgende scenarier:

1. A2 tilhører TEAM 1 og TEAM 2. Hvis A2 vælger TEAM 1 til at logge på Agent Desktop, betragter systemet A2 som en del af TEAM 1 og dermed kun den første opkaldsdistributionsgruppe.
2. A5 tilhører TEAM 1, men kunne også have været en del af et andet team i organisationen, som de aktuelt har logget ind i. Derfor betragtes A5 ikke som en del af TEAM 1 og er ikke tilknyttet denne kø.

Køer med teamtildeling giver agenter denne effektive mulighed for at flytte mellem køer ved blot at vælge et team under logon.

Tilgængeligt routingmønster:

• Længst tilgængelig

Ikke-færdighedsbaserede køer er en type kø, hvor en pulje af agenter tildeles direkte til køen. I modsætning til andre køtyper, som indirekte bestemmer puljen af agenter, der er tildelt dem, giver disse køer administratorer mulighed for at vælge agenter direkte og manuelt. Teambaserede tildelingskøer tildeler f.eks. agenter baseret på deres indloggede teams, og færdighedsbaserede tildelingskøer matcher agenter baseret på påkrævede færdigheder. I modsætning hertil kan administratorer føje agenter direkte til disse køer for at blive en del af køen. Dette giver en enkel måde at administrere agentallokering på uden at være afhængig af systemdrevne tildelinger.

Køer med agenttildeling giver enkle, men effektive distributionsalgoritmer, der hjælper med distribution af kontakter blandt puljen af agenter. De tager ikke hensyn til agenternes færdigheder i distribution af kontakter. Men agenter kan sorteres inden for hver kø, og dette tages i betragtning, når kontakter distribueres til dem. I denne kontekst fungerer teams primært som en organisatorisk konstruktion for supervisorer snarere end en faktor i beslutninger om agent-køtilknytning og kontaktdistribution, hvilket forenkler køstyring.

Denne type kø er bedst egnet, hvor statisk tildeling af agenter og administration af agent-kø-tilknytning er mulig og ønskelig til driftskontrol, og valget af routingalgoritmer er egnet til arbejdsfordeling blandt agenter. Disse køer er også særligt nyttige i scenarier, hvor flere typer kundeforespørgsler kræver specialiseret ekspertise, der kan betjenes af et på forhånd oprettet segment af ekspertagenter.

Komplekse kontaktcenterorganisationer kan dog finde det vanskeligt manuelt at administrere agenttildelinger i disse køer. De kunne drage større fordel af andre køtyper, der tilbyder dynamisk distribution og agent-kø-tilknytninger.

I dette eksempel har køen et sæt agenter tilknyttet i en bestemt rækkefølge, f.eks. A4, A9, A7 osv. Denne rækkefølge spiller en rolle i specifikke distributionsalgoritmer, der matcher indgående kontakter med agenter. Systemet matcher kontakter med disse agenter baseret på deres tilgængelighed og den valgte routingalgoritme.

I modsætning til køer med teamtildeling er der ikke noget koncept for måludvidelse over tidsintervaller. Hvis ingen af de konfigurerede agenter er tilgængelige til at distribuere denne kontakt, parkeres den i kø, indtil en af disse agenter bliver tilgængelig til at håndtere kontakter før parkens timeout. Måludvidelse gælder ikke for disse køer.

Tilgængelige routingmønstre:

• Længst tilgængelig
• Cirkulær
• Lineær/top-down

Administratorer kan tildele fagkriterier til køer. Færdighedsbaserede køer med fagkriterier giver administratorer mulighed for at konfigurere påkrævede færdigheder direkte i køen. Alle agenter i organisationen, der har alle de nødvendige færdigheder i køen via direkte færdighedsprofil, bliver implicit en del af denne kø.

Denne konfiguration hjælper administratorer med at få en direkte visning af agenter, der knytter sig til køen i kraft af deres færdigheder. I situationer med stor eller lav volumen kan administratorer overveje at justere de krævede færdigheder for køen og agentens færdighedsprofiler for at udvide eller formindske agentpuljen efter behov.

Denne type kø adskiller sig fra teamtildelingsbaserede køer i den forstand, at der ikke er nogen opkaldsfordelingsgruppeindstilling, hvilket betyder, at teamet ikke spiller nogen rolle i agent-til-kø-tilknytningen. Desuden konfigureres de krævede færdigheder statisk i denne kø i modsætning til teambaserede færdighedskøer, hvor flowet injicerer (statiske eller variable) krævede færdigheder. Derfor er færdighederne teknisk set en del af køen snarere end selve kontakten.

Enhver agent i organisationen, der fuldt ud opfylder fagkriterierne for køen (har færdigheder fra direkte færdighedsprofil), bliver implicit tilknyttet denne kø. Team spiller ingen rolle i agenttilknytningen til disse køer. Disse agenter kan være en del af ethvert team til administrations- og driftsformål.

Hver kontakt, der sættes i kø i denne kø, antager automatisk de fagkriterier, der er defineret i selve køen. Individuelle kontakter kan ikke definere eller tilsidesætte deres egne kvalifikationskrav/-kriterier i modsætning til i færdighedsbaserede køer med teamtildeling.

I dette eksempel

• Kun agenterne A1, A3 og A7 opfylder fuldt ud de fagkriterier, der er konfigureret i køen, og derfor vil kun disse agenter blive tilknyttet denne kø.
• Agenterne A2, A4 og A6, som delvist opfylder kriterierne, eller A5, som mangler relevante færdigheder, kan ikke tilknyttes denne kø.

Opdatering af en agents færdighedsprofil (kaldet videreuddannelse), så den opfylder fagkriterierne for køen, vil automatisk og dynamisk gøre den pågældende agent til en del af denne kø. Alternativt vil opdatering af selve køfærdighedskriteriet, så flere (eller færre) agenter opfylder de opdaterede fagkriterier, også automatisk og dynamisk tilføje (eller fjerne) agenter fra denne kø.

I modsætning til køer med teamtildeling er der ikke noget koncept for måludvidelse over tidsintervaller. Hvis kontakten ikke kan matches med nogen af de tilknyttede agenter, parkeres den i kø, indtil en af disse agenter bliver tilgængelig til at håndtere kontakter før parkeringstimeout.

Færdighedsbaserede køer er bedst egnede, hvor statisk tildeling af færdigheder og styring af kø til agenttilknytning er mulig og ønskelig for driftskontrol. De er også egnede, når udvælgelsen af routingalgoritmer er passende til arbejdsfordeling blandt agenter. Disse køer er også særligt nyttige i scenarier, hvor forskellige typer kundeforespørgsler kræver specifikke færdigheder, der kan betjenes af et på forhånd afledt segment af ekspertagenter.

Komplekse kontaktcenterorganisationer kan finde det lettere at administrere kø til agent-tildelinger i færdighedsbaserede køer sammenlignet med køer med agenttildeling, hvor hver agent manuelt skal føjes til listen, hvilket er besværligt, især for en større organisation.

Færdighedsbaserede køer med kvalifikationskrav tildelt i flow er en type teamtildelingsbaseret kø i Webex Contact Center, hvor et sæt teams konfigureres på flere niveauer, kaldet opkaldsdistributionsgrupper. Agenter, der er logget på disse konfigurerede teams, tildeles kontakter fra denne kø baseret på niveauet Opkaldsdistributionsgruppe, hvor deres team er konfigureret i køen, hvis de også fuldt ud opfylder kontaktens kvalifikationskrav.

Inden for en sådan kø grupperes agentteams i opkaldsdistributionsgrupper med konfigurerbare tidsforsinkelser mellem dem. Hvis der ikke er nogen agent tilgængelig til kontakten, parkeres anmodningen, og efter forsinkelsen udvides distributionen til den næste opkaldsdistributionsgruppe. Denne proces fortsætter, indtil en agent er tildelt, eller alle grupper er opbrugt. Hvis en agent i en tidligere kontrolleret gruppe bliver tilgængelig under denne proces, vælges den pågældende agent.

Agenter erhverver færdigheder via en færdighedsprofil, der er direkte tildelt agenten. Agentfærdigheder bestemmes ud fra teamvalget under logon.

Hver kontakt kan valgfrit angive kvalifikationskrav i flowet, som matches med færdighederne hos tilgængelige agenter for at vælge den bedst egnede agent.

Derudover kan kontakter også angive færdighedslempelser med konfigurerede tidsintervaller. Disse er ændrede sæt af fagkrav, der ville overskrive kontaktens oprindelige kvalifikationskrav efter konfigurerede tidsintervaller. Dette gør det muligt for en kontakt at ændre (typisk bruges til at "slappe af") sine kvalifikationskrav, mens den er parkeret i kø, så flere agenter kan matche disse lempede færdighedskrav.

Måludvidelse via opkaldsdistributionsgrupper kan ske samtidig med cyklusser for lempelse af færdigheder – begge med det formål at matche en parkeret kontakt med berettigede agenter hurtigere, hvilket reducerer den samlede ventetid og forbedrer serviceniveauet for køen.

Ligesom køer uden færdigheder med teamtildeling har den tre opkaldsdistributionsgrupper, der giver mulighed for "måludvidelse", dvs. udvidelse til flere agenter på tværs af teams over konfigurerede tidsintervaller.

• Den første opkaldsdistributionsgruppe indeholder TEAM 1, som har 3 agenter konfigureret – A1, A2 og A5.
• Den anden opkaldsdistributionsgruppe indeholder TEAM 2, som har 3 agenter konfigureret – A2, A3 og A4.
• Den tredje (og sidste) opkaldsdistributionsgruppe indeholder TEAM 3, som har 2 agenter konfigureret – A6 og A7.

Der er dog to hovedting at bemærke:

• Hver kontakt, der sættes i kø i denne kø, definerer sine færdighedskrav og afslapning gennem flowet.
• Agenter kan have færdigheder konfigureret (via en færdighedsprofil – direkte eller nedarvet fra det team, der er logget på).

Mens A2 er konfigureret til at være en del af både TEAM 1 og TEAM 2, betragtes agenten i sin aktuelle session som en del af dette team og vil derfor også arve færdighedsprofilen (og dermed færdighedsværdierne) fra dette team (medmindre dette tilsidesættes med en direkte færdighedsprofilkonfiguration for denne agent).

Dette er en effektiv funktion, der leveres af køer med teamtildelinger, hvor agenter kan flytte mellem køer ved blot at vælge et team under logon.

Sammen med muligheden for at nedarve indstillinger for færdighedsprofiler fra det valgte team kan en agent også arbejde med forskellige sæt færdigheder.

I dette eksempel

• Kontakter sættes i kø med et indledende færdighedskrav (sk_1 >= 6) under eskalering fra flow med en færdighedslempelse (sk_1 >= 3) efter et konfigureret tidsinterval.
• På tværs af alle agenter i alle opkaldsdistributionsgrupper er det kun A1, A3, A6 og A7, der har færdigheder, der opfylder det oprindelige færdighedskrav til kontakter i kø.
• De resterende agenter har enten færdigheden (sk_1), men opfylder ikke færdighedskravene (f.eks. A2 i TEAM 1 og A4 i TEAM 2), eller har slet ikke denne færdighed (f.eks. A5, A2 i TEAM 2).
• Over tid, efter afslapning af færdigheder, opfylder A2 og A4 nu også kontaktens "afslappede" færdighedskrav.

For hver kontakt, der sættes i kø i denne kø, forsøger systemet at finde en matchende agent inden for distributionsgruppen for første opkald, som fuldt ud opfylder de aktuelle kvalifikationskrav til kontakten. Hvis der ikke findes en matchende agent, parkeres kontakten i den konfigurerede varighed, før måludvidelsen sker med den anden opkaldsdistributionsgruppe. Alle teams, der er konfigureret i den anden opkaldsdistributionsgruppe, føjes også til eksisterende teams fra den første gruppe. Nu forsøger systemet at finde en matchende agent inden for den udvidede gruppe. Bemærk, at mens dette sker, opdaterer fagafslapning også fagkravene til kontakten med konfigurerede tidsintervaller, og systemet bruger opdaterede fagkrav til at matche med tilgængelige agenter i den aktuelle opkaldsdistributionsgruppe.

Dette fortsætter, indtil alle de konfigurerede opkaldsdistributionsgrupper er udvidet, og alle færdighedslempelser er anvendt, medmindre der tidligere findes en matchende agent.

Tilgængelige routingmønstre:

• Længst tilgængelig
• Bedste tilgængelige

Scenariet Agentoverskud opstår, når der er flere tilgængelige agenter, end der er kontakter i kø. I dette tilfælde, når en kundeinteraktion (kontakt) er sat i kø, forsøger systemet straks at finde en matchende agent for denne specifikke kontakt, og hvis der findes en matchende agent, behøver kontakten ikke at blive parkeret i kø og vente på, at en matchende agent bliver tilgængelig senere.

Hver gang en kontakt udvides via en opkaldsdistributionsgruppe eller gennem lempelse af kvalifikationer, forsøger systemet igen at finde en matchende agent til denne specifikke kontakt med det samme.

Når du finder en agent, der matcher en bestemt kontakt, bruges det konfigurerede distributionsmønster i køen.

Webex Contact Center tilbyder flere routingmønstre på tværs af forskellige typer køer, som giver organisationer mulighed for at optimere kundeservice ved at minimere ventetider, afbalancere agentarbejdsbelastninger og sikre, at kunderne er forbundet med agenter, der har de nødvendige færdigheder til at imødekomme deres specifikke behov. Se afsnittet Distributionsmønster for at få detaljerede oplysninger om distributionsmønstre.

Kontaktoverskudsdistribution forekommer, når antallet af indgående kundeinteraktioner (eller kontakter) overstiger de tilgængelige agenter. Denne situation opstår ofte i spidsbelastningstider eller uventede stigninger i kontaktvolumen. Det primære mål med kontaktoverskudsdistribution er at styre dette overløb effektivt og sikre, at kundeservicestandarderne opretholdes på trods af den overskydende efterspørgsel. For en agent, der netop er blevet tilgængelig på en bestemt kanal, arbejder overskydende kontaktdistribution på at finde og tildele den relevante kontakt blandt alle parkerede kontakter på tværs af alle køer, som denne agent er tilknyttet.

De vigtigste strategier til at udføre kontaktdistribution effektivt med begrænset agenttilgængelighed er:

• Kørangering

  Kørangering gør det muligt for administratorer at angive køernes relative vigtighed. Administratorer kan definere køklassificeringer for at indstille den rækkefølge, som opkald distribueres fra køer til agenter, der er logget på teams, i på teambasis.

  Overvej f.eks., at agenter, der er logget på team A, er tilknyttet to køer – "Fakturering" og "Salg". Administratorer kan bruge kørangering til at tildele en højere klassificering til "Fakturering"-køen, så når der kommer kontakter ind i køerne, distribueres kontakter fra "Fakturering" til agenter, der hører til team A, foran kontakter fra "Salg"-køer. Dette sker, selvom der kan være ældre kontakter med højere prioritet, der kunne vente i køen "Salg" – blot fordi køen "Fakturering" har en højere kørangering end køen "Salg". Kun når der ikke er flere ventende kontakter i faktureringskøen, får agenter fra team A tildelt kontakter fra køen "Salg" (og enhver anden), som de er tilknyttet.

  Følgende er nogle af de vigtige egenskaber ved kørangering:

  • • Hvis en klassificering kun tildeles til nogle af køerne, har opkald i disse køer forrang for opkald i køerne, som der ikke er angivet nogen klassificering for.
    • Kørangering kan maksimalt indstilles på 50 køer på tværs af alle medietyper med en værdi mellem 1 og 50 med 1 som den højeste rangering.
    • Du kan tildele den samme rang til flere køer.
    • Hvis du aktiverer kørangering, behandles køer, der ikke er tildelt nogen eksplicit klassificering, lavere end alle rangerede køer.

    • Kørangering fungerer inden for den samme medietype.

      Hvis Køsalg f.eks. er en stemmemedietypekø med rang 2, og Understøttelse af køfakturering er en chatkø med rang 1 for team A, så får agenter, der er tilgængelige på stemmekanalen i team A, taleopkaldet først, selvom rangeringen er 2.

      Overvej dog to chatkøer til Hold B - Køkreditkort med kørang 2 og Kødebetkort med kørang 1. Derefter vil de tilgængelige agenter i team B blive tilbudt kontakter fra kødebetkort først.

    • Kørangering gælder ikke for kapacitetsbaserede teams.

• Kontaktprioritet

  Når en kontakt er sat i kø, kan dens prioritet defineres ved at tildele en hierarkisk vigtighed fra 1 (højest) til 10 (laveste, standard). Denne prioritering sikrer, at visse kontakter adresseres hurtigere baseret på deres vigtighed, hastende karakter eller strategiske værdi for organisationen. Når en agent er tilgængelig til at håndtere den næste kontakt blandt alle parkerede kontakter på tværs af alle køer, som agenten er tilknyttet, distribueres kontakten med højeste prioritet på tværs af alle køer til agenten (forudsat at andre kriterier, f.eks. matchning af færdigheder og andre, er opfyldt).

  For kontakter, der sættes i kø uden nogen eksplicit prioritet, overvejes en standardprioritet på 10 (lavest). Blandt flere kontakter, der har samme prioritet, distribueres den kontakt, der venter i køen i længst tid, først til den tilgængelige og kvalificerede agent.

• Længst ventende kontakt

  Dette er en grundlæggende strategi, der sikrer, at den kontakt, der har ventet længst på tværs af alle køer, som agenten er tilknyttet, distribueres til agenten.

  Dette er det ultimative kriterium, der bestemmer den kontakt, der skal distribueres, når flere kontakter på tværs af køer med samme kørangering og samme kontaktprioritet venter på at blive behandlet.

I bund og grund betyder kontaktoverskudsdistribution for en agent, der lige er blevet tilgængelig, at der vælges en enkelt kontakt, som:

• Er af samme medietype som den, som agenten er tilgængelig på
• Parkeres i en af de køer, som denne agent er knyttet til
• Hvis kvalifikationskrav (hvis nogen) alle opfyldes af denne agent
• Parkeres i en kø, hvis rangering er højere end andre køer, som er konfigureret i agentens team
• Har højeste prioritet blandt alle sådanne kontakter
• Er den ældste ventende kontakt blandt kontakter med samme prioritet

I ovenstående eksempel, der illustrerer et kontaktoverskudsscenarie, er agent A1 logget på TEAM 1 og er blevet tilgængelig til at håndtere kontakter på flere medietyper.

A1 er knyttet til 3 køer – Q1,Q2 og Q3. TEAM 1 har også defineret kørangering, hvor Q1 rangeres højest, derefter henholdsvis Q2 og Q3 .

Der er kontakter, der allerede er parkeret i alle disse køer, hvor fagkrav og prioritet er defineret for hver kontakt.

Nu fungerer kontaktoverskudsscenariet som følger:

• Blandt alle de parkerede kontakter på tværs af disse køer kan kun 4 kontakter distribueres til A1–C2,C7 (fra KØ 2) ogC3,C8 (fra KØ 3).

  Kun færdighedskravene til disse 4 kontakter opfyldes fuldt ud af A1's færdigheder.

• Blandt disse 4 kontakter gives prioritet til kontakter fra KØ 2 (dvs. C2, C7), fordi KØ 2 har den højeste kørangering.

  Bemærk, at selvom KØ 1 er den højest rangerede kø, kan ingen af de parkerede kontakter dirigeres til A1, da deres kvalifikationskrav ikke opfyldes af A1.

• Mellem C2 og C7 erkontakten med højeste prioritet C7 . Så det endelige valg er C7 , og systemet dirigererdet til A1.

  Dette sker, selvom C2 blev sat i kø tidligere, fordi kontaktprioriteten har forrang for tiden i kø.

Gennem multimedieprofilkonfiguration giver Webex Contact Center agenter mulighed for at servicere kontakter på tværs af forskellige medietyper (stemme, chat, e-mail og sociale medier). Baseret på denne konfiguration får agenter klargjorte kanaler pr. medietype.

Hver kontakt, der distribueres til en agent, bruger én kanal af den pågældende medietype, så længe agenten arbejder på den pågældende kontakt. Mens agenter kun kan have én stemmekanal, kan de have op til fem kanaler af andre medietyper.

Indstillingen blandet distribution i multimedieprofiler giver administratorer mulighed for at styre, hvordan forskellige kanaler kan bruges samtidigt for hver agent. Dette gør det muligt for organisationer at give dedikeret opmærksomhed til kunder, fremme bedre servicekvalitet, forbedret kundeoplevelse og bedre konverteringsfrekvenser. Organisationer kan også afbalancere belastningen på tværs af mediekanaler, når de oplever ujævn belastning i nogle kanaler, hvilket muliggør effektiv udnyttelse af agenter.

Der er tre valgmuligheder:

• Eksklusiv – agenten kan kun håndtere én kontakt af enhver medietype ad gangen.

  Dette er nyttigt, når organisationen forventer, at agenter fokuserer fuldstændigt på én opgave ad gangen.

• Blandet – Et vilkårligt antal kontakter af hver medietype kan håndteres samtidigt op til kapaciteten for de konfigurerede kanaler.

  Dette er nyttigt, når en organisation forventer, at agenter multitasker og arbejder på flere kontakter på tværs af forskellige medietyper.

• Blended-Realtime - Samme som blandet, men stemme og chat udelukker hinanden. Hvis stemmen håndteres, vises chatkontakter ikke og omvendt.

  Dette er nyttigt, når organisationen forventer, at agenter multitasker, men stadig giver agenten mulighed for at fokusere på en enkelt "realtidskontakt" (stemme eller chat), så agenten kan være fuldt opmærksom på slutkunden i den anden ende.

Du kan finde flere oplysninger om konfiguration af multimedieprofiler under Administrere multimedieprofiler.

Færdighedsbaserede distributionsmønstre i Webex Contact Center diriger indgående kundeinteraktioner til agenter baseret på specifikke færdigheder, der kræves for at løse forespørgslen, såsom sprogfærdigheder eller teknisk ekspertise. Disse mønstre sikrer, at hver kunde opretter forbindelse til den mest kvalificerede agent, hvilket forbedrer serviceeffektiviteten og kundetilfredsheden. Fordelene omfatter reduceret håndteringstid, forbedrede løsningsrater og optimeret brug af agentressourcer ved at tilpasse deres ekspertise til kundernes behov.

Når der bruges færdighedsbaserede distributionsmønstre, bruges først kontaktens færdighedskrav (tildelt i flow) eller de færdighedskriterier, der er tildelt til køen, til at filtrere tilgængelige agenter, hvis færdigheder opfylder disse krav / kriterier fuldstændigt. Blandt agenter, der filtreres, vælges der derefter en enkelt til kontakten baseret på det konfigurerede routingmønster.

Webex Contact Center understøtter også en række ikke-færdighedsbaserede routingmønstre, der fokuserer på at distribuere indgående kundeinteraktioner uden at overveje agenternes specifikke færdigheder eller ekspertise. I modsætning til færdighedsbaserede routingmønstre tager disse ikke hensyn til agentfærdigheder eller kræver, at kontakten eller køen definerer kvalifikationskrav/kriterier for distribution. De prioriterer snarere faktorer som tilgængelighed, arbejdsbelastningsfordeling og foruddefinerede sekvenser, hvilket giver mulighed for effektiv håndtering af kontakter baseret på driftslogik snarere end individuelle agentkompetencer. Disse mønstre er især nyttige i miljøer, hvor interaktioner er relativt ensartede eller ikke kræver specialiseret håndtering.

Agentbaseret distribution er en funktion, der distribuerer eller sætter en kontakt i kø til en angivet ("foretrukken") agent direkte. Et agentopslag med agentens mailadresse eller agentens id distribuerer en kontakt til den foretrukne agent. Kø til agent-aktiviteten i flowet hjælper med at opnå agentbaseret routing. Du kan finde flere oplysninger i Kø til agent-aktivitet .

En kontakt kan have en tilknytning til en eller flere foretrukne agenter, som typisk kan administreres i et eksternt program uden for Webex Contact Center. Den foretrukne agentopslag for en kontakt foretages via HTTP-anmodningsaktiviteten , som henter tilknytningen fra et eksternt program. Hvis du vil distribuere eller parkere kontakten med den foretrukne agent, skal du konfigurere aktiviteten Kø til agent ved hjælp af agentens Webex Contact Center-id eller e-mail-adresse. Kontakten kan også parkeres mod en foretrukken agent, hvis den foretrukne agent ikke er tilgængelig med det samme.

Agentbaseret distribution er nyttig i følgende scenarier:

• Foretrukken agentdistribution: Kunden kan tildele kontakter til dedikerede agenter eller relationsledere. I sådanne scenarier distribuerer den agentbaserede routing kontakterne direkte til den foretrukne agent.
• Sidste agentdistribution: Når en kontakt ringer tilbage til kontaktcentret flere gange for at interagere med en agent, kan agentbaseret distribution dirigere kontakten til den sidste agent, der behandlede kontakten.

I begge brugstilfælde gemmes oplysningerne om kontakten og agenttilknytningen uden for Webex Contact Center.

Køkontaktaktiviteten giver mulighed for at sætte en kontakt i kø i en aktiv indgående kø fra organisationen, så den kan matches og distribueres til den rigtige agent i den pågældende kø.

Følgende aspekter af kødannelse kan styres via denne aktivitet:

• Prioritet – Tildeling af en hierarkisk vigtighed fra 1 (højest) til 10 (lavest, standard) til den kontakt, der sættes i kø.
• Færdighedskrav – Angiv de færdighedskriterier, der skal opfyldes af agenter i en færdighedsbaseret kø for at blive betragtet som kvalificerede til distribution af kontakten.
• Færdighedsafslapninger - Tuning, ændring eller fjernelse af tidligere indstillede færdighedskrav efter en periode for at forbedre chancerne for at finde en agent.
• Kontroller agenttilgængelighed – Tillad, at systemet øjeblikkeligt udvides gennem alle opkaldsdistributionsgrupper, hvor der ikke findes nogen tilgængelige agenter, for at undgå ventetid.

Se Routing for at få flere oplysninger om, hvordan prioritet, færdighedskonfiguration og agenttilgængelighed spiller en rolle ved distribution af kontakter.

Når kontaktkøaktiviteten har sat kontakten i kø,

• Hvis der allerede er en matchende agent tilgængelig, forsøger systemet at dirigere kontakten til en agent.

  Dette afbryder udførelsen af hovedflowet , og yderligere hændelser kan udløse de respektive hændelsesflows, hvis de er konfigureret.

• Hvis der ikke findes en matchende agent, parkeres kontakten i køen og venter på, at en matchende agent bliver tilgængelig.

  Flowudførelsen fortsætter derefter med de aktiviteter, der er knyttet efter køkontaktaktiviteten, hvilket giver mulighed for at:

  • Afspil en forudkonfigureret musik til kunden, der venter i kø - ved at vedhæfte en PlayMusic-aktivitet .
  • Registrer et tilbagekald baseret på kundens anmodning - ved at vedhæfte en tilbagekaldsaktivitet .
  • Sæt kontakten i kø igen, dvs. fjern kontakten fra den aktuelle kø, og føj den til en ny kø – ved at knytte en anden køkontakt eller kø til agentaktivitet .

Når en matchende agent bliver tilgængelig, forsøger systemet at dirigere kontakten til agenten.

Når det lykkes, afbryder dette udførelsen af hovedflowet , og yderligere hændelser kan udløse de respektive hændelsesflows, hvis de er konfigureret.

I sådanne tilfælde resulterer aktiviteten i en fejl, og flowudførelsen flyttes til fejlhåndteringsstien .

Du kan finde flere oplysninger om aktivitetsindstillinger, forbrugs- og outputvariabler i Oprette og administrere flows > køkontakt.

Aktiviteten Kø til agent giver mulighed for at sætte kontakten i kø direkte til en foretrukken agent ved at slå vedkommendes entydige agent-id eller mailadresse op i Webex Contact Center.

Følgende aspekter af kødannelse kan styres via denne aktivitet:

• Prioritet – Tildel en højere/lavere prioritet til kontakter, der står i kø mod den samme agent.
• Rapporteringskø – Identificer køen, der skal bruges til konfiguration, f.eks. optagelse og standardmusik i køen, og rapportformål for kontakten.
• Genoprettelseskø – Identificer køen, der skal bruges som reserve, når kontakten ikke kunne distribueres til den angivne foretrukne agent.

Når kø til agent-aktiviteten har sat kontakten i kø,

• Hvis agenten allerede er tilgængelig, distribueres kontakten til agenten.

  Dette afbryder udførelsen af hovedflowet , og yderligere hændelser kan udløse de respektive hændelsesflows, hvis de er konfigureret.

• Hvis agenten er tilgængelig, men vælger at afvise, ikke svare eller ikke modtager kontakten, flyttes den til den angivne gendannelseskø.

  I gendannelseskøen distribueres kontakten til den agent, der har været længst tilgængelig, uden understøttelse af færdigheder.

• Hvis agenten ikke er tilgængelig, og indstillingen " Parker kontakt, hvis agent ikke er tilgængelig " er valgt, parkeres kontakten og venter på, at agenten bliver tilgængelig.

  Flowudførelsen fortsætter derefter med de aktiviteter, der er knyttet efter aktiviteten Kø til agent, hvilket giver mulighed for at:

  • Afspil en forudkonfigureret musik til kunden, der venter i kø - ved at vedhæfte en PlayMusic-aktivitet .
  • Genkaldsaktivitet .
  • Sæt i kø igen, dvs. fjern kontakten fra den aktuelle kø, og tilføj den til en ny kø – ved at knytte en anden kø til agent - eller køkontaktaktivitet .

  Når agenten bliver tilgængelig, forsøger systemet at dirigere kontakten til agenten.

  Dette afbryder udførelsen af hovedflowet , og yderligere hændelser kan udløse de respektive hændelsesflows, hvis de er konfigureret.

• Hvis agenten ikke er tilgængelig, og indstillingen " Parker kontakt, hvis agent ikke er tilgængelig " ikke er valgt, mislykkes køen.

I sådanne tilfælde resulterer aktiviteten i en fejl, og flowudførelsen flyttes til fejlhåndteringsstien .

Du kan finde flere oplysninger om aktivitetsindstillinger, forbrugs- og outputvariabler i Oprette og administrere flows > kø til agent.

Aktiviteten Eskaler opkaldsdistributionsgruppe understøttes kun for køer med teamtildeling og giver mulighed for at opdatere opkaldsdistributionsgruppen for kontakten med det samme i stedet for at vente på, at den automatiske udvidelsesopdatering sker for den næste gruppe efter den konfigurerede ventetid. Dette gør det muligt hurtigt at distribuere kontakten til alle kvalificerede agenter i køen.

Ved hjælp af aktiviteten Eskaler opkaldsdistributionsgruppe kan kontakten eskaleres til:

• Næste gruppe – Udvidelse af teamsættet til at omfatte dem, der er tilføjet i den umiddelbart næste opkaldsdistributionsgruppe.
• Sidste gruppe – Udvidelse af teamsættet til at omfatte alle de teams, der er tilknyttet på tværs af alle opkaldsdistributionsgrupper, der er konfigureret for køen.

I sådanne tilfælde resulterer aktiviteten i en fejl, og flowudførelsen flyttes til fejlhåndteringsstien .

Overvej et eksempelscenarie, hvor en kontakt sættes i kø i en kø med tre opkaldsdistributionsgrupper, der hver opdateres efter en periode på 30 sekunder.

Ingen agenter er tilgængelige i teamdelen af CDG 1 og CDG 2, og en agent er tilgængelig i TEAM 3 , som hører til distributionsgruppen for sidste opkald.

Når aktiviteten Eskaler opkaldsfordelingsgruppe ikke bruges i flowet, resulterer det i en lang ventetid som vist nedenfor:

Ventetiden kan sænkes ved hjælp af aktiviteten Eskaler opkaldsdistributionsgruppe, der bruges på følgende måde:

Baseret på indstillingen Næste gruppe eller Sidste gruppe , der er valgt, reduceres ventetiden på kontakten betydeligt, som illustreret nedenfor:

Du kan finde flere oplysninger om aktivitetsindstillinger, forbrugs- og outputvariabler i Oprette og administrere flows > Eskaler opkaldsdistributionsgruppe.

Aktiviteten Hent køoplysninger giver mulighed for at hente køoplysninger i realtid for en given kontakt, f.eks.:

• Kontaktens aktuelle position i kø (PIQ) eller den potentielle position, hvis den endnu ikke er sat i kø.
• Den estimerede ventetid eller varighed, hvor en opgave estimeres at vente i køen, før den besvares.
• Antallet af agenter, der er logget på eller tilgængelige i kontaktens aktuelle opkaldsdistributionsgruppe.
• Antallet af agenter, der er logget på eller tilgængelige på tværs af alle opkaldsdistributionsgrupper for den valgte kø.
• Den varighed, som den ældste kontakt i køen har ventet på.

Disse oplysninger gøres tilgængelige i flowudførelsen som aktivitetsoutputvariabler.

Du kan finde flere oplysninger om aktivitetsforbruget, den detaljerede definition og beregningsmetoden for hver kødetalje i Oprette og administrere flows > Hent køoplysninger.

Nogle af måderne at bruge køoplysningerne på kan være:

• At meddele kontaktens placering i kø og estimerede ventetid til kunden, mens vedkommende venter på at blive sendt.
• At afgøre, om et tilbagekald kan registreres for kunden, hvis den estimerede ventetid er for lang.
• At eskalere kontakten til næste opkaldsdistributionsgruppe (CDG), hvis der ikke er nogen agenter tilgængelige i teams, der er knyttet til den aktuelle CDG.

I disse tilfælde angiver værdien -1 i disse outputfelter, at disse oplysninger ikke er relevante.

Overvej et eksempelscenarie, hvor kunden skal informeres om en lang EWT i køen efter hvert 15. sekund, der er brugt i køen.

Dette kan opnås ved at bruge aktiviteten Hent køoplysninger i flowet på følgende måde:

Aktiviteten Avancerede køoplysninger giver mulighed for at hente køoplysninger i realtid for en given kontakt under hensyntagen til kontaktens færdighedskriterier, f.eks.:

• Kontaktens aktuelle position i kø (PIQ) eller den potentielle position, hvis den endnu ikke er sat i kø.
• Antallet af agenter, der er logget på eller tilgængelige i kontaktens aktuelle opkaldsdistributionsgruppe, der matcher de angivne færdighedskriterier.
• Antallet af agenter, der er logget på eller tilgængelige på tværs af alle opkaldsdistributionsgrupper for den valgte kø, og som matcher de angivne færdighedskriterier.
• Den aktuelle opkaldsdistributionsgruppe, hvor kontakten er parkeret i en angivet kø.
• Det samlede antal opkaldsdistributionsgrupper i en angivet kø.

Disse oplysninger gøres tilgængelige i flowudførelsen som aktivitetsoutputvariabler.

Du kan finde flere oplysninger om aktivitetsforbruget, den detaljerede definition og beregningsmetoden for hver kødetalje i Oprette og administrere flows > Avancerede køoplysninger.

Nogle af måderne at bruge de avancerede køoplysninger på kan være:

• At meddele kontaktens placering i kø til kunden, mens vedkommende venter på at blive sendt.
• For at eskalere kontakten til næste opkaldsdistributionsgruppe, hvis ingen agenter, der matcher fagkriterierne, er tilgængelige i teams, der er knyttet til den aktuelle opkaldsdistributionsgruppe.
• At afgøre, om et tilbagekald kan registreres for kunden, hvis der ikke er logget nogen agenter, der matcher fagkriterierne, på tværs af alle opkaldsdistributionsgrupper.

I sådanne tilfælde resulterer aktiviteten i en fejl, og flowudførelsen flyttes til fejlhåndteringsstien .

Overvej et eksempelscenarie, hvor kunden bør informeres om at modtage et tilbagekald, da der ikke er nogen agenter, der opfylder færdighedskriterierne.

Dette kan opnås ved at bruge aktiviteten Avanceret køinfo i flowet på følgende måde:

Aktiviteten Angiv opkalds-id bruges til at definere det opkalds-id, der skal vises under et opkald. Aktiviteten Angiv opkalds-id må kun bruges på hændelsesflow for forhåndsopkald som en terminalaktivitet, der markerer afslutningen på hændelsesflowet.

Aktiviteten Angiv opkalds-id gør det muligt at konfigurere den påkrævede ANI-aktivitet (Automatic Number Identification) baseret på DNIS (Dialed Number Identification Service), operationstype eller deltagertype.

Du kan finde flere oplysninger om aktivitetsindstillinger, forbrugs- og outputvariabler i Oprette og administrere flows > Angiv opkalds-id.

Aktiviteten Optagelseskontrol er designet til at blive brugt sammen med en menuaktivitet til at indsamle samtykke til optagelse fra den, der ringer op. Dette sikrer overholdelse af regler eller politikker, der kræver udtrykkeligt samtykke, før optagelsen begynder, og integrerer dette trin problemfrit i arbejdsgangen.

Menuaktiviteten IVR skal registrere brugerens samtykke i en boolsk variabel, der vil blive tildelt som input til aktiviteten Optagelseskontrol. Hvis kunden skal rapportere brugerens samtykke i en samtykkerapport, skal samtykkeværdien gemmes i en rapporterbar global variabel. Alternativt kan en lokal variabel bruges, hvis rapportering ikke er påkrævet. Denne tilgang giver lejere og kunder øget fleksibilitet i at styre og udnytte variabler effektivt.

Når denne aktivitet tilføjes til flowet, har brugerens samtykke forrang frem for konfigurationsindstillingerne på lejerniveau, køniveau eller optagelsesplanniveau.

Prioritetsrækkefølgen er som følger:

• Hvis brugersamtykket er Ja i flowet, optages opkaldet, uanset den optagelseskonfiguration, der er angivet på lejer-, kø- eller optagelsesplanniveau.
• Hvis brugeren ikke giver samtykke som svar på aktiviteten, optages opkaldet ikke, uanset den optagelseskonfiguration, der er angivet på lejer-, kø- eller optagelsesplanniveau.
• Hvis aktiviteten Optagelseskontrol ikke er konfigureret i flowet, men en konfiguration er indstillet til Ja på et af de andre niveauer, f.eks. lejer eller kø eller optagelsesplan, optages opkaldet.
• Hvis aktiviteten Optagelseskontrol ikke er konfigureret i flowet, og en konfiguration er indstillet til Nej på alle niveauer, f.eks. lejer, kø og optagelsesplan, optages opkaldet ikke.

Denne optagelseskontrol kan illustreres som følger:

Derudover forbliver optagelseskonfigurationer som Fortsæt ved overførsel, Pause Genoptag aktiveret, Pausevarighed og andre gældende i henhold til det eksisterende hierarki, herunder lejer-, kø- eller optagelsesplanniveauer.

For yderligere information om aktivitetsindstillinger, brug og outputvariabler, se Opbyg og administrer flows > Optagelseskontrol.

Blind overførsel er en proces, hvor en kontakt effektivt dirigeres til et eksternt opkaldsnummer (DN) via IVR-systemet, hvilket eliminerer behovet for agentinddragelse.

Aktiviteten Blind omstilling bruges, når et opkald skal omstilles til et eksternt eller tredjeparts DN. Dette er en terminalaktivitet, så flowet slutter, når overførslen er udført.

Blind overførselsaktivitet understøttes ikke, når flowet udføres til konsultation.

For yderligere information om aktivitetsindstillinger, brug og outputvariabler, se Opbyg og administrer flows > Blind overførsel.

Aktiviteten Bridged Transfer gør det muligt midlertidigt at overføre en kontakt til en ekstern destination, mens flowet bevarer kontrollen over opkaldet. Den eksterne destination kan være en ekstern bro eller en Interactive Voice Response (IVR) tjeneste.

Når den eksterne destination afslutter opkaldet, fortsætter opkaldsflowet efter behov, f.eks. ved at sætte det i kø hos en agent.

Aktiviteten Bridge Transfer fjerner køen til en kontakt, mens den overføres til et tredjepartssystem IVR eller et automatisk opkaldsfordelingssystem (ACD). Hvis kontakten ikke håndteres af tredjepartssystemet, kan den sættes tilbage i den oprindelige kø, hvilket sikrer, at kontakten forbliver i arbejdsgangen for korrekt håndtering.

Antag f.eks., at et kontaktcenter har Webex Contact Center agentressourcer og agentressourcer på et eksternt callcenter eller en privat central (PBX). Kunden ønsker at sætte et opkald i kø op mod en kø af Webex Contact Center-agenter i en kort periode (f.eks. 60 sekunder). Hvis der ikke er nogen agent tilgængelig i den periode, kan opkaldet derefter omstilles via en bro (med en implicit fjernelse af køen) til det eksterne callcenter, der håndterer kontakten.

For yderligere information om aktivitetsindstillinger, brug og outputvariabler, se Opbyg og administrer flows > Brooverført overførsel.

Aktiviteten Afbryd kontakt giver mulighed for at afbryde eller afslutte en aktiv kontakt direkte fra flowet.

Dette er en terminalaktivitet, der er knyttet til flowet, og som kan være nyttig til at afslutte kontakter uden en agents indgriben, hvilket er egnet til fejlflows eller efter registrering af et tilbagekald for kunden.

Baseret på konfigurationen udløses POST opkaldsundersøgelsen eller feedbacken, når kontakten afsluttes via denne aktivitet.

For yderligere information om aktivitetsindstillinger, brug og outputvariabler, se Opbyg og administrer flows > Afbryd kontakt.

En tilbagekaldsaktivitet giver opkaldere mulighed for at anmode om et tilbagekald i stedet for at vente på hold, hvilket forbedrer kundetilfredsheden betydeligt ved at reducere ventetider og minimere antallet af afbrudte kunder. Når den er aktiveret, opretter tilbagekaldsaktiviteten en opgave i en kø, hvilket sikrer, at en tilgængelig agent kan returnere kundens opkald.

Flowdesigneren kan konfigurere aktiviteten til enten at beholde kontakten i den oprindelige kø, hvor opkaldet opstod, eller tildele den til en anden kø baseret på præferencer. Hvis tilbagekaldet forbliver i den oprindelige kø, beholder kontakten sin position, færdigheder, prioritet og kontekstuelle data, hvilket muliggør problemfri tildeling til den næste tilgængelige agent. Hvis der vælges en anden kø, skubbes kontakten dog til slutningen af den valgte kø uden færdigheder og med standardprioritet.

Aktiviteten giver også kunderne mulighed for at anmode om tilbagekald fra deres foretrukne agenter, hvilket tilføjer et personligt præg til oplevelsen og øger kundetilfredsheden. Dette kan opnås, når callback-aktiviteten følger en QueueToAgent-aktivitet i flowet. Derudover tilbyder tilbagekaldsaktiviteten en valgfri konfiguration til tilpasning af den automatiske nummeridentifikation (ANI), der bruges under tilbagekaldsprocessen. Denne tilpasning bidrager til brandens konsistens og reducerer sandsynligheden for afvisning af opkald ved at sikre et genkendeligt nummeropkald.

Flowdesigneren har mulighed for at inkludere en CallbackFailed-hændelse i hændelsesflowet. Denne hændelse udløses, når et tilbagekaldsforsøg mislykkes, hvilket gør det muligt for flowdesigneren at implementere nye forsøg med bestemte intervaller. Forsinkelsen eller intervallet mellem genforsøg kan konfigureres ved hjælp af aktiviteten Vent, med et minimumsinterval på 10 sekunder og et maksimum på 72 timer. Systemet understøtter op til 10 nye forsøg over en maksimal periode på 14 dage ved hjælp af venteaktiviteten.

For yderligere information om aktivitetsindstillinger, brug og outputvariabler, se Opbyg og administrer flows > Tilbagekald.

Aktiviteten Opkaldsstatusanalyse (CPA) muliggør detektion af automatiserede telefonsvarer og levende menneskelige stemmer på tilbagekald.

Når et tilbagekaldsforsøg støder på en telefonsvarer (AMD) eller voicemail, identificerer systemet opkaldet som mislykket. Resultatet af Answering Machine Detection (AMD) registreres i outputvariablen årsag i CallbackFailed-hændelseshandleren. Baseret på denne outputvariabel kan flowdesigneren konfigurere tilbagekaldsforsøg.

For yderligere information om aktivitetsindstillinger, brug og outputvariabler, se Opbyg og administrer flows > Analyse af opkaldsstatus.