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

Question

Eu tive muitas experiências ultimamente com o tempo de inatividade de aplicativos, tanto de fornecedores quanto de meus próprios aplicativos. Isso me fez pensar e, da melhor forma, eu posso pesquisar no Google, não há realmente uma maneira boa ou padrão de gerenciar a comunicação com o cliente durante incidentes com tempo de inatividade.

Eu já vi isso acontecer de várias maneiras, da abordagem "culpe todos, menos nós" para a abordagem "nós erramos e sentimos muito" .

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

1. Você admite falta imediatamente? (Se você, legalmente?)
2. Quanta informação você dá 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 simplesmente o deixa em "isso foi resolvido"?
4. Você fornece atualizações em tempo real? Com que frequência? Via Twitter ou site voltado para o público?

Outras práticas recomendadas para isso que você achou bem-sucedidas?

    

Answer 1

Aqui está o que eu faço:

• Indique claramente quais são as consequências (agora e no futuro imediato). Destaque prováveis conseqüências permanentes ou falta dela (perda de dados, perda de horas de trabalho).
• Mantenha o tom muito neutro. Não gaste energia em culpa / culpa. O ideal é que isso transmita "eu quero lhe dar informações, mas minha atenção também é necessária em outro lugar".
• Sua notificação será encaminhada para muitas pessoas, certifique-se de que seu CEO entenda a essência no primeiro meio parágrafo. Normalmente eu forneço um 'resumo executivo'. Detalhes técnicos podem fornecer informações básicas a outras pessoas técnicas.
• Forneça detalhes de contato (de preferência alguém que tenha tempo no calor do tempo de inatividade) para perguntas adicionais e peça paciência na mesma frase (isso funciona com frequência).
• Promete atualizações quando a situação muda.

Envie atualizações quando houver boas notícias, antes do horário de encerramento do escritório ("toda a equipe continuará durante a noite" - conta com fusos horários, se necessário) e novamente em torno do horário de abertura 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 a curto prazo e planejadas para o futuro ("lições aprendidas"); com base em:
• Análise de causa raiz técnica

Guarde todas as chamadas para culpar, culpar ou linchar em e-mails separados, de preferência após algum tempo de resfriamento.

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

Eu prefiro usar um meio em que uma notificação é enviada em todas as mensagens (e-mail, Twitter, etc.)

    

Answer 2

A coisa mais importante que encontrei como provedor de serviços e como usuário do serviço é a responsabilidade proativa. Não é capaz o que você diz, mas quando (quanto tempo) 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 sozinho e tentar entrar em contato com o fornecedor para descobrir o que está acontecendo no mundo. Também ajuda com o jogo de culpas e economiza muito tempo de resolução de problemas (somos nós ou são eles?).

No que diz respeito aos detalhes, acho que fornecer um resumo simples do que aconteceu é bom, a menos que os usuários solicitem especificamente mais informações. Haverá algumas pessoas que sempre querem o máximo de detalhes que conseguirem, mas a maioria das pessoas só quer que as coisas funcionem (mesmo que sejam altamente técnicas).

Por fim, ser capaz de explicar os passos que você deu para que isso não aconteça novamente vai muito longe em direção à boa vontade e confiança futuras.

    

Answer 3

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

1. Adotar seus próprios erros é geralmente o caminho. Consulte o seu advogado se o seu campo é aquele onde muitas leis, SLAs ou contratos meticulosos se aplicam.
2. É uma linha tênue entre detalhes demais e mínimos. Em geral, detalhes suficientes que um usuário comum sentiria como se entendessem.
3. Se for um erro pequeno e rapidamente corrigido; não me debruçar sobre isso. Se foi um grande erro, você tem controle de danos para fazer.
4. Pequenos erros, notifique quando estiver inativo e quando estiver corrigido. Grandes erros, notifique quando quaisquer marcos da solução forem atingidos.

Eu prefiro que meus fornecedores forneçam muita informação sobre interrupções. Mas muitas empresas simplesmente não podem ou estão zipadas pelos advogados. Consulte seu advogado / seguro se tiver alguma dúvida.