CRM en 25 días

En veinticinco días, una firma de contabilidad de catorce personas pasó de seis sistemas paralelos sin conectar a un CRM propio con modelo relacional, permisos por departamento y tres automatizaciones en producción. Se migraron 2.607 registros maestros e histórico desde un CRM comercial que el equipo había dejado de usar, se levantó por primera vez un pipeline comercial completo de 74 clientes activos, y se cerró el prerrequisito de identidad que bloqueaba cualquier modelo de seguridad.

En las tres semanas siguientes se construyó la capa que faltaba: el comunicado mensual de cumplimiento, que sustituye el trabajo de calendario que Operaciones hacía a mano cada mes —primer envío real, veinticuatro de veinticuatro correos aceptados, veintisiete negocios cubiertos, en 21,9 segundos—, y el sistema documental, que enlazó 605 de 607 carpetas de cliente a su ficha e indexó 4.140 documentos. Las secciones 13 y 21 las detallan; la 22 y la 23 explican qué de todo esto es método reutilizable y qué es específico de esta firma.

También hay una parte incómoda, y este informe la trata con el mismo detalle: el sistema tiene los maestros llenos y las transacciones en cero. Se crearon 76 tareas y ninguna se ha cerrado. Las 1.548 actividades son histórico importado, no registro de trabajo nuevo. El módulo que concentraba el 83 % del valor del proyecto —el cumplimiento contributivo— sigue sin construirse. Y el hallazgo crítico de seguridad detectado el día 5 sigue abierto el día 25.

Los seis hallazgos que gobiernan el resto del informe

1. El problema nunca fue la falta de un CRM. El 83 % del trabajo real de la firma —cumplimiento contributivo, cobros, documentos, reconciliaciones— no estaba modelado en ningún sistema. Comprar o construir un CRM comercial no lo habría resuelto.
2. El sistema anterior no falló técnicamente: fracasó en adopción. 618 cuentas registradas contra 14 tareas. Ese ratio, y no una carencia funcional, es el dato que determinó todo el diseño posterior.
3. La información del cliente estaba multiplicada, no duplicada. 403 nombres únicos normalizados para unos 170 clientes reales; 67 de ellos aparecían en cuatro o más pestañas distintas.
4. Hay una exposición de datos sensibles que exige tratamiento de incidente, no de tarea de proyecto: ~122 contraseñas de portales gubernamentales en texto plano, 9 números de seguridad social completos y 55 cuentas bancarias con su número de ruta, todo bajo una cuenta de correo personal. Reportado el día 5. Sin evidencia de remediación al día 25.
5. El prerrequisito de identidad se resolvió casi del todo. De 13 de 15 personas con correo personal se pasó a 14 de 14 con dominio corporativo. Pero persiste un buzón compartido por tres personas de tres departamentos distintos, y como el CRM resuelve permisos por dirección de correo, ese buzón concede el nivel máximo de acceso a las tres.
6. La decisión de plataforma cambió tres veces en 24 días, y la fecha que la fuerza —el vencimiento de la suscripción del CRM anterior— cae tres días después del cierre de este informe, sin que exista ninguna medición de adopción con la que decidir.

Este documento reconstruye el proyecto completo: diagnóstico, auditoría de datos, diseño, construcción, automatización, pruebas y estado resultante. No es un resumen de entregables; es una memoria con trazabilidad, en la que cada afirmación relevante se puede remontar a una fuente y a una fecha.

Clasificación de la evidencia

Todo el informe usa cuatro marcas, visibles en el margen izquierdo de cada sección y junto a las afirmaciones fuertes:

Fuentes analizadas

Diecisiete fuentes, de cuatro naturalezas distintas. Las de mayor peso son las tres primeras.

Lo que este informe no puede afirmar

Cinco limitaciones condicionan la lectura y se declaran por adelantado. Ninguna se disimula más adelante.

Un despacho de servicios profesionales en Guaynabo, Puerto Rico, que acompaña a pequeñas empresas en tres frentes que se venden juntos pero se ejecutan por separado: constitución y cumplimiento (crear la entidad y mantenerla al día ante Hacienda, el CRIM, el Departamento de Estado y el Fondo del Seguro del Estado), contabilidad y asesoría financiera (reconciliaciones, estados financieros, planillas) y servicios accesorios (gestión de financiamiento y marketing digital).

El modelo de ingresos condiciona todo lo demás

La firma cobra una iguala mensual recurrente, entre 100 y 700 dólares según el paquete, complementada con tarifas por servicio puntual de 150 a 500 dólares por obligación radicada. Eso la convierte en un negocio de suscripción, con una consecuencia de diseño directa: su salud depende de la retención, y la retención depende de que el cliente perciba que sus obligaciones están al día.

De ahí se sigue el criterio que ordena las prioridades del proyecto. Un CRM que gestione bien el embudo comercial pero no sepa qué le vence a cada cliente no ataca la variable que sostiene el negocio. Esta observación, hecha en el diagnóstico, es la que justificó no empezar por lo comercial.

La estructura

Catorce personas en siete departamentos. Dirección aprueba y decide. Operaciones coordina el alta de clientes y la asignación de trabajo. Ventas capta. Contaduría ejecuta el cumplimiento contributivo. Auxiliar contable lleva las reconciliaciones, repartidas casi a tercios entre tres personas. Financiamiento gestiona los casos ante instituciones. Marketing produce contenido para unos 74 clientes.

Un dato del diagnóstico que resultó revelador: cuatro de las quince personas de entonces no aparecían en ninguna hoja operativa. O eran incorporaciones recientes, o su trabajo sencillamente no se registraba en ningún sitio. En una firma de este tamaño, eso no es una anécdota administrativa: es un cuarto de la plantilla trabajando fuera de todo registro.

El modelo comercial, en sus propias palabras

Las actas de reunión describen un embudo concreto: anuncios en redes sociales con llamada a la acción → dos centros de llamadas que agendan una asesoría gratuita → dos cerradores que trabajan el contrato. Tras la firma empieza el onboarding, que exige verificar el estado legal, corporativo y contributivo del cliente, y solicitar credenciales de acceso a los portales gubernamentales y los estados bancarios.

La capacidad declarada en agosto de 2026 era de ocho contratos mensuales en Puerto Rico, con la meta de llegar a veinte mediante expansión a Florida. Esa meta —duplicar y algo más el volumen— es el argumento operativo más fuerte a favor de automatizar: el proceso actual depende de que alguien recuerde cada paso.

