--- type: PG asset_id: PG-MTX-SoporteTecnicoRemoto-v01 version: v01 status: N1 sembrado — anti-jerga PASS · N2/N3 en borrador owner: Juan Carlos Angeles Ramírez verificado_por: JuanCarlosX verificado_fecha: 2026-07-22 intellibank: IB-MTX-MatriX nodo_map: "5.5" exposicion: "🔒 interna (N1-N2 como referencia pública; N3 es operacional)" fuente_canonica: SOP-EL-JuanCarlos-SoporteTecnicoRemoto-v01 nodo_grafo: "soporte (grupo entrega)" base: PLAN-MTX-MatriX-MasterPlan-v01 §2.3 (anatomía canónica) --- # Soporte Técnico Remoto ## 1 · Tarjeta resumen > **¿Qué es en una frase?** El proceso para reportar un problema técnico, que alguien lo diagnostique y resuelva en tiempo — sin que se pierda en canales informales o sin saber a dónde escalarlo. > **Familia:** D5 · Entrega e implementación — la fase de soporte operativo del Kit de Ensamblaje > **Metáfora:** es como un servicio técnico que no te deja esperando — sabe exactamente qué urgencia es cada cosa, dónde escalarlo si es necesario, y cuánto tiempo toma de verdad. ## 2 · Nivel 1 · 🌱 Esencial Cuando algo no funciona en tu SherpaX, en el vault o en los skills, hay un proceso para reportarlo y que se resuelva. No es un email que desaparece ni una llamada que interrumpe — es un canal claro donde entra tu problema, se le asigna una prioridad y un tiempo de respuesta. El proceso no es complicado. Si eres cliente, mandas un WhatsApp o correo. Si eres del equipo interno, usas el buzón de tareas. Alguien recibe tu reporte, lo anota, corre un diagnóstico para saber qué está pasando, y te dice qué se puede hacer — o lo escala a alguien que sí puede arreglarlo. La prioridad depende de cuánto te bloquea. Si el sistema está caído y no puedes trabajar hoy, es urgente (máx 2 horas). Si funciona pero con problemas, es menos urgente (máx 4 horas). Si es una duda o una mejora futura, puede esperar un día. Lo importante es que no se pierda. Cada reporte queda anotado en un log simple — no necesita herramienta sofisticada para que nada se olvide. Y escalado significa que si el diagnóstico necesita a un ingeniero, o si hay que negociar con el cliente, o si hay que decidir a nivel estratégico, eso pasa sin que tú estés dando vueltas en medio. ## 3 · Nivel 2 · 🛠 Implementador El Soporte Técnico Remoto es la **fase F5 del Kit de Ensamblaje** (5.1): la infraestructura operativa que mantiene el sistema funcionando después de que fue instalado. **Cómo está construido:** 1. **Canales de entrada sin fricción.** Clientes reportan por WhatsApp o correo (como ya lo hacen). El equipo interno usa el buzón de tareas para crear un ticket formal. Nada de herramienta nueva; se usan los canales que ya existen. 2. **Log simple.** Cada reporte queda registrado en una hoja de cálculo (fecha · quién reporta · descripción · gravedad · estado). Esto evita perder tickets en mensajes informales. 3. **Clasificación rápida (SLA).** Tres niveles de urgencia con tiempo de respuesta garantizado: - 🔴 **Crítico** (sistema caído, no se puede trabajar): respuesta ≤ 2 horas - 🟡 **Alto** (funciona pero con problemas): respuesta ≤ 4 horas - 🟢 **Normal** (duda, mejora, no bloquea): respuesta ≤ 1 día hábil 4. **Diagnóstico automatizado.** Antes de escalar, se corre `sk-ibhealth` (para salud del vault y skills) o `/wx-setupsherpax` (para instalación del SherpaX). Esto reduce problemas falsos. 5. **Escalación clara.** Si el diagnóstico dice que necesita técnico (Jay/Alex), comercial (Ángeles) o decisión estratégica (Victor), eso se anota y se escala. No hay ambigüedad de "¿a quién le pregunto?". **La regla de oro:** cada reporte forma parte del aprendizaje del sistema. Si algo falla, alguien lo documenta y el proceso mejora para el próximo. El log simple se revisa cada dos semanas para detectar patrones. **Cómo se adapta a otra organización:** El esquema es portable. Conserva los canales que esa org ya usa (no fuerza Jira ni Zendesk), el SLA que decide (puede ser más agresivo o más relajado), y los escalamientos a sus propios roles. La estructura es la misma. ## 4 · Nivel 3 · 🔬 Ingeniería — INTERNO Nodo `soporte` (grupo `entrega`, id 27) · fuente `SOP-EL-JuanCarlos-SoporteTecnicoRemoto-v01` (Operativo bajo delegación · ratificación diferida Victor). Va en la **base del Cubo A** (siempre incluido), no es Add-On. Validación de proceso: 22-jul, sk-ibhealth + /wx-setupsherpax PASS (6/6 checks). **Arquitectura del log (REG-EL-JuanCarlos-TicketsSoporte-v01):** ``` Fecha | Quién reporta | Canal | Descripción | Gravedad | Estado | Diagnóstico | Escalado a | Resolución ``` Campos opcionales después de "Estado" — se llenan al avanzar el ticket (diagnóstico se descubre al correr sk-ibhealth o /wx-setupsherpax; escalación ocurre si aplica; resolución se documenta cuando cierra). **Diagnósticos disponibles (primeros 2 meses):** - **sk-ibhealth:** sincronización del vault (↔ nube), duplicados de skills, rutas muertas (Reinventaverse), carpetas indebidas. Output: estado de sync + banderas de salud. - **/wx-setupsherpax:** validación de conexión SherpaX (MCP handshake), perfil del operador, acceso a IntelliBanks. Output: 6 checks con resultado PASS/FAIL. - **Manual (G0 consulta):** si el problema no lo cubre ninguno de los dos, JC revisa el vault manualmente contra las fuentes canónicas. **Escalación según tipo (matriz en SOP §5):** | Tipo | Escala a | Decisión | |------|----------|----------| | Infraestructura técnica (SherpaX, IntelliBanks, plugins) | Jay o Alex | Ejecución técnica | | Decisión comercial (cliente, alcance, cobro) | Ángeles | Negociación | | Decisión estratégica (prioridad, rumbo) | Victor | Autorización L3 | | Bloqueo de gobernanza (G0, activo sin dueño, conflicto >2 días) | Victor + Ángeles | Desempate L3+L2 | JC arbitra solo hasta 2 días en conflictos menores; después, ambos. **Medición (segunda quincena onward):** - Volumen por nivel (cuántos críticos/altos/normales por semana) - Tiempo real vs. SLA (se resolvió en 1.5h o tardó 4h) - Tasa de resolución sin escalar (% que se cierra en L1) - Patrón de problemas (¿siempre falla la misma cosa?) Esto alimenta KPI 3 de `PLAN-EL-JuanCarlos-RolTrabajo-v02` (segunda mitad: "medir tiempo de respuesta/resolución"). **Validación real (caso vivo 22-jul):** - sk-ibhealth M-A: vault sano, 11 IntelliBanks, sync OK (3,408 skills · 246 carpetas · 0 indebidas detectadas) - /wx-setupsherpax: operador JC validado (6/6 checks PASS), perfil creado (DC-EL-PerfilOperador-JuanCarlos-v01), luz_verde=true Ratificación de Victor diferida (SOP v01 operativo, patrón del plan de rol v02). ## 5 · Casos de uso 1. **Un cliente reporta que no puede descargar un archivo del vault.** Entra por WhatsApp → JC anota en el log (Crítico) → corre sk-ibhealth → detecta que la app no está sincronizando (ruta muerta) → arreglable en 20 min → responde en <2h. Resuelto sin escalar. 2. **El equipo interno reporta que `/wx-setupsherpax` tarda 5 minutos más de lo normal.** Entra por buzón → JC anota (Normal, no bloquea trabajo) → corre diagnóstico → no hay error, es que hoy hay 3,408 skills y la validación de cada una toma tiempo → responde "esto es normal, aquí el detalle" → cerrado L1. 3. **Un cliente reporta que necesita acceso a una carpeta privada del vault que no le cabe comercialmente en su plan.** Entra por correo → JC anota (Alto, necesita decisión) → sk-ibhealth dice que acceso OK técnicamente, pero es cuestión de acuerdo → escala a Ángeles (comercial) → Ángeles negocia si se amplía el alcance o no → JC documenta la resolución. ## 6 · Verifica tu comprensión 1. **¿Cuál es la diferencia entre un reporte Crítico y un Normal?**
Ver respuestaCrítico bloquea el trabajo hoy (respuesta ≤2h). Normal no bloquea nada — es una duda o mejora (respuesta ≤1 día). La diferencia define el SLA, no el esfuerzo de resolver.
2. **¿Qué pasa si sk-ibhealth no encuentra nada pero el cliente sigue reportando el problema?**
Ver respuestaSignifica que el problema no es técnico o no lo cubre ese diagnóstico. JC consulta el vault manualmente (G0) y revisa si es configuración, uso, o algo que necesita escalación. Si aún no es claro, se escala a Jay/Alex con toda la información ya reunida.
3. **¿Quién decide si algo es Crítico o Alto?**
Ver respuestaJC, en el momento del reporte. Usa la definición: ¿bloquea trabajo hoy? Sí = Crítico. ¿Afecta pero hay workaround? = Alto. ¿Es una duda o mejora? = Normal. Si el cliente discrepa, la decisión la hace JC (si es cliente directo) o se escala a Ángeles (si es negociable).
--- *Creado: 2026-07-22 · PG-MTX-SoporteTecnicoRemoto-v01 · Owner: Juan Carlos · Sherpa: JuanCarlosX · Ratificador: Victor (diferida)*