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

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

Du kan oprette disse typer hold:

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

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

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

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

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

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

En funktion kaldet 'Kontroller agenttilgængelighed' får kontakten til øjeblikkeligt at blive udvidet til den efterfølgende opkaldsdistributionsgruppe, hvis der ikke findes matchende agenter i den aktuelle gruppe. Dette kan aktiveres i aktiviteten Køkontakt <LINK TIL afsnit 3.1.1> i flowet.

Denne opsætning resulterer i følgende scenarier:

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

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

Tilgængeligt rutemønster:

• Længst tilgængelig

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

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

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

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

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

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

Tilgængelige routingmønstre:

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

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

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

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

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

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

I dette eksempel

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

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

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

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

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

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

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

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

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

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

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

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

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

Der er dog to hovedting at bemærke:

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

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

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

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

I dette eksempel

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

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

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

Tilgængelige routingmønstre:

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

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

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

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

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

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

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

• Kørangering

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

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

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

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

    • Kørangering fungerer inden for den samme medietype.

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

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

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

• Kontaktprioritet

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

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

• Længst ventende kontakt

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

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

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

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

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

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

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

Nu fungerer kontaktoverskudsscenariet som følger:

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

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

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

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

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

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

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

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

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

Der er tre valgmuligheder:

• Ekskludering

• Kombineret

• Blandet i realtid

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

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

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

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

Agentbaseret routing er en funktion, der routerer eller sætter en kontakt direkte i kø til en bestemt ("foretrukket") agent. Et agentopslag med agentens e-mailadresse eller agentens ID dirigerer en kontakt til den foretrukne agent. Aktiviteten "Kø til agent" i flowet hjælper med at opnå agentbaseret routing. For mere information, se Kø til agent aktivitet.

En kontakt kan have en tilknytning til en eller flere foretrukne agenter, som typisk kan administreres i en ekstern applikation uden for Webex Contact Center. Opslaget for en kontaktperson efter en foretrukken agent udføres via HTTP-anmodning aktivitet, som henter kortlægningen fra en ekstern applikation. For at dirigere eller parkere kontakten med den foretrukne agent skal du konfigurere aktiviteten "Sæt i kø til agent" ved hjælp af agentens Webex Contact Center-id eller e-mailadresse. Kontakten kan også parkeres mod en foretrukken agent, hvis denne foretrukne agent ikke er tilgængelig med det samme.

Agentbaseret routing er nyttig i følgende scenarier:

• Foretrukken agentrute Kunden kan tildele kontakter til dedikerede agenter eller relationsansvarlige. I sådanne scenarier sender den agentbaserede routing kontakterne direkte til den foretrukne agent.
• Sidste agent-routing: Når en kontakt ringer tilbage til kontaktcenteret flere gange for at interagere med en agent, kan agentbaseret routing dirigere kontakten til den sidste agent, der håndterede den pågældende kontakt.

I begge anvendelsesscenarier gemmes oplysningerne om kontakten og agenttilknytningen uden for Webex Contact Center.

Aktiviteten "Sæt kontakt i kø" giver mulighed for at sætte en kontakt i en aktiv indgående kø fra organisationen, så den kan matches og dirigeres til den rigtige agent i den pågældende kø.

Følgende aspekter af køstyring kan håndteres gennem denne aktivitet:

• Prioritet - Tildeling af en hierarkisk vigtighed fra 1 (højest) til 10 (lavest, standard) til den kontakt, der sættes i kø.
• Færdighedskrav - Angiv de færdighedskriterier, som agenter i en færdighedsbaseret kø skal opfylde for at blive betragtet som berettigede til at dirigere kontakten.
• Færdighedsafslapninger - Justering, ændring eller fjernelse af tidligere fastsatte færdighedskrav efter et stykke tid for at forbedre chancerne for at finde en agent.
• Tjek agenttilgængelighed - Giv systemet mulighed for øjeblikkeligt at udvide sig gennem alle opkaldsdistributionsgrupper, hvor der ikke findes tilgængelige agenter, for at undgå ventetid.

Se Routing for yderligere information om, hvordan prioritet, færdighedskonfiguration og agenttilgængelighed spiller en rolle i routing af kontakter.

Når aktiviteten "Sæt kontakt i kø" har sat kontakten i kø,

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

  Dette afbryder Hovedflowets udførelse, og yderligere hændelser kan udløse de respektive Hændelsesflows, hvis de er konfigureret.

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

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

  • Afspil en forudkonfigureret musik til kunden, der venter i køen - ved at tilknytte en AfspilMusik aktivitet.
  • Registrer et tilbagekald baseret på kundens anmodning - ved at vedhæfte en Tilbagekald aktivitet.
  • Sæt kontakten i kø igen, dvs. fjern kontakten fra den nuværende kø og tilføj den til en ny kø - ved at tilknytte en anden køkontakt eller kø til agentaktiviteten .

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

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

I sådanne tilfælde resulterer aktiviteten i en fejl, og flow-udførelsen flyttes til Fejlhåndtering stien.

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

