Voz

Variáveis para configurar

• Tipo de Marcador: PowerDialer, VoiceBroadCast, Progressive (com a alocação por Agente), Predictive (50 agentes mínimos)
• Nome: É o nome do Marcador para VoiceBroadCast, você pode colocar qualquer nome, para PowerDialer e Predictive uma campanha de entrada é selecionado, para Progressive uma campanha de saída.
• Habilitado: Si o marcador esta ativado.
• Cadeia de discagem: É o que você usa para fazer a chamada. Exemplo: DAHDI/G1/ ou SIP/CARRIER/
• Contexto: Onde o marcador vai entrar. Para VoiceBroadCast, PowerDialer, Predictive é o contexto em que entra uma chamada estabelecida com um cliente e junta-se com um workflow. Em Progressive é o contexto para qual a chamada é feita para o cliente uma vez conectado ao agente.
• Máximo: Número máximo de chamadas simultâneas
• Tempo entre Ligação: Time Between Calls, é o tempo esperado entre as chamadas. Exemplo: 300 ms Geralmente é 0, se ele recebe -1 em PowerDialer, executa sobremarcado pra ter mais agentes ocupados atravéz de fórmula estadística.
• Tempo máximo: Tempo limite de espera de chamadas para un número na base em Progressive para tentar se conectar com um agente.
• Nova tentativa: Quantidade máxima de chamadas para um número na base em Progressive para tentar se conectar com um agente.
• Audios: Audio ou concatenação de áudios (com &) passado para o Workflow, útil para VoiceBroadCast.
• Callerid: Número da chamada
• CallerPres: Para ISDN se deve ou não exibir o CallerID onde o provedor admita.
• AMD: Se esta habilitado a detecção de Answering Machine, esta variável vem ${am} em 1 o 0 e é possível utilizá-lo no fluxo para utilizar a actividade amd para para cortar as chamadas Correio de voz.
• DNCR: Do not Call Registry, verifica se o registro está bloqueado por BlackList.
• Variáveis: Tudo o que você quer passar a o Workflow.
  

Processo

O sistema é iniciado de acordo com o scheduler criado.

Para começar, o sistema cria uma tarefa para cada marcador definido no sistema, as mesmas iniciam e finalizam e acordo com o schedule que tenha. No Dashboard poderá ter uma monitorização dos valores em Tempo Real para o día.

Você pode ver dois dashboards circulares indicando o número de chamadas processadas e não como o número de agentes em diferentes estados, assim como também um gráfico que indica em tempo real o total de chamadas ativas, os agentes ocupados e as chamadas que estão sendo marcadas.

Nota: É possivel observar neste último gráfico que a cantidade de ocupados seja maior do que o total assim como também ver os discandos negativos. Isso acontece quando a campanha realiza chamadas manuais ou cuando tenha chamadas recebidas que não sejam do marcador, de qualquer maneira os gráficos mostram a evolução do marcador.

É possível a qualquer momento parar ou reiniciar a campanha manualmente e fazer upload de novas listas ou registros de lista negra, também é possível fazer o download das listas do marcador acessando do botao de listas localizado na parte superior dereita.

A tarefa é executada, esta tarefa é responsável de fazer as chamadas enviando chamadas obtidas do spool (tabela calls_spool) para a mesa, estes são obtidos de acordo com o tipo de marcador e são marcados de acordo com a seqüência de marcação dos mesmos (pode ser por TDM ou VOIP). Notar que só vai funcionar em linhas Digitais, VOIP ou Analógicas com Disconnect Supervision (ou seja inversión da polaridad). Al executar a chamada, a mesma altera o estado.

Quando algum evento que o sistema poderia processar a chamada chega, é excluído da tabela, se foi ocupado ou não answer ou algum problema que não ter canais, essa chamada faz um novo intento, aumentado o retry, é para não ser tomada imediatamente e outros sejam processadas antes de tentar novamente com ela. É de salientar que entre as chamadas espera o tempo TBC em milissegundos que é geralmente de 0 (sem delay) si o servidor não suporta e/ou haver muitos canais simultâneos. é melhor colocar o delay em, por exemplo, 300 ms para lograr que cuando gera um lote de chamadas de uma só vez, não seja demasiado rápido e o sistema não possa processar correctamente.

