Forstå ruting og kø i Webex kontaktsenter

I denne artikkelen

Tilbakemelding?

Denne artikkelen gir en oversikt over hvordan Webex kontaktsenter håndterer og leder innkommende interaksjoner med agenter. Den dekker ulike typer køer, som ferdighetsbaserte og ikke-ferdighetsbaserte og rutingsmetoder som Lengst tilgjengelig, Sirkulær og Best tilgjengelig. Den forklarer også flytaktiviteter som hjelper administratorer med å administrere interaksjoner, tildele agenter, kontrollere samtaleflyt og få køoppdateringer i sanntid for å forbedre driften og kundenes erfaring.

Kø

Oversikt

I Webex Contact Center fungerer en kø som et venteområde for innkommende interaksjoner som telefoni, chat, e-post eller sosiale kanaler.Kontakter parkeres i køer til de automatisk distribueres til agenter eller agenter henter dem manuelt for håndtering.I tillegg støtter de funksjoner som ferdighetsbasert ruting, prioritetsadministrasjon og rettferdig arbeidsbelastningsdistribusjon.

Ledere kan bruke køer til å observere forskjellige arbeidslinjer og forbedre hvordan oppgaver håndteres i kontaktsenteret.

Noen av de viktigste fordelene ved å bruke køer effektivt er:

Bedre kundeopplevelse:Administrer ventetider og la kundene få vite at de er i kø for å få hjelp.
Økt effektivitet:Sørg for at anrop håndteres på en ordentlig måte, noe som reduserer kaos og feil håndtering.
Rettferdig Distribusjon av kontakter:Distribuer anrop jevnt mellom agenter for å hindre overbelastning av enkeltagenter.
Prioritetshåndtering:Tillat prioritering av bestemte samtaler, for eksempel VIP-kunder eller hasteproblemer.

Typer køer

Webex Contact Center støtter flere typer køer som muliggjør en rekke brukstilfeller for kontaktsentre av alle størrelser og kompleksiteter, på tvers av alle medietyper med ensartede funksjoner.

Det finnes køer som vurderer agentferdigheter i rutingskontakter, og køer som ikke gjør det.Disse køene er også forskjellige når det gjelder hvordan agenter er knyttet til dem for å arbeide med kontakter.

Det finnes to brede kategorier av køer:

Ikke-ferdighetsbaserte køer
Ferdighetsbaserte køer

Ikke-ferdighetsbaserte køer

Ikke-ferdighetsbaserte køer vurderer ikke ferdigheter knyttet til agenter.Du kan konfigurere ikke-ferdighetsbaserte køer med følgende alternativer:

Teamoppgaver
Agentoppgaver

Ikke-ferdighetsbaserte køer med teamoppgaver

I ikke-ferdighetsbaserte køer med teamtilordning kan du organisere agenter i team og kombinere disse teamene for å danne samtaledistribusjonsgrupper (CDG).Du kan angi en tidsforsinkelse mellom hver gruppe for å administrere samtaleflyten.

Samtaledistribusjonsgrupper hjelper med å definere flere nivåer av agenter som blir kvalifiserte for å jobbe med kontakter i denne køen over konfigurerte tidsintervaller.Kontakter tilordnes agenter basert på teamnivå.Hvis ingen agenter er tilgjengelige, parkeres kontaktene i en forhåndskonfigurert varighet før de utvides til neste gruppe av team.Denne prosessen fortsetter til en agent er tilgjengelig eller alle grupper er sjekket.

Du kan sette opp disse typer team:

Individuelle team:Agenter kan organiseres i team som kan representere en bestemt organisasjonsfunksjon, som deretter kan bli en del av køer slik at kontakter kan rutes til agenter i disse teamene.Du kan tagge en agent til flere team for å håndtere kontakter fra forskjellige køer for effektiv ruting.
Kapasitetsbaserte team:Kapasitetsbasert team (CBT) er en funksjon som sender taleanrop til et kapasitetsbasert direkte nummer (DN), der kapasiteten bestemmer hvor mange samtaler som kan behandles samtidig.Det gjør det mulig å rute anrop til telefonnumre uten at agenter må logge på systemet, noe som gjør det egnet for scenarier der anrop besvares med talepost, telefonsvarere eller huntgrupper, i stedet for tradisjonelle telefonsenteragenter.I dette oppsettet er det ingen spesifikke agenter tilordnet teamet, og de bruker ikke Webex Contact Center Agent Desktop.

｟_ph_1｠

I dette eksemplet er det tre samtaledistribusjonsgrupper, som tillater målutvidelse, noe som betyr å utvide til flere agenter på tvers av team over konfigurerte tidsintervaller.

Den første samtaledistribusjonsgruppen inneholder TEAM 1, som har 3 agenter konfigurert – A1, A2 og A5.

Den andre samtaledistribusjonsgruppen inneholder TEAM 2, som har 3 agenter konfigurert – A2, A3 og A4.

Den tredje (og siste) samtaledistribusjonsgruppen inneholder TEAM 3, som har 2 agenter konfigurert – A6 og A7.

Når en kontakt står i kø, søker systemet først etter en samsvarende agent i den første samtaledistribusjonsgruppen.Hvis det ikke finnes noen agenter, parkeres kontakten i den konfigurerte varigheten før målutvidelsen gjøres til neste gruppe.Dette legger til nye team til de eksisterende.Denne prosessen gjentas til den finner en match, eller alle grupper utvides.

En funksjon kalt «Sjekk agenttilgjengelighet» fører til at kontakten umiddelbart utvides til den påfølgende samtaledistribusjonsgruppen hvis det ikke finnes noen samsvarende agenter i den gjeldende gruppen.Dette kan aktiveres i køkontaktaktiviteten <LINK TO section 3.1.1> i flyten.

Dette oppsettet resulterer i følgende scenarioer:

A2 tilhører TEAM 1 og TEAM 2.Hvis A2 velger TEAM 1 å logge på Agent Desktop, vil systemet vurdere A2 en del av TEAM 1 og dermed kun den første samtaledistribusjonsgruppen.
A5 tilhører TEAM 1, men kan også ha vært en del av et annet team i organisasjonen de for øyeblikket har logget på.Derfor A5 anses ikke som en del av TEAM 1 og er ikke knyttet til denne køen.

Køer med teamtilordning gir agenter denne kraftige kapasiteten til å flytte mellom køer ved å velge et team under pålogging.

Tilgjengelig rutingsmønster:

Longest Available

Ikke-ferdighetsbaserte køer med agenttilordninger

Ikke-ferdighetsbaserte køer er en type kø der en gruppe agenter er direkte tilordnet køen.I motsetning til andre køtyper, som indirekte bestemmer utvalget av agenter som er tilordnet dem, lar disse køene administratorer velge agenter direkte og manuelt.For eksempel tilordner teambaserte tildelingskøer agenter basert på deres innloggede team, og ferdighetsbaserte tildelingskøer samsvarer agenter basert på nødvendige ferdigheter.Administratorer kan derimot legge til agenter direkte i disse køene for å bli en del av køen.Dette gir en enkel måte å administrere agenttildeling på uten å være avhengig av systemdrevne oppgaver.

Køer med agenttilordning gir enkle, men effektive rutingsalgoritmer som hjelper til med distribusjon av kontakter mellom agentgruppen.De tar ikke hensyn til agentenes ferdigheter i ruting kontakter.Agenter kan imidlertid bestilles i hver kø, og dette tas i betraktning ved ruting av kontakter til dem.I denne sammenhengen fungerer teamene først og fremst som en organisasjonskonstrukt for ledere i stedet for som en faktor i tilknytning til agent/kø og beslutninger om kontaktruting som forenkler køadministrasjon.

Denne typen kø er best egnet der statisk tilordning av agenter og administrasjon av agent-kø-tilknytning er mulig og ønskelig for operativ kontroll, og valget av rutingsalgoritmer er egnet for arbeidsdistribusjon mellom agenter.Disse køene er også spesielt nyttige for scenarier der flere typer kundehenvendelser krever spesialisert ekspertise som kan betjenes av et forhåndsopprettet segment av ekspertagenter.

Komplekse kontaktsenterorganisasjoner kan imidlertid finne det vanskelig å administrere agentoppgaver manuelt i disse køene.De kan dra mer nytte av andre køtyper som tilbyr dynamisk ruting og agent-kø-assosiasjoner.

｟_ph_1｠

I dette eksemplet har køen et sett med agenter tilordnet den i en bestemt rekkefølge, for eksempel A4, A9, A7 og så videre.Denne ordren spiller en rolle i spesifikke rutingsalgoritmer som samsvarer med innkommende kontakter til agenter.Systemet samsvarer kontakter med disse agentene basert på deres tilgjengelighet og den valgte rutingsalgoritmen.

I motsetning til køer med teamoppdrag, er det ikke noe konsept for målutvidelse over tidsintervaller.Hvis ingen av de konfigurerte agentene er tilgjengelige for å rute denne kontakten, blir den parkert i kø til en av disse agentene blir tilgjengelig for å håndtere kontakter før tidsavbruddet på parkeringen.Målutvidelse gjelder ikke for disse køene.

Tilgjengelige rutingsmønstre:

Longest available
Circular
Linear/Top-down

Ferdighetsbaserte køer

Ferdighetsbaserte køer gir mulighet for at kontakter kan rutes til agenter med de riktige ferdighetene for å møte deres behov.

Du kan konfigurere følgende typer ferdighetsbaserte alternativer:

Skill criteria assigned to queue
Skill requirements assigned in flow

Kompetansekriterier tilordnet til kø

Administratorer kan tilordne kompetansekriterier til køer.Ferdighetsbaserte køer med ferdighetskriterier gjør det mulig for administratorer å konfigurere nødvendige ferdigheter direkte i køen.Alle agenter i organisasjonen som har alle nødvendige ferdigheter i køen via direkte kompetanseprofil, blir implicit en del av denne køen.

Dette oppsettet hjelper administratorer med å få en direkte oversikt over agenter som tilordner køen i kraft av ferdigheter.I situasjoner som høyt volum eller lavt volum kan administratorer vurdere å justere de nødvendige ferdigheter i køen og agentens kompetanseprofiler for å utvide eller redusere agentgruppen etter behov.

Denne typen kø er forskjellig fra teamoppgavebaserte køer i den forstand at det ikke finnes noen innstilling for samtaledistribusjonsgruppe, noe som betyr at teamet ikke spiller noen rolle i tilknytning til agent til kø.I tillegg er de nødvendige ferdighetene statisk konfigurert i denne køen i motsetning til teambaserte ferdighetskøer der flyten tilfører de nødvendige ferdighetene (statisk eller variabel).Derfor er ferdighetene teknisk sett en del av køen i stedet for selve kontakten.

Alle agenter i organisasjonen som oppfyller ferdighetskriteriene i køen (som har ferdigheter fra direkte ferdighetsprofil), blir indirekte knyttet til denne køen.Teamet spiller ingen rolle i agenttilknytning til disse køene.Disse agentene kan være en del av et hvilket som helst team for ledelses- og driftsformål.

Hver kontakt som settes i kø i denne køen, vil automatisk anta ferdighetskriteriene som er definert i selve køen.Individuelle kontakter kan ikke definere eller overstyre sine egne kompetansekrav/kriterier i motsetning til ferdighetsbaserte køer med teamtilordning.

｟_ph_1｠

I dette eksemplet:

Bare agenter A1, A3 og A7 oppfyller ferdighetskriteriene som er konfigurert i køen. Derfor vil bare disse agentene være knyttet til denne køen.
Agenter A2, A4 og A6 som delvis oppfyller kriteriene eller A5 som mangler relevante ferdigheter, kan ikke knyttes til denne køen.

Ved å oppdatere ferdighetsprofilen til en agent (kalt reskilling) slik at den oppfyller ferdighetskriteriene i køen, blir agenten automatisk og dynamisk en del av denne køen.Hvis du oppdaterer selve køferdighetskriteriene slik at flere (eller færre) agenter oppfyller de oppdaterte ferdighetskriteriene, vil du også automatisk og dynamisk legge til (eller fjerne) agenter fra denne køen.

I motsetning til køer med teamoppdrag, er det ikke noe konsept for målutvidelse over tidsintervaller.Hvis kontakten ikke kan matches med noen av de tilknyttede agentene, blir den parkert i kø til en av disse agentene blir tilgjengelig for å håndtere kontakter før parkeringsavbrudd.

Ferdighetsbaserte køer er best egnet der statisk tilordning av ferdigheter og administrasjon av kø til agenttilknytning er mulig og ønskelig for operativ kontroll.De er også egnet når valget av rutingsalgoritmer er egnet for arbeidsdistribusjon mellom agenter.Disse køene er også spesielt nyttige for scenarier der ulike typer kundehenvendelser krever spesifikke ferdigheter som kan betjenes av et forhåndsutledet segment av ekspertagenter.

Komplekse Contact Center-organisasjoner kan finne det enklere å administrere kø til agenttilordninger i ferdighetsbaserte køer, sammenlignet med køer med agenttilordning der hver agent må legges til i listen manuelt, noe som er vanskelig spesielt for en større organisasjon.

Kompetansekrav tilordnet i flyt

Kompetansebaserte køer med kompetansekrav tilordnet i flyt er en type teamtilordningsbasert kø i Webex Contact Center der et sett med team konfigureres på flere nivåer, kalt samtaledistribusjonsgrupper.Agenter som er logget på disse konfigurerte teamene, tilordnes kontakter fra denne køen basert på samtaledistribusjonsgruppenivå der teamet deres er konfigurert i køen, hvis de også oppfyller ferdighetskravene til kontakten.

I en slik kø grupperes agentteam i samtaledistribusjonsgrupper med konfigurerbare tidsforsinkelser mellom dem.Hvis ingen agent er tilgjengelig for kontakten, parkeres forespørselen, og etter forsinkelsen utvides ruting til neste samtaledistribusjonsgruppe.Denne prosessen fortsetter til en agent er tilordnet eller alle grupper er oppbrukt.I mellomtiden, hvis en agent i en tidligere kontrollert gruppe blir tilgjengelig under denne prosessen, velges denne agenten.

Agenter tilegner seg ferdigheter via ferdighetsprofil som er direkte tilordnet agenten.Agentens ferdigheter bestemmes basert på teamvalg under pålogging.

Hver kontakt kan eventuelt angi kompetansekrav i flyten, som samsvarer med ferdighetene til tilgjengelige agenter for å velge den mest passende agenten.

I tillegg kan kontakter også angi kompetanseavslapninger ved konfigurerte tidsintervaller.Disse er endrede sett med kompetansekrav som ville overskrive kontaktens opprinnelige kompetansekrav ved konfigurerte tidsintervaller.Dette gjør det mulig for en kontakt å endre (vanligvis brukes til å "slappe av") sine kompetansekrav mens de er parkert i kø, slik at flere agenter kan samsvare med disse avslappet kompetansekravene.

Målutvidelse gjennom samtaledistribusjonsgrupper kan skje samtidig med kompetanseavslapningssykluser – begge rettet mot å samsvare en parkert kontakt med kvalifiserte agenter raskere, og dermed redusere den totale ventetiden og forbedre servicenivået i køen.

｟_ph_1｠

I likhet med ufaglærte køer med teamtilordning, har den tre samtaledistribusjonsgrupper som tillater "målutvidelse", dvs. utvidelse til flere agenter på tvers av team over konfigurerte tidsintervaller.

Den første samtaledistribusjonsgruppen inneholder TEAM 1, som har 3 agenter konfigurert – A1, A2 og A5.
Den andre samtaledistribusjonsgruppen inneholder TEAM 2, som har 3 agenter konfigurert – A2, A3 og A4.
Den tredje (og siste) samtaledistribusjonsgruppen inneholder TEAM 3, som har 2 agenter konfigurert – A6 og A7.

Det er imidlertid to ting å merke seg:

Hver kontakt som blir satt i kø, vil definere sine kompetansekrav og kompetanseavslapning gjennom flyten.
Agenter kan ha ferdighetene konfigurert (gjennom en ferdighetsprofil – direkte eller arvet fra det påloggede teamet).

Selv om A2 er konfigurert til å være en del av både TEAM 1 og TEAM 2, avhengig av valget av team denne agenten har gjort under pålogging, anses han i sin nåværende økt som en del av dette teamet, og vil derfor også arve ferdighetsprofilen (og dermed ferdighetsverdiene) fra dette teamet (med mindre dette overstyres med en direkte ferdighetsprofil for denne agenten).

Dette er en kraftig funksjon levert av køer med teamoppgaver der agenter kan flytte mellom køer bare ved å velge et team under pålogging.

Sammen med muligheten til å arve kompetanseprofilinnstillinger fra det valgte teamet, kan en agent også arbeide med forskjellige sett med ferdigheter.

I dette eksemplet:

Kontakter settes i kø med et opprinnelig kompetansekrav (sk_1 >= 6) under eskalering fra flyt, med en kompetanseavslapning (sk_1 >= 3) etter et konfigurert tidsintervall.
På tvers av alle agenter i alle samtaledistribusjonsgrupper, bare A1, A3, A6 og A7 har ferdigheter som oppfyller det opprinnelige ferdighetskravet til kontakter i kø.
De gjenværende agentene har enten ferdigheten (sk_1), men oppfyller ikke ferdighetskravene (f.eks. A2 i TEAM 1 og A4 i TEAM 2), eller har ikke denne ferdigheten i det hele tatt (f.eks. A5, A2 i TEAM 2).
Over tid, etter kompetanseavslapning, i tillegg A2 og A4 også nå tilfredsstille kontaktens "avslappet" kompetansekrav.

For hver kontakt som settes i kø, prøver systemet å finne en samsvarende agent i den første samtaledistribusjonsgruppen som oppfyller kontaktens gjeldende kompetansekrav.Hvis ingen samsvarende agent blir funnet, parkeres kontakten i den konfigurerte varigheten før målutvidelsen skjer til den andre samtaledistribusjonsgruppen.Alle teamene som er konfigurert i den andre samtaledistribusjonsgruppen, legges også til eksisterende team fra den første gruppen.Nå prøver systemet å finne en samsvarende agent i den utvidede gruppen.Vær oppmerksom på at mens dette skjer, vil kompetanseavslapning også oppdatere kompetansekravene til kontakten ved konfigurerte tidsintervaller, og systemet vil bruke oppdaterte kompetansekrav til å samsvare med tilgjengelige agenter i gjeldende samtaledistribusjonsgruppe.

Dette fortsetter inntil alle konfigurerte samtaledistribusjonsgrupper utvides og alle kompetanseavslapninger brukes, med mindre det finnes en samsvarende agent før.

Tilgjengelige rutingsmønstre:

Longest available
Best available

Køkonfigurasjon

Konfigurer ferdighetsbaserte køer

Tilordne ferdighetskriterier til en kø

Opprette ferdigheter og, om nødvendig, dynamiske ferdigheter.
Create Skill Profiles.
Tilordne kompetanseprofil direkte til agenter.
Tilordne dynamiske ferdigheter direkte til agenter.Dynamiske ferdigheter tilordnes ikke gjennom kompetanseprofiler.
Opprett kø med kanaltypen telefoni, chat, e-post eller sosial.
Tilordne ferdigheter og krav til dynamiske ferdigheter til køer i Control Hub.
Vis liste over agenter som kan håndtere kontakter i køen.
Velg en rutingalgoritme enten LAA eller BAA.For BAA konfigurerer du vekter for kompetanseferdigheter og kompetansedynamiske ferdigheter når det er nødvendig.
Legg til en køkontaktaktivitet i flyten, og velg denne køen.

Tilordne kompetansekrav til en kø

Opprette ferdigheter og, om nødvendig, dynamiske ferdigheter.
Create Skill Profiles.
Tilordne kompetanseprofil til agenter direkte eller team.
Tilordne dynamiske ferdigheter direkte til agenter.Dynamiske ferdigheter tilordnes ikke gjennom kompetanseprofiler.
Create a Team.
Legg til agenter i teamet.
Opprett kø med kanaltypen telefoni, chat, e-post eller sosial.
Legg team til køen i én enkelt CDG eller flere CDG-er.
Velg et rutingsmønster enten LAA eller BAA.
Legg til en køkontaktaktivitet i flyten, og velg køen som kompetansebasert ruting er konfigurert for. For more information, see Queue Contact.
Tilordne ferdigheter, dynamiske ferdigheter og kompetanseavslapning i kø-kontaktaktivitet.For BAA konfigurerer du vekter for kompetanseferdigheter og kompetansedynamiske ferdigheter når det er nødvendig.
Bruk Eskalere samtaledistribusjonsaktivitet i flyten etter kø for raskt å gå til neste eller siste samtaledistribusjonsgruppe.

Konfigurer ikke-ferdighetsbaserte køer

Tilordne team til en kø

Create a Team.
Legg til agenter i teamet.
Opprett kø med kanaltypen telefoni, chat, e-post eller sosial.
Legg team til køen i én enkelt CDG eller flere CDG-er.
Velg et rutingsmønster enten LAA.
Legg til en køkontaktaktivitet i flyten, og velg denne køen.
Bruk Eskalere samtaledistribusjonsaktivitet i flyten etter kø for raskt å gå til neste eller siste samtaledistribusjonsgruppe.

Tilordne agent til en køflyt

Opprett kø med kanaltypen telefoni, chat, e-post eller sosial.
Legg til agenter direkte i køer (Merk:Verken Ferdigheter eller team brukes i denne typen kø).
Velg rutingsmønstre, for eksempel Sirkulær eller Lineær agent eller Lengst tilgjengelig agent.

Ruting

Rutingskonsepter

Agentoverskudsscenario

Agent Surplus-scenario oppstår når det er flere tilgjengelige agenter enn det er kontakter i kø. I dette tilfellet, når en kundesamhandling (kontakt) er i kø, prøver systemet å finne en samsvarende agent for denne bestemte kontakten umiddelbart, og hvis en samsvarende agent blir funnet, trenger ikke kontakten parkeres i kø og venter på at en samsvarende agent blir tilgjengelig senere.

Hver gang en kontakt utvides gjennom en samtaledistribusjonsgruppe, eller gjennom kompetanseavslapning, prøver systemet igjen umiddelbart å finne en samsvarende agent for denne bestemte kontakten.

Hvis du finner en samsvarende agent for en bestemt kontakt, bruker du det konfigurerte rutingsmønsteret i køen.

Webex Contact Center tilbyr flere rutingsmønstre på tvers av forskjellige typer køer, som gjør det mulig for organisasjoner å optimalisere kundeservice ved å minimere ventetider, balansere agentarbeidsbelastningen og sikre at kundene er koblet til agenter som har de nødvendige ferdighetene til å møte sine spesifikke behov. Se delen Rutingsmønster for detaljert informasjon om rutingsmønstre.

Scenario for kontaktoverskudd

Kontaktoverløpsruting skjer når antallet innkommende kundeinteraksjoner (eller kontakter) overskrider de tilgjengelige agentene. Denne situasjonen oppstår ofte under peak-tider eller uventede overganger i kontaktvolum. Hovedmålet med ruting av kontaktoverløp er å administrere denne overflyten effektivt, og sikre at kundeservicenivåene opprettholdes til tross for overskudd. For en agent som nettopp har blitt tilgjengelig på en bestemt kanal, fungerer kontaktoverløpsruting for å finne og tilordne riktig kontakt, blant alle parkerte kontakter på tvers av alle køer som denne agenten er tilknyttet.

De viktigste strategiene for å utføre kontaktruting effektivt med begrenset agenttilgjengelighet er:

Kørangering
Kørangering gjør det mulig for administratorer å angi den relative viktigheten av køer. Administratorer kan definere kørangeringer for å angi rekkefølgen samtaler rutes fra køer til agenter som er logget inn i team, per team.
Vurder for eksempel at agenter som er logget på team A, er knyttet til to køer – «Fakturering» og «Salg». Administratorer kan bruke kørangering til å tilordne en høyere rangering til "Fakturering"-køen, så når kontakter kommer inn i køene, blir kontakter fra "Fakturering" rutet til agenter som tilhører team A i forkant av kontakter fra "Salg"-køer. Dette vil skje selv om det kan være eldre kontakter med høyere prioritet som kan vente i "Salg"-køen - bare fordi "Fakturering"-køen har en høyere kø enn "Salg"-køen. Bare når det ikke er flere ventende kontakter i "Fakturering"-køen, vil agenter fra team A bli rutet kontakter fra "Salg" (og enhver annen) kø de er tilknyttet.
Følgende er noen av de viktigste egenskapene ved kørangering:
- - Hvis en rangering bare tilordnes til noen av køene, vil anrop i disse køene prioriteres fremfor anrop i køene som ingen rangering er angitt for.
  - Kørangering kan angis på maksimalt 50 køer på tvers av alle medietyper med en verdi mellom 1 og 50 med 1 som høyeste rangering.
  - Du kan tilordne samme rangering til flere køer.
  - Hvis du aktiverer kø-rangering, behandles køer som ikke er tilordnet en eksplisitt rangering, lavere enn alle rangerte køer.
  - Kørangering fungerer innenfor samme medietype.
    
    Hvis for eksempel Køsalg er en taletype med rangering 2 og Køfaktureringsstøtte er en chatkø med rangering 1 for team A, får agenter som er tilgjengelige på talekanal i team A taleanrop først selv om rangeringen er 2.
    
    Vurder imidlertid to chattekøer for team B – kredittkort i kø med kørangering 2 og debetkort i kø med kørangering 1. Deretter vil de tilgjengelige agentene i team B bli tilbudt kontakter fra Kø-debetkort først.
  - Kørangering gjelder ikke for kapasitetsbaserte team.
Kontaktprioritet
Når en kontakt står i kø, kan prioriteten defineres ved å tilordne en hierarkisk viktighet fra 1 (høyeste) til 10 (laveste, standard). Denne prioriteringen sikrer at enkelte kontakter blir håndtert raskere basert på hvor viktig, haster eller strategisk verdi de har for organisasjonen. Når en agent er tilgjengelig for å håndtere neste kontakt blant alle parkerte kontakter på tvers av alle køer som agenten er knyttet til, rutes kontakten med høyest prioritet på tvers av alle køer til agenten (forutsatt at andre kriterier som kompetansesamsvar og andre er oppfylt).
For kontakter som står i kø uten eksplisitt prioritet, vurderes en standardprioritet på 10 (lavest). Blant flere kontakter med samme prioritet, blir kontakten som venter i køen for lengst varighet, først rutet til den tilgjengelige og kvalifiserte agenten.
Lengst ventende kontakt
Dette er en grunnleggende strategi som sikrer at den lengste ventende kontakten på tvers av alle køene som agenten er tilknyttet, blir rutet til agenten.
Dette er det endelige kriteriet som bestemmer at kontakten skal rutes når flere kontakter på tvers av køer med samme kørangering og samme kontaktprioritet venter på å bli behandlet.

I utgangspunktet betyr kontaktoverskuddsruting for en agent som nettopp ble tilgjengelig å velge én enkelt kontakt som:

er av samme medietype som agenten er tilgjengelig på
er parkert i en av køene som denne agenten er tilknyttet
hvis kompetansekrav (hvis noen) er oppfylt av denne agenten
er parkert i en kø med rangering høyere enn andre køer som er konfigurert i agentens team
har høyest prioritet blant alle slike kontakter
er den eldste ventende kontakten blant kontakter med samme prioritet

I eksemplet ovenfor, som illustrerer et kontaktoverskuddsscenario, har agent A1 logget på TEAM 1 og blitt tilgjengelig for å håndtere kontakter på flere medietyper.

A1 er knyttet til 3 køer – Q1, Q2 og Q3. TEAM 1 har også definert kørangering der Q1 er rangert høyest, deretter Q2 og Q3.

Det er allerede parkerte kontakter i alle disse køene, med kompetansekrav og prioritet definert for hver kontakt.

Nå fungerer scenarioet for kontaktoverskudd som følger:

Blant alle parkerte kontakter på tvers av disse køene, kan bare 4 kontakter rutes til A1 – C2, C7 (fra KØ 2) og C3, C8 (fra KØ 3).

Bare kompetansekravene til disse 4 kontaktene er fullstendig oppfylt av ferdighetene til A1.
Blant disse 4 kontaktene prioriteres kontakter fra KØ 2 (dvs. C2, C7) fordi KØ 2 har den høyeste kørangeringen.

Vær oppmerksom på at selv om KØ 1 er den høyest rangerte køen, kan ingen av de parkerte kontaktene rutes til A1 siden ferdighetskravene ikke oppfylles av A1.
Mellom C2 og C7 er kontakten med høyest prioritet C7. Så det endelige valget er C7, og systemet ruter det til A1.

Dette skjer selv om C2 var i kø tidligere, fordi kontaktprioritet har forrang over tid i kø.

Blandede multimedieprofiler

Webex Contact Center gjør det mulig for agenter å betjene kontakter på tvers av forskjellige medietyper (tale, chat, e-post og sosial). Basert på denne konfigurasjonen får agenter kanaler klargjort per medietype.

Hver kontakt som rutes til en agent, bruker én kanal av denne medietypen så lenge agenten arbeider med den kontakten. Selv om agenter bare kan ha én talekanal, kan de ha opptil fem kanaler av andre medietyper.

