Esquema CRM ligero para equipos pequeños que se mantiene simple

Qué problema debe resolver este esquema CRM

Un equipo pequeño necesita un CRM que responda preguntas del día a día con rapidez: ¿con quién hablamos?, ¿qué intentamos cerrar?, ¿qué pasó último?, y ¿qué sigue? Ese es el trabajo real de un esquema CRM ligero. Todo lo que no apoye esas preguntas suele ser ruido.

Los equipos pequeños rara vez necesitan jerarquías de cuentas profundas, docenas de objetos personalizados o modelos de scoring complicados. Sí necesitan ownership claro, un historial simple de interacciones y un pipeline que todos entiendan igual.

La “simplicidad” se rompe cuando depende de texto libre y duplicados. Si una persona escribe una etapa del deal como "Negotiation" y otra escribe "negotiating", el reporting se vuelve un juego de adivinanzas. Si las actividades viven en tablas separadas para llamadas, reuniones y notas, terminas con múltiples campos de fecha y sin un valor fiable de “último contacto”.

Este esquema se ciñe a cuatro objetos centrales que cubren la mayoría de los CRM de equipos pequeños sin convertirse en un monstruo:

• Contacts (y opcionalmente Organizations) como las personas con las que hablas
• Deals como las oportunidades que sigues a través de un pipeline
• Activities como un registro unificado para tareas, reuniones, llamadas y notas
• Permissions como reglas prácticas sobre quién puede ver y editar qué

Un reporting limpio significa que puedes ver con fiabilidad los deals por etapa esta semana, la tasa de conversión de etapa a etapa, el tiempo medio en cada etapa, la última actividad por deal y las tareas abiertas de cada representante para hoy. Esos informes deben seguir teniendo sentido cuando el equipo crece de 3 personas a 15.

Si estás construyendo un CRM interno en una herramienta no-code como AppMaster (appmaster.io), este enfoque mantiene la base de datos pequeña a la vez que te da números estables para dashboards y revisiones semanales.

Principios para mantenerlo ligero sin encasillarte

Un esquema CRM ligero funciona cuando responde claramente a una pregunta: ¿dónde vive este hecho? Si la misma “verdad” puede almacenarse en dos sitios, se almacenará, y tus informes derivarán.

Elige un pequeño conjunto de objetos fuente de verdad y haz que todo lo demás apunte a ellos. Para la mayoría de equipos pequeños eso significa Contacts, Organizations (opcional), Deals y Activities. Cuando necesites más detalle, añade una tabla nueva en lugar de meter significado en un único campo de texto que acaba siendo un cajón de trastos.

Algunas reglas mantienen el modelo simple y flexible:

• Un hecho, un hogar: un teléfono pertenece a Contact, un valor pertenece a Deal.
• Prefiere tablas explícitas sobre campos sobrecargados: el historial de etapas no es una cadena separada por comas.
• Mantén los IDs estables y los nombres editables: la gente renombra empresas, no cambia claves primarias.
• Separa “status” de “type”: una tarea puede ser “open” y “call” al mismo tiempo.
• Asume que las importaciones serán desordenadas: espacios en blanco, duplicados y formatos raros son normales.

Planifica datos desordenados desde el día uno añadiendo algunos campos aburridos pero poderosos: created_at, updated_at, y un simple external_id (o import_source + import_key) en tus tablas centrales. Eso te da una forma segura de reimportar sin crear duplicados.

Un ejemplo concreto: importas una hoja de cálculo donde “Acme Inc.” aparece como “ACME” en la mitad de las filas. Si Organization.name es editable y Organization.id es estable, puedes fusionar registros más tarde sin romper los deals y activities existentes.

Contacts y organizations: la estructura más simple que funciona

Un esquema CRM ligero empieza con una decisión: ¿rastrear solo personas, o personas más empresas? Si tu equipo vende a negocios, casi siempre querrás tanto Contact (persona) como Organization (empresa). Si vendes a consumidores, puedes saltarte organizations por completo y mantener todos los registros como contacts.

Para una configuración B2B, mantén la relación simple: cada contact pertenece a una organización primaria (nullable), y una organización puede tener muchos contacts. Esto cubre la mayoría de los flujos de trabajo de equipos pequeños sin empujarte a jerarquías de cuentas complicadas.

