Hoja de ruta completa para migrar el departamento de Arrendamientos desde Zoho Desk (CRM DEI)
hacia Zoho CRM Plus ABR — con análisis de estrategias, limpieza de deuda técnica y mejoras requeridas.
Coninsa opera hoy con dos instancias de Zoho CRM Plus en la misma cuenta de administrador: CRM DEI (proyectos inmobiliarios) y CRM Plus ABR (inmobiliaria / arrendamientos). El departamento PQRS ABR está actualmente alojado dentro del CRM DEI, conviviendo con flujos de proyectos. El objetivo es extraerlo y reconfigurarlo completamente en el CRM Plus ABR, separando los dos universos de negocio. La migración fue planeada originalmente sin rediseñar Zoho Desk, lo que representa un riesgo operativo y estratégico directo.
4–5 años de uso limitado: Zoho funciona como "Gmail con plantillas"
Configuración inicial sin mejora continua ni optimizaciones
PQRS ABR mezclado con CRM DEI — flujos contaminados
54% de ANS vencidos: 428 de 789 tickets abiertos incumplidos
Asignación de casos 100% manual — trabajo administrativo sin valor
Licencias compartidas entre 11 personas — reportes y ANS inútiles
Deuda técnica acumulada: duplicados, código hardcoded, funciones dev sin limpiar
Arrendatario rastrea el estado de su solicitud de forma autónoma
Comunicación asertiva por tipificación — no solo "recibimos su caso"
Procesos macro (Renovaciones / Reparaciones) con blueprints propios
Ali (IA) como orquestador de comunicaciones automatizadas (gestionado por empresa externa)
ANS diferenciados por tipificación — no un único SLA para todo
Asignación automática de casos por reglas de tipificación
Dashboard de ANS en tiempo real — sin exportar Excel
| Alerta | Etapa | Estado |
|---|---|---|
| Registro / REGISTRO | Registrado | ×3 — Duplicado |
| Confirmación de recibido | Registrado | ✔ Único |
| En Trámite | En Trámite | ✔ Único |
| En Ejecución 3a/3A | En Ejecución | ×2 — Revisar |
| En Aprobación | En Aprobación | ✔ Único |
| Correo a contratista | Contratistas | ×3 — Duplicado |
| Función | Criticidad | Problema |
|---|---|---|
| Integración Nuwwe J | 🔴 Crítica | Token atado a CRM DEI — debe recrearse |
| Consultar API SINCO | ⚠ Alta | Credenciales hardcodeadas en el script |
| TICKET_REABIERTO→NUEVO | ⚠ Alta | Sin umbral definido — comportamiento indefinido |
| AsociarTelefono | Media | Directorio de 54 analistas sin verificar vigencia |
| Prueba / testJ | Descartar | Código de dev sin uso productivo — basura técnica |
| Regla | Problema / Riesgo |
|---|---|
| Consulta Data Contrato Nuwwe | Depende del token del entorno viejo. Sin reconfigurar, no trae datos al ticket. |
| Ticket cerrado → nuevo ticket | Umbral de reapertura no está definido. Comportamiento actual es impredecible. |
| Autocompletar tel. Analista | Directorio hardcodeado de 54 personas — puede estar desactualizado. |
| Agregar URL caso anterior | Lógica válida. Migrar sin cambios. |
| Correos no deseado | Lógica válida. Migrar sin cambios. |
| Marcar Ticket Cerrado | Campo personalizado debe recrearse en nuevo entorno. |
Blueprint "Reparaciones Locativas" (13 transiciones) — inactivo, sin validar
Solo perfil Administrador ve datos de CRM desde Desk
Sync CRM ↔ Desk: Productos sin configurar
Facturas copropiedades dentro de Desk — contamina métricas
| Componente | Estado actual | ¿Funciona en nuevo entorno? | Consecuencia |
|---|---|---|---|
| Integración Nuwwe J | Token = CRM DEI | ✗ No funciona | 12+ campos del ticket no se poblarán. El analista debe llenar datos de contrato a mano en cada caso. |
| API SINCO (Deluge) | Credenciales hardcoded | ✗ Probablemente no | Falla silenciosa al cambiar el contexto de ejecución. Sin error visible, sin datos de propietario ni arrendatario. |
| Alertas duplicadas (×3, ×2) | Registro ×3, Ejec. ×2, Contrat. ×3 | Funciona pero mal | El arrendatario recibe 3 correos idénticos de confirmación. Daña la percepción de profesionalismo de Coninsa. |
| Blueprint Reparaciones (inactivo) | 13 trans. sin validar | Riesgo operativo | Si se activa sin validación, puede asignar flujos incorrectos a solicitudes de reparación. Desconcierto para agentes. |
| Umbral de reapertura | No definido | Comportamiento indefinido | La regla "Ticket cerrado → nuevo ticket" tomará decisiones arbitrarias. Tickets que deberían reabrir crean casos nuevos y viceversa. |
| Funciones dev (Prueba/testJ) | Sin uso productivo | No agrega valor | Ocupa espacio, genera confusión y puede ejecutarse accidentalmente si queda ligada a algún disparador residual. |
| Campo "Ticket Cerrado?" | Personalizado en Desk actual | ✗ No existe en nuevo entorno | La regla "Marcar Ticket Cerrado" fallará sin el campo destino. Los filtros y reportes que lo usen quedarán rotos. |
| Componente | Decisión | Acción concreta |
|---|---|---|
| Dpto. PQRS ABR | ✔ Migrar | Crear departamento nuevo en CRM Plus ABR. No copiar — construir según diseño TO-BE aprobado. |
| Blueprint "Estado solicitudes" (7 trans.) | ✔ Migrar + ajustar | Recrear con umbral de reapertura definido. Validar cada transición antes de activar. |
| Blueprint "Reparaciones Locativas" (13 trans.) | ⚠ Rediseñar | Cesar Castro valida flujo. Se definen los puntos de integración con Ali — ⚠ Ali es implementado por empresa externa, no INLAT. |
| Alertas de workflow (con duplicados) | ⚠ Consolidar primero | Eliminar Registro ×3, Ejecución ×2, Contratista ×3. Recrear 1 alerta por etapa con plantillas mejoradas. |
| Función "Integración Nuwwe J" | ✔ Reconfigurar | Recrear variable Nuwwe_Token en CRM Plus ABR. Reapuntar función al nuevo token. Probar con contrato real. |
| Función "Consultar API SINCO" | ✔ Reconfigurar | Eliminar credenciales del código. Crear variable de organización SINCO_Credentials. Actualizar función. |
| Función "TICKET_REABIERTO→NUEVO" | ✔ Reconfigurar | Definir umbral en F1. Recrear función con valor documentado. Probar los dos escenarios (reapertura y nuevo). |
| Función "AsociarTelefono" | ⚠ Revisar y migrar | Verificar vigencia del directorio de 54 analistas antes de migrar. Actualizar entradas obsoletas. |
| Funciones "Prueba / testJ" | ✗ Descartar | No migrar bajo ninguna circunstancia. Son residuos de desarrollo. |
| 238 contactos | ⚠ Migrar con depuración | Exportar, depurar (email como llave), cruzar contra CRM para evitar duplicados, importar validado. |
| Dpto. Pruebas Coninsa | ✗ No migrar | Descartar. Se crea entorno de UAT dedicado en CRM Plus ABR para pruebas futuras. |
| Facturas copropiedades | ✗ Sacar de Desk | Redefinir canal en F1. No entra al nuevo entorno de ninguna forma. |
| Solicitud del equipo | Problema hoy | Propuesta INLAT | Resp. |
|---|---|---|---|
| 📣 Comunicación asertiva | Respuesta genérica para todos — "hemos recibido su solicitud" | Plantillas diferenciadas por tipificación. Ali ext. conectado a KB para respuestas contextuales automáticas | INLAT + Ext. |
| 📱 WhatsApp como canal | Solo correo. Cliente llama para saber el estado de su caso | Canal WhatsApp Business en Zoho Desk. Ticket se crea automáticamente. Actualizaciones de estado en el mismo hilo | INLAT |
| 🔄 Blueprints por tipificación | Un blueprint genérico — procesos forzados a encajar en un solo flujo | Blueprint independiente por proceso macro (Renovaciones y Reparaciones). Transiciones automáticas por acción del sistema, no marcado manual | INLAT |
| ⚡ Asignación automática | 100% manual — tarea administrativa sin valor para el negocio | Reglas de asignación por tipificación en Zoho Desk. Cada caso al analista correcto desde el momento de creación. Cero intervención manual | INLAT |
| 📊 Licencias individuales + ANS | Hasta 11 personas por licencia — reportes inútiles, ANS sin trazabilidad | Licencia individual por agente. Dashboard en tiempo real de ANS, cumplimiento y segmentación. Sin exportar Excel | INLAT |
| 📚 Base de conocimiento | No existe — toda consulta requiere intervención humana | Zoho Desk KB estructurada por proceso. Ali ext. la consume para autoatención del arrendatario | INLAT + Ext. |
| ⏱️ ANS por tipificación | ANS único para todo — 54% de incumplimiento con metas irreales | ANS diferenciados: ej. 8h corrección certificados, 5d renovación, 10d reparaciones. Alertas automáticas de vencimiento por tipo | INLAT |
| Criterio | Opción A — Lift & Shift | Opción B — Migración Limpia ✔ INLAT recomienda |
|---|---|---|
| Tiempo de ejecución | Aparentemente más rápido (2–4 sem.) ⚠ Ilusorio | 6 semanas — condicionadas a prerequisitos resueltos antes del kick-off Alcanzable |
| Integraciones Nuwwe / SINCO | Fallan desde el día 1 — token viejo, credenciales inválidas | Reconfiguradas y probadas antes del go-live |
| Alertas duplicadas | Se transfieren: ×3, ×2 — arrendatarios reciben correos múltiples | Consolidadas — 1 alerta por etapa, plantillas mejoradas |
| Blueprint Reparaciones | Inactivo sin validar — riesgo de activarse mal | Validado + puntos de integración Ali listos — empresa externa implementa Ali |
| ANS y cumplimiento | Mismo ANS único — 54% de incumplimiento se transfiere | ANS por tipificación — metas realistas y medibles |
| Licencias y reportes | Compartidas sin cambio — reportes siguen siendo inútiles | Individuales — dashboards reales de ANS y desempeño |
| Asignación de casos | Sigue siendo manual 100% | Automática por tipificación desde el primer día |
| Calidad del entorno resultante | Deuda técnica heredada íntegra | Entorno limpio, documentado y escalable |
| Riesgo operativo | Alto — problemas silenciosos que emergen en producción | Bajo — todo probado en UAT antes del corte |
| Valor para el negocio | Igual al sistema actual — solo cambió de casa | Ali (ext.), WhatsApp, autoasignación, dashboards — sistema nuevo real |
| Riesgo | Prob. | Impacto | Mitigación |
|---|---|---|---|
| Nuwwe_Token perdido / apuntando al entorno viejo | Media | Crítico | Documentar y respaldar credencial actual antes de iniciar F2. Primer paso de configuración del nuevo entorno. |
| SINCO falla por credenciales hardcodeadas | Alta | Alto | Crear variable de organización en F2 antes de copiar la función. Probar con ID de contrato real antes de activar en producción. |
| 789 tickets vencidos trasladados al nuevo entorno | Alta | Alto | Operación paralela obligatoria en F4. El nuevo entorno solo recibe tickets nuevos. El viejo liquida los abiertos hasta que quede en cero. |
| Blueprint Reparaciones activado sin validar | Media | Medio | F1 incluye sesión dedicada con Cesar Castro. El blueprint solo se activa en F3 una vez aprobado y probado en UAT. |
| Umbral de reapertura no definido antes del go-live | Media | Medio | Es entregable obligatorio de F1. Sin este valor documentado, F2 no puede migrar la regla de reapertura. |
| Licencias insuficientes en CRM Plus ABR | Baja | Alto | Paola y Diego Ossa auditan licencias actuales en F1. Coninsa confirma disponibilidad antes de comenzar configuración de agentes. |
| Duplicación de contactos al importar 238 registros | Alta | Medio | Diseñar estrategia de deduplicación en F1. Exportar, cruzar contra CRM usando email como llave única, importar solo los netos. |
| Ali no lee estados del blueprint correctamente ⚠ Empresa externa | Media | Medio | INLAT define y documenta los puntos de integración (webhooks / APIs de Zoho Desk) en F1. La empresa externa que implementa Ali debe participar en UAT de F3 para validar la lectura de estados antes del go-live. |
Diseño TO-BE completo + documento aprobado
Migración limpia PQRS ABR a CRM Plus ABR
Blueprints por tipificación (Renovaciones + Reparaciones)
Reconfiguración Nuwwe J + SINCO + reapertura de tickets
Canal WhatsApp + asignación automática + ANS por tipificación
Dashboards ANS + base de conocimiento estructurada
Puntos de integración Ali listos para empresa externa
Manuales de autogestión + soporte post go-live
Prerequisitos de "Próximos Pasos" resueltos antes del kick-off
Empresa externa de Ali confirmada y disponible para UAT en S4
Decisiones de negocio (umbral reapertura, licencias, facturas) no generan retrabajo
Implementación, entrenamiento y activación de Ali (empresa externa)
Licencias de Zoho CRM Plus (cargo de Coninsa con Zoho)
Migración de departamento Proveedores y Contratistas (alcance futuro)