Não construa, integre – um guia para integração de CRM

Digamos que você esteja trabalhando para uma startup que vende robôs em todos os setores. Você recebe pedidos de vários clientes e uma equipe de operações avalia os pedidos e trabalha com fornecedores terceirizados para que seus clientes tenham o robô certo.

Construir o MVP foi estressante, mas também muito divertido. Seus investidores estão animados e enchem você de dinheiro. A próxima fase começa. Você precisa de mais visibilidade na lucratividade e deseja adquirir clientes maiores que precisam de faturamento mais sofisticado. Ao mesmo tempo, você tem um roteiro de produto bastante sofisticado para permitir a venda de robôs com margens mais altas. Os recursos são escassos, mas você ainda precisa ter certeza de manter a empresa funcionando.

Como muitas vezes pregado para empresas menores, focar nas coisas em que você é bom é uma ótima regra. Mas e todas as áreas que mantêm as operações diárias da sua empresa funcionando? Você certamente não quer construir um sistema de gerenciamento de relacionamento com o cliente (CRM) ou um sistema de contabilidade. Afinal, existem muitos produtos por aí que resolvem todos os problemas. Mas como esses sistemas funcionarão em conjunto com seu sistema de pedidos existente?

É aqui que a integração de terceiros é útil. Então, vamos mergulhar e ver se podemos evitar algumas armadilhas comuns.

Integração CRM

Esteja você fazendo vendas de baixo contato (marketing de conteúdo, anúncios de mídia social ou boletins informativos) ou vendas de alto contato (chamadas frias, participando de conferências ou acompanhando clientes existentes por telefone), um sistema de CRM pode oferecer muito visibilidade sobre como você está se saindo com os clientes existentes e como você é bem-sucedido em convencer novos clientes.

Muitas vezes, a seleção de um sistema de CRM é deixada principalmente para o departamento de vendas e marketing. Em geral, não há nada de errado com isso. Afinal, essas pessoas sabem melhor como aumentar a receita e precisam do melhor suporte disponível. Mas mesmo o melhor software não vale nada se não funcionar corretamente em conjunto com o sistema de pedidos do seu robô.

Inclua seu departamento técnico na decisão

Seja o CTO ou um engenheiro dedicado, mantenha-os informados desde o início. Eles provavelmente fornecerão mais informações sobre como os dois sistemas funcionarão juntos no futuro.

E uma palavra para os engenheiros: mantenham a mente aberta para soluções de terceiros. É fácil descartá-los porque sua API não é a melhor ou sua interface do usuário é feia. No entanto, pode ser muito gratificante encontrar soluções elegantes em torno dos sistemas existentes.

No entanto, existem alguns tópicos que podem ser benéficos para falar antes de tomar uma decisão. Tópicos gerais como “Precisamos disso?” precisa ser endereçado. Mas também é uma boa ideia já ter uma ideia de qual é o escopo. Existe a necessidade de uma sincronização bidirecional ou o sistema de terceiros apenas seguirá o sistema de pedidos? Uma vez que o escopo está fora do caminho, também precisa haver uma discussão técnica sobre detalhes de implementação, como webhooks ou avaliação dos limites da API.

Você precisa de uma integração personalizada?

Quando se trata de integração, não é de surpreender que já existam plataformas que prometem resolver alguns dos problemas que você provavelmente encontrará. Atualmente, Zapier e IFTTT são os mais promissores.

Dependendo do problema que você está tentando resolver, seu sistema de pedidos de robôs pode nem estar envolvido na integração. Digamos que você esteja gerenciando seus assinantes de newsletter com um sistema de CRM como Salesforce ou HubSpot e apenas queira uma maneira mais conveniente de contatá-los por meio de um provedor de serviços de e-mail como Mailchimp, o Zapier tem várias integrações existentes para ajudá-lo com isso. A partir deste ponto, escolher um provedor que tenha um conector Zapier é um bom caminho a seguir.

E mesmo que se trate de integrar dados personalizados (robôs encomendados e seu preço), o Zapier Webhooks pode atuar como um intermediário para sua integração.

