Como adicionar funcionalidades de IA a um SaaS que já construiu

Há uma pressão muito particular que atinge agora todos os fundadores de um SaaS. Um membro do conselho, um cliente, ou simplesmente a voz na sua própria cabeça repete as mesmas três palavras: «precisamos de IA». O produto já funciona. As pessoas pagam por ele. E, ainda assim, parece subitamente faltar-lhe algo que todos os outros parecem ter. Por isso abre um sprint, liga uma API, lança um chatbot num canto, e um mês depois ninguém o usa. O problema nunca foi o modelo. Foi decidir para onde o apontar.

Acrescentar IA a um produto novinho em folha é, curiosamente, a versão fácil. Não tem utilizadores a desiludir, nenhum modelo de dados a respeitar, nenhuma equipa de apoio a informar. Acrescentar IA a um SaaS que já existe — com clientes que pagam, um fluxo de trabalho estabelecido e a reputação de ser fiável — é outro desporto. Cada nova funcionalidade aterra dentro de um sistema em que as pessoas já confiam, e a confiança é precisamente o que uma funcionalidade de IA demasiado ansiosa queima mais depressa.

Ajudámos uma boa quantidade de equipas de software a fazer isto bem, e vimos algumas fazê-lo mal. As equipas que têm sucesso quase nunca partem da tecnologia. Partem da pergunta dolorosa que os seus utilizadores não param de fazer, e só depois questionam se a IA é a resposta honesta mais barata. Este guia é exatamente essa abordagem, posta por escrito: como escolher a funcionalidade, construí-la sem partir o que funciona, e lançá-la de modo que as pessoas a usem mesmo.

Porque falham a maioria das funcionalidades de IA acopladas

Percorra painéis de SaaS suficientes e começa a reconhecer o cemitério. Um botão «✨ Assistente de IA» em que ninguém clica. Um painel de resumo que produz três frases insípidas que qualquer um poderia ter escrito. Um chatbot que responde a perguntas que o produto já respondia melhor com uma caixa de pesquisa normal. Estas funcionalidades não falharam porque a IA era fraca. Falharam porque eram soluções à procura de um problema.

O padrão é quase sempre o mesmo. Alguém sentiu a pressão de lançar algo com forma de IA, por isso agarrou na opção mais genérica e mais visível — uma caixa de conversa — porque é o que mais obviamente se lê como «IA». Mas uma caixa de conversa é uma página em branco, e uma página em branco é uma interface péssima para quem entrou no seu produto para concluir uma tarefa concreta. Não querem conversar. Querem o relatório terminado, o e-mail redigido, os dados limpos.

O segundo modo de falhar é mais subtil e mais caro: lançar uma funcionalidade que acerta na maioria das vezes num fluxo de trabalho em que errar é inaceitável. Uma sugestão com 90 % de exatidão soa ótima numa demonstração. Numa ferramenta com que as pessoas enviam faturas ou marcam turnos de pessoal, um erro confiante em cada dez não se lê como «IA impressionante»: lê-se como «não se pode confiar neste produto». A fasquia dentro de um produto existente é mais alta do que numa página de destino, porque está a gastar uma confiança que já conquistou.

Comece pela pergunta, não pelo modelo

A boa notícia é que um SaaS existente lhe entrega algo que um produto novo nunca tem: provas. Já sabe onde os seus utilizadores se debatem, porque lho dizem todos os dias. A matéria-prima da sua primeira grande funcionalidade de IA está na sua caixa de apoio, nos seus inquéritos de cancelamento e nas partes do seu próprio produto que as pessoas evitam em silêncio.

Por isso, antes de alguém escrever um prompt, vá reunir essas provas. Leia os últimos duzentos tickets de apoio e marque os repetitivos. Pergunte à sua equipa de apoio de que pergunta está farta de responder. Procure nas suas análises o ecrã onde as pessoas abrandam, abandonam ou clicam com raiva. Algalgures aí dentro está uma tarefa enfadonha, com forma de linguagem, feita vezes sem conta, e essa é exatamente a forma de uma tarefa em que a IA é boa.

Repare no que estes pedidos têm em comum: nenhum é «adiciona um chatbot». São concretos, integrados, e terminam num resultado palpável. É essa a diferença entre uma funcionalidade de IA e um brinquedo de IA. Uma funcionalidade desaparece dentro do fluxo de trabalho e poupa um passo. Um brinquedo fica ao lado e pede ao utilizador trabalho extra para dele extrair algum valor.

Uma forma rápida de ordenar as suas candidatas de IA

