Cómo crear un CRM sin programar en 2026: guía práctica

Un CRM sin programar se construye describiendo tu proceso, no eligiendo bloques: nombras las entidades, los campos, las etapas y los roles, y el constructor genera una aplicación con listas, fichas y acceso. En Zugo una versión sencilla llega en alrededor de un minuto y una herramienta de varias pantallas, en unos minutos.

La diferencia entre una herramienta que se usa y una maqueta bonita se decide en la fase de descripción, no en la de construcción. Esta guía va sobre cómo descomponer tu proceso, qué hacer con la hoja de cálculo que ya tienes y dónde este enfoque topa con su techo.

¿Qué CRM quieres sustituir exactamente?

Conviene contestar esto antes del primer prompt, porque bajo la palabra CRM viven dos cosas muy distintas.

La primera es la suite grande: telefonía, secuencias de correo, inventario, informes y contabilidad. Se implantan durante meses y el proceso de la empresa se adapta a ellas. Un constructor con IA no las sustituye y no lo pretende.

La segunda es una herramienta interna para un proceso concreto de una empresa concreta: una base de clientes con su historial, un registro de solicitudes con tus etapas, un control de obras o contratos, un panel para un colaborador. Aquí la suite suele estorbar, porque la mitad de los campos sobran, falta el que necesitas y el embudo no se parece al tuyo.

La segunda es justo donde este método funciona mejor. Si tu caso es el primero, el mejor consejo honesto es no empezar por aquí.

¿Cómo se descompone tu proceso para poder describirlo?

Es el único paso que no se delega. Coge un folio, responde a cuatro preguntas y luego copia las respuestas al prompt.

Qué objetos manejas. Cliente, oportunidad, solicitud, obra, contrato, tarea. Normalmente son dos o tres, no diez. Si te salen más de cinco, probablemente algunos son campos de otro.

Qué campos tiene cada uno. Solo los que se rellenan de verdad. Un campo puesto por si acaso está vacío en todas las fichas al mes siguiente y estorba para leer.

Por qué etapas pasa un registro. Con tus palabras, no con las de un manual. Si en tu oficina se dice "visita hecha", escribe eso: la herramienta tiene que hablar el idioma del equipo.

Quién ve qué. El comercial ve lo suyo, la dirección lo ve todo y un resumen. Se describe con una frase y se convierte en pantallas distintas.

¿Cómo es un prompt que funciona?

Coge la tabla anterior y conviértela en un párrafo seguido. Este ejemplo se usa cambiando el contenido por el tuyo:

CRM interno para el equipo comercial de [sector].
Entidades: cliente (nombre, teléfono, dirección, origen),
oportunidad (cliente, importe, etapa, fecha del próximo contacto,
comentarios).
Etapas: [las tuyas, separadas por comas].
Pantalla principal: embudo por etapas con número e importe total.
El comercial entra con su correo, ve sus oportunidades y filtra
por etapa y por fecha del próximo contacto.
La dirección ve todas y un resumen por comercial.
En la ficha se cambia de etapa, se añade comentario con fecha
y se planifica el siguiente contacto.

En proyectos de varias pantallas conviene revisar el plan antes de generar: Zugo muestra qué va a construir y ese plan se corrige antes de la construcción. En una herramienta interna ese paso ahorra más tiempo que ningún otro, porque rehacer un plan sale más barato que rehacer una construcción.

Después vienen las ediciones normales por chat: "añade un filtro por periodo al embudo", "resalta la oportunidad si la fecha de próximo contacto ya pasó", "exporta la lista a CSV con un botón". Cada edición cuesta 3 créditos.

¿Qué se hace con los datos que ya están en una hoja de cálculo?

Casi siempre hay historia previa: un archivo con clientes de los últimos dos años. El orden importa más que la herramienta.

Primero limpia la hoja a mano, antes de construir. Un cliente por fila, columnas homogéneas, un solo formato de teléfono y de fecha. Arreglar datos sucios dentro de la aplicación sale más caro que ordenarlos antes en la hoja.

Después decide dónde van a vivir. Zugo Cloud es la base integrada: no hay que configurar nada y sirve para un prototipo o una herramienta de pocas personas. El conector de Supabase te da tu propio Postgres, con las tablas visibles en su panel, consultas SQL y carga directa del histórico, y es la elección correcta en cuanto entren datos reales de clientes.

