Los CRM horizontales mueren por la hoja en blanco

Hay una forma concreta en que el software flexible fracasa, y ocurre en los primeros veinte minutos. Te registras. Te dicen que puedes modelar cualquier cosa. Te muestran un espacio de trabajo vacío y un botón que dice “crear objeto”. Y cierras la pestaña, porque viniste a resolver un problema y te entregaron un ejercicio de modelado.

Creamos una plataforma horizontal: un modelo de datos que defines tú, un solo motor de consultas, un solo motor de automatización. Y creemos que entregarla como un espacio de trabajo vacío habría sido un error, por razones que vale la pena explicar.

La flexibilidad es un costo al registrarte y una ventaja al sexto mes

El valor de poder configurar es real, pero llega tarde. El primer día no sabes qué campos vas a necesitar, así que elegirlos es adivinar. Al sexto mes sabes exactamente qué está mal en tu configuración, y para entonces la rigidez es lo que te hace daño.

Así que los dos fracasos son imágenes en espejo. Los productos rígidos son agradables al registrarte y dolorosos al sexto mes, cuando te descubres guardando una propiedad en un campo llamado Nombre de la oportunidad. Los productos de hoja en blanco son dolorosos al registrarte y agradables al sexto mes, si sobrevives al registro.

La salida no es elegir un bando. Es llegar ya configurado y seguir siendo configurable.

Qué es realmente un paquete

Los paquetes llegan pronto, empezando por bienes raíces. Al empezar, te preguntaremos qué vende tu negocio. Responde “bienes raíces” y el espacio de trabajo instalará un paquete: Propiedades, Publicaciones, Compradores, Visitas y Ofertas como objetos con campos sensatos, un pipeline de compradores con etapas reales y automatizaciones de seguimiento ya conectadas.

Lo fundamental es que un paquete son datos, no código. Todo lo que instala es el mismo tipo de configuración que podrías haber creado a mano, lo que significa que puedes cambiarlo todo. Cambia el nombre de un objeto, borra una etapa, reconecta una automatización. Nada es un caso especial que se resista a la edición por estar compilado dentro.

Esa es también la prueba más dura para la plataforma que está debajo. Si el paquete necesitara una sola excepción programada a mano, la capa de metadatos estaría incompleta. Construir el producto de bienes raíces como un paquete y no como funciones es la forma en que demostramos que no lo está.

Un espacio de trabajo en blanco debería ser la salida de emergencia, no el punto de partida.

Cómo distinguir un paquete real de una galería de plantillas

Muchos productos ofrecen plantillas por sector. La mayoría son un conjunto de campos personalizados y un pipeline con etapas renombradas. Son cosméticas, y se te quedan chicas en dos semanas. Cuatro preguntas separan una cosa de la otra, y puedes hacerlas durante una prueba:

1. ¿Instala objetos, o solo campos en los que ya existen? Una propiedad que en realidad es una oportunidad con campos extra va a producir informes sin sentido para siempre.
2. ¿Las automatizaciones son reales y están funcionando, o son ejemplos que tienes que construir? “Aquí tienes una plantilla que podrías implementar” es un documento, no un producto.
3. ¿Puedes borrar o renombrar todo lo que instaló, incluidos los objetos? Si algunas partes se resisten a la edición, eran código haciéndose pasar por configuración.
4. ¿El proveedor construye así sus propios productos por sector? Si su producto estrella para un sector está programado a mano y los paquetes son una función secundaria, los paquetes siempre serán de segunda.

Por qué esto define el roadmap, no solo el discurso

Apostar por los paquetes obliga a tomar decisiones sobre el orden del trabajo que de otro modo es fácil aplazar. El formato de paquete tiene que diseñarse pronto (antes de que exista el marketplace que distribuirá los paquetes, y antes de que haya presión externa para definirlo) porque el primer paquete se está construyendo ahora y cada atajo que se tome se convierte más adelante en una excepción programada a mano.

También cambia lo que cuesta crecer. Un sector nuevo es trabajo de contenido: modelar los objetos, definir el pipeline, escribir las automatizaciones, publicarlo. Eso es un experto del sector y unas pocas semanas, no un trimestre de ingeniería. Que entrar en seguros o en reclutamiento sea rentable deja de depender de si el equipo de plataforma tiene capacidad.

Lo que no estamos afirmando

Dos límites honestos, porque aquí sería fácil prometer de más.

Un paquete es un punto de partida sólido, no una implementación terminada de tu negocio. Si tu proceso es realmente poco común (y si eres bueno en lo que haces, una parte lo es), vas a cambiar cosas. El paquete hace que edites algo que funciona en lugar de armarlo desde cero.

Y los paquetes van a variar en profundidad. El de bienes raíces será el más completo, porque ahí está nuestro conocimiento del sector y se está construyendo como caso de prueba. Los demás serán sólidos, pero no igual de probados en el campo. Preferimos decirlo ahora antes que dejar que lo descubras en la tercera semana.

El principio general es la parte que defenderíamos en cualquier lugar: haz que los primeros veinte minutos sean concretos y que los seis meses siguientes se puedan editar. Casi todos los productos que mueren por la hoja en blanco acertaron en la primera mitad y hicieron la segunda al revés.