El diagnóstico se hizo sobre seis fuentes reales de la operación: el CRM comercial en producción y cinco hojas de cálculo independientes, ninguna conectada con las demás. La conclusión que ordenó el resto del proyecto fue incómoda y clara: el problema no era que faltara un CRM, sino que el grueso del trabajo de la firma no estaba modelado en ninguna parte.

Lo que sí estaba bien hecho

Un diagnóstico que solo enumera defectos suele producir un rediseño desde cero, que es la forma más cara de perder lo que ya funciona. El análisis identificó explícitamente cinco cosas que había que conservar, y se conservaron:

• Once catálogos formalmente definidos en la plantilla existente: tipo y estado de cuenta, fuente y estado de lead, etapa de trato, tipo de servicio, departamento, tipo y estado de actividad. Base sólida: se amplía, no se rehace.
• Un maestro de empleados con departamento. Era la primera vez que la firma tenía una tabla de personas.
• Un primer control de acceso a datos sensibles —una bandera de permiso para ver identificadores fiscales— con su documentación.
• Claves primarias con prefijo en cinco de seis tablas. Eso resolvía de raíz el problema número uno: la ausencia de identificador único de cliente.
• Cero datos sensibles en la plantilla del CRM. Se había mantenido deliberadamente limpia de contraseñas, números de seguridad social y cuentas bancarias. Decisión correcta.

Cómo se toma una decisión hoy, y con qué información

El diagnóstico incluyó una observación que resultó más útil que cualquier cifra: describir el trabajo desde el puesto, no desde el sistema.

Un auxiliar contable, cada mañana

Necesita saber qué clientes le deben estados de cuenta y cuáles tienen una reconciliación atrasada. Abre una hoja de 33 pestañas y lee una columna de texto que dice «Completado 2025 hasta marzo 2026» o «Pendiente nov y dic 2025. Ya solicitado». Es prosa, no un dato: no se puede filtrar, ordenar ni contar.

Dirección

Necesita saber cuánto factura, cuánto cobra y por qué se van los clientes. Sabe que se fue el 48 % de una cartera, pero no por qué, porque el motivo de baja no se captura en ningún sitio.

Contaduría

Necesita saber qué vence esta semana. Eso vivía en la memoria de una persona y en el nombre de una columna.

Esa última frase —«el cumplimiento de 46 clientes vive en la cabeza de una persona»— quedó registrada como riesgo formal de concentración de conocimiento, y es la que mejor explica por qué el proyecto se planteó como externalización de criterio al sistema, no como digitalización de hojas.

El CRM comercial anterior fue el punto de partida de los datos y, a la vez, la mejor evidencia de qué evitar. Conviene separar las dos cosas, porque es fácil concluir que la herramienta era mala cuando el problema era otro.

Volumetría real

La primera etapa de la auditoría midió el contenido completo por consulta directa, no por estimación. El resultado dibuja un sistema con mucho archivo y muy poca gestión.

Cinco campos que parecían fiables y no lo eran

Este es el aporte más reutilizable de la auditoría: identificar campos que un plan de migración habría tomado por buenos.

Frente a todo eso, el campo más fiable resultó ser el menos formal: las etiquetas manuales que el propio equipo había ido poniendo —«revisar teléfono contaminado», «revisar email interno», «inactivo», «contrato cancelado»—. La firma ya había hecho parte del trabajo de detección; lo que faltaba era actuar sobre él. Aun así, el 54,5 % de las cuentas no tenía ninguna etiqueta.

Por qué el equipo lo había abandonado

La evaluación formal comparó ambas plataformas en costo, ajuste al negocio y riesgo. El resultado no fue unánime: el CRM comercial ganaba con claridad en facturación, reportería y campañas; la alternativa ganaba en calendario contributivo, checklist documental, propiedad del dato y uso móvil.

El desempate no fue funcional sino de adopción. Con una sola licencia comprada para quince personas que necesitaban acceso, el sistema quedó reducido a un archivador al que entraba una persona. Ese es el origen real del 618-contra-14, y explica también por qué en la reunión del 7 de agosto se rechazó comprar más licencias: unos 500 dólares mensuales adicionales por un software que, en palabras de la propia Dirección, se estaba usando solo para almacenar archivos.

La auditoría se planteó con cinco reglas que no se rompieron en ningún momento, y que en retrospectiva fueron lo que hizo el proceso defendible:

1. El sistema en producción nunca se modifica. Todo el análisis sobre él es de solo lectura. La limpieza ocurre únicamente en la copia documental.
2. No se elimina nada sin justificación y evidencia.
3. Nunca se asume: se pregunta.
4. Se prioriza conservar historial completo, no solo cuentas activas. Decisión explícita del cliente.
5. Cada hallazgo requiere aprobación explícita antes de ejecutarse, uno por uno.

Dos hallazgos que cambiaron el método de trabajo

Los duplicados no se resuelven con el dato, se resuelven con el contenido. Dos pares marcados como duplicados por coincidencia de identificador fiscal y teléfono resultaron tener, cada carpeta, decenas de documentos genuinos y distintos —56 en un caso, y en otro un expediente legal completo—. Muy por encima de los dos o tres archivos que sugería el hallazgo original. Fusionarlos por el dato habría destruido documentación real. Un tercer par, con nombres casi espejo, resultó ser dos empresas legalmente distintas: registros de comerciante y direcciones diferentes.

Las carpetas de cliente no contienen solo información del negocio. Al fusionar, apareció el patrón: expedientes que mezclan documentos de identidad y financieros personales de terceros —licencias de conducir, informes de crédito— con la documentación corporativa. Se registró como advertencia permanente para cualquier trabajo futuro sobre esos expedientes.

El callejón sin salida, y cómo se salió

El encargo de Operaciones era concreto: crear un trato por cada cliente activo, leyendo su contrato. El importe del contrato solo existía dentro de un PDF. Se intentó por cuatro vías y las cuatro fallaron:

• La API del CRM expone metadatos de adjuntos pero no permite descargarlos.
• Adivinar la URL de descarga: se probaron una docena de variantes. Todas devolvían HTML de error. Una de ellas devolvía 200 con 133 KB —el armazón de la aplicación web— lo que parece un éxito y no lo es. De ahí salió una regla que se aplicó desde entonces: verificar siempre que los primeros bytes sean los de un PDF, nunca fiarse del código de estado.
• Leer el DOM del adjunto: la ficha vive en iframes anidados y la URL se construye en JavaScript al hacer clic. No hay enlace que recuperar.
• Las notas del CRM sí se leen por API y son ricas —contienen la entrevista inicial completa— pero recogen las finanzas del cliente, no la tarifa que cobra la firma. Usarlas como importe habría sido un error grave. Además contienen datos personales en texto plano.

