¿Cómo gestionar la comunicación durante el tiempo de inactividad de la aplicación?

Últimamente he tenido muchas experiencias con el tiempo de inactividad de las aplicaciones, tanto de proveedores como de mis propias aplicaciones. Esto me ha hecho pensar y lo mejor que puedo buscar en Google no existe realmente una forma buena o estándar de administrar la comunicación con el cliente durante los incidentes de inactividad.

He visto que esto se maneja de muchas maneras desde el enfoque de "culpar a todos menos a nosotros" al enfoque de "nos equivocamos y lo sentimos" .

Entonces, mis preguntas son ... cuando arruinas una aplicación y provocas tiempo de inactividad:

1. ¿Admites culpa inmediatamente? (¿Deberías, legalmente?)
2. ¿Cuánta información le da al cliente sobre lo que salió mal? ("Un problema" frente a "Un error de sintaxis de código en una de nuestras consultas SQL")
3. ¿Vuelve con un plan de prevención de seguimiento, o simplemente lo deja en "esto se ha resuelto"?
4. ¿Proporcionan actualizaciones en tiempo real? ¿Con qué frecuencia? ¿A través de Twitter o sitio web público?

¿Alguna otra mejor práctica para esto que hayas encontrado exitosa?

Esto es lo que hago:

• Indique muy claramente cuáles son las consecuencias (en este momento y en el futuro inmediato). Destaque las posibles consecuencias permanentes o la falta de ellas (pérdida de datos, pérdida de horas de trabajo).
• Mantén el tono muy neutral. No gastes energía en culpa / culpa. Idealmente, esto transmite "Quiero darle información, pero mi atención también es necesaria en otros lugares".
• Su notificación se enviará a muchas personas, asegúrese de que su CEO comprenda la esencia del primer medio párrafo. Por lo general, proporciono un "resumen ejecutivo". Los detalles técnicos pueden proporcionar información de antecedentes a otras personas técnicas.
• Proporcione detalles de contacto (preferiblemente alguien que tenga el tiempo en el calor del tiempo de inactividad) para más preguntas y pida paciencia en la misma oración (esto funciona a menudo).
• Promete actualizaciones cuando la situación cambie.

Envíe actualizaciones cuando haya buenas noticias, antes de la hora de cierre de la oficina ("todo el personal continuará durante la noche", tenga en cuenta las zonas horarias si es necesario) y nuevamente alrededor de la hora de apertura de la oficina.

Cuando se resuelva el problema (para cualquier definición de esa palabra), envíe:

• Un resumen que incluye el tiempo de las consecuencias.
• Las acciones / cambios realizados a corto plazo y planificados para el futuro ("lecciones aprendidas"); Residencia en:
• Análisis técnico de la causa raíz

Mantenga cualquier llamada de culpa, culpa o linchamiento en correos separados, preferiblemente después de un tiempo de enfriamiento.

No se comprometa con nada durante el tiempo de inactividad a menos que esté realmente seguro de poder cumplir. De alguna manera, dos situaciones separadas de "malas noticias" son peores que una larga.

Prefiero usar un medio donde se envía una notificación en cada mensaje (correo, Twitter, ..)

Lo más importante que he encontrado tanto como proveedor de servicios como usuario de servicios es la responsabilidad proactiva. No es capaz de lo que dices, pero cuando (qué tan pronto) lo dices.

Si se le notifica que sucedió un problema y se solucionó (o se está trabajando), es mucho mejor que descubrir el problema usted mismo y tratar de comunicarse con el proveedor para averiguar qué está pasando en el mundo. También ayuda con el juego de la culpa y ahorra mucho tiempo de solución de problemas (¿somos nosotros o somos ellos?).

En cuanto a los detalles, encuentro que dar un resumen simple de lo que sucedió es bueno a menos que los usuarios soliciten específicamente más información. Habrá algunas personas que siempre deseen tantos detalles como puedan obtener, pero la mayoría de las personas solo quieren que las cosas funcionen (incluso si son altamente técnicas).

Por último, ser capaz de explicar qué pasos ha tomado para que no vuelva a suceder ayuda mucho a la buena voluntad y confianza futuras.

Sin saber mucho más acerca de su aplicación en particular, cómo tiene licencia, el campo para el que presta servicios, etc. Es imposible responder a sus preguntas sin adivinar.

1. Reconocer tus propios errores suele ser la ruta. Consulte a su abogado si su campo es uno donde se aplican muchas leyes, acuerdos de nivel de servicio o contratos meticulosos.
2. Es una delgada línea entre demasiado y muy poco detalle. En general, suficientes detalles para que un usuario común sienta que entiende.
3. Si es un error pequeño y rápidamente corregido; no te detengas en eso. Si fue un gran error, tienes que controlar el daño.
4. Pequeños errores, notifique cuando esté inactivo y cuando esté solucionado. Grandes errores, notifique cuando se hayan alcanzado los hitos de la solución.

Prefiero que mis proveedores brinden demasiada información sobre los tiempos de inactividad. Pero muchas empresas simplemente no pueden o los abogados las cierran. Consulte a su abogado / seguro si tiene alguna duda.