Você sabe que precisa entregar integrações nativas com outros sistemas para seus clientes para que a experiência do seu produto seja coerente com os processos que eles têm. E se você já chegou a certo porte, deve ter feito muito mais do que algumas integrações para isso.
Aí é que está o problema. Integrações não são realmente o motivo pelo qual sua equipe trabalha, pelo qual sua empresa recebe investimentos e pelo qual seus clientes se inspiram. Logo, é comum que a questão seja sempre despriorizada por outra funcionalidade mais interessante para o mercado.
Será que é essa a melhor atitude a tomar no longo prazo?
Nós acreditamos que essa visão, embora natural, pode levar a desafios incontroláveis no futuro, e que deve ser substituída. Integrações nativas são necessárias para o sucesso de um SaaS. Por isso, devem ser olhadas não como simples demandas para atender os clientes, mas como uma competência estratégica e fundamental.
Como fazer isso? Neste artigo explicamos qual é a melhor abordagem de integração que uma empresa SaaS pode adotar e o que pode fazer para chegar a ela. Acompanhe e, depois de refletir, veja se concorda com nossa visão.
Como as equipes de software lidam com integrações SaaS
É comum que equipes de produto lidem com as integrações do software que criaram como uma outra demanda. Como se fosse uma feature. Integrar, de certa forma, é um feature: permitir que o produto faça alguma coisa que não faz, como trocar informações com outro sistema.
Inicialmente, as integrações são levantadas, avaliadas por valor de negócio e priorizadas, assim como outras funcionalidades. Digamos que 80% dos casos são atendidos por essas integrações nativas. Isso funciona bem, mas ainda sobram os 20%.
Esses 20% vêm de requisições por integrações, e partem de vários os lugares. Pode vir da equipe de vendas, que depende de uma integração para fechar uma negociação com um lead. Pode vir de customer success e suporte, que depende dela para manter um cliente na base. Pode até vir do mercado, no caso da aquisição maciça de uma solução.
São essas integrações que vão entrando no backlog a toque de caixa e sem regra. Feitas muitas vezes de maneira pouco cuidadosa.
Integração não é uma demanda
Embora uma integração possa ser vista como uma demanda por funcionalidade, ela deve ser tratada de um jeito diferente de típicas funcionalidades porque tem especificidades como:
- pode ser mais complexa;
- não faz parte da proposição fundamental do produto; e
- é influenciada pelo produto construído por outra empresa.
Nenhuma funcionalidade em sentido forte de um produto SaaS tem essas características.
Há mais que essas diferenças. Ao tratar as integrações como simples funcionalidades requisitadas, a equipe abre mão de desenvolver uma atitude estratégica em relação à conectividade de sua solução com outros sistemas. Mais radicalmente ainda: ela não se preocupa em pensar o lugar de seu produto dentro de um ecossistema tecnológico maior. O que se perde quando se faz um SaaS isolado?
Outro problema dessa atitude é um processo de integração complicado, caro e pouco escalável, que gera dívida técnica, processos manuais e a um alto custo de ownership.
Integrações nativas como uma competência
Como um fornecedor SaaS, você precisa aceitar que terá a responsabilidade de proporcionar a seus clientes certo nível de conectividade da sua solução com os sistemas deles. Não há sistema isolado. E você sabe que vai retardar o time-to-value do seu produto se não fizer isso. Há poucas opções.
Ao mesmo tempo, integração não é o seu negócio. Então você precisa facilitar as coisas.
A solução é pensar a integração como uma competência que você tem, não como uma demanda que você resolve. Como é isso?
Você não constrói uma integração específica, depois outra e depois outra, você tem a capacidade de criar conectividade em escala. É uma abordagem distinta. Você coloca em primeiro plano o nível do ecossistema, a realidade dos seus clientes.
Na prática isso se traduz em um processo para priorizar, desenhar e entregar integração no longo prazo, ou seja, de maneira estruturada, contínua e, principalmente, simples.
Isso não significa que necessidades de curto prazo não possam ser endereçadas. Ter uma visão de longo prazo sobre integrações SaaS e criar as condições de executá-la significa também gerar as condições para que você tenha flexibilidade suficiente para lidar com demandas não previstas.
Mudando a abordagem de integração de demanda isolada para competência estruturada
Ao deixar de fazer integrações para ter a competência de integrar, você precisa pensar mais em como vai oferecer conectividade e não nas conexões que vai oferecer.
Para isso, precisa considerar:
- Qual é o time de integração? Quais as funções atuais e skills? Como eles trabalham hoje?
- Você tem algum framework para decidir que integrações SaaS vai fazer e quais não vai?
- Você tem algum framework para decidir que integrações SaaS são importantes para os objetivos estratégicos da empresa?
- Você adota práticas de padronização de integrações?
- Você faz atualizações para melhorar a performance das integrações?
- Você monetiza integrações?
Como fazer da integração uma competência
Apenas respondendo às perguntas acima, você vai entender a sua situação atual, mas não vai obter uma competência em integração. Para chegar a esse patamar, você precisa:
- adotar uma plataforma de integração como serviço; e
- desenhar um processo que transforma demandas de integração em fluxos de integração.
Vamos falar mais de cada um deles.
Criando uma plataforma de integração como serviço
Com uma plataforma de integração, você adquire a competência para resolver sempre de maneira padronizada qualquer caso de integração. É o que você alcaça com um iPaaS embedded.
Com uma ferramenta dessa, você cria fluxos de integração SaaS com outros sistemas e oferece, desde a sua solução, para seus clientes em marktplace de integrações. Eles ativam os fluxos que precisam e pagam pelo uso.
As vantagens são várias. Funcionalidades já construídas e necessárias em diferentes cenários de integração poderão ser reutilizadas. Você não vai precisar investir nisso de novo. Se um profissional entender a lógica de um, ele vai entender todos.
Transformando demandas de integração em fluxos
Fazer a demanda “sistema A integrar com sistema B” se transformar em um fluxo de integração no escopo de um processo de negócio, ou seja, em algo que tenha significado em termos de desenvolvimento, não é tão simples quanto parece.
E, em último caso, é o que leva a alterações, a falhas e a integrações tão customizadas que não podem ser reutilizadas.
Ter um processo para definir e desenhar a integração de um produto resolve isso. Os dados que você precisa integrar e as APIs à disposição vão ditar as regras.
Tenha mais que integrações nativas, tenha conectividade nativa
Pense em como o seu produto se insere em um contexto maior de processos, como ele se conecta com outras soluções para que seus clientes atinjam seus objetivos de negócio. Com isso, você pensará em conectividade, não apenas em integrações.
Sair da abordagem de entregar integrações específicas para entregar conectividade sistematicamente é chegar a um framework de integração mais estável e flexível, para você, e para seu cliente a uma plataforma de conectividade.
Você pode acomodar um amplo espectro de possibilidades de integração para seus clientes dentro de seu sistema, sendo um hub ou marktplace de fluxos de integração. Com isso, você será o centro de gravidade em torno do qual um ecossistema de desenvolve, muito mais do que um produto. Quantas empresas SaaS você conhece com esse nível de conectividade?
Se essa é a jornada que você pretende trilhar, nós podemos ajudar você a ter um iPaaS embedded dentro do seu produto. Para trocar uma ideia conosco, preencha o formulário abaixo ou, clicando no botão de WhatsApp, fale com um de nossos consultores.