Tak for din feedback.

Kø Kontakt-aktiviteten giver mulighed for at kø en kontakt ind i en aktiv indgående kø fra organisationen, så den kan matches og dirigeres til den rigtige agent i den kø.

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

• Priority - Tildele en hierarkisk betydning fra 1 (højeste) til 10 (laveste, standard) til den kontakt, der køres.
• Skill Requirements - Angiv de kvalifikationskriterier, der skal opfyldes af agenter i en færdighed-baseret kø, for at blive betragtet som berettigede til routing af kontakten.
• Skill Relaxations - Tuning, modifikation eller fjernelse af tidligere fastsatte færdighedskrav efter en periode for at forbedre chancerne for at finde en agent.
• Check Agent Availability - Lad systemet øjeblikkeligt udvide sig gennem alle Call Distribution Groups, hvor der ikke findes nogen tilgængelige agenter, for at undgå ventetid.

Se Rutevejledning, for at få flere oplysninger om, hvordan prioritet, færdighedskonfiguration og agenttilgængelighed spiller en rolle i routing-kontakter.

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

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

  Dette afbryder Main flow udførelse og yderligere begivenheder kan udløse de respektive Event Flows, hvis konfigureret.

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

  Flowudførelsen fortsætter derefter med de aktiviteter, der er vedhæftet efter Kø Kontakt aktivitet, som giver mulighed for at:

  • Afspil en forudindstillet musik til kunden, der venter i kø - ved at vedhæfte en PlayMusic aktivitet.
  • Registrer en tilbagekaldelse baseret på kundens anmodning - ved at vedhæfte en Callback aktivitet.
  • Re-kø dvs. fjern kontakten fra den aktuelle kø og tilføj den i en ny kø - ved at vedhæfte en anden Queue Contact eller Queue to Agent aktivitet.

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

Når det lykkes, afbryder det Main flow udførelse og yderligere begivenheder kan udløse de respektive Event Flows, hvis konfigureret.

I sådanne tilfælde resulterer aktiviteten i en fiasko, og gennemstrømningen flyttes til Error Handling vej.

For mere information om aktivitetsindstillinger, forbrug og outputvariabler, se Byg og håndtér strømme > Kø Kontakt2.

Aktiviteten Queue to Agent giver mulighed for at sætte kontakten i kø direkte til en foretrukken agent ved at kigge på deres unikke agent-id eller e-mailadresse i Webex Contact Center.

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

• Priority - Tildele højere/lavere betydning til de kontakter, der køes mod den samme agent.
• Reporting Queue - Identificer den kø, der skal bruges til konfiguration, såsom optagelse og standard musik-i-kø, og rapportér formålet med kontakten.
• Recovery Queue - Identificer den kø, der skal bruges som en faldback, når kontakten ikke kunne omdirigeres til den angivne foretrukne agent.

Når aktiviteten i Kø Til Agent med succes køer kontakten,

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

  Dette afbryder Main flow udførelse og yderligere begivenheder kan udløse de respektive Event Flows, hvis konfigureret.

• Hvis agenten er tilgængelig, men vælger at afslå, ikke svarer eller ikke modtager kontakten, flyttes den ind i den leverede genoprettelseskø.

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

• Hvis agenten ikke er tilgængelig og "Park Contact If Agent Unavailable" mulighed er selected, kontakten bliver parkeret og venter på, at agenten bliver tilgængelig.

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

  • Afspil en forudindstillet musik til kunden, der venter i kø - ved at vedhæfte en PlayMusic aktivitet.
  • Callback aktivitet.
  • Re-kø dvs. fjern kontakten fra den aktuelle kø og tilføj den i en ny kø - ved at vedhæfte en anden Queue to Agent eller Queue Contact aktivitet.

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

  Dette afbryder Main flow udførelse og yderligere begivenheder kan udløse de respektive Event Flows, hvis konfigureret.

• Hvis agenten ikke er tilgængelig og "Park Contact If Agent Unavailable" mulighed er not selected, køen fejler.

I sådanne tilfælde resulterer aktiviteten i en fiasko, og gennemstrømningen flyttes til Error Handling vej.

For mere information om aktivitetsindstillinger, forbrug og outputvariabler, se Byg og håndtér strømme > Kø til agent2.

Aktiviteten Escalate Call Distribution Group understøttes kun for queues with team assignment, og giver mulighed for at opdatere Call Distribution Group 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 omdirigere kontakten til alle godkendte agenter i køen.

Ved at bruge aktiviteten Escalate Call Distribution Group kan kontakten eskaleres til:

• Next Group—Udvide antallet af hold til at omfatte dem, der er tilføjet i den umiddelbare næste opkaldsdistributionsgruppe.
• Last Group—Udvidelse af sæt af hold til at omfatte alle hold, der er kortlagt på tværs af alle opkaldsdistributionsgrupper, der er konfigureret til køen.

I sådanne tilfælde resulterer aktiviteten i en fiasko, og gennemstrømningen flyttes til Error Handling vej.