Innstillingen for blandet ruting i Multimedieprofiler gjør det mulig for administratorer å kontrollere hvordan ulike kanaler kan brukes samtidig for hver agent. Dette gjør det mulig for organisasjoner å gi dedikert oppmerksomhet til kundene, fremme bedre kvalitet på tjenesten, forbedret kundeopplevelse og bedre konverteringsrater. Organisasjoner kan også balansere belastningen på tvers av mediekanaler når de opplever ujevn belastning i noen kanaler, noe som muliggjør effektiv utnyttelse av agenter.

Det er tre valg:

Uten
Blandet
Blandet sanntid

Når agenter håndterer en kontakt som ikke er tale, kan de starte et manuelt utgående taleanrop fra Agent Desktop, så lenge de har en talekanal tilgjengelig. Dette gjelder for alle multimedieprofiltyper.

Hvis du vil ha mer informasjon om hvordan du konfigurerer multimedieprofiler, kan du se Administrer multimedieprofiler.

Rutingsmønstre

Ferdighetsbasert

Ferdighetsbaserte rutingsmønstre i Webex Contact Center sender innkommende kundesamhandlinger til agenter basert på spesifikke ferdigheter som kreves for å løse forespørselen, for eksempel språkkunskaper eller teknisk kompetanse. Disse mønstrene sikrer at hver kunde kobler seg til den mest kvalifiserte agenten, noe som forbedrer tjenesteeffektiviteten og kundetilfredsheten. Fordelene inkluderer redusert behandlingstid, forbedret oppløsningshastighet og optimalisert bruk av agentressurser ved å tilpasse ekspertisen til kundens behov.

Ferdighetsbasert ruting kan bruke ferdigheter som agenter mottar fra ferdighetsprofiler og dynamiske ferdigheter som er tilordnet direkte til agenter. Dynamiske ferdigheter representerer agentattributter som kan endres uavhengig av en agents kompetanseprofil.

Når ferdighetsbaserte rutingsmønstre brukes, brukes først ferdighetskravet til kontakten (tilordnet i flyt) eller ferdighetskriteriene tilordnet til kø til å filtrere tilgjengelige agenter hvis ferdigheter og dynamiske ferdigheter helt oppfyller disse kravene/kriteriene. Deretter, blant agenter som filtreres, velges én enkelt for kontakten basert på rutingsmønsteret som er konfigurert.

For Best Tilgjengelig ruting kan kompetanseferdigheter og kompetansedynamiske ferdigheter også bruke vekter til å påvirke poengsummen som brukes til agentvalg. Vekter påvirker ikke Lengst Tilgjengelig ruting; at mønsteret bruker ferdigheter og dynamiske ferdigheter bare for å fastslå agentens kvalifisering.

Lengst tilgjengelig

Det Lengst tilgjengelige ferdighetsbaserte rutingsmønsteret ruter en kontakt til agenten hvis ferdigheter oppfyller kravene til kontaktferdigheter/kriterier for køen helt, og som har vært tilgjengelig lengst siden håndtering av sin siste kontakt blant alle kvalifiserte agenter i den køen.

Dette rutingsmønsteret bidrar til å fordele arbeidet jevnt på tvers av agenter ved å tilordne interaksjoner til de som har vært tilgjengelige lengst, og forhindre ubalanse i arbeidsbelastningen. Det bidrar til å opprettholde rettferdighet i arbeidsdistribusjonen, slik at ingen agenter blir overbelastet mens andre forblir frie.

I eksemplet ovenfor finnes det 4 agenter som har kompetanse og ikke-kompetanse med ulike kompetanseverdier.

Vurder en kontakt som står i kø i en ferdighetsbasert kø som har rutingsmønsteret «Lengst tilgjengelig»:

med ovennevnte kompetansekrav tilordnet via flyt, eller
med ferdighetskriteriene ovenfor konfigurert i den ferdighetsbaserte køen

I dette scenariet:

Bare agenter som fullt ut oppfyller kravene til kontaktferdigheter/kriterier for kø vurderes for ruting. Bare agentene A1, A2 og A4 oppfyller kravene til kontaktferdigheter/kriterier for køkompetanse.

Agent A3 er ikke kvalifisert. I tilfelle Kompetansekriterier tilordnet til kø, er A3 ikke engang knyttet til køen.
Blant A1, A2 og A4 blir kontakten rutet til den lengst tilgjengelige agenten – A1 som har vært tilgjengelig i 10 minutter, lengre enn A2 eller A4.

I kraft av at A1 blir tildelt kontakten, vil A1 ikke lenger være den lengste tilgjengelige agenten på tvers av alle mediekanaler.
Neste kontakt med nøyaktig samme kompetansekrav vil bli rutet til den nest lengste tilgjengelige agenten – A2, og så videre.

Dette rutingsmønsteret støttes i følgende typer ferdighetsbaserte køer:

Kompetansekrav tilordnet i flyt
Kompetansekriterier tilordnet til kø

Best tilgjengelig

Det beste tilgjengelige ferdighetsbaserte rutingsmønsteret sikrer at kundesamhandlinger rettes mot den mest kvalifiserte agenten som er tilgjengelig. Dette mønsteret evaluerer ikke bare tilstedeværelsen av nødvendige ferdigheter blant agenter, men også ferdighetsnivået til disse ferdighetene, og beregner en ferdighetsscore for å fastslå den mest kvalifiserte ("beste") agenten for hver kontakt.

Dette mønsteret filtrerer tilgjengelige agenter med ferdigheter som oppfyller kravene til kontaktferdigheter / kriterier for køen helt. Deretter beregnes en poengsum for hver kvalifisert agent ved hjelp av kompetanseverdier for alle ferdigheter som er nevnt i krav til kontaktferdigheter/kriterier for køen. Agenten med høyest kompetansepoeng regnes som den "beste" agenten for hver kontakt.

Summen av kompetanseverdiene til agenten som samsvarer med kravene til kontaktkompetansekriteriene / køkompetansekriteriene bestemmer poengsummen.

Noen viktige punkter å forstå:

Vanligvis brukes den faktiske ferdighetsverdien i poengberegningen, fordi en høyere ferdighetsverdi indikerer en sterkere match. Bortsett fra når et ferdighetskrav bruker betingelsen mindre enn lik (<=), inverteres den spesifikke ferdighetsverdien til agenten i poengberegningen, dvs. effective_skill_value = (10) minus (actual_skill_value). Dette gjøres for å sikre at en lavere poengsum indikerer en sterkere match.
Når flere kvalifiserte agenter har samme poengsum, velges den lengste tilgjengelige agenten blant dem
Kun ferdigheter vurderes ved beregning av poengsum. Eventuelle boolske, tekst- eller enum-ferdigheter i kontaktferdighetskravene/kriteriene for kø vurderes ikke for beregning av poengsum.

I eksemplet ovenfor er det fire agenter som har kompetanse og ikke-kompetanse med ulike kompetanseverdier.

Vurder at en kontakt som står i kø i en ferdighetsbasert kø har rutingsmønsteret «Best tilgjengelig»:

med ovennevnte kompetansekrav tilordnet via flyt, eller
med ferdighetskriteriene ovenfor konfigurert i den ferdighetsbaserte køen.

I dette scenariet:

Bare agenter som fullt ut oppfyller kravene til kontaktferdigheter/kriterier for kø vurderes for ruting. Bare agentene A1, A2 og A4 oppfyller kravene til kontaktferdigheter/kriterier for køkompetanse.

Agent A3 er ikke kvalifisert. I tilfelle Kompetansekriterier tilordnet til kø, er A3 ikke engang knyttet til køen.
Blant A1, A2 og A4 utføres poengberegningen av systemet basert på krav til kontaktferdigheter / kriterier for køkompetanse, der bare kompetanse vurderes.

Bare de ferdighetene som er nevnt i kravene til kontaktferdigheter / kriterier for køen vurderes for beregning av poengsum, selv om agenter kan ha ytterligere / andre ferdigheter.

Legg også merke til at ferdighetsverdien er reversert i poengberegningen når tilstanden er mindre enn lik (<=) brukes.
Kontakten rutes til A2 da dette er den beste tilgjengelige agenten basert på poengsummen. Hvis A2 ikke er tilgjengelig / opptatt, vil kontakten bli rutet til den nest beste tilgjengelige agenten med nest høyeste poengsum, osv.

Vi har imidlertid 2 agenter – A1 og A4 med nest høyeste poengsum. Kontakten rutes til den lengst tilgjengelige agenten mellom A1 og A4.

Dette rutingsmønsteret støttes i følgende typer ferdighetsbaserte køer:

Kompetansekrav tilordnet i flyt
Kompetansekriterier tilordnet til kø

Ikke-ferdighetsbasert ruting

Webex Contact Center støtter også en rekke ikke-ferdighetsbaserte rutingsmønstre som fokuserer på å distribuere innkommende kundesamhandlinger uten å vurdere agentenes spesifikke ferdigheter eller ekspertise. I motsetning til ferdighetsbaserte rutingsmønstre tar disse ikke hensyn til agentferdigheter eller krever at kontakten eller køen definerer kompetansekrav/kriterier for ruting. I stedet prioriterer de faktorer som tilgjengelighet, arbeidsbelastningsdistribusjon og forhåndsdefinerte sekvenser, slik at kontakter kan håndteres effektivt basert på driftslogikk i stedet for individuelle agentkompetanser. Disse mønstrene er spesielt nyttige i miljøer der interaksjonene er relativt ensartede eller ikke krever spesialisert håndtering.

Lengst tilgjengelig

Det lengste tilgjengelige rutingsmønsteret ruter en kontakt til agenten i køen som har vært tilgjengelig lengst siden håndtering av den siste kontakten på tvers av alle agenter som er tilgjengelige og tilknyttet den køen.

Dette rutingsmønsteret sikrer en rettferdig og balansert fordeling av arbeidsbelastningen ved å tilordne interaksjoner til agenter som har vært inaktive lengst. Ved å forhindre ubalanse i arbeidsbelastningen sikrer det at ingen agenter blir overbelastet mens andre forblir frie. Denne tilnærmingen er spesielt effektiv i perioder med jevn kontaktflyt, og opprettholder konsekvent engasjement på tvers av agentgruppen.

Agenter mister sine «lengst tilgjengelige» stillinger på tvers av alle kanaler når de får tilbudt en kontakt av enhver medietype. Dette betyr at etter at en agent håndterer en kontakt, vil neste kontakt av en medietype som er i kø, tilordnes til den nest lengste tilgjengelige agenten i den køen.

I eksemplet ovenfor er agenten A1 den lengste tilgjengelige agenten (posisjon 1) – enten er agenten logget på først eller har ikke blitt tilordnet en kontakt lenger enn noen annen agent.

Agentene A2 (posisjon 2) og A3 (posisjon 3) er også tilgjengelige, men de har enten logget på eller behandlet kontakter etter A1. Alle agenter er knyttet til begge køene som har dette rutingsmønsteret.

Vurder følgende scenario:

På tidspunktet T0 står en talekontakt C1 i kø og rutes til den lengste tilgjengelige agenten, dvs. A1.

I kraft av at A1 blir tildelt C1, er A1 ikke lenger den lengste tilgjengelige agenten på tvers av alle mediekanaler.
På tidspunktet T1 står en chatkontakt C2 i kø og rutes til den lengste tilgjengelige agenten, som nå er A2.
Til slutt, på tid {1>T2<1}, en annen talekontakt {3>C3<3} er i kø og rutet til {5>A3<5}.

A1 og A2 fikk nylig kontakter – på dette tidspunktet er det A3 som har ventet lengst.

På grunn av den svært distribuerte arkitekturen til Webex Contact Center, er det en liten mulighet for at en enkelt agent som har lengst tilgjengelig kan rutes flere kontakter når disse kontaktene står i kø til samme kø samtidig.

Dette rutingsmønsteret støttes i følgende typer ikke-ferdighetsbaserte køer:

Teamoppgave
Agenttilordning

Sirkulær

Sirkulær rutingsmønster distribuerer innkommende kontakter mellom en gruppe tilgjengelige agenter i en round-robin-rekkefølge. Når en kontakt er i kø, tilordner systemet den til neste tilgjengelige agent i køen basert på en forhåndsbestemt sekvens.

Prosessen starter med agenter i en konfigurert rekkefølge. Den første innkommende kontakten tilordnes til den første tilgjengelige agenten i denne rekkefølgen. For etterfølgende kontakter velger systemet neste tilgjengelige agent, og fortsetter fra der den sluttet i den definerte kørekkefølgen. Dette mønsteret gjentas, sykler gjennom agentene, men starter alltid etter den siste valgte agentens posisjon.

Denne tilnærmingen er effektiv for å fordele kontakter jevnt og jevnt mellom agentene. Det bidrar til å sikre at ingen enkelt agent er overveldet av kontakter, og at alle agenter har like muligheter til å håndtere samhandlinger konsekvent. Sirkulær rutingsmønster tar imidlertid ikke hensyn til gjeldende arbeidsbelastning eller andre faktorer som kan påvirke en agents evne til å håndtere en bestemt kontakt.

I eksemplet ovenfor konfigureres agenter i en sirkulær kø i følgende rekkefølge: A3 → A4 → A5 → A6 → A1 → A2.

Til å begynne med er startposisjonen den første agenten i den konfigurerte rekkefølgen (A3). Etter hvert som kontakter rutes til agenter i denne køen, flyttes posisjonen rundt sirkelen, plassert til agenten som er neste i konfigurert rekkefølge til agenten som siste kontakt ble rutet til.

Vurder følgende scenario:

Den første kontakten (C1) er i kø, og den rutes til agent A3.

Pekeren oppdateres til neste agent i konfigurert rekkefølge, dvs. A4.
Når den andre kontakten (C2) er i kø, begynner systemet å finne tilgjengelige agenter fra A4, dvs. A4 → A5 → A6 → A1 → A2 → A3.

A4 og A5 er imidlertid utilgjengelige (enten er de ikke engang logget på, eller de er inaktive eller fullt opptatt med andre kontakter av denne medietypen), så C2 blir rutet til neste tilgjengelige agent – A6. Pekeren oppdateres til neste agent i konfigurert rekkefølge, dvs. A1.
På samme måte blir den tredje kontakten (C3) rutet til A1, den fjerde kontakten (C4) rutet til A2. Pekeren er på A3 igjen.

Denne logikken fortsetter, og kontakter distribueres mellom tilgjengelige agenter i "sirkulære" / "runde-robin"-mønsteret.

Hvis det er parkerte kontakter i kø, vil agentoverskuddsscenariet samsvare med neste agent som blir tilgjengelig på denne medietypen med den høyest prioriterte, eldste kontakten blant dem.

Dette tar ikke hensyn til eller påvirker ikke den eksisterende posisjonsverdien i denne køen, som bare oppdateres når kontaktoverskuddsruting samsvarer med en agent.

Dette rutingsmønsteret støttes i følgende typer ikke-ferdighetsbaserte køer:

Agenttilordning

Ovenfra og ned

Rutingsmønsteret ovenfra og ned distribuerer innkommende kontakter mellom en gruppe tilgjengelige og bestilte agenter i en sekvensiell rekkefølge. Når en kontakt står i kø, går systemet alltid gjennom listen over agenter fra begynnelsen og samsvarer kontakten med den første tilgjengelige agenten (som har en gratis tilgjengelig kanal av kontaktens medietype) i den rekkefølgen.

Dette skjer for hver kontakt som står i kø. Kontakten forsøkes alltid å matche fra toppen (først konfigurert agent) og deretter nedover listen til en matchende agent blir funnet.

I motsetning til sirkulært rutingsmønster, er det ingen "peker" som dynamisk endrer startpunktet basert på den siste valgte agentens posisjon.

Denne fremgangsmåten er effektiv for å distribuere kontakter mellom agenter som er bestilt basert på en viss bias/preferanser som bestemt av administratoren. Det bidrar til å sikre at agentene øverst alltid foretrekkes å håndtere kontakter over agenter under dem. Rutingsmønsteret ovenfra og ned tar imidlertid ikke hensyn til gjeldende arbeidsbelastning eller andre faktorer som kan påvirke en agents evne til å håndtere en bestemt kontakt.

I eksemplet ovenfor konfigureres agenter i en kø ovenfra og ned i følgende rekkefølge: A3 → A4 → A5 → A6 → A1 → A2.

Dette betyr at administratoren vil at hver kontakt skal rutes til den første agenten (A3) hvis tilgjengelig, ellers neste agent (A4) hvis tilgjengelig og så videre, i konfigurert rekkefølge.

Vurder følgende scenario:

Den første kontakten (C1) er i kø, og den rutes til agent A3, siden A3 er øverst i bestillingen.
Når den andre kontakten (C2) er i kø, forsøkes ruting igjen fra toppen av bestillingen (starter alltid med A3).

Hvis A3 har mer kanalkapasitet for denne medietypen, blir C2 også rutet til A3. Men hvis A3 er fullt opptatt med denne medietypen, fortsetter ruting ned på listen til A4.
A4 og A5 er imidlertid utilgjengelige (de er enten ikke engang logget på, inaktive eller fullt opptatt med andre kontakter av denne medietypen), så C2 blir rutet til neste tilgjengelige agent i den øverste rekkefølgen – A6.
På samme måte forsøkes den tredje kontakten (C3) å rutes fra A3 ned til bunnen. Den første samsvarende agenten ville være A1.

Denne logikken fortsetter, inntil en kontakt ikke finner noen tilgjengelige agenter før bunnen av rekkefølgen, i så fall er den parkert i kø.

Dette rutingsmønsteret støttes i følgende typer ikke-ferdighetsbaserte køer:

Agenttilordning

Agentbasert ruting

Agentbasert ruting er en funksjon som ruter eller kø en kontakt direkte til en bestemt ("foretrukket") agent. Et agentoppslag med agentens e-postadresse eller agentens ID ruter en kontakt til den foretrukne agenten. Aktiviteten Køen Til Agent i flyten bidrar til å oppnå Agentbasert Ruting. Hvis du vil ha mer informasjon, kan du se aktiviteten Kø til agent.

En kontakt kan ha en tilordning til én eller flere foretrukne agenter, som vanligvis kan administreres i et eksternt program utenfor Webex Contact Center. Det foretrukne agentoppslaget for en kontakt gjøres via aktiviteten HTTP-forespørsel, som henter tilordningen fra et eksternt program. Hvis du vil rute eller parkere kontakten med den foretrukne agenten, konfigurerer du aktiviteten Kø-til-agent ved hjelp av agentens Webex Contact Center-ID eller e-postadresse. Kontakten kan også parkeres mot en foretrukket agent hvis den foretrukne agenten ikke er umiddelbart tilgjengelig.

Agentbasert ruting er nyttig i følgende scenarier:

Ruting av foretrukket agent: Kunden kan tilordne kontakter til dedikerte agenter eller relasjonsledere. I slike scenarier ruter den agentbaserte ruting kontaktene direkte til den foretrukne agenten.
Siste agentruting: Når en kontakt ringer tilbake kontaktsenteret flere ganger for å samhandle med en agent, kan agentbasert ruting rute kontakten til den siste agenten som håndterte kontakten.

I begge brukstilfeller lagres kontaktdetaljene og agenttilordningen utenfor Webex Contact Center.

Køings- og rutingsfunksjoner i flyt

I Webex Contact Center kan et bredt spekter av ruting-, kø- og samtalekontrollfunksjoner organiseres gjennom flyter.

En rekke flyteaktiviteter og hendelseshåndterere som tilbys i flytdesigneren, kan plasseres i flyten for å effektivt administrere livssyklusen til innkommende og utgående kontakter.

Hvis du vil ha mer informasjon om hvordan du konfigurerer og bruker flyter, kan du se Bygg og administrer flyter med flytdesigner.

Aktiviteter i kø

Køkontakt

Køkontaktaktiviteten gir mulighet til å kø en kontakt inn i en aktiv innkommende kø fra organisasjonen, slik at den kan matches og rutes til riktig agent i den køen.

Følgende aspekter ved kø kan håndteres gjennom denne aktiviteten:

Priority - Tilordner en hierarkisk betydning fra 1 (høyest) til 10 (lavest, standard) til kontakten som står i kø.
Skill Requirements - Angi kompetansekriteriene som agenter i en ferdighetsbasert kø må oppfylle, for å bli betraktet som kvalifisert for ruting av kontakten.
Skill Relaxations - Justere, endre eller fjerne tidligere innstilte kompetansekrav etter en periode for å forbedre sjansene for å finne en agent.
Check Agent Availability - La systemet umiddelbart utvide gjennom alle samtaledistribusjonsgrupper der ingen tilgjengelige agenter blir funnet, for å unngå ventetid.

Se Ruting for mer informasjon om hvordan prioritet, kompetansekonfigurasjon og agenttilgjengelighet spiller en rolle i rutingskontakter.

Når køkontaktaktiviteten har satt kontakten i kø,

Hvis en samsvarende agent allerede er tilgjengelig, prøver systemet å rute kontakten til en agent.
Dette avbryter Main flow utførelse og ytterligere hendelser kan utløse de respektive Event Flows, hvis konfigurert.
Hvis ingen samsvarende agent blir funnet, blir kontakten parkert i køen og venter på at en samsvarende agent blir tilgjengelig.
Flytkjøringen fortsetter deretter med aktivitetene som er vedlagt etter kø kontakt-aktivitet, noe som gir mulighet til å:
- Spill av en forhåndskonfigurert musikk til kunden som venter i kø – ved å feste en PlayMusic aktivitet.
- Registrer en tilbakeringing basert på kundens forespørsel – ved å legge ved en Callback aktivitet.
- Ny kø, dvs. fjern kontakten fra gjeldende kø og legg til i en ny kø – ved å feste en ny Queue Contact eller Queue to Agent aktivitet.

Når en matchende agent blir tilgjengelig, prøver systemet å rute kontakten til agenten.

Når det lykkes, avbryter dette Main flow utførelse og ytterligere hendelser kan utløse de respektive Event Flows, hvis konfigurert.

Køkontaktaktiviteten fungerer når:

Kontakten er ikke tilordnet og klar til å bli rutet til en agent.
Køen, ferdighetene og andre flytkonfigurasjoner er riktig konfigurert.
Kontakten forblir innenfor den tillatte grensen på 25 inngangspunkt og køoverganger.
Kontakten forblir innenfor den tillatte grensen på 20 vellykkede rutingsforsøk.

Konfigurer feilhåndteringsbanen for å administrere kontakter som krever alternativ ruting eller ekstra håndtering på en elegant måte.

I slike tilfeller fører aktiviteten til en feil, og gjennomføringen av flyten flyttes til Error Handling bane.

Funksjoner som kompetansekrav, kompetanseavslapning og sjekk agenttilgjengelighet er bare tilgjengelige i køkontaktaktiviteten når køer med teamtilordning er valgt.

Hvis du vil ha mer informasjon om aktivitetsinnstillinger, bruks- og utdatavariabler, kan du se Bygg og administrer flyter > Køkontakt.

Kø til agent

Kø til agent-aktiviteten gir mulighet til å kø kontakten direkte til en foretrukket agent ved å slå opp deres unike agent-ID eller e-postadresse i Webex Contact Center.

Følgende aspekter ved kø kan håndteres gjennom denne aktiviteten:

Priority - Tilordne høyere/lavere viktighet til kontaktene som står i kø mot samme agent.
Reporting Queue - Identifisere køen som skal brukes til konfigurasjon, for eksempel opptak og standard musikk i kø, og rapportformål for kontakten.
Recovery Queue - Identifiser køen som skal brukes som reserve, når kontakten ikke kunne rutes til den angitte foretrukne agenten.

Når aktiviteten I Køen Til Agent har satt kontakten i kø,

Hvis agenten allerede er tilgjengelig, blir kontakten rutet til agenten.
Dette avbryter Main flow utførelse og ytterligere hendelser kan utløse de respektive Event Flows, hvis konfigurert.
Hvis agenten er tilgjengelig, men velger å avslå, ikke svarer eller ikke mottar kontakten, flyttes den inn i den angitte gjenopprettingskøen.
I gjenopprettingskøen vil kontakten bli rutet til den lengst tilgjengelige agenten, uten støtte for ferdigheter.
Hvis agenten er utilgjengelig og "Park Contact If Agent Unavailable" alternativet er selectedKontakten blir parkert og venter på at agenten skal være tilgjengelig.
Flytkjøringen fortsetter deretter med aktivitetene knyttet etter Kø Til agentaktivitet, noe som gir mulighet til å:
- Spill av en forhåndskonfigurert musikk til kunden som venter i kø – ved å feste en PlayMusic aktivitet.
- Callback aktivitet.
- Ny kø, dvs. fjern kontakten fra gjeldende kø og legg til i en ny kø – ved å feste en ny Queue to Agent eller Queue Contact aktivitet.
Når agenten blir tilgjengelig, prøver systemet å rute kontakten til agenten.
Dette avbryter Main flow utførelse og ytterligere hendelser kan utløse de respektive Event Flows, hvis konfigurert.
Hvis agenten er utilgjengelig og "Park Contact If Agent Unavailable" alternativet er not selectedKøen mislykkes.

Aktiviteten Køen Til Agent fungerer når:

Kontakten er ikke tilordnet og klar til å bli rutet til en agent.
Den foretrukne agent-ID-en eller e-postadressen er gyldig.
Rapporteringskøen og gjenopprettingskøen er riktig konfigurert.
Den foretrukne agenten er pålogget, tilgjengelig og klar til å håndtere kontakten.

Konfigurer en gjenopprettingskø for å sikre at kontakten rutes problemfritt når den foretrukne agenten ikke er tilgjengelig.

I slike tilfeller fører aktiviteten til en feil, og gjennomføringen av flyten flyttes til Error Handling bane.

Hvis du vil ha mer informasjon om aktivitetsinnstillinger, bruks- og utdatavariabler, kan du se Bygg og administrer flyter > Kø til agent.

Eskalere samtaledistribusjonsgruppe

Aktiviteten Eskalere samtaledistribusjonsgruppe støttes bare for queues with team assignment, og gir mulighet til å oppdatere Call Distribution Group for kontakten umiddelbart, i stedet for å vente på at den automatiske utvidelsesoppdateringen skal skje til neste gruppe etter den konfigurerte ventetiden. Dette gjør at kontakten raskt kan rutes til alle kvalifiserte agenter i køen.

Ved å bruke aktiviteten Eskalere anropsdistribusjonsgruppe, kan kontakten eskaleres til:

Next Group– Utvide settet av team til å inkludere dem som er lagt til i den umiddelbare neste samtaledistribusjonsgruppen.
Last Group– Utvider settet med team til å inkludere alle team som er kartlagt på tvers av alle samtaledistribusjonsgrupper som er konfigurert for køen.

Aktiviteten i gruppen Eskalere anropsdistribusjon fungerer når:

Kontakten er allerede i kø og klar for eskalering.
Kontakten står i kø i en kø som bruker samtaledistribusjonsgrupper.

For køer som bruker standard ruting, fortsett å distribuere kontakter gjennom køens konfigurerte rutingadferd.

I slike tilfeller fører aktiviteten til en feil, og gjennomføringen av flyten flyttes til Error Handling bane.

Vurder et eksempelscenario der en kontakt blir satt i kø i en kø og har tre samtaledistribusjonsgrupper, hver oppdatert etter en periode på 30 sekunder.

Ingen agenter er tilgjengelige i teamdelen av CDG 1 og CDG 2, og en agent er tilgjengelig i TEAM 3 som tilhører den siste anropsdistribusjonsgruppen.

Når aktiviteten i gruppen for eskalering av anropsdistribusjon ikke brukes i flyten, fører det til en lang ventetid, som vist nedenfor:

Ventetiden kan reduseres ved å bruke aktiviteten Eskalere anropsdistribusjonsgruppe som følger:

Basert på Next Group eller Last Group alternativet er valgt, ventetiden på kontakten reduseres betraktelig, som vist nedenfor:

Hvis du vil ha mer informasjon om aktivitetsinnstillinger, bruks- og utdatavariabler, kan du se Bygge og administrere flyter > Eskalere samtaledistribusjonsgruppe.

Aktiviteter for køinformasjon

Hent informasjon om kø

Informasjonsaktiviteten Get Queue gir muligheten til å hente informasjon om kø i sanntid for en gitt kontakt, for eksempel:

Kontaktens nåværende posisjon i kø (PIQ), eller den potensielle posisjonen hvis den ennå ikke er i kø.
Beregnet ventetid (EWT) eller hvor lenge en oppgave er beregnet til å vente i køen før den blir besvart.
Antall agenter som er logget på eller tilgjengelig i kontaktens nåværende samtaledistribusjonsgruppe.
Antall agenter som er logget på eller tilgjengelig på tvers av alle samtaledistribusjonsgrupper for den valgte køen.
Hvor lenge den eldste kontakten i køen har ventet.

Disse detaljene er gjort tilgjengelige i flytkjøringen som aktivitetsvariabler.

Hvis du vil ha mer informasjon om aktivitetsbruken, den detaljerte definisjonen og beregningsmetoden for hver kødetalj, kan du se Bygg og administrer flyter > Hent køinformasjon.

