---
id: KB-TD-013
url: https://app.codecontract.io/ayuda/trabajo-diario/el-dia-que-algo-no-va
idioma: es
categoria: trabajo-diario
subcategoria: bandeja
audiencia: usuario
nivel: basico
actualizado: 2026-08-13
tambienEn: [en]
relacionados: [KB-PR-009, KB-PR-001, KB-TD-018]
citadoPor: [KB-TD-001]
---

# El día que algo no va

_Qué se puede seguir haciendo, qué conviene posponer y qué NO hay que hacer._

**Responde a:** la plataforma va lenta qué hago · no puedo trabajar hoy sistema caído · seguir trabajando si falla el sistema · plan b cuando algo no funciona

Algún día algo no irá: el sistema, vuestra conexión, el correo de un tercero. La diferencia entre una mañana perdida y una molestia está en tener decidido de antemano qué se hace y, sobre todo, qué no.

## Los tres primeros minutos

1. **Comprobad si es vuestro o es general** — Que lo intente otra persona desde otra conexión. Ahorra la mitad de las llamadas.
2. **Mirad la página de estado** — Si es general, ya lo saben y hay poco que aportar.
3. **Y avisad a quien esperaba algo hoy** — Un aviso de dos líneas evita cinco llamadas y una mala impresión.

> [!IMPORTANT]
> El tercer punto es el que más valora quien está al otro lado. Un plazo que se retrasa avisado se gestiona; el mismo plazo sin avisar se convierte en un problema de confianza que dura mucho más que la incidencia.

## Qué se puede seguir haciendo

| Sí | No conviene |
| --- | --- |
| Hacer fotos y prepararlas para subir después | Volver al papel «solo por hoy» |
| Llamar a quien tiene pendiente algo | Mandar el mismo envío varias veces |
| Redactar y dejar preparado | Rehacer trabajo que quizá esté guardado |
| Y anotar lo que va pasando, con hora | Dar por perdido lo que estaba en curso |

> [!WARNING]
> La segunda fila de la derecha es la que más consume y la que más lío genera después: reintentar un envío que sí salió deja al destinatario con tres correos idénticos y a vosotros con tres acciones cobradas. Comprobad el estado antes de repetir nada.

## Volver a la normalidad

**En corto**

- Subid lo que se hizo fuera del sistema, ese mismo día.
- Revisad si algo quedó a medias antes de darlo por hecho.
- Y anotad qué pasó en el expediente afectado, si tuvo consecuencias.

Ese último punto no es burocracia: si un plazo se incumplió por una caída, poder decir cuándo empezó y cuándo se resolvió cambia por completo la conversación.

> [!NOTE]
> La cuarta fila de la izquierda —anotar con hora— es lo que después permite explicarlo. Reconstruir tres días más tarde a qué hora dejó de funcionar algo es imposible y suena a excusa.

**¿Se pierde lo que estaba escribiendo?**

Lo guardado está; lo que no llegó a guardarse, no. Ante la duda, comprobad antes de rehacer.

**¿A quién aviso si es general?**

A quien esperaba algo vuestro. La incidencia técnica ya está en curso.

**¿Y si es solo lento?**

Trabajad en lo que no dependa de subir ficheros grandes y dejadlos para después.

## Ejemplos

**Un equipo pierde una mañana reintentando envíos durante una incidencia.**

- Comprueba si es general y avisa a los clientes con entrega ese día
- Prepara fotos y borradores para subir después

→ La tarde se recupera entera y ningún destinatario recibe envíos duplicados.

**Algo no funciona y el equipo se queda parado media mañana.**

- Comprueba si le pasa a más gente o solo a uno
- Sigue por la vía alternativa mientras se resuelve
- Reporta con la hora, la pantalla y el código de error

→ El trabajo no se detiene y soporte empieza con un diagnóstico en lugar de una pregunta.

**Se reporta «no va» sin más detalle.**

- Describe qué se esperaba y qué ocurrió

→ La primera respuesta ya es útil.

**Cinco personas reportan lo mismo por separado.**

- Comprueba si ya hay un caso abierto

→ Se trabaja una vez sobre el problema.

**Se espera a que se arregle sin avisar a los proveedores.**

- Avisa a quien esté esperando algo

→ Nadie de fuera se queda sin explicación.

**Se resuelve y no queda constancia de qué pasó.**

- Registra la incidencia y su resolución

→ La próxima vez se resuelve en minutos.