---
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 respuesta
Crí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 respuesta
Significa 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 respuesta
JC, 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)*