Overvej et eksempel scenarie, hvor en kontakt står i kø i en kø med tre opkaldsdistributionsgrupper, som hver opdateres efter en periode på 30 sekunder.

Der er ingen agenter til rådighed i holdene del af CDG 1 og CDG 2, og en agent er tilgængelig i TEAM 3 som tilhører den sidste opkaldsdistributionsgruppe.

Når aktiviteten Escalate Call Distribution Group ikke bruges i flow, resulterer det i en lang ventetid, som illustreret nedenfor:

Ventetiden kan reduceres ved at bruge aktiviteten Escalate Call Distribution Group bruges som følger:

Baseret på Next Group eller Last Group valgt mulighed, bliver ventetiden for kontakten betydeligt reduceret, som illustreret nedenfor:

For mere information om aktivitetsindstillinger, forbrug og outputvariabler, se Byg og håndter strømme > Eskalere Call Distribution Group2.

Aktiviteten Get Queue Info giver mulighed for at hente oplysninger om kø i realtid for en given kontakt, såsom:

• Kontaktens aktuelle position i kø (PIQ), eller den potentielle position, hvis den endnu ikke er i kø.
• Forventet ventetid (EWT) eller den varighed, som en opgave forventes at vente i køen, inden den besvares.
• Antallet af agenter, der er logget ind eller tilgængelige i kontaktens nuværende Call Distribution Group.
• Antallet af agenter, der er logget ind eller tilgængelige på tværs af alle Call Distribution Groups for den valgte kø.
• Hvor længe den ældste kontakt i køen har ventet.

Disse oplysninger stilles til rådighed i flowudførelsen som aktivitetsoutput variabler.

For mere information om aktivitetsforbrug, den detaljerede definition og beregningsmetode for hver kø, se Byg og håndtér strømme > Få kø-info2.

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

• At meddele kontaktens position i kø og forventet ventetid til kunden, mens de venter på at blive omdirigeret.
• At afgøre, om en tilbagekaldelse kan registreres for kunden, hvis den forventede ventetid er for lang.
• For at eskalere kontakten til næste opkaldsdistributionsgruppe (CDG), hvis der ikke er nogen agenter til rådighed i hold, der er kortlagt til den nuværende CDG.

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

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

Dette kan opnås ved hjælp af Get Queue Info-aktiviteten i strømmen som følger:

Aktiviteten Advanced Queue Info giver mulighed for at hente oplysninger om kø i realtid for en given kontakt, idet der desuden tages hensyn til kontaktens kvalifikationskriterier, såsom:

• Kontaktens aktuelle position i kø (PIQ), eller den potentielle position, hvis den endnu ikke er i kø.
• Antallet af agenter, der er logget ind eller tilgængelige i kontaktens nuværende opkaldsdistributionsgruppe, der matcher de givne kvalifikationskriterier.
• Antallet af agenter, der er logget ind eller tilgængelige på tværs af alle opkaldsdistributionsgrupper for den valgte kø, svarende til de givne kvalifikationskriterier.
• Den aktuelle opkaldsdistributionsgruppe, hvor kontakten er parkeret i en given kø.
• Det samlede antal opkaldsdistributionsgrupper i en given kø.

Disse oplysninger stilles til rådighed i flowudførelsen som aktivitetsoutput variabler.

For mere information om aktivitetsforbrug, den detaljerede definition og beregningsmetode for hver kø, se Byg og håndter strømme > Avanceret kø Info2.

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

• At meddele kontaktens position i køen til kunden, mens de venter på at blive omdirigeret.
• For at eskalere kontakten til næste opkaldsdistributionsgruppe, hvis der ikke findes agenter, der matcher kvalifikationskriterierne, i hold, der er kortlagt til den aktuelle opkaldsdistributionsgruppe.
• For at afgøre, om en tilbagekaldelse kan registreres for kunden, hvis ingen agenter, der opfylder kvalifikationskriterierne, er logget ind på tværs af alle opkaldsdistributionsgrupper.

I sådanne tilfælde resulterer aktiviteten i en fiasko, og gennemstrømningen flyttes til Error Handling vej.

Overvej et eksempel, hvor kunden skal informeres om at modtage en tilbagekaldelse i betragtning af, at der ikke findes agenter, der opfylder kvalifikationskriterierne.

Dette kan opnås ved at bruge aktiviteten Advanced Queue Info i strømmen som følger:

Aktiviteten Sæt opkalds-id bruges til at definere det opkalds-id, der skal vises under et opkald. Aktiviteten Set Caller ID må kun bruges på Predial Event Flows som en terminal aktivitet, der markerer slutningen af begivenhedsstrømmen.

Aktiviteten Set Caller ID gør det muligt at konfigurere den krævede Automatic Number Identification (ANI) baseret på Dialed Number Identification Service (DNIS), operationstype eller deltagertype.

For mere information om aktivitetsindstillinger, forbrug og outputvariabler, se Byg og håndtér strømme > Sæt opkalds-id2.