Assim que tiver uma seleção de três a seis ideias, precisa de uma forma de escolher que não se reduza a quem discute mais alto na reunião de planeamento. Pontuamos cada candidata em três eixos francos, de um a cinco, e o total mais alto costuma ganhar, ou pelo menos inicia a discussão certa.

1. 1
   Valor: o quanto os utilizadores querem isto?

   Pontue 5 se responde a um pedido que ouve constantemente e pouparia tempo de forma visível. Pontue 1 se é um «era bom ter» que alguém na equipa imaginou.
2. 2
   Tolerância: o que acontece quando erra?

   Pontue 5 se um erro é barato e fácil de apanhar — um rascunho que o utilizador revê de qualquer modo. Pontue 1 se uma falha corrompe em silêncio dados, dinheiro ou uma relação com um cliente.
3. 3
   Viabilidade: consegue mesmo alimentá-la?

   Pontue 5 se já possui os dados de que a funcionalidade precisa, numa forma utilizável. Pontue 1 se depende de dados que não tem, a que não consegue aceder ou que são uma confusão.
4. 4
   Multiplique e depois confirme o bom senso

   Multiplique os três. Depois faça a pergunta humana: conseguimos lançar uma primeira versão da vencedora em cerca de um mês? Se não, reduza o âmbito até conseguir.

Esse eixo do meio — a tolerância ao erro — é o que as equipas saltam, e é o que afunda projetos. Uma funcionalidade pode ser de alto valor e totalmente viável e ainda assim ser uma péssima primeira escolha, simplesmente porque o custo de uma resposta confiante mas errada é demasiado alto. A sua primeira funcionalidade de IA deve viver num lugar indulgente, onde a pessoa permanece no circuito e um erro custa uns segundos, não um cliente.

Construa-a dentro do produto, não ao lado

Eis o erro que separa uma funcionalidade de IA adorada de uma tolerada: onde a coloca. O instinto é acrescentar uma superfície de IA nova e separada — um painel, uma página, uma gaveta de conversa — porque parece uma forma limpa de lançar. Mas uma superfície separada pede ao utilizador que abandone o que estava a fazer, vá a outro sítio e regresse. Cada um desses passos perde pessoas.

As funcionalidades que pegam são as que aparecem exatamente onde o trabalho já acontece. O botão de rascunho fica dentro da caixa de resposta, não numa barra lateral. Os dados extraídos fluem direto para os campos do formulário, pré-preenchidos e editáveis. A prioridade sugerida surge como um selo discreto na lista que o utilizador já percorre com o olhar. A IA não se anuncia; apenas torna o clique seguinte manifestamente mais fácil. É nisto que reside todo o ofício.

É também aqui que ter um produto existente é uma dádiva e não uma limitação. Já conhece o momento exato em que o seu utilizador encrava, o campo exato que está prestes a preencher, o e-mail exato que está prestes a escrever. Use esse contexto. O mesmo modelo, alimentado com os dados envolventes que o seu produto já guarda, produz algo dez vezes mais útil do que uma caixa de conversa vazia alguma vez poderia, porque não está a adivinhar o que o utilizador quer. Já o sabe.

Mantenha uma pessoa no circuito — e que se note

Para as suas primeiras funcionalidades de IA, o padrão mais seguro e de maior confiança é quase sempre sugerir, não agir. A IA propõe; a pessoa aprova. Redige o e-mail e a pessoa envia-o. Preenche os campos e a pessoa verifica-os. Assinala a prioridade e a pessoa decide. Isto não é falta de ambição: é assim que constrói o historial que depois lhe permite automatizar mais.

Há uma dimensão de desenho nisto, não apenas técnica. Torne visualmente claro quando algo veio da IA e aguarda a bênção de uma pessoa. Uma etiqueta subtil, um fundo diferente, um «rever e enviar» explícito em vez de uma ação automática silenciosa. Os utilizadores perdoam uma sugestão de IA ligeiramente ao lado muito mais facilmente do que uma ação de IA que aconteceu sem perguntar. A primeira parece uma colega prestável; a segunda dá a impressão de que o software se descontrolou.

• Mostre o resultado da IA como um rascunho ou sugestão que o utilizador pode editar antes de contar.
• Torne-o visualmente distinto, para que ninguém confunda um palpite da máquina com um facto confirmado.
• Ofereça sempre um «não, obrigado» limpo: deixe as pessoas descartar a sugestão e prosseguir à moda antiga.
• Quando a IA estiver insegura, que o diga, e que degrade com elegância em vez de inventar uma resposta confiante.
• Registe o que foi sugerido e o que a pessoa fez com isso: são os seus dados de exatidão para mais tarde.