Por outro lado, se você já está enviando dados para terceiros, por que não enviá-los diretamente para o sistema de CRM? Quanto mais dados você quiser sincronizar, mais útil será a integração direta.

O que me leva ao meu próximo ponto.

Você precisa de sincronização bidirecional?

Normalmente, uma integração começa com um requisito simples, como Podemos colocar todos os nossos clientes em nosso sistema de CRM? , normalmente combinado com os valores de pedidos de robôs individuais, facilitando a utilização de ferramentas de segmentação de clientes.

No entanto, mais cedo ou mais tarde, pode ser que as pessoas queiram usar as ferramentas de gerenciamento de contatos que um pacote de CRM normalmente oferece. Isso inclui recursos como desduplicação, alteração de detalhes de contato com dados de mídia social, normalização de endereços de entrega ou simplesmente excluir contatos antigos.

A alteração de contatos em um sistema de CRM provavelmente significará que você precisará alterar os detalhes de contato em outro sistema, ou seja, as alterações precisam ser feitas nos dois sentidos.

O esforço de implementação para isso está muito além de uma simples sincronização unidirecional, portanto, este é um excelente ponto para pensar em como você deseja usar um novo sistema estrategicamente.

Como você será notificado das alterações do CRM?

Se você decidir ter uma sincronização bidirecional, há uma pergunta de acompanhamento: como você sabe que algo mudou no lado do CRM?

A maioria dos provedores de sistemas tem ferramentas para isso, mas a melhor para mudanças imediatas são os webhooks — basicamente, um sistema de notificação HTTP que pode ser configurado para informar sobre mudanças relevantes (para alguns sistemas, mesmo campo a campo) .

Caso o sistema não ofereça webhooks, pelo menos verifique se consegue obter uma lista de todas as entidades que foram atualizadas recentemente. Dessa forma, você não precisa passar por todos os contatos e negócios apenas para atualizar seus próprios dados. Mas lembre-se de que você precisará pesquisar o sistema em intervalos regulares.

Nesse caso, seu sistema de pedidos ainda mudaria e criaria dados por meio de uma chamada de API no sistema CRM. Mas todas as alterações do sistema CRM seriam pesquisadas em um intervalo definido.

O que vale ressaltar é que as atualizações ficarão restritas a esse intervalo e podem levar à inconsistência temporária dos dados. Por exemplo, quando você sincroniza apenas uma vez por dia do sistema CRM para o sistema de pedidos, os dados que você está visualizando no sistema de pedidos podem ter até 24 horas.

Dependendo de quais recursos o sistema oferece, a tarefa de integração pode variar em complexidade e tempo de implementação. Certifique-se de verificar o que o sistema oferece com antecedência e verifique o plano que você pretende comprar. Por exemplo, alguns sistemas de CRM oferecem webhooks nas camadas mais bem pagas.

Um exemplo aqui é o CRM da HubSpot, que oferece webhooks em geral, mas o recurso de webhook está disponível apenas no pacote Enterprise. As ferramentas de contabilidade Zoho Books oferecerão cinco fluxos de trabalho automatizados (que incluem webhooks) em seu nível mais baixo.

Seus dados estão em boa forma?

Quando se trata de criar conjuntos de dados em um sistema externo, é bom saber como os dados se parecem em seu próprio sistema. Felizmente, não há muitas maneiras diferentes de apresentar contatos e negócios, mas um campo que sempre causa problemas é o campo de e-mail.

Diferentes sistemas têm ideias diferentes sobre o que é um endereço de e-mail válido, e aqui está um alerta de spoiler – seus clientes podem ter fornecido endereços de e-mail inválidos de todos os tipos. Muitos sistemas de CRM rejeitam a criação de um contato com um endereço de e-mail inválido (e, claro, o provedor de CRM define o que é válido e o que não é).

Dica: se possível, sincronize apenas endereços de e-mail confirmados com seu CRM. Isso vai lhe poupar muita dor a longo prazo.

Limitações da API

Por fim, as limitações da API são algo que precisa ser resolvido o mais cedo possível.

