Qué es un SLA de soporte Shopify
Un SLA de soporte Shopify es el acuerdo que define cómo se recibe, clasifica, atiende y comunica una incidencia. Debe separar el tiempo de primera respuesta del tiempo de diagnóstico, mitigación y resolución.
“Respondemos rápido” no es un SLA. Tampoco lo es prometer que cualquier problema estará resuelto en unas horas: la causa puede estar en Shopify, una app, el proveedor de pagos, el ERP o un cambio del propio equipo.
Un acuerdo serio fija qué puede controlar el proveedor, qué necesita del merchant y cómo se gestiona una dependencia externa. Si buscas acompañamiento continuo, consulta el alcance de soporte Shopify.
Respuesta, mitigación y resolución no son lo mismo
| Hito | Qué confirma |
|---|---|
| Acuse | La solicitud ha llegado y tiene un identificador |
| Primera respuesta | Una persona ha revisado el contexto y confirma la prioridad inicial |
| Diagnóstico | Existe una hipótesis respaldada por pruebas |
| Mitigación | Se reduce el impacto aunque la causa siga abierta |
| Resolución | El servicio vuelve al comportamiento acordado |
| Cierre | Se valida el resultado y queda registrada la causa |
Medir solo la primera respuesta incentiva contestaciones rápidas que no resuelven nada. Medir solo la resolución penaliza problemas que dependen de terceros. El SLA debe mostrar ambos tiempos y detener el contador cuando falta información imprescindible del cliente, si así se ha pactado.
Modelo de prioridades para ecommerce
La prioridad se asigna por impacto y urgencia, no por quién escribe más fuerte.
P1: operación comercial detenida
Ejemplos: la mayoría de clientes no puede completar el pago, el storefront no carga o una integración genera un riesgo grave sobre pedidos. Requiere atención inmediata dentro del horario contratado, canal de crisis y actualizaciones frecuentes.
P2: función crítica degradada
Ejemplos: un método de pago relevante falla para un segmento, pedidos no llegan al sistema logístico o una campaña importante tiene una regresión sin alternativa estable. Existe impacto alto, pero parte de la operación continúa.
P3: incidencia limitada
Ejemplos: error visual en una plantilla, automatización no crítica o problema que afecta a pocos casos y tiene alternativa manual. Se planifica dentro del flujo ordinario.
P4: consulta o mejora
Petición de cambio, ajuste preventivo, análisis o duda funcional. No debe competir con incidencias que están afectando ventas o datos.
Qué información debe acompañar cada incidencia
Una solicitud útil incluye:
- URL y tienda afectada;
- fecha y hora con zona horaria;
- pasos para reproducir;
- resultado esperado y resultado observado;
- dispositivo, navegador, mercado y tipo de cliente;
- pedido, producto o variante de ejemplo sin exponer datos sensibles;
- cambio reciente relacionado;
- captura o vídeo cuando aporta contexto;
- alcance conocido: un caso, un segmento o toda la tienda.
Sin esa información, el equipo pierde tiempo reconstruyendo el escenario. El formulario de entrada debe ser corto, pero exigir lo que cambia el diagnóstico.
Cobertura y dependencias
El SLA debe indicar horarios, festivos, canal de emergencia y personas autorizadas. También debe aclarar si cubre theme, configuración, apps propias, apps de terceros, integraciones, analítica y consultas funcionales.
Cuando Shopify presenta una incidencia de plataforma, el equipo puede confirmar el impacto, aplicar una alternativa segura y comunicar el estado, pero no reparar la infraestructura de Shopify. Lo mismo ocurre con un proveedor de pagos o logística. La fuente oficial de estado ayuda a distinguir una caída general de un fallo específico de la tienda.
Escalado que funciona
Un escalado operativo tiene tres rutas:
- Técnica: pasa a quien conoce el componente y puede obtener registros o desplegar una corrección.
- De negocio: decide si se desactiva una campaña, un mercado, una app o una función para reducir impacto.
- Proveedor: abre el caso externo con pruebas reproducibles y mantiene el seguimiento.
Escalar no significa reenviar el mismo mensaje. Significa añadir evidencia, concretar la decisión pendiente y definir cuándo será la siguiente actualización.
Cómo evaluar un SLA antes de contratarlo
Pide ejemplos anonimizados del formato de ticket, parte de cierre y comunicación de crisis. Revisa estas preguntas:
- ¿qué evento convierte una solicitud en P1?
- ¿quién puede cambiar la prioridad?
- ¿la cobertura es horario laboral o continua?
- ¿qué ocurre fuera de horario?
- ¿qué dependencias quedan excluidas?
- ¿cómo se prueba una corrección antes de publicarla?
- ¿cómo se informa durante una incidencia larga?
- ¿qué métricas se revisan cada mes?
Un buen acuerdo reduce discusiones durante la crisis porque esas decisiones ya están escritas.
Métricas que sí ayudan
Combina volumen por prioridad, tiempo hasta diagnóstico, tiempo hasta mitigación, reaperturas, incidencias repetidas y porcentaje de casos con causa documentada. Añade el impacto comercial solo cuando exista una medición fiable; no lo inventes a partir de intuiciones.
La mejora más valiosa suele aparecer fuera del propio SLA: eliminar una causa repetida, automatizar una alerta o incorporar una prueba al proceso de releases.
Preguntas frecuentes
¿Un SLA garantiza el tiempo de resolución?
Puede fijar objetivos o compromisos sobre componentes controlados, pero una garantía absoluta no es realista cuando intervienen plataformas y proveedores externos. Debe quedar claro qué tiempos se comprometen y qué excepciones existen.
¿Qué diferencia hay entre soporte y una bolsa de horas?
El soporte organiza entrada, prioridad, comunicación y continuidad. Una bolsa de horas limita capacidad, pero por sí sola no define cómo se atiende una incidencia crítica.
¿Todos los problemas de checkout son P1?
No. Depende del alcance y de las alternativas. Un fallo general de pago suele ser P1; un método secundario afectado en un mercado concreto puede clasificarse como P2 tras comprobar el impacto.
Fuentes oficiales revisadas
Referencias usadas para contrastar recomendaciones técnicas, documentación de plataforma y criterios de búsqueda.