É importante não solapar quantidade de canais, se temos 30 canais y temos 2 campanhas a o mesmo tempo com máximo de 20 vai resultar em potencial erros do marcador onde pode repetir algumas chamadas. Tambéin ao ter mais do que uma campanh, para melhor performance é uma boa ideia deixar 1 canal de pivote, como é um sistema assíncrono baseado em eventos é possivel que em algum milissegundo se esté marcando em outras campanhas e todavía não se ter dato de que a mesma é realmente ativa ocupando um canal, portanto no caso de beira é possivel que possa ignorar uma campanha, de qualquer maneira se acontece e o sistema não pode criar outro canal porque não há, este processo será concluído mais tarde quando o processamento existente do spool termina porque a mesma vai ter uma tentativa mais

No callerid(nome) pode encontrar VoiceBroadCast:Campanha:Número:Lista a Marcar. Esto permite o seguimento dos eventos do sistema para saber quantas chamadas ativas por campanhas e permite volver a colocar no spool, chamadas que não podiam chegar ao destino.

Carregar contatos

Arquivo CSV onde pode encontrar: campanha, número de telefone, status, datos. O formato correto é MSDOS CSV (separado por ; e quebras de linha)

O orden em que eles fazem é a ordem do Excel, a única coisa que vairia é que os que aumentan as tentativas van a o final e as Programadas ou com maior prioridade vai sair primeiro.

Base.csv

prueba1;098344484;var1=val1:var2=val2;099124484:099111111;99;1001

VoiceBroadCast

Introdução

O sistema VoiceBroadCast é para realizar campanhas de marcado automático, uma base de telefonia é carregado e são dirigidos a um fluxo IVR o cual pode ser utilizado para reproduzir anúncios, áudios, de forma dinâmica ou estática, também pode lograr fazer pesquisas automáticas dinâmica ou estática, e também permitem, de acordo com uma configuração, o cliente seja redirecionado para uma campanha.

Neste caso, o importante é definir a quantidade de canais como o VoiceBroadCast utilizar todos os possíveis a maior parte do tempo.

Passos

1. O marcador obtém a quantidade máxima de chamas a realizar, si é 0 espera e pede novamente, senão obtein de acordo com a:
   
   1. Quantidade de canais disponíveis (Máximo - Usados)
2. O marcador obtém em base a quantidade e as seguintes regras:
   
   1. Pede para essa campanha, contatos que esten ativos para a base que é marcada como ativa
   2. Ou cualquer contato que é incluido em la agenda para essa campanha com máxima prioridade
   3. Ordenando os contatos por Prioridade e Quantidade de tentativas (Prioridade → 1 vai chamar antes)
3. Si o DNCR (do not call registry) é ativo, só deja fazer a chamada si não estiver na lista preta (Black list)
4. Tudas as variáveis são passados para o fluxo de trabalho (workflow), de campanha ou contato
5. Se passa o registro do contato de marcador com tentativa +1 para a lógica de negócio, isso permitirá criar a Lógica de Respooling (re-introduzir o contato por não ser realmente eficaz com o seu número alternativo)
6. Si a quantidade de tentativas é qubrada para esse número, então si tiver alternativos, obtém o primeiro e deixá-lo como principal e o resto como alternativos. Em seguida, o processo começa novamente.
7. A chamada é realizada
8. Si não é atendida ou ocorre um erro na chamada, então as tentativas é incrementada e a chamada passa ao fundo para marcar logo.
9. Si é atendida, o workflow associado é executado e os pasos do mesmo.

prueba1;098344484;NOMBRE=Sebastian Gutierrez:Monto=200;099124484:099111111;9999;

Fluxo standard

