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.

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:

1. 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.
2. 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 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.

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
• Sirkelrund
• Lineær/ovenfra og ned

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.

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.

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 som 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.

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

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 arbeidsbelastninger for agenter 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.

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ø.

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 kundene, fremme bedre servicekvalitet, 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:

• Eksklusiv – bare én kontakt av en hvilken som helst medietype kan håndteres av agenten om gangen.

  Dette er nyttig når organisasjonen forventer at agenter skal fokusere fullstendig på én oppgave om gangen.

• Blandet – Et hvilket som helst antall kontakter for hver medietype kan håndteres samtidig, opptil kapasiteten til konfigurerte kanaler.

  Dette er nyttig når en organisasjon forventer at agenter skal utføre flere oppgaver samtidig og arbeide med flere kontakter på tvers av ulike medietyper.

• Blended-Realtime - Samme som blandet, men tale og chat er gjensidig utelukkende. Hvis tale håndteres, blir ikke chatkontakter presentert, og omvendt.

  Dette er nyttig når organisasjonen forventer at agenter skal utføre flere oppgaver samtidig, men likevel tillater agenten å fokusere på én enkelt sanntidskontakt (tale eller chat), slik at agenten kan være fullt oppmerksom på sluttkunden i den andre enden.

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

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åkferdigheter 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.

Webex Contact Center støtter også en rekke ikke-ferdighetsbaserte rutingmønstre som fokuserer på å distribuere innkommende kundeinteraksjoner uten å vurdere de spesifikke ferdighetene eller ekspertisen til agenter. 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.

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 agent-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 hjelp av 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 brukstilfeller lagres detaljene for kontakten og agenttilordningen utenfor Webex Contact Center.

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.

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økontakt.

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.

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.

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.

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.

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.

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:

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.

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:

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

Aktiviteten Angi anroper-ID tillater konfigurering av den nødvendige automatiske nummeridentifikasjonen (ANI) basert på DNIS-tjenesten (Dialed Number Identification Service), operasjonstype eller deltakertype.

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

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.

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.

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.

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

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.

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 anroper-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.

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.

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