Mantén los campos obligatorios al mínimo

La forma más rápida de llenar de datos basura una base es exigir demasiados campos. Una buena base es:

• Contact: id, nombre (o first_name + last_name), created_at
• Organization: id, name, created_at

Todo lo demás (cargo, sitio web, dirección, industria, origen) puede ser opcional. Puedes añadir reglas después, pero es difícil limpiar una base de datos llena de marcadores como "N/A".

Email y teléfono: unicidad sin problema

Es tentador hacer único el email. Funciona bien para B2C, o para un CRM que también actúa como sistema de login. En equipos B2B pequeños, los inbox compartidos (sales@, info@) y los teléfonos reutilizados son comunes. Reglas de unicidad estrictas pueden bloquear registros válidos.

Un compromiso práctico:

• Hacer cumplir la unicidad solo cuando el valor está presente (y solo si encaja en tu caso de uso).
• Permitir duplicados, pero mostrar una advertencia suave en la UI cuando se encuentra una coincidencia.

Si necesitas múltiples emails o teléfonos, evita columnas como email_2 o phone_3. Usa una tabla separada en su lugar (por ejemplo, ContactMethod con type, value, is_primary). El reporting se mantiene limpio y el modelo escala de forma natural.

Ejemplo: tu equipo conoce a Pat, que cambia de trabajo a mitad de trimestre. Con Contact ligado a Organization, puedes mover a Pat a la nueva empresa, mantener los métodos de contacto antiguos para el historial, y tus informes seguirán contando los deals por empresa correctamente.

Deals y pipelines: estructura que siga siendo legible

Un deal es tu unidad de forecasting: una posible compra con un siguiente paso claro. Mantén el registro de deal pequeño y referencia todo lo demás.

Empieza con campos que puedas explicar a cualquier persona del equipo:

• Deal name: una etiqueta corta que tenga sentido en una lista
• Stage: una referencia a una etapa del pipeline (no escrita a mano)
• Value: monto esperado (y elige una moneda para todo el sistema)
• Owner: la persona responsable de moverlo adelante
• Close date: la mejor estimación actual de cuándo se cerrará

Para relaciones, elige un contacto primario en el deal. Eso mantiene el reporting sencillo (por ejemplo, ingresos por contacto, tasa de cierre por segmento). Si a veces necesitas más personas involucradas, añade una tabla deal_contacts para adjuntar contactos extra sin convertir cada deal en una relación many-to-many complicada. La mayoría de equipos pequeños se manejan con 1 contacto primario más participantes opcionales.

Las etapas son donde los CRM suelen ensuciarse. No almacenes la etapa como texto libre. Guarda las stages como datos de referencia para poder renombrar una etapa después sin romper los informes. Una tabla mínima de stages podría incluir:

• stage_id
• pipeline_id
• stage_name
• stage_order
• is_closed (o flags separados para won y lost)

Si tu equipo es pequeño, evita dividir registros en “lead” y “deal” a menos que realmente gestionéis los leads de forma distinta. Una regla simple funciona: cuando tienes una oportunidad real que merece seguimiento, es un deal. Antes de eso, mantenlo como un contact con un estado como “new” o “nurture”. Esto mantiene el pipeline legible y evita que deals medio creados contaminen tus números.

Ejemplo: un equipo de ventas de dos personas registra “Acme Renewal” como un deal propiedad de Sam, etapa “Proposal Sent”, valor 12,000, fecha de cierre el próximo mes. El contacto primario es el comprador y se añade un segundo contacto como aprobador financiero. Los informes siguen siendo consistentes porque los nombres y el orden de las etapas están fijados.

Activities: un modelo para tareas, reuniones y notas

Un equipo pequeño no necesita tablas separadas para llamadas, emails, reuniones y notas. Un modelo Activity suele ser suficiente, y hace el CRM más fácil de usar y de reportar.

Una sola tabla Activity

Usa un registro por cada cosa que ocurrió (o que debe ocurrir). Dale un campo type simple con un conjunto reducido, por ejemplo: call, email, meeting, note, task. Mantén la lista corta para que la gente elija las mismas palabras cada vez.