exten=> _X.,1,Set(CHANNEL(Language)=es)
exten=> _X.,2,Answer(5)
exten=> _X.,3,Set(CALLERID(num)=${EXTEN})
exten=> _X.,4,Set(CALLERID(name)=${CDR(campaign)})
exten=> _X.,5,Set(__dialed=${EXTEN})
exten=> _X.,6,Set(__REALDIALED=${EXTEN})
exten=> _X.,7,Playback(${sound},)
exten=> _X.,8,Read(__confirma,IVRDemoDesicion,1,,1,5)
exten=> _X.,9,GotoIf($["${confirma}" = "1"]?12:10)
exten=> _X.,10,GotoIf($["${confirma}" = "2"]?7:11)
exten=> _X.,11,Hangup()
exten=> _X.,12,GUID(__guid)
exten=> _X.,13,Set(CDR(guid)=${guid})
exten=> _X.,14,Set(CDR(campaign)=${CDR(campaign)})
exten=> _X.,15,Set(MONITOR_FILENAME=${guid})
exten=> _X.,16,Set(__Ani=${EXTEN})
exten=> _X.,17,Set(CDR(type)=record)
exten=> _X.,18,Set(AUDIOHOOK_INHERIT(MixMonitor)=yes)
exten=> _X.,19,SipAddHeader(CTI: {"Guid": "${guid}" , "Screen": "FALSE" , "Form": "${FORM}" , "Campaign" : "${CDR(campaign)}" , "Callerid" : "${CALLERID(num)}" , "ParAndValues" : "${PARAVAL}" , "Beep" : "TRUE" , "Answer" : "TRUE" , "Dialer" : "${DIALERRECORD}"})
exten=> _X.,20,Queue(${VBQUEUE},TtKk,,,600,,,,,)
exten=> _X.,21,Goto(VoiceBroadCast,${EXTEN},11)
 
 
  
exten=> h,1,Set(HASH(rates)=${ODBC_Data(select  rates.gateway\, rates.rate\, rates.cost\, rates.note FROM rates LEFT JOIN provider ON provider.name=rates.gateway WHERE provider.status = 'true' AND substring( '${EXTEN}'\, 1\, length( prefix_regexp ) ) REGEXP prefix_regexp ORDER BY length(prefix_regexp) DESC\,rates.rate ASC)})
exten=> h,2,Set(talkedminutes=${MATH(${CDR(billsec)} / 60,f)})
exten=> h,3,Set(talkedminutes=$[CEIL(${talkedminutes})])
exten=> h,4,Set(chargedbalance=${MATH(${talkedminutes} * ${HASH(rates,rate)},f)})
exten=> h,5,Set(realbalance=${MATH(${talkedminutes} * ${HASH(rates,cost)},f)})
exten=> h,6,Set(CDR(charged_balance)=${chargedbalance})
exten=> h,7,Set(CDR(real_balance)=${realbalance})
exten=> h,8,Set(CDR(note)=${HASH(rates,note)})
exten=> h,9,Set(CDR(carrier)=${HASH(rates,gateway)})
exten=> h,10,Set(CDR(userfield)=${userfield})
exten=> h,11,Set(CDR(direction)=outgoing)
exten=> h,12,Set(CDR(causecode)=${HANGUPCAUSE})
exten=> h,13,Hangup()

Marcadores Progresivos

Introdução

Neste caso, é um passo abaixo respeito ao PowerDialer ou Preditivo na máxima automação, mais continuamos em sistemas de chamadas puramente automatizados. Os marcadores progresivos são baseados na disponibilidade dos Agentes.

Os marcadores progresivos são geralmente muito adequados para Centros com baixo volume ou moderado de chamadas, onde não seriam capaz de recolher suficiente informação para alcançar estatísticas confiáveis.

Basicamente chama ao agente e cuando éste atende, executa a chamada, isso faz que muitas tentativas podem estar ocupado, número errado, etc usando tempo de agente. O Workflow que é usado é de saida, por isto usamos em Progresivos, campanhas de saída e não de entrada (não existe manejo de colas mais sim conceito de wrapup)

Os contatos têm prioridade de Agentes, o seja cada contato é asociado a um telefone de um agente que é o que vai ter esse contato.

Passos

1. O marcador obtém a quantidade de chamadas a fazer, si é 0 espera e pergunta novamente, senão obtém de acordo com:
   
   1. Quantidade de Agentes disponíveis que não estão em estado de Wrapup
2. O marcador obtém os contactos em base a quantidade e as seguintes regras:
   
   1. Pede para essa campanha, contatos que esten ativos para a base que este marcada como ativa mas para os agentes que estão disponível, um para cada um deles
   2. Ou cualquer contato que seja Programado para essa campanha com máxima prioridade, enquanto o agente fique ativo.
   3. Ordenando os contatos por Prioridade e Quantidade de tentativas (Prioridade → 1 vai chamar antes)