La salida la dio Operaciones en una frase: cada cliente tiene su carpeta en el repositorio documental, con el contrato dentro. El conector de ese repositorio extrae el texto de los PDF directamente, incluida la capa de OCR de los escaneos legibles. Lo que llevaba dos días bloqueado se resolvió cambiando de fuente, no de técnica.

El contrato como fuente estructurada

Una vez accesibles, los contratos resultaron tener estructura predecible y reutilizable: una cláusula de honorarios con el importe mensual y el mes de inicio del débito, una fórmula de otorgamiento con la fecha de firma, y una penúltima página de autorización de débito directo que repite el monto —lo que permitió resolver los casos en que la cláusula era ilegible—. Duración típica de un año. El importe es mensual, no total de contrato: confundirlos habría multiplicado por doce todo el pipeline.

Seis contratos eran escaneos sin capa de texto y hubo que leerlos a pantalla, página a página. Uno resultó firmado pero sin importe pactado en ninguna parte, y otro estaba archivado bajo el cliente equivocado. Ambos casos se registraron como excepción en vez de forzar un número.

Esta es la sección que ninguna extracción de datos podía producir. Tres actas de reunión —del 7 y el 26 de agosto y del 31— describen cómo funciona la operación de verdad, y en varios puntos contradicen lo que el sistema modela.

El proceso de onboarding, tal como se ejecuta

Tras la firma del contrato, y en este orden: reunión de traspaso entre ventas y operaciones —explícitamente, para que el cliente no tenga que repetir lo que ya contó—, entrega de un kit de bienvenida, verificación del estado legal, corporativo y contributivo, evaluación de deudas con Hacienda y, si las hay, asignación de un especialista en planes de pago. Se solicitan credenciales de acceso a los portales gubernamentales y los estados bancarios.

Sobre las credenciales apareció un matiz operativo relevante: ante la reticencia de algunos clientes a compartirlas, se recurre a formularios legales de representación autorizados por las propias agencias, y se explora el uso de plataformas que permitan ver saldos sin acceso directo. Es decir: la firma ya había identificado por su cuenta que acumular contraseñas de clientes es un problema, y estaba buscando alternativas. Ese contexto importa para leer el hallazgo de seguridad de la sección 12 — no es negligencia despreocupada, es una práctica heredada que ya incomodaba internamente.

Dos mecanismos de control que el equipo diseñó por su cuenta

Semáforo de salud del cliente

Un indicador de estado de la información de cada cliente, para saber de un vistazo si el expediente está completo. Es, funcionalmente, lo mismo que el diseño llamaba «perfil fiscal» — llegaron a la misma necesidad desde el lado operativo.

SLA por etapa de onboarding

Tiempos máximos de ejecución en cada etapa, con un límite de 5 días para la etapa inicial. Es la primera vez que aparece un compromiso temporal interno explícito, y es un requisito que el sistema construido todavía no soporta: no hay campo de fecha de entrada en etapa ni cálculo de días transcurridos.

Lo que la operación necesita y el sistema aún no da

La brecha entre el proceso diseñado y el proceso real

El diagnóstico había mapeado diez procesos y dónde vivía cada uno. Vale la pena mirar esa tabla junto a lo que dicen las actas, porque la diferencia es instructiva: el sistema modelaba el trabajo por objeto —cuenta, trato, tarea— y la operación lo vive por etapa y por persona responsable. Un auxiliar contable no piensa «tabla de reconciliaciones»; piensa «qué clientes me deben estados de cuenta esta semana».

Ese desajuste explica, como hipótesis razonable, parte de la falta de adopción observada: una aplicación organizada por entidades obliga a traducir mentalmente antes de poder usarla. El propio diseño lo había anticipado al proponer «Mi Día» como pantalla de inicio y vistas por defecto distintas para cada rol — pero esas vistas están entre lo que no se construyó.

Quince decisiones estructurales, cada una trazable a un hallazgo concreto. La última columna es la parte honesta: qué se puede medir hoy del resultado.

El diseño completo comprendía 25 tablas en 7 módulos, 36 vistas, 24 automatizaciones, 7 roles y 24 indicadores, con una implantación en 5 fases a lo largo de 22 semanas y un prerrequisito no negociable. Lo que se construyó son 7 tablas. Ese recorte fue una decisión explícita del cliente el 15 de agosto, no una desviación, y merece explicarse con precisión porque es el hecho estructural que condiciona todo el estado actual.

Los siete módulos del diseño

Por qué se recortó

Al abrir el entorno el 15 de agosto apareció un hecho que reordenó el plan: la aplicación ya existía, con seis tablas cargadas y un libro de datos propio de ocho pestañas. No era el esquema de 25 tablas: era una plantilla de CRM que alguien había desplegado antes. Había dos diseños vivos y distintos.

La decisión del cliente fue cargar contra la plantilla existente. Es una decisión defendible: entregaba un sistema utilizable en días en lugar de semanas, y aprovechaba trabajo ya hecho. Pero tiene un costo que este informe debe nombrar sin rodeos — la plantilla cubre el módulo comercial, que era precisamente el 17 % del trabajo real. El diagnóstico había concluido que migrar primero lo que ya funcionaba, antes de resolver lo que no existía, era invertir el orden del riesgo. El recorte hizo exactamente eso.

El orden que el roadmap proponía, y que no se siguió

Las cinco fases eran secuenciales por diseño, con hitos de control que funcionaban como puertas: no se abre una fase sin cerrar la anterior. El hito 1, al final de la semana 4, era «≥80 % de los usuarios registra al menos una actividad semanal durante dos semanas seguidas», con una instrucción explícita: si no se cumple, no avanzar; el problema es de adopción, no de funcionalidad.

A la fecha de cierre no se puede evaluar ese hito porque nadie mide la actividad. Y el proyecto avanzó igualmente hacia automatizaciones de captación, que corresponden a fases posteriores. Es la desviación de proceso más relevante del proyecto y conviene registrarla como tal.

Una inconsistencia en el propio documento de diseño

