Eficiência converter emails para suporte@ em ticket

[edvan]

Na epoca, tentei implementar a utilização deste recurso, mas não consegui me adaptar.

 

E por causa disso emails enviados para o suporte não são convertidos em ticket...

 

Chuva,

 

Qual foi sua dificuldade? Utilizo esse recurso há mais de 3 anos e não tenho problemas.

[chuvadenovembro]

Chuva,

 

Qual foi sua dificuldade? Utilizo esse recurso há mais de 3 anos e não tenho problemas.

 

Então Edvan,

 

Até coloquei aqui no tópico mesmo, veja alguns detalhes:

 

Quando eu mandei suporte@ mandar copia dos emails para email2@, e tinha a configuração em email2@, mesmo com a opção clients only habilitado, todo email recebido era criado um ticket (independente de clientes ou não), por ser um email com aquela opção remetente não funciona adequamente.

Então decidi fazer uma copia dos meus emails de suporte, limpei a caixa de entrada dele e fiz a configuração diretamente nele.

O primeiro problema que tive, os emails de cron daemon enchen o saco, e são criados tickets.

Os emails que o suporte@ recebe para avisar que foi aberto um ticket é mais bizarro ainda, além criar tickets, eles respondem um ticket aberto, no qual fica imediatamente respondido e você só tem condições de saber se foi aberto o ticket depois que entra no sistema e verifica os tickets respondidos.

Para contornar estes problemas, criei filtros no cpanel para remover emails com os titulos (do cron daemon, aviso de que foi aberto um ticket, cron e algum outro que não lembro no momento), lembrando que estes emails são duplicados para email2@ e teoricamente, ele faz a copia do email antes de remover.

A principio, estou um pouco desapontado com o sistema, não esta me parecendo tão eficiente e para faze-lo funcionar no suporte@ é preciso criar varios filtros...com isso o sistema fica dependente de várias gambiarras.

Ainda sim, decidi deixar configurado e vamos ver como ficará, pretendo deixar assim por uma semana. (se bem que hoje vou procurar maiores informações em foruns gringos, se eu achar relatos de muitas falhas vou desconfigurar enquanto estamos no feriado hehehehehe

 

Eu postei isso a dois anos (tempo passa rapidinho heim hehehe)

 

Atualmente recebo um volume muito maior de emails e no suporte por questões de segurança, recebo avisos do servidor como: relay, autorelay, failhas, cxs, maldet, e uma porrada de coisas...hoje acabo usando os emails do cron para verificar log de backups

 

E com um volume alto de emails assim, teria que fazer aquele mesmo esquema, replicar tudo para um segundo email e neste segundo email o whmcs transformar apenas emails dos clientes em tickets, mas na ocasião em que testei isso não funcionou de forma adequada então desisti de usar...

 

:(

[edvan]

Então Edvan,

 

Até coloquei aqui no tópico mesmo, veja alguns detalhes:

 

 

Eu postei isso a dois anos (tempo passa rapidinho heim hehehe)

 

Atualmente recebo um volume muito maior de emails e no suporte por questões de segurança, recebo avisos do servidor como: relay, autorelay, failhas, cxs, maldet, e uma porrada de coisas...hoje acabo usando os emails do cron para verificar log de backups

 

E com um volume alto de emails assim, teria que fazer aquele mesmo esquema, replicar tudo para um segundo email e neste segundo email o whmcs transformar apenas emails dos clientes em tickets, mas na ocasião em que testei isso não funcionou de forma adequada então desisti de usar...

 

 

Isso realmente é complicado... por isso optei por separar os avisos em e-mails distintos!

 

suporte@ ou atendimento@ são exclusivos para criação de tickets ( Mail Parser ) e funciona 100%.

 

O erro mais comum é esse ( http://docs.whmcs.com/Email_Piping#Ticket_ID_Not_Found ).

[Leonardo_Gomes]

Nao sabia que tinha essa função