CCK CrossCheck CONFIDENCIAL — USO INTERNO CrossCheck Platform Documento de Requisitos del Producto Plataforma Unificada de CRM, Gestión de Tareas y Base de Conocimiento Versión 1.0 Fecha Julio 2026 Empresa CrossCheck (CCK) Clasificación Confidencial CrossCheck S.A.S. — Bogotá, Colombia — crosscheck.co Tabla de Contenidos 1. Resumen Ejecutivo 2. Equipo y Roles 2.1 Perfiles del Equipo Actual 2.2 Matriz de Permisos 3. Arquitectura del Sistema — 9 Pilares 3.1 Pilar 1: CRM y Pipeline de Ventas 3.2 Pilar 2: Motor de Tareas Unificado 3.3 Pilar 3: Diseño de Solución y Templates 3.4 Pilar 4: Portal de Cliente 3.5 Pilar 5: Sistema de E-Tickets con SLA 3.6 Pilar 6: Dashboard Ejecutivo 3.7 Pilar 7: Base de Conocimiento 3.8 Pilar 8: Motor de Documentos 3.9 Pilar 9: Pipeline de Desarrollo e Integraciones 4. Modelo de Datos Conceptual 5. Flujos de Trabajo Detallados 6. Requisitos No Funcionales 7. Estrategia de Migración de Datos 8. Roadmap de Desarrollo — 3 Fases 9. Métricas de Éxito 10. Apéndices Sección 1 Resumen Ejecutivo 167 Registros CRM en Notion 1,073 Tareas históricas 129 E-tickets de soporte 25 Clientes activos (Cerrado) 9 Pilares integrados 3 Fases de desarrollo ¿Qué es CrossCheck? CrossCheck (CCK) es una empresa colombiana B2B que provee una plataforma de gestión operativa digital a clientes en seguridad, retail, transporte, hotelería y otras industrias. Su portafolio de módulos incluye minutas digitales, asistencia por códigos QR, dashboards de control en tiempo real, motores de programación, inventario y módulos de mantenimiento. Con 25 clientes activos y un pipeline de 38 prospectos en distintas etapas, CrossCheck opera en 7 industrias y ha construido en los últimos años una base sólida de conocimiento operativo, procesos de onboarding e historial de interacciones con clientes. El equipo actual de 5 personas — David Stewart (CEO/Fundador), Asleidy Garavito (Gerente de Operaciones), Simon Stewart (Ventas/Marketing), Angela Florez (Administrativa/Legal) y Andrés Felipe (Ingeniero Junior) — gestiona simultáneamente el crecimiento comercial, la implementación de nuevos clientes, el soporte técnico y el desarrollo del producto. Esta concentración de responsabilidades exige herramientas que multipliquen la capacidad del equipo, no que la consuman. El Problema: Fragmentación Operativa Actualmente CrossCheck opera con tres sistemas desconectados entre sí: un workspace de Notion que funge como CRM y gestor de tareas, Google Sheets como planes de proyecto individuales por cliente y módulo, y una hoja de e-tickets para solicitudes de soporte. Esta fragmentación genera consecuencias documentadas y cuantificables: Pérdida de leads: El 98% de las 1,073 tareas en Notion no tiene prioridad asignada; el 95.6% no tiene proyecto vinculado. Sin un sistema de seguimiento estructurado, los leads pueden pasar semanas sin contacto. Crisis de SLA: De los 129 e-tickets registrados, 68 no están resueltos y 63 tienen fecha límite vencida. No existe ningún mecanismo automático de alerta ni medición de tiempos de respuesta. Cuello de botella operacional: Asleidy Garavito concentra el 67% de todas las asignaciones de e-tickets (87 de 129), lo que crea un único punto de falla en la operación. Visibilidad nula para clientes: Los clientes como Pacific (con 5 módulos activos y 2 en proceso) reciben su plan de proyecto a través de Google Sheets por correo, sin visibilidad en tiempo real ni capacidad de interacción. Escalabilidad imposible: Con 25 clientes activos y procesos 100% manuales, añadir nuevos clientes o empleados requiere replicar trabajo manual, sin automatización ni trazabilidad. La Solución: CrossCheck Platform CrossCheck Platform es una plataforma web unificada que consolida en un único sistema todos los procesos operativos, comerciales y de gestión de conocimiento de la empresa. Se construirá en tres fases progresivas, comenzando por los elementos críticos para la operación inmediata y extendiendo capacidades hacia clientes y automatización en fases posteriores. Visión del Producto Una plataforma única donde el equipo CrossCheck gestiona el ciclo de vida completo: desde la captura de un lead comercial, pasando por la firma del contrato, la implementación por fases, el soporte continuo y la renovación del servicio — todo con trazabilidad completa, sin cambiar de herramienta. Por qué se construye ahora La decisión de construir una plataforma propia en lugar de adoptar una solución de mercado responde a varias razones estratégicas identificadas durante el análisis de datos y las sesiones de trabajo con el equipo: Producto propio como diferenciador: CrossCheck vende una plataforma de gestión operativa a sus clientes. Construir su propio sistema interno demuestra capacidad técnica real y genera activos reutilizables. Datos y relaciones preexistentes: Los 167 registros CRM, 1,073 tareas y 129 e-tickets representan capital operativo que debe migrarse con precisión, algo que ninguna herramienta off-the-shelf facilita. Arquitectura a medida: El flujo específico de CrossCheck — desde el diseño de solución post-cierre hasta la sincronización bidireccional con Google Sheets — requiere lógica de negocio que no existe en productos genéricos. Crecimiento planificado: La plataforma está diseñada para escalar con el equipo: agregar nuevos roles, nuevos agentes y nuevas industrias sin rediseñar la arquitectura. Este documento de requisitos del producto (PRD) es el documento fundacional que guiará el diseño, desarrollo, pruebas y despliegue de CrossCheck Platform. Toda decisión de arquitectura, modelo de datos y flujo de trabajo descrita en este documento fue confirmada con el equipo durante sesiones de trabajo entre mayo y julio de 2026. Sección 2 Equipo y Roles 2.1 Perfiles del Equipo Actual El equipo CrossCheck está compuesto actualmente por cinco personas con roles claramente definidos. La plataforma está diseñada para escalar: los roles son abstracciones del sistema, no ataduras a individuos. A medida que la empresa crezca, nuevos miembros heredarán los permisos y rutas de onboarding del rol correspondiente sin requerir reconfiguración. Perfiles del Equipo CrossCheck y Responsabilidades Principales Nombre Rol en la Plataforma Responsabilidades Principales Módulos Principales David Stewart CEO / Fundador Estrategia técnica y de producto, definición de pricing, decisiones de arquitectura, diseño de solución para clientes clave, aprobación de documentos CRM (todos los registros), Diseño de Solución, Dashboard Ejecutivo, Dev Pipeline, Configuración del sistema Asleidy Garavito Gerente de Operaciones Configuración de la plataforma CrossCheck para clientes, soporte operativo, ejecución de tareas de implementación, gestión de e-tickets, diseño de solución colaborativa Motor de Tareas, Diseño de Solución, E-Tickets, Portal de Cliente (configuración), CRM operativo Simon Stewart Ventas / Marketing Captura y calificación de leads, presentaciones comerciales, reuniones con clientes, llamadas en frío, seguimiento del pipeline de ventas CRM Pipeline, Tareas de ventas (propias), Base de Conocimiento (materiales comerciales) Angela Florez Administrativa / Legal Gestión de facturación y cobros, contratos y documentos legales, cumplimiento normativo, reportes financieros, firma y custodia de documentos Motor de Documentos, CRM (datos financieros), Tareas administrativas Andrés Felipe Ingeniero Junior Nuevos desarrollos de la plataforma CrossCheck, estabilidad y mantenimiento técnico, implementación de feature requests, QA de nuevas funcionalidades Dev Pipeline, Tareas de desarrollo, Base de Conocimiento técnica 2.2 Matriz de Permisos por Rol La siguiente matriz define el nivel de acceso de cada rol a las funcionalidades de la plataforma. Los permisos son heredados por cualquier nuevo usuario asignado al rol, permitiendo el crecimiento del equipo sin fricción administrativa. El símbolo ✅ indica permiso completo, 🔍 indica acceso de solo lectura o filtrado, y ❌ indica sin acceso. Matriz de Permisos por Rol — CrossCheck Platform Acción / Módulo CEO (David) Operaciones (Asleidy) Ventas (Simon) Admin/Legal (Angela) Dev (Andrés) CRM y Pipeline Ver todos los registros CRM ✅ ✅ ✅ ✅ 🔍 Crear y editar registros CRM ✅ ✅ ✅ ✅ ❌ Eliminar registros CRM ✅ ❌ ❌ ❌ ❌ Mover etapas del pipeline ✅ ✅ ✅ ❌ ❌ Ver datos financieros (mensualidad, implementación) ✅ ✅ ❌ ✅ ❌ Tareas y Kanban Ver todas las tareas ✅ ✅ 🔍 ✅ ✅ Crear tareas ✅ ✅ ✅ ✅ ✅ Editar tareas propias ✅ ✅ ✅ ✅ ✅ Editar cualquier tarea ✅ ✅ ❌ ❌ ❌ Eliminar tareas ✅ ❌ ❌ ❌ ❌ Priorizar y reordenar tareas ✅ ✅ ❌ ❌ ❌ Diseño de Solución y Documentos Ejecutar Diseño de Solución ✅ ✅ ❌ ❌ ❌ Crear y generar documentos ✅ ✅ ✅ ✅ ❌ Aprobar y firmar documentos ✅ ❌ ❌ ✅ ❌ Portal, Dashboard y KB Configurar accesos al Portal de Cliente ✅ ✅ ❌ ❌ ❌ Ver Dashboard Ejecutivo (completo) ✅ ✅ 🔍 ✅ 🔍 Crear y editar artículos de KB ✅ ✅ ✅ ❌ ✅ Gestionar Dev Pipeline ✅ ❌ ❌ ❌ ✅ Configuración del sistema / Gestión de usuarios ✅ ❌ ❌ ❌ ❌ Escalabilidad del Sistema de Roles Los roles son abstractos y no están atados a personas específicas. Al contratar un nuevo ejecutivo de ventas, basta con asignarle el rol "Ventas" para que herede todos los permisos de Simon Stewart. Cuando se contrate un nuevo operador de soporte, recibirá el rol "Operaciones" y la ruta de onboarding correspondiente en la Base de Conocimiento — sin intervención del área técnica. 2.3 Rutas de Onboarding por Rol La plataforma asigna automáticamente una ruta de aprendizaje estructurada al crear un nuevo usuario, basada en su rol. Las rutas se construyen desde el contenido de la Base de Conocimiento (Pilar 7) y se presentan como una secuencia de artículos, videos y checklists de verificación. Rutas de Onboarding por Rol Rol Secuencia de Módulos de Onboarding CEO / Fundador Overview completo de todos los módulos → Dashboard Ejecutivo → Configuración del sistema → Diseño de Solución Operaciones Gestión de CRM → Motor de Tareas y Kanban → Diseño de Solución → Portal de Cliente → E-Tickets / SLA → Reportes Ventas / Marketing CRM / Pipeline de Ventas → Propuestas y Presentaciones → Seguimiento de Leads → Demostración del Portal de Cliente Admin / Legal CRM (datos financieros) → Facturación y cobros → Motor de Documentos → Contratos y firma → Reportes financieros Ingeniero Arquitectura del sistema → Dev Pipeline → Base de Conocimiento técnica → QA y despliegue → Módulos de la plataforma CCK Sección 3 Arquitectura del Sistema — 9 Pilares Integrados La arquitectura de CrossCheck Platform se organiza en nueve pilares funcionales interconectados, agrupados en tres fases de desarrollo. Cada pilar tiene responsabilidades claras, conexiones definidas con los demás pilares, y un modelo de datos propio. Los pilares de Fase 1 son el MVP: sin ellos, nada funciona. Los pilares de Fase 2 extienden el valor hacia clientes externos y visibilidad ejecutiva. Los pilares de Fase 3 automatizan procesos manuales costosos y preparan la plataforma para escalar. Resumen de los 9 Pilares por Fase # Pilar Fase Descripción Corta 1 CRM y Pipeline de Ventas Fase 1 — MVP Gestión del ciclo comercial completo desde lead hasta cliente activo 2 Motor de Tareas Unificado + Kanban Fase 1 — MVP Sistema único para tareas operativas, soporte y ad-hoc con Kanban continuo 3 Diseño de Solución y Templates Fase 1 — MVP Paso intermedio post-cierre que genera automáticamente el árbol de tareas 4 Portal de Cliente Fase 2 Interfaz external vía Magic Link con visibilidad de proyectos por módulo 5 Sistema de E-Tickets con SLA Fase 2 Tickets con SLA formal, indicadores visuales y métricas de cumplimiento 6 Dashboard Ejecutivo Fase 2 Tablero de control con métricas de pipeline, carga del equipo y salud de clientes 7 Base de Conocimiento Fase 3 Repositorio centralizado de SOPs, procesos y rutas de capacitación por rol 8 Motor de Documentos Fase 3 Generación de contratos y manuales con auto-llenado desde CRM y validación 9 Pipeline de Desarrollo e Integraciones Fase 3 Gestión de feature requests, dev pipeline y sincronización bidireccional con Sheets 3.1 Pilar 1: CRM y Pipeline de Ventas Fase 1 — MVP Descripción Funcional El CRM es la fuente de verdad de todas las relaciones comerciales de CrossCheck. Gestiona el ciclo completo desde la primera captura de un lead hasta la conversión en cliente activo con módulos contratados. Incluye un pipeline visual con siete estados, datos de contacto estructurados, información financiera en COP (mensualidad e implementación), categorización por industria, historial de interacciones, y un score de salud automático basado en actividad y tiempo sin contacto. Estados del Pipeline El pipeline tiene flujo unidireccional con los siguientes estados: Lead → Calificado → Propuesta → Negociación → Cerrado Ganado / Cerrado Perdido / Descalificado. El evento de conversión a "Cerrado Ganado" dispara automáticamente el paso de Diseño de Solución (Pilar 3). Campos del CRM (34 columnas migradas desde Notion) Los campos se organizan en cinco categorías: Datos de empresa (nombre, industria, dirección, NIT, tipo de empresa), Datos financieros (mensualidad COP, implementación COP, fecha de facturación, módulos contratados), Datos de contacto (nombre gerencia, email gerencia, teléfono, email contable, nombre contable, datos del embajador), Fechas del ciclo comercial (primer contacto, primera reunión, envío de propuesta, inicio de negociación, cierre, próxima reunión, último contacto), y Campos de gestión (estado pipeline, responsable CCK, notas último contacto, tipo de reporte, reporte por entregar). Health Score Automático Cada registro de cliente activo (estado "Cerrado") recibe un health score calculado automáticamente con base en: días desde el último contacto registrado, número de tareas de soporte vencidas vinculadas al cliente, porcentaje de progreso de implementación, y regularidad en el pago de mensualidades. El semáforo de salud (verde / amarillo / rojo) es visible en la lista de CRM y en el Dashboard Ejecutivo. Conectores con Otros Pilares → Pilar 3: El cierre del deal dispara el Diseño de Solución → Pilar 8: Los datos del CRM son fuente para placeholders en documentos; la compuerta de validación CRM debe estar completa antes de generar documentos → Pilar 6: Métricas de pipeline y MRR se derivan del CRM ← Pilar 5: Los e-tickets se vinculan al registro CRM del cliente → Pilar 4: Los datos de empresa y contacto alimentan la creación del Portal 3.2 Pilar 2: Motor de Tareas Unificado + Kanban Fase 1 — MVP Descripción Funcional El motor de tareas es el corazón operativo de la plataforma. Unifica en un solo sistema tres tipos de trabajo que hoy viven en herramientas separadas: tareas operativas de implementación (de Notion), e-tickets de soporte (de la hoja de tickets), y solicitudes ad-hoc que surgen de conversaciones con clientes. El diferenciador que permite distinguirlos sin separarlos es el identificador de urgencia, un campo filtrable en todas las vistas. Tipos de Urgencia (Identificador) Parametrización: Tareas de implementación y configuración de módulos CCK para clientes. Generadas automáticamente desde el Diseño de Solución. Soporte: E-tickets, correcciones, bugs y solicitudes de asistencia técnica. Tienen SLA formal. Ad-hoc: Solicitudes operativas que surgen de conversaciones, no planificadas en ningún template. Sin SLA predefinido pero con fecha límite asignada. Interno: Tareas del equipo CCK sin vinculación a un cliente específico (planificación, marketing, administración). Estados Kanban (Flujo Continuo — Sin Sprints) El tablero Kanban opera con flujo continuo: Sin empezar → En curso → Lista. Estados adicionales de gestión: En pausa (bloqueada esperando información) y Archivada (completada pero preservada para historial). No hay sprints ni iteraciones — la priorización es continua y por decisión de equipo. Campos Obligatorios de Toda Tarea Toda tarea creada en el sistema debe tener: título descriptivo, tipo de urgencia, fecha/hora de vencimiento, responsable del equipo CCK (siempre un miembro interno, nunca un cliente), prioridad (Alta / Media / Baja), estado Kanban, empresa cliente vinculada (si aplica), y módulo vinculado (si aplica). El ID secuencial en formato CCK-NNN se asigna automáticamente al crear la tarea. Indicadores Visuales SLA Cada tarea muestra un indicador de estado temporal basado en la fecha/hora de vencimiento: Verde — a tiempo (más de 24 horas restantes), Amarillo — próxima a vencer (menos de 24 horas), Rojo — vencida (fecha límite pasada sin completar), Gris — completada a tiempo (histórico). Estos indicadores son visibles en todas las vistas: Kanban, lista, por persona, por cliente. Priorización Global con Trazabilidad El equipo puede reordenar prioridades mediante drag-and-drop en la vista global de tareas. Cada cambio de posición genera automáticamente un registro de trazabilidad: quién realizó el cambio, cuándo, y desde/hasta qué posición. Esto resuelve el problema actual donde el 98% de las tareas de Notion no tienen prioridad y nadie sabe por qué. Vistas Disponibles Kanban global (todas las tareas del equipo, filtrable) Por miembro del equipo (carga de trabajo individual) Por empresa cliente (todas las tareas de un cliente) Por módulo / proyecto Por tipo de urgencia (parametrización / soporte / ad-hoc) Por estado SLA (solo vencidas, solo próximas a vencer) 3.3 Pilar 3: Diseño de Solución y Templates Fase 1 — MVP Descripción Funcional El Diseño de Solución es el paso intermedio que conecta el cierre de una venta con la generación del árbol de tareas de implementación. Sin este paso, el equipo tendría que crear las tareas manualmente cada vez. El Diseño de Solución es liderado por David Stewart o Asleidy Garavito, quienes seleccionan o construyen una plantilla flexible de tareas según las necesidades específicas del cliente y los módulos contratados. Constructor Flexible de Templates (No Catálogo Fijo) El sistema no tiene un catálogo predefinido de templates. En su lugar, ofrece un constructor flexible donde cada plantilla puede tener más o menos elementos según el contexto. Los templates se organizan por tipo de módulo (Mantenimiento, Calidad, QR, Minutas, etc.) pero son totalmente editables. Esta flexibilidad replica la forma en que David y Asleidy trabajan hoy, pero elimina la creación manual de Sheets individuales. Estructura de Fases Basada en Google Sheets Pacific El modelo de fases se deriva directamente de los Sheets de Pacific (la referencia más madura del equipo), y se convierte en la estructura estándar de todo proyecto de implementación: Fases Estándar de Implementación CCK Fase Nombre Descripción Principal Responsable Típico 1 Análisis e inicio Entendimiento de la problemática, legalización (contrato), identificación de contraparte, paquete de bienvenida Cliente y CCK 2 Levantamiento de información Estructura organizacional, roles y usuarios, espacios físicos, información para tableros, capacitaciones requeridas Equipo CCK 3 Desarrollo — DTL Creación del ambiente, usuarios y roles, tareas y categorías, homogeneización, prueba interna Equipo CCK 4 Validación y entrenamiento Entrega de plataforma parametrizada, jornadas de capacitación, interacción de entrenamiento, correcciones Cliente y CCK 5 Entrega y capacitaciones Entrega de plataforma perfilada según uso, capacitación final de uso de producto, SOPs Cliente y CCK 6 Delimitación y sostenibilidad Tablero de control con datos reales, retroalimentación UX/datos, seguimiento cada 15 días por 2 meses Cliente y CCK Flujo del Diseño de Solución El CRM registra el cierre del deal (estado "Cerrado Ganado"). Se dispara automáticamente la creación de un registro de Diseño de Solución vinculado al cliente. David o Asleidy abren el Diseño de Solución, seleccionan los módulos a implementar y eligen o construyen la plantilla correspondiente. Personalizan las fases, subtareas, responsables y fechas estimadas según la información recolectada del cliente. La solicitud de Diseño pasa a revisión (David) y luego a aprobación. Al aprobar, el sistema genera automáticamente el árbol completo de tareas en el Motor de Tareas (Pilar 2), asigna responsables y fechas. El progreso se calcula automáticamente: % Fase = PROMEDIO(% subtareas), reemplazando las fórmulas AVERAGE manuales de Sheets. 3.4 Pilar 4: Portal de Cliente Fase 2 Descripción Funcional El Portal de Cliente es la interfaz externa de CrossCheck. Reemplaza la entrega de Google Sheets por correo como mecanismo de visibilidad para los clientes. Cada empresa cliente tiene un portal personalizado con arquitectura multi-módulo: una persona de contacto ve todos los proyectos/módulos de su empresa en una sola pantalla, con drill-down a cada uno. Acceso vía Magic Link (Sin Contraseñas) El portal elimina completamente la gestión de contraseñas. El flujo de acceso es: (1) El equipo CCK configura el acceso para el contacto principal de la empresa. (2) El contacto recibe un email con un enlace único (Magic Link) con tiempo de expiración configurable. (3) Al hacer click, el token autentica automáticamente al usuario y abre el portal. (4) Para sesiones futuras, el cliente ingresa su email y el sistema envía un nuevo Magic Link. No hay gestión de contraseñas ni flujos de recuperación. Dashboard a Nivel Empresa La vista inicial muestra una panorámica de todos los módulos de la empresa. Ejemplo para Pacific (7 módulos): cada módulo aparece como una tarjeta con nombre, estado (Activo / En Implementación / Completado), porcentaje de progreso auto-calculado, conteo de tareas (completadas / total) y próximo hito. Un resumen ejecutivo muestra métricas agregadas de todos los módulos. Capacidades del Cliente en el Portal Marcar tareas como completadas — solo las tareas asignadas al cliente (responsable: "Cliente" o "Cliente y CCK" en la terminología de los Sheets) Ver progreso en tiempo real — por módulo y por fase, calculado automáticamente desde las tareas Crear solicitudes ad-hoc — fluyen directamente al Motor de Tareas con tipo de urgencia "soporte" Acceder a documentos — contratos firmados, manuales, SOPs entregados Exportar datos — descargar reporte de progreso para documentación interna El equipo CCK también puede marcar tareas de clientes como completadas desde la vista interna, ya que en la práctica los clientes a veces no acceden al portal y el equipo necesita registrar el avance en su nombre. 3.5 Pilar 5: Sistema de E-Tickets con SLA Fase 2 Descripción Funcional El sistema de e-tickets es parte del Motor de Tareas Unificado (Pilar 2) — no un sistema separado. Los tickets se diferencian por el identificador de urgencia "soporte" y cuentan con SLA formal: cada ticket tiene una fecha/hora de vencimiento asignada al momento de creación, indicadores visuales de semáforo, y métricas de cumplimiento. Los 129 e-tickets existentes se migran como semilla del sistema. Semáforo SLA Visual El indicador de SLA es una barra de tiempo coloreada visible en todas las vistas: verde (más de 24h restantes), amarillo (menos de 24h), rojo (vencido sin resolver). Al completar un ticket, el sistema registra si fue resuelto a tiempo, tarde, o en el plazo exacto — generando las métricas de cumplimiento del Dashboard Ejecutivo. Categorías de Tickets (derivadas del análisis de 129 registros) Informes / Reportes (8 registros históricos): generación de reportes periódicos para clientes Desarrollo / Plataforma (14 registros): cambios técnicos, nuevas funcionalidades, correcciones de bugs Capacitación / Seguimiento (13 registros): sesiones de entrenamiento, videos, acompañamiento Parametrización / Configuración (6 registros): ajustes de la plataforma CCK para el cliente Operativas / Otras (73 registros): solicitudes diversas sin categoría principal Reglas de SLA por Defecto Las reglas de SLA se configuran por prioridad: Alta — máximo 24 horas, Media — máximo 72 horas, Baja — máximo 7 días. Estas reglas son configurables por el CEO desde la Configuración del Sistema. 3.6 Pilar 6: Dashboard Ejecutivo Fase 2 Descripción Funcional El Dashboard Ejecutivo consolida métricas de todos los pilares en una sola vista de control para el equipo CCK. Elimina la necesidad de consultar múltiples herramientas para entender el estado del negocio. Widgets y Métricas Widgets del Dashboard Ejecutivo Widget Métrica Principal Fuente de Datos Salud del Pipeline Leads por etapa, valor ponderado, velocidad de conversión Pilar 1 — CRM MRR Proyectado Ingresos recurrentes actuales + proyección desde pipeline Pilar 1 — CRM (mensualidades) Carga de Trabajo del Equipo Tareas activas por persona, tareas vencidas por persona Pilar 2 — Tareas Salud de Clientes Score de salud por cliente activo, clientes en riesgo Pilares 1, 2 y 5 Cumplimiento de SLA % tickets resueltos a tiempo esta semana/mes Pilar 5 — E-Tickets Progreso de Implementaciones % completado por módulo activo en todos los clientes Pilar 2 — Tareas Ingresos por Industria MRR distribuido por sector industrial Pilar 1 — CRM Tareas Vencidas Lista de tareas con SLA rojo, agrupadas por responsable Pilar 2 — Tareas 3.7 Pilar 7: Base de Conocimiento Fase 3 Descripción Funcional La Base de Conocimiento es el repositorio centralizado de todo el saber operativo de CrossCheck: SOPs de módulos, procedimientos de onboarding, guías por industria, videos de capacitación Loom (migrados desde el Notion KB actual), y plantillas de documentos internos. Está diseñada como el motor de escalabilidad del equipo: cuando se contrata un nuevo miembro, la KB guía su onboarding estructurado. Tipos de Contenido Soportados Editor de texto enriquecido con bloques: texto libre, encabezados (H1-H3), listas, listas de verificación, tablas, imágenes, bloques de código, videos embebidos (Loom, YouTube), y enlaces a Google Drive. Estructura jerárquica: carpetas → páginas → sub-páginas. Búsqueda de texto completo en todo el contenido. Organización del Contenido Por módulo CCK: Minutas, QR, Inventario, Mantenimiento, Calidad, etc. Por industria: Seguridad, Retail, Transporte, Hotelería, etc. Por proceso interno: Onboarding de clientes, Soporte técnico, Ventas, Administración Rutas de capacitación por rol: Secuencias estructuradas para nuevos empleados 3.8 Pilar 8: Motor de Documentos Fase 3 Descripción Funcional El Motor de Documentos automatiza la creación de contratos, manuales técnicos y presentaciones comerciales mediante plantillas con placeholders que se rellenan automáticamente desde los datos del CRM. Una compuerta de validación garantiza que ningún documento se genere con información incompleta. Flujo de Generación Navegar al cliente en CRM → click en "Generar Documento" Compuerta de validación CRM: el sistema verifica que todos los campos requeridos estén completos. Si hay campos vacíos, muestra la lista y bloquea la generación hasta completarlos. Selección de plantilla: el usuario elige el tipo de documento del repositorio. Auto-llenado: el sistema rellena todos los placeholders (nombre empresa, NIT, dirección, representante legal, módulos contratados, mensualidad, fecha de inicio). Revisión humana: el documento se presenta en vista previa para edición manual antes de finalizar. Generación en PDF: se genera la versión final descargable. Flujo de firma simplificado: el cliente descarga el documento, lo firma externamente y sube la copia firmada por email. El sistema almacena la versión firmada con registro de fecha y auditoría. (Nota: no se implementa firma digital en-plataforma en esta versión.) Tipos de Documentos Contratos de servicio (contrato inicial, adiciones, renovaciones) Manuales técnicos de usuario por módulo Presentaciones comerciales por industria Informes de gestión periódicos 3.9 Pilar 9: Pipeline de Desarrollo e Integraciones Fase 3 Descripción Funcional El Pipeline de Desarrollo gestiona la evolución interna del producto CCK: desde las ideas y feature requests de clientes hasta la producción. Se nutre de los e-tickets de tipo "desarrollo/plataforma" y los convierte en un pipeline estructurado de desarrollo. Adicionalmente, incluye la sincronización bidireccional con Google Sheets para mantener la compatibilidad con los planes de proyecto existentes durante la transición. Estados del Dev Pipeline Idea → Backlog → Diseño → Desarrollo → QA → Producción. Los feature requests se vinculan a los registros de cliente CRM, permitiendo saber qué cliente solicitó qué funcionalidad y cuándo fue entregada. Sincronización Bidireccional con Google Sheets Cada cliente tiene opcionalmente un Google Sheet de plan de proyecto (como Pacific hoy). La sincronización es bidireccional: los cambios en la plataforma se reflejan en el Sheet y viceversa. Esto permite una transición progresiva sin obligar a los clientes a abandonar los Sheets de un día para otro. La estructura de columnas es compatible con el formato actual: Obj., Título, Responsable, % Completado, Fechas de inicio y entrega. Sección 4 Modelo de Datos Conceptual El modelo de datos de CrossCheck Platform define las entidades centrales del sistema, sus atributos clave, y las relaciones entre ellas. Este modelo es el contrato que guía el desarrollo de la base de datos y garantiza que todas las conexiones entre pilares estén correctamente representadas. 4.1 Entidades Principales Company (Empresa Cliente) Campos: id (PK), nombre, industria (enum: Seguridad, Retail, Transporte, Hotelería, Servicios, Grandes Superficies, Salubridad), NIT, dirección, email_gerencia, tel_gerencia, email_contable, nombre_contable, mensualidad_COP, implementacion_COP, estado_pipeline (enum), fecha_primer_contacto, fecha_cierre, responsable_cck_id (FK → User), health_score, created_at, updated_at Relaciones: tiene N Contacts, tiene N Modules, tiene N Tasks vinculadas, tiene N Documents generados Contact (Persona de Contacto) Campos: id (PK), company_id (FK → Company), nombre, email, telefono, rol (enum: Gerencia, Contable, Embajador, Portal), es_contacto_portal (bool), magic_link_token, magic_link_expires_at, last_portal_access Relaciones: pertenece a 1 Company; si es_contacto_portal = true, tiene acceso al Portal del cliente Module (Módulo Contratado) Campos: id (PK), company_id (FK → Company), nombre (libre: "Mantenimiento", "Calidad", "QR", etc.), tipo_modulo, estado (enum: En Implementación, Activo, Completado, En Pausa), progreso_calculado (float, derivado), solution_design_id (FK → SolutionDesign), fecha_inicio, fecha_entrega_estimada Relaciones: pertenece a 1 Company; tiene N Tasks vinculadas; tiene 1 SolutionDesign fuente Task (Tarea Unificada) Campos: id (PK), cck_id (string, formato CCK-NNN, único), titulo, descripcion, urgency_type (enum: parametrizacion, soporte, ad-hoc, interno), prioridad (enum: Alta, Media, Baja), estado (enum: Sin empezar, En curso, Lista, En pausa, Archivada), fecha_limite (datetime), company_id (FK → Company, nullable), module_id (FK → Module, nullable), parent_task_id (FK → Task, nullable, self-relation), assignee_ids (array FK → User[]), created_by (FK → User), sla_config_id (FK → SLAConfig, nullable), completada_a_tiempo (bool, calculado), created_at, updated_at Relaciones: pertenece a 0-1 Company; pertenece a 0-1 Module; puede tener 1 tarea padre (parent) y N subtareas; asignada a N Users CCK; puede ser completada por Contact (portal) o User (interno) PriorityDecision (Trazabilidad de Priorización) Campos: id (PK), task_id (FK → Task), user_id (FK → User), posicion_anterior (int), posicion_nueva (int), timestamp Relaciones: pertenece a 1 Task; registrada por 1 User; cada drag-and-drop genera 1 registro User (Miembro del Equipo CCK) Campos: id (PK), nombre, email, role_id (FK → Role), activo (bool), fecha_incorporacion Relaciones: tiene 1 Role; puede ser asignado a N Tasks; ejecuta N PriorityDecisions; crea N Tasks Role (Rol de Permisos) Campos: id (PK), nombre (enum: CEO, Operaciones, Ventas, Admin, Desarrollo), permissions (JSON con permisos granulares por módulo) Relaciones: tiene N Users; define permissions como estructura JSON configurable SolutionDesign (Diseño de Solución) Campos: id (PK), company_id (FK → Company), lider_id (FK → User), template_id (FK → TaskTemplate, nullable), modulos_seleccionados (JSON), configuracion (JSON), estado (enum: Borrador, En Revisión, Aprobado), aprobado_por (FK → User), fecha_aprobacion, generated_tasks_count Relaciones: pertenece a 1 Company; basado en 0-1 TaskTemplate; genera N Tasks al aprobarse TaskTemplate (Plantilla de Tareas) Campos: id (PK), nombre, tipo_modulo, estructura (JSON con fases y subtareas), creado_por (FK → User), version, activo (bool) Relaciones: puede ser base de N SolutionDesigns DocumentTemplate / GeneratedDocument DocumentTemplate: id, nombre, tipo (enum: Contrato, Manual, Presentación), contenido_html (con placeholders), version, activo GeneratedDocument: id, template_id (FK), company_id (FK), campos_llenados (JSON snapshot del CRM), estado (enum: Borrador, Revisión, Generado, Firmado), pdf_url, signed_pdf_url, fecha_firma, creado_por (FK → User), audit_trail (JSON) KBArticle / TrainingPath (Base de Conocimiento) KBArticle: id, titulo, contenido (rich text), categoria, parent_id (self-relation jerárquica), tags[], autor_id (FK → User), version, created_at TrainingPath: id, role_id (FK → Role), articulo_ids (ordenados), progreso por usuario en tabla separada UserTrainingProgress FeatureRequest (Dev Pipeline) Campos: id (PK), titulo, descripcion, company_ids (FK[] → Company, puede ser solicitado por N clientes), estado_dev (enum: Idea, Backlog, Diseño, Desarrollo, QA, Producción), prioridad, asignado_a (FK → User), ticket_origen_id (FK → Task, nullable) Relaciones: puede estar vinculado a N Companies; puede originarse en 1 Task (e-ticket de desarrollo) 4.2 Tabla de Relaciones Clave Relaciones del Modelo de Datos — Cardinalidades y Claves Foráneas Entidad Origen Cardinalidad Entidad Destino Descripción Company 1 : N Contact Una empresa tiene múltiples contactos Company 1 : N Module Una empresa contrata múltiples módulos (ej: Pacific tiene 7) Module 1 : N Task Cada módulo tiene su árbol de tareas Task 1 : N (self) Task (subtarea) Jerarquía tarea padre / subtareas Task N : M User Múltiples usuarios pueden ser asignados a una tarea Company 1 : 1 SolutionDesign (por cierre) Cada cierre de deal genera un Diseño de Solución SolutionDesign 1 : N Task Al aprobar el Diseño, genera el árbol de tareas User N : 1 Role Cada usuario tiene un rol único DocumentTemplate 1 : N GeneratedDocument Una plantilla puede generar múltiples documentos GeneratedDocument N : 1 Company Cada documento pertenece a una empresa FeatureRequest N : M Company Un feature puede ser solicitado por varios clientes FeatureRequest N : 1 Task Un feature request puede originarse en un e-ticket Task N : 1 Company Toda tarea vinculada a un cliente (78% histórico) Nota sobre la Entidad Task La entidad Task es el centro del modelo de datos. Unifica operativas, e-tickets y solicitudes ad-hoc mediante el campo urgency_type. La misma estructura de tabla soporta los tres tipos, con el campo actuando como discriminador para las vistas, reglas de SLA y métricas. Esta decisión arquitectónica elimina la necesidad de múltiples tablas separadas y facilita los reportes cruzados. Sección 5 Flujos de Trabajo Detallados Esta sección describe los seis flujos de trabajo principales de CrossCheck Platform. Cada flujo muestra los actores involucrados (quién hace qué), las acciones del sistema (qué ocurre automáticamente), y los puntos de decisión. Los flujos están ordenados por frecuencia e impacto operacional. Flujo A: Lead → Cliente (Pipeline Completo) Actor principal: Simon Stewart (Ventas). Actores secundarios: David Stewart, Asleidy Garavito, Angela Florez. Duración típica: 2 semanas a 3 meses. 1 Simon identifica una oportunidad (llamada en frío, referido, inbound). Sistema: crea registro Company con estado "Lead", asigna a Simon como responsable, registra fecha de primer contacto. 2 Simon / David evalúan fit: industria, tamaño, necesidad real, presupuesto. Registran notas de la primera conversación. Deciden: calificar o descalificar. 3 Sistema: mueve el deal a "Calificado" o "Descalificado". Si calificado, registra alerta de seguimiento si hay inactividad por más de X días. 4 Simon prepara presentación personalizada por industria y módulos. David define pricing (mensualidad COP + implementación COP). Sistema: registra fecha de envío de propuesta. Estado: "Propuesta". 5 Simon / David realizan reuniones de negociación. Registran cada interacción en el historial del CRM. Posibles ajustes de alcance o precio. Estado: "Negociación". 6 Angela gestiona la documentación legal. El cliente acepta. Sistema: registra fecha de cierre, valores finales, módulos contratados. Estado: "Cerrado Ganado". Se activa automáticamente el Diseño de Solución. 7 David o Asleidy reciben notificación del nuevo Diseño de Solución pendiente. Abren el registro, analizan la información del cliente, seleccionan o construyen la plantilla de tareas, personalizan fases y subtareas. 8 David revisa y aprueba el Diseño de Solución. Sistema: genera automáticamente el árbol de tareas en el Motor de Tareas. Asigna responsables. Crea acceso al Portal de Cliente vía Magic Link. Notifica al equipo. 9 Inicia la implementación. Las tareas fluyen por el Kanban: Sin empezar → En curso → Lista. El cliente ve el progreso en tiempo real en su portal. Flujo B: Solicitud Ad-Hoc de Cliente Activo Actor principal: Asleidy Garavito (Operaciones). Actor secundario: Cliente vía portal o conversación. Duración típica: 1 a 5 días. 1 Origen de la solicitud: conversación WhatsApp / reunión / email / llamada con el cliente, o el cliente la crea directamente desde el Portal de Cliente. 2 Asleidy (o el cliente desde el portal) crea una tarea en el Motor de Tareas Unificado. Campos obligatorios: título, tipo de urgencia ("soporte" o "ad-hoc"), responsable CCK, prioridad, fecha/hora límite. Sistema: asigna CCK-NNN automáticamente. Inicia el reloj SLA. 3 Sistema: calcula indicadores SLA basados en la fecha límite. Muestra semáforo visual: verde, amarillo o rojo según el tiempo restante. 4 Responsable asignado mueve la tarea a "En curso" en el Kanban. Registra observaciones de avance durante la ejecución. 5 Responsable CCK completa la tarea y la mueve a "Lista". Alternativamente, el cliente la marca como completada desde el Portal. Sistema: registra quién cerró, fecha/hora, tiempo total de resolución. Calcula si fue dentro del SLA. Actualiza métricas del Dashboard. 6 El progreso del módulo vinculado se recalcula automáticamente si la tarea pertenece a un módulo activo. El cliente ve la actualización en tiempo real en su portal. Flujo C: Generación de Documentos Actor principal: Angela Florez (Admin/Legal) para contratos; Simon Stewart para propuestas. Actor secundario: David Stewart (aprobación). Duración típica: 30 minutos. 1 Angela / Simon navegan al registro del cliente en CRM. Hacen click en "Generar Documento". 2 Sistema: ejecuta la compuerta de validación CRM. Verifica que todos los campos requeridos estén completos (NIT, representante legal, módulos, mensualidad, dirección). Si hay campos vacíos, muestra la lista detallada y bloquea la generación. 3 Si faltan campos: Angela / Simon completan la información faltante en el registro CRM y regresan al paso 2. Si todo está completo: continúan al paso 4. 4 Angela / Simon seleccionan la plantilla del repositorio (ej: "Contrato de Servicio v3"). Sistema: auto-rellena todos los placeholders con datos del CRM. 5 Angela / David revisan el documento en vista previa. Realizan ajustes manuales si es necesario. 6 Sistema: genera PDF final descargable. Registra en el audit trail: quién generó, desde qué plantilla, qué datos del CRM se usaron, timestamp. 7 Angela envía el PDF al cliente por email. El cliente descarga, firma en papel o digitalmente con su herramienta habitual, y devuelve la copia firmada por email. 8 Angela sube la copia firmada a la plataforma. Sistema: vincula el archivo firmado al registro del cliente. Estado del documento: "Firmado". Accesible desde el Portal de Cliente. Flujo D: Experiencia del Portal de Cliente Actor principal: Contacto del cliente (ej: Director de Operaciones de Pacific). Duración: sesión de 5-15 minutos. 1 Cliente recibe un email de CrossCheck con un Magic Link. El enlace es único y tiene tiempo de expiración configurable. 2 Cliente hace click en el enlace. Sistema: valida el token, autentica al contacto automáticamente, abre el portal personalizado de su empresa. Registra la sesión en el audit trail. 3 Cliente ve el dashboard de su empresa con todas las tarjetas de módulos: Mantenimiento (74%), Calidad (57%), y los demás módulos activos con sus porcentajes de progreso en tiempo real. 4 Cliente hace click en "Módulo: Mantenimiento". Ve la vista detallada con el árbol de tareas por fase, con estados (completada, en curso, pendiente) y fechas. 5 Cliente identifica una tarea asignada a él en la Fase 4 (Validación). Marca la tarea como completada. Sistema: actualiza el estado de la tarea, recalcula el % de la fase y del módulo, registra quién completó y cuándo. 6 Cliente tiene una solicitud adicional. Hace click en "Nueva Solicitud". Describe el requerimiento. Sistema: crea una Task con urgency_type "soporte", vinculada a la empresa del cliente. Notifica al equipo CCK. Flujo E: Priorización Global de Tareas Actor principal: David Stewart o Asleidy Garavito. Contexto típico: reunión de equipo al inicio de la semana. Duración: 15-30 minutos. 1 David / Asleidy abren la vista global de tareas (filtro: todas las tareas "Sin empezar" + "En curso"). Las tareas están ordenadas por prioridad actual. 2 El equipo revisa juntos el tablero. Identifican tareas urgentes que requieren reasignación de prioridad. 3 David / Asleidy arrastran una tarea hacia arriba en la lista de prioridad. Sistema: registra automáticamente en PriorityDecision: quién (David Stewart), qué tarea (CCK-1253), de qué posición (12) a qué posición (3), timestamp exacto. 4 Sistema: actualiza las vistas individuales de cada miembro del equipo. Cada persona ve su lista de tareas reordenada según las decisiones de la reunión. 5 Si alguien pregunta posteriormente "¿por qué esta tarea está arriba de esta otra?", cualquier miembro del equipo puede consultar el historial de PriorityDecisions para ver quién tomó la decisión y cuándo. Flujo F: Onboarding de Nuevo Empleado CCK Actor principal: Nuevo empleado. Actor secundario: David Stewart (Admin). Duración: 1-2 semanas de onboarding. 1 David crea la cuenta del nuevo empleado en la Configuración del Sistema. Asigna el rol correspondiente (ej: "Operaciones" para un nuevo agente de soporte). 2 Sistema: envía email de bienvenida al nuevo empleado con sus credenciales. Asigna automáticamente la Ruta de Onboarding correspondiente al rol "Operaciones" desde la Base de Conocimiento. 3 Nuevo empleado accede a la plataforma. Ve su ruta de capacitación: "Gestión de CRM → Motor de Tareas → Diseño de Solución → Portal de Cliente → E-Tickets/SLA → Reportes". 4 Nuevo empleado completa los módulos de onboarding secuencialmente: lee artículos de la KB, ve videos de capacitación Loom embebidos, completa checklists de verificación. 5 Sistema: registra el progreso del onboarding. Notifica a David cuando el empleado completa cada módulo. Una vez completada la ruta, el empleado queda habilitado para operar con los permisos de su rol. 6 David puede verificar el progreso de onboarding de cualquier empleado desde el Dashboard Ejecutivo. No hay incertidumbre sobre si el nuevo miembro conoce los procesos clave. Sección 6 Requisitos No Funcionales 6.1 Plataforma y Accesibilidad Requisitos No Funcionales — Plataforma Requisito Especificación Notas Tipo de acceso Web únicamente (navegador) No se requiere app móvil nativa. La web debe ser responsive. Dispositivos soportados Desktop (principal), Tablet iPad, Smartphone Diseño responsive. Uso móvil principalmente para consulta y completación de tareas. Modo offline No requerido La plataforma requiere conexión a internet. Auto-sync cuando hay conexión. Navegadores Chrome, Firefox, Safari, Edge (versiones modernas) Compatibilidad con las 2 últimas versiones principales de cada navegador. Idioma de la interfaz Español (Colombia) Formato de fechas: DD/MM/YYYY. Moneda: COP. Zona horaria: América/Bogotá (UTC-5). 6.2 Rendimiento Requisitos de Rendimiento Métrica Objetivo Mínimo Aceptable Tiempo de carga inicial menos de 2 segundos menos de 4 segundos Tiempo de respuesta de operaciones CRUD menos de 500ms menos de 1 segundo Volumen de datos actual (capacidad mínima) 167 empresas, 1,200 tareas, 200 e-tickets Sin degradación de rendimiento Escalabilidad objetivo (10x) 1,670 empresas, 12,000 tareas, 2,000 e-tickets Sin rediseño de arquitectura Usuarios concurrentes 5 usuarios internos CCK (actual) Hasta 50 usuarios simultáneos (portal + internos) 6.3 Seguridad Autenticación interna (equipo CCK): Email + contraseña con hash seguro (bcrypt o equivalente). Soporte para 2FA opcional en fases futuras. Autenticación de clientes (portal): Magic Link — token único por email, con tiempo de expiración configurable (recomendado: 72 horas). No hay gestión de contraseñas para clientes. Control de acceso basado en roles (RBAC): Cada acción en la plataforma verifica los permisos del rol del usuario activo. Los permisos se evalúan en el backend, no solo en el frontend. Aislamiento de datos: Los clientes del portal solo ven datos de su propia empresa. No es posible acceder a datos de otros clientes por error de URL o manipulación de parámetros. Comunicación cifrada: HTTPS obligatorio para todas las comunicaciones. Certificado SSL/TLS válido. Auditoría: Todas las acciones sensibles (generación de documentos, firma, cambios de permisos, eliminaciones) se registran en un log de auditoría inmutable. 6.4 Integraciones y Dependencias Externas Integraciones de CrossCheck Platform Sistema Tipo de Integración Dirección Fase Google Sheets API de Google Sheets — lectura/escritura bidireccional Bidireccional Fase 3 Google Drive Almacenamiento de documentos generados y firmados Escritura Fase 3 Servicio de email Envío de Magic Links, notificaciones, alertas SLA Salida Fase 1 Duitya (plataforma operativa CCK) Sin integración — sistemas independientes N/A N/A Sin Integración con Duitya La plataforma CrossCheck (Duitya) y CrossCheck Platform son sistemas completamente independientes. No se requiere ni se planifica ninguna integración entre ellos. Los e-tickets que originalmente se capturaban via Duitya migrarán al nuevo sistema unificado de tareas. 6.5 Exportación de Datos La plataforma debe garantizar que los datos nunca queden "atrapados". Se requieren las siguientes capacidades de exportación: CRM completo exportable a CSV / Excel (todas las empresas, todos los campos) Tareas exportables a CSV con todos los campos (por empresa, por responsable, por periodo) Documentos generados descargables como PDF Reportes de SLA y cumplimiento exportables a PDF y CSV Datos del portal de cliente exportables por el propio cliente (reporte de progreso) Sección 7 Estrategia de Migración de Datos La migración de datos es inseparable del MVP. El nuevo sistema debe nacer con los datos históricos correctamente estructurados, para que el equipo no tenga que operar en paralelo ni transcribir información manualmente. 7.1 Inventario de Datos a Migrar Fuentes de Datos para Migración Fuente Registros Campos Entidad Destino Prioridad CRM Notion (Base de datos CRM_all.csv) 167 empresas 34 columnas Company + Contact + Deal Crítica Tareas Notion (Tareas_all.csv) 1,073 tareas 22 columnas Task (urgency_type: parametrizacion) Crítica E-Tickets (Solicitudes de Tareas) 129 registros 22 columnas Task (urgency_type: soporte) Alta Google Sheets Pacific (Mantenimiento) 37 subtareas 9 columnas Referencia para validación de estructura Media Google Sheets Pacific (Calidad) ~35 subtareas 9 columnas Referencia para validación de estructura Media 7.2 Mapeo de Campos — CRM Notion → Company Mapeo de Campos CRM Notion a Entidad Company Campo Notion Campo Destino Transformación Clientes (título) Company.nombre Directo Status Company.estado_pipeline Mapeo: Cerrado → Cerrado Ganado, Perdido → Cerrado Perdido, demás estados directo Industrias Company.industria Normalización al enum de 7 valores Mensualidad (COP) Company.mensualidad_COP Directo, preservar valor numérico Implementación (COP) Company.implementacion_COP Directo, null si vacío Email gerencia Contact.email (rol: Gerencia) Crear entidad Contact vinculada Nombre cliente Contact.nombre (rol: Gerencia) Crear entidad Contact vinculada Correo área contable Contact.email (rol: Contable) Crear segunda entidad Contact Datos Embajador Contact (rol: Embajador) Parsear texto libre a campos estructurados Responsable Company.responsable_cck_id Mapear nombre Notion → User.id en nuevo sistema Notas último contacto Activity (interaction) vinculada Crear registro de última interacción 7.3 Mapeo de Campos — Tareas Notion → Task Mapeo de Campos Tareas Notion a Entidad Task Campo Notion Campo Destino Transformación ID tarea (CCK-NNN) Task.cck_id Directo — preservar exactamente Nombres de las tareas Task.titulo Directo Estado Task.estado Sin empezar → Sin empezar, En curso → En curso, Lista → Lista, Archivada → Archivada, En pausa → En pausa Prioridad Task.prioridad Alta/Media/Baja directo; vacío → Baja (valor por defecto para 98% de registros) Fecha límite Task.fecha_limite Directo; null si vacío Responsable Task.assignee_ids Mapear nombres Notion → User.ids 👟 Sales CRM 1 Task.company_id Mapear nombre empresa → Company.id post-migración de CRM Tarea principal Task.parent_task_id Resolver auto-referencias después de migrar todas las tareas Notas Task.descripcion Convertir rich text → texto plano (preservar contenido) urgency_type Task.urgency_type Todas las tareas de Notion → "parametrizacion" por defecto 7.4 Reconciliación de Entidades entre Fuentes El mismo cliente puede aparecer con nombres diferentes en Notion CRM, e-tickets, y Sheets. Se requiere una tabla maestra de reconciliación: Ejemplos de Variantes de Nombres de Clientes Nombre en CRM Notion Nombre en E-Tickets Nombre Normalizado CC Santafé Centro comercial Santa fe CC Santafé Hoteles B3 Sibelius Hotel b3 Sibelius Hoteles B3 Sibelius Club Hatogrande Club Hatogrande Club Hatogrande (coincide) PACIFIC (en Sheets) Pacific Pacific (mapear a empresa en CRM) Estrategia: (1) Crear tabla maestra de empresas desde el CRM de Notion (167 registros, fuente más completa). (2) Normalizar nombres usando fuzzy matching + revisión manual para los 29 clientes únicos de e-tickets. (3) Mapear cada e-ticket y tarea al Company.id correcto. 7.5 Manejo de Huérfanos Definición: Tareas o e-tickets que no pueden vincularse a ninguna empresa activa (descalificada, perdida, o sin nombre reconocible). Cifras: 236 tareas de Notion (22%) no están vinculadas a ningún cliente CRM. Tareas de las 95 empresas "Descalificadas" y 9 "Perdidas" son candidatas a huérfanas. Regla: Marcar como completados con nota de auditoría: "Migrado como completado — registro huérfano de [fuente original]." No se eliminan; se preservan en estado archivado para trazabilidad histórica. 7.6 Orden de Migración Users (5): Crear manualmente los 5 miembros del equipo CCK con sus roles. Companies (167): Migrar desde CRM Notion como fuente principal. Contacts: Extraer desde campos de contacto del CRM, crear entidades vinculadas. Tasks operativas (1,073): Migrar desde Tareas Notion, preservando CCK-NNN. Tasks de soporte (129): Migrar e-tickets con urgency_type = soporte. Relaciones Task ↔ Company: Resolver vínculos usando tabla de reconciliación. Auto-referencias Task ↔ Task: Resolver jerarquías padre/subtarea. Validación: Reconciliación cruzada, marcado de huérfanos, verificación de IDs únicos. Continuación de secuencia CCK-NNN: Los IDs existentes (CCK-15 a CCK-1252+) se preservan exactamente. Los nuevos registros continúan desde el último ID + 1. Los 129 e-tickets reciben IDs en la secuencia al migrar al sistema unificado. Sección 8 Roadmap de Desarrollo — 3 Fases El desarrollo de la CrossCheck Platform se divide en tres fases consecutivas. Cada fase tiene un alcance claramente delimitado, entregables concretos y criterios de aceptación verificables. Las fases no se solapan; la Fase 2 sólo comienza una vez que los entregables de la Fase 1 hayan superado pruebas de aceptación con usuarios internos. Fase 1 Fundación — CRM y Gestión de Tareas Unificada Duración estimada: 10–12 semanas Objetivo: Reemplazar Notion como herramienta operativa central. Al finalizar esta fase, todo el equipo trabaja exclusivamente dentro de la plataforma para crear clientes, gestionar tareas y consultar el historial. Notion pasa a modo solo-lectura y se congela para importación final. Módulos incluidos Módulo Descripción Prioridad Autenticación y Roles Login, gestión de usuarios, permisos por rol (Admin, Técnico, Comercial, Solo-Lectura) Crítica CRM — Clientes CRUD completo de Client con todos los 34 campos del modelo; importación inicial de 167 registros desde Notion Crítica CRM — Contactos Entidad Contact vinculada a Client; múltiples contactos por cliente con roles y canales Alta Gestión de Tareas Entidad Task unificada con urgency_type; vistas Kanban y lista; filtros por tipo, estado, asignado Crítica Migración CRM Script ETL Notion → plataforma; validación de 167 registros; preservación de IDs CCK-NNN Crítica Dashboard operacional Vista principal con contadores de tareas pendientes, vencidas y por asignar; acceso rápido a clientes recientes Alta Notificaciones básicas Alerta en plataforma y correo electrónico para tareas vencidas y asignaciones nuevas Alta Criterios de aceptación de la Fase 1 100 % de los 167 clientes importados sin pérdida de datos; IDs CCK-NNN preservados. Equipo completo crea y completa tareas sin usar Notion durante 2 semanas consecutivas. Tiempo de carga de lista de clientes < 2 s con 500 registros concurrentes. Cero errores de pérdida de datos detectados en auditoría post-migración. Fase 2 Operaciones — Onboarding, Tickets de Soporte y Documentos Duración estimada: 8–10 semanas Objetivo: Centralizar los procesos de onboarding de nuevos clientes (actualmente en Google Sheets Pacific) y la gestión de tickets de soporte (actualmente en el sistema de e-tickets). Al cerrar esta fase, la operación completa de CrossCheck vive en la plataforma. Módulos incluidos Módulo Descripción Prioridad Onboarding — Proyectos Entidad Project con 7 fases; checklist por fase configurable; asignación de responsables Crítica Onboarding — Progreso Tablero visual de fases por proyecto; alertas de bloqueo cuando una fase supera SLA Alta Migración Sheets ETL de filas activas de Pacific Sheets al módulo de proyectos; mapeo de 7 fases Crítica Tickets de Soporte Entidad Ticket con estados (Abierto → En Progreso → Resuelto → Cerrado); prioridad; SLA configurables Crítica Migración E-tickets Importación de los 129 e-tickets existentes; normalización de prioridad; preservación de IDs Crítica Portal de Solicitudes Formulario web embebible para que clientes abran tickets sin acceder a la plataforma interna Alta Gestión de Documentos Adjuntos por cliente y ticket; flujo de firma simplificado (descarga PDF → firma externa → carga) Media Reportes operacionales Dashboard con backlog de tickets, tiempo medio de resolución, tasa de resolución en primer contacto Alta Criterios de aceptación de la Fase 2 Todos los proyectos activos de onboarding migrados y visibles en la plataforma con estado correcto. Los 129 e-tickets migrados con prioridad normalizada y asignaciones confirmadas. Tiempo de resolución promedio de tickets visible en dashboard con datos históricos. Al menos un cliente piloto usa el portal de solicitudes para abrir un ticket real. Fase 3 Inteligencia — Reportes Avanzados, Automatizaciones e Integraciones Duración estimada: 6–8 semanas Objetivo: Añadir capacidad analítica avanzada y reducir la carga operativa manual mediante automatizaciones y conexiones con herramientas externas ya en uso. Esta fase convierte la plataforma en ventaja competitiva, no sólo en sistema de registro. Módulos incluidos Módulo Descripción Prioridad Reportería personalizable Constructor de reportes con filtros, agrupaciones y exportación a Excel/PDF por cualquier entidad Alta Automatizaciones Motor de reglas: "Si ticket sin asignar > 24 h → notificar Admin"; "Si fase de onboarding supera SLA → escalar" Alta API pública REST Endpoints para integraciones externas; autenticación por API key; webhooks de eventos clave Media Integraciones WhatsApp Business (notificaciones salientes); Google Calendar (sincronizar fechas de onboarding) Media Auditoría avanzada Log inmutable de todos los cambios con usuario, timestamp y valor anterior/nuevo Alta Módulo de Contratos Plantillas de contrato parametrizables; generación de PDF; flujo de firma simplificado Media Criterios de aceptación de la Fase 3 Al menos tres reglas de automatización activas y ejecutándose sin intervención manual. API REST documentada (OpenAPI) y consumida por al menos una integración externa. Tiempo de generación de reporte mensual < 30 s con 12 meses de historial. Log de auditoría cubre 100 % de los cambios en entidades críticas (Client, Ticket, Project). Dependencias críticas entre fases La Fase 2 depende de que la estructura de Client de la Fase 1 esté estable, pues Project y Ticket referencian a Client. La Fase 3 depende de que los datos de Fases 1 y 2 estén completos para que los reportes y automatizaciones tengan historial suficiente. No se debe comenzar una fase sin el sign-off formal de la anterior por parte de David Stewart (CEO). Sección 9 Métricas de Éxito El éxito de la CrossCheck Platform se mide en tres dimensiones: eficiencia operacional, calidad del servicio al cliente y adopción interna del equipo. Las métricas de referencia se extraen del análisis de los sistemas actuales y se recolectarán automáticamente desde el día uno de operación en producción. 9.1 Métricas de Eficiencia Operacional Métrica Línea Base (actual) Meta — Fase 1 Meta — Fase 2 Tareas sin asignar (> 7 días) ~95 % (sin campo "asignado") < 20 % < 5 % Tareas sin prioridad 97.6 % (Notion) < 30 % < 5 % Tiempo promedio de cierre de ticket Desconocido (sin tracking) Medido (línea base) < 5 días hábiles Tickets vencidos (SLA) 63 / 129 (48.8 %) < 30 % < 10 % Proyectos de onboarding con fase bloqueada Mantenimiento 74 %, Calidad 57 % Medido < 20 % 9.2 Métricas de Calidad de Servicio Métrica Línea Base Meta — Fase 2 Meta — Fase 3 Concentración de tickets por persona (Asleidy: 67 %) 1 persona atiende > 2/3 Distribución visible Ninguna persona > 40 % Tickets de prioridad Alta sin SLA definido 76 % marcados Alta sin SLA SLA definido para toda Alta Cumplimiento > 90 % Tiempo de respuesta inicial a solicitudes Sin dato Medido < 4 h hábiles Satisfacción interna del equipo (encuesta trimestral) Sin dato Primera encuesta Score ≥ 4 / 5 9.3 Métricas de Adopción Interna Métrica Meta — Fase 1 Meta — Fase 2 % del equipo con sesión activa semanal ≥ 80 % 100 % Registros creados en la plataforma vs. fuera ≥ 90 % dentro 100 % dentro Uso de Notion para operaciones activas Solo lectura archivado Cero acceso operativo Uso de Google Sheets Pacific para onboarding activo En paralelo (Fase 1) Cero acceso operativo Instrumento de medición Todas las métricas deben ser visibles sin consultas manuales. El dashboard principal de la plataforma debe mostrar en tiempo real: tickets abiertos/vencidos, tareas sin asignar y progreso de onboarding por fase. Los reportes de adopción se generan automáticamente el primer lunes de cada mes y se envían a David Stewart (CEO). Sección 10 Apéndices A. Resumen del Análisis de Notion CRM El análisis del export de Notion reveló dos bases de datos principales con los siguientes hallazgos clave: Base de datos: Clientes CCK Dimensión Hallazgo Total de registros 167 clientes activos Rango de IDs CCK-15 a CCK-1252 (secuencia con saltos) Campos totales 34 campos por registro Campos con > 80 % completitud Nombre empresa, ID, sector, ciudad, estado Campos con < 30 % completitud Fecha instalación, coordenadas GPS, tipo de contrato, valor contrato Ciudades más frecuentes Bogotá (62 %), Medellín (14 %), Cali (9 %) Sectores Retail (38 %), Logística (22 %), Educación (15 %), Otros (25 %) Base de datos: Tareas Dimensión Hallazgo Total de registros 1,073 tareas Sin prioridad asignada 97.6 % (1,047 / 1,073) Sin proyecto asociado 95.6 % (1,026 / 1,073) Sin responsable asignado ~60 % (estimado por análisis) Estados encontrados Pendiente, En progreso, Completada, Archivada, Bloqueada Tareas vencidas Sin dato — fecha de vencimiento ausente en > 80 % de registros Fuente: notion_analysis_v2.md — análisis realizado por el equipo CrossCheck sobre export de Notion. B. Resumen del Análisis de Google Sheets Pacific El análisis de la hoja de cálculo Pacific reveló la estructura de onboarding de clientes industriales en 7 fases secuenciales: Fase Nombre % Bloqueados (sin completar) 1 Propuesta comercial 12 % 2 Contrato y firma 28 % 3 Instalación hardware 41 % 4 Configuración software 35 % 5 Capacitación 45 % 6 Calidad / QA 57 % 7 Mantenimiento preventivo 74 % Las fases 6 y 7 (Calidad y Mantenimiento) concentran el mayor porcentaje de proyectos bloqueados, indicando que los procesos post-instalación carecen de seguimiento sistemático. La plataforma resolverá esto con alertas automáticas de SLA por fase. Fuente: sheets_analysis.md — análisis realizado por el equipo CrossCheck. C. Resumen del Análisis de E-Tickets de Soporte Dimensión Hallazgo Total de tickets 129 registros Tickets vencidos 63 (48.8 %) Prioridad Alta asignada 76 % de todos los tickets Prioridad Media / Baja 14 % / 10 % Tickets asignados a Asleidy 67 % (86 / 129) Tickets sin asignar ~8 % (estimado) Estados presentes Abierto, En revisión, Pendiente cliente, Cerrado Rango de fechas Tickets con más de 90 días sin resolución detectados Diagnóstico principal: La inflación de prioridad "Alta" (76 %) indica que el sistema actual no tiene criterios claros de priorización. La concentración en Asleidy representa un riesgo operacional si dicha persona no está disponible. La plataforma implementará una matriz de prioridad 3×3 (impacto × urgencia) y distribución automática según carga. Fuente: solicitudes_analysis.md — análisis realizado por el equipo CrossCheck. D. Glosario de Términos Término Definición en el contexto CrossCheck CCK Abreviación oficial de CrossCheck Colombia. Prefijo de todos los IDs de cliente (CCK-NNN). E-ticket Solicitud de soporte técnico o servicio creada por un cliente o agente. Equivale a "ticket" en la plataforma. Pacific Nombre interno de la hoja de cálculo de Google Sheets usada para gestionar el onboarding de clientes. Onboarding Proceso completo desde la firma del contrato hasta la puesta en marcha del cliente con los sistemas CCK. Urgency Type Discriminador de la entidad Task que clasifica el origen: parametrización, soporte, ad-hoc o interno. SLA Service Level Agreement — acuerdo de nivel de servicio. Define el tiempo máximo para responder y resolver una solicitud según su prioridad. ETL Extract, Transform, Load — proceso de migración de datos desde sistemas origen a la nueva plataforma. RBAC Role-Based Access Control — control de acceso basado en roles; modelo de permisos de la plataforma. Duitya Sistema externo independiente de CrossCheck. No se integra con la plataforma en ninguna de las tres fases. API REST Interfaz de programación basada en el protocolo HTTP, sin estado, usada para conectar la plataforma con sistemas externos en la Fase 3. Dashboard Pantalla principal de la plataforma con indicadores operacionales en tiempo real. Checklist de fase Lista de verificación configurable de tareas obligatorias para aprobar una fase del onboarding. E. Historial de Versiones del Documento Versión Fecha Descripción Autor 0.1 Junio 2026 Borrador inicial — estructura y análisis de sistemas actuales Equipo CrossCheck 1.0 Julio 2026 Documento completo con arquitectura, modelo de datos, roadmap y métricas David Stewart (CEO)