> For the complete documentation index, see [llms.txt](https://docs.helena.app/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.helena.app/duvidas-e-novidades/novidades-de-produto/julho-de-2026/31-07-2026.md).
# 31/07/2026
### **📊** Relatórios: Tempo de Primeira Resposta zerado mesmo com atendimentos concluÃdos no perÃodo
No quadro "Qualidade do atendimento por equipe" (e por usuário), o indicador de tempo de **Primeira Resposta** podia aparecer zerado mesmo quando a equipe tinha diversos de atendimentos concluÃdos no perÃodo.
**O que foi corrigido?**
* O cálculo do tempo de Primeira Resposta passou a considerar corretamente os atendimentos iniciados pelo contato (receptivos).
* Quando o tempo de resposta é muito curto (menos de 1 segundo), o valor passou a ser exibido em milissegundos, em vez de aparecer como zero
* Respostas de chatbots ou agentes de IA continuam não sendo consideradas como primeira resposta. O indicador reflete apenas a resposta de um agente humano
* Atendimentos concluÃdos sem nenhuma interação entre contato e agente humano, ou iniciados pela própria empresa, continuam fora do cálculo da mediana
### 💬 Canais: Falha intermitente no envio de imagens JPEG em modelos de mensagem rápida
Imagens JPEG podem ser salvas em diferentes modos de cor. O modo RGB é o padrão de telas, redes sociais e WhatsApp. Já o modo CMYK é usado em materiais criados para impressão: banners, panfletos e artes feitas em softwares de design costumam vir nesse formato. O WhatsApp aceita apenas imagens em RGB, mas o sistema não fazia essa distinção ao validar o arquivo: como a extensão, o tipo e o tamanho estavam corretos, o envio era aceito normalmente.
O WhatsApp, porém, recebia a imagem e a rejeitava em seguida, exibindo no chat o aviso *"Não foi possÃvel realizar o carregamento da mÃdia, verifique se o formato e tamanho do arquivo está de acordo com os requisitos e envie novamente"*. O resultado era uma falha que parecia aleatória, o mesmo modelo funcionava em alguns atendimentos e falhava em outros, dependendo apenas de qual imagem havia sido usada na hora do cadastro.
**O que foi corrigido?**
O sistema passou a identificar e tratar imagens JPEG em modo CMYK antes de enviá-las ao WhatsApp. Com isso:
* Modelos de mensagem rápida com imagens criadas para impressão passam a ser enviados corretamente
* A falha intermitente no envio deixa de ocorrer para esse tipo de arquivo
* Imagens que antes eram aceitas no cadastro mas rejeitadas no envio agora são processadas de forma adequada
### 🤖 Chatbot: Card criado pelo bot não recebia o responsável correto pelo atendimento
Quando um fluxo de chatbot está configurado para atribuir automaticamente o card ao responsável pelo atendimento, o sistema vinculava o card ao agente no momento em que ele era criado , mas não atualizava essa informação se o responsável pelo atendimento mudasse depois. Em alguns cenários, especialmente quando o bot iniciava o atendimento antes de qualquer agente assumir a conversa, o card ficava sem o responsável correto mesmo após a atribuição acontecer.
**O que foi corrigido?**
A lógica de atribuição automática foi ajustada para manter o card sempre sincronizado com o responsável atual pelo atendimento. Agora:
* Cards criados pelo chatbot com **"Atribuição automática"** habilitada acompanham o responsável pelo atendimento em tempo real
* A sincronização se mantém enquanto o atendimento não for assumido por um agente ou concluÃdo
* O responsável no card passa a refletir corretamente quem está atendendo, independentemente do momento em que o bot criou o card
### 💬 Canais: Atendimento duplicado ao enviar mensagem pelo app do WhatsApp em canal Z-API
Em canais conectados via Z-API, quando um agente iniciava um atendimento pela plataforma e depois enviava uma mensagem para o mesmo contato diretamente pelo aplicativo do WhatsApp, a plataforma abria um segundo atendimento em paralelo para a mesma pessoa. Isso acontecia porque o WhatsApp identifica o contato de formas diferentes dependendo do canal de envio: pela plataforma, usa o número de telefone; pelo aplicativo, usa um identificador interno do WhatsApp.
Como o sistema ainda não havia associado essas duas identificações ao mesmo contato, interpretava a mensagem do app como se fosse de uma conversa nova e criava um atendimento separado. O resultado eram dois atendimentos abertos simultaneamente para o mesmo contato, com mensagens chegando de forma fragmentada entre eles.
**O que foi corrigido?**
A lógica de identificação de contatos em canais Z-API foi ajustada para reconhecer que o número de telefone e o identificador interno do WhatsApp pertencem à mesma pessoa. Agora:
* Mensagens enviadas pelo app do WhatsApp são corretamente vinculadas ao atendimento já aberto na plataforma para aquele contato
* Não há mais abertura de atendimento duplicado nem criação de contato duplicado nesse cenário
* Quando um novo atendimento é iniciado pela plataforma para um contato que já tem uma conversa em aberto pelo app, o atendimento anterior é encerrado automaticamente