Skip to content

RC-CRM: Modelo de Datos

CampoDetalle
EstadoBorrador
Documento padreRC-crm-tickets.md
Reuniones fuente2026-03-09, 2026-03-10-p2
ClasificaciónProyecto Customware para Reccius (no es módulo de Tu Magistral)

1. Implementación en Twenty CRM

Twenty CRM utiliza un sistema de objetos personalizables (Custom Objects) que se almacenan en PostgreSQL. Esto permite modelar las entidades del CRM de Reccius aprovechando tanto los objetos nativos de Twenty como objetos custom adicionales.

Mapeo de entidades a objetos de Twenty

Entidad del modeloObjeto en TwentyTipoDetalle
ContactoPeople (nativo) + campos customNativoTwenty incluye People con nombre, email, teléfono, empresa. Se agregan campos custom: RUT, tipo (paciente/médico/farmacia/institución/proveedor), notas
OrganizaciónCompanies (nativo) + campos customNativoTwenty incluye Companies con nombre, dirección, email. Se agregan campos custom: RUT, tipo (farmacia/clínica/hospital/convenio)
TicketCustom Object "Ticket"CustomObjeto personalizado con campos: número, asunto, descripción, estado, prioridad, canal de origen, timestamps
InteracciónActivities (nativo) + campos customNativoTwenty incluye Activities con timeline. Se agregan campos custom: tipo de canal, dirección (entrante/saliente/interna), adjuntos
PipelinePipeline (nativo)NativoTwenty incluye pipeline views configurables con etapas y kanban
EtapaTicketGestionado por el pipeline nativo de TwentyNativoTwenty registra automáticamente el movimiento entre etapas del pipeline
UsuarioWorkspace Members (nativo)NativoTwenty gestiona usuarios del workspace con roles y permisos
AlertaCustom Object "Alerta" o workflowsCustomSe puede implementar como objeto custom o mediante workflows automáticos de Twenty

Consideraciones de compatibilidad

  • Twenty usa PostgreSQL como base de datos, lo cual es compatible con Supabase si en el futuro se necesita integrar con Tu Magistral.
  • La API GraphQL de Twenty permite acceder y manipular todos los objetos (nativos y custom) de forma programática.
  • Los Custom Objects en Twenty se crean desde la interfaz de administración o vía API, sin necesidad de modificar el código fuente.

2. Diagrama entidad-relación

Nota: El siguiente diagrama ER representa el modelo lógico de datos. En Twenty CRM, este modelo se implementa mediante una combinación de objetos nativos (People, Companies, Activities, Pipeline) y Custom Objects (Ticket, Alerta). Las relaciones se configuran como campos de relación (Relation fields) en Twenty.


3. Descripción de entidades

Contacto

Representa a cualquier persona o entidad con la que Reccius tiene comunicación. Un contacto puede ser un paciente individual, un médico prescriptor, una farmacia, una institución de salud o un proveedor.

En Twenty: se implementa como People (objeto nativo) con campos personalizados adicionales.

CampoTipoObligatorioDescripción
idUUIDIdentificador único
nombreStringNombre completo o razón social
rutStringNoRUT chileno (único si se ingresa)
emailStringNoEmail principal de contacto
teléfonoStringNoTeléfono principal (puede ser WhatsApp)
tipoEnumpaciente, médico, farmacia, institución, proveedor
organizacion_idUUID (FK)NoOrganización a la que pertenece (si aplica)
notasTextNoNotas generales sobre el contacto
created_atTimestampFecha de creación del registro
updated_atTimestampFecha de última modificación

Nota: Un contacto puede existir sin organización (ej: paciente individual) o estar asociado a una (ej: médico de una clínica).

Organización

Agrupa contactos bajo una entidad común. Ejemplos: Farmacia Salco (convenio), Clínica Santa Gemita (convenio), Hospital X.

En Twenty: se implementa como Companies (objeto nativo) con campos personalizados adicionales.

CampoTipoObligatorioDescripción
idUUIDIdentificador único
nombreStringNombre de la organización
rutStringNoRUT de la organización (único si se ingresa)
tipoEnumfarmacia, clínica, hospital, convenio
direcciónStringNoDirección física
teléfonoStringNoTeléfono principal
emailStringNoEmail institucional
notasTextNoNotas sobre la organización
created_atTimestampFecha de creación
updated_atTimestampFecha de última modificación

Ticket

Unidad fundamental de trabajo del CRM. Cada solicitud, consulta, reclamo o gestión se representa como un ticket. Se origina desde cualquier canal y tiene un ciclo de vida definido.

En Twenty: se implementa como Custom Object "Ticket" con todos los campos definidos a continuación.