Noen av måtene du kan bruke køinformasjonen på kan være:

For å kunngjøre kontaktens posisjon i kø og beregnet ventetid til kunden mens de venter på å bli rutet.
For å avgjøre om en tilbakeringing kan registreres for kunden, hvis den estimerte ventetiden er for lang.
For å eskalere kontakten til neste samtaledistribusjonsgruppe (CDG), hvis ingen agenter er tilgjengelige i team som er tilordnet gjeldende CDG.

Informasjonsaktiviteten Hent kø fungerer når den valgte variabelen løses til en gyldig kø.

Konfigurer feilhåndteringsbanen for å administrere på en elegant måte tilfeller der den valgte variabelen trenger validering eller ikke løses til en tilgjengelig kø.

I følgende tilfeller gjelder ikke informasjon om køen i sanntid for den gjeldende samtaledistribusjonsgruppen:

kontakten er (ennå) ikke i kø når aktiviteten Get Queue Info utføres.
kontakten settes i kø i en kø som ikke støtter konseptet med samtaledistribusjonsgrupper.

I disse tilfellene indikerer verdien på -1 i disse utdatafeltene at denne informasjonen ikke gjelder.

Vurder et eksempelscenario der kunden bør informeres om en lang EWT i køen etter hvert 15 sekund brukt i køen.

Dette kan oppnås ved hjelp av Get Queue Info-aktiviteten i flyten på følgende måte:

Avansert køinformasjon

Den avanserte køinfo-aktiviteten gir muligheten til å hente køinformasjon i sanntid for en gitt kontakt, og tar i tillegg hensyn til kontaktens kompetansekriterier, for eksempel:

Kontaktens nåværende posisjon i kø (PIQ), eller den potensielle posisjonen hvis den ennå ikke er i kø.
Antall agenter som er logget på eller tilgjengelig i kontaktens nåværende samtaledistribusjonsgruppe, samsvarer med de angitte ferdighetskriteriene.
Antall agenter som er logget på eller tilgjengelig på tvers av alle samtaledistribusjonsgrupper for den valgte køen, samsvarer med de angitte ferdighetskriteriene.
Gjeldende samtaledistribusjonsgruppe der kontakten er parkert i en bestemt kø.
Totalt antall samtaledistribusjonsgrupper i en angitt kø.

Disse detaljene er gjort tilgjengelige i flytkjøringen som aktivitetsvariabler.

Hvis du vil ha mer informasjon om aktivitetsbruken, den detaljerte definisjonen og beregningsmetoden for hver kødetalj, kan du se Bygg og administrer flyter > Avansert køinformasjon.

Noen av måtene du kan bruke avansert køinformasjon på, kan være:

For å kunngjøre kontaktens posisjon i kø til kunden mens de venter på å bli rutet.
For å eskalere kontakten til neste samtaledistribusjonsgruppe, hvis ingen agenter som samsvarer med kompetansekriteriene er tilgjengelige i team som er tilordnet den gjeldende samtaledistribusjonsgruppen.
For å avgjøre om en tilbakeringing kan registreres for kunden, logges ingen agenter som samsvarer med kompetansekriteriene på tvers av alle samtaledistribusjonsgrupper.

Den avanserte køinfo-aktiviteten fungerer når:

Køinformasjonen er forespurt for køer der kompetansekrav konfigureres i flyten, i stedet for som kompetansekriterier på kønivå.
Hvis kontakten allerede er i kø, blir informasjonen bedt om for den samme køen der kontakten for øyeblikket er i kø.
Kontakten står i kø til en kø, ikke direkte til en foretrukket agent.

Konfigurer feilhåndteringsbanen for å administrere forespørsler som ikke oppfyller disse kravene.

I slike tilfeller fører aktiviteten til en feil, og gjennomføringen av flyten flyttes til Error Handling bane.

Vurder et eksempelscenario der kunden bør informeres om å motta en tilbakeringing når ingen agenter som oppfyller kompetansekriteriene er tilgjengelige.

Dette kan oppnås ved å bruke aktiviteten Avansert køinformasjon i flyten på følgende måte:

Aktiviteter for samtalekontroll

Angi innringer-ID

Aktiviteten Angi oppringer-ID brukes til å definere oppringer-ID som skal vises under en samtale. Aktiviteten Angi oppringer-ID må bare brukes på hendelsesflyter før oppringing som en terminal aktivitet som markerer slutten på hendelsesflyten.

Aktiviteten Angi oppringer-ID gjør det mulig å konfigurere den nødvendige automatiske nummeridentifikasjonen (ANI) basert på oppringt nummeridentifikasjonstjeneste (DNIS), operasjonstype eller deltakertype.

Hvis du vil ha mer informasjon om aktivitetsinnstillinger, bruks- og utdatavariabler, kan du se Bygg og administrer flyter > Angi innringer-ID.

Opptakskontroll

Opptakskontroll-aktiviteten er utformet for å brukes sammen med en menyaktivitet for å fange opp innringerens samtykke. Dette sikrer overholdelse av forskrifter eller retningslinjer som krever eksplisitt samtykke før opptaket begynner, og integrerer dette trinnet sømløst i arbeidsflyten.

Menyen IVR-aktivitet må registrere brukerens samtykke i en boolsk variabel som vil bli tilordnet som inndata til opptakskontroll-aktivitet. Hvis kunden trenger å rapportere brukerens samtykke i en samtykkerapport, skal samtykkeverdien lagres i en rapporterbar global variabel. Alternativt kan en lokal variabel brukes hvis rapportering ikke er nødvendig. Denne tilnærmingen gir leietakere og kunder økt fleksibilitet i å administrere og bruke variabler effektivt.

Når denne aktiviteten legges til i flyten, får brukerens samtykke forrang over innstillingene for leietakernivået eller kønivået eller innstillingene for opptaksplannivå.

Prioritetsrekkefølgen er som følger:

Hvis brukerens samtykke er Ja i flyten, registreres samtalen, uavhengig av opptakskonfigurasjonen som er angitt på leietakeren eller køen eller opptaksplannivået.
Hvis brukeren ikke samtykker som svar på aktiviteten, blir ikke samtalen tatt opp, uavhengig av opptakskonfigurasjonen som er angitt på leietakeren eller køen eller opptaksplannivået.
Hvis opptakskontroll-aktiviteten ikke er konfigurert i flyten, men en konfigurasjon er satt til Ja på et av de andre nivåene, for eksempel leietaker eller kø eller opptaksplan, blir samtalen tatt opp.
Hvis opptakskontroll-aktiviteten ikke er konfigurert i flyten, og en konfigurasjon er satt til Nei på alle nivåer, for eksempel leietaker, kø og opptaksplan, blir ikke samtalen tatt opp.

Denne opptakskontrollen kan illustreres som nedenfor:

I tillegg gjelder opptakskonfigurasjoner som Fortsett ved overføring, Pause gjenoppta aktivert, Pause varighet og andre fortsatt i henhold til det eksisterende hierarkiet, inkludert leietaker, kø eller opptakstidsplan.

Hvis du vil ha mer informasjon om aktivitetsinnstillinger, bruks- og utdatavariabler, kan du se Bygg og administrer flyter > Opptakskontroll.

Blind overføring

Blind Transfer er en prosess der en kontakt effektivt rutes til et eksternt oppringingsnummer (DN) gjennom IVR-systemet, noe som eliminerer behovet for agentinvolvering.

Blind Transfer-aktiviteten brukes når et anrop må overføres til et eksternt eller tredjeparts DN. Dette er en terminal aktivitet, så flyten avsluttes når overføringen er utført.

Blind overføring-aktivitet støttes ikke når flyten utføres for konsultasjon.

Hvis du vil ha mer informasjon om aktivitetsinnstillinger, bruks- og utdatavariabler, kan du se Bygg og administrer flyter > Blind Transfer.

Brolagt overføring

Den brolagte overføringsaktiviteten gjør det mulig for en kontakt å midlertidig overføres til en ekstern destinasjon mens flyten beholder kontrollen over samtalen. Den eksterne destinasjonen kan være en ekstern bro eller en interaktiv talerespons-tjeneste (IVR).

Når den eksterne destinasjonen avslutter samtalen, fortsetter samtaleflyten videre etter behov, som å kø den til en agent.

Brooverføring-aktiviteten dekø en kontakt mens den overføres til et tredjeparts IVR- eller automatisk samtaledistribusjonssystem (ACD). Hvis kontakten ikke håndteres av tredjepartssystemet, kan den settes tilbake i kø i den opprinnelige køen, slik at kontakten forblir i arbeidsflyten for riktig håndtering.

Anta for eksempel at et kontaktsenter har Webex Contact Center-agentressurser og agentressurser på et eksternt kontaktsenter eller Private Branch Exchange (PBX). Kunden ønsker å kø en samtale mot en kø med Webex Contact Center-agenter i en kort periode (si 60 sekunder). Hvis ingen agent er tilgjengelig i løpet av denne perioden, kan samtalen deretter overføres (med en implisitt dekø) til det eksterne kontaktsenteret for håndtering av kontakten.

Brolagt overføring-aktivitet støttes ikke i utgående anropsflyter og hendelsesflyter.
Kontakter som allerede er tilordnet en agent, støttes ikke for brooverføring gjennom flyten.

Hvis du vil ha mer informasjon om aktivitetsinnstillinger, bruks- og utdatavariabler, kan du se Bygg og administrer flyter > Brolagt overføring.

Koble fra kontakten

Frakoble kontakt-aktiviteten gir muligheten til å koble fra eller avslutte en aktiv kontakt direkte fra flyten.

Dette er en terminalaktivitet knyttet til flyten og kan være nyttig ved å avslutte kontakter uten agentintervensjon, egnet for feilbaneflyter eller etter at kunden har registrert en tilbakeringing.

Basert på konfigurasjonen utløses undersøkelsen etter samtale eller tilbakemelding når kontakten avsluttes gjennom denne aktiviteten.

Hvis du vil ha mer informasjon om aktivitetsinnstillinger, bruks- og utdatavariabler, kan du se Bygg og administrer flyter > Koble fra kontakt.

Angi kontaktprioritet

Aktiviteten Sett kontaktprioritet forenkler effektiv styring av kontaktprioritet i flyten ved å tillate tilordning av bestemte prioritetsnivåer til kontakter. Dette gjør det mulig å gi visse kontakter større eller mindre betydning, slik at de blir rutet riktig i forhold til andre ventende kontakter når agenter blir tilgjengelige. Denne fleksibiliteten gir nøyaktig kontroll over kontaktprioritering gjennom hele flyten.

Prioriteten fastsettes ved å tilordne et hierarkisk viktighetsnivå fra 1 (høyeste) til 9 (laveste). Kontakter med høyest prioritet rutes før de med lavere prioritet. Når flere kontakter deler samme prioritetsnivå, rutes kontakten som har ventet lengst først til neste tilgjengelige og kvalifiserte agent. Dette systemet sikrer at kontakter med høyere prioritet får umiddelbar oppmerksomhet, samtidig som det opprettholdes rettferdighet blant kontakter med lik prioritet basert på ventetiden.

Aktiviteten Angi kontaktprioritet kan plasseres når som helst i hovedflyten eller hendelsesflyten.
Hvis aktiviteten Angi kontaktprioritet er konfigurert før en køaktivitet (for eksempel Køkontakt eller Kø til agent), kan prioritetsinnstillingen overstyres av en hvilken som helst prioritet som er eksplisitt konfigurert i de påfølgende køaktivitetene. Hvis følgende køaktivitet imidlertid ikke angir en prioritet, vil kontaktprioriteten som er angitt av den tidligere aktiviteten Angi kontaktprioritet, bli brukt.
Hvis aktiviteten Angi kontaktprioritet er konfigurert etter en køaktivitet (for eksempel Køkontakt eller Kø til agent), overstyrer den prioritetsinnstillingen som er konfigurert av den forrige køaktiviteten.
Aktiviteten Angi kontaktprioritet støttes for øyeblikket ikke for oppringings- og kampanjekontakter.

Hvis du vil ha mer informasjon om aktivitetsinnstillinger, bruks- og utdatavariabler, kan du se Bygg og administrer flyter > Angi kontaktprioritet.

Tilbakeringingsaktiviteter

Tilbakeringing

En tilbakeringingsaktivitet gjør det mulig for innringere å be om tilbakeringing i stedet for å vente på vent, noe som forbedrer kundetilfredsheten betydelig ved å redusere ventetiden og minimere nedlastingshastigheten. Når den er aktivert, oppretter tilbakeringingsaktiviteten en oppgave i en kø, slik at en tilgjengelig agent kan returnere kundens samtale.

Flytdesigneren kan konfigurere aktiviteten til enten å holde kontakten i den opprinnelige køen, der samtalen kom fra, eller tilordne den til en annen kø basert på preferanser. Hvis tilbakeringingen forblir i den opprinnelige køen, opprettholder kontakten sin posisjon, ferdigheter, prioritet og kontekstuelle data, noe som gjør det mulig å tilordne neste tilgjengelige agent sømløs. Hvis en annen kø velges, skyves kontakten til slutten av den valgte køen uten ferdigheter og med standard prioritet.

Aktiviteten gjør det også mulig for kunder å be om tilbakeringinger fra sine foretrukne agenter, noe som tilfører opplevelsen et personlig preg og forbedrer kundetilfredsheten. Dette kan oppnås når tilbakeringingsaktiviteten følger en QueueToAgent-aktivitet i flyten. I tillegg tilbyr tilbakeringingsaktiviteten en valgfri konfigurasjon for å tilpasse den automatiske nummeridentifikasjonen (ANI) som brukes under tilbakeringingsprosessen. Denne tilpasningen bidrar til merkevarekonsistens og reduserer sannsynligheten for avvisning av anrop ved å sikre en gjenkjennelig oppringer-ID.

Flytdesigneren har muligheten til å inkludere en CallbackFailed-hendelse i hendelsesflyten. Denne hendelsen utløses når et tilbakeringingsforsøk mislykkes, slik at flytdesigneren kan gjennomføre nye forsøk med bestemte intervaller. Forsinkelsen eller intervallet mellom nye forsøk kan konfigureres ved hjelp av venteaktiviteten, med et minimumsintervall på 10 sekunder og et maksimum på 72 timer. Systemet støtter opptil 10 forsøk på nytt over et maksimum på 14 dager ved hjelp av venteaktiviteten.

Hvis du vil ha mer informasjon om aktivitetsinnstillinger, bruks- og utdatavariabler, kan du se Bygg og administrer flyter > Tilbakeringing.

Planlegg tilbakeringing

Den planlagte tilbakeringingsaktiviteten gjør det mulig for kunder å be om en tilbakeringing på en bestemt fremtidig dato og klokkeslett – noe som eliminerer behovet for umiddelbar tilkobling til en agent. Denne funksjonen forbedrer kundeopplevelsen ved å gjøre det mulig for dem å velge et praktisk tilbakeringingsvindu, og dermed minimere opplevd ventetid og redusere hastigheten for tilbakeringing.

Flyten må registrere innringerens inndata, for eksempel foretrukket dato og klokkeslett, via DTMF-ledetekster og sende dem til aktiviteten etter at de nødvendige inndatavalideringene er utført.

Før du kommer i gang, må du sørge for at Callback Default Entry Point er konfigurert under Channel Settings i Control Hub. Hvis du vil ha mer informasjon, kan du se Konfigurere et inngangspunkt for tilbakeringing.

Tilbakeringing kan planlegges ved hjelp av en hvilken som helst telefonikø – enten innkommende eller utgående. For best resultat anbefales det å legge til en frakobling-aktivitet umiddelbart etter den planlagte tilbakeringingsaktiviteten for å sikre at den gjeldende samtalen avsluttes på riktig måte når tilbakeringingen er planlagt. Hvis du vil ha mer informasjon om planlegging av IVR-tilbakeringinger, kan du se Planlegg IVR-tilbakeringinger.

Når tilbakeringingen utløses på den forespurte fremtidige datoen og klokkeslettet, opprettes det et nytt anrop eller en ny samhandling. Denne nye samhandlingen vil følge standardflyten som er koblet til standard inngangspunkt for tilbakeringing. Hvis tilbakeringingsforsøket mislykkes, kan flyten automatisk prøve å ringe på nytt ved hjelp av hendelsesbehandleren TilbakeringingFailed hvis den er konfigurert i den flyten.

Følgende inndatavalideringer bør vurderes før inndata overføres til aktiviteten:

Datovalg – Du kan velge en hvilken som helst dato fra i dag til 31 dager i fremtiden. Datoen må være i dette formatet: ÅÅÅÅ-MM-DD (for eksempel 2025-07-18).
Starttidspunkt og sluttidspunkt for tidsvindu – Tidspunktet du velger må starte minst 30 minutter fra nå og kan vare hvor som helst mellom 30 minutter og 8 timer. Bruk 24-timers tidsformat (som 14:30:00).
Tidssone – Du må angi en gyldig tidssone i IANA-format (som America/New_York), slik at vi kan ringe deg til rett tid.

En referanseimplementering er gitt i form av en underflytmal for å demonstrere DTMF-ledetekstene og grunnleggende valideringer som brukes sammen med aktiviteten. Hvis du vil ha mer informasjon, se Mal for planlagt tilbakeringing.

Analyse av samtalefremdrift

CPA (Call Progress Analysis) gjør det mulig å oppdage automatiserte svarsystemer og direkte menneskelige stemmer ved tilbakeringingssamtaler.

Når et tilbakeringingsforsøk støter på en svarmaskingjenkjenning (AMD) eller talepost, identifiserer systemet samtalen som mislykket. Resultatet av Answering Machine Detection (AMD) registreres i årsaken til utdatavariabelen for CallbackFailed-hendelsesbehandleren. Basert på denne utdatavariabelen kan flytdesigneren konfigurere nye forsøk på tilbakeringing.

For høflig tilbakeringing kan CallProgressAnalysis plasseres på et punkt etter tilbakeringingsaktiviteten i hovedflyten. For planlagt tilbakeringing eller personlig planlagt tilbakeringing kan den plasseres etter NewPhoneContact i hovedflyten.
I hendelsesflyten støttes den bare i CallbackFailed-hendelsesbehandler.
Hvis en kundeundersøkelse etter samtale (tilbakemeldingsaktivitet) er konfigurert i flyten, vil den ikke bli startet hvis anropet besvares av en AMD eller talepost. Dette forhindrer at unødvendige undersøkelser utløses.

Hvis du vil ha mer informasjon om aktivitetsinnstillinger, bruks- og utdatavariabler, kan du se Bygg og administrer flyter > Analyse av samtalefremdrift.

Kø

Oversikt

I Webex kontaktsenter fungerer en kø som et venteområde for innkommende samhandlinger som telefoni, chat, e-post eller sosiale kanaler. Kontakter parkeres i køer inntil de distribueres automatisk til agenter, eller agenter henter dem manuelt for håndtering. I tillegg støtter de funksjoner som ferdighetsbasert ruting, prioritetsadministrasjon og rettferdig arbeidsfordeling.

Ledere kan bruke køer til å observere ulike arbeidslinjer og forbedre hvordan oppgaver håndteres i kontaktsenteret.

Noen av de viktigste fordelene med å bruke køer effektivt er:

Bedre kundeopplevelse: Administrer ventetider og la kundene vite at de står i kø for å bli hjulpet.
Økt effektivitet: Sørg for at samtaler håndteres på en ordnet måte, noe som reduserer kaos og dårlig administrasjon.
Rettferdig fordeling av kontakter: Fordel samtaler jevnt mellom agentene for å unngå overbelastning av én enkelt agent.
Prioritert håndtering: Tillat prioritering av bestemte anrop, for eksempel VIP-kunder eller hastesaker.

Typer køer

Webex kontaktsenter støtter flere typer køer som muliggjør et bredt utvalg av brukstilfeller for kontaktsentre i alle størrelser og kompleksiteter, på tvers av alle medietyper med ensartede funksjoner.

Det finnes køer som tar hensyn til agentferdigheter ved rutering av kontakter, og køer som ikke gjør det. Disse køene er også forskjellige når det gjelder hvordan agenter er tilknyttet dem for å jobbe med kontakter.

Det finnes to hovedkategorier av køer:

Ikke-ferdighetsbaserte køer
Ferdighetsbaserte køer

Ikke-ferdighetsbaserte køer

Køer som ikke er ferdighetsbaserte, tar ikke hensyn til ferdigheter knyttet til agenter. Du kan konfigurere køer som ikke er ferdighetsbaserte med følgende alternativer:

Teamoppgaver
Agentoppdrag

Ikke-ferdighetsbaserte køer med teamtildelinger

I køer som ikke er ferdighetsbaserte og har teamtildeling, kan du organisere agenter i team og kombinere disse teamene for å danne samtaledistribusjonsgrupper (CDG). Du kan angi en tidsforsinkelse mellom hver gruppe for å administrere samtaleflyten.

Anropsdistribusjonsgrupper hjelper med å definere flere nivåer av agenter som blir kvalifisert til å jobbe med kontakter i denne køen over konfigurerte tidsintervaller. Kontakter tilordnes agenter basert på teamnivået deres. Hvis ingen agenter er tilgjengelige, parkeres kontaktene i en forhåndskonfigurert periode før de utvides til å inkludere den neste gruppen med team. Denne prosessen fortsetter til en agent er tilgjengelig eller alle gruppene er sjekket.

Du kan sette opp disse typene team:

Individuelle lag: Agenter kan organiseres i team som kan representere en spesifikk organisasjonsfunksjon, som deretter kan bli en del av køer slik at kontakter kan rutes til agenter i disse teamene. Du kan merke en agent til flere team for å håndtere kontakter fra ulike køer for effektiv ruting.
Kapasitetsbaserte team: Kapasitetsbasert team (CBT) er en funksjon som dirigerer taleanrop til et kapasitetsbasert direktenummer (DN), der kapasiteten bestemmer hvor mange anrop som kan håndteres samtidig. Det muliggjør rutering av anrop til telefonnumre uten at agenter må logge seg på systemet, noe som gjør det egnet for scenarier der anrop besvares av telefonsvarer, telefonsvarere eller søkegrupper, i stedet for tradisjonelle kundesenteragenter. I dette oppsettet er det ingen spesifikke agenter tilordnet teamet, og de bruker ikke Webex Contact Center Agent Desktop.

Arbeidsflytdiagram for hvordan ikke-ferdighetsbasert kø med teamtildeling fungerer i Webex kontaktsenter

I dette eksemplet er det tre samtaledistribusjonsgrupper, som tillater målutvidelse, som betyr utvidelse til flere agenter på tvers av team over konfigurerte tidsintervaller.

Den første samtaledistribusjonsgruppen inneholder TEAM 1, som har 3 konfigurerte agenter – A1, A2 og A5.

Den andre samtaledistribusjonsgruppen inneholder TEAM 2, som har 3 konfigurerte agenter – A2, A3 og A4.

Den tredje (og siste) samtaledistribusjonsgruppen inneholder TEAM 3, som har to konfigurerte agenter – A6 og A7.

Når en kontakt settes i kø, søker systemet først etter en samsvarende agent i den første samtaledistribusjonsgruppen. Hvis det ikke finnes noen agenter, parkeres kontakten i den konfigurerte varigheten før målutvidelsen til neste gruppe foretas. Dette legger til nye lag til de eksisterende. Denne prosessen gjentas til den finner et treff, eller alle gruppene utvides.

En funksjon kalt «Sjekk agenttilgjengelighet» fører til at kontakten umiddelbart utvides til den påfølgende samtaledistribusjonsgruppen hvis det ikke finnes noen samsvarende agenter i gjeldende gruppe. Dette kan aktiveres i køkontaktaktiviteten <LINK TO section 3.1.1> i flyten.

Dette oppsettet resulterer i følgende scenarier:

A2 tilhører LAG 1 og LAG 2. Hvis A2 velger TEAM 1 for å logge på Agent Desktop, anser systemet A2 som en del av TEAM 1 og dermed bare den første samtaledistribusjonsgruppen.
A5 tilhører TEAM 1, men kan også ha vært en del av et annet team i organisasjonen de er logget inn på. Derfor regnes ikke A5 som en del av TEAM 1 og er ikke tilknyttet denne køen.

Køer med teamtildeling gir agenter denne kraftige muligheten til å navigere mellom køer ved ganske enkelt å velge et team under pålogging.

Tilgjengelig rutemønster:

Lengst tilgjengelig

Ikke-ferdighetsbaserte køer med agenttildelinger

Ikke-ferdighetsbaserte køer er en type kø der en gruppe agenter er direkte tilordnet køen. I motsetning til andre køtyper, som indirekte bestemmer utvalget av agenter som er tildelt dem, lar disse køene administratorer velge agenter direkte og manuelt. For eksempel tildeler teambaserte tildelingskøer agenter basert på deres påloggede team, og ferdighetsbaserte tildelingskøer matcher agenter basert på nødvendige ferdigheter. I motsetning til dette kan administratorer legge til agenter direkte i disse køene for å bli en del av køen. Dette gir en enkel måte å administrere agentallokering uten å være avhengig av systemdrevne tildelinger.

Køer med agenttildeling gir enkle, men effektive rutingsalgoritmer som hjelper med å fordele kontakter blant agentgruppen. De tar ikke hensyn til agentenes ferdigheter i å rute kontakter. Agenter kan imidlertid bestilles innenfor hver kø, og dette tas i betraktning når kontakter rutes til dem. I denne sammenhengen fungerer team primært som en organisatorisk konstruksjon for veiledere, snarere enn en faktor i beslutninger om tilknytning mellom agent og kø og kontaktruting, noe som forenkler køhåndteringen.

Denne typen kø er best egnet der statisk tildeling av agenter og administrasjon av agent-kø-tilknytning er gjennomførbart og ønskelig for driftskontroll, og valget av rutingsalgoritmer er egnet for arbeidsfordeling mellom agenter. Disse køene er også spesielt nyttige i scenarioer der flere typer kundehenvendelser krever spesialisert ekspertise som kan betjenes av et forhåndsopprettet segment av ekspertagenter.

Komplekse kontaktsenterorganisasjoner kan imidlertid synes det er vanskelig å administrere agenttildelinger manuelt i disse køene. De kan dra mer nytte av andre køtyper som tilbyr dynamisk ruting og agent-kø-tilknytninger.

Arbeidsflytdiagram som viser hvordan et eksempel på en ikke-ferdighetsbasert kø med agenttildeling i Webex Contact Center fungerer

I dette eksemplet har køen et sett med agenter som er tilordnet i en bestemt rekkefølge, for eksempel A4, A9, A7 og så videre. Denne rekkefølgen spiller en rolle i spesifikke rutingsalgoritmer som matcher innkommende kontakter med agenter. Systemet matcher kontakter med disse agentene basert på tilgjengeligheten deres og den valgte rutingsalgoritmen.

I motsetning til køer med teamtildeling, finnes det ikke noe konsept med målutvidelse over tidsintervaller. Hvis ingen av de konfigurerte agentene er tilgjengelige for å rute denne kontakten, parkeres den i køen inntil en av disse agentene blir tilgjengelig for å håndtere kontakter før tidsavbruddet for parkering. Målutvidelse gjelder ikke for disse køene.

Tilgjengelige rutemønstre:

Lengst tilgjengelig
Sirkulær
Linear/Top-down

Ferdighetsbaserte køer

Ferdighetsbaserte køer gir muligheten til at kontakter kan rutes til agenter med de riktige ferdighetene for å dekke deres behov.

Du kan konfigurere følgende typer ferdighetsbaserte alternativer:

Ferdighetskriterier tilordnet kø
Ferdighetskrav tildelt i flyt

Ferdighetskriterier tilordnet kø

Administratorer kan tilordne ferdighetskriterier til køer. Ferdighetsbaserte køer med ferdighetskriterier lar administratorer konfigurere nødvendige ferdigheter direkte i køen. Alle agenter i organisasjonen som har alle de nødvendige ferdighetene i køen via direkte ferdighetsprofil, blir implisitt en del av denne køen.

Dette oppsettet hjelper administratorer med å få en live-visning av agenter som er tilordnet til køen i kraft av ferdigheter. I situasjoner som høyt eller lavt volum kan administratorer vurdere å justere de nødvendige ferdighetene i køen og agentens ferdighetsprofiler for å utvide eller krympe agentpoolen etter behov.

Denne typen kø skiller seg fra køer basert på teamtildeling ved at det ikke finnes noen innstilling for samtaledistribusjonsgruppe, som betyr at teamet ikke spiller noen rolle i tilknytningen mellom agent og kø. Dessuten er de nødvendige ferdighetene statisk konfigurert i denne køen, i motsetning til teambaserte ferdighetskøer der flyten injiserer (statiske eller variable) nødvendige ferdigheter. Derfor er ferdighetene teknisk sett en del av køen snarere enn selve kontakten.

Enhver agent i organisasjonen som fullt ut oppfyller ferdighetskriteriene i køen (har ferdigheter fra direkte ferdighetsprofil) blir implisitt tilknyttet denne køen. Teamet spiller ingen rolle i agenttilknytningen til disse køene. Disse agentene kan være en del av ethvert team for ledelses- og driftsformål.

