Twenty figura en Interoperable Europe como CRM open source autoalojable para gestionar contactos, organizaciones, oportunidades, tareas y registros configurables.
Qué ofrece
La solución incluye vistas configurables, flujos, permisos, paneles, integraciones de correo y calendario, APIs REST y GraphQL y webhooks.
Por qué puede interesar al sector público
Organismos y equipos de servicio pueden utilizar un CRM para gestionar stakeholders, proveedores, partners o relaciones con usuarios sin depender necesariamente de un SaaS externo.
Soberanía y datos
El autoalojamiento permite mantener la infraestructura bajo control de la organización, aunque eso traslada responsabilidad sobre seguridad, copias y actualizaciones.
Interoperabilidad
REST, GraphQL, webhooks e importación/exportación en formatos comunes facilitan integraciones con sistemas corporativos.
Licencias
La mayor parte del repositorio utiliza AGPLv3 con permisos adicionales y algunos paquetes MIT, por lo que las condiciones deben revisarse antes de una implantación.
Qué debe evaluar una Administración
Capacidad de hosting, soporte, seguridad, evolución del proyecto, portabilidad y adaptación al modelo de datos propio.
Fuentes
Fuente: Interoperable Europe.
Conclusión
Twenty amplía el catálogo de alternativas open source para CRM, pero su valor dependerá del modelo de operación y soporte que acompañe al autoalojamiento.
Un CRM público no es solo una herramienta comercial
En el sector público, un CRM puede servir para gestionar relaciones con empresas, asociaciones, proveedores, participantes de programas, centros educativos o entidades colaboradoras. El concepto debe adaptarse al servicio y evitar copiar sin más procesos comerciales privados.
Antes de implantarlo conviene definir qué relación se quiere gestionar, qué datos son necesarios y qué sistemas ya contienen información equivalente.
La arquitectura debería evitar que Twenty se convierta en otra base de datos paralela. Siempre que exista un registro autoritativo, el CRM debería consumirlo o referenciarlo.
Autoalojamiento: control a cambio de responsabilidad
Desplegar Twenty en infraestructura propia permite decidir ubicación, copias, red y políticas de acceso. Sin embargo, también obliga a la organización a mantener actualizaciones, base de datos, monitorización y seguridad.
El autoalojamiento no debe presentarse como ausencia de costes. La comparación con SaaS debe incluir personal, infraestructura, soporte y tiempo de respuesta ante incidencias.
La estrategia europea de código abierto recuerda que la soberanía tecnológica depende de capacidad operativa y no únicamente de disponer del código.
Modelo de datos configurable sin perder gobierno
La flexibilidad para crear objetos y campos puede ser útil en programas muy diferentes. Pero una libertad total puede generar decenas de estructuras incompatibles dentro del mismo organismo.
Conviene definir convenciones para nombres, identificadores, campos obligatorios y retención. Los objetos compartidos deberían contar con responsables y documentación.
Cuando exista un dato maestro externo, como una organización o unidad administrativa, el CRM debe almacenar el identificador y no inventar una copia desconectada.
REST, GraphQL y webhooks como capa de integración
Twenty ofrece interfaces que pueden conectar formularios, portales, correo, calendarios y sistemas corporativos. La Administración debería gestionar estas APIs mediante un catálogo y credenciales de servicio.
Los webhooks permiten reaccionar a cambios sin consultas continuas, pero necesitan reintentos, firma y control de duplicados.
El patrón se relaciona con iniciativas de interoperabilidad mediante bloques y APIs, donde el objetivo es desacoplar servicios.
Identidad y permisos
Un CRM puede concentrar información de contactos y organizaciones. Los roles deben limitar qué equipos ven, modifican o exportan cada tipo de dato.
La autenticación debería integrarse con el sistema corporativo cuando sea posible. Mantener cuentas locales independientes aumenta carga de gestión y riesgo de accesos olvidados.
Los permisos necesitan revisión periódica, especialmente cuando empleados cambian de unidad o terminan proyectos.
Protección de datos y finalidad
La flexibilidad no justifica recopilar cualquier información sobre una persona. Cada campo debería responder a una finalidad concreta y contar con una política de conservación.
Los procesos de exportación deben estar controlados, porque un CRM facilita generar listas masivas con pocos clics.
También conviene diferenciar información de contacto profesional de datos que puedan tener una sensibilidad mayor.
Correo y calendario: integraciones con impacto
Sincronizar correo o calendario puede mejorar productividad, pero amplía el volumen de información procesada. La Administración debe decidir si necesita almacenar contenido completo, metadatos o únicamente referencias.
Los tokens de acceso a suites corporativas deben gestionarse como secretos y revocarse cuando se elimina un usuario.
La sincronización también necesita límites para evitar que conversaciones ajenas a la finalidad terminen replicadas en el CRM.
Automatizaciones y workflows
Los flujos pueden asignar tareas, crear avisos o actualizar estados. Antes de automatizar conviene documentar el proceso y eliminar pasos redundantes.
Cada automatización debería tener propietario y versión. Cuando una regla cambia, los equipos necesitan saber qué registros se vieron afectados.
Los workflows críticos requieren pruebas en un entorno separado antes de llegar a producción.
Interoperabilidad con gobierno del dato
El CRM puede formar parte de un ecosistema más amplio en el que los datos maestros residen fuera. Iniciativas como Impulsa DATA muestran la importancia de romper silos y definir fuentes autoritativas.
Twenty debería consumir esos datos mediante interfaces y publicar únicamente la información que otros sistemas necesiten.
Este diseño evita que una herramienta de relación termine compitiendo con registros oficiales.
Licencias y obligaciones del software abierto
La presencia de AGPLv3 y componentes con otras licencias obliga a revisar cómo se distribuye, modifica y presta el servicio. El análisis debe realizarse antes de incorporar desarrollos propios.
La organización también debería mantener inventario de dependencias y versiones para conocer vulnerabilidades y obligaciones asociadas.
El código abierto facilita auditoría y adaptación, pero exige disciplina de mantenimiento.
Copias, recuperación y actualización
La base de datos debe respaldarse con una política que contemple pruebas reales de restauración. Un backup no probado puede fallar cuando más se necesita.
Las actualizaciones deberían pasar primero por un entorno de prueba con datos representativos y verificaciones de migraciones de esquema.
El rollback debe formar parte del procedimiento cuando la nueva versión afecte a funciones críticas.
Contratación y soporte
Una Administración puede operar internamente o contratar soporte. En ambos casos, el pliego debería especificar tiempos de respuesta, versiones soportadas, actualizaciones de seguridad y transferencia de conocimiento.
La documentación de despliegue, configuración e integraciones debe pertenecer al organismo y mantenerse actualizada.
La capacidad de cambiar de empresa de soporte es una parte importante de la soberanía.
Cómo evaluar un piloto
Un piloto puede centrarse en una unidad con un caso claro: gestión de empresas participantes, programas de innovación o relaciones con entidades. Debe medir tiempo, calidad de información, adopción y reducción de hojas de cálculo.
También conviene registrar cuántas integraciones requiere y qué esfuerzo operativo supone mantener la plataforma.
El éxito no debería definirse por el número de contactos almacenados, sino por la mejora del proceso.
IA y CRM público
La aparición de asistentes y clasificación automática puede incorporarse en el futuro, pero conviene mantener separada la capa de IA del núcleo de datos. Así se puede cambiar de modelo sin migrar todo el CRM.
La estrategia europea de IA pública interoperable favorece precisamente componentes modulares y reutilizables.
Los casos que afecten a personas deberían mantener supervisión y métricas.
Qué preguntas debe responder un organismo antes de implantarlo
¿Qué dato será maestro? ¿Quién administra campos y workflows? ¿Cómo se integra identidad? ¿Quién actualiza la plataforma? ¿Qué ocurre si cambia el proveedor de soporte? Estas preguntas importan más que una lista de funcionalidades.
También debe existir una política de exportación que permita reconstruir relaciones y configuraciones fuera de la herramienta.
Conclusión operativa
Twenty puede ser una alternativa interesante para equipos públicos que necesitan un CRM configurable y quieren conservar mayor control sobre infraestructura y datos. Su valor dependerá de un modelo de operación maduro.
Autoalojar software abierto no elimina dependencia por sí solo; la reduce cuando se combina con documentación, estándares, capacidades internas y posibilidad real de sustituir componentes.
Qué procesos públicos encajan mejor en un CRM
No todos los procedimientos administrativos necesitan una herramienta de relación. Twenty puede tener sentido en programas de emprendimiento, redes de proveedores, gestión de partners, seguimiento de proyectos, captación de participantes o atención no procedimental.
En cambio, un expediente con efectos jurídicos debe seguir residiendo en los sistemas administrativos correspondientes. El CRM puede mostrar contexto o referencias, pero no debería convertirse de forma accidental en el registro oficial.
Definir esta frontera evita que la flexibilidad de la herramienta genere un segundo sistema de expediente.
Single source of truth y sincronización
Cuando una organización, persona o proyecto ya existe en otro sistema, el CRM debería guardar el identificador común y sincronizar los atributos necesarios. Duplicar manualmente la información produce divergencias difíciles de corregir.
Las sincronizaciones necesitan reglas de precedencia: qué sistema manda sobre dirección, estado, clasificación o datos de contacto. Sin esta decisión, dos aplicaciones pueden sobrescribirse mutuamente.
Los procesos de conciliación deben detectar registros duplicados antes de que afecten a informes y automatizaciones.
Auditoría de cambios
Un CRM público debería permitir conocer quién modificó un registro, qué campo cambió y cuándo. Esta trazabilidad es importante cuando varias unidades trabajan sobre la misma relación.
Los cambios masivos y las importaciones requieren controles adicionales. Una carga incorrecta puede modificar miles de registros en segundos.
Antes de ejecutar operaciones de gran alcance conviene disponer de backup, validación previa y posibilidad de revertir.
Importaciones y calidad inicial del dato
Muchos proyectos empiezan migrando hojas de cálculo y bases existentes. El esfuerzo de limpieza puede ser mayor que el despliegue técnico de la herramienta.
Campos duplicados, formatos inconsistentes y registros obsoletos deberían resolverse antes de cargar. Importar toda la deuda de datos al nuevo CRM reduce la calidad desde el primer día.
Un diccionario de datos ayuda a decidir qué conservar, transformar o eliminar.
Paneles y analítica sin crear métricas engañosas
Twenty permite construir vistas y paneles, pero la Administración debe definir qué indicadores reflejan realmente el proceso. Contar contactos o tareas cerradas puede ser poco útil si el objetivo es mejorar participación o seguimiento.
Los KPI necesitan una definición estable, fuente y responsable. Esto evita que distintos equipos interpreten el mismo número de manera distinta.
Cuando un panel utiliza datos externos, debe mostrar la fecha de actualización y posibles limitaciones.
Integración con herramientas de colaboración
Correo y calendario son solo una parte del ecosistema. Formularios, portales, firma, gestión documental o BI pueden necesitar conectarse. Cada integración añade dependencias y debe justificarse por valor.
La organización debería mantener un catálogo de conectores con propietario, versión y credenciales utilizadas.
Los conectores sin uso deben retirarse para reducir superficie de ataque y complejidad.
Alta disponibilidad y crecimiento
Un piloto puede ejecutarse con una infraestructura pequeña, pero el dimensionamiento cambia si cientos de usuarios trabajan de forma concurrente o si se almacenan millones de actividades.
La base de datos, almacenamiento, colas y búsquedas necesitan monitorización. Los umbrales deberían definirse antes de que el rendimiento afecte a los usuarios.
La escalabilidad también tiene un coste que debe compararse con alternativas SaaS.
Plan de salida y migración
La organización debería ensayar una exportación completa durante la vida del servicio. Contactos, organizaciones, relaciones, campos personalizados y actividades deben poder reconstruirse con formatos documentados.
Las automatizaciones y permisos son a menudo más difíciles de migrar que los datos. Por ello deben mantenerse documentados fuera de la interfaz.
Una prueba de salida reduce incertidumbre cuando llegue una renovación o cambio tecnológico.
Gobernanza de configuración
No todos los administradores deberían poder crear campos, objetos o workflows sin coordinación. La flexibilidad necesita un proceso ligero de gobierno para evitar proliferación descontrolada.
Un comité de producto o responsable funcional puede revisar cambios con impacto transversal y mantener un backlog de mejoras.
La herramienta funcionará mejor si la configuración evoluciona como un producto y no como una suma de peticiones aisladas.
Qué debería contener una prueba de concepto
Un piloto útil necesita datos realistas, integración con identidad, una importación representativa y al menos un flujo completo de trabajo. Probar solo la interfaz no demuestra viabilidad operativa.
La evaluación debería incluir tiempos de alta, búsqueda, actualización, exportación y recuperación, además de seguridad y soporte.
Con esos datos, la Administración puede decidir si Twenty aporta suficiente valor frente a otras alternativas.
La gobernanza de configuración debería revisarse al menos de forma trimestral para detectar campos duplicados, automatizaciones sin uso y permisos heredados que aumenten complejidad o riesgo.
La organización debería revisar también el crecimiento de almacenamiento y actividad para anticipar costes y evitar degradación de rendimiento a medida que aumentan usuarios y registros.
Fotografía: MART PRODUCTION / Pexels.