O tempo que um chamado de suporte leva está apenas frouxamente relacionado a quão difícil é o problema subjacente. Uma questão genuinamente difícil que chega com tudo o que o fornecedor precisa pode andar rápido; uma simples que chega como três linhas de descrição pode ficar parada por dias, não porque alguém seja lento, mas porque as primeiras várias trocas são gastas pedindo os dados que deveriam ter estado no chamado desde o começo. Cada uma dessas trocas é uma ida e volta medida em horas ou em um dia útil, e elas se acumulam. A coisa mais eficaz que você pode fazer para acelerar um chamado é sem glamour: abri-lo completo. Isso significa reunir os artefatos que o fornecedor vai pedir antes de digitar a primeira palavra, para que a primeira coisa que um engenheiro de suporte faça seja trabalhar o problema em vez de pedir o básico.
O chamado é uma passagem, e deve se ler como uma
Uma boa escalação é escrita para a pessoa que a recebe, que conhece o produto mas não sabe nada sobre o seu ambiente ou o seu incidente. Esse enquadramento dita a estrutura. Ela abre com uma declaração de problema escrita antes de você começar a digitar — o que está quebrado, o que você esperava em vez disso e o sintoma mais claro — porque uma declaração de problema vaga ou em evolução é a coisa mais lenta de triar. Ela informa a severidade e, crucialmente, o impacto ao negócio, porque o impacto é o que define a severidade que o fornecedor atribui; um chamado de serviço fora sem impacto declarado com frequência é classificado abaixo do que a situação justifica. Ela dá o ambiente: o produto afetado e a versão exata, e onde ele fica, porque uma incompatibilidade de versão é uma primeira pergunta frequente e a resposta estar ali economiza uma ida e volta. E ela é honesta sobre o que você já tentou, porque mostrar o que você já descartou permite ao engenheiro pular isso em vez de pedir que você repita.
Os diagnósticos são a diferença
A parte que mais confiavelmente determina se um chamado anda é a evidência de diagnóstico anexada a ele. Quase todo fornecedor vai, como um primeiro pedido quase reflexo, solicitar o próprio pacote de diagnóstico do dispositivo afetado — capturado enquanto o problema está presente, se de todo possível, porque um pacote tirado após a recuperação costuma mostrar um sistema saudável. Anexá-lo de antemão simplesmente elimina essa primeira ida e volta. O texto exato do erro, copiado literalmente em vez de parafraseado, importa mais do que parece: é a cadeia que o engenheiro usa para buscar na própria base de conhecimento interna, e uma paráfrase não casa. Para problemas que tocam o tráfego, uma captura de pacotes tirada no ponto da falha, filtrada para o fluxo afetado e com o ponto de captura anotado, transforma uma descrição em evidência. Logs cobrindo a janela da falha, com carimbos de tempo e o fuso horário declarado, fazem o mesmo. Nada disso é exótico; é o conjunto padrão, e a diferença entre um chamado rápido e um lento costuma ser apenas se foi reunido antes de o chamado abrir ou pedido depois.
A reprodutibilidade muda o que coletar
Quão repetível é o problema deveria moldar a evidência que você prepara. Um problema que você consegue reproduzir sob demanda é o melhor caso para o fornecedor, porque um chamado que eles conseguem reproduzir no próprio laboratório anda mais rápido de todos — então passos exatos de reprodução se tornam o artefato de maior valor que você pode fornecer. Um problema intermitente é o difícil: você não consegue invocá-lo, então o trabalho é preparar a captura e o registro agora, antes da próxima ocorrência, para que, quando acontecer de novo, ela seja registrada em vez de perdida. Um problema que aconteceu uma vez e não recorreu deixa os logs daquela janela como o seu registro primário, o que torna coletá-los antes que rolem uma prioridade. Casar a evidência que você reúne com a reprodutibilidade do problema é a diferença entre esperar por uma recorrência que você não controla e ter a recorrência já capturada quando ela vier.
Completo é uma lista de verificação, não uma sensação
"Abrir o chamado completo" é fácil de concordar e fácil de pular sob pressão, que é exatamente quando uma lista de verificação prova o seu valor. O movimento útil é tratar o estado pré-abertura como uma lacuna a fechar: liste os artefatos que um chamado com este formato precisa, marque o que você já tem, e deixe o que resta ser a lista curta e concreta do que coletar antes de abrir. Uma lista também resiste à pressão de um Sev 1, em que a tentação é abrir imediatamente com o que estiver à mão — mas um chamado de serviço fora com um pacote magro ainda empaca no primeiro pedido de dados, então reunir os essenciais mesmo sob pressão é mais rápido no todo, não mais lento. O objetivo não é burocracia; é que o chamado chegue como uma passagem que um engenheiro consegue pegar e trabalhar, que é todo o ponto de escalar em primeiro lugar.