Para vincular activities sin confusión, usa reglas claras:

• Si se trata de una persona (llamada de seguimiento, email de presentación), vincúlalo a un contact.
• Si se trata de mover ingresos (llamada de precios, reunión de negociación), vincúlalo a un deal.
• Si realmente involucra a ambos, vincula a los dos, pero trata al deal como primario para el reporting del pipeline.

En la práctica, Activity puede tener contact_id (nullable) y deal_id (nullable), más un owner_id opcional (quién es responsable).

Marcas de tiempo útiles para reporting

Mantén tanto due_at como completed_at. Responden a preguntas diferentes. due_at te dice lo que debía ocurrir (planificación y carga de trabajo). completed_at te dice lo que realmente pasó (ejecución y tiempo de ciclo).

Puedes derivar el estado sin un campo separado: si completed_at está relleno, está hecho. Si no, está abierto. Eso evita valores de estado extra que se desincronizan.

Para el texto de la actividad, almacena un único campo buscable como summary o body. Evita sobreestructurar notas al principio. Ejemplo: “Llamada con Maya: confirmó presupuesto, enviar propuesta viernes.” Añade campos especializados después solo cuando sientas verdadero dolor.

Ownership y visibilidad: mantenerlo práctico

Ownership es quien es responsable del siguiente paso. En un esquema CRM ligero, eso suele significar un campo como owner_user_id en un deal (y a menudo en contacts también).

Dos significados de “owner” se confunden con frecuencia: asignación a usuario (una persona específica) y asignación a equipo (un grupo). Si intentas hacer todo como propiedad de equipo desde el día uno, pierdes claridad sobre quién debe actuar hoy.

Un valor por defecto que funciona para la mayoría de equipos pequeños es: todo visible para todos, pero cada deal tiene exactamente un owner. La colaboración sigue siendo fácil y evitas casos límite de permisos cuando alguien debe cubrir a un compañero.

Cuando necesites visibilidad más estricta, mantenla como un único interruptor, no como una matriz compleja. Por ejemplo, añade un campo visibility en deals y activities con valores como public y private, donde private significa “solo el owner (y admins) puede verlo.”

Solo necesitas teams o territories cuando se cumple una de estas condiciones:

• Tienes grupos separados que no deben ver los deals de los demás.
• Informas rendimiento por equipo y la gente se mueve entre equipos.
• Los managers necesitan acceso a su grupo, pero no a toda la compañía.
• Asignas leads a una cola compartida antes de que un rep los reclame.

El ownership afecta al reporting. Si quieres números limpios “por rep”, reporta por el owner_user_id actual en el deal. Si también quieres agregados “por equipo”, añade owner_team_id (o dérivalo del perfil del owner), pero sé explícito sobre cuál es la fuente de la verdad.

Ejemplo: dos reps comparten un inbox. Un nuevo deal empieza sin asignar con owner_user_id = null y owner_team_id = Sales. Cuando Alex lo toma, pon owner_user_id = Alex (mantén team como Sales). Tu pipeline sigue legible y los totales por equipo siguen funcionando.

Diseño de permisos: suficiente control sin complejidad

Empieza con RBAC simple

Los permisos funcionan mejor cuando separas tres ideas: roles (quién), recursos (qué) y acciones (qué pueden hacer). Eso es role-based access control (RBAC), y sigue siendo entendible a medida que tu equipo crece.

Mantén los recursos cerca de tus objetos centrales: Contacts, Organizations, Deals, Activities y quizá Pipelines (si las stages son editables). Define un pequeño conjunto de acciones consistente entre ellos: view, create, edit, delete, export.

Export vale la pena separarlo. Muchos equipos están bien con amplios derechos de visualización, pero quieren limitar extracciones masivas de datos.

Los permisos a nivel de objeto son el lugar más fácil para empezar: “¿Puede este rol editar deals en general?” Para la mayoría de equipos pequeños eso basta durante meses. Las reglas a nivel de registro (por contacto o por deal) son donde aparece la complejidad, así que añádelas solo cuando haya una necesidad real.

