Email-to-Service-Request
Um residente que escreve para o seu endereço de suporte para relatar uma torneira vazando não deveria precisar esperar que alguém copie a mensagem dele em um chamado. O Email-to-Service-Request abre o chamado por ele. Aponte uma caixa de correio de suporte ou de manutenção para a REDA e todo e-mail que chegar lá vira automaticamente uma Solicitação de serviço — com assunto e descrição retirados diretamente da mensagem, o contato do remetente vinculado quando a REDA o reconhece, e o e-mail original arquivado na solicitação, para que a sua equipe tenha as palavras do próprio residente diante dos olhos. Esse é o mesmo padrão do Email-to-Inquiry, voltado ao trabalho de serviço em vez de vendas. Este artigo explica como ele funciona, o que a REDA grava na solicitação e como direcionar uma caixa de correio de suporte por meio dele.
Acesso necessário. Para trabalhar as solicitações que chegam, basta o seu acesso normal ao registro de Solicitação de serviço. Configurar um endereço de entrada é trabalho de administrador, coberto em Configuração do Email Services.
O que o Email-to-Service-Request faz
Um endereço de entrada é uma porta para a sua fila de serviço. O seu administrador designa uma caixa de correio — um endereço de suporte, um endereço de manutenção — como endereço de entrada para solicitações de serviço. A partir daí, todo e-mail enviado ou encaminhado para ele é lido pela REDA e transformado em uma Solicitação de serviço, com o próprio e-mail arquivado no registro, para que o pedido exato do residente nunca se perca em uma passagem de bastão.
Um ponto essencial diferencia isso do caminho dos Leads: uma solicitação de serviço é criada mesmo quando a REDA não reconhece o remetente. O e-mail de suporte costuma vir de endereços que ainda não estão cadastrados — um residente novo, um prestador de serviço, uma caixa de correio compartilhada da família — e nada disso deveria impedir a abertura de um chamado. Se a REDA reconhecer o remetente, ela vincula o contato dele à solicitação por conveniência; se não reconhecer, a solicitação é criada mesmo assim e o endereço de e-mail do remetente é preservado, para que a sua equipe possa identificá-lo e falar com ele.
- Todo e-mail abre uma solicitação. Uma mensagem para o endereço de entrada cria uma nova solicitação de serviço, pronta para a triagem da sua equipe.
- O contato é vinculado quando é conhecido, mas não é obrigatório. Um remetente reconhecido fica vinculado à solicitação; um remetente desconhecido também gera uma solicitação, com o endereço dele registrado nela.
- A mensagem é sempre preservada. O e-mail original é arquivado na solicitação, com a formatação e os anexos intactos.
- As respostas permanecem na solicitação. Depois que uma solicitação existe, as respostas dentro do encadeamento dela são arquivadas nessa mesma solicitação, em vez de abrir uma nova, de modo que uma troca de mensagens em andamento fica em um só lugar.
- Nada se perde. Se a REDA não conseguir criar a solicitação, o e-mail fica retido para revisão em vez de ser descartado (veja Quando uma solicitação não pode ser criada).
Como um e-mail vira uma solicitação
Diferente do caminho dos Leads, que reaproveita o Lead aberto de um prospect, um novo e-mail para um endereço de entrada de serviço abre uma nova solicitação — porque dois e-mails separados normalmente significam dois problemas separados a resolver. É a resposta que se encadeia em uma solicitação existente, não toda nova mensagem da mesma pessoa.
O que a REDA grava na solicitação
| Na solicitação de serviço | De onde vem |
|---|---|
| Assunto | A linha de assunto do e-mail, de modo que a solicitação recebe como título o que o residente escreveu. |
| Descrição | O corpo do e-mail, de modo que todos os detalhes do problema ficam registrados na solicitação. |
| Contact | O contato do remetente, vinculado quando a REDA reconhece o endereço de e-mail dele. Fica em branco — mas com o endereço do remetente preservado — quando o remetente é desconhecido. |
Além disso, o próprio e-mail é arquivado na solicitação — visível na linha do tempo de Atividade e na lista relacionada E-mails — com os anexos salvos nos Arquivos da solicitação. A partir daí, a solicitação se comporta como qualquer outra: a sua equipe atribui, trabalha e resolve, com o e-mail de origem sempre anexado como fonte da verdade sobre o que foi pedido.
O que o usuário final faz e vê
- Você acompanha a lista de Solicitações de serviço. As solicitações originadas de e-mail aparecem na guia Solicitações de serviço ao lado daquelas abertas manualmente. Trabalhe-as como parte da sua fila normal.
- Você pode encaminhar solicitações para lá. Se um residente escrever para uma caixa de correio pessoal por engano, encaminhar essa mensagem para o endereço de entrada abre uma solicitação de serviço a partir dela.
- Você lê o e-mail de origem no registro. Abra a solicitação e a mensagem do residente estará na linha do tempo de atividades — as palavras exatas dele, mais qualquer foto ou documento que tenha anexado.
- Você responde a partir da solicitação. Responder de dentro da solicitação mantém a conversa registrada nela, e as respostas do residente se encadeiam de volta no mesmo registro; veja Envio de e-mail pelo REDA.
Quando uma solicitação não pode ser criada
Se a REDA não conseguir transformar um e-mail em uma solicitação de serviço — uma mensagem à qual falta algo necessário, ou que esbarra em uma regra que impede a criação — o e-mail não se perde. Ele fica retido na fila de Unmatched Email com todo o seu conteúdo, para que um administrador possa revisá-lo, corrigir o que bloqueou a criação e abrir a solicitação manualmente. É a mesma fila de revisão que recolhe os e-mails sincronizados automaticamente sem correspondência e as falhas de entrada de Leads, então a sua equipe de triagem tem um único lugar para acompanhar. Ela é detalhada em A fila Unmatched Email.
Como começar a usar o Email-to-Service-Request
Exemplo prático: um e-mail de manutenção vira uma solicitação
Uma residente, Aisha Rahman, escreve para o suporte da Meridian Properties: assunto "Torneira da cozinha não para de pingar", com uma breve descrição e uma foto anexada. Como Aisha é uma residente já cadastrada, a REDA reconhece o endereço dela e vincula o contato dela à nova Solicitação de serviço — com o Subject "Torneira da cozinha não para de pingar" e a Description trazendo a mensagem dela, e a foto salva nos Arquivos da solicitação. A equipe de manutenção a assume pela guia Solicitações de serviço.
Se o e-mail tivesse vindo de um endereço que a REDA não reconhecesse — um locatário novo, ainda não cadastrado — a solicitação teria sido aberta do mesmo jeito, com assunto e descrição intactos, e com o e-mail do remetente preservado para que a equipe pudesse identificá-lo e falar com ele; o contato simplesmente ficaria para alguém vincular depois. Quando Aisha responde à resposta da equipe sobre o agendamento de uma visita, essa resposta se encadeia na mesma solicitação em vez de abrir uma segunda.
O que vem a seguir
- REDA Email Services: visão geral — como o Email-to-Service-Request se posiciona ao lado do Auto-Sync e do Email-to-Inquiry.
- Email-to-Inquiry — o mesmo padrão para consultas de vendas e de locação.
- Email Auto-Sync — como as respostas posteriores do residente e as suas respostas são arquivadas na solicitação.
- A fila Unmatched Email — onde espera um e-mail que não pôde virar uma solicitação.
- Email Services: solução de problemas — o que verificar quando os e-mails de suporte não estão virando solicitações.
Perguntas frequentes
Eles seguem o mesmo padrão para trabalhos diferentes. O Email-to-Inquiry cria Leads — leads de vendas e de locação — a partir de uma caixa de correio de consultas. O Email-to-Service-Request cria Solicitações de serviço — itens de suporte e de manutenção — a partir de uma caixa de correio de suporte. Cada endereço de entrada é configurado para um ou para o outro.
Não. Se a REDA reconhece o remetente, ela vincula o contato dele à solicitação de serviço, mas a solicitação é criada mesmo quando o remetente é desconhecido. O endereço de e-mail é preservado nos dois casos, então você consegue identificar quem escreveu.
Um e-mail novo para o endereço de entrada abre uma nova solicitação de serviço. Já as respostas dentro do encadeamento de uma solicitação existente são arquivadas nessa mesma solicitação, em vez de abrir outra — assim, uma troca de mensagens em andamento permanece em um único registro.
O Subject da solicitação é retirado da linha de assunto do e-mail e a Description, do corpo da mensagem, de modo que o chamado descreve o problema com as palavras do próprio residente.
Se a REDA não conseguiu criar a solicitação de serviço a partir de uma mensagem, o e-mail fica retido na fila Unmatched Email com todo o seu conteúdo, para que um administrador possa revisá-lo e criar o registro manualmente. Nada é descartado.
Isso foi útil?