Cómo hacer el triaje de una incidencia Shopify
El triaje de una incidencia Shopify responde primero a cuatro preguntas: qué está fallando, a quién afecta, desde cuándo y qué cambió. Después separa el problema entre storefront, checkout, configuración, app o integración para reducir el espacio de búsqueda.
La prioridad inicial debe poder cambiar cuando aparecen datos nuevos. Un caso reportado como “no se puede comprar” puede terminar siendo una variante sin stock, un método de pago limitado a un país o una caída general de un proveedor.
Para una operación continua, el triaje forma parte de un servicio de soporte Shopify con canales, prioridades y comunicación definidos.
Primeros diez minutos
- Registrar hora, zona, URL y caso de ejemplo.
- Confirmar si el problema se reproduce.
- Consultar el estado oficial de Shopify y proveedores críticos.
- Delimitar mercados, dispositivos, clientes y métodos afectados.
- Identificar despliegues, apps o cambios de configuración recientes.
- Preservar registros y capturas antes de modificar nada.
- Decidir si existe una mitigación segura.
- Comunicar impacto confirmado y próxima actualización.
No borres una app, reviertas el theme y cambies pagos al mismo tiempo. Si varias variables cambian a la vez, se pierde la capacidad de identificar la causa.
Aislar el storefront
Si el problema está en navegación, producto, variante o carrito, compara:
- theme publicado frente a una copia anterior;
- ventana normal frente a sesión limpia;
- móvil frente a escritorio;
- producto afectado frente a producto control;
- mercado e idioma;
- app embed activo frente a configuración conocida.
Revisa errores del navegador y solicitudes fallidas, pero no asumas que cada mensaje es la causa. Un error antiguo puede estar presente incluso cuando el flujo funciona.
Si una copia anterior resuelve el fallo, todavía hay que localizar qué cambio lo introdujo. Publicar la copia puede mitigar; no completa el diagnóstico.
Aislar checkout y pagos
Comprueba el alcance antes de tocar la configuración:
- ¿falla al entrar en checkout o al confirmar el pago?
- ¿afecta a todos los productos o a una combinación?
- ¿solo ocurre con un mercado, moneda o dirección?
- ¿el método de pago aparece y luego falla?
- ¿hay descuentos, suscripciones o B2B implicados?
- ¿el pedido se crea aunque el cliente vea un error?
Utiliza pedidos de prueba según la documentación de Shopify y evita activar modos que bloqueen pagos reales durante tráfico activo. Si el fallo depende de una pasarela externa, reúne hora, referencia segura y resultado antes de abrir el caso con el proveedor.
Aislar apps e integraciones
En una integración, sigue el recorrido del objeto. Para un pedido:
- Shopify crea el pedido.
- Se emite un webhook o se consulta la API.
- La capa de integración recibe y valida.
- ERP o WMS acepta o rechaza.
- El resultado vuelve y actualiza el estado.
Localiza el último paso confirmado. Shopify ofrece métricas de entrega para webhooks en los entornos compatibles; un 200 solo confirma recepción, no que el sistema final haya procesado correctamente el pedido.
Compara identificadores, timestamps e idempotencia. Reenviar un evento sin comprobar si ya se procesó puede duplicar pedidos, fulfillments o movimientos de stock.
Mitigar sin agravar
Una mitigación reduce impacto mientras sigue abierta la causa. Ejemplos:
- volver al theme anterior;
- desactivar temporalmente un bloque no esencial;
- ocultar un método afectado si existe alternativa y negocio lo aprueba;
- detener una sincronización que está escribiendo datos incorrectos;
- pasar un proceso a revisión manual controlada;
- pausar una campaña que dirige a una ruta rota.
Define también cómo se recuperarán los casos que ocurrieron durante la mitigación: pedidos pendientes, stock desfasado o clientes que necesitan comunicación.
Comunicación durante la incidencia
Cada actualización debe contener:
- impacto confirmado, no supuesto;
- servicios y segmentos afectados;
- mitigación activa;
- investigación en curso;
- decisión o dato que falta;
- hora de la siguiente actualización.
No llenes el canal de hipótesis sin validar. Mantén un registro técnico aparte y una comunicación ejecutiva corta para quienes toman decisiones comerciales.
Cierre y prevención
El cierre incluye hora de recuperación, validación del flujo completo y casos que deben reprocesarse. Después documenta una causa suficientemente concreta: “la app falló” no permite prevenir.
Una acción preventiva puede ser una alerta, una prueba automatizada, un permiso más restrictivo, una validación de datos o un cambio en el proceso de release. Asigna fecha y comprueba en la siguiente revisión que se ejecutó.
La página de integraciones Shopify detalla cómo diseñar observabilidad y responsabilidades cuando ERP, WMS, CRM u otros sistemas forman parte de la operación.
Preguntas frecuentes
¿Hay que contactar primero con Shopify ante cualquier incidencia?
No. Primero delimita si el problema es general, de configuración, theme, app o integración. El estado oficial y una reproducción controlada ayudan a dirigir el caso al proveedor correcto con evidencia.
¿Desactivar una app es una buena prueba?
Puede serlo en un entorno controlado, pero en producción puede retirar funciones, scripts o sincronizaciones críticas. Antes hay que conocer su alcance y disponer de una forma de volver atrás.
¿Cuándo termina una incidencia?
Cuando el servicio está recuperado, el flujo crítico se ha validado, los datos pendientes están identificados y existe un registro de causa y acciones posteriores. Que deje de aparecer el error no basta.
Fuentes oficiales revisadas
Referencias usadas para contrastar recomendaciones técnicas, documentación de plataforma y criterios de búsqueda.