Este último ponto é, em surdina, o mais valioso. Sempre que um utilizador aceita, edita ou rejeita uma sugestão, está a dizer-lhe o quão boa a sua funcionalidade realmente é, no mundo real, com dados reais, não numa demonstração. Esse ciclo de retorno é a forma como decide se uma funcionalidade está pronta para se tornar mais autónoma, e onde ainda precisa de uma mão humana ao volante.

A realidade de engenharia de que ninguém o avisa

A demonstração são os 20 % fáceis. Deixar uma funcionalidade de IA pronta para produção dentro de um SaaS real são os outros 80 %, e é sobretudo trabalho pouco vistoso que tem pouco a ver com o modelo em si. Vale a pena saber isto à partida, para que um protótipo a funcionar não o engane e o leve a prometer uma data de lançamento que vai falhar.

Canalização de dados e contexto

Um modelo só é tão útil quanto aquilo com que o alimenta. A parte difícil é reunir de forma fiável o contexto certo a partir da sua base de dados existente, formatá-lo, mantê-lo atualizado e respeitar que utilizador tem permissão para ver o quê. Num SaaS multi-inquilino isto importa imenso: uma funcionalidade de IA que por acidente mistura os dados de um cliente na resposta de outro não é um erro, é um incidente. O isolamento entre inquilinos tem de chegar até ao fundo da sua camada de IA.

Custo e latência

Cada chamada de IA custa dinheiro e tempo, e ambos crescem com o uso de um modo que uma subscrição de SaaS de valor fixo não tem. Uma funcionalidade encantadora para dez utilizadores em beta pode tornar-se, em surdina, um problema de margem com dez mil. Tem de pensar cedo em que modelo se adequa a que tarefa — não precisa do modelo mais potente e caro para categorizar um ticket de apoio —, em pôr em cache o trabalho repetido, e no que a funcionalidade faz quando uma resposta demora quatro segundos em vez de um.

A falha e o caminho infeliz

Os utilizadores reais colam lixo, carregam o ficheiro errado, escrevem em três línguas e solicitam a sua funcionalidade no pior momento possível. O fornecedor de IA tem uma falha de serviço. Uma resposta volta malformada. A sua funcionalidade tem de gerir tudo isto sem partir o resto do produto. A regra é simples e rígida: a falha de uma funcionalidade de IA nunca deve arrastar consigo um fluxo de trabalho essencial. Deve falhar em silêncio, recuar para o caminho manual e deixar o utilizador continuar a trabalhar.

Dar-lhe preço: uma funcionalidade, um complemento ou toda a história?

Assim que a funcionalidade funciona, enfrenta uma questão de negócio que faz tropeçar muitas equipas: como cobra por ela? Não há uma única resposta certa, mas há alguns padrões honestos. Pode incorporá-la nos seus planos existentes como uma mais-valia que melhora a retenção e justifica o seu preço. Pode torná-la um complemento pago ou um escalão superior, o que resulta quando a funcionalidade entrega valor óbvio e mensurável. Ou pode medi-la por utilização quando o custo subjacente cresce genuinamente com o consumo.

A armadilha a evitar é dar preço à funcionalidade como se a IA fosse o produto. Para a maioria das empresas de SaaS, a IA não é uma nova linha de produto: é uma nova capacidade que torna o seu produto existente mais valioso. Os clientes não acordam a querer comprar «IA». Querem o seu problema real resolvido um pouco mais facilmente, e pagarão por esse resultado, haja ou não uma máquina por trás. Dê preço ao resultado, não à tecnologia.

Lance uma coisa pequena e depois suba

Toda a estratégia se resume a uma sequência, não a um único lançamento. Escolha a única funcionalidade de alto valor e tolerante ao erro que os seus utilizadores já pedem. Incorpore-a onde o trabalho acontece. Mantenha uma pessoa no circuito. Lance-a a uma fatia de clientes atrás de um flag. Observe como a usam de verdade, corrija o que está áspero, e depois alargue-a. Só quando essa funcionalidade tiver dado provas é que avança para a seguinte, um pouco mais ambiciosa.

Faça isto algumas vezes e acontece algo discretamente poderoso. O seu produto deixa de ser «software com um botão de IA acoplado» e torna-se uma ferramenta genuinamente mais inteligente nas tarefas concretas com que os seus clientes se importam. É uma posição muito mais forte do que a da equipa que lançou uma demonstração de chatbot impressionante na primeira semana e passou os seis meses seguintes a explicar porque ninguém a usa.

Perguntas frequentes