Em primeiro lugar, gostaria de começar por me apresentar:
Cara equipa de suporte XYZ
Sou o programador web responsável pelo site example.com.
Ao apresentá-lo desta forma, está a estabelecer o quadro para o tratar, sugerindo que deve ser suposto ser como proficiente, para que possam optar por responder com um detalhe mais técnico. Note que se de facto foi a sua falha (tal como não encontrar as alterações porque estava a ligar-se ao webhost errado), quanto maior for o conhecimento que implicou ter, é mais provável que o olhem para baixo como não sendo um bom “especialista” (apesar de todos nós cometermos erros parvos de vez em quando). ¹
Não creio que dizer-lhes que você é o “administrador” do site transmita isto, uma vez que isso poderia aplicar-se a qualquer pessoa com uma conta de administrador no CMS, independentemente da sua proficiência.
¹ Não que isso importe muito depois de fecharem o bilhete. A menos que os contacte com tanta frequência que eles lembrem-no, o que seria bom se eles tivessem uma boa opinião, e provavelmente significaria que eles ficariam ainda mais burros se pensassem que você não faz ideia.
Segundo, explique claramente o problema:
O meu cliente está a ter um problema em que a sua instalação do WordPress 4.9.4 não mostra o conteúdo actualizado após a edição. Ele afirma que isto acontece em diferentes computadores e browsers. No entanto, acabará por ser mostrado.
Estou a referir o problema, a tecnologia utilizada até à versão actual. E também, os factos de não se ter verificado estão a ser qualificados como tal (não seria improvável que lhe fosse dito algo que estivesse errado).
Em terceiro lugar, indique a resolução de problemas que já realizou e os seus resultados:
Não há nenhum plugin de cache instalado, e a opção “Mostrar conteúdo antigo” que está disponível nas preferências do site está desactivada.
Então, pode avançar a sua hipótese:
Tem alguma outra camada de cache que possa estar a afectar o cliente? Existe algum proxy de caching (como lulas ou vernizes) a servir as páginas antes de ser servido pelo Apache?
Aqui está a adivinhar que existe um proxy a servir páginas em caching. A menção de pacotes reais pode ser útil caso a equipa de suporte não conhecesse os “caching proxies”, mas lembra-se que existe algo chamado “verniz” instalado ali.
Obrigado pela sua atenção
Seja educado nos seus bilhetes, guarde os identificadores dos bilhetes sobre o assunto, trate da sua ortografia, organize o texto em parágrafos. Um texto que seja agradável de ler será mais fácil de manusear do que um texto em que precisa de adivinhar do que está a falar, e só por isso será provavelmente respondido mais rapidamente. Além disso, o esforço poupado na compreensão pode ser orientado para o problema real.
Incluir capturas de ecrã, se necessário (e suportado pelo sistema de bilhética). Nos mesmos casos podem mostrar o problema melhor do que uma descrição de texto (por vezes, há uma dica crucial que pode ser obtida). Se estiver a utilizar a linha de comando, forneça tanto o comando como a sua saída.
Tenha em atenção que fazer um texto demasiado longo também pode ter o efeito oposto. Se pensa que a explicação longa pode realmente desencorajar a resposta, pode organizar de forma diferente:
Prezada equipa de suporte XYZ
Tem alguma camada de cache em frente do seu pacote FooWebsites?
O problema que enfrento é que o cliente não vê imediatamente as alterações que realizou no WordPress 4.9.4.
Já verifiquei as seguintes coisas:
(…)
Se alguns dos dados forem longos (como um ficheiro de debug), pode fornecê-los num anexo. Desta forma, se irrelevante, pode ser saltado ao não abrir. Dependendo da plataforma do bilhete, podem ter de percorrer sete páginas de registos antes de ler a resposta seguinte.
Se houver alguma informação extra de que dificilmente precisariam, pode simplesmente oferecer-se para a fornecer (“Gravei um vídeo com as etapas de publicação e onde o problema pode ser visto, estaria interessado nele?”).
Deve por vezes seguir-se, reconhecendo que a sua solução funcionou. Especialmente se tiver andado para trás e para a frente com o suporte técnico. Em vez de apresentar uma lista de possibilidades para resolver o problema do conteúdo obsoleto e não ouvir de volta, é bom receber:
Muito obrigado, mudando essa opção no cPanel resolveu-o. Você é o melhor!
Desta forma, o HelpDesk pode anotar o problema tão resolvido como e fechá-lo. Mas leve-o com um grão de sal, pois pode ser que o bilhete já tenha sido fechado após a sua resposta, e agradecendo-lhes que o reabrissem (gerando mais trabalho). Por isso, se pensa que será esse o caso, talvez seja desejável não o fazer (especialmente se fosse uma resposta fácil para eles). Se não souber o estado do bilhete ao seu lado, recomendo que se engane ao reconhecer a solução e agradecendo, no entanto. As pessoas que vos respondem são humanos (esperemos) e merecem ser tratadas como tal. Em geral, é muito simples reclassificar tal mensagem de “Obrigado”.
Em geral, tente seguir orientações para colocar questões técnicas, como o famoso Eric S. Raymond How To Ask Questions The Smart Way .
Pode demorar um pouco mais a dizer o que tentou em vez de simplesmente dizer “WordPress não funciona”, mas dessa forma está a apresentar a sua proficiência pelo seu trabalho. E pode até poupar-lhe totalmente a pergunta (afirmar a questão pode sugerir uma solução, ou fornecer uma forma de obter confirmação do que está a acontecer por si mesmo). De qualquer forma será mais rápido do que se tivessem de começar a perguntar-lhe “Em que sentido não funciona, o que tentou?” seguindo um guião.
Recomendo o envio de um e-mail/ticket em vez de telefonar. A menos que você tenha um contrato de suporte caro (e provavelmente mesmo assim), as chamadas serão tratadas pelo nível mais baixo, e pode realmente precisar de converter isso em um bilhete se a escalada como observado por Gypsy ). Se contactar por e-mail, a informação que forneceu (não a forma como o primeiro nível compreendeu algumas partes do que disse) está disponível para qualquer pessoa que trate do bilhete (mesmo você!), o que permite uma comunicação menos barulhenta. Também o poupa de ter de explicar tudo desde o início a cada agente cada vez que é transferido.
Você menciona que escreve muitos destes emails e eles são um desperdício do seu tempo e de todos. Eu argumentaria que há algo errado se você precisa gastar muito tempo em relação ao trabalho “normal” para manter a coisa em dia. Talvez você não seja tão proficiente [na forma como o seu amigo WordPress está instalado], o webhost está a fazer algumas coisas incomuns, o seu suporte técnico é incompetente… A certa altura pode fazer sentido mudar de fornecedor.
Você pode descobrir que mesmo que a sua pergunta seja cristalina, estão a ser-lhe dadas respostas longas com muitos pontos não muito relevantes para a sua questão, “desperdiçando o tempo deles”. Por exemplo, depois de lhe perguntarem a que anfitrião deve ssh, eles não só indicam onde encontrá-lo, mas também como aceder por FTP e explicam como descarregar e executar o PuTTY.
Isto não significa que ao não perceberem que você é proficiente eles gastaram muito tempo para lhe explicar conceitos básicos. Quando há uma pergunta frequente, haverá um template para a solução, e na verdade é mais rápido responder explicando tudo do que reduzindo apenas o que foi pedido. Portanto, se houver um caso em que o resto possa ser útil, faz sentido deixá-lo mesmo que seja um pouco redundante para o seu perfil.
Ter uma comunicação escrita vai para os dois lados, pois pode folhear a resposta para a parte em que eles explicam o que você queria. No entanto, se precisar de voltar a perguntar, do leia tudo e confirme que não foi noutra parte da resposta deles.
No entanto, por muito bem explicado que esteja tudo, por vezes entrará em contacto com um suporte técnico que irá fail para responder adequadamente ao seu pedido da primeira vez.