Alle kontakter som er plassert i denne køen, vil automatisk anta ferdighetskriteriene som er definert i selve køen. Individuelle kontakter kan ikke definere eller overstyre sin egen ferdighet requirements/criteria i motsetning til i ferdighetsbaserte køer med teamtildeling.

Arbeidsflytdiagram som viser et eksempel på hvordan ferdighetsbasert kø med ferdighetskriterier fungerer i Webex kontaktsenter

I dette eksemplet,

Bare agentene A1, A3 og A7 oppfyller ferdighetskriteriene som er konfigurert i køen, og derfor vil bare disse agentene være tilknyttet denne køen.
Agentene A2, A4 og A6 som delvis oppfyller kriteriene, eller A5 som mangler relevante ferdigheter, kan ikke tilknyttes denne køen.

Hvis du oppdaterer ferdighetsprofilen til en agent (kalt omskolering) slik at den oppfyller ferdighetskriteriene i køen, vil agenten automatisk og dynamisk bli en del av denne køen. Alternativt vil oppdatering av selve køferdighetskriteriene slik at flere (eller færre) agenter oppfyller de oppdaterte ferdighetskriteriene også automatisk og dynamisk legge til (eller fjerne) agenter fra denne køen.

I motsetning til køer med teamtildeling, finnes det ikke noe konsept med målutvidelse over tidsintervaller. Hvis kontakten ikke kan matches med noen av de tilknyttede agentene, parkeres den i køen inntil en av disse agentene blir tilgjengelig for å håndtere kontakter før parkeringstiden utløper.

Ferdighetsbaserte køer er best egnet der statisk tildeling av ferdigheter og administrasjon av kø-til-agent-tilknytning er gjennomførbart og ønskelig for driftskontroll. De er også egnet når valget av rutingsalgoritmer er passende for arbeidsfordeling mellom agenter. Disse køene er også spesielt nyttige i scenarioer der ulike typer kundehenvendelser krever spesifikke ferdigheter som kan betjenes av et forhåndsdefinert segment av ekspertagenter.

Komplekse kontaktsenterorganisasjoner kan synes det er enklere å administrere tildelinger fra kø til agent i ferdighetsbaserte køer, sammenlignet med køer med agenttildeling der hver agent må legges til listen manuelt, noe som er tungvint, spesielt for en større organisasjon.

Ferdighetskrav tildelt i flyt

Ferdighetsbaserte køer med ferdighetskrav tilordnet i flyten er en type teamtildelingsbasert kø i Webex Contact Center der et sett med team er konfigurert på flere nivåer, kalt samtaledistribusjonsgrupper. Agenter som er logget på disse konfigurerte teamene, tildeles kontakter fra denne køen basert på nivået for samtaledistribusjonsgruppe der teamet deres er konfigurert i køen, hvis de også oppfyller kontaktens ferdighetskrav fullt ut.

Innenfor en slik kø grupperes agentteamene i samtaledistribusjonsgrupper med konfigurerbare tidsforsinkelser mellom seg. Hvis ingen agent er tilgjengelig for kontakten, parkeres forespørselen, og etter forsinkelsen utvides rutingen til neste samtaledistribusjonsgruppe. Denne prosessen fortsetter til en agent er tildelt eller alle gruppene er oppbrukt. Hvis en agent i en tidligere merket gruppe blir tilgjengelig i løpet av denne prosessen, velges den agenten.

Agenter tilegner seg ferdigheter via ferdighetsprofiler som er direkte tildelt agenten. Agentferdigheter bestemmes basert på teamvalget under pålogging.

Hver kontakt kan eventuelt spesifisere ferdighetskrav i flyten, som matches mot ferdighetene til tilgjengelige agenter for å velge den mest passende agenten.

I tillegg kan kontakter også spesifisere ferdighetsavslappinger med konfigurerte tidsintervaller. Dette er et modifisert sett med ferdighetskrav som overskriver de opprinnelige ferdighetskravene til kontakten etter konfigurerte tidsintervaller. Dette lar en kontakt endre (vanligvis brukt for å "avslappe") sine ferdighetskrav mens de er parkert i kø, slik at flere agenter kan matche disse avslappede ferdighetskravene.

Målutvidelse gjennom samtaledistribusjonsgrupper kan skje samtidig med ferdighetsavlastningssykluser – begge med sikte på å matche en parkert kontakt med kvalifiserte agenter raskere, og dermed redusere den totale ventetiden og forbedre servicenivået i køen.

Arbeidsflytdiagram som viser et eksempel på hvordan ferdighetsbasert kø med teamtildeling fungerer i Webex kontaktsenter.

I likhet med køer for ikke-kvalifiserte med teamtildeling, har den tre samtaledistribusjonsgrupper som tillater "målutvidelse", dvs. utvidelse til flere agenter på tvers av team over konfigurerte tidsintervaller.

Den første samtaledistribusjonsgruppen inneholder TEAM 1, som har 3 konfigurerte agenter – A1, A2 og A5.
Den andre samtaledistribusjonsgruppen inneholder TEAM 2, som har 3 konfigurerte agenter – A2, A3 og A4.
Den tredje (og siste) samtaledistribusjonsgruppen inneholder TEAM 3, som har to konfigurerte agenter – A6 og A7.

Det er imidlertid to hovedting å merke seg:

Hver kontakt som settes i denne køen vil definere sine ferdighetskrav og ferdighetsavlastning gjennom flyten.
Agenter kan ha konfigurerte ferdigheter (gjennom en ferdighetsprofil – direkte eller arvet fra det innloggede teamet).

Selv om A2 er konfigurert til å være en del av både LAG 1 og LAG 2, avhengig av hvilket lag denne agenten har valgt under innlogging, regnes han i sin nåværende økt som en del av det teamet, og vil derfor også arve ferdighetsprofilen (og dermed ferdighetsverdiene) fra det teamet (med mindre dette overstyres med en direkte ferdighetsprofilkonfigurasjon for denne agenten).

Dette er en kraftig funksjon som tilbys av køer med teamtildelinger, der agenter kan navigere mellom køer ganske enkelt ved å velge et team under pålogging.

Kombinert med muligheten til å arve ferdighetsprofilinnstillinger fra det valgte teamet, kan en agent også jobbe med forskjellige sett med ferdigheter.

I dette eksemplet,

Kontakter settes i kø med et innledende ferdighetskrav (sk_1 >= 6) under eskalering fra flyt, med en ferdighetsavslapning (sk_1 >= 3) etter et konfigurert tidsintervall.
På tvers av alle agenter i alle samtaledistribusjonsgrupper har bare A1, A3, A6 og A7 ferdigheter som tilfredsstiller det opprinnelige ferdighetskravet for kontakter i kø.
De gjenværende agentene har enten ferdigheten (sk_1), men tilfredsstiller ikke ferdighetskravene (f.eks. A2 i TEAM 1 og A4 i TEAM 2), eller har ikke denne ferdigheten i det hele tatt (f.eks. A5, A2 i TEAM 2).
Over tid, ved avslapping av ferdigheter, tilfredsstiller i tillegg A2 og A4 nå også de "avslappede" ferdighetskravene til kontakten.

For hver kontakt som settes i denne køen, prøver systemet å finne en matchende agent i den første samtaledistribusjonsgruppen som fullt ut tilfredsstiller kontaktens gjeldende ferdighetskrav. Hvis ingen samsvarende agent finnes, parkeres kontakten i den konfigurerte varigheten før målutvidelsen skjer til den andre samtaledistribusjonsgruppen. Alle teamene som er konfigurert i den andre samtaledistribusjonsgruppen legges også til eksisterende team fra den første gruppen. Nå prøver systemet å finne en matchende agent innenfor den utvidede gruppen. Merk at mens dette skjer, vil ferdighetsavslapping også oppdatere kontaktens ferdighetskrav med konfigurerte tidsintervaller, og systemet vil bruke oppdaterte ferdighetskrav for å matche tilgjengelige agenter i den gjeldende samtaledistribusjonsgruppen.

Dette fortsetter til alle de konfigurerte anropsdistribusjonsgruppene er utvidet og alle ferdighetsavslappinger er brukt, med mindre en samsvarende agent blir funnet først.

Tilgjengelige rutemønstre:

Lengst tilgjengelig
Beste tilgjengelige

Køkonfigurasjon

Sett opp ferdighetsbaserte køer

Tilordne ferdighetskriterier til en kø

Opprett ferdigheter og, om nødvendig, dynamiske ferdigheter.
Opprett ferdighetsprofiler.
Tilordne ferdighetsprofil direkte til agenter.
Tildel dynamiske ferdigheter direkte til agenter. Dynamiske ferdigheter tildeles ikke gjennom ferdighetsprofiler.
Opprett kø med kanaltypen Telefoni eller Chat eller E-post eller Sosialt.
Tilordne ferdigheter og krav til dynamiske ferdigheter til køer i Control Hub.
Vis liste over agenter som kan håndtere kontakter i køen.
Velg en rutingsalgoritme, enten LAA eller BAA. For BAA, konfigurer vekter for ferdighetsferdigheter og dynamiske ferdighetsferdigheter ved behov.
Legg til en køkontaktaktivitet i flyten og velg denne køen.

Tilordne ferdighetskrav til en kø

Opprett ferdigheter og, om nødvendig, dynamiske ferdigheter.
Opprett ferdighetsprofiler.
Tilordne ferdighetsprofil til agenter direkte eller team.
Tildel dynamiske ferdigheter direkte til agenter. Dynamiske ferdigheter tildeles ikke gjennom ferdighetsprofiler.
Opprett et -team.
Legg til agenter i teamet.
Opprett kø med kanaltypen Telefoni eller Chat eller E-post eller Sosialt.
Legg til lag i køen i én eller flere CDG-er.
Velg et rutemønster enten LAA eller BAA.
Legg til en køkontaktaktivitet i flyten og velg køen som ferdighetsbasert ruting er konfigurert for. For mer informasjon, se Køkontakt.
Tildel ferdigheter, dynamiske ferdigheter og ferdighetsavslapping i køkontaktaktiviteten. For BAA, konfigurer vekter for ferdighetsferdigheter og dynamiske ferdighetsferdigheter ved behov.
Bruk Eskaler samtaledistribusjonsaktivitet i flytetterkø for å raskt gå til neste samtaledistribusjonsgruppe eller den siste.

Sett opp køer som ikke er ferdighetsbaserte

Tilordne team til en kø

Opprett et -team.
Legg til agenter i teamet.
Opprett kø med kanaltypen Telefoni eller Chat eller E-post eller Sosialt.
Legg til lag i køen i én eller flere CDG-er.
Velg et rutemønster enten LAA.
Legg til en køkontaktaktivitet i flyten og velg denne køen.
Bruk Eskaler samtaledistribusjonsaktivitet i flytetterkø for å raskt gå til neste samtaledistribusjonsgruppe eller den siste.

Tilordne agent til en køflyt

Opprett kø med kanaltypen Telefoni eller Chat eller E-post eller Sosialt.
Legge til agenter direkte i køer (Merk: Verken ferdigheter eller lag brukes i denne typen kø).
Velg rutingsmønstre som Sirkulær eller Lineær eller Lengst tilgjengelig agent.

Ruting

Rutekonsepter

Agentoverskuddsscenario

Et agentoverskuddsscenario oppstår når det er flere tilgjengelige agenter enn det er kontakter i køen. I dette tilfellet, når en kundeinteraksjon (kontakt) settes i kø, prøver systemet å finne en samsvarende agent for denne spesifikke kontakten umiddelbart, og hvis en samsvarende agent blir funnet, trenger ikke kontakten å parkeres i køen og vente på at en samsvarende agent skal være tilgjengelig senere.

Hver gang en kontakt gjennomgår utvidelse gjennom en samtaledistribusjonsgruppe, eller gjennom ferdighetsavslapping, prøver systemet igjen å finne en matchende agent for denne spesifikke kontakten umiddelbart.

Det konfigurerte rutingsmønsteret i køen brukes til å finne en samsvarende agent for en bestemt kontakt.

Webex Contact Center tilbyr flere rutingsmønstre på tvers av ulike typer køer, noe som lar organisasjoner optimalisere kundeservicen ved å minimere ventetider, balansere arbeidsbelastninger for agenter og sikre at kundene kobles til agenter som har de nødvendige ferdighetene til å imøtekomme deres spesifikke behov. Se avsnittet Rutemønster for detaljert informasjon om rutemønstre.

Kontaktoverskuddsscenario

Kontaktoverskuddsruting oppstår når antallet innkommende kundeinteraksjoner (eller kontakter) overstiger antallet tilgjengelige agenter. Denne situasjonen oppstår ofte i rushtiden eller ved uventede økninger i kontaktvolum. Hovedmålet med ruting av kontaktoverskudd er å håndtere dette overløpet effektivt, og sikre at kundeservicestandardene opprettholdes til tross for overetterspørselen. For en agent som nettopp har blitt tilgjengelig på en bestemt kanal, jobber ruting av kontaktoverskudd med å finne og tilordne riktig kontakt blant alle parkerte kontakter på tvers av alle køer som denne agenten er tilknyttet.

De viktigste strategiene for å utføre kontaktruting effektivt med begrenset agenttilgjengelighet er:

Kørangering
Kørangering lar administratorer spesifisere den relative viktigheten av køer. Administratorer kan definere kørangeringer for å angi rekkefølgen samtaler rutes fra køer til agenter som er logget på team, på teambasis.
Tenk deg for eksempel at agenter som er logget inn på Team A er tilknyttet to køer – «Fakturering» og «Salg». Administratorer kan bruke kørangering for å tildele en høyere rangering til «Fakturering»-køen, slik at når kontakter kommer inn i køene, blir kontakter fra «Fakturering» rutet til agenter som tilhører Team A før kontakter fra «Salg»-køene. Dette vil skje selv om det kan være eldre og høyere prioriterte kontakter som venter i «Salg»-køen – bare fordi «Faktureringskøen» har en høyere rangering i køen enn «Salg»-køen. Først når det ikke er flere ventende kontakter i «Fakturerings»-køen, vil agenter fra Team A bli omdirigert til kontakter fra «Salg»-køen (og alle andre køer) de er tilknyttet.
Følgende er noen av de viktigste egenskapene ved kørangering:
- - Hvis en rangering kun tildeles noen av køene, vil anrop i disse køene prioriteres over anrop i køene der det ikke er spesifisert noen rangering.
  - Kørangering kan settes på maksimalt 50 køer på tvers av alle medietyper med en verdi mellom 1 og 50, med 1 som høyeste rangering.
  - Du kan tilordne samme rang til flere køer.
  - Hvis du aktiverer kørangering, behandles køer som ikke er tildelt noen eksplisitt rangering lavere enn alle rangerte køer.
  - Kørangering fungerer innenfor samme medietype.
    
    Hvis for eksempel Køsalg er en kø av typen talemedie med rangering 2 og Køfaktureringsstøtte er en chattekø med rangering 1 for Team A, får agenter som er tilgjengelige på talekanalen i Team A taleanropet først, selv om rangeringen er 2.
    
    Tenk imidlertid på to chatkøer for Team B - Køkredittkort med kørangering 2 og Kødebetkort med kørangering 1. Deretter vil de tilgjengelige agentene i Team B først bli tilbudt kontakter fra kødebetkort.
  - Kørangering gjelder ikke for kapasitetsbaserte team.
Kontaktprioritet
Når en kontakt er satt i kø, kan prioriteten defineres ved å tilordne en hierarkisk viktighet fra 1 (høyest) til 10 (lavest, standard). Denne prioriteringen sikrer at visse kontakter blir adressert raskere basert på deres viktighet, hastverk eller strategiske verdi for organisasjonen. Når en agent er tilgjengelig for å håndtere den neste kontakten blant alle parkerte kontakter på tvers av alle køene som agenten er tilknyttet, blir kontakten med høyest prioritet på tvers av alle køene rutet til agenten (forutsatt at andre kriterier som ferdighetsmatching og andre er oppfylt).
For kontakter som er i kø uten noen eksplisitt prioritet, vurderes en standardprioritet på 10 (laveste). Blant flere kontakter som har samme prioritet, blir kontakten som venter lengst i køen rutet først til den tilgjengelige og kvalifiserte agenten.
Kontakt med lengst ventetid
Dette er en grunnleggende strategi som sikrer at den kontakten som har ventet lengst på tvers av alle køene som agenten er tilknyttet, blir rutet til agenten.
Dette er det endelige kriteriet som avgjør hvilken kontakt som skal rutes når flere kontakter på tvers av køer med samme kørangering og samme kontaktprioritet venter på å bli behandlet.

I hovedsak betyr ruting av overflødige kontakter for en agent som nettopp ble tilgjengelig å velge én enkelt kontakt som:

er av samme medietype som den agenten er tilgjengelig på
er parkert i noen av køene som denne agenten er tilknyttet
hvis ferdighetskrav (hvis noen) alle oppfylles av denne agenten
er parkert i en kø med høyere rang enn andre køer, slik det er konfigurert i agentens team
har høyest prioritet blant alle slike kontakter
er den eldste ventende kontakten blant kontakter med samme prioritet

I eksemplet ovenfor som illustrerer et scenario med kontaktoverskudd, har agent A1 logget seg på TEAM 1 og blitt tilgjengelig for å håndtere kontakter på flere medietyper.

A1 er tilknyttet 3 køer – Q1, Q2 og Q3. TEAM 1 har også definert kørangering der Q1 er rangert høyest, deretter henholdsvis Q2 og Q3.

Det er allerede kontakter parkert i alle disse køene, med ferdighetskrav og prioritet definert for hver kontakt.

Nå fungerer scenariet med kontaktoverskudd som følger:

Blant alle de parkerte kontaktene på tvers av disse køene, kan bare 4 kontakter rutes til A1 – C2, C7 (fra KØ 2) og C3, C8 (fra KØ 3).

Bare ferdighetskravene til disse 4 kontaktene er fullstendig oppfylt av ferdighetene til A1.
Blant disse fire kontaktene prioriteres kontakter fra KØ 2 (dvs. C2, C7) fordi KØ 2 har den høyeste rangeringen i køen.

Merk at selv om KØ 1 er den høyest rangerte køen, kan ingen av dens parkerte kontakter rutes til A1 siden ferdighetskravene deres ikke oppfylles av A1.
Mellom C2 og C7er kontakten med høyest prioritet C7. Så det endelige valget er C7, og systemet ruter det til A1.

Dette skjer selv om C2 ble satt i kø tidligere, fordi kontaktprioritet prioriteres over køtid.

Blandede multimediaprofiler

Gjennom konfigurasjon av multimedieprofil lar Webex Contact Center agenter betjene kontakter på tvers av ulike medietyper (tale, chat, e-post og sosiale medier). Basert på denne konfigurasjonen får agenter kanaler tildelt per medietype.

Hver kontakt som rutes til en agent bruker én kanal av den medietypen så lenge agenten jobber med den kontakten. Selv om agenter bare kan ha én talekanal, kan de ha opptil fem kanaler med andre medietyper.

Innstillingen for blandet ruting i Multimedieprofiler lar administratorer kontrollere hvordan forskjellige kanaler kan brukes samtidig for hver agent. Dette gjør det mulig for organisasjoner å gi kundene dedikert oppmerksomhet, fremme bedre servicekvalitet, forbedret kundeopplevelse og bedre konverteringsrater. Organisasjoner kan også balansere belastningen på tvers av mediekanaler når de opplever ujevn belastning i noen kanaler, noe som muliggjør effektiv utnyttelse av agenter.

Det er tre valg:

Eksklusiv
Blandet
Blandet sanntid

Når agenter håndterer en ikke-talekontakt, kan de starte et manuelt utgående taleanrop fra Agent Desktop, så lenge de har en talekanal tilgjengelig. Dette gjelder for alle typer multimedieprofiler.

Hvis du vil ha mer informasjon om konfigurering av multimedieprofiler, kan du se Administrere multimedieprofiler.

Rutemønstre

Ferdighetsbasert

Ferdighetsbaserte rutingsmønstre i Webex Contact Center dirigerer innkommende kundeinteraksjoner til agenter basert på spesifikke ferdigheter som kreves for å løse forespørselen, for eksempel språkkunnskaper eller teknisk ekspertise. Disse mønstrene sikrer at hver kunde kobler seg til den mest kvalifiserte agenten, noe som forbedrer tjenesteeffektiviteten og kundetilfredsheten. Fordelene inkluderer redusert behandlingstid, forbedrede løsningsrater og optimalisert bruk av agentressurser ved å tilpasse ekspertisen deres til kundenes behov.

Ferdighetsbasert ruting kan bruke ferdigheter som agenter mottar fra ferdighetsprofiler og dynamiske ferdigheter som er tildelt direkte til agenter. Dynamiske ferdigheter representerer agentattributter som kan endres uavhengig av en agents ferdighetsprofil.

Når ferdighetsbaserte rutingsmønstre brukes, brukes først ferdighetskravet til kontakten (tilordnet i flyten) eller ferdighetskriteriene som er tilordnet køen, for å filtrere tilgjengelige agenter med ferdigheter og dynamiske ferdigheter som oppfyller disse kravene. / kriteriene helt. Deretter velges én agent for kontakten blant de filtrerte, basert på det konfigurerte rutingsmønsteret.

For beste tilgjengelige ruting kan ferdighetsferdigheter og dynamiske ferdighetsferdigheter også bruke vekter for å påvirke poengsummen som brukes for agentvalg. Vekter påvirker ikke rutingen for lengst tilgjengelig; det mønsteret bruker kun ferdigheter og dynamiske ferdigheter for å avgjøre om agenten er kvalifisert.

Lengst tilgjengelig

Det lengst tilgjengelige ferdighetsbaserte rutingsmønsteret ruter en kontakt til den agenten hvis ferdigheter tilfredsstiller kravene til kontaktferdigheter. / ferdighetskriteriene for køen fullstendig, og hvem som har vært tilgjengelig lengst siden de håndterte sin siste kontakt blant alle kvalifiserte agenter i den køen.

Dette rutingsmønsteret bidrar til å fordele arbeidet jevnt på tvers av agenter ved å tilordne interaksjoner til de som har vært tilgjengelige lengst, noe som forhindrer ubalanser i arbeidsmengden. Det bidrar til å opprettholde rettferdighet i arbeidsfordelingen, og sikrer at ingen agenter blir overbelastet mens andre forblir frie.

I eksemplet ovenfor er det fire agenter med ferdighets- og ikke-ferdighetsferdigheter med varierende ferdighetsverdier.

Tenk deg en kontakt som er satt i kø i en ferdighetsbasert kø med rutingsmønsteret «Lengst tilgjengelig»:

med ovennevnte ferdighetskrav tildelt via flyt, eller
med ovennevnte ferdighetskriterier konfigurert i den ferdighetsbaserte køen

I dette scenariet:

Kun agenter som fullt ut oppfyller kravene til kontaktferdigheter / Kriterier for køferdigheter vurderes for ruting. Bare agenter A1, A2 og A4 oppfyller kravene til kontaktferdigheter / kriterier for køferdigheter helt.

Agent A3 er ikke kvalifisert. Når det gjelder Ferdighetskriterier tilordnet kø, er A3 ikke engang tilknyttet køen.
Blant A1, A2 og A4 vil kontakten bli rutet til den agenten som har vært tilgjengelig lengst – A1 som har vært tilgjengelig i 10 minutter, lenger enn A2 eller A4.

Ved at A1 er tildelt kontakten, vil A1 ikke lenger være den lengst tilgjengelige agenten på tvers av alle mediekanaler.
Den neste kontakten med nøyaktig de samme ferdighetskravene ville bli rutet til den nest lengst tilgjengelige agenten – A2, og så videre.

Dette rutingsmønsteret støttes i følgende typer ferdighetsbaserte køer:

Ferdighetskrav tildelt i flyt
Ferdighetskriterier tilordnet kø

Best tilgjengelig

Det ferdighetsbaserte rutingmønsteret for beste tilgjengelige sikrer at kundeinteraksjoner rettes til den mest kvalifiserte agenten som er tilgjengelig. Dette mønsteret evaluerer ikke bare tilstedeværelsen av nødvendige ferdigheter blant agenter, men også ferdighetsnivåene for disse ferdighetene, og beregner en ferdighetspoengsum for å bestemme den mest kvalifiserte ("beste") agenten for hver kontakt.

Dette mønsteret filtrerer tilgjengelige agenter med ferdigheter som tilfredsstiller kravene til kontaktferdigheter / kriterier for køferdigheter helt. Deretter beregnes en poengsum for hver kvalifisert agent ved å bruke ferdighetsverdiene for alle ferdighetene som er nevnt i kravene til kontaktferdigheter. / kriterier for køferdigheter. Agenten med høyest ferdighetspoengsum regnes som den «beste» agenten for hver kontakt.

Effektivt sett summen av agentens ferdighetsverdier som samsvarer med kravene til kontaktferdigheter / Kriteriene for køferdigheter avgjør poengsummen.

Noen viktige punkter å forstå:

Normalt brukes den faktiske ferdighetsverdien i poengberegningen, fordi en høyere ferdighetspoengsum indikerer en sterkere match. Bortsett fra når et ferdighetskrav bruker mindre-enn-lik-til ( < =) betingelse, at agentens spesifikke ferdighetsverdi inverteres i poengsumberegningen, dvs. effective_skill_value = (10) minus (actual_skill_value). Dette gjøres for å sikre at en lavere poengsum indikerer en sterkere kamp.
Når flere kvalifiserte agenter har samme poengsum, velges den agenten som er tilgjengelig lengst blant dem
Kun ferdigheter tas med i beregningen av poengsum. Eventuelle boolske, tekst- eller enum-ferdigheter i kravene til kontaktferdigheter / Kriterier for køferdigheter tas ikke med i beregningen av poengsum.

I eksemplet ovenfor er det fire agenter med ferdighets- og ikke-ferdighetsferdigheter med varierende ferdighetsverdier.

Tenk deg en kontakt som er satt i kø i en ferdighetsbasert kø med rutingsmønsteret «Best tilgjengelig»:

med ovennevnte ferdighetskrav tildelt via flyt, eller
med ferdighetskriteriene ovenfor konfigurert i den ferdighetsbaserte køen.

I dette scenariet:

Kun agenter som fullt ut oppfyller kravene til kontaktferdigheter / Kriterier for køferdigheter vurderes for ruting. Bare agenter A1, A2 og A4 oppfyller kravene til kontaktferdigheter / kriterier for køferdigheter helt.

Agent A3 er ikke kvalifisert. Når det gjelder Ferdighetskriterier tilordnet kø, er A3 ikke engang tilknyttet køen.
Blant A1, A2 og A4 beregnes poengsummen av systemet basert på kravene til kontaktferdigheter. / kriterier for køferdigheter, der kun ferdighetsferdigheter vurderes.

Kun ferdighetene som er nevnt i kravene til kontaktferdigheter / Kriterier for køferdigheter tas i betraktning for poengsumberegning, selv om agenter kan ha ytterligere / andre ferdighetsferdigheter.

Legg også merke til inversjonen av ferdighetsverdien i poengsumberegningen når den er mindre enn lik ( < =) tilstanden brukes.
Kontakten blir rutet til A2 ettersom dette er den beste tilgjengelige agenten basert på poengsum. Hvis A2 ikke er tilgjengelig / Hvis den er opptatt, vil kontakten bli sendt til den nest beste tilgjengelige agenten med nest høyest poengsum, og så videre.

Vi har imidlertid to agenter – A1 og A4 med nest høyest poengsum. Kontakten blir rutet til den lengste tilgjengelige agenten mellom A1 og A4.

Dette rutingsmønsteret støttes i følgende typer ferdighetsbaserte køer:

Ferdighetskrav tildelt i flyt
Ferdighetskriterier tilordnet kø

Ikke-ferdighetsbasert ruting

Webex kontaktsenter støtter også en rekke ikke-ferdighetsbaserte rutingsmønstre som fokuserer på å distribuere innkommende kundeinteraksjoner uten å ta hensyn til agentenes spesifikke ferdigheter eller ekspertise. I motsetning til ferdighetsbaserte rutingsmønstre, tar ikke disse hensyn til agentferdigheter eller krever at kontakten eller køen definerer ferdighetskrav. / kriterier for ruting. De prioriterer heller faktorer som tilgjengelighet, arbeidsfordeling og forhåndsdefinerte sekvenser, noe som muliggjør effektiv håndtering av kontakter basert på driftslogikk snarere enn individuelle agenters kompetanser. Disse mønstrene er spesielt nyttige i miljøer der interaksjonene er relativt ensartede eller ikke krever spesialisert håndtering.

Lengst tilgjengelig

Rutingsmønsteret for lengst tilgjengelig ruter en kontakt til den agenten i køen som har vært tilgjengelig lengst siden håndteringen av den siste kontakten på tvers av alle agenter som er tilgjengelige og tilknyttet den køen.