Aktiviteten Optagelseskontrol er designet til at blive brugt sammen med en Menu-aktivitet til at fange optagelsesindehaverens samtykke. Dette sikrer overholdelse af regler eller politikker, der kræver udtrykkeligt samtykke, før registreringen begynder, og integrerer dette trin problemfrit i arbejdsprocessen.

Menu IVR-aktiviteten skal indfange brugerens samtykke i en boolesk variabel, som vil blive tildelt som input til aktiviteten Recording Control. Hvis kunden skal indberette brugerens samtykke i en samtykkeerklæring, skal samtykkeværdien opbevares i en indberetningspligtig global variabel. Alternativt kan en lokal variabel bruges, hvis rapportering ikke er påkrævet. Denne tilgang giver lejere og kunder øget fleksibilitet i forvaltningen og udnyttelsen af variabler effektivt.

Når denne aktivitet føjes til strømmen, går brugerens samtykke forud for lejerens niveau eller kø niveau eller optageplan niveau konfigurationsindstillinger.

Prioritetsrækkefølgen er som følger:

• Hvis brugerens samtykke er Ja i strømmen, registreres opkaldet, uanset optagekonfigurationen, der er indstillet på lejer- eller kø- eller optagetidsplanen.
• Hvis brugeren ikke giver sit samtykke som svar på aktiviteten, registreres opkaldet ikke, uanset den optagelseskonfiguration, der er indstillet på lejer- eller kø- eller optagelsesplanniveau.
• Hvis aktiviteten Optagelseskontrol ikke er konfigureret i strømmen, men en konfiguration er indstillet til Ja på et af de andre niveauer, f.eks. lejer eller kø eller optagelsesplan, registreres opkaldet.
• Hvis aktiviteten Optagelseskontrol ikke er konfigureret i strømmen, og en konfiguration er indstillet til Nej på alle niveauer såsom lejer, kø og optagelsesplan, registreres opkaldet ikke.

Denne optagelseskontrol kan illustreres som følger:

Derudover gælder optagelseskonfigurationer som Fortsæt på overførsel, Pause genoptag aktiveret, Pause varighed og andre fortsat i henhold til det eksisterende hierarki, herunder lejer, kø eller optagelsesplan niveauer.

For mere information om aktivitetsindstillinger, forbrug og outputvariabler, se Byg og administrer strømme > Registreringskontrol2.

Blind Transfer er en proces, hvor en kontakt effektivt ledes til et eksternt Dial Number (DN) gennem IVR-systemet, hvilket eliminerer behovet for agentinvolvering.

Aktiviteten Blind Transfer bruges, når et opkald skal overføres til et eksternt eller tredjeparts DN. Dette er en terminal aktivitet, så strømmen slutter, når overførslen er udført.

Blind Transfer-aktivitet understøttes ikke, når strømmen udføres til høring.

For mere information om aktivitetsindstillinger, forbrug og outputvariabler, se Byg og administrer strømme > Blind overførsel2.

Med Bridged Transfer-aktiviteten kan en kontakt midlertidigt overføres til en ekstern destination, mens strømmen bevarer kontrollen over opkaldet. Den eksterne destination kan være en ekstern bro eller en interaktiv stemmesvartjeneste (IVR).

Når den eksterne destination slutter opkaldet, fortsætter opkaldsstrømmen yderligere efter behov, som at køe den til en agent.

Aktiviteten Bridge Transfer afkøler en kontakt, mens den overføres til et tredjeparts IVR- eller automatisk opkaldsdistributionssystem (ACD). Hvis kontakten ikke håndteres af tredjepartssystemet, kan den sættes i kø igen i den oprindelige kø, så kontakten forbliver i arbejdsprocessen for korrekt håndtering.

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

For mere information om aktivitetsindstillinger, forbrug og outputvariabler, se Byg og administrer strømme > Bridged Transfer2.

Afbryd kontakt-aktiviteten giver mulighed for at afbryde eller afslutte en aktiv kontakt direkte fra strømmen.

Dette er en terminalaktivitet, der er knyttet til strømmen, og kan være nyttig til at afslutte kontakter uden en agent indgriben, egnet til fejlsøgningsstrømmene eller efter registrering af en tilbagekaldelse for kunden.

Baseret på konfigurationen udløses efteropkaldsundersøgelsen eller feedback, når kontakten afsluttes gennem denne aktivitet.

For mere information om aktivitetsindstillinger, forbrug og outputvariabler, se Byg og administrer strømme > Afbryd kontakt2.

Aktiviteten Set Contact Priority letter effektiv styring af kontaktprioritet inden for strømmen ved at give mulighed for tildeling af specifikke prioritetsniveauer til kontakter. Dette gør det muligt at give visse kontakter større eller mindre betydning, hvilket sikrer, at de fordeles hensigtsmæssigt i forhold til andre ventende kontakter, når agenter bliver tilgængelige. Denne fleksibilitet giver mulighed for præcis kontrol over kontaktprioritering i hele flowet.

