[AsteriskBrasil] Problema de transferencia na fila de atendimento

[Moisés de Oliveira Santos]

Olá Alexandre,

Obrigado por responder. Eu consegui resolver o problema de transferência
aqui no meu callcenter, eu uso o próprio queuemetrics para autenticar os
agentes. Eu estava fazendo o login do agente da seguinte maneira:
Local/9077 em ramais/n e descobri que desse forma a transferência não funciona.
Pesquisando na internet encontrei que se tirar o "/n" funciona, e foi o que
eu fiz. Agora logo os agentes sem o /n, ex: Local/9077 em ramais e as
transferencias funcionam. Gera o log do queue_log com o TRANSFER
normalmente.

Segue uma linha do queue_log, onde temos o agente 9077 da fila tele1
transferindo para a fila tele2:

1298398710|1298398683.23571|tele1|9077|TRANSFER|tele2|ramais|2|17|3

para transferir estou usando o #9, percurso da ligação:

1 - Ligação entra na fila tele1
2 - Vai para o agente 9077
3 - aparece no Monitoramento em tempo real do queuemetrics o agente
atendendo;
4 - O cidadão pede pra falar com a fila tele2
5 - O agente transfere para fila tele2, usando #9 + RAMAL DA FILA (usando o
#9 o agente transfere e automaticamente  a ligação cai para ele)
6 -  a chamada encerra no queuemetrics da fila tele1 e automaticamente
aparece na fila tele2
7 - o agente da fila tele2 atende a ligação.

Podia-se usar também a transferencia assistida que funciona o *2 + RAMAL DA
FILA

Eu não fiz o teste na transferência para outro agente ate porque não
precisamos disso aqui. Mas vou testar e posto depois o resultado.

Bom foi isso.

vlw

Moisés de Oliveira



Em 22 de fevereiro de 2011 14:53, alexandre - aldeia digital <
alepaes em ad2.com.br> escreveu:

> Salve,
>
> Realmente é um problema, principalmente quando a transferência não é
> feita para outra fila, mas para outro agente:
>
> O agente atendeu, mas ele não é a melhor pessoa para solucionar o
> problema e transfere para o colega do lado.
> Resultado: evento TRANSFER no queuelog e só. Como não entrou em outra
> fila, essa chamada não tem mais medição.
> No site do Queuemetrics, já avisa que isso é "by design" no asterisk e
> até não discordo que o comportamento é correto, já que ele está de certa
> forma saindo da fila.
>
> No VICIDIAL/GoAutoDial a ideia, pelo que entendi, é forçar o atendente
> atual a parkear e falar com o outro atendente, transferindo por uma
> função própria depois (acredito que um redirect da vida).
> Mas não sei como ele deixa isso no relatório para contabilizar o
> atendimento de cada um dos agentes nem se isso é só para agentes ativos
> (aí fica fácil porque você mesmo gera seus logs).
>
> O cenário ideal seria:
> * Transferência completada, gere os eventos TRANSFER e COMPLETEAGENT com
> o agente atual.
> * Gere um CONNECT com o novo agente.
> * Gere um COMPLETEAGENT ou COMPLETECALLER para o novo agente no término.
>
>
> Abraço,
>
> Alexandre
> Aldeia Digital
>
> Em 14-02-2011 18:50, Moisés de Oliveira Santos escreveu:
> > Pessoal,
> >
> > estou com o seguinte problema:
> >
> > Estou usando o queuemetrics para monitoramento de minhas filas em um
> > servidor asterisk versão 1.6.2.14, tudo funcionando, mas na hora de
> > transferir de uma fila para outra, ai os problemas começam, por exemplo:
> >
> > Liguei para fila 5001 e atendi com o agente 8155, dai o agente percebeu
> > que a ligação era para outra fila e transferiu usando o # + NUMERO DA
> > FILA, ou #5002, com isso a transferencia ocorrou normalmente, mas na
> > fila 5001 no queuemetrics a ligação ainda conta como ativa e no caso eu
> > gostaria que ela fosse encerrada nessa fila. No queuemetrics a ligação
> > chega na fila 5002 certinho. Mas ainda continua ativa na fila 5001 desse
> > modo perceba o problema. Para o asterisk o agente 8155 que atendeu a
> > ligacao na fila 5001 quando ele transfere o canal dele desocupa apto
> > para receber ligações, mas no queuemetrics a ligacao que ele transferiu
> > continua como ativa. E se chegar outra  ligacao ele vai atender e no
> > queuemetrics vai mostrar como se ele estivesse em 2 ligações.
> >
> > Alguém já passou por isso? Sabe como eu posso resolver?
> >
> > Obrigado a todos, Boa Noite!!!
> >
> > --
> > Moisés
> > Gerente de TI
> > Msn: moises em linfox.com.br <mailto:moises em linfox.com.br>
> >
> >
> >
> >
> > _______________________________________________
> > KHOMP: qualidade em placas de E1, GSM, FXS e FXO para Asterisk.
> > - Hardware com alta disponibilidade de recursos e qualidade KHOMP
> > - Suporte técnico local qualificado e gratuito
> > Conheça a linha completa de produtos KHOMP em www.khomp.com.br
> > _______________________________________________
> > Headsets Plantronics com o melhor preço do Brasil.
> > Acesse agora www.voipmania.com.br
> > VOIPMANIA STORE
> > ________
> > Lista de discussões AsteriskBrasil.org
> > AsteriskBrasil em listas.asteriskbrasil.org
> > http://listas.asteriskbrasil.org/mailman/listinfo/asteriskbrasil
> > ______________________________________________
> > Para remover seu email desta lista, basta enviar um email em branco para
> asteriskbrasil-unsubscribe em listas.asteriskbrasil.org
> _______________________________________________
> KHOMP: qualidade em placas de E1, GSM, FXS e FXO para Asterisk.
> - Hardware com alta disponibilidade de recursos e qualidade KHOMP
> - Suporte técnico local qualificado e gratuito
> Conheça a linha completa de produtos KHOMP em www.khomp.com.br
> _______________________________________________
> Headsets Plantronics com o melhor preço do Brasil.
> Acesse agora www.voipmania.com.br
> VOIPMANIA STORE
> ________
> Lista de discussões AsteriskBrasil.org
> AsteriskBrasil em listas.asteriskbrasil.org
> http://listas.asteriskbrasil.org/mailman/listinfo/asteriskbrasil
> ______________________________________________
> Para remover seu email desta lista, basta enviar um email em branco para
> asteriskbrasil-unsubscribe em listas.asteriskbrasil.org
>



-- 
Moisés de Oliveira Santos
Gerente de TI
Msn: moises em linfox.com.br
Skype: moisesosantos
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: http://listas.asteriskbrasil.org/pipermail/asteriskbrasil/attachments/20110222/a456aa10/attachment.htm