Supondo que haja uma API (que é basicamente um item obrigatório para qualquer integração), é benéfico observar as limitações da API. A maioria das startups pode lidar com os limites básicos de API da maioria dos sistemas de CRM. Como exemplo, o HubSpot oferece 250.000 chamadas de API por período de 24 horas, mesmo em seu nível gratuito. Por outro lado, também limita as chamadas a 10 por segundo (100 se você usar OAuth). A líder de mercado Salesforce permite apenas 100.000 a cada 24 horas, mas oferece a compra de mais.

Na maioria das vezes, você cairá facilmente dentro dessas limitações, mas há uma coisa a considerar: E quanto à sua corrida inicial? No início, você estará enviando muitos contatos e negócios para o seu CRM (e possivelmente várias vezes se houver problemas). Como resultado, você pode atingir o limite diário da API.

Para atenuar isso, você pode testar com um pequeno conjunto de dados e aumentar lentamente o número ao longo da implementação para permanecer dentro do limite da API. Para a migração inicial, planeje-a em vários dias ou em um fim de semana. Como alternativa, entre em contato com o provedor e informe suas intenções. Quando você está na fase de avaliação (e ainda não pagou pelo sistema), eles podem estar dispostos a aumentar um pouco sua permissão de API.

Implementação de CRM

Digamos que todos estejam de acordo. Você escolheu uma ótima ferramenta de CRM e os engenheiros estão confiantes de que ela pode ser integrada com bastante facilidade. Você decidiu definir o escopo para apenas enviar dados de clientes e aceitar pedidos de robôs. Portanto, a sincronização bidirecional não é necessária e as alterações de endereço só serão tratadas em seu próprio sistema de pedidos.

Ainda há algumas práticas recomendadas a serem seguidas durante a fase de implementação.

Experimente tudo em um ambiente de teste

Na maioria dos casos, o sistema CRM só será utilizado após a sua integração estar completa e pronta para uso. Para este caso de uso, pode parecer atraente usar apenas o sistema de produção durante o desenvolvimento. Afinal, não há dados de produção que você possa estar afetando. Depois que o desenvolvimento estiver concluído, você simplesmente removerá todos os dados de teste que criou, executará uma migração inicial e apontará seu sistema de pedidos para esse ambiente.

Existem alguns problemas com essa abordagem:

1. Você está apenas chutando a lata na estrada. Mesmo que seu go-live ocorra sem problemas, mais cedo ou mais tarde, haverá uma solicitação de recurso para alterar parte de sua integração. Dado que a solicitação de recurso é grande o suficiente, você provavelmente precisará de outra fase de teste. Neste ponto, um sistema de teste separado é inevitável; caso contrário, você pode acabar atrapalhando os dados de produção. Então, por que esperar com a configuração até que você seja solicitado a implementar o primeiro recurso?

   

2. Você acaba com uma configuração confusa. É muito provável que seu sistema CRM precise de algum tipo de configuração para atender às necessidades do seu sistema de pedidos. Os nomes de status podem precisar ser ajustados, campos personalizados geralmente precisam ser criados e assim por diante. Como a maioria dos desenvolvedores precisará se acostumar com o sistema CRM, será adicionada uma configuração que não será necessária a longo prazo. Na realidade, essa configuração não utilizada não é removida posteriormente e pode até ficar no seu CRM para sempre. Ao forçar a etapa adicional de replicar a configuração do sistema de teste para a produção, você provavelmente terminará com uma configuração mais simples em seu sistema de produção.
   
   Deve-se notar que isso também pode ser uma desvantagem se você esquecer de copiar a configuração do teste para o sistema de produção e acabará com erros de produção.
   
   Embora existam alguns sistemas de CRM que o ajudarão a comparar e copiar itens de configuração, em geral, será útil anotar suas configurações para não esquecer itens cruciais. A maioria dos CRMs fornece uma API para sua configuração, portanto, é possível automatizar essa etapa.