CampoTipoObligatorioDescripción
idUUIDIdentificador único
númeroStringNúmero legible de ticket (ej: TK-20260325-001), único
asuntoStringTítulo breve de la solicitud
descripciónTextNoDescripción detallada
estadoEnumnuevo, asignado, en_gestion, esperando_respuesta, escalado, resuelto, cerrado
prioridadEnumbaja, media, alta, urgente
canal_origenEnumemail, whatsapp, teléfono, web, presencial
contacto_idUUID (FK)Contacto que originó la solicitud
organizacion_idUUID (FK)NoOrganización asociada (si aplica)
asignado_aUUID (FK)NoUsuario responsable del ticket
pipeline_idUUID (FK)NoPipeline al que pertenece (si aplica)
created_atTimestampFecha de creación del ticket
updated_atTimestampFecha de última modificación
primera_respuesta_atTimestampNoFecha de la primera respuesta al contacto
resuelto_atTimestampNoFecha en que se marcó como resuelto
cerrado_atTimestampNoFecha de cierre definitivo

Nota sobre número de ticket: El formato sugerido es TK-YYYYMMDD-NNN (ej: TK-20260325-001). Permite identificación rápida y comunicación con el contacto ("su ticket es el TK-20260325-001").

Interacción

Cada comunicación registrada en un ticket. Puede ser un email enviado o recibido, un mensaje WhatsApp, una llamada telefónica, una nota interna o una visita presencial.

En Twenty: se implementa mediante Activities (objeto nativo) con campos personalizados para canal, dirección y adjuntos.

CampoTipoObligatorioDescripción
idUUIDIdentificador único
ticket_idUUID (FK)Ticket al que pertenece
tipoEnumemail, whatsapp, teléfono, nota_interna, presencial
contenidoTextTexto de la interacción
direcciónEnumentrante (del contacto), saliente (de Reccius), interna (nota entre equipo)
autor_idUUID (FK)Usuario que registró o envió la interacción
adjuntosJSONNoLista de archivos adjuntos (fotos de receta, documentos, etc.)
created_atTimestampFecha y hora de la interacción

Nota sobre adjuntos: El campo JSON contiene un arreglo de objetos con: nombre_archivo, url_almacenamiento, tipo_mime, tamano_bytes.

Pipeline

Flujo de trabajo configurable que define las etapas por las que pasa un ticket según su tipo. Permite personalizar el proceso para cotizaciones, reclamos, seguimientos, etc.

En Twenty: se implementa mediante Pipeline (funcionalidad nativa) con vistas kanban configurables.

CampoTipoObligatorioDescripción
idUUIDIdentificador único
nombreStringNombre del pipeline (ej: "Cotización", "Reclamo")
etapasJSONArreglo ordenado de etapas con nombre y configuración
activoBooleanSi el pipeline está disponible para uso
created_atTimestampFecha de creación
updated_atTimestampFecha de última modificación

Ejemplo del campo etapas (JSON):

json
[
  {"nombre": "Recibida", "orden": 1, "color": "#3B82F6"},
  {"nombre": "En análisis", "orden": 2, "color": "#F59E0B"},
  {"nombre": "Cotizada", "orden": 3, "color": "#8B5CF6"},
  {"nombre": "Esperando confirmación", "orden": 4, "color": "#EF4444"},
  {"nombre": "Confirmada", "orden": 5, "color": "#10B981"},
  {"nombre": "Cerrada", "orden": 6, "color": "#6B7280"}
]

EtapaTicket

Registro histórico de las etapas por las que ha pasado un ticket dentro de un pipeline. Permite calcular tiempo en cada etapa e identificar cuellos de botella.

En Twenty: gestionado automáticamente por el pipeline nativo de Twenty.

CampoTipoObligatorioDescripción
idUUIDIdentificador único
ticket_idUUID (FK)Ticket que está en el pipeline
pipeline_idUUID (FK)Pipeline al que pertenece
etapa_nombreStringNombre de la etapa (coincide con Pipeline.etapas)
entered_atTimestampFecha y hora en que el ticket entró a esta etapa
exited_atTimestampNoFecha y hora en que el ticket salió de esta etapa (null si es la etapa actual)

Usuario

Miembro del equipo de Reccius que opera el CRM. Cada usuario tiene un rol que define sus permisos.

En Twenty: se implementa mediante Workspace Members (funcionalidad nativa) con roles configurables.

CampoTipoObligatorioDescripción
idUUIDIdentificador único
nombreStringNombre completo
emailStringEmail corporativo (único)
rolEnumejecutiva, dirección, gerencia, administrador
activoBooleanSi el usuario está activo en el sistema
created_atTimestampFecha de creación
updated_atTimestampFecha de última modificación

Roles y permisos:

RolCrear ticketsGestionar ticketsEscalarVer métricasConfigurar pipelinesAdministrar usuarios
ejecutivaSolo asignadosNoNoNo
direcciónTodosParcialNoNo
gerenciaTodosTodos
administradorTodosTodos