Prioriteten fastsættes ved at tildele et hierarkisk prioritetsniveau fra 1 (højeste) til 9 (laveste). Kontakter med den højeste prioritet flyttes frem for kontakter med den laveste prioritet. Når flere kontakter har samme prioritetsniveau, videreføres den kontakt, der har ventet længst, først til den næste tilgængelige og kvalificerede agent. Dette system sikrer, at kontakter med højere prioritet modtager øjeblikkelig opmærksomhed, samtidig med at der opretholdes retfærdighed blandt kontakter med samme prioritet baseret på deres ventetid.

For mere information om aktivitetsindstillinger, forbrug og outputvariabler, se Byg og håndtér strømme > Sæt kontaktprioritet2.

En Callback-aktivitet gør det muligt for opkaldende at anmode om en callback i stedet for at vente på pause, hvilket i høj grad forbedrer kundetilfredsheden ved at reducere ventetiderne og minimere frafaldsprocenterne. Når den er aktiveret, opretter aktiviteten Callback en opgave i en kø, hvilket sikrer, at en tilgængelig agent kan returnere kundens opkald.

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

Aktiviteten giver også kunderne mulighed for at anmode om tilbagekaldelser fra deres foretrukne agenter, hvilket tilføjer et personligt præg til oplevelsen og forbedrer kundetilfredsheden. Dette kan opnås, når tilbagekaldelsesaktiviteten følger en Queuetoagent-aktivitet i strømmen. Derudover tilbyder aktiviteten Callback en valgfri konfiguration til at tilpasse den automatiske nummeridentifikation (ANI), der anvendes under callback-processen. Denne tilpasning bidrager til mærkets konsistens og reducerer sandsynligheden for afvisning af opkald ved at sikre et genkendeligt opkalds-ID.

Flowdesigneren har mulighed for at inkludere en Callback Failed begivenhed i begivenhedsstrømmen. Denne begivenhed udløses, når et tilbagekaldelsesforsøg mislykkes, hvilket gør det muligt for flowdesigneren at gennemføre genforsøg med bestemte intervaller. Forsinkelsen eller intervallet mellem genforsøg kan konfigureres ved hjælp af Vent-aktiviteten, med et minimum genprøveinterval på 10 sekunder og et maksimum på 72 timer. Systemet understøtter op til at forsøge 10 igen på tværs af et maksimalt tidsrum 14 af dage ved hjælp af Vent-aktiviteten.

For mere information om aktivitetsindstillinger, forbrug og outputvariabler, se Byg og håndtér strømme > Tilbagekaldelse2.

Den planlagte tilbagekaldelse gør det muligt for strømmen at tilbyde kunderne bekvemmeligheden ved at anmode om en tilbagekaldelse på en bestemt fremtidig dato og klokkeslæt – hvilket eliminerer behovet for øjeblikkelig forbindelse til en agent. Denne funktion forbedrer kundeoplevelsen ved at give dem mulighed for at vælge et bekvemt tilbagekaldsvindue, hvilket minimerer opfattede ventetider og reducerer frafaldsprocenten.

Strømmen skal indfange den opkaldende persons input, f.eks. foretrukket dato og klokkeslæt, via DTMF-prompter og videregive dem til aktiviteten efter udførelse af de nødvendige input-valideringer.

Tilbagekaldelsen kan planlægges ved hjælp af en hvilken som helst telefonkø – hvad enten det er indgående eller udgående. For at opnå de bedste resultater anbefales det at tilføje en Afbryd-aktivitet umiddelbart efter den planlagte tilbagekaldelse for at sikre, at det aktuelle opkald slutter korrekt, når tilbagekaldelsen er planlagt. For mere information om planlægning af IVR-tilbagekaldelser, se Skemalæg IVR-tilbagekaldelser2.

Når tilbagekaldelsen udløses på den ønskede fremtidige dato og klokkeslæt, oprettes der et nyt opkald eller en ny interaktion. Denne nye interaktion vil følge standardstrømmen, der er knyttet til standardindtastningspunktet for tilbagekaldelse. Hvis tilbagekaldelsesforsøget mislykkes, kan strømmen automatisk prøve opkaldet ved hjælp af begivenhedshåndteringen Tilbagekaldelse mislykkedes, hvis den er konfigureret i denne strøm.

En referenceimplementering leveres i form af en subflowskabelon til at demonstrere de DTMF-prompter og grundlæggende valideringer, der anvendes sammen med aktiviteten. For mere information, se Skabelon til planlagt tilbagekaldelsessubflow2.

Aktiviteten Call Progress Analysis (CPA) gør det muligt at registrere automatiske svarsystemer og levende menneskelige stemmer på Call Back-opkald.

Når et tilbagekaldelsesforsøg støder på en Answering Machine Detection (AMD) eller voicemail, identificerer systemet opkaldet som mislykket. Resultatet af Answering Machine Detection (AMD) er optaget i Reason output variablen for Callback Failed event manager. Baseret på denne outputvariabel kan flowdesigneren konfigurere tilbagekaldelsesforsøg.

For mere information om aktivitetsindstillinger, forbrug og outputvariabler, se Byg og håndtér strømme > Analyse af opkald2.

