Прежде всего, я бы начать представлять себя:
Уважаемые XYZ команда поддержки
Я веб-разработчик отвечает за веб-сайт example.com.
Представляя вас таким образом, вы устанавливаете фрейм, чтобы относиться к вам, намекая, что вы должны быть somewhat опытным, так что они могли бы выбрать ответ в более технических деталях. Обратите внимание, что если на самом деле это была ваша ошибка (например, не найти изменения, потому что вы подключались к неправильному веб-хосту), тем выше знания, которые вы подразумевали, чтобы иметь, скорее всего, они будут смотреть свысока на вас, как на плохого “эксперта” (несмотря на то, что все мы делаем глупые ошибки время от времени).
Я не думаю, что сказать им, что вы “администратор” сайта, передает это, так как это может относиться к любому, у кого есть учетная запись администратора на CMS, независимо от их квалификации.
Не то, чтобы это будет иметь большое значение после того, как они закроют билет. Если только вы не связываетесь с ними так часто, что они помнят вас, что было бы неплохо, если бы у них было хорошее мнение, и, вероятно, это означает, что они будут отуплять еще больше, если они думают, что вы понятия не имеете вообще.
Во-вторых, объясните четко проблему:
Мой клиент испытывает проблему, когда его WordPress 4.9.4 установка не показывает обновленный контент после редактирования. Он утверждает, что это происходит на разных компьютерах и в разных браузерах. В конце концов, он будет показан, хотя.
Я заявляю о проблеме, технологии, использованной до фактической версии. А также, факты, которые вы не проверили себя, квалифицируются как таковые (не будет маловероятно, что вам сказали что-то не так).
В-третьих, укажите устранение неполадок, которые вы уже сделали, и их результаты:
Не установлен плагин кэширования, а опция “Показывать несвежий контент”, которая доступна на сайте предпочтения отключена.
Тогда, вы можете выдвинуть свою гипотезу:
Есть ли у вас другие слои кэширования, которые могут повлиять на заказчика? Есть ли прокси-сервер кэширования (например, кальмар или лак), обслуживающий страницы перед обслуживанием Apache?
Здесь вы предполагаете, что есть прокси-сервер, обслуживающий кэшированные страницы. Упоминание актуальных пакетов может быть полезно в том случае, если команда поддержки не знала о “кэшировании прокси”, но помнит, что там установлено нечто под названием “лак”.
Спасибо за внимание
Будьте вежливы в своих билетах, храните идентификаторы билетов на тему, позаботьтесь о своей орфографии, организовывайте текст в параграфах. Текст, который приятно читать, будет проще обрабатывать, чем текст, в котором нужно угадать, о чем идет речь, и просто за это на него, скорее всего, ответят быстрее. Плюс усилия, потраченные на понимание, могут быть направлены на реальную проблему.
Включите скриншоты при необходимости (и поддерживается системой билетов). В тех же случаях они могут показать проблему лучше, чем текстовое описание (иногда там есть важный намек, который можно получить). Если вы используете командную строку, предоставьте и команду, и ее вывод.
Остерегайтесь, что слишком длинный текст может иметь обратный эффект. Если вы думаете, что длинное объяснение на самом деле может отпугнуть ответ, вы можете организовать по-другому:
Уважаемая команда поддержки XYZ
Есть ли у вас слой кэширования перед вашим пакетом FooWebsites?
Проблема, с которой я сталкиваюсь, что клиент не видит сразу же изменения, которые он сделал в WordPress 4.9.4.
Я уже проверил следующие вещи:
(…)
Если некоторые данные длинные (например, отладочный файл), вы можете предоставить это на вложении. Таким образом, если это не имеет значения, это можно пропустить, не открывая. В зависимости от билетной платформы, в противном случае им может потребоваться прокрутить семь страниц логов, прежде чем читать следующий ответ.
Если есть некоторая дополнительная информация, они вряд ли будут нуждаться, вы можете просто предложить, чтобы предоставить его (“Я записал видео, выполняя шаги публикации и где проблема может быть видно, вы бы заинтересованы в этом?”).
Вы должны sometimes последующих признав, что их решение сработало. Особенно, если вы обращались в техподдержку. Вместо того, чтобы представлять список возможностей для исправления застоявшейся проблемы с контентом и не слышать обратно, приятно получить:
Большое спасибо, изменение этой опции в cPanel решило эту проблему. Вы - лучший!
Таким образом, HelpDesk может отметить проблему как исправленную и закрыть ее. Однако, возьмите его с зерном соли, так как может быть, что тикет уже был закрыт после их ответа, и спасибо им за то, что они снова его откроют (сгенерировав больше работы). Так что, если вы думаете, что так и будет, то, возможно, желательно этого не делать (особенно, если для них это был простой ответ). Если вы не знаете, в каком состоянии находится билет на их стороне, я бы порекомендовал отступить на сторону признания решения и спасибо. Люди, отвечающие вам, - люди (будем надеяться), и заслуживают того, чтобы к ним относились как к таковым. Как правило, очень просто записать такое сообщение “Спасибо”.
В общем, постарайтесь следовать инструкциям для постановки технических вопросов, таких как известный Эрик С. Рэймонд Как задавать вопросы Умный Путь .
Может потребоваться немного больше времени, чтобы заявить о том, что вы пытались, вместо того, чтобы просто сказать “WordPress не работает”, но таким образом вы представляете свое мастерство по вашей работе. И это может даже избавить вас от вопроса полностью (указание на проблему может намекнуть на решение, или предоставить способ, с помощью которого вы можете получить подтверждение того, что происходит само по себе). В любом случае, это будет быстрее, чем если бы они начали спрашивать вас “В каком случае это не работает, что вы пробовали?”, следуя скрипту.
я рекомендую отправить письмо/билетку вместо того, чтобы звонить. Если у вас нет дорогостоящего контракта на поддержку (и, вероятно, даже тогда), звонки будут обрабатываться на самом низком уровне, и, возможно, на самом деле нужно будет преобразовать это в билет при эскалации , как отметил цыган ). Если вы свяжетесь с нами по электронной почте, то информация, которую вы предоставили (а не так, как первый Tier понял некоторые части того, что вы сказали), будет доступна любому, кто будет обрабатывать билет (даже самому себе!), что позволит вам общаться менее шумно. Это также избавляет вас от необходимости объяснять все от начала до каждого агента каждый раз, когда вы переводитесь.
Вы упоминаете, что вы пишете много этих писем, и они являются пустой тратой вашего и всех elses времени. Я бы поспорил, что что-то не так, если Вам нужно потратить слишком много времени по отношению к “нормальной” работе, чтобы продолжать в том же духе. Возможно, вы не очень хорошо разбираетесь [в том, как установлен WordPress у ваших друзей], веб-хостинг делает некоторые необычные вещи, их техподдержка некомпетентна… В какой-то момент имеет смысл поменять провайдера.
Вы можете обнаружить, что даже если ваш вопрос кристально ясен, вам дают длинные ответы с множеством пунктов, не слишком относящихся к вашему вопросу, “тратя их время”. Например, после того, как вы спросили, на какой хост вам нужно ssh, они не только указывают, где его найти, но и как получить доступ по FTP и объясняют, как загрузить и запустить PuTTY.
Это не значит, что, не понимая, что вы умеете, они потратили много времени, чтобы объяснить вам основные понятия. Когда вопрос часто задается, будет шаблон решения, и на самом деле быстрее ответить на все объяснения, чем сократить до того, что было задано. Таким образом, если есть случай, когда остальное может быть полезным, имеет смысл оставить его, даже если он может быть немного избыточным для вашего профиля.
Наличие письменного сообщения идет в обе стороны, так как вы можете пропустить ответ на ту часть, где они объясняют то, что вы хотели. Тем не менее, если вам нужно запросить ответ, do прочитайте все и подтвердите, что это не было в другой части их ответа.
Тем не менее, как бы хорошо ни объяснялось все, иногда вы будете связываться с техподдержкой, которая будет fail, чтобы правильно адресовать ваш запрос в первый раз.