3. Si o DNCR (do not call registry) é ativo, só deja fazer a chamada si não estiver na lista preta (Black list).
4. Tudas as variáveis são passados para o fluxo de trabalho (workflow), de campanha ou contato
5. Se passa o registro do contato de marcador com tentativa +1 para a lógica de negócio, isso permitirá criar a Lógica de Respooling (re-introduzir o contato por não ser realmente eficaz com o seu número alternativo)
6. Si a quantidade de tentativas é qubrada para esse número, então si tiver alternativos, obtém o primeiro e deixá-lo como principal e o resto como alternativos. Em seguida, o processo começa novamente.
7. A chamada é feita para o Agente, Se por algum motivo ele não puder atender, se vai tentar novamente sem afetar a quantidade de tentativas uma vez que o agente volte a ficar ativo.
8. Si não é atendida ou ocorre um erro na chamada, então as tentativas é incrementada e a chamada passa ao fundo para marcar logo.
9. Ao Agente é passado o registro do contato para que ele possa tomar medidas basado na lógica de negócio e assim fazer o Respooling do contato conforme seja necessário (Tendo todos os dados sobre ele). Também obtém os dado para o CTI (Para abrir o formulário com os dados do cliente a chamar)

prueba1;098344484;NOMBRE=Sebastian Gutierrez:Monto=200;099124484:099111111;9999;1001

Fluxo standard

exten=> _X.,1,Set(VOLUME(TX)=2)
exten=> _X.,2,Set(VOLUME(RX)=2)
exten=> _X.,3,Set(__OUTQUEUE=${CDR(campaign)})
exten=> _X.,4,Set(__DIALED=${EXTEN})
exten=> _X.,5,Set(__AGENT=${OUTAGENT})
exten=> _X.,6,Set(__guid=${OUTGUID})
exten=> _X.,7,Set(CALLERID(num)=${OUTDID})
exten=> _X.,8,Set(CALLERID(name-pres)=${CALLERPRESS})
exten=> _X.,9,Set(dummy=${ODBC_Data(UPDATE calls_spool set status =0\, retries = retries + 1 WHERE contact = ${CDR(contact)} AND destination = '${EXTEN}')})
exten=> _X.,10,Set(CDR(guid)=${guid})
exten=> _X.,11,Set(CDR(type)=record)
exten=> _X.,12,MixMonitor(${guid}.gsm,b,)
exten=> _X.,13,Set(CDR(accountcode)=${AGENT})
exten=> _X.,14,Set(__idLlamada=${guid})
exten=> _X.,15,Set(__REALDIALED=${EXTEN})
exten=> _X.,16,Dial(${DIALSTRING:0:-1}/${EXTEN},30,TtKkc,)
exten=> _X.,17,Set(CDR(causecode)=${HANGUPCAUSE})
exten=> _X.,18,NoOp(${DIALSTATUS} - ${HASH(SIP_CAUSE,${CDR(dstchannel)})} -  ${HANGUPCAUSE})
exten=> _X.,19,Hangup()
 
 
  
exten=> h,1,Set(HASH(rates)=${ODBC_Data(select  rates.gateway\, rates.rate\, rates.cost\, rates.note FROM rates LEFT JOIN provider ON provider.name=rates.gateway WHERE provider.status = 'true' AND substring( '${EXTEN}'\, 1\, length( prefix_regexp ) ) REGEXP prefix_regexp ORDER BY length(prefix_regexp) DESC\,rates.rate ASC)})
exten=> h,2,Set(talkedminutes=${MATH(${CDR(billsec)} / 60,f)})
exten=> h,3,Set(talkedminutes=$[CEIL(${talkedminutes})])
exten=> h,4,Set(chargedbalance=${MATH(${talkedminutes} * ${HASH(rates,rate)},f)})
exten=> h,5,Set(realbalance=${MATH(${talkedminutes} * ${HASH(rates,cost)},f)})
exten=> h,6,Set(CDR(charged_balance)=${chargedbalance})
exten=> h,7,Set(CDR(real_balance)=${realbalance})
exten=> h,8,Set(CDR(note)=${HASH(rates,note)})
exten=> h,9,Set(CDR(carrier)=${HASH(rates,gateway)})
exten=> h,10,Set(CDR(userfield)=${userfield})
exten=> h,11,Set(CDR(direction)=outgoing)
exten=> h,12,Set(CDR(causecode)=${HANGUPCAUSE})
exten=> h,13,QueueUpdate(${OUTQUEUE},${UNIQUEID},${AGENT},${DIALSTATUS},${ANSWEREDTIME},${DIALEDTIME}|${DIALED}|${IdLlamada}|)
exten=> h,14,Hangup()