3. Você corre um risco maior de poluir os dados de produção. Imagine por um segundo dois desenvolvedores trabalhando em uma integração. Você já tem um sistema de preparação do sistema de pedidos de robôs. Essa preparação também está conectada ao seu CRM. Depois que sua integração for enviada, você precisará se lembrar de desconectar todos os três sistemas, caso contrário, poderá acabar criando dados de teste em seu (agora) CRM de produção.

Todos esses problemas podem ser evitados desenvolvendo contra um sistema de teste desde o início. A produção só é apresentada no final, pouco antes de tudo ir ao ar. Dessa forma, você fica com uma configuração limpa, não corre o risco de esquecer de desconectar os sistemas locais e fica alerta ao implementar novos recursos.

Definir ID para correspondência de entidades

Agora, vamos começar a escrever o código de integração real. Vamos pegar o exemplo da sincronização de contatos com um sistema de CRM. Presumivelmente, você precisará criar novos contatos e atualizar os contatos existentes. Para distinguir uma criação de uma atualização, você precisa vincular as duas entidades. Dessa forma, você pode verificar se o contato em seu sistema existe no sistema externo.

Embora pareça atraente usar apenas o endereço de e-mail (afinal, é um identificador comum para um registro de contato), há uma solução mais geral – para cada registro, você sincroniza com uma retenção de sistema externa e um ID em seu próprio banco de dados.

Portanto, altere sua tabela de contatos com uma coluna chamada crm_id ou external_id . Essa abordagem tem algumas vantagens:

• Por ser um ID, ele não mudará (ao contrário de um endereço de e-mail ou número de telefone).
• Você pode ver se precisa criar ou atualizar a entidade sem fazer uma chamada de API primeiro (se o campo de ID externo estiver vazio, você pode assumir que o contato não existe).

Antes de:

Depois de:

Por exemplo, digamos que você seja um desenvolvedor Ruby on Rails trabalhando em um aplicativo que precisa sincronizar clientes novos e existentes com o HubSpot.

Um exemplo de código simplificado poderia ser assim:

 class HubspotSync def sync(customer) hubspot_return = if customer.hubspot_id.present? update(customer, customer.hubspot_id) else create(customer) end customer.update(hubspot_id: hubspot_return['companyId']) end private def create(customer) response = HTTParpty.post("https://api.hubapi.com/companies/v2/companies", map(company)) handle_response(response) end def update(customer, hubspot_id) response = HTTParpty.put("https://api.hubapi.com/companies/v2/companies/#{hubspot_id}", map(company)) handle_response(response) end def handle_response(response) raise RuntimeError, "Unexpected Status code: #{response.code}" if response.code >= 500 JSON.parse(response.body) end def map(company) # mapping code goes here { properties: [ name: 'name', value: company.name ] } end end

Observe como estamos aproveitando para salvar o companyId retornado do HubSpot. Isso não apenas nos ajuda a determinar se queremos atualizar ou criar uma empresa no HubSpot, mas também podemos ver na tabela do banco de dados quais entidades já estão sincronizadas com o HubSpot e quais ainda estão faltando.

Quando se trata de mapear campos, vá de estilo livre

Já vi projetos em que a implementação é precedida pela criação de uma planilha gigante do Excel definindo quais colunas vão para onde no sistema de CRM, com anotações de como os dados devem ser transformados.

Na realidade, existem apenas algumas maneiras de representar contatos e negócios. Então, em vez de gastar muito tempo pensando em como exatamente você deseja mapear, por que não começar com um experimento? Dê ao desenvolvedor algum espaço para descobrir o mapeamento, mas também mantenha contato para que as perguntas possam surgir com antecedência.

Pelo menos para os campos gerais de contato (nome, endereço de e-mail, telefone, endereço), o mapeamento será muito simples e as transformações geralmente são triviais.

Quando se trata de mapeamento de status para negócios, um pouco mais de comunicação é útil (às vezes, o primeiro status é chamado open , às vezes new e às vezes, o modelo de status não corresponde a 100%, então você terá que agrupar os status ). Em vez de encontrar a solução perfeita, observe seus dados atuais e veja como eles se encaixam melhor no modelo de dados do CRM. Afinal, você é uma empresa ágil, certo?

