Хорошее описание ошибки.

Банально, но факт - скорость решения проблем пользователей напрямую зависит от опыта специалистов службы поддержки, причем не только тех кто собственно эти проблемы решает, но также и тех кто проблемы регистрирует (так называемая 1 линия поддержки).

Возьмем, для примера, заявку увидев которую и возникло желание написать этот пост:
Заявка от пользователя, зарегистрированная сотрудником 1 линии поддержки:

Просьба рассмотреть вопрос и принять необходимые меры по внесению своевременных изменений данных в базе товара Axapta. Менеджеры говорят о том, что резервируемое кол-во тех или иных позиций в течение нескольких часов / дня не списывается, что приводит к неверному информированию секретарями клиентов. Таким образом, преподносимая информация на 2-ю половину дня не является актуальной.

А вот ответ более опытного коллеги, сразу чувствуется, что второй матерый:

Не понятно:
Какие своевременные изменения должны происходить в Аксапте?
По словам каких менеджеров?
Что значит резервируемое количество тех или иных позиций?
Что значит резервируемое количество не списывается?
Куда преподносится информация и почему считается, что она не актуальна?
Где смотрится данная информация (полный путь)?
Абсолютно не понятна проблема пользователя.
Следует уточнить, что и где смотрит пользователь, какие данные хочет получить и какие ошибки возникают?
Если пользователь считает что какие то данные не актуальны, то нужны конкретные примеры.

Очевидно, что чем меньше вот таких переписок, тем лучше работает поддержка.
Поэтому нужно не забывать обучать новых сотрудников 1 линии грамотно фиксировать обращения пользователях об ошибках.

Просто покажите новичку такую памятку:

Вопросы, которые необходимо задавать пользователю для уточнения сути возникшей проблемы:

1. При работе в каком приложении происходит ошибка? Программа должна быть одной из списка, программ на сопровождении. При этом требуется узнать конкретное название программы.
2. Какое действие делает пользователь перед возникновением ошибки? Желательно указать пункт меню.
3. Как должно быть? Какой результат ожидал получить пользователь? Например:
   • ввести данные
   • напечатать отчет
   • что еще?
4. Желательно узнать, когда пользователь перестал получать ожидаемый результат. Другими словами, когда работало? Например, «Вчера в 18:30 программа работала, а сегодня в 10:00, уже нет»
5. Если ошибка происходит при входе пользователя в программу, то необходимо выяснить выполнил ли пользователь вход в сеть.
6. Нужно узнать, есть ли еще пользователи, выполняющие такие же (или аналогичные) действия, у которых при этом нет проблем.
7. Если пользователь сообщает о проблеме с каким-то отчетом, то нужно узнать параметры, заданные при формировании отчета.

Каждое хорошее описание ошибки должно содержать ровно три вещи:

1. Какие шаги привели к ошибке.
2. Что вы ожидали увидеть.
3. Что вы в самом деле увидели.