El roadmap arranca el 11 de agosto de 2026 y dura 22 semanas, lo que lleva su cierre a enero de 2027. Sin embargo fija la decisión sobre el sistema anterior en «julio de 2026», una fecha ya pasada en el momento de escribirse. La fecha que manda de verdad es otra: el vencimiento de la suscripción, el 4 de septiembre de 2026 — tres días después del cierre de este informe. Se señala porque un plan cuyo hito de decisión es anterior a su propio inicio no puede ejecutarse tal como está escrito.

El sistema es una aplicación no-code sobre un único libro de hojas de cálculo. Siete tablas cargadas, dos pestañas más que existen como catálogo y leyenda pero no están cargadas como tablas — un detalle con consecuencias que se explica más abajo.

Estado de los datos

Cinco decisiones de modelo que definen el sistema

Claves con prefijo, propias, que nunca se reutilizan

Cuentas y contactos usan claves secuenciales legibles; tratos y tareas usan identificadores generados. La mezcla es deliberada pero tiene un coste: las tareas muestran su hash en vez de su título en cualquier referencia, porque la clave está marcada también como etiqueta. Defecto conocido, corrección de un clic, no aplicada.

El responsable es una referencia, no un texto

Fue posible convertirlo sin riesgo porque las cuatro columnas estaban totalmente vacías — se verificó leyendo la hoja antes de tocar nada, no se asumió. El efecto secundario valioso: cada ficha de empleado lista automáticamente su carga de trabajo en las cuatro tablas.

Servicios como selección múltiple

Convertidos en tres tablas para que un cliente pueda llevar contabilidad y marketing a la vez. Se verificó antes que las columnas estaban vacías en 139 leads y 616 cuentas. El catálogo conserva un valor «todos los servicios» que el diseño recomendaba eliminar por romper el modelo relacional — sigue ahí.

Una referencia apunta a una sola tabla

La actividad puede relacionarse con una cuenta o con una tarea, pero el enumerado ofrece también contacto, lead y trato — tres opciones que no seleccionan nada. Es una limitación asumida conscientemente para no multiplicar columnas, y está documentada como tal.

Los catálogos no están cargados como tabla

La pestaña de catálogos existe y está poblada, pero la aplicación no la lee: los valores están escritos a mano dentro de la definición de cada columna. Editar el catálogo no cambia nada por sí solo. Existe un procedimiento verificado para propagarlo —validación de datos en la hoja y regeneración del esquema— pero no se ha aplicado de forma general.

El inventario completo. La distinción entre operativo, parcial y no construido se apoya en medición directa, no en la intención de diseño.

Esta sección va aparte y no dentro de arquitectura por una razón de énfasis: contiene el único hallazgo del proyecto con consecuencias legales potenciales, y el mecanismo que más iteraciones consumió.

El prerrequisito de identidad: de bloqueante a casi resuelto

El diseño lo llamaba «bloqueante absoluto», y con razón: la aplicación identifica a cada persona por su dirección de correo, así que toda la seguridad descansa sobre ese único dato. El punto de partida era malo — 13 de 15 personas con correo personal, dos pares compartiendo buzón y una persona sin correo registrado. En esas condiciones no se puede saber quién tocó un registro, y un empleado que se va conserva el acceso porque la cuenta es suya.

Es el avance más limpio del proyecto y no lo produjo la tecnología, sino la organización:

Los dos pares originales están separados y la persona sin correo ya lo tiene. Pero apareció una configuración nueva que anula parte del avance: un buzón operativo está asignado a tres personas de tres departamentos distintos — Operaciones, Financiamiento y Contaduría. Como los permisos se resuelven por dirección de correo, quien entre por ahí obtiene el nivel de acceso más alto de las tres, independientemente de lo que diga su departamento. Inferencia

Y hay un segundo efecto, más sutil: la bandera de «puede ver el identificador fiscal» está en «No» para el registro de Operaciones y en «Sí» para los otros dos. Con tres filas compartiendo correo, el resultado de la consulta de permiso es indeterminado.

La matriz de permisos

Verificada leyendo directamente la definición de las siete tablas el 1 de septiembre de 2026. El predicado privilegiado es el mismo en todas: pertenecer a Dirección u Operaciones según el maestro de personas.

IFS(
  IN(USEREMAIL(), SELECT(Usuarios[Email_Workspace],
      OR(STARTSWITH([Departamento],"Direcci"), [Departamento]="Operaciones"))), "ALL_CHANGES",
  IN(USEREMAIL(), SELECT(Usuarios[Email_Workspace], [Departamento]="Ventas")), "ADDS_ONLY",
  TRUE, "READ_ONLY")

Dos virtudes de este diseño merecen destacarse. Se administra desde la hoja, no desde el editor: dar permiso a alguien nuevo es escribir su departamento en el maestro de personas; nadie toca una expresión. Y falla en seguro: quien no aparezca en el maestro cae en solo lectura por defecto.

El predicado usa una comparación por prefijo en vez de igualdad exacta para no depender de teclear una tilde correctamente por automatización. Es un detalle menor que evitó una clase entera de fallo silencioso.

Dos consecuencias operativas del modelo elegido

• Nadie fuera de Dirección y Operaciones puede cerrar una tarea. Con permiso de solo alta, un auxiliar contable puede crear una tarea pero no marcarla como completada. Esto no es un defecto de implementación —es exactamente lo que se pidió— pero es una hipótesis razonable sobre por qué hay 76 tareas y ninguna cerrada. Inferencia
• Quien anota una actividad no puede corregirla. Ni siquiera la propia, ni un error de tecleo. Solo tres personas pueden arreglarlo.

El hallazgo crítico, y su estado

Durante el proyecto se verificó además que la exposición no se limitaba a esos archivos: aparecía también dentro del sistema origen —decenas de notas con credenciales bancarias y de portales, en un tercio de las cuentas activas— y dentro de contratos firmados, cuya página de autorización de débito recoge número de cuenta, ruta e identificador fiscal en claro.

Y ocurrió algo que conviene registrar sin adornos, porque es la lección más incómoda del proyecto: la migración replicó parte del problema. Al construir la primera versión del archivo de carga se copió literalmente un campo de texto libre del origen, y con él llegaron datos personales a una hoja compartida — pese a que la columna explícitamente sensible se había dejado vacía a propósito.

Un residuo de esa replicación sigue en el sistema: en la importación de 1.547 notas históricas se redactaron con éxito todas las credenciales de acceso —se verificó que ninguna sobrevivió—, pero la redacción no cubría otros formatos, y quedaron identificadores personales y fiscales en texto plano en una veintena de filas. Como no hay filtros de seguridad por fila en ninguna tabla, esas filas se descargan al dispositivo de cualquier persona con acceso.