Kø Kontakt-aktiviteten giver mulighed for at kø en kontakt ind i en aktiv indgående kø fra organisationen, så den kan matches og dirigeres til den rigtige agent i den kø.

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

• Priority - Tildele en hierarkisk betydning fra 1 (højeste) til 10 (laveste, standard) til den kontakt, der køres.
• Skill Requirements - Angiv de kvalifikationskriterier, der skal opfyldes af agenter i en færdighed-baseret kø, for at blive betragtet som berettigede til routing af kontakten.
• Skill Relaxations - Tuning, modifikation eller fjernelse af tidligere fastsatte færdighedskrav efter en periode for at forbedre chancerne for at finde en agent.
• Check Agent Availability - Lad systemet øjeblikkeligt udvide sig gennem alle Call Distribution Groups, hvor der ikke findes nogen tilgængelige agenter, for at undgå ventetid.

Se Rutevejledning, for at få flere oplysninger om, hvordan prioritet, færdighedskonfiguration og agenttilgængelighed spiller en rolle i routing-kontakter.

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

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

  Dette afbryder Main flow udførelse og yderligere begivenheder kan udløse de respektive Event Flows, hvis konfigureret.

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

  Flowudførelsen fortsætter derefter med de aktiviteter, der er vedhæftet efter Kø Kontakt aktivitet, som giver mulighed for at:

  • Afspil en forudindstillet musik til kunden, der venter i kø - ved at vedhæfte en PlayMusic aktivitet.
  • Registrer en tilbagekaldelse baseret på kundens anmodning - ved at vedhæfte en Callback aktivitet.
  • Re-kø dvs. fjern kontakten fra den aktuelle kø og tilføj den i en ny kø - ved at vedhæfte en anden Queue Contact eller Queue to Agent aktivitet.

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

Når det lykkes, afbryder det Main flow udførelse og yderligere begivenheder kan udløse de respektive Event Flows, hvis konfigureret.

I sådanne tilfælde resulterer aktiviteten i en fiasko, og gennemstrømningen flyttes til Error Handling vej.

For mere information om aktivitetsindstillinger, forbrug og outputvariabler, se Byg og håndtér strømme > Kø Kontakt2.

Aktiviteten Queue to Agent giver mulighed for at sætte kontakten i kø direkte til en foretrukken agent ved at kigge på deres unikke agent-id eller e-mailadresse i Webex Contact Center.

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

• Priority - Tildele højere/lavere betydning til de kontakter, der køes mod den samme agent.
• Reporting Queue - Identificer den kø, der skal bruges til konfiguration, såsom optagelse og standard musik-i-kø, og rapportér formålet med kontakten.
• Recovery Queue - Identificer den kø, der skal bruges som en faldback, når kontakten ikke kunne omdirigeres til den angivne foretrukne agent.

Når aktiviteten i Kø Til Agent med succes køer kontakten,

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

  Dette afbryder Main flow udførelse og yderligere begivenheder kan udløse de respektive Event Flows, hvis konfigureret.

• Hvis agenten er tilgængelig, men vælger at afslå, ikke svarer eller ikke modtager kontakten, flyttes den ind i den leverede genoprettelseskø.

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

• Hvis agenten ikke er tilgængelig og "Park Contact If Agent Unavailable" mulighed er selected, kontakten bliver parkeret og venter på, at agenten bliver tilgængelig.

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

  • Afspil en forudindstillet musik til kunden, der venter i kø - ved at vedhæfte en PlayMusic aktivitet.
  • Callback aktivitet.
  • Re-kø dvs. fjern kontakten fra den aktuelle kø og tilføj den i en ny kø - ved at vedhæfte en anden Queue to Agent eller Queue Contact aktivitet.

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

  Dette afbryder Main flow udførelse og yderligere begivenheder kan udløse de respektive Event Flows, hvis konfigureret.

• Hvis agenten ikke er tilgængelig og "Park Contact If Agent Unavailable" mulighed er not selected, køen fejler.

I sådanne tilfælde resulterer aktiviteten i en fiasko, og gennemstrømningen flyttes til Error Handling vej.

For mere information om aktivitetsindstillinger, forbrug og outputvariabler, se Byg og håndtér strømme > Kø til agent2.

Aktiviteten Escalate Call Distribution Group understøttes kun for queues with team assignment, og giver mulighed for at opdatere Call Distribution Group 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 omdirigere kontakten til alle godkendte agenter i køen.

Ved at bruge aktiviteten Escalate Call Distribution Group kan kontakten eskaleres til:

• Next Group—Udvide antallet af hold til at omfatte dem, der er tilføjet i den umiddelbare næste opkaldsdistributionsgruppe.
• Last Group—Udvidelse af sæt af hold til at omfatte alle hold, der er kortlagt på tværs af alle opkaldsdistributionsgrupper, der er konfigureret til køen.

I sådanne tilfælde resulterer aktiviteten i en fiasko, og gennemstrømningen flyttes til Error Handling vej.