Marcadores Powerdialer

Introdução

A diferença do marcador Progresivo, o PowerDialer não chama primeiro ao agente e depois faze a chamada, sinão que é muito similar ao Preditivo mais com um cálculo do sobremarcado mais básico.

O primeiro que o sistema faz é marcar enquanto existam agentes disponíveis para lidar com as chamadas da campanha, exemplo si há 2 agentes disponiveis vai realizar 2 chamadas simultaneamente e assim até que contate algum. Uma vez em contato com um cliente, ele é enviado para a campanha, no 99% dos casos, devería ter agente livre para atender ao instante. Isso impide de dar ao agente chamadas de números ocupados ou inexistente e enregar chamadas somente que foram atendidas. A manera de trabalhar é exactamente a mesma nos marcadores VoiceBroadCast, PowerDialer, Predictive, a única diferença é o número de chamadas que são executados.

O PowerDialer tenta ter tudos os agentes com chamada com seu sobremarcado.

Passos

1. O marcador obtém a quantidade de chamadas a fazer, si é 0 espera e pergunta novamente, senão obtém de acordo com:
   
   1. Modo Normal (TBC >= 0): Quantidade de Agentes disponível que não estão em estado de Wrapup sem passar a máxima quantidad de canais para a campanha.
   2. Modo Sobremarcado (TBC -1): é como o Modo Normal mais com um porcentagem de sobremarcado com base em um modelo estatístico (Preditivo)
2. O marcador obtém em base a quantidade as seguintes regras:
   1. Pede para essa campanha, contatos que esten ativos para a base que este marcada como ativa
   2. Ou cualquer contato que seja Programado para essa campanha com máxima prioridade
   3. Ordenando os contatos por Prioridade e Quantidade de tentativas (Prioridade → 1 vai chamar antes)
3. Si o DNCR (do not call registry) é ativo, só deja fazer a chamada si não estiver na lista preta (Black list).
4. Se passan tudas a variáveis a os Workflows, sejan de campanha ou contato.
5. Se passa o registro do contato de marcador com tentativa +1 para a lógica de negócio, isso permitirá criar a Lógica de Respooling (re-introduzir o contato por não ser realmente eficaz)
6. Si a quantidade de tentativas é qubrada para esse número, então si tiver alternativos, obtém o primeiro e deixá-lo como principal e o resto como alternativos. Em seguida, o processo começa novamente.
7. A chamada e feita.
8. Si não é atendida ou ocorre um erro na chamada, então as tentativas é incrementada e a chamada passa ao fundo para marcar logo.
9. Si é atendida e está habilitado AMD então si é MACHINE o registro é reinserido com o próximo alternativo a menos que seja a última tentativa do contato HUMAN, então vai ao ACD a repartor entre os agentes disponívels.
10. Si é atendida e não está habilitado AMD vai diretamente para o ACDa os agentes.
11. Ao Agente é passado o registro do contato para que ele possa tomar medidas basado na lógica de negócio e assim fazer o Respooling do contato conforme seja necessário (Tendo todos os dados sobre ele)

prueba1;098344484;var1=val1:var2=val2;099124484:099111111;9999;

Fluxo Standard

