En primer lugar, empezaría presentándome:
Estimado equipo de soporte de XYZ
Soy el desarrollador web a cargo de la página web example.com.
Presentándote de esta manera, estás estableciendo el marco para tratarte, insinuando que se debe presuponer que eres algo competente, para que puedan elegir responder con un detalle más técnico. Tenga en cuenta que si en realidad fue su culpa (como no encontrar los cambios porque se estaba conectando al webhost equivocado), cuanto mayor sea el conocimiento que usted insinuó tener, es más probable que le menosprecien por no ser un buen “experto” (aunque todos cometemos errores tontos de vez en cuando). ¹
No creo que decirles que eres el “administrador” del sitio web transmita esto, ya que eso podría aplicarse a cualquiera con una cuenta de administrador en el CMS, independientemente de su competencia.
¹ No es que importe mucho después de que cierren el ticket. A menos que te pongas en contacto con ellos tan a menudo que te recuerden, lo cual sería bueno si tienen una buena opinión, y probablemente signifique que se quedarán aún más callados si piensan que no tienes ni idea.
En segundo lugar, explica claramente el problema:
Mi cliente está experimentando un problema en el que su instalación de WordPress 4.9.4 no muestra el contenido actualizado después de la edición. Afirma que esto ocurre en diferentes ordenadores y navegadores. Sin embargo, eventualmente se mostrará.
Estoy declarando el problema, la tecnología usada hasta la versión actual. Y también, los hechos que no se verificaron están siendo calificados como tales (no sería improbable que le dijeran algo que está mal).
En tercer lugar, indique la solución de problemas que ya realizó y sus resultados:
No hay ningún plugin de caché instalado, y la opción “Mostrar contenido antiguo” que está disponible en las preferencias del sitio está desactivada.
Entonces, puede avanzar su hipótesis:
¿Tiene alguna otra capa de caché que pueda estar afectando al cliente? ¿Existe un proxy de cacheo (como el calamar o el barniz) que sirva las páginas antes de ser servidas por Apache?
Aquí está suponiendo que hay un proxy que sirve páginas en caché. La mención de los paquetes reales puede ser útil en caso de que el equipo de soporte no supiera de los “caching proxies”, pero recuerda que hay algo llamado “barniz” instalado allí.
Gracias por su atención
Sea cortés en sus tickets, mantenga los identificadores de los tickets sobre el tema, cuide su ortografía, organice el texto en párrafos. Un texto que sea agradable de leer será más fácil de manejar que uno en el que hay que adivinar de qué habla, y sólo por eso probablemente será contestado más rápido. Además el esfuerzo ahorrado en la comprensión puede ser dirigido al problema real.
Incluya capturas de pantalla si es necesario (y con el apoyo del sistema de tickets). En los mismos casos pueden mostrar el problema mejor que una descripción de texto (a veces, hay una pista crucial que se puede obtener). Si está usando la línea de comandos, proporcione tanto el comando como su salida.
Tenga en cuenta que hacer un texto demasiado largo puede tener también el efecto contrario. Si crees que la explicación larga puede desalentar la respuesta, puedes arreglar de otra manera:
Estimado equipo de soporte de XYZ
¿Tienes alguna capa de caché delante de tu paquete FooWebsites?
El problema al que me enfrento es que el cliente no ve inmediatamente los cambios que ha realizado en WordPress 4.9.4.
Ya he comprobado lo siguiente:
(…)
Si algunos de los datos son largos (como un archivo de depuración), puede proporcionarlos en un archivo adjunto. De esta manera, si es irrelevante, puede ser omitido al no abrirse. Dependiendo de la plataforma de tickets, puede que de otra manera necesiten desplazarse hacia abajo siete páginas de registros antes de leer la siguiente respuesta.
Si hay alguna información extra que probablemente no necesiten, puede simplemente ofrecerse a proporcionarla (“Grabé un vídeo realizando los pasos de publicación y donde se puede ver el problema, ¿le interesaría?”).
Debería a veces hacer un seguimiento reconociendo que su solución funcionó. Especialmente si ha estado de ida y vuelta con el soporte técnico. En lugar de presentar una lista de posibilidades para arreglar el problema de contenido rancio y no escuchar de nuevo, es agradable recibir:
Muchas gracias, cambiar esa opción en cPanel lo solucionó. Eres el mejor!
De esta manera, el HelpDesk puede anotar el problema como solucionado y cerrarlo. Sin embargo, no hay que olvidar que puede ser que el ticket ya haya sido cerrado después de su respuesta, y agradecerles que lo reabrieran (generando más trabajo). Así que si piensan que este será el caso, puede ser deseable no hacerlo (especialmente si fue una respuesta fácil para ellos). Si no conoces el estado del billete a su lado, recomendaría errar en el lado de reconocer la solución y Gracias, sin embargo. Las personas que responden son humanos (esperemos), y merecen ser tratados como tales. Generalmente es muy simple volver a cerrar el mensaje de “Gracias”.
En general, trata de seguir las pautas para plantear preguntas técnicas, como el famoso Eric S. Raymond How To Ask Questions The Smart Way .
Puede que te lleve un poco más de tiempo declarar lo que intentaste en lugar de decir simplemente “WordPress no funciona”, pero de esa manera estás presentando tu competencia por tu trabajo. Y puede incluso ahorrarle la pregunta por completo (declarar la cuestión puede sugerir una solución, o proporcionar una manera de obtener una confirmación de lo que está sucediendo por sí mismo). De todos modos será más rápido que si tuvieran que empezar a preguntarte “¿En qué sentido no funciona, qué has intentado?” siguiendo un guión.
Recomiendo enviar un correo electrónico/ticket en lugar de llamar. A menos que tengas un contrato de soporte caro (y probablemente incluso entonces), las llamadas serán atendidas por el nivel más bajo, y puede que en realidad necesite convertirlo en un ticket si se escalan como ha señalado Gypsy ). Si contactas por correo electrónico, la información que proporcionaste (no la forma en que el primer nivel entendió algunas partes de lo que dijiste) está disponible para cualquiera que maneje el ticket (¡incluso para ti mismo!), lo que permite una comunicación menos ruidosa. También te ahorra tener que explicar todo desde el principio a cada agente cada vez que te transfieren.
Mencionas que tú escribes muchos de estos correos electrónicos y son una pérdida de tu tiempo y el de todos los demás. Yo diría que hay algo malo si necesitas pasar demasiado tiempo en relación con el trabajo “normal” para mantener la cosa. Quizás no seas tan competente [en la forma en que están instalados tus amigos de WordPress], el webhost está haciendo cosas poco comunes, su soporte técnico es incompetente… En algún momento puede tener sentido cambiar de proveedor.
Puede que descubras que incluso si tu pregunta es muy clara, te están dando largas respuestas con muchos puntos no muy relevantes para tu asunto, “perdiendo su tiempo”. Por ejemplo, después de preguntar a qué host deberías ssh, no sólo están indicando dónde encontrarlo, sino también cómo acceder por FTP y explicando cómo descargar y ejecutar PuTTY.
Esto no significa que al no entender que eres competente hayan pasado mucho tiempo para explicarte los conceptos básicos. Cuando hay una pregunta frecuente, habrá una plantilla para la solución, y en realidad es más rápido responder explicando todo que reducirse a sólo lo que se preguntó. Por lo tanto, si hay un caso en el que el resto puede ser útil, tiene sentido dejarlo aunque sea un poco redundante para tu perfil.
Tener una comunicación escrita va en ambos sentidos, ya que puedes hojear la respuesta a la parte en la que explican lo que querías. Sin embargo, si necesita volver a preguntar, lea todo y confirme que no fue en otra parte de su respuesta.
No obstante, no importa lo bien explicado que esté todo, a veces se pondrá en contacto con un soporte técnico que fallará para atender adecuadamente su solicitud la primera vez.