Finalmente, y por decisión explícita del cliente tras advertencia y tres alternativas ofrecidas, el maestro de personas incluye una columna de contraseña de correo en texto plano. La decisión está documentada como tal.

La automatización se reparte entre dos plataformas por una razón de límites: los bots internos de la aplicación resuelven bien lo que ocurre dentro del CRM, y un orquestador externo resuelve lo que cruza la frontera —formularios web, correo saliente, repositorios documentales—.

La cadena de captación: tres piezas en producción

Tres decisiones de ingeniería que valen más que los flujos

El flujo de bienvenida escucha la tabla destino, no el formulario

Podría haberse encadenado al primero. Al colgarlo de la tabla de leads cubre también las altas manuales y las conversiones, y sobrevive a cualquier cambio en el formulario. Cuesta lo mismo y cubre tres orígenes en vez de uno.

La clave del lead es determinista y no numérica

Se deriva de la marca temporal codificada en base 36, con un prefijo alfabético. Determinista para que un reproceso no duplique; no numérica a propósito, porque una clave de solo dígitos la guardaría la hoja como número y rompería la referencia.

Los campos obligatorios se relajan solo para el formulario

La conversión automática fallaba porque la tabla destino exigía siete campos que el bot no puede conocer. En vez de quitar la obligatoriedad —lo que habría degradado la calidad del alta manual— se condicionó a que el campo sea obligatorio únicamente cuando se está rellenando un formulario. La persona sigue teniendo que completarlos; el bot puede escribir sin ellos.

El comunicado mensual de cumplimiento

Cada mes, Operaciones escribía uno a uno a los clientes activos pidiéndoles las ventas del mes anterior —totales, exentas y tributables—, las compras y los estados bancarios, para poder radicar su planilla mensual del impuesto sobre ventas. Era trabajo de calendario, idéntico mes tras mes, y el coste de olvidarse lo paga el cliente en forma de recargo.

El flujo entró en producción el 9 de septiembre. La primera corrida real se lanzó a mano —el día 9 caía fuera del calendario y el disparo automático del día 10 habría enviado el texto de recordatorio sin que existiera una petición previa—. El resultado está medido, no estimado: veinticuatro de veinticuatro correos aceptados por el servidor con respuesta 250 OK, cero rechazos, cero errores, veintisiete negocios cubiertos, en 21,9 segundos.

Cinco decisiones que valen más que el flujo

Se agrupa por dueño, no se deduplica por correo

Al preparar los datos apareció algo que ninguna especificación recogía: hay direcciones de correo que pertenecen a varios negocios del mismo dueño —una a tres, otra a dos—. Deduplicar por correo, que es el reflejo natural, habría enviado un solo mensaje nombrando un solo negocio y habría callado en silencio las obligaciones de los demás. La solución fue agrupar por correo y nombrar todos los negocios de esa persona en el mismo mensaje. Verificado con datos reales: 27 tareas → 27 negocios cubiertos → 24 correos. Queda como regla para cualquier automatización futura que escriba a clientes.

El asunto cambia en cada recordatorio, a propósito

Los clientes de correo agrupan por asunto. Cinco recordatorios con el mismo asunto caen en un único hilo colapsado y el cliente puede no ver los nuevos; además leen como copia y pega. La cuenta atrás en el asunto —«Quedan 4 días», «Mañana vence», «ÚLTIMO DÍA»— resuelve las dos cosas a la vez. Hay una comprobación automática que falla si dos de los siete asuntos coinciden.

El mes se calcula solo: nadie edita el correo nunca

No hay ningún nombre de mes escrito a mano en el flujo, ni en el asunto, ni en el cuerpo, ni en la fecha límite que se reabre. Todo se deriva de la fecha de la corrida en la zona horaria de la firma. Verificado sobre doce meses consecutivos, incluido el salto de año: en enero dice «diciembre» con el año correcto.

La fecha interna de radicación no sale en el correo

El plazo legal real es posterior al que se le pide al cliente. La plantilla antigua de la firma lo mencionaba; Dirección ordenó quitarlo —el cliente solo ve el plazo de la firma—. Se conservó la frase que pide anticipación sin revelar la fecha. Hay una comprobación automática que falla si alguien reintroduce el dato interno: la decisión de negocio quedó convertida en una prueba, no en una nota que se olvida.

Una sola señal de salida

El cliente deja de recibir recordatorios en el momento en que Operaciones marca su tarea como completada o cancelada en el CRM. No hay una segunda lista que mantener, ni un «dar de baja» que alguien tenga que recordar. El flujo lee el mismo sitio donde el equipo ya trabaja.

Indexación documental: doce mil archivos que nadie podía encontrar

El repositorio documental de la firma tiene 607 carpetas de cliente con más de 12.492 archivos y unos 12,8 GB. Esa cifra es un piso, no un total: al contar por lotes, once de cuarenta y un lotes se truncaron en el límite de mil de la API, así que el número real es mayor. Las carpetas son un volcado plano —documentos legales y contables mezclados con material de marketing— sin ninguna taxonomía. Encontrar el contrato de un cliente era una búsqueda a ojo.

La trampa: el código de seis dígitos no es único. Dos clientes distintos pueden compartirlo, porque sus identificadores difieren en dígitos intermedios que el nombre de la carpeta no conserva. En la corrida real aparecieron 14 colisiones, que afectaban a 27 carpetas. Se resolvieron con un desempate por similitud de nombre y un umbral declarado de antemano —gana quien supere 0,60 y aventaje al segundo en 0,30; si no, revisión humana—. Las veintisiete dieron coincidencia perfecta.

Dos cautelas quedaron documentadas junto al sistema. La columna nueva se añadió al final de la tabla a propósito: reordenar columnas rompe la aplicación en silencio. Y el flujo de indexado sobrescribe el rango completo al reejecutarse, así que cualquier corrección manual de tipo hecha desde la aplicación se perdería; antes de volver a correrlo hay que convertirlo en sincronización incremental. Está anotado como pendiente, no descubierto tarde.

El inventario real de la plataforma de automatización

Los tres flujos huérfanos que la primera edición de este informe señalaba ya no están activos en la instancia: quedaron archivados. Este es el estado consultado directamente, no tomado de notas:

Las que siguen sin existir

