3

O GitHub Issues será meu canal de suporte

Gerencio vários produtos simultaneamente. Cada um tem seu próprio domínio e sua própria caixa de entrada de suporte. Cansei de gerenciar uma ferramenta diferente para cada um deles. A solução: o suporte passa a ser uma issue no GitHub.

Um cliente envia um e-mail para support@mydomain.com, isso se transforma em uma issue em um dos meus repositórios, privado, exclusivo meu. Respondo através de comentários, da mesma forma que respondo a qualquer outra coisa no GitHub. O cliente recebe minha resposta na caixa de entrada dele e nem precisa saber que o GitHub está envolvido no processo.

Nada de nova conta para o cliente. Nada de nova ferramenta para mim. O histórico permanece versionado e pesquisável, e ganho de brinde todos os recursos que já funcionam com as Issues: marcadores (labels), projetos, respostas salvas e o aplicativo móvel para responder de qualquer lugar.

O fluxo

  1. O e-mail chega em support@domain.com
  2. O Cloudflare Email Routing o encaminha gratuitamente
  3. Um Worker processa a mensagem e cria a issue via API do GitHub
  4. Eu respondo nos comentários
  5. Um webhook do GitHub (issue_comment) aciona outro Worker
  6. Esse Worker envia minha resposta de volta por e-mail

Dois Workers pequenos, uma regra de roteamento gratuita e a API do GitHub. Nada novo para manter em execução.

O verdadeiro valor não está na ponte de conexão

Criar um sistema de e-mail para issue exige apenas um fim de semana de código de integração; essa parte é óbvia. A camada que realmente vale a pena construir fica acima disso: todos os dias, uma IA varre as issues abertas, compara cada uma com tudo o que já encerrei e sinaliza as correspondências: "isso parece com a #142, já resolvida". Para cada correspondência, ela elabora um rascunho de resposta baseado em como lidei com o caso anteriormente.

Abro minha fila de tarefas e o contexto já está lá, o rascunho já está lá; basta editar e enviar. Nada de resposta automática, nada de "caixa preta" respondendo aos clientes por conta própria. Continuo sendo eu quem decide o que é enviado; a IA apenas elimina a etapa de redigitar a mesma resposta pela sexta vez.

Isso já existe?

Pesquisei. Muitas ferramentas de helpdesk se integram ao GitHub (Zendesk, HappyFox, HelpDesk.com), mas todas mantêm o ticket no próprio helpdesk e apenas o espelham no GitHub para visibilidade da equipe de desenvolvimento. Existe uma ferramenta pequena, o HubDesk, que faz exatamente isso, transforma e-mails em chamados, sem um sistema de helpdesk complexo por trás, mas não vejo tração nenhuma: não há avaliações, nem estudos de caso, e a organização no GitHub tem apenas um seguidor.

Talvez seja algo muito específico do meu flow de trabalho, mas está sendo bem intressante usar. Mais alguém fazendo algo similar?

Carregando publicação patrocinada...
1

Me pareceu um bom fluxo para alguns casos de uso. Senti um alívio ao entender com o texto que o GitHub Issues é o seu canal de suporte, e não o do cliente.

Quantos "tickets" você costuma receber por semana (ou mês)?

Isso tem chances de ficar desorganizado se o cliente mandar um novo e-mail ao invés de responder outro (o assunto se dividirá em dois issues), mas pelo menos hoje dá para adicionar um "issue pai" no GitHub.

Adicionar labels na criação dos issues pode ajudar a IA a filtrar o que é realmente relevante (issues do projeto em questão).

2

Recebo uns 20/30 tickets por semana somando de todos os produtos.

Otimo ponto sobre a desorganização, mas é ai que a IA entra. Diariamente tem um fluxo que faz como se fosse uma triagem. Ai casos como esse vão ser "mergeados" e tal.

Não tenho um volume grande de tickets, mas mesmo assim isso já ajudou demais.

valeu por comentar!