Overvej et eksempel scenarie, hvor en kontakt står i kø i en kø med tre opkaldsdistributionsgrupper, som hver opdateres efter en periode på 30 sekunder.

Der er ingen agenter til rådighed i holdene del af CDG 1 og CDG 2, og en agent er tilgængelig i TEAM 3 som tilhører den sidste opkaldsdistributionsgruppe.

Når aktiviteten Escalate Call Distribution Group ikke bruges i flow, resulterer det i en lang ventetid, som illustreret nedenfor:

Ventetiden kan reduceres ved at bruge aktiviteten Escalate Call Distribution Group bruges som følger:

Baseret på Next Group eller Last Group valgt mulighed, bliver ventetiden for kontakten betydeligt reduceret, som illustreret nedenfor:

For mere information om aktivitetsindstillinger, forbrug og outputvariabler, se Byg og håndter strømme > Eskalere Call Distribution Group2.

Aktiviteten Get Queue Info giver mulighed for at hente oplysninger om kø i realtid for en given kontakt, såsom:

• Kontaktens aktuelle position i kø (PIQ), eller den potentielle position, hvis den endnu ikke er i kø.
• Forventet ventetid (EWT) eller den varighed, som en opgave forventes at vente i køen, inden den besvares.
• Antallet af agenter, der er logget ind eller tilgængelige i kontaktens nuværende Call Distribution Group.
• Antallet af agenter, der er logget ind eller tilgængelige på tværs af alle Call Distribution Groups for den valgte kø.
• Hvor længe den ældste kontakt i køen har ventet.

Disse oplysninger stilles til rådighed i flowudførelsen som aktivitetsoutput variabler.

For mere information om aktivitetsforbrug, den detaljerede definition og beregningsmetode for hver kø, se Byg og håndtér strømme > Få kø-info2.

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

• At meddele kontaktens position i kø og forventet ventetid til kunden, mens de venter på at blive omdirigeret.
• At afgøre, om en tilbagekaldelse kan registreres for kunden, hvis den forventede ventetid er for lang.
• For at eskalere kontakten til næste opkaldsdistributionsgruppe (CDG), hvis der ikke er nogen agenter til rådighed i hold, der er kortlagt til den nuværende CDG.

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

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

Dette kan opnås ved hjælp af Get Queue Info-aktiviteten i strømmen som følger:

Aktiviteten Advanced Queue Info giver mulighed for at hente oplysninger om kø i realtid for en given kontakt, idet der desuden tages hensyn til kontaktens kvalifikationskriterier, såsom:

• Kontaktens aktuelle position i kø (PIQ), eller den potentielle position, hvis den endnu ikke er i kø.
• Antallet af agenter, der er logget ind eller tilgængelige i kontaktens nuværende opkaldsdistributionsgruppe, der matcher de givne kvalifikationskriterier.
• Antallet af agenter, der er logget ind eller tilgængelige på tværs af alle opkaldsdistributionsgrupper for den valgte kø, svarende til de givne kvalifikationskriterier.
• Den aktuelle opkaldsdistributionsgruppe, hvor kontakten er parkeret i en given kø.
• Det samlede antal opkaldsdistributionsgrupper i en given kø.

Disse oplysninger stilles til rådighed i flowudførelsen som aktivitetsoutput variabler.

For mere information om aktivitetsforbrug, den detaljerede definition og beregningsmetode for hver kø, se Byg og håndter strømme > Avanceret kø Info2.

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

• At meddele kontaktens position i køen til kunden, mens de venter på at blive omdirigeret.
• For at eskalere kontakten til næste opkaldsdistributionsgruppe, hvis der ikke findes agenter, der matcher kvalifikationskriterierne, i hold, der er kortlagt til den aktuelle opkaldsdistributionsgruppe.
• For at afgøre, om en tilbagekaldelse kan registreres for kunden, hvis ingen agenter, der opfylder kvalifikationskriterierne, er logget ind på tværs af alle opkaldsdistributionsgrupper.

I sådanne tilfælde resulterer aktiviteten i en fiasko, og gennemstrømningen flyttes til Error Handling vej.

Overvej et eksempel, hvor kunden skal informeres om at modtage en tilbagekaldelse i betragtning af, at der ikke findes agenter, der opfylder kvalifikationskriterierne.

Dette kan opnås ved at bruge aktiviteten Advanced Queue Info i strømmen som følger:

Aktiviteten Sæt opkalds-id bruges til at definere det opkalds-id, der skal vises under et opkald. Aktiviteten Set Caller ID må kun bruges på Predial Event Flows som en terminal aktivitet, der markerer slutningen af begivenhedsstrømmen.

Aktiviteten Set Caller ID gør det muligt at konfigurere den krævede Automatic Number Identification (ANI) baseret på Dialed Number Identification Service (DNIS), operationstype eller deltagertype.

For mere information om aktivitetsindstillinger, forbrug og outputvariabler, se Byg og håndtér strømme > Sæt opkalds-id2.