De las veinticuatro automatizaciones que especificaba el diseño original, el comunicado mensual cubre ahora una parte del ciclo de cumplimiento —la petición de información al cliente y la reapertura de la tarea— construida en el orquestador externo en vez de como bot interno. Las de mayor impacto declarado siguen en el papel:

El diseño incluía además un criterio de higiene que conviene conservar para cuando se construyan: todas las alertas diarias se agrupan en un único correo por persona, y la escalación a Dirección solo ocurre a los tres días. Un sistema que manda quince correos sueltos entrena al usuario a ignorarlos.

Higiene de la plataforma de automatización

Una auditoría de la instancia de automatización arrojó 22 hallazgos: ninguno crítico, seis medios. Los dos relevantes para el estado actual:

• Las credenciales colgaban de una cuenta personal y la instancia corría en una máquina local. Ambas cosas se resolvieron migrando a una instancia en la nube propiedad de la empresa, con las credenciales rehechas a nombre corporativo. Resuelto
• Ningún flujo tiene manejo de error. Si un nodo falla, el flujo se detiene sin alerta ni registro útil. En automatizaciones desatendidas el síntoma es «dejó de funcionar» sin rastro. El mecanismo se validó de extremo a extremo en la instancia local anterior —con dos condiciones que no son obvias: el manejador debe estar activo o no se invoca, y solo se dispara en ejecuciones de producción, nunca en las manuales del editor—, pero no se trasladó a la instancia en la nube. Sigue siendo la corrección de mejor relación esfuerzo/beneficio de todo el inventario. Pendiente

Tres posiciones estratégicas en veinticuatro días

Merece registro explícito porque es el patrón más instructivo del proyecto:

1. 7 de agosto — consolidar en el sistema comercial existente, rechazar la migración y las licencias adicionales.
2. 11 de agosto — modelo híbrido por etapas: el sistema nuevo asume la operación, el anterior conserva facturación e histórico hasta el vencimiento.
3. 31 de agosto — desarrollar un CRM propio, sin depender de herramientas externas, para mejorar la retención.

No son contradictorias en el fondo —las tres reaccionan al mismo problema de coste y adopción— pero sí implican planes de trabajo distintos, y la tercera se tomó sin que existiera medición de la segunda. La posición vigente al cierre es la del 31 de agosto, por ser la más reciente y la de mayor autoridad.

Un patrón atraviesa casi todos: el sistema no dio error. Devolvió éxito, o no dijo nada, y el problema apareció días después en forma de datos que faltaban. Esa es la clase de fallo que la validación automática no detecta y que solo encuentra una verificación deliberada contra el estado real.

Resultados demostrados

Respaldados por medición directa contra los sistemas.

• 2.607 registros maestros e histórico migrados con integridad verificada — 616 cuentas, 231 leads, 138 contactos, 1.548 actividades, 74 tratos. Cero referencias rotas en el cruce documental, cero duplicados en la clave principal, cero diferencias en la auditoría de la importación masiva contra su archivo origen.
• Un pipeline comercial donde no había ninguno. De 2 oportunidades a 74 tratos con etapa. Es la primera vez que la firma puede responder «en qué estado está cada cliente activo» sin abrir un contrato en PDF.
• Honorarios contractuales registrados por primera vez en un sistema: 45 contratos leídos, con un total de importes registrados de $14.936,99 mensuales. Es la suma de lo que consta en el sistema, no el ingreso de la firma — 29 tratos siguen sin importe.
• Cinco automatizaciones en producción, probadas de extremo a extremo. Tres cubren la cadena completa de captación —formulario web, alta en el CRM, correo de bienvenida con documento adjunto y conversión a cuenta y contacto—; una sustituye el trabajo de calendario del ciclo mensual de cumplimiento; y dos, reejecutables bajo demanda, sostienen el sistema documental.
• El primer envío real del comunicado mensual: 24 de 24 correos aceptados por el servidor, 0 rechazos, 0 errores, 27 negocios cubiertos, 21,9 segundos. Es el único resultado del proyecto con métrica de entrega completa.
• 605 de 607 carpetas documentales enlazadas a su ficha de cliente y 4.140 documentos indexados, con 0 cuentas duplicadas y 0 huérfanos. Las 2 carpetas sin enlazar y el 70 % de documentos sin clasificar por tipo se reportan como pendientes, no como logro parcial.
• El prerrequisito de identidad, resuelto en un 90 %. De 2 de 15 personas con correo corporativo a 14 de 14. Es la condición sin la cual ningún modelo de seguridad tiene sentido.
• Un modelo de permisos verificado y administrable sin conocimientos técnicos. Dar acceso a alguien nuevo es escribir su departamento en una hoja.
• Infraestructura de automatización bajo control de la empresa, migrada desde una máquina local y una cuenta personal.
• Dos fallos silenciosos detectados y corregidos antes de causar daño: el contador desincronizado que habría perdido leads reales, y la referencia rota que habría impedido el envío del primer correo.

Beneficios operativos esperados, sin medición formal

Razonablemente asociados a lo construido, pero todavía no medidos. Se presentan como expectativa, no como resultado. Inferencia

• Eliminación del re-tecleo en el alta de leads procedentes del formulario web.
• Reducción del tiempo hasta el primer contacto con un lead, de indeterminado a un minuto.
• Menor riesgo de pérdida de información al existir una clave única y trazable por cliente.
• Posibilidad de responder preguntas de gestión —cartera activa, estado del pipeline, carga por persona— que antes exigían contar a mano, siempre que los campos correspondientes se rellenen.

Beneficios potenciales, no reclamables hoy

Oportunidades reales que dependen de trabajo aún no hecho. Enumerarlas como logros sería incorrecto.

• La eliminación de 696 marcados manuales al año depende del módulo de cumplimiento, que no existe.
• La reducción del riesgo de multa al cliente depende de las alertas de vencimiento, que no existen.
• El análisis de la fuga del 48 % depende del motivo de baja estructurado, que no existe.
• El ahorro de licenciamiento estimado en unos 8.500 dólares anuales procede de una comparación de precios de lista hecha por terceros, sujeta a confirmación con cada proveedor, y depende de una decisión que aún no se ha tomado.

El registro original identificaba catorce riesgos. Tres semanas después, el mapa ha cambiado menos de lo esperado en lo importante y más de lo esperado en lo estructural.

Riesgos nuevos, surgidos durante el proyecto

