Casos reales: sistemas que construí y qué enseñaron

Casi todos los casos de estudio del sector son inútiles. El cliente llegó con un problema, entregamos una solución, quedó feliz. No dicen qué se decidió, qué costó, ni qué salió mal. Esta página intenta lo contrario.

Esta página reúne los sistemas que he construido y operado en producción, con lo que funcionó y también con lo que no. Los clientes van anonimizados salvo autorización expresa, pero los detalles técnicos son exactos y las cifras son medidas, no estimadas. Sin eso, un caso no demuestra experiencia, solo la decora.

Por qué están anonimizados y por qué eso no los debilita

Publicar el nombre de un cliente sin su permiso explícito no se hace, y pedirlo cada vez frena la publicación durante semanas. La salida es anonimizar al cliente y no anonimizar nada más.

La regla que sigo: se oculta quién, nunca qué. Un caso que dice «un cliente del sector alimentación» no vale nada. Uno que dice «un negocio de comida preparada, pedidos por WhatsApp, sin app propia, con el despachador trabajando de pie y con las manos ocupadas» es verificable en su lógica aunque no lleve nombre. La especificidad es lo que sostiene la credibilidad cuando falta la marca.

Cuando hay autorización, el nombre aparece. Es el caso de Antojo.

Los casos

Un sistema de pedidos por WhatsApp que opera de verdad

El caso de Antojo, nombrado con autorización, con el cliente final anonimizado. Es el más completo de los tres porque incluye la parte que nadie publica: lo que la producción enseñó, lo que está medido frente a lo que se estimó, el estado real de lo que falta, y cuándo un sistema así no tiene sentido.

Qué demuestra: que administrar y operar son actividades distintas y necesitan pantallas distintas. El equipo que recibía pedidos nunca abrió el CRM, y tenían razón en no abrirlo. Lo que usaban era un tablero ordenado por hora de entrega en vez de por fecha de creación, con sonido y vibración porque quien trabaja con las manos ocupadas no mira una pantalla, y con deshacer en cada acción porque sin deshacer nadie se atreve a ir rápido.

Arquitectura multi-tenant sobre GoHighLevel

Construir un SaaS multi-tenant sobre GoHighLevel, con el cliente anonimizado. Cómo se sostiene un sistema con varios clientes dentro sin que atender al número veintiuno obligue a abrir un editor. Dónde vive la configuración, dónde vive el código, y por qué la bifurcación casi nunca ocurre dentro de la plataforma sino en el middleware.

Qué demuestra: la diferencia económica entre un producto y un desarrollo a medida disfrazado de producto. Con una sola base de código, arreglar un fallo cuesta una vez y se arregla para todos. Con una versión por cliente, cada mejora hay que portarla, probarla y desplegarla de una en una, y el mantenimiento crece con las ventas.

Un bot con contexto real, no un árbol de decisiones

Cómo le dimos memoria a un bot de GoHighLevel, con el cliente anonimizado. Qué cambia cuando el bot consulta el estado real del negocio en vez de recitar un guion, y qué se rompe cuando la fuente de verdad no está donde debería.

Qué demuestra: que la calidad de un bot no depende del modelo sino de a qué datos puede llegar y con qué garantías. Un bot sin acceso al estado real inventa, y un bot con acceso a datos mal gobernados inventa con más confianza.

Lo que tienen en común

Ninguno de los tres empieza por la herramienta. En los tres, el trabajo que produjo el resultado fue decidir la estructura antes de configurar nada: qué es estable y qué es intercambiable, qué dato es autoritativo y dónde vive, qué pasa cuando el sistema se cae y la operación tiene que seguir.

Esa es la parte que no se ve en una demo y es la que decide si el sistema aguanta el segundo año.

Cuándo NO tiene sentido contratar esto

