База знаний
Для статей базы знаний хочется дополнительные настраиваемые поля, одного раздела лично мне мало ;)
И чтобы по этим полям посетитель мог фильтровать статьи.
Кроме этого хочется настраивать список популярных статей базы знаний, который отображается на главной странице центра поддержки.
Чтобы показать посетителю важную информацию вне зависимости от ее популярности.
6 комментариев
-
О каких именно дополнительных настраиваемых полях идет речь?
По фиксированным статьям, которые пользователь должен видеть в любом случае, идея понятна. -
На моем примере. Я работаю с 1С и мне хотелось классифицировать статьи и обращения по: конфигурациям 1С, разделам учета. Это первое что приходит в голову. -
Более того, точно такие же дополнительные поля хотелось бы видеть и для обращений пользователей. При этом пользователя не утруждать их заполнением.
В итоге хочется единую сквозную классификацию обращений и статей базы знаний не только по разделам, но и по другим настраиваемым полям. -
Мозг разбушевался и просит множественный выбор в этих "дополнительных полях". В примере: чтобы можно было указать что обращение связано с интеграцией двух конфигураций ;)
-
Дополнительные поля данных для пользователей будут. Об этом вкратце сказано в статье - https://support.omnidesk.ru/knowledge_base/item/11 Правда, очевидно, что вам нужно несколько иное.
Что же касается последнего предложения, четкой картинки того, чего вы хотите, не складывается. Все обращения распределяются по группам. Обращения не имеют отношения к разделам базы знаний, которые предназначены для структурирования последней. Если вам нужна какая-то классификация для себя, то просто помечайте обращения метками, которые будут иметь такие же названия, как и разделы базы знаний.
Статьи пишутся для того, чтобы пользователи могли без вашей помощи находить ответы на интересующие их вопросы. Обращения создаются тогда, когда возникает вопрос или проблема, которые требуют их решения. По сути это разные вещи, "сквозная классификация" которых мало чем поможет. -
Я попробую развернуть объяснение. ;)
Хорошо когда работа связана с одним единственным проектом. Замечательно когда этот проект твой от макушки до пят. Чудесно когда проект не имеет отношения к автоматизации того, что придумывают наши законотворцы. Но такое бывает не всегда.
В моей работе часто важно понимать о чем вообще идет речь. ;)
О какой платформе? А их как минимум 3.
О какой конфигурации? А их как минимум штук 10.
И о каких объектах? А их от 300 в каждой конфигурации.
Ах да! У платформ и у конфигураций есть еще и релизы ;)
Совершенно одинаковые по смыслу обращения пользователей могут иметь разные для них решения если конфигурации или платформы будут разные. После такой классификации нового обращения, хочется получить отбор по этой же классификации ранее обработанных обращений, чтобы не изобретать велосипед.
После обработки множества обращений, хочется увидеть, а где собственно больше всего проблем? Где они повторяются? И после этого написать для моих многострадальных пользователей небольшую статейку.
И когда я напишу статью базы знаний, хочется чтобы пользователь для начала мог ее просто найти. И найти не кучу похожих, а именно для своего набора платформа+конфигурация.
Да, классификация статей БЗ может не совпадать с классификацией обращений, но иногда она совпадает. ;) И как впихнуть весь мой зверинец в одномерный список(метки для обращений или разделы для БЗ) , или еще хуже - в два ничем не связанных одномерных списка, я не представляю.
И еще не ясно как будет вести себя omnidesk если метки будут выглядеть примерно вот так:
1С:Предприятие 8.3 (8.3.4.465)
Управление торговлей, редакция 11.1 (11.1.5.16) -
Так бы с самого начала, Александр :)
На самом деле в вашем конкретном случае не нужно изобретать велосипед. Метки для обращений и разделы для статей позволят вам добиться нужного результата.
Метки, конечно, можно писать и в виде "Управление торговлей, редакция 11.1 (11.1.5.16)", но я думаю, вы легко можете их сократить (к примеру, УТ 11.1 (11.1.5.16). В целом же система меток сильно поможет вам. На сервисе есть возможность просмотривать количество обращений по каждой метке, делать фильтрацию и т.д. Соответственно, вы сможете сделать правильные выводы и понять, какие статьи нужно писать.
Со статьями и разделами также не возникнет проблем. К примеру, вы можете создать разделы по платформам или кофигурациям, а сами статьи по объектам. У пользователей есть поиск, по которому они без труда найдут нужную статью (объект). -
Решил было проверить на практике. И тогда понял почему вы предложили сократить метку.
У вас ограничение на количество символов.
И это похоже окончательно перечеркивает возможность использования сервиса. И вот почему:
Я не хочу отвлекаться на сокращение меток, я их копирую из 1С. Это лишняя работа и неизбежные ошибки при ручной корректировке. Кроме того, если с платформами и конфигурациями я могу представить как сократить, то как сократить РегистрСведений.ЗапросыАдминистрированияРазрешенийИспользованияВнешнихРесурсов ? И главное как потом понять, что имелось ввиду под этим сокращением? ;) И как по этому сокращению потом найти реальный объект в базе?
Как-то так... -
Что ж, очень жаль. Делать метки неограниченными по длине мы не будем. У вас слишком специфичные нужды, чтобы подгонять под них весь проект.
Может попробуете использовать заметки? Определять количество можно будет с помощью поиска. Правда, в этом случае вы не сможете видеть весь список различных заметок с количеством обращений, к которым они относятся (как было бы с метками).