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

1. Если у Вас есть доступ франча на сайт 1С, то там есть кусок их базы знаний. Непонятно, почему они его в общий доступ не выкладывают и почему даже для франчей лишь частично...

2. Телефонный help-desk с низкоквалифицированными операторами - бесполезен, к сожалению. Разумеется, это лишь мое humble opinion, но опыт ряда проектов (не только 1С) показывает, что самый лучший способ техподдержки такой:

- ключевые пользователи должны пройти качественное обучение (и, в дальнейшем, нести "сакральное знание" в массы); если пользователей немного - учить всех.
- необходимо развернуть issue tracker (мне нравится входящий в поставку OnTime, но на рынке дофига таких систем, в т.ч. и freeware)
- необходимо определить, кто из пользователей может писать в issue tracker. В ряде случаев можно ограничить к нему доступ с тем, чтобы продвинутые пользователи выполняли роль первой линии поддержки.
- необходимо обучить пользователей issue tracker'а
- на управление потоком issues нужно ставить одного из ведущих аналитиков; решение может показаться спорным, но так - гораздо эффективнее (проверено), особенно, если были серьезные доработки; главные требования к человеку: глубокое знание функционала системы и предметной области
- необходимо обеспечить для управляющего потоком issues возможность для делегирования как мелких вопросов (глупо как-то, если человек за $3-3,5K в месяц будет объяснять, как поиском пользоваться, скажем), так и вопросов, требующих глубоких технических знаний.
- хорошо, если issue tracker интегрирован с bug&feature tracker: часть issues превращаются в feature requests и bugs
- с определенной периодичностью нужно идти к пользователям и самому спрашивать, какие есть проблемы: удивительно, но некоторые пользователи упорно не хотят сами озвучивать возникающие у них проблемы (даже при отлично работающей техподдержке)

Уж извините за сумбурность изложения, но, надеюсь, что-то из написанного может Вам пригодиться.

Уважаемый Алексей,

"а можно поподробнее" - будете в Москве, я с радостью с Вами повстречаюсь. Пиво с куриными крылышками с Вас %-)

"где можно найти инфу про организацию поддержки с использованием issue tracker" - можно что-то почитать у производителей систем. А так: "опыт, сын ошибок трудных"

"уже внедрили т.с. планово-веерный опрос пользователей" - очень правильный шаг. Но есть одна важная особенность: походы "в народ" должны быть нерегулярными. Иначе пользователи будут игнорировать иные, более дешевые каналы техподдержки, зная, что "в четверг придет программист и все порешает".

"на данный момент поддержку по ВСЕМ вопросам работы с 1С осуществляют программисты " - очень настораживает термин "программист". Наводит на мысль, что у Вас роли аналитика, разработчика и тестера не разделены. Позволю себе еще раз повторить ранее изложенную идею: поток issues должен администрить мощный аналитик. Аналитик сам никакой разработки осуществлять не должен (в идеале: и уметь не должен). Аналитик должен:

- сортировать поступающие задачи по следующим категориям (мне кажутся удобными нижеприведенные, можно выдумать свои) и отправлять их дальше по workflow:

- "мелочевка": issues, обусловленные низкой квалификацией пользователей. Передаются на исполнение "мальчику на побегушках". Обязательно нужно отслеживать статистику "мелочевки" по пользователям.
- "методология": требуют внимания самого аналитика. Дальнейшая конкретика сильно зависит от предметной области, организации работы, отношений в компании...
- "очевидная техника": баги, мелкие feature requests. Передаются на исполнение одному из разработчиков, далее: стандартный workflow.
- "хитрая техника": "тяжелые" feature requests. Передаются на исполнение руководству, т.к. влияют на scope проекта.
- "администрирование": проблемы с правами доступа, "отвалившиеся" лицензионные ключи... Передаются на исполнение специалисту по технической архитектуре.

- управлять приоритетами задач для "выделенных" под техподдержку людей и участвовоать в управлении приоритетами задач для "расшаренных" людей. Утрясать конфликты с функциональными заказчиками, возникающие по поводу приоритетов.

- разруливать "методологические" issues

- внятно описывать bug & feature requests. Довольно редко можно тупо сделать из issue request bug или feature request: нужно уточнять задачу и описывать ее в удобоваримом для разработчика виде.

- участвовать в тестировании разработки по bug & feature requests.

- отслеживать закрытие issues. Issues должны закрываться пользователями.

Как-то так. Может, что-нибудь забылось...