Higienização e Refatoração
1. O QUE É ISSO?
Não importa o quão preparado um CRM esteja para uma emergência, se os dados estiverem incorretos haverá uma ruptura nos processos, leads ou clientes não serão atendidos, agentes comerciais não serão notificados sobre tarefas ou ações importantes e clientes simplesmente não vão receber as comunicações que deveriam.
Atenção
Antes de iniciar a execução da tarefa é importante deixar claro que, nos cenários de migração e correção de conta, você JAMAIS deve deletar ou refatorar um asset sem alinhamento prévio e formalização do cliente.
Lembre-se: a comunicação é chave, por isso, comunique-se constantemente com o cliente para mitigar probabilidades de erro.
2. POR QUE É IMPORTANTE?
O epic de higienização e refatoração costuma demorar de 3 a 4 semanas para ser completamente executado.
3. AÇÕES
TAREFAS
- Deletar esse epic.
- Deletar Workflows: Liste quais fluxos são exibidos na tab Unused workflows, os com status Inativo e os que possuem um Total enrolled baixo (<=100). Verifique com o cliente se podem ser deletados. Delete esses e reserve os demais para refatoração.
- Deletar Custom Objects: Liste os objetos customizados, confira qual a data de criação do último registro e a finalidade desse objeto com o cliente. Se o objeto não possui registros nos últimos 30 dias, confira se é possível deletar.
- Deletar Pipelines: Liste todos os pipelines que não possuem um novo deal ou ticket criado há 30 ou mais dias. Acesse Deals > Lista > Exibir Todos os Deals. Faça o mesmo com Tickets! Você pode exportar os deals para realizar essa análise ou mesmo filtrar individualmente por pipeline. Contudo, uma planilha será mais rápido. Verifique com o cliente se é possível deletar os pipelines e, após deletar, o que fazer com os deals e tickets. Lembre-se, um deal e ticket nunca podem ficar sem owner ou pipeline.
- Deletar Propriedades: Em cada um dos objetos (contact, company, deal, ticket, product) ordene as propriedades por Used in. Onde for igual a zero, identifique com o cliente se podem ser deletadas. Nessa etapa, também é importante buscar por propriedades duplicadas no mesmo objeto, ou seja, propriedades que exercem a mesma função ou muito similar. Independente de onde são usadas, reserve para análise do cliente e fusão ou exclusão. Para facilitar o trabalho, selecione todas as propriedades criadas por todos os usuários menos a HubSpot.
- Deletar Forms: Liste todos os forms que não recebem um cadastro há mais de 90 dias, confira com o cliente se ainda estão sendo utilizados e, caso não estejam, delete e alinhe para que esses forms sejam substituídos por outro. Identifique se algum dos forms que estão recebendo cadastros nos últimos 90 dias poderiam ser deletados e substituídos. Aprove com o cliente! Delete esses e reserve os demais para refatoração.
- Deletar Lists: Documente as listas na tab Unused, listas que o Used in é igual a 0 ou que o Last Updated é maior ou igual a 30 dias. Confira com o cliente quais podem ser deletados. Delete esses e reserve os demais para refatoração.
- Deletar Views: Liste com o cliente todas as views que podem ser deletadas nos objetos (contact, company, deal, ticket e custom object). Delete esses e reserve os demais para refatoração.
- Deletar Dashboards e Reports: Identifique com o cliente quais dashboards e reports podem ser deletados. Delete os aprovados.
- Atribuir Record Owner: Identifique todos os objetos com records sem owner e junto com o cliente determine uma régua e um proprietário para receber os registros.
Atenção
Em uma conta operacional, você irá realizar a refatoração no ambiente de Sandbox ou produção dessa conta.
Quando se trata de uma migração de portal, você deverá refatorar esses assets no novo portal, mantendo os assets como estão na conta legada.
Portanto, não confunda esse processo de refatoração com uma migração, pois, embora existam similaridades, aqui se trata de refazer algo que deveria ser diferente em um ambiente novo.
- Refatorar Workflows: Para refatoração de workflows, você deverá primeiro ajustar a taxonomia do fluxo e alocar na pasta correta. Na sequência, irá avaliar com o cliente o que é esse fluxo, por que ele existe e qual o impacto de ser deletado. Caso não haja impacto, ele poderá ser deletado. Caso seja um fluxo importante, após ajustar pasta e taxonomia, você deve refatorar a lógica seguindo nosso playbook de workflows! Caso esse fluxo exista no modelo Nexforce ou conflite com nosso modelo, priorize a substituição do fluxo do cliente pelo nosso.
- Refatorar Pipelines: Para refatorar os pipelines, você precisará de muito cuidado, pois deletar um stage pode afetar workflows, reports e listas. Por isso, compreenda como e para qual finalidade os pipelines estão sendo utilizados e se eles deveriam continuar da forma atual ou deveriam ser mesclados.
Importante: é comum clientes terem pipelines para produtos diferentes por conta das propriedades obrigatórias do funil, terem o time de pré-vendas em um pipeline de deal, não terem a mesma estrutura da Nexforce em tickets, ou simplesmente não utilizarem as etapas reunião marcada e realizada em deal.
Esses componentes afetam diretamente a arquitetura de dados! Produtos diferentes devem existir no mesmo pipe caso o processo seja o mesmo (nesse caso, deveria haver a fusão dos pipes e criar playbooks e seções condicionais para separar propriedades). O time de pré-vendas jamais deve operar em um pipeline de deals, e sempre é necessário as etapas de reunião marcada e realizada no nosso processo. Por fim, nem sempre o cliente terá a mesma estrutura que a nossa em ticket, mas entender isso e usar o blueprint é o que fará você atuar corretamente aqui.
Lembre-se: arquitetura irá te apoiar nessa tasks no Blueprint AS IS e TO BE. Uma refatoração de pipeline é um processo delicado e que precisa ser feito com o devido acompanhamento para não quebrar a operação do cliente.
- Refatorar Propriedades: A refatoração das propriedades inclui apenas na correção do nome, grupo e valores para os objetos de contact, company, deal e ticket.
- Refatorar Forms: A refatoração dos forms, de forma geral, é mais simples, pois consiste em primeiro agrupar os forms nas pastas corretas de Marketing, Sales e Service, e, em seguida, ajustar a taxonomia dos formulários que serão mantidos.
Lembre-se: há 3 componentes críticos na taxonomia:
1) Área: Será usada nos workflows de roundrobin e reports para segmentar quais registros devem ser atribuídos ou analisados de acordo com a área.
2) Etapa do Funil: Esse item deve apenas ser utilizado nos forms de Marketing (BOFU, MOFU e TOFU) - essa taxonomia será utilizada por um workflow que irá setar a propriedade content funnel stage, que mostrará qual a etapa do funil do forms convertido.
3) Tipo de Conteúdo: Assim como no item anterior, essa propriedade é especialmente importante para Marketing, mas também pode ser utilizada por Sales e Service, pois será utilizada para saber em quais tipos de conteúdo os contatos estão convertendo, contribuindo no entendimento da eficiência dos conteúdos para influenciar os contatos. A taxonomia aqui deve conversar com a propriedade Content Type, pois essa taxonomia será utilizada pelos workflows para setar a propriedade.
Em caso de dúvidas sobre a taxonomia, por favor, entre em contato com Arquitetura.
- Refatorar Listas: Assim como nos forms, a refatoração das listas consiste em realocar as listas remanescentes nas pastas do modelo Nexforce e, posteriormente, refatorar a taxonomia. Em caso de dúvidas sobre a taxonomia das listas, entre em contato com o time de Arquitetura.
- Refatorar Views: A refatoração das Views consiste em corrigir a taxonomia nos diferentes objetos (Contact, Company, Deal e Ticket). Lembre-se: a taxonomia aqui é importante pois ela controla a ordem como as views são exibidas, e como as views influenciam o processo da operação, é importante garantir que as views mais importantes (modelo Nexforce) são exibidas primeiro.
- Refatorar das Integrações via API: Esse item consiste em corrigir integrações que eventualmente tenham sido feitas de forma incorreta. Por exemplo, é comum os clientes para criação de contatos utilizarem a API de contacts mas, como a criação desses contatos pode ser sido via um form ou chat proprietário do cliente, ele deveria ter utilizado na realidade o Form API para Formulário e o Conversations API para chat. Ou seja, o uso incorreto das APIs pode ter diversas implicações negativas na conta, como perda de dados ou mesmo ultrapassar os limites da API da HubSpot. Para esse item, solicite o apoio de Arquitetura.
DEFINIÇÃO DE PRONTO
- Com a aprovação do cliente, deletar todos os assets que são estão sendo utilizados ou que a recomendação seja deletar.
- Com a aprovação do cliente, refatorar todos os assets necessários na conta operacional ou nova.
- Aprovação de arquitetura do processo realizado.
4. MATERIAIS DE APOIO
Nexforce - Video - Higienização e Retaforação→ Clique aqui para acessar o template