Conviene decirlo antes de que alguien pierda su tiempo y su dinero.

  • Si el proceso no está definido. Un sistema sobre un proceso que nadie sigue automatiza un negocio imaginario. Primero se define, y eso lo tiene que hacer quien opera, no un consultor.
  • Si el problema es de oferta o de demanda. Ninguna arquitectura arregla que el producto no se venda. Se nota rápido y es dinero tirado.
  • Si buscas a alguien que ejecute sin discutir. Mi trabajo incluye decir que algo no se debería construir, y eso a veces molesta.
  • Si necesitas llamadas y reuniones frecuentes. Trabajo por escrito, de forma asíncrona y documentada. Para quien necesita acompañamiento en vivo, hay perfiles mejores.

Cómo trabajo

Tres formas, de menor a mayor compromiso. Todas terminan en un documento, no en una reunión.

ServicioQué entregaDesde
Auditoría de cuentaLectura de lo que existe antes de tocar nada: pipelines y si sus etapas significan algo, workflows y sus ejecuciones facturables, y dónde está ocurriendo la operación de verdad490 USD
ArquitecturaEl mapa por escrito: subcuentas y gobernanza, qué vive en configuración y qué en código, y qué debe vivir fuera de la plataforma1.800 USD
Consultoría continuaAcompañamiento por escrito sobre decisiones de arquitectura mientras se construye2.900 USD

¿Tu cuenta hace lo que crees que hace?

La auditoría empieza leyendo lo que ya existe, no proponiendo lo que falta. Sale un documento con lo que está mal, lo que está bien y en qué orden conviene tocarlo. Desde 490 USD, todo por escrito.

Escríbeme y cuéntame tu caso

Preguntas frecuentes

¿Por qué los casos están anonimizados?

Porque publicar el nombre de un cliente sin permiso explícito no se hace, y pedirlo cada vez retrasa la publicación semanas. Se anonimiza al cliente y no se anonimiza nada más: los detalles técnicos, las decisiones y las cifras se publican tal cual. Cuando hay autorización, como en el caso de Antojo, el nombre aparece.

¿Puedo ver el sistema funcionando antes de contratar?

De los sistemas de clientes no, porque contienen datos reales de sus contactos y sus ventas. Lo que sí se puede es leer el caso completo, que incluye las decisiones de diseño, lo que se midió y lo que falló. Es más útil que una demo, que solo enseña el camino que el vendedor eligió mostrar.

¿Trabajas solo con GoHighLevel?

Es la plataforma que conozco a fondo y sobre la que puedo responder por lo que afirmo. Los principios de arquitectura son independientes de la herramienta, pero la implementación y las cifras concretas de estos casos vienen de operar esa plataforma en producción.

¿Cuánto tarda una auditoría?

Depende del tamaño de la cuenta, y esa es la respuesta honesta. Lo que sí es fijo es el formato: se entrega por escrito, con los hallazgos ordenados por impacto y no por facilidad, y con lo que recomiendo no tocar. La primera respuesta a un correo llega en un día laborable.

¿Qué pasa si la auditoría concluye que no necesito nada?

Se entrega esa conclusión y se cobra igual, porque el trabajo de averiguarlo se hizo. Ha pasado y es un resultado válido: saber que el problema está en otro sitio evita gastar en una reforma que no era el problema.


La idea que ordena todo esto

Un caso de estudio sirve para una sola cosa: enseñar cómo piensa quien lo escribió cuando algo se complica. Por eso estos incluyen lo que falló y lo que todavía falta. Un caso donde todo salió bien no informa de nada, porque en producción nunca sale todo bien, y quien afirme lo contrario está enseñando un folleto en vez de un sistema.

Transparencia: algunos enlaces de este sitio son de afiliado. Si contratas a través de ellos, Marketing Nativo recibe una comisión sin costo adicional para ti; es parte de cómo se financia este contenido. Marketing Nativo es un sitio independiente y no está afiliado oficialmente a HighLevel Inc. GoHighLevel y HighLevel son marcas de sus respectivos propietarios.