En veinticinco días se sustituyó el andamiaje de datos de una firma completa: de 403 nombres dispersos a 616 cuentas con clave única, de dos oportunidades a un pipeline de 74 tratos, de trece correos personales a catorce corporativos, de cero automatizaciones a tres en producción. Todo verificado contra los sistemas, no contra la intención.

Pero la conclusión que más vale la pena conservar es de método, no de resultado. El diagnóstico acertó en lo que importaba y el proyecto se desvió de él en el punto exacto que el propio diagnóstico había señalado como peligroso. El análisis decía que migrar primero el 17 % que ya funcionaba, antes de resolver el 83 % que no existía, era invertir el orden del riesgo. Eso es lo que se hizo, por una razón razonable —había una aplicación ya montada— y con un resultado predecible: un sistema técnicamente sólido que resuelve el problema que la firma no tenía.

El segundo aprendizaje es sobre la naturaleza del fallo en estos entornos. Ocho de los nueve incidentes registrados fueron silenciosos: validaciones que pasaban sobre configuraciones rotas, ejecuciones exitosas que escribían campos vacíos, lecturas truncadas sin aviso, contadores desincronizados que habrían perdido leads reales. Ninguno lo habría detectado una comprobación previa. Todos se encontraron releyendo el estado real después de actuar. En herramientas no-code y de bajo código, el mensaje de respuesta no es evidencia de nada.

El tercero es el que ya sabía el diagnóstico y el proyecto volvió a demostrar en pequeño: el panel interino que se construyó con siete pestañas, tres reglas y una rutina diaria de diez minutos tiene todos sus contadores en cero. Se hizo bien y no se usó. Es el mismo fracaso que el sistema anterior —618 cuentas contra 14 tareas— reproducido a escala reducida y en tres semanas. Construir la herramienta es la parte barata.

Al cierre, la firma tiene cimientos que antes no tenía y una decisión de plataforma que vence en tres días sin el dato que debía sustentarla. Lo primero es un logro real. Lo segundo es el trabajo que sigue.

Las secciones anteriores cuentan el proceso. Esta responde a una pregunta distinta y más simple: ¿qué hay, exactamente, después de cuarenta y dos días? Está ordenado por naturaleza del entregable, no por cronología, y cada línea lleva el estado que se verificó, no el que se esperaba.

1 · El sistema operativo del negocio

2 · Los datos

3 · Las automatizaciones

Detalladas en la sección 13. En resumen: tres flujos activos en producción —captación, bienvenida y comunicado mensual de cumplimiento—, dos reejecutables bajo demanda para el sistema documental, y un bot interno de conversión de lead a cuenta y contacto. Todos probados de extremo a extremo contra datos reales antes de activarse, y todos con el mismo procedimiento de prueba: envío desactivado, ejecución manual, lectura del resultado por la API.

4 · Las piezas de comunicación con el cliente

5 · Los agentes y el utillaje

6 · Los documentos de conocimiento

Nada de lo anterior salió de una metodología elegida de antemano. Salió de un orden de trabajo que se fue imponiendo porque saltárselo costaba caro, y que al mirarlo desde el final resulta bastante estable. Esta sección lo enuncia para que sea auditable y repetible, no para presentarlo como marco propietario.

Las siete fases y lo que produce cada una

1 · Escuchar la operación antes de mirar el software

Reuniones, actas y el trabajo real, no el organigrama. En este proyecto reveló el hallazgo que gobierna todo lo demás: el 83 % del trabajo de la firma no estaba modelado en ningún sistema, así que ninguna decisión de plataforma habría resuelto nada. Produce: el mapa del trabajo real y el ratio de adopción del sistema que ya existe.

2 · Auditar el dato, no el sistema

La pregunta no es «¿qué hace la herramienta?» sino «¿cuánto de lo que hay dentro es verdad?». Aquí apareció que cinco campos que parecían fiables no lo eran, que 403 nombres correspondían a unos 170 clientes reales, y la exposición de datos sensibles. Produce: la volumetría real, la lista de campos en los que no se puede confiar y los hallazgos de seguridad.

3 · Recortar el alcance contra la realidad

El diseño pedía 25 tablas; se construyeron 7. No por falta de tiempo, sino porque al descubrir lo que ya existía, cargar contra ello costaba una fracción y entregaba antes. Recortar es una decisión de ingeniería, no una concesión. Produce: el alcance firmado y la lista explícita de lo que queda fuera.

4 · Construir el modelo relacional primero

Antes que ninguna pantalla. Referencias reales entre tablas, claves deterministas, sin borrado en cascada. Cambiar el modelo después de tener datos dentro es lo más caro que hay. Produce: el modelo, los archivos de carga y la auditoría de integridad de la migración.

5 · Resolver identidad y permisos antes que funciones

La seguridad por fila se resuelve por dirección de correo. Mientras trece de quince personas usaban correo personal y dos pares compartían buzón, cualquier modelo de permisos era decorativo. Se declaró bloqueante y se resolvió antes de seguir. Produce: la matriz de permisos y el inventario de identidades.

6 · Automatizar el borde, no el centro

Primero lo que cruza la frontera de la organización —formularios, correo saliente, repositorios— porque ahí el trabajo manual es repetitivo, medible y no tiene excepciones. El centro del proceso, donde viven las excepciones y el criterio profesional, se automatiza después o no se automatiza. Produce: los flujos, sus bancos de prueba y el procedimiento de activación.

7 · Medir, y decir lo que no se puede afirmar

Se consultan los sistemas vivos y se separan tres cosas que casi siempre se mezclan: lo medido, lo inferido razonablemente y lo meramente posible. Este informe usa esa etiqueta en el margen de cada sección. Produce: la memoria del proyecto — el documento que está leyendo.

Las cinco reglas que no se negocian

1. Nada se da por cierto sin leerlo del sistema. El código de las carpetas documentales parecía el número de cuenta; era el identificador interno del CRM de origen. Se verificó por consulta directa en cuatro casos antes de construir nada encima. Un supuesto razonable habría dejado 607 carpetas mal enlazadas.
2. Se verifica releyendo el estado, no el mensaje de respuesta. La plataforma devolvió errores en operaciones que sí se habían aplicado. Un reintento a ciegas ya generó un flujo duplicado. La única fuente de verdad es volver a leer.
3. Se prueba contra la librería real, nunca contra un doble escrito a mano. Un banco de pruebas que imita una dependencia da confianza falsa: pasa sus comprobaciones mientras el fallo real sigue ahí. Si falta la dependencia, el banco de pruebas aborta.
4. Se propone y se espera un sí explícito antes de escribir. Rige igual para la persona que para el agente configurador. Y ante riesgo de pérdida de datos, primero se lee el contenido real de lo que se va a modificar.
5. Toda decisión de negocio que importe se convierte en una comprobación automática. «No menciones la fecha interna al cliente» no es una nota en un documento que alguien leerá dentro de un año: es una prueba que falla si el dato reaparece. Las notas se olvidan; las pruebas no.