Un primer paso práctico es una regla única de ownership: cada registro tiene owner_user_id, y los no-admins solo pueden editar lo que poseen. Si necesitas un nivel más, añade team_id y permite la visualización por equipo manteniendo la edición solo por owner.

Reglas por registro cuando realmente las necesites

Añade permisos por registro para casos como:

• Los reps de ventas no deben ver los deals de los demás
• Soporte puede ver deals pero nunca editarlos
• Managers pueden ver todo y reasignar owners

Mantén las necesidades de auditoría livianas pero reales. Añade created_at, created_by, updated_at y updated_by a cada tabla principal. Si necesitas historial más profundo después, añade una tabla audit_log pequeña con: object type, record id, action, who, when, y un JSON corto de campos cambiados.

Paso a paso: construye el esquema en un fin de semana

Esto es más fácil de acertar cuando lo tratas como un pequeño producto: define los datos primero, pruébalos con entradas reales y luego construye las pantallas.

Día 1: fija el modelo de datos

Empieza con un boceto rápido del ERD en papel o pizarra. Mantén el número de tablas pequeño, pero sé claro sobre los enlaces: contact pertenece opcionalmente a una organization, deal pertenece a un pipeline y tiene un owner, activity puede relacionarse con un contact y/o un deal.

Luego haz lo básico en orden:

• Define objetos y relaciones: contacts, organizations, deals, activities, users/roles, más tablas de lookup pequeñas si las necesitas.
• Define campos obligatorios y valores por defecto: haz created_at, owner_id y nombres clave obligatorios; pon valores por defecto para stage y currency si usas montos.
• Define enums o tablas de referencia: stages de deals y tipos de activities para que el reporting sea consistente.
• Añade índices para filtros comunes: owner_id, stage, due_at, created_at y claves foráneas que filtres a diario.
• Prueba con 20 registros reales: usa nombres reales, fechas y notas desordenadas para ver qué falla.

Día 2: demuestra que reporta bien

Antes de construir formularios, escribe 6-8 preguntas que tu equipo se haga cada semana. Por ejemplo: “Deals en Negotiation por owner”, “Activities vencidas”, “Contactos nuevos este mes”, “Ingresos ganados por mes”. Si una pregunta necesita joins confusos o casos especiales, arregla el esquema ahora.

Un escenario de prueba simple ayuda: añade 3 contacts en una compañía, 2 deals en diferentes etapas y 6 activities entre ellos (una llamada, una reunión, dos tareas y dos notas). Luego comprueba si puedes responder quién lo tiene, qué sigue y qué cambió la semana pasada sin adivinar.

Una vez que los datos estén sólidos, construye la UI y las automatizaciones al final. Irás más rápido y no tendrás que reescribir la historia después para que los informes coincidan con la realidad.

Errores comunes que ensucian el reporting

El reporting desordenado suele empezar con “arreglos rápidos” que parecen más rápidos hoy pero te cuestan cada semana. Un esquema CRM ligero funciona mejor cuando tus datos tienen formas claras y unas pocas reglas que el equipo realmente cumple.

Una trampa común es forzar todo en una sola tabla “customer”. Suena simple hasta que necesitas responder preguntas básicas como “¿Cuántos deals están ligados a una empresa?” o “¿Qué persona cambió de trabajo?” Separa personas (contacts) y empresas (organizations) y conéctalas.

Otro killer de reporting es permitir que las stages de los deals sean texto libre. Si uno escribe “Negotiation” y otro “negotiating”, tu gráfico de pipeline ya está mal. Usa una lista fija de stages (o una tabla de stages) para que cada deal apunte al mismo conjunto.

Evita empaquetar múltiples valores en un campo. Emails o teléfonos separados por comas dificultan búsqueda, deduplicación y exportes. Si realmente necesitas múltiples valores, guárdalos como filas separadas (por ejemplo, un email por registro en una tabla hija).

Las activities se vuelven un lío cuando las fechas no están claras. Un único campo “date” no puede decir si una tarea vencía el viernes pasado o se completó el viernes pasado. Separa esos conceptos para poder informar correctamente sobre trabajo vencido y trabajo completado.

Aquí tienes una lista rápida para “salvar al tú del futuro”:

• Separa contacts y organizations, luego enlázalos
• Usa IDs de stage, no nombres de stage tipeados
• Un valor por campo; usa una tabla hija para múltiples
• Mantén due_at y completed_at como campos separados
• Empieza con roles simples; añade reglas por registro solo después de ver flujos reales

Ejemplo: si tu equipo registra llamadas como notas y luego las marca “hechas” editando el mismo campo, no puedes reportar cuánto tardaron los seguimientos. Con campos separados, ese informe es directo.

Lista de verificación rápida antes de comprometerte con el esquema

Antes de construir pantallas, automatizaciones y dashboards, haz una pasada rápida de reporting y reglas. Un esquema CRM ligero sigue siendo ligero solo si puedes responder preguntas comunes sin hacks o campos ad-hoc.

Recorre estas comprobaciones usando datos de muestra reales (incluso 20 contacts y 10 deals bastan). Si te atas, suele ser por un campo faltante, una picklist inconsistente o una relación demasiado suelta.

Las 5 comprobaciones que detectan la mayoría de los problemas

• Fundamentos del reporting: ¿puedes agrupar deals por stage, por owner y por mes de cierre sin adivinar qué campo de fecha usar?
• Gestión del trabajo: ¿puedes obtener “activities vencidas por owner” en un informe, donde vencido se basa en una única due date y un estado claro de hecho?
• Contacto a organización: ¿puede existir un contact sin organization y poder vincularse después sin romper el historial (emails, notas, participación en deals)?
• Consistencia: ¿vienen stages y tipos de activity de una lista fija, para que no acabes con “Follow up”, “Follow-up” y “Followup” como tres valores distintos?
• Seguridad: ¿puedes restringir quién borra registros o exporta listas, sin bloquear actualizaciones normales como mover un deal a la siguiente etapa?

Si puedes responder “sí” a los cinco, vas bien. Si no, arréglalo ahora mientras el esquema sigue siendo pequeño.

Un consejo práctico: define stages y tipos de activity una vez (como tabla o enum) y reutilízalos en todas partes para que cada pantalla y proceso use los mismos valores.

Un ejemplo realista para equipos pequeños y siguientes pasos

Una agencia de 5 personas es una buena prueba para un esquema CRM ligero. El equipo está ocupado, los leads vienen de todas partes y nadie quiere cuidar datos. Imagina: 1 admin, 2 ventas, 1 ops y 1 miembro solo en lectura (el fundador que solo consulta números).

Llega una nueva solicitud inbound (formulario web o email): “Necesitamos refrescar el sitio, presupuesto $15k, plazo 6 semanas.” La regla es simple: crea una organization (si es una empresa) y un contact (la persona). Luego crea un deal ligado a la organization, con el contact como contacto primario del deal.

Para mantenerlo rápido usan una pequeña checklist de intake:

• Si el dominio o nombre de la compañía coincide con una organization existente, reutilízala.
• Si el email de la persona existe, reutiliza ese contact.
• Siempre crea un deal para intención de compra real.
• Pon el mensaje original en la descripción del deal.
• Añade source (referral, form, outbound) como un campo único.

Las activities evitan llamadas perdidas porque cada siguiente paso se convierte en un ítem fechado y con dueño. Cuando ventas hace una discovery call, registran una activity como meeting y agregan la siguiente de inmediato: una llamada a los dos días. Si ops necesita detalles para dimensionar el trabajo, crean una tarea Activity en el mismo deal para que todo aparezca en un lugar.

Los roles se mantienen prácticos: Admin puede editar todo y gestionar ajustes, Sales puede crear y actualizar contacts, deals y sus activities, Ops puede actualizar campos relacionados con la entrega y activities, y Read-only puede ver pipeline e informes sin cambiar datos.

Si quieres convertir esto en una herramienta interna funcional rápidamente, AppMaster (appmaster.io) es una opción directa: puedes modelar el esquema en su Data Designer (PostgreSQL), añadir reglas de flujo en el editor Business Process, construir una bandeja de leads simple y la página de deal, y luego desplegar en AppMaster Cloud o en tu propia nube cuando estés listo para compartirlo con el equipo.