Dette rutingsmønsteret sikrer rettferdig og balansert fordeling av arbeidsmengden ved å tilordne interaksjoner til agenter som har vært inaktive lengst. Ved å forhindre ubalanser i arbeidsmengden sikrer det at ingen agenter blir overbelastet mens andre forblir ledige. Denne tilnærmingen er spesielt effektiv i perioder med jevn kontaktflyt, og opprettholder jevnt engasjement på tvers av agentpoolen.

Agenter mister sine «lengst tilgjengelige» stillinger på tvers av alle kanaler når de blir tilbudt en kontakt av en hvilken som helst medietype. Dette betyr at etter at en agent håndterer en kontakt, vil den neste kontakten av en hvilken som helst medietype i køen bli tilordnet den nest lengste tilgjengelige agenten i den køen.

I eksemplet ovenfor er agent A1 den agenten som har vært tilgjengelig lengst (posisjon 1) – enten logget denne agenten inn først, eller så har den ikke vært tildelt en kontakt lenger enn noen annen agent.

Agentene A2 (posisjon 2) og A3 (posisjon 3) er også tilgjengelige, men de har enten logget inn eller har håndtert kontakter etter A1. Alle agenter er tilknyttet begge køene som har dette rutingsmønsteret.

Tenk deg følgende scenario:

Ved tidspunktet T0settes en talekontakt C1 i kø og rutes til den agenten som er tilgjengelig lengst, dvs. A1.

Ved at A1 er tildelt C1, er A1 ikke lenger den lengst tilgjengelige agenten på tvers av alle mediekanaler.
Ved tidspunktet T1settes en chatkontakt C2 i kø og rutes til den agenten som har lengst tilgjengelighet, som nå er A2.
Til slutt, ved tidspunkt T2, blir en annen talekontakt C3 satt i kø og rutet til A3.

A1 og A2 har nylig fått kontakt – for øyeblikket er det A3 som har ventet lengst.

På grunn av den svært distribuerte arkitekturen til Webex Contact Center, er det en liten mulighet for at én enkelt agent med lengst tilgjengelighet kan rutes flere kontakter når disse kontaktene er i kø i samme kø samtidig.

Dette rutingsmønsteret støttes i følgende typer ikke-ferdighetsbaserte køer:

Teamoppgave
Agenttildeling

Sirkulær

Det sirkulære rutingsmønsteret fordeler innkommende kontakter blant en gruppe tilgjengelige agenter i en round-robin-rekkefølge. Når en kontakt settes i kø, tilordner systemet den til den neste tilgjengelige agenten i køen basert på en forhåndsbestemt sekvens.

Prosessen starter med agenter i en konfigurert rekkefølge. Den første innkommende kontakten tilordnes den første tilgjengelige agenten i den sekvensen. For påfølgende kontakter velger systemet den neste tilgjengelige agenten, og fortsetter der det slapp i den definerte kørekkefølgen. Dette mønsteret gjentas, og går gjennom agentene, men starter alltid etter den sist valgte agentens posisjon.

Denne tilnærmingen er effektiv for å fordele kontakter rettferdig og jevnt mellom agenter. Det bidrar til å sikre at ingen enkeltagent blir overveldet av kontakter, og at alle agenter har like muligheter til å håndtere interaksjoner konsekvent. Det sirkulære rutingsmønsteret tar imidlertid ikke hensyn til gjeldende arbeidsmengde eller andre faktorer som kan påvirke en agents evne til å håndtere en bestemt kontakt.

I eksemplet ovenfor er agenter konfigurert i en sirkulær kø i følgende rekkefølge: A3 → A4 → A5 → A6 → A1 → A2.

Tenk deg følgende scenario:

Den første kontakten (C1) settes i kø, og den rutes til agent A3.

Pekeren oppdateres til neste agent i konfigurert rekkefølge, dvs. A4.
Når den andre kontakten (C2) er satt i kø, begynner systemet å finne tilgjengelige agenter fra A4, dvs. A4 → A5 → A6 → A1 → A2 → A3.

Imidlertid er A4 og A5 utilgjengelige (enten er de ikke engang logget inn, inaktive, eller helt opptatt med andre kontakter av denne medietypen), så C2 blir rutet til neste tilgjengelige agent – A6. Pekeren oppdateres til neste agent i konfigurert rekkefølge, dvs. A1.
På samme måte blir den tredje kontakten (C3) rutet til A1, den fjerde kontakten (C4) rutet til A2. Pekeren er på A3 igjen.

Denne logikken fortsetter, og kontaktene fordeles blant tilgjengelige agenter i det «sirkulære» / "round-robin"-mønster.

Hvis det er parkerte kontakter i køen, vil scenariet med agentoverskudd matche den neste agenten som blir tilgjengelig på denne medietypen med den eldste kontakten med høyest prioritet blant dem.

Dette verken vurderer eller påvirker den eksisterende posisjonsverdien i denne køen, som bare oppdateres når ruting av overskytende kontakter samsvarer med en agent.

Dette rutingsmønsteret støttes i følgende typer ikke-ferdighetsbaserte køer:

Agenttildeling

Ovenfra og ned

Ovenfra-og-ned-rutingsmønsteret fordeler innkommende kontakter blant en gruppe tilgjengelige og ordnede agenter i en sekvensiell rekkefølge. Når en kontakt settes i kø, går systemet alltid gjennom den ordnede listen over agenter fra begynnelsen og matcher kontakten med den første tilgjengelige agenten (som har en ledig kanal av kontaktens medietype) i den sekvensen.

Dette skjer for hver kontakt som er satt i kø. Kontakten forsøkes alltid å bli matchet, alltid fra toppen (først konfigurerte agent) og nedover listen til en matchende agent blir funnet.

I motsetning til sirkulært rutingsmønster, finnes det ingen "peker" som dynamisk endrer startpunktet basert på den sist valgte agentens posisjon.

Denne tilnærmingen er effektiv for å fordele kontakter blant agenter som er sortert basert på en viss skjevhet / preferanse som bestemt av administratoren. Det bidrar til å sikre at agentene på toppen alltid foretrekkes til å håndtere kontakter fremfor agenter under dem. Imidlertid tar ikke ovenfra-og-ned-rutingsmønsteret hensyn til gjeldende arbeidsmengde eller andre faktorer som kan påvirke en agents evne til å håndtere en bestemt kontakt.

I eksemplet ovenfor er agenter konfigurert i en ovenfra-og-ned-kø i følgende rekkefølge: A3 → A4 → A5 → A6 → A1 → A2.

Dette betyr at administratoren ønsker at alle kontakter skal rutes til den første agenten (A3) hvis tilgjengelig, ellers den neste agenten (A4) hvis tilgjengelig og så videre, i konfigurert rekkefølge.

Tenk deg følgende scenario:

Den første kontakten (C1) settes i kø, og den blir rutet til agent A3, siden A3 er øverst i ordren.
Når den andre kontakten (C2) er satt i kø, forsøkes rutingen igjen fra toppen av rekkefølgen (alltid startende med A3).

Hvis A3 har mer kanalkapasitet for denne medietypen, blir C2 også rutet til A3. Men hvis A3 er fullt opptatt på denne medietypen, fortsetter rutingen nedover listen til A4.
Imidlertid er A4 og A5 utilgjengelige (de er enten ikke engang logget inn, inaktive, eller helt opptatt med andre kontakter av denne medietypen), så C2 blir rutet til neste tilgjengelige agent i ovenfra-og-ned-rekkefølgen – A6
På samme måte forsøkes den tredje kontakten (C3) å bli rutet fra A3 og ned mot bunnen. Den første matchende agenten ville være A1.

Denne logikken fortsetter helt til en kontakt ikke finner noen tilgjengelige agenter før nederst i bestillingen, i så fall parkeres den i køen.

Dette rutingsmønsteret støttes i følgende typer ikke-ferdighetsbaserte køer:

Agenttildeling

Agentbasert ruting

Agentbasert ruting er en funksjon som ruter eller setter en kontakt direkte i kø til en spesifisert ("foretrukket") agent. Et agentoppslag med agentens e-postadresse eller agentens ID ruter en kontakt til den foretrukne agenten. Aktiviteten «Kø til agent» i flyten bidrar til å oppnå agentbasert ruting. Hvis du vil ha mer informasjon, kan du se aktiviteten Kø til agent.

En kontakt kan ha en tilordning til én eller flere foretrukne agenter, som vanligvis kan administreres i et eksternt program utenfor Webex kontaktsenter. Oppslaget til en foretrukket agent for en kontakt gjøres via aktiviteten HTTP Request, som henter tilordningen fra et eksternt program. For å rute eller parkere kontakten med den foretrukne agenten, konfigurerer du aktiviteten «Sett i kø til agent» ved hjelp av agentens Webex-kontaktsenter-ID eller e-postadresse. Kontakten kan også parkeres mot en foretrukket agent hvis den foretrukne agenten ikke er umiddelbart tilgjengelig.

Agentbasert ruting er nyttig i følgende scenarier:

Foretrukket agentruting: Kunden kan tilordne kontakter til dedikerte agenter eller kundeansvarlige. I slike scenarier ruter agentbasert ruting kontaktene direkte til den foretrukne agenten.
Siste agentruting: Når en kontakt ringer tilbake til kontaktsenteret flere ganger for å samhandle med en agent, kan agentbasert ruting rute kontakten til den siste agenten som håndterte den kontakten.

I begge brukstilfellene lagres detaljene om kontakten og agenttilordningen utenfor Webex kontaktsenter.

Kø- og rutingfunksjoner i Flow

I Webex kontaktsenter kan et bredt spekter av rutings-, kø- og samtalekontrollfunksjoner orkestreres gjennom flyter.

En rekke flytaktiviteter og hendelseshåndterere som finnes i Flow Designer, kan plasseres i flyten for å effektivt administrere livssyklusen til innkommende og utgående kontakter.

Hvis du vil ha mer informasjon om hvordan du konfigurerer og bruker flyter, kan du se Bygg og administrer flyter med Flow Designer.

Køaktiviteter

Køkontakt

Aktiviteten «Sett kontakt i kø» gir muligheten til å plassere en kontakt i en aktiv innkommende kø fra organisasjonen, slik at den kan matches og rutes til riktig agent i den køen.

Følgende aspekter ved køarbeid kan håndteres gjennom denne aktiviteten:

Prioritet – Tilordner en hierarkisk viktighet fra 1 (høyest) til 10 (lavest, standard) til kontakten som er satt i kø.
Ferdighetskrav – Angi ferdighetskriteriene som må oppfylles av agenter i en ferdighetsbasert kø for å bli ansett som kvalifisert for å rute kontakten.
Ferdighetsavslappinger – Justering, endring eller fjerning av tidligere fastsatte ferdighetskrav etter en viss tid for å forbedre sjansene for å finne en agent.
Sjekk agenttilgjengelighet – Lar systemet umiddelbart utvide seg gjennom alle samtaledistribusjonsgrupper der det ikke finnes tilgjengelige agenter, for å unngå ventetid.

Se Rutingfor mer informasjon om hvordan prioritet, ferdighetskonfigurasjon og agenttilgjengelighet spiller en rolle i ruting av kontakter.

Når aktiviteten «Sett kontakt i kø» har satt kontakten i kø,

Hvis en samsvarende agent allerede er tilgjengelig, prøver systemet å rute kontakten til en agent.
Dette avbryter utførelse av Hovedflyt og ytterligere hendelser kan utløse de respektive Hendelsesflytene, hvis konfigurert.
Hvis ingen matchende agent finnes, parkeres kontakten i køen og venter på at en matchende agent skal bli tilgjengelig.
Flytutførelsen fortsetter deretter med aktivitetene som er knyttet til etter køkontaktaktiviteten, som gir muligheten til å:
- Spill av forhåndskonfigurert musikk til kunden som venter i køen – ved å legge ved en PlayMusic -aktivitet.
- Registrer en tilbakeringing basert på kundens forespørsel – ved å legge ved en Callback -aktivitet.
- Sett i kø på nytt, dvs. fjern kontakten fra gjeldende kø og legg den til i en ny kø – ved å legge til en annen Queue Contact - eller Queue to Agent -aktivitet.

Når en matchende agent blir tilgjengelig, prøver systemet å rute kontakten til agenten.

Når dette lykkes, avbryter dette utførelsen av Hovedflyt og ytterligere hendelser kan utløse de respektive Hendelsesflytene, hvis konfigurert.

Køkontakt-aktiviteten fungerer når:

Kontakten er ikke tilordnet og klar til å bli rutet til en agent.
Kø-, ferdighets- og andre flytkonfigurasjoner er riktig konfigurert.
Kontakten holder seg innenfor den tillatte grensen på 25 inngangspunkter og køoverganger.
Kontakten holder seg innenfor den tillatte grensen på 20 vellykkede rutingsforsøk.

Konfigurer feilhåndteringsbanen for å håndtere kontakter som krever alternativ ruting eller ekstra håndtering på en elegant måte.

I slike tilfeller resulterer aktiviteten i en feil, og flytutførelsen flyttes til banen Feilhåndtering.

Funksjoner som ferdighetskrav, ferdighetsavlastninger og sjekk agenttilgjengelighet er bare tilgjengelige i køkontaktaktiviteten når køer med teamtildeling er valgt.

Hvis du vil ha mer informasjon om aktivitetsinnstillinger, bruk og utdatavariabler, kan du se Bygge og administrere flyter > Køkontakt.

Kø til agent

Aktiviteten «Kø til agent» gir muligheten til å sette kontakten i kø direkte til en foretrukket agent ved å slå opp deres unike agent-ID eller e-postadresse i Webex kontaktsenter.

Følgende aspekter ved køarbeid kan håndteres gjennom denne aktiviteten:

Prioritet - Tildeling higher/lower betydning for kontaktene som er i kø mot den samme agenten.
Rapporteringskø – Identifiser køen som skal brukes til konfigurasjon, for eksempel opptak og standard musikk-i-kø, og rapporteringsformål for kontakten.
Gjenopprettingskø – Identifiser køen som skal brukes som reserve når kontakten ikke kunne rutes til den angitte foretrukne agenten.

Når aktiviteten «Sett i kø til agent» har satt kontakten i kø,

Hvis agenten allerede er tilgjengelig, blir kontakten sendt til agenten.
Dette avbryter utførelse av Hovedflyt og ytterligere hendelser kan utløse de respektive Hendelsesflytene, hvis konfigurert.
Hvis agenten er tilgjengelig, men velger å avslå, ikke svarer eller ikke mottar kontakten, flyttes vedkommende til den angitte gjenopprettingskøen.
I gjenopprettingskøen vil kontakten bli rutet til den lengst tilgjengelige agenten, uten støtte for ferdigheter.
Hvis agenten ikke er tilgjengelig og alternativet «Park Contact If Agent Unavailable» er valgt , parkeres kontakten og venter på at agenten skal bli tilgjengelig.
Flytutførelsen fortsetter deretter med aktivitetene som er knyttet til etter «Kø til agent»-aktiviteten, noe som gir muligheten til å:
- Spill av forhåndskonfigurert musikk til kunden som venter i køen – ved å legge ved en PlayMusic -aktivitet.
- Callback aktivitet.
- Sett i kø på nytt, dvs. fjern kontakten fra gjeldende kø og legg den til i en ny kø – ved å legge til en annen Queue to Agent - eller Queue Contact -aktivitet.
Når agenten blir tilgjengelig, prøver systemet å rute kontakten til agenten.
Dette avbryter utførelse av Hovedflyt og ytterligere hendelser kan utløse de respektive Hendelsesflytene, hvis konfigurert.
Hvis agenten ikke er tilgjengelig og alternativet «Park Contact If Agent Unavailable» ikke er valgt , mislykkes køen.

Aktiviteten «Kø til agent» fungerer når:

Kontakten er ikke tilordnet og klar til å bli rutet til en agent.
Den foretrukne agent-ID-en eller e-postadressen er gyldig.
Rapporteringskøen og gjenopprettingskøen er riktig konfigurert.
Den foretrukne agenten er logget inn, tilgjengelig og klar til å håndtere kontakten.

Konfigurer en gjenopprettingskø for å sikre at kontakten rutes problemfritt når den foretrukne agenten ikke er tilgjengelig.

I slike tilfeller resulterer aktiviteten i en feil, og flytutførelsen flyttes til banen Feilhåndtering.

Hvis du vil ha mer informasjon om aktivitetsinnstillinger, bruk og utdatavariabler, kan du se Bygge og administrere flyter > Kø til agent.

Eskaler samtaledistribusjonsgruppe

Aktiviteten Eskaler samtaledistribusjonsgruppe støttes bare for køer med teamtildeling, og gir muligheten til å oppdatere samtaledistribusjonsgruppen for kontakten umiddelbart, i stedet for å vente på at den automatiske utvidelsesoppdateringen skal skje for neste gruppe etter den konfigurerte ventetiden. Dette gjør at kontakten raskt kan rutes til alle kvalifiserte agenter i køen.

Ved å bruke aktiviteten Eskaler samtaledistribusjonsgruppe kan kontakten eskaleres til:

Neste gruppe– Utvider settet med team til å inkludere de som er lagt til i distribusjonsgruppen for neste samtale.
Siste gruppe– Utvider settet med team til å inkludere alle teamene som er tilordnet på tvers av alle samtaledistribusjonsgrupper som er konfigurert for køen.

Aktiviteten Eskaler samtaledistribusjonsgruppe fungerer når:

Kontakten er allerede satt i kø og klar for eskalering.
Kontakten er plassert i en kø som bruker anropsdistribusjonsgrupper.

For køer som bruker standard ruting, fortsett å distribuere kontakter gjennom køens konfigurerte rutingsvirkemåte.

I slike tilfeller resulterer aktiviteten i en feil, og flytutførelsen flyttes til banen Feilhåndtering.

Tenk deg et eksempelscenario der en kontakt blir satt i en kø med tre samtaledistribusjonsgrupper, som hver oppdateres etter 30 sekunder.

Ingen agenter er tilgjengelige i teamdelen av CDG 1 og CDG 2, og en agent er tilgjengelig i TEAM 3 som tilhører distribusjonsgruppen for siste anrop.

Når aktiviteten Eskaler samtaledistribusjonsgruppe ikke brukes i flyten, resulterer det i lang ventetid, som illustrert nedenfor:

Ventetiden kan reduseres ved å bruke aktiviteten Eskaler samtaledistribusjonsgruppe som følger:

Basert på om alternativet Neste gruppe eller Siste gruppe er valgt, reduseres ventetiden for kontakten betraktelig, som illustrert nedenfor:

Hvis du vil ha mer informasjon om aktivitetsinnstillinger, bruk og utdatavariabler, kan du se Bygge og administrere flyter > Eskaler samtaledistribusjonsgruppe.

Køinformasjonsaktiviteter

Få køinformasjon

Aktiviteten Hent køinformasjon gir muligheten til å hente køinformasjon i sanntid for en gitt kontakt, for eksempel:

Kontaktens nåværende posisjon i køen (PIQ), eller den potensielle posisjonen hvis den ikke er i kø ennå.
Den estimerte ventetiden (EWT) eller varigheten en oppgave er beregnet å vente i køen før den blir besvart.
Antall agenter som er logget på eller tilgjengelige i kontaktens gjeldende samtaledistribusjonsgruppe.
Antall agenter som er logget på eller tilgjengelige på tvers av alle samtaledistribusjonsgrupper for den valgte køen.
Hvor lenge den eldste kontakten i køen har ventet.

Disse detaljene gjøres tilgjengelige i flytutførelsen som aktivitetsutdatavariabler.

Hvis du vil ha mer informasjon om aktivitetsbruken, den detaljerte definisjonen og beregningsmetoden for hver kødetalj, kan du se Bygge og administrere flyter > Hent køinformasjon.

Noen av måtene å bruke køinformasjonen på er:

Å kunngjøre kontaktens plassering i køen og estimert ventetid til kunden, mens de venter på å bli rutet.
For å avgjøre om en tilbakeringing kan registreres for kunden, hvis den estimerte ventetiden er for lang.
For å eskalere kontakten til neste samtaledistribusjonsgruppe (CDG), hvis ingen agenter er tilgjengelige i team som er tilordnet gjeldende CDG.

Aktiviteten Hent køinformasjon fungerer når den valgte variabelen omdannes til en gyldig kø.

Konfigurer feilhåndteringsbanen for å håndtere tilfeller der den valgte variabelen trenger validering eller ikke løses til en tilgjengelig kø på en elegant måte.

I følgende tilfeller er sanntidskøinformasjon for gjeldende samtaledistribusjonsgruppe ikke aktuelt:

Kontakten er ikke (ennå) i kø når aktiviteten Hent køinformasjon utføres.
Kontakten står i kø i en kø som ikke støtter konseptet med samtaledistribusjonsgrupper.

I disse tilfellene indikerer verdien -1 i disse utdatafeltene at denne informasjonen ikke er relevant.

Tenk deg et eksempelscenario der kunden skal informeres om en lang EWT i køen, etter hvert 15. sekund brukt i køen.

Dette kan oppnås ved å bruke aktiviteten Hent køinformasjon i flyten som følger:

Avansert køinformasjon

Aktiviteten Avansert køinformasjon gir muligheten til å hente køinformasjon i sanntid for en gitt kontakt, i tillegg til å ta hensyn til kontaktens ferdighetskriterier, for eksempel:

Kontaktens nåværende posisjon i køen (PIQ), eller den potensielle posisjonen hvis den ikke er i kø ennå.
Antall agenter som er logget på eller tilgjengelige i kontaktens gjeldende samtaledistribusjonsgruppe, som samsvarer med de gitte ferdighetskriteriene.
Antall agenter som er logget på eller tilgjengelige på tvers av alle samtaledistribusjonsgrupper for den valgte køen, som samsvarer med de gitte ferdighetskriteriene.
Den gjeldende samtaledistribusjonsgruppen der kontakten er parkert i en gitt kø.
Det totale antallet anropsdistribusjonsgrupper i en gitt kø.

Disse detaljene gjøres tilgjengelige i flytutførelsen som aktivitetsutdatavariabler.

Hvis du vil ha mer informasjon om aktivitetsbruken, den detaljerte definisjonen og beregningsmetoden for hver kødetalj, kan du se Bygge og administrere flyter > Avansert køinfo.

Noen av måtene å bruke den avanserte køinformasjonen på er:

Å annonsere kontaktens plassering i køen til kunden, mens de venter på å bli rutet.
For å eskalere kontakten til neste samtaledistribusjonsgruppe, hvis ingen agenter som samsvarer med ferdighetskriteriene er tilgjengelige i team som er tilordnet gjeldende samtaledistribusjonsgruppe.
For å avgjøre om en tilbakeringing kan registreres for kunden, hvis ingen agenter som samsvarer med ferdighetskriteriene er logget på tvers av alle samtaledistribusjonsgruppene.

Aktiviteten Avansert køinfo fungerer når:

Køinformasjonen blir forespurt for køer der ferdighetskrav er konfigurert i flyten, i stedet for som ferdighetskriterier på kønivå.
Hvis kontakten allerede er i kø, blir informasjonen forespurt for den samme køen der kontakten for øyeblikket er i kø.
Kontakten er plassert i en kø, ikke direkte hos en foretrukket agent.

Konfigurer feilhåndteringsbanen for å administrere forespørsler som ikke oppfyller disse kravene.

I slike tilfeller resulterer aktiviteten i en feil, og flytutførelsen flyttes til banen Feilhåndtering.

Tenk deg et eksempelscenario der kunden skal informeres om å motta en tilbakeringing, gitt at ingen agenter som oppfyller ferdighetskriteriene er tilgjengelige.

Dette kan oppnås ved å bruke aktiviteten Avansert køinformasjon i flyten som følger:

Aktiviteter for samtalekontroll

Angi nummerpresentasjon

Aktiviteten Angi nummerpresentasjon brukes til å definere nummerpresentasjonen som skal vises under en samtale. Aktiviteten Angi nummerpresentasjon må kun brukes på hendelsesflyter før oppringing som en terminalaktivitet som markerer slutten på hendelsesflyten.

Aktiviteten Angi nummerpresentasjon lar deg konfigurere den nødvendige automatiske nummeridentifikasjonen (ANI) basert på identifikasjonstjenesten for oppringte nummer (DNIS), operasjonstype eller deltakertype.

Hvis du vil ha mer informasjon om aktivitetsinnstillinger, bruk og utdatavariabler, kan du se Bygge og administrere flyter > Angi nummerpresentasjon.

Opptakskontroll

Aktiviteten Opptakskontroll er utformet for å brukes sammen med en menyaktivitet for å innhente samtykke fra innringeren til opptak. Dette sikrer samsvar med forskrifter eller retningslinjer som krever eksplisitt samtykke før opptaket starter, og integrerer dette trinnet sømløst i arbeidsflyten.

Meny-IVR-aktiviteten må registrere brukerens samtykke i en boolsk variabel som vil bli tilordnet som input til Opptakskontroll-aktiviteten. Hvis kunden må rapportere brukerens samtykke i en samtykkerapport, bør samtykkeverdien lagres i en rapporterbar global variabel. Alternativt kan en lokal variabel brukes hvis rapportering ikke er nødvendig. Denne tilnærmingen gir leietakere og kunder økt fleksibilitet i å håndtere og utnytte variabler effektivt.

Når denne aktiviteten legges til i flyten, prioriteres brukerens samtykke over konfigurasjonsinnstillingene på leietakernivå, kønivå eller nivå for opptaksplan.

Prioriteringsrekkefølgen er som følger:

Hvis brukersamtykket er Ja i flyten, blir samtalen tatt opp, uavhengig av opptakskonfigurasjonen som er angitt på leietaker-, kø- eller opptaksplannivå.
Hvis brukeren ikke samtykker som svar på aktiviteten, blir ikke samtalen tatt opp, uavhengig av opptakskonfigurasjonen som er angitt på leietaker-, kø- eller opptaksplannivå.
Hvis aktiviteten Opptakskontroll ikke er konfigurert i flyten, men en konfigurasjon er satt til Ja på et av de andre nivåene, for eksempel leietaker, kø eller opptaksplan, blir samtalen tatt opp.
Hvis aktiviteten Opptakskontroll ikke er konfigurert i flyten, og en konfigurasjon er satt til Nei på alle nivåer, for eksempel leietaker, kø og opptaksplan, blir ikke samtalen tatt opp.

Denne opptakskontrollen kan illustreres som følger:

I tillegg forblir opptakskonfigurasjoner som Fortsett ved overføring, Pause Gjenoppta aktivert, Pausevarighet og andre gjeldende i henhold til det eksisterende hierarkiet, inkludert nivåer for leietaker, kø eller opptaksplan.

Hvis du vil ha mer informasjon om aktivitetsinnstillinger, bruk og utdatavariabler, kan du se Bygge og administrere flyter > Opptakskontroll.

Blind overføring

Blind overføring er en prosess der en kontakt effektivt rutes til et eksternt oppringingsnummer (DN) gjennom IVR-systemet, noe som eliminerer behovet for agentinvolvering.

Aktiviteten Blind overføring brukes når en samtale må overføres til et eksternt eller tredjeparts DN. Dette er en terminalaktivitet, så flyten avsluttes når overføringen er utført.

Blind overføringsaktivitet støttes ikke når flyten utføres for konsultasjon.

Hvis du vil ha mer informasjon om aktivitetsinnstillinger, bruk og utdatavariabler, kan du se Bygge og administrere flyter > Blind overføring.

Brooverføring

Aktiviteten Brooverføring gjør det mulig å overføre en kontakt midlertidig til et eksternt mål mens flyten beholder kontrollen over samtalen. Det eksterne målet kan være en ekstern bro eller en IVR-tjeneste (interaktiv talerespons).

Når den eksterne destinasjonen avslutter samtalen, fortsetter samtaleflyten videre etter behov, som å sette den i kø hos en agent.

Aktiviteten Bridge Transfer fjerner køen til en kontakt mens den overføres til et tredjeparts IVR-system eller et automatisk samtalefordelingssystem (ACD). Hvis kontakten ikke håndteres av tredjepartssystemet, kan den settes tilbake i den opprinnelige køen, slik at kontakten forblir i arbeidsflyten for riktig håndtering.

La oss for eksempel anta at et kontaktsenter har Webex Contact Center-agentressurser og agentressurser på et eksternt kundesenter eller en privat sentral (PBX). Kunden ønsker å sette en samtale i kø mot en kø av Webex Contact Center-agenter i en kort periode (for eksempel 60 sekunder). Hvis ingen agent er tilgjengelig i løpet av denne perioden, kan samtalen deretter overføres via en bro (med en implisitt utkøing) til det eksterne kundesenteret for håndtering av kontakten.

Brobasert overføringsaktivitet støttes ikke i utgående anropsflyter og hendelsesflyter.
Kontakter som allerede er tilordnet en agent, støttes ikke for Bridge Transfer gjennom flyten.

Hvis du vil ha mer informasjon om aktivitetsinnstillinger, bruk og utdatavariabler, kan du se Bygge og administrere flyter > Brooverføring.

Koble fra kontakten

Aktiviteten Koble fra kontakt gir muligheten til å koble fra eller avslutte en aktiv kontakt direkte fra flyten.

Dette er en terminalaktivitet som er knyttet til flyten, og kan være nyttig for å avslutte kontakter uten at agenten må involvere seg. Dette er egnet for feilsøkingsflyter eller etter at en tilbakeringing er registrert for kunden.