No exemplo acima, você pode ver um método map que converte nosso modelo Rails em um hash regular que é entendido pelo HubSpot. Para este caso de uso específico, o único item sincronizado é o nome. Para uso mais avançado, você provavelmente deseja incluir mais campos, mas para um ótimo resultado, comece com um palpite e comunique-se com o lado comercial com frequência para obter detalhes.

Considerar novas tentativas

Vamos ao nível mais técnico: implementar a sincronização real entre seu sistema e o CRM. É quase certo que a integração ocorrerá em uma conexão HTTP. A maioria dos sistemas fornece uma API HTTP e todas as linguagens de programação permitem que você faça chamadas HTTP com muita facilidade.

Infelizmente, não importa quanto dinheiro você gaste em um sistema de CRM, eventualmente, ele não será acessível. Isso vai acontecer em algum momento e não há nada que você possa fazer sobre isso. Então, você também pode levar isso em consideração quando estiver desenvolvendo sua integração.

O que isso significa na prática é: sempre que você chamar uma API, certifique-se de que sua chamada seja repetida em caso de problema (código de status 500 do outro lado). A implementação de novas tentativas é algo que geralmente é fornecido por bibliotecas de terceiros de sua linguagem de escolha.

Além de apenas tentar novamente, você pode considerar registrar o que exatamente aconteceu. Receber uma notificação sobre um erro que já foi resolvido na primeira tentativa pode ser frustrante.

Portanto, em vez de enviar spam ao seu canal de erro com problemas resolvidos, registre todas as chamadas com o número de tentativas para ter uma ideia de quão confiável é o sistema - um sistema pelo qual você acabou de pagar muito dinheiro.

Se tomarmos a classe que criamos como exemplo e permanecermos no contexto do Ruby on Rails, podemos simplesmente envolver a chamada em um ActiveJob e ter certeza de que a chamada será bem-sucedida eventualmente. O método handle_response gerará um erro no caso de um código de status inesperado e o ActiveJob tentará uma nova tentativa com uma retirada exponencial. Para uma solução mais avançada, você também deve considerar os códigos de status 4xx para que uma nova tentativa seja evitada e uma mensagem de erro seja gerada.

 class HubspotSyncJob < ApplicationJob def perform(customer) HubspotSync.new.sync(customer) end End

Certifique-se de que o sistema é realmente usado

OK, vamos supor que você enviou tudo. Você está super orgulhoso do seu trabalho e o sistema entra em operação. O que agora? Isto é apenas o começo. Porque não importa quantos testes você esteja fazendo, sempre haverá bugs e mudanças solicitadas.

O problema é que você não vai descobrir sobre isso a menos que você realmente use seu sistema. E isso acontece por vários motivos – o departamento de vendas está muito ocupado para começar a usá-lo, a estratégia mudou ou até mesmo novos sistemas já estão sendo avaliados.

Portanto, para evitar possíveis problemas a longo prazo, certifique-se de eliminar todos os obstáculos que impediam o uso do sistema em produção. Comunique-se frequentemente entre as equipes para alinhar os novos requisitos. E se você descobrir que o sistema simplesmente não vai funcionar para você, desligue a integração. Parece duro e pode parecer muito frustrante, mas é menos frustrante do que sempre ter que corrigir problemas de inconsistência de dados e lidar com soluções alternativas.

Empacotando

No final, um projeto de integração é um projeto infernal, e há muitas coisas que podem dar errado. Não é muito popular entre os engenheiros por vários motivos, mas pode ser gratificante ver que uma implementação tem um impacto positivo na produtividade das pessoas sentadas ao seu lado.

Portanto, para engenheiros, tente entender as necessidades de um sistema externo, como um CRM ou um sistema de faturamento, fazendo perguntas concretas como: Como esse produto facilitará sua vida? Já considerou os concorrentes? Por que eles não funcionam?

Para todos os outros envolvidos - chame os engenheiros o mais cedo possível, confie neles quando apontarem linhas vermelhas e não opte por um plano barato quando perceber que a implementação da integração tornará muito mais difícil no longo prazo.