Como gerenciar a comunicação durante o tempo de inatividade do aplicativo?

Ultimamente, tenho tido muitas experiências com o tempo de inatividade de aplicativos, tanto de fornecedores quanto de meus próprios aplicativos. Isso me fez pensar e, da melhor maneira que posso pesquisar no Google, não existe realmente uma maneira boa ou padrão de gerenciar a comunicação do cliente durante incidentes de inatividade.

Eu já vi isso de várias maneiras, desde a abordagem "culpar todos, menos nós" à abordagem "estragamos tudo e desculpe" .

Então, minhas perguntas são ... quando você estraga um aplicativo e causa um tempo de inatividade:

1. Você reconhece a culpa imediatamente? (Você deveria legalmente?)
2. Quanta informação você fornece ao cliente sobre o que deu errado? ("Um problema" vs. "Um erro de sintaxe de código em uma de nossas consultas SQL")
3. Você volta com um plano de prevenção de acompanhamento ou apenas o deixa em "isto foi resolvido"?
4. Você fornece atualizações em tempo real? Com que frequência? Via Twitter ou site público?

Quaisquer outras práticas recomendadas para isso que você considerou bem-sucedidas?

Aqui está o que eu faço:

• Declare com clareza quais são as consequências (agora e no futuro imediato). Destaque as prováveis ​​conseqüências permanentes ou a falta delas (perda de dados, perda de horas dos funcionários).
• Mantenha o tom muito neutro. Não gaste energia com culpa / culpa. Idealmente, isso indica "Quero fornecer informações, mas minha atenção também é necessária em outros lugares".
• Sua notificação será encaminhada para muitas pessoas. Verifique se o seu CEO entende a essência no primeiro semestre. Normalmente, forneço um "resumo executivo". Detalhes técnicos podem fornecer informações básicas para outras pessoas técnicas.
• Forneça detalhes de contato (de preferência alguém que tenha tempo de inatividade) para perguntas adicionais e peça paciência na mesma frase (isso geralmente funciona).
• Prometa atualizações quando a situação mudar.

Envie atualizações quando houver boas notícias, antes do horário de encerramento do escritório ("toda a equipe continuará durante a noite" - contabilize fusos horários, se necessário) e novamente no horário de funcionamento do escritório.

Quando o problema for resolvido (para qualquer definição dessa palavra), envie:

• Um resumo incluindo o tempo das consequências
• As ações / mudanças realizadas em curto prazo e planejadas para o futuro ("lições aprendidas"); baseado em:
• Análise técnica de causa raiz

Mantenha todos os pedidos de culpa, culpa ou linchamento em e-mails separados, de preferência após algum tempo de espera.

Não se comprometa com nada durante o tempo de inatividade, a menos que você tenha muita certeza de que pode entregar. De alguma forma, duas situações separadas de "más notícias" são piores do que longas.

Prefiro usar um meio em que uma notificação é enviada a cada mensagem (e-mail, Twitter, ..)

A coisa mais importante que encontrei tanto como provedor de serviços quanto como usuário é responsabilidade proativa. Não é possível o que você diz, mas quando (quando) você diz.

Se você for notificado de que um problema aconteceu e foi corrigido (ou está sendo trabalhado), é muito melhor do que descobrir o problema e tentar entrar em contato com o fornecedor para descobrir o que está acontecendo no mundo. Também ajuda no jogo da culpa e economiza muito tempo para solucionar problemas (somos nós ou são eles?).

Quanto aos detalhes, acho que fornecer um resumo simples do que aconteceu é bom, a menos que os usuários solicitem mais informações especificamente. Algumas pessoas sempre querem o máximo de detalhes possível, mas a maioria quer apenas que as coisas funcionem (mesmo que sejam altamente técnicas).

Por fim, ser capaz de explicar quais as medidas que você tomou para que isso não aconteça novamente contribuem muito para a futura boa vontade e confiança.

Sem saber muito mais sobre seu aplicativo em particular, como ele é licenciado, o campo em que você presta serviços, etc; é impossível responder suas perguntas sem adivinhar.

1. Possuir seus próprios erros geralmente é o caminho. Consulte o seu advogado se o seu campo for um onde muitas leis, SLAs ou contratos meticulosos se aplicam.
2. É uma linha tênue entre muitos e poucos detalhes. Em geral, detalhes suficientes para que um usuário comum sinta que entende.
3. Se é um erro pequeno e rapidamente corrigido; não me debruças sobre isso. Se foi realmente um grande erro, você tem o controle de danos para fazer.
4. Pequenos erros, notifique quando estiver inoperante e quando estiver consertado. Grandes erros, notifique quando alguma etapa da solução for alcançada.

Prefiro que meus fornecedores forneçam muitas informações sobre períodos de inatividade. Mas muitas empresas simplesmente não podem ou são fechadas pelos advogados. Consulte seu advogado / seguro se você tiver alguma dúvida.