Basert på konfigurasjonen utløses undersøkelsen eller tilbakemeldingen etter samtalen når kontakten avsluttes gjennom denne aktiviteten.

Hvis du vil ha mer informasjon om aktivitetsinnstillinger, bruk og utdatavariabler, kan du se Bygge og administrere flyter > Koble fra kontakten.

Angi kontaktprioritet

Aktiviteten Angi kontaktprioritet muliggjør effektiv administrasjon av kontaktprioritet i flyten ved å tillate tildeling av spesifikke prioritetsnivåer til kontakter. Dette gjør at visse kontakter kan gis høyere eller lavere viktighet, noe som sikrer at de blir rutet riktig i forhold til andre ventende kontakter når agenter blir tilgjengelige. Denne fleksibiliteten gir presis kontroll over kontaktprioritering gjennom hele flyten.

Prioriteten etableres ved å tilordne et hierarkisk viktighetsnivå fra 1 (høyest) til 9 (lavest). Kontakter med høyest prioritet blir rutet før de med lavere prioritet. Når flere kontakter deler samme prioritetsnivå, blir kontakten som har ventet lengst sendt først til den neste tilgjengelige og kvalifiserte agenten. Dette systemet sikrer at kontakter med høyere prioritet får rask oppmerksomhet, samtidig som det opprettholdes rettferdighet blant kontakter med lik prioritet basert på ventetid.

Aktiviteten Angi kontaktprioritet kan plasseres hvor som helst i hovedflyten eller hendelsesflyten.
Hvis aktiviteten Angi kontaktprioritet konfigureres før en køaktivitet (for eksempel Sett kontakt i kø eller Sett agent i kø), kan prioritetsinnstillingen overstyres av en hvilken som helst prioritet som eksplisitt konfigureres i de påfølgende køaktivitetene. Hvis den følgende køaktiviteten ikke angir en prioritet, vil kontaktprioriteten som ble angitt av den tidligere aktiviteten Angi kontaktprioritet, bli brukt.
Hvis aktiviteten Angi kontaktprioritet derimot konfigureres etter en køaktivitet (for eksempel Sett kontakt i kø eller Sett agent i kø), vil den overstyre prioritetsinnstillingen som er konfigurert av den foregående køaktiviteten.
Aktiviteten «Angi kontaktprioritet» støttes for øyeblikket ikke for kontakter fra utgående oppringing og kampanjer.

Hvis du vil ha mer informasjon om aktivitetsinnstillinger, bruk og utdatavariabler, kan du se Bygge og administrere flyter > Angi kontaktprioritet.

Tilbakeringingsaktiviteter

Tilbakeringing

En tilbakeringingsaktivitet lar innringere be om en tilbakeringing i stedet for å vente på vent, noe som forbedrer kundetilfredsheten betydelig ved å redusere ventetider og minimere antall avbrutt kunder. Når tilbakeringingsaktiviteten er aktivert, oppretter den en oppgave i en kø, slik at en tilgjengelig agent kan ringe tilbake til kunden.

Flytdesigneren kan konfigurere aktiviteten til enten å beholde kontakten i den opprinnelige køen, der samtalen oppsto, eller tilordne den til en annen kø basert på preferanser. Hvis tilbakeringingen forblir i den opprinnelige køen, beholder kontakten sin posisjon, ferdigheter, prioritet og kontekstuelle data, noe som gir sømløs tildeling til neste tilgjengelige agent. Hvis en annen kø velges, flyttes kontakten imidlertid til slutten av den valgte køen uten ferdigheter og med standardprioritet.

Aktiviteten lar også kunder be om tilbakeringinger fra sine foretrukne agenter, noe som gir et personlig preg til opplevelsen og forbedrer kundetilfredsheten. Dette kan oppnås når tilbakeringingsaktiviteten følger en QueueToAgent-aktivitet i flyten. I tillegg tilbyr tilbakeringingsaktiviteten en valgfri konfigurasjon for å tilpasse den automatiske nummeridentifikasjonen (ANI) som brukes under tilbakeringingsprosessen. Denne tilpasningen bidrar til merkevarekonsistens og reduserer sannsynligheten for avvisning av anrop ved å sikre en gjenkjennelig nummerpresentasjon.

Flytdesigneren har muligheten til å inkludere en CallbackFailed-hendelse i hendelsesflyten. Denne hendelsen utløses når et tilbakeringingsforsøk mislykkes, slik at flytdesigneren kan implementere nye forsøk med bestemte intervaller. Forsinkelsen eller intervallet mellom nye forsøk kan konfigureres ved hjelp av Vent-aktiviteten, med et minimumsintervall for nye forsøk på 10 sekunder og maksimalt 72 timer. Systemet støtter opptil 10 nye forsøk over en maksimal periode på 14 dager ved bruk av Vent-aktiviteten.

Hvis du vil ha mer informasjon om aktivitetsinnstillinger, bruk og utdatavariabler, kan du se Bygge og administrere flyter > Tilbakeringing.

Planlegg tilbakeringing

Aktiviteten Planlagt tilbakeringing gir flyten muligheten til å tilby kundene bekvemmeligheten av å be om en tilbakeringing på en bestemt fremtidig dato og klokkeslett – noe som eliminerer behovet for umiddelbar tilkobling til en agent. Denne funksjonen forbedrer kundeopplevelsen ved å la dem velge et praktisk tilbakeringingsvindu, og dermed minimere opplevd ventetid og redusere antallet avbrutte samtaler.

Flyten må fange opp innringerens inndata, for eksempel foretrukket dato og klokkeslett, via DTMF-ledetekster og sende dem til aktiviteten etter at de nødvendige inndatavalideringene er utført.

Før du starter, må du sørge for at Standard inngangspunkt for tilbakeringing er konfigurert under Kanalinnstillinger i Kontrollhuben. Hvis du vil ha mer informasjon, kan du se Konfigurere et tilbakeringingspunkt.

Tilbakeringingen kan planlegges ved hjelp av en hvilken som helst telefonkø – enten innkommende eller utgående. For best resultat anbefales det å legge til en Frakoblingsaktivitet umiddelbart etter den planlagte tilbakeringingsaktiviteten for å sikre at den gjeldende samtalen avsluttes riktig når tilbakeringingen er planlagt. Hvis du vil ha mer informasjon om planlegging av IVR-tilbakeringinger, kan du se Planlegge IVR-tilbakeringinger.

Når tilbakeringingen utløses på den forespurte fremtidige datoen og klokkeslettet, opprettes en ny samtale eller interaksjon. Denne nye interaksjonen vil følge standardflyten som er knyttet til standard inngangspunkt for tilbakeringing. Hvis tilbakeringingsforsøket mislykkes, kan flyten automatisk prøve å kalle på nytt ved hjelp av hendelsesbehandleren CallbackFailed hvis den er konfigurert i den flyten.

Følgende valideringer av inndata bør vurderes før inndata sendes til aktiviteten:

Datovalg – Du kan velge hvilken som helst dato fra i dag og opptil 31 dager frem i tid. Datoen må være i dette formatet: ÅÅÅÅ-MM-DD (for eksempel 2025-07-18).
Start- og sluttid for tidsvindu – Tidspunktet du velger må starte minst 30 minutter fra nå og kan vare alt fra 30 minutter til 8 timer. Vennligst bruk 24-timers tidsformat (som 14:30:00).
Tidssone – Du må angi en gyldig tidssone i IANA-format (som America/New_York) slik at vi kan ringe deg til riktig tid.

En referanseimplementering gis i form av en underflytmal for å demonstrere DTMF-ledetekstene og grunnleggende valideringer som brukes sammen med aktiviteten. Hvis du vil ha mer informasjon, kan du se Mal for planlagt tilbakeringingsdelflyt.

Analyse av samtalefremdrift

Aktiviteten Samtalefremdriftsanalyse (CPA) muliggjør deteksjon av automatiserte telefonsvarer og levende menneskestemmer på tilbakeringingsanrop.

Når et tilbakeringingsforsøk støter på en telefonsvarerdeteksjon (AMD) eller talemelding, identifiserer systemet anropet som mislykket. Resultatet av telefonsvarerdeteksjon (AMD) registreres i årsak-utdatavariabelen til hendelsesbehandleren CallbackFailed. Basert på denne utdatavariabelen kan flytdesigneren konfigurere tilbakeringingsforsøk.

For tilbakeringing av tjenesten kan CallProgressAnalysis plasseres på et punkt etter tilbakeringingsaktiviteten i hovedflyten. For planlagt tilbakeringing eller personlig planlagt tilbakeringing kan den plasseres etter NyTelefonkontakt i hovedflyten.
I hendelsesflyten støttes den bare i CallbackFailed-hendelsesbehandleren.
Hvis en kundeundersøkelse etter samtale (tilbakemeldingsaktivitet) er konfigurert i flyten, vil den ikke bli startet hvis samtalen besvares av en AMD eller telefonsvarer. Dette forhindrer unødvendige undersøkelser.

Hvis du vil ha mer informasjon om aktivitetsinnstillinger, bruk og utdatavariabler, kan du se Bygge og administrere flyter > Analyse av samtalefremdrift.

Kø

Oversikt

I Webex Contact Center fungerer en kø som et oppbevaringsområde for innkommende interaksjoner som telefoni, chat, e-post eller sosiale kanaler. Kontakter lagres i køer til de automatisk distribueres til agenter, eller agenter som henter dem manuelt for håndtering. I tillegg støtter de funksjoner som ferdighetsbasert ruting, prioritetsadministrasjon og rettferdig fordeling av arbeidsbelastninger.

Ledere kan bruke køer til å observere ulike arbeidslinjer og forbedre hvordan oppgaver håndteres i kontaktsenteret.

Noen av de viktigste fordelene ved å bruke køer effektivt er:

Bedre kundeopplevelse: Administrer ventetider og la kundene vite at de står i kø for å bli hjulpet.
Økt effektivitet: Sørg for at samtaler håndteres på en ryddig måte, og reduser kaos og dårlig ledelse.
Rettferdig fordeling av kontakter: Fordel anrop jevnt mellom agenter for å unngå overbelastning av én enkelt agent.
Prioritert håndtering: Tillat prioritering av visse samtaler, for eksempel VIP-kunder eller presserende problemer.

Typer køer

Webex Contact Center støtter flere typer køer som muliggjør et bredt utvalg av brukstilfeller for kontaktsentre i alle størrelser og kompleksiteter, på tvers av alle medietyper med ensartede funksjoner.

Det finnes køer som tar hensyn til agentferdigheter ved ruting av kontakter, og køer som ikke gjør det. Disse køene varierer også med hensyn til hvordan agenter er knyttet til dem for å arbeide med kontakter.

Det finnes to brede kategorier av køer:

Ikke-ferdighetsbaserte køer
Ferdighetsbaserte køer

Ikke-ferdighetsbaserte køer

Ikke-kompetansebaserte køer vurderer ikke ferdigheter knyttet til agenter. Du kan konfigurere ikke-ferdighetsbaserte køer med følgende alternativer:

Tildelinger i teamet
Agenttilordninger

Ikke-ferdighetsbaserte køer med teamoppgaver

I ikke-ferdighetsbaserte køer med teamtilordning kan du organisere agenter i team og kombinere disse teamene for å danne anropsdistribusjonsgrupper (CDG). Du kan angi en tidsforsinkelse mellom hver gruppe for å administrere samtaleflyten.

Anropsdistribusjonsgrupper bidrar til å definere flere nivåer av agenter som blir kvalifisert for å arbeide på kontakter i denne køen over konfigurerte tidsintervaller. Kontakter tilordnes til agenter basert på teamets nivå. Hvis ingen agenter er tilgjengelige, parkeres kontaktene i en forhåndskonfigurert varighet før de utvides til å omfatte den neste gruppen med team. Denne prosessen fortsetter til en agent er tilgjengelig eller alle grupper er kontrollert.

Du kan konfigurere denne typen team:

Individuelle team: Agenter kan organiseres i team som kan representere en bestemt organisasjonsfunksjon, som deretter kan bli en del av køer slik at kontakter kan rutes til agenter i disse teamene. Du kan merke en agent til flere team for å håndtere kontakter fra ulike køer for effektiv ruting.
Kapasitetsbaserte team: Kapasitetsbasert team (CBT) er en funksjon som dirigerer taleanrop til et kapasitetsbasert direkte nummer (DN), der kapasiteten bestemmer hvor mange anrop som kan håndteres samtidig. Det gjør det mulig å rute anrop til telefonnumre uten at agenter må logge på systemet, noe som gjør det egnet for scenarier der anrop besvares av talepost, telefonsvarer eller søkegrupper, i stedet for tradisjonelle telefonsenteragenter. I dette oppsettet er det ingen bestemte agenter tilordnet til teamet, og de bruker ikke Webex Contact Center Agent Desktop.

Arbeidsflytdiagram over hvordan ikke-ferdighetsbasert kø med teamtildeling fungerer i Webex Contact Center

I dette eksemplet er det tre anropsdistribusjonsgrupper, som tillater målutvidelse, noe som betyr å utvide til flere agenter på tvers av team over konfigurerte tidsintervaller.

Den første anropsdistribusjonsgruppen inneholder TEAM 1, som har 3 agenter konfigurert – A1, A2 og A5.

Den andre anropsdistribusjonsgruppen inneholder TEAM 2, som har 3 agenter konfigurert – A2, A3 og A4.

Den tredje (og siste) anropsdistribusjonsgruppen inneholder TEAM 3, som har 2 agenter konfigurert – A6 og A7.

Når en kontakt er i kø, søker systemet først etter en samsvarende agent i den første anropsdistribusjonsgruppen. Hvis det ikke blir funnet noen agenter, parkeres kontakten i den konfigurerte varigheten før målutvidelsen utvides til neste gruppe. Dette legger til nye lag til de eksisterende. Denne prosessen gjentas til den finner et treff, eller alle grupper er utvidet.

En funksjon kalt Kontroller agenttilgjengelighet fører til at kontakten umiddelbart utvides til den påfølgende anropsdistribusjonsgruppen hvis det ikke finnes samsvarende agenter i den gjeldende gruppen. Dette kan aktiveres i aktiviteten Køkontakt <KOBLE TIL 3.1.1> i flyten.

Dette oppsettet resulterer i følgende scenarier:

A2 tilhører LAG 1 og LAG 2. Hvis A2 velger TEAM 1 for å logge på Agent Desktop, anser systemet A2 som en del av TEAM 1 og dermed bare den første distribusjonsgruppen for anrop.
A5 tilhører TEAM 1, men kunne også ha vært en del av et annet team i organisasjonen som de for øyeblikket har logget inn på. A5 regnes derfor ikke som en del av TEAM 1 og er ikke knyttet til denne køen.

Køer med teamtilordning gir denne kraftige muligheten for agenter til å flytte mellom køer ved ganske enkelt å velge et team under pålogging.

Tilgjengelig rutemønster:

Lengst tilgjengelig

Ikke-kompetansebaserte køer med agenttilordninger

Ikke-kompetansebaserte køer er en type kø der et utvalg av agenter er direkte tilordnet til køen. I motsetning til andre køtyper, som indirekte bestemmer utvalget av agenter som er tilordnet dem, tillater disse køene administratorer å velge agenter direkte og manuelt. Teambaserte tilordningskøer tilordner for eksempel agenter basert på de påloggede teamene, og ferdighetsbaserte tilordningskøer samsvarer med agenter basert på nødvendige ferdigheter. Administratorer kan derimot legge til agenter direkte i disse køene for å bli en del av køen. Dette gir en enkel måte å administrere agenttildeling på uten å være avhengig av systemdrevne tilordninger.

Køer med agenttilordning gir enkle, men effektive rutingalgoritmer som hjelper til med å distribuere kontakter mellom agentgruppen. De tar ikke hensyn til ferdighetene til agenter i ruting av kontakter. Agenter kan imidlertid bestilles i hver kø, og dette tas i betraktning når kontakter rutes til dem. I denne sammenhengen fungerer team primært som en organisatorisk konstruksjon for ledere snarere enn en faktor i beslutninger om agentkøtilknytning og kontaktruting, noe som forenkler køadministrasjon.

Denne typen kø er best egnet der statisk tilordning av agenter og styring av agentkøtilknytning er mulig og ønskelig for operasjonell kontroll, og valg av rutingalgoritmer er egnet for arbeidsfordeling mellom agenter. Disse køene er også spesielt nyttige for scenarier der flere typer kundeforespørsler krever spesialisert ekspertise som kan betjenes av et forhåndsopprettet segment av ekspertagenter.

Komplekse kontaktsenterorganisasjoner kan imidlertid finne det vanskelig å behandle agenttilordninger manuelt i disse køene. De kan ha mer nytte av andre køtyper som tilbyr dynamisk ruting og agentkøtilknytninger.

Arbeidsflytdiagram som viser hvordan et eksempel på ikke-ferdighetsbasert kø med agenttilordning i Webex Contact Center fungerer

I dette eksemplet er et sett med agenter tilordnet i en bestemt rekkefølge, for eksempel A4, A9, A7 og så videre. Denne ordren spiller en rolle i bestemte rutingalgoritmer som samsvarer innkommende kontakter med agenter. Systemet matcher kontakter med disse agentene basert på deres tilgjengelighet og den valgte rutingalgoritmen.

I motsetning til køer med teamtilordning, er det ikke noe konsept for målutvidelse over tidsintervaller. Hvis ingen av de konfigurerte agentene er tilgjengelige for å rute denne kontakten, parkeres den i køen til en av disse agentene blir tilgjengelig for å behandle kontakter før tidsavbruddet for parkering. Målutvidelse gjelder ikke for disse køene.

Tilgjengelige rutemønstre:

Lengst tilgjengelig
Sirkulær
Lineær/ovenfra og ned

Ferdighetsbaserte køer

Kompetansebaserte køer gjør det mulig for kontakter å bli rutet til agenter med riktig kompetanse for å dekke deres behov.

Du kan konfigurere følgende typer ferdighetsbaserte alternativer:

Kompetansekriterier tilordnet til kø
Kompetansekrav tilordnet i flyt

Kompetansekriterier tilordnet til kø

Administratorer kan tilordne ferdighetskriterier til køer. Kompetansebaserte køer med ferdighetskriterier gjør det mulig for administratorer å konfigurere nødvendige ferdigheter direkte i køen. Alle agenter i organisasjonen som har alle de nødvendige ferdighetene i køen via direkte kompetanseprofil, blir implisitt en del av denne køen.

Dette oppsettet hjelper administratorer med å ha en direkte visning av agenter som tilordnes til køen på grunn av ferdigheter. I situasjoner med høyt volum eller lavt volum kan administratorer vurdere å justere de nødvendige ferdighetene til kø- og agentkompetanseprofilene for å utvide eller forminske agentutvalget etter behov.

Denne typen kø skiller seg fra teamoppgavebaserte køer i den forstand at det ikke finnes noen innstilling for anropsdistribusjonsgruppe, noe som betyr at teamet ikke spiller noen rolle i tilknytningen mellom agent og kø. Videre er de nødvendige ferdighetene statisk konfigurert i denne køen, i motsetning til teambaserte ferdighetskøer der flyten injiserer (statisk eller variabel) nødvendige ferdigheter. Derfor er teknisk sett ferdighetene en del av køen i stedet for selve kontakten.

Enhver agent i organisasjonen som helt tilfredsstiller kompetansekriteriene til køen (med ferdigheter fra direkte kompetanseprofil) blir implisitt assosiert med denne køen. Team spiller ingen rolle i agenttilknytningen til disse køene. Disse agentene kan være en del av ethvert team for ledelses- og driftsformål.

Hver kontakt som står i kø i denne køen, bruker automatisk kompetansekriteriene som er definert i selve køen. Individuelle kontakter kan ikke definere eller overstyre sine egne kompetansekrav/kriterier, i motsetning til i ferdighetsbaserte køer med teamoppgave.

Arbeidsflytdiagram som viser et eksempel på hvordan ferdighetsbasert kø med ferdighetskriterier fungerer i Webex Contact Center

I dette eksemplet,

Bare agentene A1, A3 og A7 oppfyller fullstendig kompetansekriteriene som er konfigurert i køen, og derfor vil bare disse agentene være knyttet til denne køen.
Agenter A2, A4 og A6 som delvis oppfyller kriteriene eller A5 som mangler relevante ferdigheter, kan ikke knyttes til denne køen.

Hvis du oppdaterer kompetanseprofilen til en agent (kalt reskilling) slik at den tilfredsstiller kompetansekriteriene i køen, blir agenten automatisk og dynamisk en del av denne køen. Hvis selve køkompetansekriteriene oppdateres, slik at flere (eller færre) agenter oppfyller de oppdaterte kompetansekriteriene, legges det også automatisk og dynamisk til (eller fjerner) agenter fra denne køen.

I motsetning til køer med teamtilordning, er det ikke noe konsept for målutvidelse over tidsintervaller. Hvis kontakten ikke samsvarer med noen av de tilknyttede agentene, parkeres den i køen til en av disse agentene blir tilgjengelig for å behandle kontakter før tidsavbruddet for parkering.

Kompetansebaserte køer egner seg best der statisk tildeling av kompetanse og styring av kø til agenttilknytning er gjennomførbart og ønskelig for operativ kontroll. De er også egnet når valg av rutingalgoritmer passer for arbeidsfordeling mellom agenter. Disse køene er også spesielt nyttige for scenarier der ulike typer kundeforespørsler krever spesifikke ferdigheter som kan betjenes av et forhåndsavledet segment av ekspertagenter.

Komplekse kontaktsenterorganisasjoner kan finne det enklere å administrere kø-til-agent-tilordninger i ferdighetsbaserte køer sammenlignet med køer med agenttilordning der hver agent må legges til manuelt i listen, noe som er tungvint spesielt for en større organisasjon.

Kompetansekrav tilordnet i flyt

Ferdighetsbaserte køer med ferdighetskrav tilordnet i flyt er en type teamoppgavebasert kø i Webex Contact Center der et sett med team er konfigurert på flere nivåer, kalt anropsdistribusjonsgrupper. Agenter som er logget på disse konfigurerte teamene, tilordnes kontakter fra denne køen basert på nivået for anropsdistribusjonsgruppen der gruppen er konfigurert i køen, hvis de også helt tilfredsstiller ferdighetskravene til kontakten.

I en slik kø grupperes agentteam i anropsdistribusjonsgrupper med konfigurerbare tidsforsinkelser mellom seg. Hvis ingen agent er tilgjengelig for kontakten, blir forespørselen parkert, og etter forsinkelsen utvides ruting til neste anropsdistribusjonsgruppe. Denne prosessen fortsetter til en agent er tilordnet eller alle gruppene er oppbrukt. Hvis en agent i en tidligere merket gruppe blir tilgjengelig i løpet av denne prosessen, velges denne agenten.

Agenter tilegner seg ferdigheter via ferdighetsprofil som er direkte tilordnet agenten. Agentferdigheter bestemmes basert på teamvalget under pålogging.

Hver kontakt kan eventuelt angi ferdighetskrav i flyten, som samsvares mot kompetansen til tilgjengelige agenter for å velge den mest egnede agenten.

I tillegg kan kontakter også angi kompetanseavslappinger ved konfigurerte tidsintervaller. Dette er et endret sett med kompetansekrav som overskriver de opprinnelige kompetansekravene til kontakten ved konfigurerte tidsintervaller. Dette gjør det mulig for en kontakt å endre (vanligvis brukes til å "slappe av") kompetansekravene mens den står parkert i køen, slik at flere agenter kan samsvare med disse avslappede kompetansekravene.

Målutvidelse gjennom anropsdistribusjonsgrupper kan skje samtidig med avslapningssykluser for ferdigheter – begge har som mål å matche en parkert kontakt med kvalifiserte agenter raskere, og dermed redusere den totale ventetiden og forbedre servicenivåene i køen.

Arbeidsflytdiagram som viser et eksempel på hvordan ferdighetsbasert kø med teamoppgave fungerer i Webex Contact Center.

I likhet med ufaglærte køer med teamtildeling har den tre anropsdistribusjonsgrupper som tillater "målutvidelse", dvs. utvidelse til flere agenter på tvers av team over konfigurerte tidsintervaller.

Den første anropsdistribusjonsgruppen inneholder TEAM 1, som har 3 agenter konfigurert – A1, A2 og A5.
Den andre anropsdistribusjonsgruppen inneholder TEAM 2, som har 3 agenter konfigurert – A2, A3 og A4.
Den tredje (og siste) anropsdistribusjonsgruppen inneholder TEAM 3, som har 2 agenter konfigurert – A6 og A7.

Det er imidlertid to hovedting å merke seg:

Hver kontakt som blir plassert i kø i denne køen, definerer kompetansekravene og ferdighetsavslapningen gjennom flyten.
Agenter kan ha ferdigheter konfigurert (gjennom en kompetanseprofil – direkte eller arvet fra det påloggede teamet).

Mens A2 er konfigurert til å være en del av både TEAM 1 og TEAM 2, avhengig av valget av team denne agenten har gjort under pålogging, anses han i sin nåværende økt som en del av det teamet, og vil derfor også arve ferdighetsprofilen (og dermed ferdighetsverdiene) fra det teamet (med mindre dette overstyres med en direkte kompetanseprofilkonfigurasjon for denne agenten).

Dette er en kraftig funksjon som tilbys av køer med teamtilordninger der agenter kan flytte mellom køer ganske enkelt ved å velge et team under pålogging.

Sammen med muligheten til å arve kompetanseprofilinnstillinger fra det valgte teamet, kan en agent også arbeide med forskjellige sett med ferdigheter.

I dette eksemplet,

Kontakter står i kø med et innledende kompetansekrav (sk_1 >= 6) under opptrapping fra flyt, med en kompetanseavslapning (sk_1 >= 3) etter et konfigurert tidsintervall.
På tvers av alle agenter i alle anropsdistribusjonsgrupper er det bare A1, A3, A6 og A7 som har ferdigheter som tilfredsstiller det opprinnelige kompetansekravet til kontakter i kø.
De gjenværende agentene har enten ferdigheten (sk_1), men tilfredsstiller ikke ferdighetskravene (f.eks. A2 i TEAM 1 og A4 i TEAM 2), eller har ikke denne ferdigheten i det hele tatt (f.eks. A5, A2 i TEAM 2).
Over tid, etter ferdighetsavslapning, tilfredsstiller i tillegg A2 og A4 nå også de "avslappede" ferdighetskravene til kontakten.

For hver kontakt som blir plassert i kø i denne køen, prøver systemet å finne en samsvarende agent i distribusjonsgruppen for første anrop som helt og holdent oppfyller de gjeldende kompetansekravene for kontakten. Hvis ingen samsvarende agent blir funnet, parkeres kontakten i den konfigurerte varigheten før målutvidelsen skjer med den andre anropsdistribusjonsgruppen. Alle teamene som er konfigurert i distribusjonsgruppen for andre anrop, legges også til eksisterende team fra den første gruppen. Nå forsøker systemet å finne en samsvarende agent i den utvidede gruppen. Vær oppmerksom på at mens dette pågår, vil kompetanseavslapning også oppdatere ferdighetskravene til kontakten ved konfigurerte tidsintervaller, og systemet vil bruke oppdaterte ferdighetskrav for å samsvare med tilgjengelige agenter i den gjeldende anropsdistribusjonsgruppen.

Dette fortsetter til alle de konfigurerte anropsdistribusjonsgruppene utvides og alle kompetanseavslapninger brukes, med mindre en samsvarende agent blir funnet før.

Tilgjengelige rutemønstre:

Lengst tilgjengelig
Best tilgjengelig

Konfigurasjon av kø

Konfigurere ferdighetsbaserte køer

Tilordne ferdighetskriterier til en kø

Skap ferdigheter.
Opprett kompetanseprofiler.
Tilordne kompetanseprofil direkte til agenter.
Opprett kø med kanaltypen Telefoni eller Chat eller E-post eller Sosialt.
Tilordne ferdighetskrav til køer i Control Hub.
Vis en liste over agenter som kan behandle kontakter i køen.
Velg en rutingalgoritme enten LAA eller BAA.
Legg til en køkontaktaktivitet i flyt, og velg denne køen.

Tilordne kompetansekrav til en kø

Skap ferdigheter.
Opprett kompetanseprofiler.
Tilordne kompetanseprofil til agenter direkte eller team.
Opprett et team.
Legg til agenter i teamet.
Opprett kø med kanaltypen Telefoni eller Chat eller E-post eller Sosialt.
Legg til team i køen i én enkelt CDG eller flere CDG-er.
Velg et rutemønster, enten LAA eller BAA.
Legg til en køkontaktaktivitet i flyt, og velg køen som kompetansebasert ruting er konfigurert for. Hvis du vil ha mer informasjon, kan du se Køkontakt.
Tilordne ferdigheter og ferdighetsavslapning i køkontaktaktivitet.
Bruk Eskaler anropsdistribusjonsaktivitet i flyt POST i kø for å gå raskt til neste eller siste anropsdistribusjonsgruppe.