Alerta

Notificación programada o generada automáticamente por el sistema para informar a un usuario sobre una situación que requiere atención.

En Twenty: se puede implementar como Custom Object "Alerta" o mediante workflows automáticos de Twenty con triggers.

CampoTipoObligatorioDescripción
idUUIDIdentificador único
ticket_idUUID (FK)Ticket relacionado
usuario_idUUID (FK)Usuario destinatario de la alerta
tipoEnuminactividad, sla, escalamiento, reasignación, mención, recordatorio
mensajeStringTexto descriptivo de la alerta
programada_paraTimestampFecha y hora en que debe dispararse la alerta
enviadaBooleanSi la alerta ya fue enviada
enviada_atTimestampNoFecha y hora en que se envió (null si no enviada)
created_atTimestampFecha de creación

4. Índices recomendados

Nota: Twenty CRM gestiona los índices de sus objetos nativos automáticamente. Los índices listados a continuación aplican para los Custom Objects y como referencia para optimización si se accede directamente a PostgreSQL.

TablaColumnasTipoPropósito
ContactorutÚnicoBúsqueda rápida por RUT
ContactoemailÍndiceBúsqueda rápida por email
ContactoteléfonoÍndiceBúsqueda por teléfono (WhatsApp)
ContactonombreGINBúsqueda de texto parcial por nombre
Contactoorganizacion_idÍndiceListar contactos de una organización
TicketnúmeroÚnicoBúsqueda por número de ticket
TicketestadoÍndiceFiltrar tickets por estado
Ticketasignado_aÍndiceBandeja de tickets por ejecutiva
Ticketcontacto_idÍndiceHistorial de tickets por contacto
Ticketorganizacion_idÍndiceTickets por organización
Ticketpipeline_id, estadoCompuestoVista de pipeline con filtro de estado
Ticketcreated_atÍndiceOrdenamiento cronológico
Interacciónticket_id, created_atCompuestoTimeline de interacciones por ticket
EtapaTicketticket_id, pipeline_idCompuestoHistorial de etapas por ticket
Alertausuario_id, enviadaCompuestoAlertas pendientes por usuario
Alertaprogramada_para, enviadaCompuestoAlertas pendientes de envío (cron job)

5. Volumetría estimada

Basado en el diagnóstico de Reccius (reunión 2026-03-09 y 2026-03-10-p2):

EntidadVolumen inicial estimadoCrecimiento mensual estimado
Contacto2.000 - 5.000100 - 200
Organización50 - 1005 - 10
Ticket0 (nuevo)500 - 1.000
Interacción0 (nuevo)2.000 - 5.000
Pipeline4 - 5Raro (configuración)
Usuario6 - 8Raro
Alerta0 (nuevo)200 - 500

Nota: Reccius procesa aproximadamente 40.000 recetas al año (mencionado por Andro en reunión 2026-03-10-p2), lo que equivale a ~3.300 recetas mensuales. No todas generarán ticket en el CRM, pero da una referencia de volumen operativo. Este volumen es perfectamente manejable por una instancia self-hosted de Twenty en un VPS modesto.


6. Consideraciones técnicas

Almacenamiento de adjuntos

Los archivos adjuntos (fotos de receta, documentos) no se almacenan en la base de datos. Se utiliza almacenamiento de objetos (ej: S3, Supabase Storage) y en la tabla Interacción se guarda solo la referencia (URL y metadatos). Twenty soporta almacenamiento de archivos de forma nativa.

Soft delete

Los contactos, organizaciones y tickets no se eliminan físicamente. Se marcan como inactivos o archivados para mantener la trazabilidad histórica. Twenty maneja soft delete de forma nativa en sus objetos.

Auditoría

Toda modificación a un ticket (cambio de estado, reasignación, edición) genera un registro de auditoría con: quién hizo el cambio, qué cambió, cuándo, valor anterior y valor nuevo. Twenty registra automáticamente las actividades en el timeline de cada objeto.

Zona horaria

Todos los timestamps se almacenan en UTC. La presentación en la interfaz se convierte a la zona horaria de Chile (America/Santiago). Twenty maneja zonas horarias de forma nativa.

Compatibilidad con PostgreSQL

Twenty utiliza PostgreSQL como base de datos. Si en el futuro se necesita integrar con Supabase (para Tu Magistral u otros servicios), la compatibilidad de base de datos facilita la conexión directa o replicación.


Historial de cambios

FechaReuniónCambio
2026-03-25--Creación del modelo de datos basado en requerimientos RC-CRM
2026-03-25--Actualización: se agrega sección de implementación en Twenty CRM con mapeo de entidades a objetos nativos y custom; se agregan notas de Twenty en cada entidad; se corrigen tildes