Cambia «la tienda está rota» por una acción concreta.
Indica la página, el usuario y la acción. ¿Falla el carrito para todo el mundo o solo después de aplicar un cupón concreto? ¿Puede el cliente comprar otro producto? Distingue entre un elemento de diseño que falta, una solicitud fallida y un resultado de pago inesperado.
Registra el último momento en que funcionaba y el primer fallo observado. No incluyas información confidencial de clientes ni credenciales de pago en una solicitud pública de soporte. La información útil es el síntoma y los pasos para reproducirlo; comparte las referencias privadas por el canal de soporte apropiado.
Examina el cambio sin dar por hecha la causa.
Compara los cambios recientes de plugins, tema, PHP y configuración. Una tarea programada o un servicio externo puede haber cambiado al mismo tiempo que la actualización visible. Pregunta quién hizo cada cambio y a qué entorno afectó.
Un conflicto significa que varios componentes interactúan mal; un componente también puede fallar por sí solo. Un desarrollador puede distinguir ambas posibilidades repitiendo la misma acción con cambios controlados. El proceso oficial de WooCommerce para probar conflictos aporta el método; quien gestiona la tienda debe dejar claro el impacto en el cliente.
Dale a la investigación un punto de partida útil.
El siguiente ejemplo es ficticio. Describe una acción fallida en el carrito sin afirmar que el plugin actualizado sea el responsable.
| Pregunta | Ejemplo de respuesta |
|---|---|
| ¿Qué esperabas que ocurriera? | Al añadir la gorra seleccionada, la camiseta sigue en el carrito |
| ¿Qué ocurrió? | El carrito mostró un indicador de carga y no se actualizó |
| ¿Cómo se puede reproducir? | En el móvil, selecciona la camiseta M, añádela y después añade la gorra |
| ¿Qué ha cambiado? | Se ha actualizado una extensión esta mañana; la causa no está determinada |
| ¿Qué hay que comprobar? | Repetir los mismos pasos en staging y revisar la solicitud fallida |
Comprueba la recuperación antes de volver al trabajo habitual.
Acuerda quién puede modificar el entorno de pruebas y cómo se restaurará. Mantén los pagos, correos y procesos de preparación de pedidos de prueba aislados de la actividad real. La copia de staging debe servir para investigar el fallo, no ser simplemente una copia antigua con ajustes que no corresponden.
Tras aplicar la solución propuesta, repite el recorrido que fallaba y otro habitual que antes funcionaba. Comprueba qué llega al pedido y al cliente. Que una página se abra no basta si el proceso de pago o el seguimiento siguen fallando. Consulta las guías del proceso de pago cuando la incidencia afecte a las compras.