Konfigurere køer som ikke er ferdighetsbaserte

Tilordne team til en kø

Opprett et team.
Legg til agenter i teamet.
Opprett kø med kanaltypen Telefoni eller Chat eller E-post eller Sosialt.
Legg til team i køen i én enkelt CDG eller flere CDG-er.
Velg et rutemønster enten LAA.
Legg til en køkontaktaktivitet i flyt, og velg denne køen.
Bruk Eskaler anropsdistribusjonsaktivitet i flyt POST i kø for å gå raskt til neste eller forrige anropsdistribusjonsgruppe.

Tilordne agent til en køflyt

Opprett kø med kanaltypen Telefoni eller Chat eller E-post eller Sosialt.
Legg til agenter direkte i køer (Merk: Verken ferdigheter eller team brukes i denne typen kø).
Velg rutingmønstre, for eksempel Sirkulær eller Lineær eller Lengste tilgjengelige agent.

Ruting

Rutingkonsepter

Scenario for agentoverskudd

Agentoverskuddsscenario oppstår når det er flere tilgjengelige agenter enn det er kontakter i kø. I dette tilfellet, når en kundesamhandling (kontakt) er i kø, prøver systemet å finne en samsvarende agent for denne bestemte kontakten umiddelbart, og hvis en samsvarende agent blir funnet, trenger ikke kontakten parkeres i køen og vente på at en samsvarende agent blir tilgjengelig senere.

Hver gang en kontakt utvides gjennom en samtaledistribusjonsgruppe eller gjennom kompetanseavslapning, prøver systemet igjen å finne en samsvarende agent for denne bestemte kontakten umiddelbart.

Når du skal finne en samsvarende agent for en bestemt kontakt, brukes det konfigurerte rutingsmønsteret i køen.

Webex Contact Center tilbyr flere rutingmønstre på tvers av ulike typer køer, noe som gjør det mulig for organisasjoner å optimalisere kundeservicen ved å minimere ventetider, balansere agentarbeidsbelastninger og sikre at kundene er koblet til agenter som har de nødvendige ferdighetene for å imøtekomme deres spesifikke behov. Se delen Rutingmønster for detaljert informasjon om rutemønstre.

Overskuddsscenario for kontakt

Overføringsruting av kontaktoverskudd forekommer når antallet innkommende kundesamhandlinger (eller kontakter) overskrider de tilgjengelige agentene. Denne situasjonen oppstår ofte i topptider eller uventede økninger i kontaktvolumet. Det primære målet med kontaktoverskuddsruting er å håndtere dette overløpet effektivt, og sikre at kundeservicestandarder opprettholdes til tross for overflødig etterspørsel. For en agent som nettopp har blitt tilgjengelig på en bestemt kanal, fungerer kontaktoverskuddsruting for å finne og tilordne den riktige kontakten blant alle parkerte kontakter på tvers av alle køer som denne agenten er tilknyttet.

De viktigste strategiene for å utføre kontaktruting effektivt med begrenset agenttilgjengelighet er:

Kø Ranking
Kørangering gjør det mulig for administratorer å angi den relative viktigheten av køer. Administratorer kan definere kørangeringer for å angi rekkefølgen anrop rutes i fra køer til agenter som er logget på team, per gruppe.
Tenk deg for eksempel at agenter som er logget på team A, er knyttet til to køer – "Fakturering" og "Salg". Administratorer kan bruke kørangering til å tilordne en høyere rangering til "Fakturering"-køen, så når kontakter kommer inn i køene, blir kontakter fra "Fakturering" rutet til agenter som tilhører gruppe A, foran kontakter fra "Salg"-køer. Dette skjer selv om det kan være eldre kontakter med høyere prioritet som kan vente i salgskøen – bare fordi køen "Fakturering" har en høyere kørangering enn "Salg"-køen. Først når det ikke er flere ventende kontakter i Fakturering-køen, blir agenter fra team A rutet kontakter fra salgskøen (og eventuelle andre) de er tilknyttet.
Følgende er noen av de viktige egenskapene til kørangering:
- - Hvis en rangering er tilordnet til bare noen av køene, vil anrop i disse køene ha forrang over anrop i køene som det ikke er angitt noen rangering for.
  - Kørangering kan angis på maksimalt 50 køer på tvers av alle medietyper med en verdi som varierer mellom 1 og 50 med 1 som høyeste rangering.
  - Du kan tilordne samme rangering til flere køer.
  - Hvis du aktiverer kørangering, behandles køer som ikke er tilordnet noen eksplisitt rangering, lavere enn alle rangerte køer.
  - Kørangering fungerer innenfor samme medietype.
    
    Hvis for eksempel Køsalg er en kø for talemedietype med rangering 2 og Støtte for køfakturering er en chattekø med rangering 1 for Gruppe A, vil agenter som er tilgjengelige på talekanalen i Team A, få taleanrop først selv om rangeringen er 2.
    
    Tenk deg imidlertid to chatkøer for Lag B - Køkredittkort med kørangering 2 og Kødebetkort med kørangering 1. Deretter vil de tilgjengelige agentene i Team B bli tilbudt kontakter fra Queue Debit Card først.
  - Kørangering gjelder ikke for kapasitetsbaserte team.
Prioritet for kontakt
Når en kontakt står i kø, kan prioriteten defineres ved å tilordne en hierarkisk viktighet fra 1 (høyest) til 10 (lavest, standard). Denne prioriteringen sikrer at visse kontakter blir adressert raskere basert på deres betydning, haster eller strategiske verdi for organisasjonen. Når en agent er tilgjengelig for å håndtere den neste kontakten blant alle parkerte kontakter i alle køer som agenten er tilknyttet, rutes kontakten med høyest prioritet på tvers av alle køer til agenten (forutsatt at andre kriterier, for eksempel kompetansematching og andre, er oppfylt).
For kontaktene som er i kø uten noen eksplisitt prioritet, vurderes en standardprioritet på 10 (lavest). Blant flere kontakter som har samme prioritet, rutes kontakten som venter i køen i lengst varighet, først til den tilgjengelige og kvalifiserte agenten.
Lengste ventetid for kontakt
Dette er en grunnleggende strategi som sikrer at kontakten med lengst ventetid på tvers av alle køer som agenten er tilknyttet, rutes til agenten.
Dette er det ultimate kriteriet som bestemmer hvilken kontakt som skal rutes når flere kontakter på tvers av køer med samme kørangering og samme kontaktprioritet venter på å bli behandlet.

I hovedsak betyr kontaktoverskuddsruting for en agent som nettopp ble tilgjengelig, å velge en enkelt kontakt som:

Er av samme medietype som den agenten er tilgjengelig på
Er parkert i en av køene som denne agenten er tilknyttet,
Hvis ferdighetskrav (hvis noen) alle tilfredsstilles av denne agenten
Er parkert i en kø der rangeringen er høyere enn andre køer, slik den er konfigurert i agentens team
Har høyeste prioritet blant alle slike kontakter
Er den eldste ventekontakten blant kontakter med samme prioritet

I eksemplet ovenfor som illustrerer et kontaktoverskuddsscenario, har agent A1 logget på TEAM 1 og blitt tilgjengelig for å håndtere kontakter på flere medietyper.

A1 er forbundet med 3 køer – Q1, Q2 og Q3. TEAM 1 har også definert kørangering der Q1 rangeres høyest, deretter henholdsvis Q2 og Q3 .

Det er kontakter som allerede er parkert i alle disse køene, med kompetansekrav og prioritet definert for hver kontakt.

Nå fungerer scenarioet for kontaktoverskudd som følger:

Blant alle parkerte kontakter på tvers av disse køene, kan bare 4 kontakter rutes til A1–C2,C7 (fra KØ 2) ogC3,C8 (fra KØ 3).

Bare ferdighetskravene til disse 4 kontaktene er helt fornøyd med ferdighetene til A1.
Blant disse 4 kontaktene gis det prioritet til kontakter fra KØ 2 (dvs. C2, C7) fordi KØ 2 har høyest kørangering.

Vær oppmerksom på at selv om KØ 1 er den høyest rangerte køen, kan ingen av de parkerte kontaktene rutes til A1 siden kompetansekravene ikke oppfylles av A1.
Mellom C2 og C7 erden høyest prioriterte kontakten C7 . Så det endelige valget er C7, og systemet ruter det til A1.

Dette skjer selv om C2 ble satt i kø tidligere, fordi kontaktprioritet har forrang over tid i kø.

Blandede multimedieprofiler

Gjennom konfigurasjon av multimedieprofil gir Webex Contact Center agenter muligheten til å betjene kontakter på tvers av ulike medietyper (tale, chat, e-post og sosialt). Basert på denne konfigurasjonen får agenter klargjort kanaler per medietype.

Hver kontakt som rutes til en agent, bruker én kanal av denne medietypen så lenge agenten jobber med denne kontakten. Mens agenter bare kan ha én talekanal, kan de ha opptil fem kanaler av andre medietyper.

Innstillingen for blandet ruting i multimedieprofiler gjør det mulig for administratorer å kontrollere hvordan forskjellige kanaler kan brukes samtidig for hver agent. Dette gjør det mulig for organisasjoner å gi dedikert oppmerksomhet til kunder, fremme bedre Quality of Service, forbedret kundeopplevelse og bedre konverteringsfrekvenser. Organisasjoner kan også balansere belastningen på tvers av mediekanaler når de opplever ujevn belastning i enkelte kanaler, noe som muliggjør effektiv utnyttelse av agenter.

Det er tre valg:

Uten
Blandet
Blandet sanntid

Ved håndtering av en ikke-talekontakt kan agenter starte et manuelt utgående taleanrop fra Agent Desktop, så lenge de har en talekanal tilgjengelig. Dette gjelder for alle multimedieprofiltyper.

Hvis du vil ha mer informasjon om hvordan du konfigurerer multimedieprofiler, kan du se Administrere multimedieprofiler.

Rutingmønstre

Ferdighetsbasert

Ferdighetsbaserte rutingmønstre i Webex Contact Center dirigerer innkommende kundeinteraksjoner til agenter basert på spesifikke ferdigheter som kreves for å løse forespørselen, for eksempel språkkunnskaper eller teknisk ekspertise. Disse mønstrene sikrer at hver kunde kobler seg til den mest kvalifiserte agenten, noe som forbedrer serviceeffektiviteten og kundetilfredsheten. Fordelene inkluderer redusert behandlingstid, forbedrede løsningsfrekvenser og optimalisert bruk av agentressurser ved å tilpasse ekspertisen til kundenes behov.

Når ferdighetsbaserte rutingmønstre brukes, brukes først kompetansekravet til kontakten (tilordnet i flyt) eller kompetansekriteriene som er tilordnet køen, til å filtrere tilgjengelige agenter med ferdigheter som tilfredsstiller disse kravene/kriteriene helt. Blant agenter som filtreres, velges deretter én enkelt for kontakten basert på det konfigurerte rutingsmønsteret.

Lengst tilgjengelig

Det lengste tilgjengelige ferdighetsbaserte rutingsmønsteret ruter en kontakt til den agenten som har ferdigheter som tilfredsstiller kompetansekriteriene for kontaktkompetanse / køkompetanse, og som har vært tilgjengelig lengst siden den siste kontakten ble håndtert blant alle kvalifiserte agenter i køen.

Dette rutemønsteret bidrar til å fordele arbeid jevnt på tvers av agenter ved å tilordne samhandlinger til de som har vært tilgjengelige lengst, og forhindrer ubalanse i arbeidsbelastningen. Det bidrar til å opprettholde rettferdighet i arbeidsfordelingen, og sikrer at ingen agenter blir overbelastet mens andre forblir frie.

I eksemplet ovenfor er det 4 agenter som har ferdighets- og ikke-ferdighetsferdigheter med varierende ferdighetsverdier.

Tenk deg en kontakt som står i kø i en kompetansebasert kø med rutemønsteret "Lengst tilgjengelig":

Med kompetansekravene ovenfor tilordnet via flyt, eller
Med kompetansekriteriene ovenfor konfigurert i den ferdighetsbaserte køen

I dette scenariet:

Bare agenter som helt tilfredsstiller kompetansekravene for kontakt, / køferdighetskriteriene, vurderes for ruting. Det er kun agentene A1 , A2 og A4 som i sin helhet tilfredsstiller kompetansekriteriene for kontaktkompetanse /kø.

Agent A3 er ikke kvalifisert. Når det gjelder ferdighetskriterier som er tilordnet kø, er A3 ikke engang knyttet til køen.
Blant A1, A2 og A4 vil kontakten bli rutet til den lengste tilgjengelige agenten – A1 som har vært tilgjengelig i 10 minutter, lenger enn A2 eller A4.

I kraft av at A1 blir tildelt kontakten, vil A1 ikke lenger være den lengst tilgjengelige agenten på tvers av alle mediekanaler.
Den neste kontakten med nøyaktig samme ferdighetskrav rutes til den nest lengste tilgjengelige agenten – A2 og så videre.

Dette rutingsmønsteret støttes i følgende typer kompetansebaserte køer:

Kompetansekrav tilordnet i flyt
Kompetansekriterier tilordnet til kø

Best tilgjengelig

Det beste tilgjengelige ferdighetsbaserte rutingmønsteret sikrer at kundeinteraksjoner blir rettet mot den mest kvalifiserte agenten som er tilgjengelig. Dette mønsteret evaluerer ikke bare tilstedeværelsen av nødvendige ferdigheter blant agentene, men også ferdighetsnivåene til disse ferdighetene, og beregner en ferdighetspoengsum for å bestemme den mest kvalifiserte ("beste") agenten for hver kontakt.

Dette mønsteret filtrerer tilgjengelige agenter med ferdigheter som tilfredsstiller kontaktferdighetskravene / køferdighetskriteriene helt. Deretter beregnes en poengsum for hver kvalifiserte agent ved hjelp av kompetanseverdier for alle ferdigheter som er nevnt i kompetansekriteriene for kontaktkompetanse. Agenten med høyest kompetansepoengsum regnes som den "beste" agenten for hver kontakt.

Summen av kompetanseverdiene til agenten som samsvarer med kompetansekravene / køferdighetskriteriene, bestemmer faktisk poengsummen.

Noen viktige punkter å forstå:

Vanligvis brukes den faktiske kompetanseverdien i poengberegningen, fordi en høyere ferdighetspoengsum indikerer et sterkere samsvar. Bortsett fra når et ferdighetskrav bruker betingelsen mindre enn lik (<=), blir den spesifikke ferdighetsverdien til agenten invertert i poengberegningen effective_skill_value dvs. = (10) minus (actual_skill_value). Dette gjøres for å sikre at en lavere poengsum indikerer en sterkere kamp.
Når flere kvalifiserte agenter har samme poengsum, velges den lengst tilgjengelige agenten blant dem
Kun ferdighetsferdigheter vurderes for poengberegning. Eventuelle boolske ferdigheter, tekst- eller opplistingsferdigheter i ferdighetskravene til kontakten/køferdighetskriteriene vurderes ikke for poengberegning.

I eksemplet ovenfor er det fire agenter som har ferdighets- og ikke-ferdighetsferdigheter med varierende ferdighetsverdier.

Tenk deg en kontakt som står i kø i en kompetansebasert kø med rutemønsteret "Best tilgjengelig":

Med kompetansekravene ovenfor tilordnet via flyt, eller
Med kompetansekriteriene ovenfor konfigurert i den ferdighetsbaserte køen.

I dette scenariet:

Bare agenter som helt tilfredsstiller kompetansekravene for kontakt, / køferdighetskriteriene, vurderes for ruting. Det er kun agentene A1 , A2 og A4 som i sin helhet tilfredsstiller kompetansekriteriene for kontaktkompetanse /kø.

Agent A3 er ikke kvalifisert. Når det gjelder ferdighetskriterier som er tilordnet kø, er A3 ikke engang knyttet til køen.
Blant A1,A2 og A4 gjøres poengberegningen av systemet basert på kontaktferdighetskravene/køferdighetskriteriene, der kun ferdighetsferdigheter vurderes.

Bare ferdighetene nevnt i kontaktferdighetskravene/køferdighetskriteriene vurderes for poengberegning, selv om agenter kan ha tilleggs-/andre ferdighetsferdigheter.

Legg også merke til inversjonen av ferdighetsverdi i poengberegningen når betingelsen mindre enn lik (<=) brukes.
Kontakt rutes til A2 siden dette er den beste tilgjengelige agenten basert på poengsum. Hvis A2 ikke er tilgjengelig/opptatt, rutes kontakten til den nest beste tilgjengelige agenten med nest høyest poengsum osv.

Vi har imidlertid 2 agenter - A1 og A4 med nest høyest score. Kontakten rutes til den lengst tilgjengelige agenten mellom A1 og A4.

Dette rutingsmønsteret støttes i følgende typer kompetansebaserte køer:

Kompetansekrav tilordnet i flyt
Kompetansekriterier tilordnet til kø

Ruting uten ferdigheter

Webex Contact Center støtter også en rekke ikke-ferdighetsbaserte rutingmønstre som fokuserer på å distribuere innkommende kundeinteraksjoner uten å vurdere agenters spesifikke ferdigheter eller ekspertise. I motsetning til ferdighetsbaserte rutingmønstre, vurderer ikke disse agentferdigheter eller krever at kontakten eller køen definerer ferdighetskrav / kriterier for ruting. I stedet prioriterer de faktorer som tilgjengelighet, fordeling av arbeidsbelastning og forhåndsdefinerte sekvenser, noe som muliggjør effektiv håndtering av kontakter basert på operasjonell logikk i stedet for individuelle agentkompetanser. Disse mønstrene er spesielt nyttige i miljøer der samhandlinger er relativt ensartede eller ikke krever spesialisert håndtering.

Lengst tilgjengelig

Rutemønsteret Lengst tilgjengelig ruter en kontakt til den agenten i køen som har vært tilgjengelig lengst siden den siste kontakten ble behandlet, på tvers av alle agenter som er tilgjengelige og tilknyttet denne køen.

Dette rutemønsteret sikrer rettferdig og balansert fordeling av arbeidsbelastninger ved å tilordne samhandlinger til agenter som har vært inaktive lengst. Ved å forhindre ubalanser i arbeidsmengden sikrer det at ingen agenter blir overbelastet mens andre forblir ledige. Denne tilnærmingen er spesielt effektiv i perioder med jevn kontaktflyt, og opprettholder konsekvent engasjement på tvers av agentutvalget.

Agenter mister sine "lengst tilgjengelige" posisjoner på tvers av alle kanaler når de blir tilbudt en kontakt av en hvilken som helst medietype. Dette betyr at når en agent har behandlet en kontakt, blir den neste kontakten av en hvilken som helst medietype i kø, tilordnet til den nest lengst tilgjengelige agenten i denne køen.

I eksemplet ovenfor er agent A1 den lengste tilgjengelige agenten (posisjon 1) – enten denne agenten logget på først eller ikke har blitt tilordnet en kontakt lenger enn noen annen agent.

Agentene A2 (posisjon 2) og A3 (posisjon 3) er også tilgjengelige, men de har enten logget seg på, eller har håndtert kontakter etter A1. Alle agenter er knyttet til begge køene som har dette rutingsmønsteret.

Tenk deg følgende scenario:

På tidspunkt T0 blir en talekontakt C1lagt i kø og rutet til den lengst tilgjengelige agenten, dvs .

I kraft av at A1 er tildelt C1, er A1 ikke lenger den lengste tilgjengelige agenten på tvers av alle mediekanaler.
På tidspunkt T1 blir en chatkontakt C2 lagt i kø og rutet til den lengst tilgjengelige agenten, som nå er A2.
Til slutt, på tidspunkt T2, blir en annen talekontakt C3 satt i kø og rutet til A3.

A1 og A2 fikk nylig kontakter – på dette tidspunktet er det A3 som har ventet lengst.

På grunn av den svært distribuerte arkitekturen Webex Contact Center er det en liten mulighet for at én enkelt lengst tilgjengelig agent kan rutes flere kontakter når disse kontaktene står i kø til samme kø samtidig.

Dette rutingsmønsteret støttes i følgende typer køer som ikke er ferdighetsbaserte:

Tildeling av team
Agenttilordning

Sirkulær

Sirkulær rutingmønster distribuerer innkommende kontakter mellom en gruppe tilgjengelige agenter i en round-robin-rekkefølge. Når en kontakt er i kø, tilordner systemet den til den neste tilgjengelige agenten i køen basert på en forhåndsbestemt sekvens.

Prosessen begynner med agenter i en konfigurert rekkefølge. Den første innkommende kontakten tilordnes den første tilgjengelige agenten i denne sekvensen. For etterfølgende kontakter velger systemet den neste tilgjengelige agenten, og fortsetter der den slapp i den definerte kørekkefølgen. Dette mønsteret gjentar seg, går gjennom agentene, men starter alltid etter den sist valgte agentens posisjon.

Denne tilnærmingen er effektiv for å fordele kontakter rettferdig og jevnt mellom agenter. Det bidrar til å sikre at ingen enkelt agent blir overveldet med kontakter, og at alle agenter har like muligheter til å håndtere samhandlinger konsekvent. Sirkulærrutingsmønsteret tar imidlertid ikke hensyn til gjeldende arbeidsbelastning eller andre faktorer som kan påvirke en agents evne til å håndtere en bestemt kontakt.

I eksemplet ovenfor konfigureres agenter i en sirkulær kø i følgende rekkefølge: A3 → A4 → A5 → A6 → A1 → A2.

Tenk deg følgende scenario:

Den første kontakten (C1) legges i kø, og den rutes til agent A3.

Pekeren oppdateres til neste agent i konfigurert rekkefølge, dvs.
Når den andre kontakten (C2) står i kø, begynner systemet å finne tilgjengelige agenter fra A4 , dvs. A4 → A5 → A6 → A1 → A2 → A3.

Imidlertid er A4 og A5 ikke tilgjengelige (enten er de ikke engang logget inn, eller inaktive, eller fullt opptatt med andre kontakter av denne medietypen), så C2 rutes til neste tilgjengelige agent - A6. Pekeren oppdateres til neste agent i konfigurert rekkefølge, dvs.
På samme måte rutes den tredje kontakten (C3) tilA1 , den fjerde kontakten (C4) rutes tilA2 . Pekeren er på A3 igjen.

Denne logikken fortsetter, og kontakter fordeles mellom tilgjengelige agenter i "sirkulær" / "round-robin" -mønsteret.

Hvis det er parkerte kontakter i kø, vil agentoverskuddsscenarioet samsvare med den neste agenten som blir tilgjengelig for denne medietypen, med den høyest prioriterte og eldste kontakten blant dem.

Dette tar ikke hensyn til eller påvirker ikke den eksisterende posisjonsverdien i denne køen, som bare oppdateres når ruting av kontaktoverskudd samsvarer med en agent.

Dette rutingsmønsteret støttes i følgende typer køer som ikke er ferdighetsbaserte:

Agenttilordning

Ovenfra og ned

Ovenfra-og-ned-rutemønsteret distribuerer innkommende kontakter mellom en gruppe tilgjengelige og bestilte agenter i en sekvensiell rekkefølge. Når en kontakt står i kø, går systemet alltid gjennom den sorterte listen over agenter fra begynnelsen og matcher kontakten med den første tilgjengelige agenten (som har en ledig tilgjengelig kanal av kontaktens medietype) i denne sekvensen.

Dette skjer for hver kontakt som er i kø. Kontakten forsøkes samsvart, alltid ved å starte fra toppen (første konfigurerte agent) og fortsette nedover listen til en samsvarende agent blir funnet.

I motsetning til sirkulært rutingsmønster er det ingen "peker" som dynamisk endrer startpunktet basert på den sist valgte agentens posisjon.

Denne tilnærmingen er effektiv for å distribuere kontakter mellom agenter som er ordnet basert på noen skjevhet / preferanse som bestemt av administratoren. Det bidrar til å sikre at agentene på toppen alltid foretrekkes for å håndtere kontakter fremfor agenter under dem. Rutingsmønsteret ovenfra og ned tar imidlertid ikke hensyn til gjeldende arbeidsbelastning eller andre faktorer som kan påvirke agentens evne til å håndtere en bestemt kontakt.

I eksemplet ovenfor konfigureres agenter i en ovenfra-og-ned-kø i følgende rekkefølge: A3 → A4 → A5 → A6 → A1 → A2.

Dette betyr at administratoren vil at hver kontakt skal rutes til den første agenten (A3) hvis tilgjengelig, ellers neste agent (A4) hvis tilgjengelig, og så videre, i konfigurert rekkefølge.

Tenk deg følgende scenario:

Den første kontakten (C1) legges i kø, og den rutes til agent A3, siden A3 er øverst i ordren.
Når den andre kontakten (C2) står i kø, forsøkes ruting igjen fra toppen av ordren (alltid med A3).

Hvis A3 har mer kanalkapasitet for denne medietypen, rutes C2 også til A3. Hvis A3 imidlertid er fullt opptatt med denne medietypen, fortsetter ruting nedover listen til A4.
A4 og A5 er imidlertid ikke tilgjengelige (de er enten ikke engang logget på, eller inaktive, eller fullt opptatt med andre kontakter av denne medietypen), så C2 rutes til neste tilgjengelige agent ovenfra og ned – A6.
På samme måte forsøkes den tredje kontakten (C3) å rutes fra A3 ned mot bunnen. Den første matchende agenten vil være A1.

Denne logikken fortsetter, helt til en kontakt ikke finner noen tilgjengelige agenter før nederst i ordren, og da er den parkert i køen.

Dette rutingsmønsteret støttes i følgende typer køer som ikke er ferdighetsbaserte:

Agenttilordning

Agentbasert ruting

Agentbasert ruting er en funksjon som ruter eller setter en kontakt i kø direkte til en angitt ("foretrukket") agent. Et agentoppslag med agentens e-postadresse eller agentens ID ruter en kontakt til den foretrukne agenten. Kø-til-agent-aktiviteten i flyten bidrar til å oppnå agentbasert ruting. Hvis du vil ha mer informasjon, kan du se Kø til agent-aktivitet .

En kontakt kan ha en tilordning til én eller flere foretrukne agenter, som vanligvis kan administreres i et eksternt program utenfor Webex Contact Center. Det foretrukne agentoppslaget for en kontakt gjøres via HTTP-forespørselsaktiviteten , som henter tilordningen fra et eksternt program. Hvis du vil rute eller parkere kontakten med den foretrukne agenten, konfigurerer du aktiviteten Kø til agent ved å bruke agentens Webex Contact Center ID eller e-postadresse. Kontakten kan også parkeres mot en foretrukket agent hvis den foretrukne agenten ikke er tilgjengelig umiddelbart.

Agentbasert ruting er nyttig i følgende scenarier:

Foretrukket agentruting: Kunden kan tilordne kontakter til dedikerte agenter eller relasjonsledere. I slike scenarier ruter den agentbaserte rutingen kontaktene direkte til den foretrukne agenten.
Siste agentruting: Når en kontakt ringer tilbake til kontaktsenteret flere ganger for å samhandle med en agent, kan agentbasert ruting rute kontakten til den siste agenten som behandlet kontakten.

I begge brukstilfellene lagres detaljene for kontakten og agenttilordningen utenfor Webex Contact Center.

Kø- og rutingfunksjoner i Flow

Kø- og rutingfunksjoner i flyt

I Webex Contact Center kan en rekke funksjoner for ruting, kø og samtalekontroll orkestreres gjennom flyter.

En rekke flytaktiviteter og hendelsesbehandlinger som tilbys i flytutformingen, kan plasseres i flyten for effektivt å administrere livssyklusen til innkommende og utgående kontakter.

Hvis du vil ha mer informasjon om hvordan du konfigurerer og bruker flyter, kan du se Bygge og administrere flyter med Flytutforming.

Aktiviteter i kø

Køkontakt

Køkontakt-aktiviteten gjør det mulig å sette en kontakt i kø i en aktiv innkommende kø fra organisasjonen, slik at den kan matches og rutes til riktig agent i denne køen.

Følgende aspekter ved køkjøring kan administreres gjennom denne aktiviteten:

Prioritet – Tilordne en hierarkisk viktighet fra 1 (høyest) til 10 (lavest, standard) til kontakten som står i kø.
Kompetansekrav – Angi kompetansekriteriene som må oppfylles av agenter i en kompetansebasert kø, for å anses som kvalifisert for ruting av kontakten.
Ferdighetsavslapninger - Tuning, modifiser eller fjern tidligere angitte ferdighetskrav etter en periode for å forbedre sjansene for å finne en agent.
Sjekk agenttilgjengelighet – La systemet utvides umiddelbart gjennom alle anropsdistribusjonsgrupper der ingen tilgjengelige agenter blir funnet, for å unngå ventetid.

Se Ruting hvis du vil ha mer informasjon om hvordan prioritet, kompetansekonfigurasjon og agenttilgjengelighet spiller en rolle i ruting av kontakter.

Når køkontaktaktiviteten er satt i kø for kontakten,

Hvis en samsvarende agent allerede er tilgjengelig, prøver systemet å rute kontakten til en agent.