Este informe es la memoria de un proyecto en un despacho de contabilidad de catorce personas. Presentarlo como prueba de que lo mismo funcionará en otra empresa sería exactamente el tipo de afirmación que el resto del documento se ha negado a hacer. Lo que sí se puede decir con precisión es qué parte del trabajo es específica de esta firma y qué parte no lo es.

Lo que transfiere íntegro

• El método de las siete fases y sus cinco reglas. No dependen del sector ni del tamaño. Dependen de que exista una operación real que observar.
• La auditoría de dato previa a cualquier construcción. Es el entregable que más ha cambiado decisiones en este proyecto, y el que menos empresas piden porque no saben que existe. Vale por sí sola aunque después no se construya nada.
• Los patrones de automatización. Escuchar la tabla destino y no el origen. Claves deterministas que un reproceso no duplica. Agrupar por persona en vez de deduplicar por correo. Variar el asunto en una secuencia de recordatorios. Convertir la regla de negocio en una prueba. Todos son independientes de la herramienta.
• La disciplina de decir lo que no se sabe. Es la parte que más incomoda en una propuesta comercial y la que más rápido se agradece a los tres meses.

Lo que no transfiere, y hay que rehacer

• El modelo de datos concreto. Ocho tablas que sirven a un despacho contable no sirven a una distribuidora ni a una clínica. Lo que se reutiliza es el criterio de modelado, no el esquema.
• Los catálogos, los estados y las etapas del pipeline. Salen del negocio de cada firma; copiarlos es el error clásico que hace que nadie adopte el sistema.
• El diagnóstico. Los hallazgos de este proyecto —el 83 %, los 403 nombres, la exposición de datos— son de esta empresa. Otra tendrá los suyos, y no se parecerán.
• Las cifras de este informe. Ninguna es una promesa. Son el resultado de un caso, con su punto de partida y sus restricciones.

El coste y la postura de plataforma

La elección de herramientas de este proyecto no fue ideológica: se optó por plataformas de bajo código sobre infraestructura que la empresa ya pagaba, con la automatización en una instancia propia en la nube. Dos consecuencias que sí son generalizables:

• La infraestructura queda en manos de la empresa, no del proveedor. Las credenciales están a nombre corporativo y las automatizaciones, con sus respaldos y su documentación, viven en un repositorio de la empresa. Si mañana cambia el proveedor de servicio, no se pierde el trabajo.
• El mantenimiento no exige perfil técnico para lo habitual. Dar acceso a alguien nuevo es escribir su departamento en una hoja. Ampliar un catálogo o añadir una columna se le pide al agente configurador en lenguaje natural. Eso es deliberado: un sistema que solo puede tocar quien lo construyó es un sistema que se abandona.

Qué hace falta del lado del cliente

Señales de que una empresa es candidata

Por orden de lo que más se repite en operaciones parecidas a la de este caso:

1. La información del cliente vive en varios sitios a la vez y nadie sabe cuál es el bueno.
2. Hay un sistema comprado que casi nadie usa, y la conversación gira en torno a cambiarlo por otro.
3. Hay trabajo de calendario —pedir lo mismo a los mismos clientes todos los meses— que se hace a mano.
4. Nadie puede responder «¿en qué estado está cada cliente?» sin abrir documentos de uno en uno.
5. Los datos sensibles circulan por correo personal y hojas compartidas, y nadie ha mirado cuántos hay.

Las cinco estaban presentes en este caso. Las cinco son observables en una primera conversación, sin acceso a nada.

A1 · Convenciones del modelo de datos

A2 · Expresión de permisos, forma canónica

IFS(
  IN(USEREMAIL(), SELECT(Usuarios[Email_Workspace],
      OR(STARTSWITH([Departamento],"Direcci"), [Departamento]="Operaciones"))), "ALL_CHANGES",
  IN(USEREMAIL(), SELECT(Usuarios[Email_Workspace], [Departamento]="<departamento>")), "ADDS_ONLY",
  TRUE, "READ_ONLY")

Valores admitidos: ALL_CHANGES · ADDS_AND_UPDATES · ADDS_ONLY · UPDATES_ONLY · DELETES_ONLY · UPDATES_AND_DELETES · ADDS_AND_DELETES · READ_ONLY. La comparación por prefijo evita depender de teclear tildes correctamente desde automatización.

A3 · Expresión de obligatoriedad condicional

Required_If:  CONTEXT("ViewType") = "Form"

Hace que un campo sea obligatorio solo en el alta manual, permitiendo que un bot escriba sin él. Fue la clave para que la conversión automática de lead funcionara sin degradar la calidad del alta humana.

A4 · Procedimiento tras borrar filas de una hoja vigilada

1. Desactivar el flujo que la vigila.
2. Borrar las filas.
3. Contar las filas reales sobre una columna siempre poblada — contar sobre una columna opcional devuelve menos, y contar líneas de un volcado falla porque los campos de texto llevan saltos de línea.
4. Ajustar el contador del disparador por API.
5. Reactivar. Si el flujo envía comunicaciones, hacerlo con el nodo de envío deshabilitado durante un ciclo, comprobar cero ejecuciones, y solo entonces rehabilitarlo.

A5 · Reglas de gobierno del dato adoptadas

• Una sola fuente de verdad por dato. Si está en dos sitios, uno está mal y nadie sabe cuál.
• Ninguna hoja de cálculo paralela «para llevar una cosita aparte». Así nacieron las 33 pestañas.
• Nunca borrar ni renombrar un registro maestro: desactivarlo. Al salir una persona se renombró la columna que llevaba su nombre y se perdió el histórico de 56 clientes.
• Cualquier script mapea por nombre de encabezado leído en vivo, nunca por posición fija.
• Sanear el texto libre en toda migración, no solo omitir los campos etiquetados como sensibles.
• Antes de regenerar un esquema, anotar el tipo y la tabla origen de todas las columnas de referencia, y verificarlas una por una después.

A6 · Estado de las fuentes al cierre