Aktiviteten Optagelseskontrol er designet til at blive brugt sammen med en Menu-aktivitet til at fange optagelsesindehaverens samtykke. Dette sikrer overholdelse af regler eller politikker, der kræver udtrykkeligt samtykke, før registreringen begynder, og integrerer dette trin problemfrit i arbejdsprocessen.

Menu IVR-aktiviteten skal indfange brugerens samtykke i en boolesk variabel, som vil blive tildelt som input til aktiviteten Recording Control. Hvis kunden skal indberette brugerens samtykke i en samtykkeerklæring, skal samtykkeværdien opbevares i en indberetningspligtig global variabel. Alternativt kan en lokal variabel bruges, hvis rapportering ikke er påkrævet. Denne tilgang giver lejere og kunder øget fleksibilitet i forvaltningen og udnyttelsen af variabler effektivt.

Når denne aktivitet føjes til strømmen, går brugerens samtykke forud for lejerens niveau eller kø niveau eller optageplan niveau konfigurationsindstillinger.

Prioritetsrækkefølgen er som følger:

• Hvis brugerens samtykke er Ja i strømmen, registreres opkaldet, uanset optagekonfigurationen, der er indstillet på lejer- eller kø- eller optagetidsplanen.
• Hvis brugeren ikke giver sit samtykke som svar på aktiviteten, registreres opkaldet ikke, uanset den optagelseskonfiguration, der er indstillet på lejer- eller kø- eller optagelsesplanniveau.
• Hvis aktiviteten Optagelseskontrol ikke er konfigureret i strømmen, men en konfiguration er indstillet til Ja på et af de andre niveauer, f.eks. lejer eller kø eller optagelsesplan, registreres opkaldet.
• Hvis aktiviteten Optagelseskontrol ikke er konfigureret i strømmen, og en konfiguration er indstillet til Nej på alle niveauer såsom lejer, kø og optagelsesplan, registreres opkaldet ikke.

Denne optagelseskontrol kan illustreres som følger:

Derudover gælder optagelseskonfigurationer som Fortsæt på overførsel, Pause genoptag aktiveret, Pause varighed og andre fortsat i henhold til det eksisterende hierarki, herunder lejer, kø eller optagelsesplan niveauer.

For mere information om aktivitetsindstillinger, forbrug og outputvariabler, se Byg og administrer strømme > Registreringskontrol2.

Blind Transfer er en proces, hvor en kontakt effektivt ledes til et eksternt Dial Number (DN) gennem IVR-systemet, hvilket eliminerer behovet for agentinvolvering.

Aktiviteten Blind Transfer bruges, når et opkald skal overføres til et eksternt eller tredjeparts DN. Dette er en terminal aktivitet, så strømmen slutter, når overførslen er udført.

Blind Transfer-aktivitet understøttes ikke, når strømmen udføres til høring.

For mere information om aktivitetsindstillinger, forbrug og outputvariabler, se Byg og administrer strømme > Blind overførsel2.

Med Bridged Transfer-aktiviteten kan en kontakt midlertidigt overføres til en ekstern destination, mens strømmen bevarer kontrollen over opkaldet. Den eksterne destination kan være en ekstern bro eller en interaktiv stemmesvartjeneste (IVR).

Når den eksterne destination slutter opkaldet, fortsætter opkaldsstrømmen yderligere efter behov, som at køe den til en agent.

Aktiviteten Bridge Transfer afkøler en kontakt, mens den overføres til et tredjeparts IVR- eller automatisk opkaldsdistributionssystem (ACD). Hvis kontakten ikke håndteres af tredjepartssystemet, kan den sættes i kø igen i den oprindelige kø, så kontakten forbliver i arbejdsprocessen for korrekt håndtering.

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

For mere information om aktivitetsindstillinger, forbrug og outputvariabler, se Byg og administrer strømme > Bridged Transfer2.

Afbryd kontakt-aktiviteten giver mulighed for at afbryde eller afslutte en aktiv kontakt direkte fra strømmen.

Dette er en terminalaktivitet, der er knyttet til strømmen, og kan være nyttig til at afslutte kontakter uden en agent indgriben, egnet til fejlsøgningsstrømmene eller efter registrering af en tilbagekaldelse for kunden.

Baseret på konfigurationen udløses efteropkaldsundersøgelsen eller feedback, når kontakten afsluttes gennem denne aktivitet.

For mere information om aktivitetsindstillinger, forbrug og outputvariabler, se Byg og administrer strømme > Afbryd kontakt2.

Aktiviteten Set Contact Priority letter effektiv styring af kontaktprioritet inden for strømmen ved at give mulighed for tildeling af specifikke prioritetsniveauer til kontakter. Dette gør det muligt at give visse kontakter større eller mindre betydning, hvilket sikrer, at de fordeles hensigtsmæssigt i forhold til andre ventende kontakter, når agenter bliver tilgængelige. Denne fleksibilitet giver mulighed for præcis kontrol over kontaktprioritering i hele flowet.

