CRMs horizontais morrem da página em branco

Existe um jeito específico de um software flexível fracassar, e ele acontece nos primeiros vinte minutos. Você se cadastra. Dizem que você pode modelar qualquer coisa. Mostram um espaço de trabalho vazio e um botão que diz “criar objeto”. E você fecha a aba, porque veio resolver um problema e recebeu um exercício de modelagem.

Criamos uma plataforma horizontal: um modelo de dados que você define, um único motor de consultas, um único motor de automação. E achamos que entregar isso como um espaço de trabalho vazio teria sido um erro, por motivos que vale deixar claros.

Flexibilidade é um custo no cadastro e uma vantagem no sexto mês

O valor de poder configurar é real, mas chega tarde. No primeiro dia você não sabe de quais campos vai precisar, então escolher é chute. No sexto mês você sabe exatamente o que está errado na sua configuração, e a essa altura a rigidez é o que está machucando.

Então os dois modos de fracasso são imagens espelhadas. Produtos rígidos são agradáveis no cadastro e dolorosos no sexto mês, quando você se pega guardando um imóvel em um campo chamado Nome do negócio. Produtos de página em branco são dolorosos no cadastro e agradáveis no sexto mês, se você sobreviver ao cadastro.

A saída não é escolher um lado. É chegar configurado e continuar configurável.

O que um pacote é de verdade

Os pacotes chegam em breve, começando pelo setor imobiliário. No onboarding vamos perguntar o que a sua empresa vende. Responda “imóveis” e o espaço de trabalho vai instalar um pacote: Imóveis, Anúncios, Compradores, Visitas e Propostas como objetos com campos sensatos, um pipeline de compradores com etapas reais e automações de follow-up já conectadas.

O ponto crucial é que um pacote é dado, não código. Tudo o que ele instala é o mesmo tipo de configuração que você poderia ter criado à mão, o que significa que você pode mudar tudo. Renomeie um objeto, apague uma etapa, refaça uma automação. Nada é um caso especial que resiste à edição por estar compilado lá dentro.

Esse também é o teste mais forte da plataforma por baixo. Se o pacote precisasse de uma única exceção fixa no código, a camada de metadados estaria incompleta. Construir o produto imobiliário como pacote, e não como recursos, é como estamos provando que ela não está.

Um espaço de trabalho em branco deveria ser a saída de emergência, não o padrão.

Como diferenciar um pacote de verdade de uma galeria de modelos

Muitos produtos oferecem modelos por setor. A maioria é um conjunto de campos personalizados e um pipeline com etapas renomeadas. São cosméticos, e em quinze dias você já passou deles. Quatro perguntas separam uma coisa da outra, e você pode fazê-las durante um teste:

1. Ele instala objetos, ou só campos nos objetos que já existem? Um imóvel que na verdade é um negócio com campos extras vai gerar relatórios sem sentido para sempre.
2. As automações são reais e estão rodando, ou são exemplos que você precisa montar? “Aqui está um modelo que você poderia implementar” é um documento, não um produto.
3. Dá para apagar ou renomear tudo o que ele instalou, inclusive os objetos? Se algumas partes resistem à edição, eram código fingindo ser configuração.
4. O fornecedor constrói os próprios produtos por setor desse jeito? Se o produto carro-chefe para um setor é fixo no código e os pacotes são um recurso secundário, os pacotes sempre vão ser de segunda classe.

Por que isso define o roadmap, não só o discurso

Apostar em pacotes força decisões sobre a ordem do trabalho que, de outra forma, seriam fáceis de adiar. O formato de pacote precisa ser projetado cedo (antes de existir o marketplace que vai distribuir os pacotes, e antes de haver qualquer pressão externa para defini-lo) porque o primeiro pacote está sendo construído agora e cada atalho tomado vira uma exceção fixa no código mais tarde.

Isso também muda o custo de expandir. Um setor novo é trabalho de conteúdo: modelar os objetos, definir o pipeline, escrever as automações, lançar. Isso é um especialista no setor e algumas semanas, não um trimestre de engenharia. A conta de entrar em seguros ou recrutamento deixa de depender de a equipe de plataforma ter capacidade.

O que não estamos afirmando

Dois limites honestos, porque aqui seria fácil prometer demais.

Um pacote é um ponto de partida forte, não uma implementação pronta do seu negócio. Se o seu processo é realmente incomum (e, se você é bom no que faz, parte dele é), você vai mudar coisas. O pacote faz você editar algo que funciona em vez de montar do zero.

E os pacotes vão variar em profundidade. O imobiliário vai ser o mais completo, porque é onde está o nosso conhecimento do setor e está sendo construído como prova de conceito. Os outros vão ser sólidos, mas não igualmente testados na prática. Preferimos dizer isso agora a deixar você descobrir na terceira semana.

O princípio geral é a parte que defenderíamos em qualquer lugar: torne os primeiros vinte minutos concretos e mantenha os seis meses seguintes editáveis. Quase todo produto que morre da página em branco acertou a primeira metade e fez a segunda ao contrário.