exten=> _X.,1,Set(CHANNEL(Language)=es)exten=> _X.,2,Answer(0)
exten=> _X.,3,Set(CALLERID(num)=${EXTEN})
exten=> _X.,4,Set(CALLERID(name)=${CDR(campaign)})
exten=> _X.,5,Set(__dialed=${EXTEN})
exten=> _X.,6,Set(__REALDIALED=${EXTEN})
exten=> _X.,7,Set(__Ani=${EXTEN})
exten=> _X.,8,GUID(__guid)
exten=> _X.,9,Set(CDR(guid)=${guid})
exten=> _X.,10,Set(CDR(campaign)=${CDR(campaign)})
exten=> _X.,11,Set(MONITOR_FILENAME=${guid})
exten=> _X.,12,Set(CDR(type)=record)
exten=> _X.,13,Set(AUDIOHOOK_INHERIT(MixMonitor)=yes)
exten=> _X.,14,SipAddHeader(CTI: {"Guid": "${guid}" , "Screen": "FALSE" , "Form": "${FORM}" , "Campaign" : "${CDR(campaign)}" , "Callerid" : "${CALLERID(num)}" , "ParAndValues" : "${PARAVAL}" , "Beep" : "TRUE" , "Answer" : "TRUE" , "Dialer" : "${DIALERRECORD}"})
exten=> _X.,15,GotoIf($["${am}" = "1"]?18:16)
exten=> _X.,16,Queue(${CDR(campaign)},TtKk,,,600,,,,,)
exten=> _X.,17,Hangup()
exten=> _X.,18,WaitForSilence(1000,,)
exten=> _X.,19,AMD(6000,1500,800,2500,100,50,3,256)
exten=> _X.,20,GotoIf($["${AMDSTATUS}" = "MACHINE"]?21:16)
exten=> _X.,21,Set(__userfield=${AMDSTATUS} - ${AMDCAUSE})
exten=> _X.,22,GotoIf($["${RESPOOL}" = "true"]?24:23)
exten=> _X.,23,Hangup()
exten=> _X.,24,Set(dummy=${ODBC_Data(INSERT INTO calls_spool VALUES(${DIALERRECORD}))})
exten=> _X.,25,Goto(PowerDialer,${EXTEN},23)
 
  
 
exten=> h,1,Set(HASH(rates)=${ODBC_Data(select  rates.gateway\, rates.rate\, rates.cost\, rates.note FROM rates LEFT JOIN provider ON provider.name=rates.gateway WHERE provider.status = 'true' AND substring( '${EXTEN}'\, 1\, length( prefix_regexp ) ) REGEXP prefix_regexp ORDER BY length(prefix_regexp) DESC\,rates.rate ASC)})
exten=> h,2,Set(talkedminutes=${MATH(${CDR(billsec)} / 60,f)})
exten=> h,3,Set(talkedminutes=$[CEIL(${talkedminutes})])
exten=> h,4,Set(chargedbalance=${MATH(${talkedminutes} * ${HASH(rates,rate)},f)})
exten=> h,5,Set(realbalance=${MATH(${talkedminutes} * ${HASH(rates,cost)},f)})
exten=> h,6,Set(CDR(charged_balance)=${chargedbalance})
exten=> h,7,Set(CDR(real_balance)=${realbalance})
exten=> h,8,Set(CDR(note)=${HASH(rates,note)})
exten=> h,9,Set(CDR(carrier)=${HASH(rates,gateway)})
exten=> h,10,Set(CDR(userfield)=${userfield})
exten=> h,11,Set(CDR(direction)=outgoing)
exten=> h,12,Set(CDR(causecode)=${HANGUPCAUSE})
exten=> h,13,Hangup()

Marcadores Preditivos

Introdução

Os marcadores preditivos baseiam sua operação em bases de dados de números de telefone a chamar, e faz, como o nome diz, de manera "preditiva".

Isto significa que entra em jogo um algoritmo com base em estratégias estatísticas, que teham múltiplas variáveis do Call Center e calculam vários fatores pra colocar em contato os Agentes com os Contatos da forma mais eficiente possível.

Como regra geral, a utilidade principal e vantagem para discadores preditivos reside no volume do call center em que se baseiam, como sendo motivos de técnicas estatísticas, o máximo de confiabilidade na Lei dos Grandes Números. É por isso que, em Call Centers que são relativamente pequenos não é recomendado 

Em essência, a ideia coneptual detrás dos marcadores preditivos é a seguinte:

• Em primeiro lugar está a ser calculado o momento ideal para lançar chamadas para clientes, usando estratégias estatísticas de vários tipos, entre os quais incluem:

  • Calcula o tempo médio para cada chamada, que resulta em sucesso e cada chamada que resulta em fracaso.

  • Calcular a proporção média de chamadas que resulta em sucesso e fracasso e, portanto, um tempo médio ponderado é calculado para todas as chamadas em geral.

  • Eles usam outros fatores que influenciam o tempo, como tempo médio de preparação para aceitar outra chamada de cada agente e Wrapup

O mais sofisticado algoritmo, melhor global será o discador preditivo. Na verdade, este é um dos principais fatores que irão determinar o seu sucesso no futuro. Muitos algoritmos preditivos são baseadas na distribuição Erlang