Regla práctica: prototipo en Zugo Cloud, uso serio en Supabase. Migrar entre los dos no es una catástrofe, pero es más fácil con la base vacía que llena. El planteamiento general está en cómo crear una app sin programar.

¿Cómo se separan los permisos del equipo?

Los permisos se describen con palabras y se comprueban con las manos. Aquí es importante no mezclar dos capas distintas.

La primera capa son los roles dentro de la aplicación construida: qué registros ve cada empleado y qué puede modificar. Los defines tú con una frase del tipo "el comercial ve solo sus oportunidades, la dirección las ve todas".

La segunda es el acceso al proyecto dentro del constructor: quién puede editar la propia herramienta. Son cosas distintas, y confundirlas acaba con un comercial teniendo permiso para modificar la aplicación en lugar de para ver sus clientes.

Una advertencia que conviene tomarse en serio: cualquier aplicación con datos de clientes merece una revisión propia de quién puede leer qué, la haya escrito una persona o una IA. Revisa esas reglas antes de meter datos personales. En el panel de Supabase las políticas se ven y se corrigen directamente, y eso por sí solo es un argumento para usar el conector cuando lo que está en juego crece.

¿Cuánto cuesta construirlo y mantenerlo?

El plan gratuito da 5 créditos para probar. Pro cuesta $25 al mes con 200 créditos, que dan para unas 33 construcciones rápidas o 16 plataformas completas, e incluye dominio propio. Business cuesta $99 al mes.

Una herramienta de una sola pantalla es una construcción normal de 6 créditos. Un CRM con varias secciones se factura como plataforma: 12 créditos por las tres primeras páginas y 3 créditos por cada página adicional. Cada edición cuesta 3 créditos y el modo Hi-Fi cuesta el doble: 12 la construcción y 6 la edición.

Antes de entregarse, cada construcción se arranca en un sandbox y tiene que cargar. La que no abre se reporta como fallida en lugar de llegarte como pantalla en blanco. Baja el riesgo, no lo elimina: crea una oportunidad de prueba, muévela por todas las etapas y entra con un usuario del rol más bajo antes de dar acceso al equipo.

¿Cómo saber si la herramienta ha calado en el equipo?

Construir el CRM es más fácil que conseguir que se use. Un equipo que sigue llevando las oportunidades por mensajería y las vuelca el viernes por la tarde es un equipo que no ha adoptado la herramienta, por bonita que sea.

Tres señales lo dicen en dos semanas. La primera: si los datos se meten en el momento o a posteriori. La segunda: si alguien más que tú mira la pantalla principal. La tercera: si el equipo pide cambios. La ausencia de peticiones no es aprobación, es indiferencia: nadie pide mejoras de algo que no usa.

Se corrige quitando, no insistiendo. Elimina los campos que nadie rellena y las pantallas donde nadie entra. La frase para el chat es "quita de la ficha estos campos y deja solo estos". Cuesta 3 créditos y suele servir más que añadir una función nueva.

¿Dónde está el límite?

Tres casos donde este enfoque no es la mejor opción.

Lógica de servidor compleja. Aprobaciones en cascada, cálculos con métodos propietarios, intercambio con un ERP por protocolo interno. La interfaz la construye el constructor y el motor lo diseña un programador: Zugo no sustituye a un equipo de desarrollo en un producto así.

Sistemas sectoriales con exigencias regulatorias. Historias clínicas, nóminas con presentación oficial, todo lo que tenga formato obligatorio y organismo supervisor. Ahí se compra una solución especializada.

Volumen y carga altos. Una herramienta para decenas de personas es un escenario razonable. Un sistema con cientos de usuarios simultáneos y analítica sobre millones de registros se diseña, no se describe.

Entre esos extremos funciona un esquema simple: construir la herramienta, usarla de verdad durante un mes y, cuando quede claro que el proceso encaja, llevarse el código por la exportación a GitHub y seguir con un programador. Una primera versión en una tarde suele valer más que un pliego perfecto en un mes. Si tu negocio vive de solicitudes que llegan por la web, mira antes cómo crear una web de empresa de limpieza o cómo crear una web de consultoría. Empieza describiendo un proceso tuyo en zugo.dev.