Dette avbryter kjøringen av hovedflyten , og ytterligere hendelser kan utløse de respektive hendelsesflytene, hvis de er konfigurert.
Hvis ingen samsvarende agent blir funnet, blir kontakten parkert i køen og venter på at en samsvarende agent skal bli tilgjengelig.

Flytkjøringen fortsetter deretter med aktivitetene tilknyttet etter køkontaktaktivitet, som gir muligheten til å:
- Spill av forhåndskonfigurert musikk til kunden som venter i kø – ved å legge ved en PlayMusic-aktivitet .
- Registrer en tilbakeringing basert på kundens forespørsel - ved å legge ved en tilbakeringingsaktivitet .
- Ny kø, dvs. fjern kontakten fra gjeldende kø og legg til i en ny kø – ved å knytte en annen køkontakt eller kø til agentaktivitet .

Når en samsvarende agent blir tilgjengelig, forsøker systemet å rute kontakten til agenten.

Når dette lykkes, avbryter dette hovedflytkjøringen , og ytterligere hendelser kan utløse de respektive hendelsesflytene, hvis de er konfigurert.

Bruk av køkontaktaktiviteten støttes ikke når:

En agent er allerede tilordnet til kontakten.
En ugyldig kø, kompetanse eller annen konfigurasjon er angitt i flyten.
Maksimalt tillatt inngangspunkt og køoverganger (25) for en kontakt er oppbrukt.
Maksimalt antall tillatte forsøk på å rute en kontakt (20) er oppbrukt.

I slike tilfeller resulterer aktiviteten i en feil, og flytkjøringen flyttes til feilbehandlingsbanen .

Funksjoner som kompetansekrav, kompetanseavslapninger og kontroll av agenttilgjengelighet er bare tilgjengelige i køkontaktaktiviteten når køer med teamtilordning er valgt.

Hvis du vil ha mer informasjon om aktivitetsinnstillinger, bruks- og utdatavariabler, kan du se Bygge og administrere flyter > Køkontakt.

Kø til agent

Kø til agent-aktiviteten gir muligheten til å sette kontakten i kø direkte til en foretrukket agent ved å slå opp deres unike agent ID eller e-postadresse i Webex Contact Center.

Følgende aspekter ved køkjøring kan administreres gjennom denne aktiviteten:

Prioritet – Tilordne høyere / lavere viktighet til kontaktene som står i kø mot samme agent.
Rapporteringskø – Identifiser køen som skal brukes til konfigurasjon, for eksempel innspilling og standard musikk i kø, og rapportformål for kontakten.
Gjenopprettingskø – Identifiser køen som skal brukes som basis, når kontakten ikke kunne rutes til den angitte foretrukne agenten.

Når aktiviteten Kø til agent er satt i kø for å sette kontakten i kø,

Hvis agenten allerede er tilgjengelig, blir kontakten rutet til agenten.

Dette avbryter kjøringen av hovedflyten , og ytterligere hendelser kan utløse de respektive hendelsesflytene, hvis de er konfigurert.
Hvis agenten er tilgjengelig, men velger å avslå, ikke svare eller ikke mottar kontakten, flyttes den til den angitte gjenopprettingskøen.

I gjenopprettingskøen blir kontakten rutet til den lengst tilgjengelige agenten, uten støtte for ferdigheter.
Hvis agenten ikke er tilgjengelig og alternativet " Parker kontakt hvis agent ikke er tilgjengelig " er valgt, blir kontakten parkert og venter på at agenten skal bli tilgjengelig.

Flytkjøringen fortsetter deretter med aktivitetene som er knyttet til etter kø-til-agent-aktiviteten, noe som gir muligheten til å:
- Spill av forhåndskonfigurert musikk til kunden som venter i kø – ved å legge ved en PlayMusic-aktivitet .
- Tilbakeringingsaktivitet .
- Gjenta køen, dvs. fjerne kontakten fra gjeldende kø og legge til i en ny kø - ved å knytte en annen kø til agent - eller køkontaktaktivitet .
Når agenten blir tilgjengelig, forsøker systemet å rute kontakten til agenten.

Dette avbryter kjøringen av hovedflyten , og ytterligere hendelser kan utløse de respektive hendelsesflytene, hvis de er konfigurert.
Hvis agenten ikke er tilgjengelig og alternativet " Parker kontakt hvis agent ikke er tilgjengelig " ikke er valgt, mislykkes køen.

Bruk av aktiviteten Kø til agent støttes ikke når:

En agent er allerede tilordnet til kontakten.
En ugyldig foretrukket agent ID eller e-postadresse er oppgitt.
Det finnes en ugyldig rapporterings- eller gjenopprettingskø.
Den foretrukne agenten finnes, men er ikke logget på, ikke tilgjengelig eller opptatt med å håndtere en annen kontakt.

I slike tilfeller resulterer aktiviteten i en feil, og flytkjøringen flyttes til feilbehandlingsbanen .

Hvis du vil ha mer informasjon om aktivitetsinnstillinger, bruks- og utdatavariabler, kan du se Bygge og administrere flyter > Kø til agent.

Eskalere anropsdistribusjonsgruppe

Aktiviteten Eskaler anropsdistribusjonsgruppe støttes bare for køer med teamtilordning, og gir mulighet til å oppdatere samtaledistribusjonsgruppen for kontakten umiddelbart, i stedet for å vente på at den automatiske utvidelsesoppdateringen skal skje med neste gruppe etter den konfigurerte ventetiden. Dette gjør at kontakten raskt kan rutes til alle kvalifiserte agenter i kø.

Ved å bruke aktiviteten Eskaler anropsdistribusjonsgruppe kan kontakten eskaleres til:

Neste gruppe – Utvidelse av gruppesettet til å inkludere de som er lagt til i distribusjonsgruppen for neste anrop.
Siste gruppe – Utvidelse av settet med team til å omfatte alle teamene som er tilordnet på tvers av alle anropsdistribusjonsgrupper som er konfigurert for køen.

Bruk av aktiviteten Eskaler anropsdistribusjonsgruppe støttes ikke når:

Kontakten er ikke allerede i kø.
Kontakten står i kø i en kø som ikke støtter konseptet med anropsdistribusjonsgrupper.

I slike tilfeller resulterer aktiviteten i en feil, og flytkjøringen flyttes til feilbehandlingsbanen .

Tenk deg et eksempelscenario der en kontakt som blir satt i kø i kø med tre anropsdistribusjonsgrupper, som hver oppdateres etter en periode på 30 sekunder.

Ingen agenter er tilgjengelige i teamene som er en del av CDG 1 og CDG 2, og en agent er tilgjengelig i TEAM 3 som tilhører distribusjonsgruppen for siste anrop.

Når aktiviteten Eskaler anropsdistribusjonsgruppe ikke brukes i flyten, resulterer det i lang ventetid, som illustrert nedenfor:

Ventetiden kan senkes ved hjelp av aktiviteten Eskaler anropsdistribusjonsgruppe brukes som følger:

Basert på alternativet Neste gruppe eller Siste gruppe som er valgt, reduseres ventetiden for kontakten betraktelig, som illustrert nedenfor:

Hvis du vil ha mer informasjon om aktivitetsinnstillinger, bruks- og utdatavariabler, kan du se Bygge og administrere flyter > Eskalere anropsdistribusjonsgruppe.

Aktiviteter for køinformasjon

Få køinformasjon

Aktiviteten Hent køinformasjon gir mulighet til å hente køinformasjon i sanntid for en gitt kontakt, for eksempel:

Kontaktens gjeldende posisjon i kø (PIQ), eller den potensielle stillingen hvis den ennå ikke er satt i kø.
Den estimerte ventetiden (EWT) eller varigheten som en aktivitet anslås å vente i køen før den blir besvart.
Antall agenter som er logget på eller tilgjengelige i kontaktens gjeldende distribusjonsgruppe for anrop.
Antall agenter som er logget på eller tilgjengelig i alle anropsdistribusjonsgrupper for den valgte køen.
Varigheten som den eldste kontakten i køen har ventet på.

Disse detaljene gjøres tilgjengelige i flytkjøringen som aktivitetsutdatavariabler.

Hvis du vil ha mer informasjon om aktivitetsbruken, den detaljerte definisjonen og beregningsmetoden for hver kødetalj, kan du se Bygge og administrere flyter > Få køinformasjon.

Noen av måtene å bruke køinformasjonen på kan være:

For å kunngjøre kontaktens posisjon i kø og estimert ventetid til kunden, mens de venter på å bli rutet.
For å avgjøre om en tilbakeringing kan registreres for kunden, hvis estimert ventetid er for lang.
Hvis du vil eskalere kontakten til neste anropsdistribusjonsgruppe (CDG), hvis ingen agenter er tilgjengelige i team som er tilordnet til gjeldende CDG.

Bruk av aktiviteten Hent køinfo støttes ikke når en ugyldig kø oppgis gjennom variabelvalget.

I dette tilfellet resulterer aktiviteten i en feil, og flytkjøringen flyttes til feilbehandlingsbanen .

I følgende tilfeller gjelder ikke køinformasjon i sanntid for gjeldende anropsdistribusjonsgruppe:

Kontakten er ikke (ennå) i kø når aktiviteten Hent køinfo utføres.
Kontakten står i kø i en kø som ikke støtter konseptet med anropsdistribusjonsgrupper.

I disse tilfellene angir verdien på -1 i disse utdatafeltene at denne informasjonen ikke er aktuell.

Tenk deg et eksempelscenario der kunden skal informeres om en lang EWT i køen, etter hvert 15. sekund tilbrakt i køen.

Dette kan oppnås ved å bruke aktiviteten Hent køinfo i flyten på følgende måte:

Avansert køinformasjon

Aktiviteten Avansert køinformasjon gjør det mulig å hente køinformasjon i sanntid for en gitt kontakt, og i tillegg ta hensyn til kompetansekriteriene for kontakten, for eksempel:

Kontaktens gjeldende posisjon i kø (PIQ), eller den potensielle stillingen hvis den ennå ikke er satt i kø.
Antall agenter som er logget på eller tilgjengelig i kontaktens gjeldende anropsdistribusjonsgruppe, som samsvarer med de angitte ferdighetskriteriene.
Antall agenter som er logget på eller tilgjengelig på tvers av alle anropsdistribusjonsgrupper for den valgte køen, som samsvarer med de angitte ferdighetskriteriene.
Gjeldende anropsdistribusjonsgruppe der kontakten er parkert i en angitt kø.
Totalt antall anropsdistribusjonsgrupper i en gitt kø.

Disse detaljene gjøres tilgjengelige i flytkjøringen som aktivitetsutdatavariabler.

Hvis du vil ha mer informasjon om aktivitetsbruken, den detaljerte definisjonen og beregningsmetoden for hver kødetalj, kan du se Bygge og administrere flyter > Avansert køinformasjon.

Noen av måtene å bruke den avanserte køinformasjonen på kan være:

For å kunngjøre kontaktens posisjon i køen til kunden, mens de venter på å bli rutet.
Hvis du vil eskalere kontakten til neste anropsdistribusjonsgruppe, hvis ingen agenter som samsvarer med ferdighetskriteriene, er tilgjengelige i team som er tilordnet til gjeldende anropsdistribusjonsgruppe.
For å avgjøre om en tilbakeringing kan registreres for kunden, hvis ingen agenter som oppfyller ferdighetskriteriene, er pålogget på tvers av alle anropsdistribusjonsgrupper.

Bruk av aktiviteten Avansert køinformasjon støttes ikke når:

Informasjonen etterspørres for køer med kompetansekriterier tilordnet til kø.
Kontakten er allerede i kø, men i en annen kø enn den der informasjonen blir forespurt.
Kontakten settes i kø direkte mot en foretrukket agent.

I slike tilfeller resulterer aktiviteten i en feil, og flytkjøringen flyttes til feilbehandlingsbanen .

Tenk deg et eksempelscenario der kunden skal informeres om å motta en tilbakeringing med tanke på at ingen agenter som oppfyller ferdighetskriteriene er tilgjengelige.

Dette kan oppnås ved å bruke aktiviteten Avansert køinformasjon i flyten på følgende måte:

Aktiviteter for samtalestyring

Angi anroper-ID

Aktiviteten Angi anroper ID brukes til å definere hvem som ringer ID som skal vises under en samtale. Aktiviteten Angi anroper ID må bare brukes på PreDial-hendelsesflyter som en terminalaktivitet som markerer slutten på hendelsesflyten.

Aktiviteten Angi anroper ID gjør det mulig å konfigurere den nødvendige automatiske nummeridentifikasjonen (ANI) basert på tjenesten for identifikasjon av oppringt nummer (DNIS), operasjonstype eller deltakertype.

Hvis du vil ha mer informasjon om aktivitetsinnstillinger, bruks- og utdatavariabler, kan du se Bygge og administrere flyter > Angi anroper ID.

Kontroll av opptak

Opptakskontrollaktiviteten er utformet for å brukes sammen med en menyaktivitet for å fange opp opptakssamtykke fra den som ringer. Dette sikrer overholdelse av forskrifter eller policyer som krever eksplisitt samtykke før opptaket begynner, og integrerer dette trinnet sømløst i arbeidsflyten.

Aktiviteten Meny IVR må registrere brukerens samtykke i en boolsk variabel som vil bli tilordnet som inndata til opptakskontrollaktivitet. Hvis kunden trenger å rapportere brukersamtykket i en samtykkerapport, bør samtykkeverdien lagres i en rapporteringspliktig global variabel. Alternativt kan en lokal variabel brukes hvis rapportering ikke er nødvendig. Denne tilnærmingen gir leiere og kunder forbedret fleksibilitet når det gjelder å administrere og utnytte variabler effektivt.

Når denne aktiviteten legges til i flyten, har brukerens samtykke forrang over leiernivå eller kønivå eller konfigurasjonsinnstillinger for registrering av tidsplannivå.

Prioritetsrekkefølgen er som følger:

Hvis brukerens samtykke er Ja i flyten, blir samtalen spilt inn, uavhengig av innspillingskonfigurasjonen som er angitt på leier- eller kø- eller opptaksplannivå.
Hvis brukeren ikke samtykker som svar på aktiviteten, blir ikke samtalen tatt opp, uavhengig av innspillingskonfigurasjonen som er angitt på leier- eller kø- eller opptaksplannivå.
Hvis opptakskontrollaktiviteten ikke er konfigurert i flyten, men en konfigurasjon er satt til Ja på et av de andre nivåene, for eksempel leier eller kø eller opptaksplan, blir samtalen tatt opp.
Hvis opptakskontrollaktiviteten ikke er konfigurert i flyten, og en konfigurasjon er satt til Nei på alle nivåer, for eksempel leier, kø og opptaksplan, blir ikke samtalen tatt opp.

Denne opptakskontrollen kan illustreres som nedenfor:

I tillegg gjelder fortsatt innspillingskonfigurasjoner som Fortsett ved overføring, Pause Gjenoppta aktivert, Pausevarighet og andre i henhold til det eksisterende hierarkiet, inkludert leier-, kø- eller opptaksplannivåer.

Hvis du vil ha mer informasjon om aktivitetsinnstillinger, bruks- og utdatavariabler, kan du se Bygge og administrere flyter > Opptakskontroll.

Blindoverføring

Blind overføring er en prosess der en kontakt effektivt rutes til et eksternt oppringingsnummer (DN) gjennom IVR-systemet, noe som eliminerer behovet for agentinvolvering.

Blind overføring-aktiviteten brukes når et anrop må overføres til en ekstern eller tredjeparts DN. Dette er en terminalaktivitet, slik at strømmen avsluttes når overføringen utføres.

Blindoverføringsaktivitet støttes ikke når flyten utføres for konsultasjon.

Hvis du vil ha mer informasjon om aktivitetsinnstillinger, bruks- og utdatavariabler, kan du se Bygge og administrere flyter > blindoverføring.

Brooverført overføring

Aktiviteten Bridged Transfer gjør at en kontakt midlertidig kan overføres til et eksternt mål, mens flyten beholder kontrollen over samtalen. Det eksterne målet kan være en ekstern bro eller en Interactive Voice Response (IVR)-tjeneste.

Når det eksterne målet avslutter samtalen, fortsetter samtaleflyten videre etter behov, for eksempel ved å sette den i kø til en agent.

Brooverføringsaktiviteten fjerner køen for en kontakt under overføring til et tredjeparts IVR eller automatisk anropsdistribusjonssystem (ACD). Hvis kontakten ikke håndteres av tredjepartssystemet, kan den settes i kø igjen i den opprinnelige køen, slik at kontakten forblir i arbeidsflyten for riktig håndtering.

Anta for eksempel at et kontaktsenter har Webex Contact Center agentressurser og agentressurser på et eksternt telefonsenter eller PBX. Kunden ønsker å sette en samtale i kø mot en kø av Webex Contact Center agenter i en kort periode (for eksempel 60 sekunder). Hvis ingen agent er tilgjengelig i denne perioden, kan anropet overføres (med en implisitt dequeue) til det eksterne telefonsenteret for behandling av kontakten.

Bridged Transfer-aktivitet støttes ikke i utgående samtaleflyter og hendelsesflyter.
Kontakter som allerede er tilordnet til en agent, støttes ikke til Bridge Transfer via flyten.

Hvis du vil ha mer informasjon om aktivitetsinnstillinger, bruks- og utdatavariabler, kan du se Bygge og administrere flyter > Bridged Transfer.

Koble fra kontakt

Aktiviteten Koble fra kontakt gir mulighet til å koble fra eller avslutte en aktiv kontakt direkte fra flyten.

Dette er en terminalaktivitet som er knyttet til flyten, og kan være nyttig ved avslutning av kontakter uten agentinngrep, egnet for feilbaneflytene eller etter registrering av tilbakeringing for kunden.

Basert på konfigurasjonen utløses samtaleundersøkelsen eller tilbakemeldingen POST når kontakten avsluttes gjennom denne aktiviteten.

Hvis du vil ha mer informasjon om aktivitetsinnstillinger, bruks- og utdatavariabler, kan du se Bygge og administrere flyter > Koble fra kontakt.

Angi kontaktprioritet

Aktiviteten Angi kontaktprioritet legger til rette for effektiv styring av kontaktprioritet i flyten ved å tillate tildeling av bestemte prioritetsnivåer til kontakter. Dette gjør det mulig å få visse kontakter høyere eller lavere betydning, slik at de rutes riktig i forhold til andre ventende kontakter når agenter blir tilgjengelige. Denne fleksibiliteten gir presis kontroll over kontaktprioritering gjennom hele flyten.

Prioriteten etableres ved å tilordne et hierarkisk viktighetsnivå fra 1 (høyest) til 9 (lavest). Kontakter med høyest prioritet rutes før kontakter med lavere prioritet. Når flere kontakter deler samme prioritetsnivå, rutes kontakten som har ventet lengst, først til den neste tilgjengelige og kvalifiserte agenten. Dette systemet sikrer at kontakter med høyere prioritet får rask oppmerksomhet, samtidig som de opprettholder rettferdighet blant kontakter med lik prioritet basert på ventetiden.

Aktiviteten Angi prioritet for kontakt kan plasseres når som helst i hoved- eller hendelsesflyten.
Hvis aktiviteten Angi prioritet for kontakt konfigureres før en køaktivitet (for eksempel Køkontakt eller Kø til agent), kan prioritetsinnstillingen overstyres av enhver prioritet som er uttrykkelig konfigurert i de påfølgende køaktivitetene. Hvis følgende køaktivitet imidlertid ikke angir en prioritet, brukes kontaktprioriteten som ble angitt av den tidligere Angi kontaktprioritet-aktiviteten.
Hvis aktiviteten Angi kontaktprioritet konfigureres etter en køaktivitet (for eksempel Køkontakt eller Kø til agent), vil den overstyre prioritetsinnstillingen som er konfigurert av den foregående køaktiviteten.
Aktiviteten Angi prioritet for kontakt støttes for øyeblikket ikke for utringings- og kampanjekontakter.

Hvis du vil ha mer informasjon om aktivitetsinnstillinger, bruks- og utdatavariabler, kan du se Bygge og administrere flyter > Angi kontaktprioritet.

Tilbakeringingsaktiviteter

Tilbakeringing

En tilbakeringingsaktivitet gjør det mulig for innringere å be om tilbakeringing i stedet for å vente på vent, noe som forbedrer kundetilfredsheten betydelig ved å redusere ventetiden og minimere avbruddsraten. Når tilbakeringingsaktiviteten er aktivert, opprettes en oppgave i en kø, slik at en tilgjengelig agent kan returnere kundens anrop.

Flytdesigneren kan konfigurere aktiviteten slik at den enten beholder kontakten i den opprinnelige køen der anropet ble startet, eller tilordne den til en annen kø basert på innstillinger. Hvis tilbakeringingen forblir i den opprinnelige køen, beholder kontakten posisjonen, ferdighetene, prioriteten og kontekstuelle dataene, noe som muliggjør sømløs tilordning til neste tilgjengelige agent. Hvis imidlertid en annen kø er valgt, skyves kontakten til slutten av den valgte køen uten kompetanse og med standardprioritet.

Aktiviteten lar også kundene be om tilbakeringinger fra sine foretrukne agenter, noe som gir opplevelsen et personlig preg og forbedrer kundetilfredsheten. Dette kan oppnås når tilbakeringingsaktiviteten følger en QueueToAgent-aktivitet i flyten. I tillegg tilbyr tilbakeringingsaktiviteten en valgfri konfigurasjon for tilpassing av automatisk nummeridentifikasjon (ANI) som brukes under tilbakeringingsprosessen. Denne tilpasningen bidrar til merkevarekonsistens og reduserer sannsynligheten for anropsavvisning ved å sikre en gjenkjennelig innringer ID.

Flytdesigneren har muligheten til å inkludere en TilbakeringingMislyktes-hendelse i hendelsesflyten. Denne hendelsen utløses når et tilbakeringingsforsøk mislykkes, slik at flytutformeren kan implementere nye forsøk med bestemte intervaller. Forsinkelsen eller intervallet mellom nye forsøk kan konfigureres ved hjelp av venteaktiviteten, med et minimum nytt forsøksintervall på 10 sekunder og maksimalt 72 timer. Systemet støtter opptil 10 nye forsøk over en periode på maksimalt 14 dager ved bruk av venteaktiviteten.

Hvis du vil ha mer informasjon om aktivitetsinnstillinger, bruks- og utdatavariabler, kan du se Bygge og administrere flyter > tilbakeringing.

Planlegg tilbakeringing

Med den planlagte tilbakeringingsaktiviteten kan flyten tilby kundene bekvemmeligheten ved å be om tilbakeringing på en bestemt fremtidig dato og klokkeslett, noe som eliminerer behovet for umiddelbar tilkobling til en agent. Denne funksjonen forbedrer kundeopplevelsen ved å gjøre det mulig for dem å velge et praktisk tilbakeringingsvindu, og dermed minimere oppfattede ventetider og redusere avbruddsfrekvensen for anrop.

Flyten må fange opp anroperens inndata, for eksempel foretrukket dato og klokkeslett, via DTMF-meldinger og sende dem til aktiviteten etter å ha utført de nødvendige inndatavalideringene.

Før du begynner, må du kontrollere at standard tilbakeringingspunkt er konfigurert under Kanalinnstillinger i kontrollhuben. Hvis du vil ha mer informasjon, kan du se Konfigurere et inngangspunkt for tilbakeringing.

Tilbakeringingen kan planlegges ved hjelp av en hvilken som helst telefonikø, enten innkommende eller utgående. For best resultat anbefales det å legge til en Koble fra-aktivitet umiddelbart etter den planlagte tilbakeringingsaktiviteten for å sikre at den gjeldende samtalen avsluttes på riktig måte når tilbakeringingen er planlagt. Hvis du vil ha mer informasjon om planlegging av IVR tilbakeringinger, kan du se Planlegge IVR tilbakeringinger.

Når tilbakeringingen utløses på ønsket fremtidig dato og klokkeslett, opprettes et nytt anrop eller en ny samhandling. Denne nye samhandlingen følger standardflyten som er koblet til standardinngangspunktet for tilbakeringing. Hvis tilbakeringingsforsøket mislykkes, kan flyten prøve anropet automatisk på nytt ved hjelp av hendelsesbehandlingen Tilbakeringingmislykket hvis dette er konfigurert i den flyten .

Følgende valideringer av inndata bør vurderes før inndata sendes til aktiviteten:

Datovalg – Du kan velge en hvilken som helst dato opptil 31 dager frem i tid fra i dag. Datoen må være i dette formatet: ÅÅÅÅ-MM-DD (for eksempel 2025-07-18).
Start- og sluttidspunkt for tidsvinduet – Klokkeslettet du velger, må starte minst 30 minutter fra nå og kan vare Anywhere mellom 30 minutter og 8 timer. Bruk 24-timers tidsformat (som 14:30:00).
Tidssone – Du må angi en gyldig tidssone i IANA-format (for eksempel America/New_York) slik at vi kan ringe deg til rett tid.

En referanseimplementering gis i form av en underflytmal for å demonstrere DTMF-ledetekstene og de grunnleggende valideringene som brukes sammen med aktiviteten. Hvis du vil ha mer informasjon, kan du se Mal for underflyt for planlagt tilbakeringing.

Analyse av samtalefremdrift

CPA (Call Progress Analysis Analysis) gjør det mulig å oppdage automatiserte svarsystemer og aktive menneskelige stemmer ved tilbakeringingsanrop.

Når et tilbakeringingsforsøk støter på en telefonsvarer (AMD) eller talepost, identifiserer systemet anropet som mislykket. Resultatet av AMD (Phoneing Machine Detection) registreres i årsaksutgangsvariabelen i hendelsesbehandlingen CallbackFailed. Basert på denne utdatavariabelen kan flytutformeren konfigurere nye tilbakeringingsforsøk.

For høflig tilbakeringing kan CallProgressAnalysis plasseres på et punkt etter tilbakeringingsaktiviteten i hovedflyten. For planlagt tilbakeringing eller personlig planlagt tilbakeringing kan den plasseres etter NyTelefonKontakt i hovedflyten.
I hendelsesflyten støttes den bare i hendelsesbehandlingen Tilbakeringingmislykket.
Hvis en kundeundersøkelse for POST-anrop (tilbakemeldingsaktivitet) er konfigurert i flyten, startes den ikke hvis anropet besvares av en AMD eller talepost. Dette forhindrer utløsing av unødvendige undersøkelser.

Hvis du vil ha mer informasjon om aktivitetsinnstillinger, bruks- og utdatavariabler, kan du se Bygge og administrere flyter > Analyse av anropsfremdrift.

Cisco AI Assistant

Takk for tilbakemeldingen.

Oversikt

Typer køer

Ikke-ferdighetsbaserte køer

Ikke-ferdighetsbaserte køer med teamoppgaver

Ikke-ferdighetsbaserte køer med agenttilordninger

Ferdighetsbaserte køer

Kompetansekriterier tilordnet til kø

Kompetansekrav tilordnet i flyt

Køkonfigurasjon

Konfigurer ferdighetsbaserte køer

Tilordne ferdighetskriterier til en kø

Tilordne kompetansekrav til en kø

Konfigurer ikke-ferdighetsbaserte køer

Tilordne team til en kø

Tilordne agent til en køflyt

Rutingskonsepter

Agentoverskudsscenario

Scenario for kontaktoverskudd

Blandede multimedieprofiler

Rutingsmønstre

Ferdighetsbasert

Lengst tilgjengelig

Best tilgjengelig

Ikke-ferdighetsbasert ruting

Lengst tilgjengelig

Sirkulær

Ovenfra og ned

Agentbasert ruting

Køings- og rutingsfunksjoner i flyt

Aktiviteter i kø

Køkontakt

Kø til agent

Eskalere samtaledistribusjonsgruppe

Aktiviteter for køinformasjon

Hent informasjon om kø

Avansert køinformasjon

Aktiviteter for samtalekontroll

Angi innringer-ID

Opptakskontroll

Blind overføring

Brolagt overføring

Koble fra kontakten

Angi kontaktprioritet

Tilbakeringingsaktiviteter

Tilbakeringing

Planlegg tilbakeringing

Analyse av samtalefremdrift

Oversikt

Typer køer

Ikke-ferdighetsbaserte køer

Ikke-ferdighetsbaserte køer med teamtildelinger

Ikke-ferdighetsbaserte køer med agenttildelinger

Ferdighetsbaserte køer

Ferdighetskriterier tilordnet kø

Ferdighetskrav tildelt i flyt

Køkonfigurasjon

Sett opp ferdighetsbaserte køer

Tilordne ferdighetskriterier til en kø

Tilordne ferdighetskrav til en kø

Sett opp køer som ikke er ferdighetsbaserte

Tilordne team til en kø

Tilordne agent til en køflyt

Rutekonsepter

Agentoverskuddsscenario

Kontaktoverskuddsscenario

Blandede multimediaprofiler

Rutemønstre

Ferdighetsbasert

Lengst tilgjengelig

Best tilgjengelig

Ikke-ferdighetsbasert ruting

Lengst tilgjengelig

Sirkulær

Ovenfra og ned

Agentbasert ruting

Kø- og rutingfunksjoner i Flow

Køaktiviteter

Køkontakt