Aktiviteten "Sæt i kø til agent" giver mulighed for at sætte kontakten direkte i kø til en foretrukken agent ved at slå deres unikke agent-ID eller e-mailadresse op i Webex Contact Center.

Følgende aspekter af køstyring kan håndteres gennem denne aktivitet:

• Prioritet - Tildel en højere/lavere vigtighed til de kontakter, der er i kø hos den samme agent.
• Rapporteringskø - Identificer den kø, der skal bruges til konfiguration, f.eks. optagelse og standardmusik i kø, og rapportformål for kontakten.
• Gendannelseskø - Identificer den kø, der skal bruges som reserve, når kontakten ikke kunne dirigeres til den angivne foretrukne agent.

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

• Hvis agenten allerede er tilgængelig, bliver kontakten sendt videre til agenten.

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

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

  I genoprettelseskøen vil kontakten blive dirigeret til den længst tilgængelige agent, uden understøttelse af færdigheder.

• Hvis agenten ikke er tilgængelig og " Parkkontakt hvis agent ikke er tilgængelig "muligheden er udvalgte, kontakten parkeres og venter på, at agenten bliver tilgængelig.

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

  • Afspil forudkonfigureret musik til kunden, der venter i køen - ved at tilslutte en Afspil Musik aktivitet.
  • Tilbagekald aktivitet.
  • Sæt kontakten i kø igen, dvs. fjern kontakten fra den nuværende kø og tilføj den til en ny kø - ved at tilknytte en anden Kø til agent eller Køkontakt aktivitet.

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

  Dette afbryder Hovedstrøm udførelse og yderligere begivenheder kan udløse de respektive Begivenhedsflows, hvis konfigureret.

• Hvis agenten ikke er tilgængelig og " Parkkontakt hvis agent ikke er tilgængelig "muligheden er ikke valgt, køen mislykkes.

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

For yderligere information om aktivitetsindstillinger, brug og outputvariabler, se Opbyg og administrer flows > Kø til agent.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Optagelseskontrolaktiviteten er designet til at blive brugt sammen med en menuaktivitet til at registrere optagelsessamtykke fra opkalderen. Dette sikrer overholdelse af regler eller politikker, der kræver udtrykkeligt samtykke, før optagelsen begynder, og integrerer problemfrit dette trin i arbejdsgangen.

Aktiviteten Menu IVR skal registrere brugerens samtykke i en boolesk variabel, der tildeles som input til aktivitet i Optagelseskontrol. Hvis kunden har brug for at rapportere brugerens samtykke i en samtykkerapport, skal samtykkeværdien gemmes i en rapporterbar global variabel. Alternativt kan du bruge en lokal variabel, hvis rapportering ikke er påkrævet. Denne tilgang giver lejere og kunder øget fleksibilitet til at administrere og udnytte variabler effektivt.

Når denne aktivitet føjes til flowet, har brugerens samtykke forrang over konfigurationsindstillingerne for lejer- eller køniveau eller optagelsesplanniveau.

Prioritetsrækkefølgen er som følger:

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

Dette optagelseskontrolelement kan illustreres som følger:

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

Du kan finde flere oplysninger om aktivitetsindstillinger, forbrugs- og outputvariabler under Oprette og administrere flows > Optagelseskontrol.

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

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

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

Du kan finde flere oplysninger om aktivitetsindstillinger, brugs- og outputvariabler i Oprette og administrere flows > Blind overførsel.

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

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

Brooverførselsaktiviteten sætter en kontakt ud af køen, mens den overføres til et tredjepartssystem med IVR eller automatisk opkaldsdistribution (ACD). Hvis kontakten ikke håndteres af tredjepartssystemet, kan den sættes i kø igen i den oprindelige kø, hvilket sikrer, at kontakten forbliver i workflowet til korrekt håndtering.

Antag f.eks., at et kontaktcenter har Webex Contact Center agentressourcer og agentressourcer på et eksternt callcenter eller PBX (Private Branch Exchange). Kunden ønsker at sætte et opkald i kø i en kø af Webex Contact Center-agenter i en kort periode (f.eks. 60 sekunder). Hvis der ikke er nogen agent tilgængelig i denne periode, kan opkaldet derefter overføres via bro (med en implicit dekø) til det eksterne callcenter til håndtering af kontakten.

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

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

Dette er en terminalaktivitet, der er knyttet til flowet, og som kan være nyttig til afslutning af kontakter uden agentintervention, der er egnet til fejlstiflow, eller efter registrering af et tilbagekald for kunden.

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

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

Aktiviteten Angiv kontaktprioritet muliggør effektiv administration af kontaktprioriteter i flowet ved at tillade tildeling af specifikke prioritetsniveauer til kontakter. Dette gør det muligt at tillægge visse kontakter højere eller mindre vigtighed, hvilket sikrer, at de distribueres korrekt i forhold til andre ventende kontakter, når agenter bliver tilgængelige. Denne fleksibilitet giver mulighed for præcis kontrol over kontaktprioritering gennem hele flowet.

