Atendimento ao cliente
Cliente errado no ticket de e-mail? Corrija o solicitante sem perder o thread
Encaminhamentos de colegas e caixas compartilhadas costumam grudar a pessoa errada como solicitante. Religue o cliente no ticket de e-mail, mantenha a conversa completa e deixe plugins e portal honestos.
Um colega encaminha o e-mail de um cliente para o suporte. O endereço da caixa compartilhada vira o “cliente.” Outra pessoa no thread fica ligada como dona na triagem inicial. As mensagens estão boas—a identidade está errada.
O solicitante é o cliente a quem o ticket pertence agora: a pessoa que o Para da resposta segue, o que plugins e histórico recente usam como chave e (com self-service ligado) quem abre o thread no portal. Enquanto o vínculo estiver errado, tudo isso segue a pessoa errada. Recriar o ticket joga contexto fora. Mudar o solicitante mantém o thread e corrige a propriedade.
Por que o ticket acaba associado ao cliente errado
Tickets de e-mail herdam identidade de como o e-mail chegou ou de quem foi selecionado na criação. Falhas comuns:
- Um colega encaminha a mensagem do cliente, e o colega (ou um endereço genérico) vira o solicitante.
- Um endereço de caixa compartilhada é tratado como o cliente em vez de quem precisa de ajuda.
- O contato errado é escolhido ao compor ou nos primeiros minutos da triagem.
Esse vínculo é estável de propósito —- tickets precisam de um cliente consistente. O custo é que um erro de roteamento pontual pode atribuir mal a conversa inteira até alguém corrigir.
O que Alterar solicitante faz
Em um ticket de e-mail, agentes com acesso à caixa de entrada do ticket podem abrir ⋯ Actions (canto superior direito da tela do ticket) e escolher Alterar solicitante.
O que acontece:
- O solicitante ao vivo do ticket religa para outro cliente (existente, encontrado pelo e-mail, ou criado com e-mail + nome).
- A conversa completa permanece—você não clona nem fecha o ticket.
- Uma nota interna do sistema registra a mudança para auditoria.
- A UI que depende do cliente atual atualiza: sidebar, plugins, tickets recentes e o endereço Para da resposta.
- Se a organização tem roteamento de CC ativo, você pode opcionalmente manter o solicitante anterior em Cc (desmarcado por padrão).
Pense em quem é dono deste ticket agora, não em cabeçalhos From congelados na criação.
Como corrigir
- Abra um ticket de e-mail.
- Abra o menu ⋯ Actions no canto superior direito da tela do ticket.
- Escolha Alterar solicitante.
- Revise o resumo do solicitante atual.
- Informe o e-mail do novo solicitante (digite ou escolha nas sugestões de clientes).
- Se o e-mail for um cliente novo, preencha o campo Nome obrigatório.
- Se o roteamento de CC estiver ativo, decida se marca Manter solicitante anterior em Cc.
- Leia os avisos na tela e confirme Alterar solicitante.
Após o sucesso, o ticket atualiza com o novo cliente, a nota de auditoria aparece na timeline, plugins e tickets recentes seguem a nova identidade, e o compositor preenche novamente o Para / Cc a partir dos destinatários atualizados.
Antes de confirmar: três cuidados
| Atenção | O que esperar |
|---|---|
| Plugins | Sidebars ligadas ao e-mail do cliente atual (faturamento, CRM, dados customizados) atualizam para a nova identidade—dados do endereço antigo podem sumir do painel. |
| Portal de self-service | O novo solicitante ganha acesso ao portal para o thread inteiro; o antigo perde. Avise o time antes de surpreender qualquer um dos lados. |
| Canal | A ação é somente e-mail. Fica oculta no Telegram e em outros canais. |
Também: se você só precisa corrigir um erro de digitação no nome de exibição sem mudar a identidade, edite o registro do cliente em vez de mudar o solicitante.
Identidade correta, história intacta
Tickets de e-mail mal atribuídos são atrito comum de operação, não motivo para reconstruir histórico. Mude o solicitante quando a pessoa errada estiver grudada no ticket, mantenha o thread e trate plugins e acesso ao portal como parte da decisão—não como detalhe de última hora.
Para fluxos relacionados, veja Transfira uma conversa de suporte sem perder o cliente (propriedade do agente) e Autoatendimento que realmente é usado (hábitos de portal). Mais notas de produto em Updates.