• Em segundo lugar, eles lançam chamadas para números armazenados na base de dados, respeitando o tempo calculado:
  • Com chamadas em andamento, o discador preditivo deve ser capaz de identificar se existe alguma desvantagem de não ser capaz de entrar em contato com o cliente, principalmente pelo tipo de tom é recebido, de acordo com o tom convenção para o país nacional especificamente.
  • Também será capaz de detectar sinais de fax e outras possibilidades também seguem algum padrão
  • Se ocorrer um evento deste tipo, dependendo do evento, a aplicação deve ser capaz de discar o telefone corretamente, dependendo do que aconteceu:
  • Além da capacidade de detectar correio de voz via de regra são símbolos de "indisponível" para repetir a chamada mais tarde. A detecção é relativamente fácil, com base no tempo total de resposta de voz, já que a maioria das respostas dos indivíduos em geral, um simples "Olá?" Embora atendedores de chamadas são geralmente uma longa sentença.
  • No momento em que recebe uma chamada atendida, ele passa para a cauda dos agentes para ser atendido rapidamente.

Com este sistema, os agentes só são aguardando a máquina para fazer o seu trabalho, e geralmente não têm a capacidade de escolher se quer atender a chamada, mas esta é colocado diretamente em comunicação com o agente.

A priori, este método pode ser ideal, e realmente se estamos diante de um marcador preditivo de qualidade, esta premissa é verdadeira. Mas, em contrapartida, encontrou alguns problemas, devemos considerar, ao escolher este tipo de marcador:

• Se não houver resposta dentro do intervalo em que o cliente de uma chamada, e o operador recebe, é muito provável que o cliente deixa a chamada. Neste caso, a maioria dos discadores preditivos, coloque o número a ser chamado no futuro, mas podemos gerar insatisfação do cliente provoca desconforto
• Se você deseja usar para fins comerciais de empresa para empresa, pode ser muito ineficiente, uma vez que a maioria das empresas têm um IVR que pode impedir o nosso discador preditivo cumprir a sua missão em condições.
• Como mencionamos, se temos algumas chamadas ao Observatório não pode tomar a estatística de qualidade algoritmos figuras e, portanto, o primeiro problema ocorre muito, ser um sistema muito ineficiente.

prueba1;098344484;var1=val1:var2=val2;099124484:099111111;9999;

Fluxo Standard

exten=> _X.,1,Set(CHANNEL(Language)=es)exten=> _X.,2,Answer(0)
exten=> _X.,3,Set(CALLERID(num)=${EXTEN})
exten=> _X.,4,Set(CALLERID(name)=${CDR(campaign)})
exten=> _X.,5,Set(__dialed=${EXTEN})
exten=> _X.,6,Set(__REALDIALED=${EXTEN})
exten=> _X.,7,Set(__Ani=${EXTEN})
exten=> _X.,8,GUID(__guid)
exten=> _X.,9,Set(CDR(guid)=${guid})
exten=> _X.,10,Set(CDR(campaign)=${CDR(campaign)})
exten=> _X.,11,Set(MONITOR_FILENAME=${guid})
exten=> _X.,12,Set(CDR(type)=record)
exten=> _X.,13,Set(AUDIOHOOK_INHERIT(MixMonitor)=yes)
exten=> _X.,14,SipAddHeader(CTI: {"Guid": "${guid}" , "Screen": "FALSE" , "Form": "${FORM}" , "Campaign" : "${CDR(campaign)}" , "Callerid" : "${CALLERID(num)}" , "ParAndValues" : "${PARAVAL}" , "Beep" : "TRUE" , "Answer" : "TRUE" , "Dialer" : "${DIALERRECORD}"})
exten=> _X.,15,GotoIf($["${am}" = "1"]?18:16)
exten=> _X.,16,Queue(${CDR(campaign)},TtKk,,,600,,,,,)
exten=> _X.,17,Hangup()
exten=> _X.,18,WaitForSilence(1000,,)
exten=> _X.,19,AMD(6000,1500,800,2500,100,50,3,256)
exten=> _X.,20,GotoIf($["${AMDSTATUS}" = "MACHINE"]?21:16)
exten=> _X.,21,Set(__userfield=${AMDSTATUS} - ${AMDCAUSE})
exten=> _X.,22,GotoIf($["${RESPOOL}" = "true"]?24:23)
exten=> _X.,23,Hangup()
exten=> _X.,24,Set(dummy=${ODBC_Data(INSERT INTO calls_spool VALUES(${DIALERRECORD}))})
exten=> _X.,25,Goto(PowerDialer,${EXTEN},23)
 
 
  