Prioriteten fastlægges ved at tildele et hierarkisk vigtighedsniveau fra 1 (højest) til 9 (lavest). Kontakter med højeste prioritet distribueres før kontakter med lavere prioriteter. Når flere kontakter deler det samme prioritetsniveau, distribueres den kontakt, der har ventet længst, først til den næste tilgængelige og berettigede agent. Dette system sikrer, at kontakter med højere prioritet får hurtig opmærksomhed, samtidig med at der opretholdes retfærdighed blandt kontakter med samme prioritet baseret på deres ventetid.

Du kan finde flere oplysninger om aktivitetsindstillinger, brugs- og outputvariabler i Oprette og administrere flows > angive kontaktprioritet.

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

Flowdesigneren kan konfigurere aktiviteten til enten at beholde kontakten i den oprindelige kø, hvor opkaldet kom fra, eller tildele den til en anden kø baseret på præferencer. Hvis tilbagekaldet forbliver i den oprindelige kø, bevarer kontakten sin position, sine færdigheder, sin prioritet og sine kontekstafhængige data, hvilket giver mulighed for problemfri tildeling til den næste tilgængelige agent. Men hvis der vælges en anden kø, skubbes kontakten til slutningen af den valgte kø uden kvalifikationer og med standardprioritet.

Aktiviteten giver også kunderne mulighed for at anmode om tilbagekald fra deres foretrukne agenter, hvilket tilføjer et personligt præg til oplevelsen og forbedrer kundetilfredsheden. Dette kan opnås, når tilbagekaldsaktiviteten følger en QueueToAgent-aktivitet i flowet. Derudover tilbyder tilbagekaldsaktiviteten en valgfri konfiguration til tilpasning af ANI (Automatic Number Identification), der bruges under tilbagekaldsprocessen. Denne tilpasning hjælper med brandkonsistens og reducerer sandsynligheden for afvisning af opkald ved at sikre et genkendeligt opkalds-id.

Flowdesigneren har mulighed for at medtage hændelsen CallbackFailed i hændelsesflowet. Denne hændelse udløses, når et tilbagekaldsforsøg mislykkes, hvilket gør det muligt for flowdesigneren at implementere nye forsøg med bestemte intervaller. Forsinkelsen eller intervallet mellem nye forsøg kan konfigureres ved brug af venteaktiviteten med et interval for nyt forsøg på mindst 10 sekunder og maksimalt 72 timer. Systemet understøtter op til 10 nye forsøg over en periode på maksimalt 14 dage ved brug af venteaktiviteten.

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

Aktiviteten Planlagt tilbagekald giver flowet mulighed for at tilbyde kunderne bekvemmeligheden ved at anmode om et tilbagekald på en bestemt fremtidig dato og et bestemt tidspunkt i fremtiden – hvilket eliminerer behovet for øjeblikkelig forbindelse til en agent. Denne funktion forbedrer kundeoplevelsen ved at give dem mulighed for at vælge et praktisk tilbagekaldsvindue, hvorved opfattede ventetider minimeres og reducerer antallet af afbrudte opkald.

Flowet skal registrere opkalderens input, f.eks. foretrukken dato og klokkeslæt, via DTMF-prompter og sende dem til aktiviteten efter at have udført de nødvendige inputvalideringer.

Tilbagekaldet kan planlægges ved hjælp af en hvilken som helst telefonikø – uanset om det er indgående eller udgående. For at opnå de bedste resultater anbefales det at tilføje en afbrydelsesaktivitet umiddelbart efter den planlagte tilbagekaldsaktivitet for at sikre, at det aktuelle opkald afsluttes korrekt, når tilbagekaldet er planlagt. Du kan finde flere oplysninger om planlægning af IVR-tilbagekald under Planlægge IVR tilbagekald.

Når tilbagekaldet udløses på den ønskede fremtidige dato og det ønskede tidspunkt, oprettes der et nyt opkald eller en ny interaktion. Denne nye interaktion følger det standardflow, der er knyttet til standardindgangspunktet for tilbagekald. Hvis forsøg på tilbagekald mislykkes, kan flowet automatisk prøve opkaldet igen ved hjælp af hændelseshandleren CallbackFailed, hvis det er konfigureret i det pågældende flow.

Der leveres en referenceimplementering i form af en underflowskabelon for at demonstrere de DTMF-prompter og grundlæggende valideringer, der bruges sammen med aktiviteten. Du kan finde flere oplysninger i Skabelon til underflow for planlagt tilbagekald.

Aktiviteten Analyse af opkaldsfremdrift (CPA) gør det muligt at registrere automatiske telefonsvarer og levende menneskestemmer ved tilbagekaldsopkald.

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

Du kan finde flere oplysninger om aktivitetsindstillinger, brugs- og outputvariabler i Oprette og administrere flows > Analyse af opkaldsstatus.