Prioriteten fastsættes ved at tildele et hierarkisk prioritetsniveau fra 1 (højeste) til 9 (laveste). Kontakter med den højeste prioritet flyttes frem for kontakter med den laveste prioritet. Når flere kontakter har samme prioritetsniveau, videreføres den kontakt, der har ventet længst, først til den næste tilgængelige og kvalificerede agent. Dette system sikrer, at kontakter med højere prioritet modtager øjeblikkelig opmærksomhed, samtidig med at der opretholdes retfærdighed blandt kontakter med samme prioritet baseret på deres ventetid.

For mere information om aktivitetsindstillinger, forbrug og outputvariabler, se Byg og håndtér strømme > Sæt kontaktprioritet2.

En Callback-aktivitet gør det muligt for opkaldende at anmode om en callback i stedet for at vente på pause, hvilket i høj grad forbedrer kundetilfredsheden ved at reducere ventetiderne og minimere frafaldsprocenterne. Når den er aktiveret, opretter aktiviteten Callback en opgave i en kø, hvilket sikrer, at en tilgængelig agent kan returnere kundens opkald.

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

Aktiviteten giver også kunderne mulighed for at anmode om tilbagekaldelser fra deres foretrukne agenter, hvilket tilføjer et personligt præg til oplevelsen og forbedrer kundetilfredsheden. Dette kan opnås, når tilbagekaldelsesaktiviteten følger en Queuetoagent-aktivitet i strømmen. Derudover tilbyder aktiviteten Callback en valgfri konfiguration til at tilpasse den automatiske nummeridentifikation (ANI), der anvendes under callback-processen. Denne tilpasning bidrager til mærkets konsistens og reducerer sandsynligheden for afvisning af opkald ved at sikre et genkendeligt opkalds-ID.

Flowdesigneren har mulighed for at inkludere en Callback Failed begivenhed i begivenhedsstrømmen. Denne begivenhed udløses, når et tilbagekaldelsesforsøg mislykkes, hvilket gør det muligt for flowdesigneren at gennemføre genforsøg med bestemte intervaller. Forsinkelsen eller intervallet mellem genforsøg kan konfigureres ved hjælp af Vent-aktiviteten, med et minimum genprøveinterval på 10 sekunder og et maksimum på 72 timer. Systemet understøtter op til at forsøge 10 igen på tværs af et maksimalt tidsrum 14 af dage ved hjælp af Vent-aktiviteten.

For mere information om aktivitetsindstillinger, forbrug og outputvariabler, se Byg og håndtér strømme > Tilbagekaldelse2.

Den planlagte tilbagekaldelse gør det muligt for strømmen at tilbyde kunderne bekvemmeligheden ved at anmode om en tilbagekaldelse på en bestemt fremtidig dato og klokkeslæt – hvilket eliminerer behovet for øjeblikkelig forbindelse til en agent. Denne funktion forbedrer kundeoplevelsen ved at give dem mulighed for at vælge et bekvemt tilbagekaldsvindue, hvilket minimerer opfattede ventetider og reducerer frafaldsprocenten.

Strømmen skal indfange den opkaldende persons input, f.eks. foretrukket dato og klokkeslæt, via DTMF-prompter og videregive dem til aktiviteten efter udførelse af de nødvendige input-valideringer.

Tilbagekaldelsen kan planlægges ved hjælp af en hvilken som helst telefonkø – hvad enten det er indgående eller udgående. For at opnå de bedste resultater anbefales det at tilføje en Afbryd-aktivitet umiddelbart efter den planlagte tilbagekaldelse for at sikre, at det aktuelle opkald slutter korrekt, når tilbagekaldelsen er planlagt. For mere information om planlægning af IVR-tilbagekaldelser, se Skemalæg IVR-tilbagekaldelser2.

Når tilbagekaldelsen udløses på den ønskede fremtidige dato og klokkeslæt, oprettes der et nyt opkald eller en ny interaktion. Denne nye interaktion vil følge standardstrømmen, der er knyttet til standardindtastningspunktet for tilbagekaldelse. Hvis tilbagekaldelsesforsøget mislykkes, kan strømmen automatisk prøve opkaldet ved hjælp af begivenhedshåndteringen Tilbagekaldelse mislykkedes, hvis den er konfigureret i denne strøm.

En referenceimplementering leveres i form af en subflowskabelon til at demonstrere de DTMF-prompter og grundlæggende valideringer, der anvendes sammen med aktiviteten. For mere information, se Skabelon til planlagt tilbagekaldelsessubflow2.

Aktiviteten Call Progress Analysis (CPA) gør det muligt at registrere automatiske svarsystemer og levende menneskelige stemmer på Call Back-opkald.

Når et tilbagekaldelsesforsøg støder på en Answering Machine Detection (AMD) eller voicemail, identificerer systemet opkaldet som mislykket. Resultatet af Answering Machine Detection (AMD) er optaget i Reason output variablen for Callback Failed event manager. Baseret på denne outputvariabel kan flowdesigneren konfigurere tilbagekaldelsesforsøg.

For mere information om aktivitetsindstillinger, forbrug og outputvariabler, se Byg og håndtér strømme > Analyse af opkald2.