exten=> h,1,Set(HASH(rates)=${ODBC_Data(select  rates.gateway\, rates.rate\, rates.cost\, rates.note FROM rates LEFT JOIN provider ON provider.name=rates.gateway WHERE provider.status = 'true' AND substring( '${EXTEN}'\, 1\, length( prefix_regexp ) ) REGEXP prefix_regexp ORDER BY length(prefix_regexp) DESC\,rates.rate ASC)})
exten=> h,2,Set(talkedminutes=${MATH(${CDR(billsec)} / 60,f)})
exten=> h,3,Set(talkedminutes=$[CEIL(${talkedminutes})])
exten=> h,4,Set(chargedbalance=${MATH(${talkedminutes} * ${HASH(rates,rate)},f)})
exten=> h,5,Set(realbalance=${MATH(${talkedminutes} * ${HASH(rates,cost)},f)})
exten=> h,6,Set(CDR(charged_balance)=${chargedbalance})
exten=> h,7,Set(CDR(real_balance)=${realbalance})
exten=> h,8,Set(CDR(note)=${HASH(rates,note)})
exten=> h,9,Set(CDR(carrier)=${HASH(rates,gateway)})
exten=> h,10,Set(CDR(userfield)=${userfield})
exten=> h,11,Set(CDR(direction)=outgoing)
exten=> h,12,Set(CDR(causecode)=${HANGUPCAUSE})
exten=> h,13,Hangup()

Scheduler

O scheduler de marcadores é para agendar chamadas para o marcador e concluí-las no momento certo para este tipo existe um cronograma WebService REST que lhes permite. e é possível a partir de formulários, ou fluxos de trabalho ou a partir de sistemas externos.

Basicamente, o processo é que há uma tabela onde estão as chamadas que são programadas com toda a informação pertinente

calls_scheduler

099111111:099121212

 variable1=valor1:variable2=valor2

O scheduler estar localizado na calls_spool com prioridade 1 a chamadas que têm de executar naquele minuto, o que fará com que os marcadores vão levá-lo o mais rapidamente possível para fazê-lo, é denominado Schedule base e Data para ver quais são chamadas que foram programados e quando eles devem ser realizados, a fim de comparar com o calldate do CDR.

WebService

POST
http://<IP-INTEGRASERVER>/Integra/resources/Dialers/ScheduleDialerCall
  
param: @FormParam("call") 
  
(json con formato call_scheduler)
  
{
  "calldate" : "2015-10-11 15:00:00",
  "campaign" : "Ventas->",
  "destination" : "098344484",
  "alternatives" : "099124484:099121212",
  "agentphone" : "1001",
  "data" :  "Par1=Val1:Par2=Val2"
}

RESPOOL

O respool é dada por um webservice que permite reprocessar um contato que foi tratado pela lógica de negócios, você pode inserir um contato como necessário com alternativa, prioridade, etc.

No CTI chega um regístro.

Dialer: Ventas->, 098344484, 1, Par1=val1:Par2=val2, 091121212:099888888, 1, 12, basetesting, 99, 1001

(ampanha, destino, status, parametros y valores, alternativos, nova tentativa, contactid, nomebase, prioridade, telefone agente)

POSThttp://<IP-INTEGRASERVER>/Integra/resources/Dialers/Respool
  
param: @FormParam("callspool") 
  
(json con formato call_spool)
  
{
  "callsSpoolPK": {
    "campaign": "Ventas->",
    "destination": "098344484",
    "dialerbase": "basetest"
  },
  "status": 1,
  "data": "Par1=Val1:Par2=Val2",
  "alternatives": "098124484",
  "contact": 222,
  "retries": 0,
  "priority": 99,
  "agentphone": "1001"
}

prueba1;098344484;Hola Mundo!;9999

POST
http://INTEGRASERVER/Integra/resources/SMS/SendSMS
  
params:
@FormParam("destination"), @FormParam("message"), @FormParam("campaign"), @FormParam("agent")

Necessarily we will have to insert a row at the beggining of all our bases independently of the dialer type that we will use, so as the time of exporting to csv, it is guided by the heads we have whether there are 5 or 6 in total