1. Безопасность
3голоса

Разграничение доступа для пользователей

Сейчас любой пользователь без авторизации в центре поддержки предприятия может ознакомиться с Предложениями и статьями из Базы знаний. Из-за нарушений прав доступа можно ознакомиться с предложениями, касающимися незакрытых недостатков на предприятии, либо информации не для всех; воровство статей, на которые тратится время и опыт.
Предложение оставить только форму авторизации.

5 комментариев
  • Вадим Кысса
    Посмотрим, как отнесутся к вашему предложению другие клиенты, но мне не совсем по душе идея закрытого центра поддержки. Вся его суть как раз в том, чтобы находить ответы и решения до обращения в службу поддержки, а также знакомиться с уже оставленными предложениями.

    Ничего плохого в том, что у пользователя есть возможность ознакомиться с базой знаний нет. Это не корпоративный блог, поэтому и статьи здесь совершенно другого плана (руководства, ответы на часто задаваемые вопросы и т.д.). Такую информацию, наоборот, нужно распространять.
  • Ананьев Андрей
    Хочется поддержать данную идею но, не в том варианте реализации, который предлагает Максим.

    Согласен что в базе знаний могут содержаться инструкции предназначенные узкому кругу лиц. К примеру, в нашей работе используются инструкции как для пользователей так и для IT специалистов. Соответственно давать простому пользователю технологическую карту IT специалиста в ряде случаев бесполезно, а в некоторых даже опасно, потому как выполнение таких инструкций подразумевает контроль промежуточных результатов. Пользователь же как правило получив такую инструкцию упорно пытается выполнить её до конца не обращая внимания на полученные результаты, чем зачастую усугубляет положение в случае если инструкция предполагала работу с инцидентом.

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

    В OTRS разграничение доступа реализовано следующим образом. 1 уровень ограничения, это ограничение доступа к разделам по связке клиент-группа. 2 уровень ограничения, это ограничение на уровне полей.

    То есть статья может состоять к примеру из 4 полей.
    1. сам вопрос (имеет тип доступа общий)
    2. общая инструкция (доступ общий)
    3. детальная инструкция со ссылками на источники доступные только по договорам (доступ для авторизованных клиентов)
    4. описание проблемы, способ диагностики, способы исправления (доступ только для сотрудника поддержки)

    ИТОГ

    1. Часть разделов доступны только клиентам входящим, к примеру, в группу "Поддержка 1С". Соответственно видят статьи только те клиенты у которых заключен договор на обслуживание "1С:Предприятие" (такие клиенты включаются в группу "Поддержка 1С")
    2. Если пользователь не авторизован он видит только краткую инструкцию, то есть базовое содержание FAQ ввиду того, что в принципе непонятно сможет ли он перейти по ссылкам из статьи FAQ, так как неизвестна его возможность иметь доступ к дополнительным источникам информации.
    3 Если пользователь авторизован, он видит в качестве ответа уже более подробный (пошаговый) вариант. В котором помимо всего прочего могут присутствовать ссылки на базы знаний вендоров. (какой смысл дублировать уже имеющийся детальный матариал, когда зачастую достаточно просто собрать сводную инструкцию,а интересующихся сверх-подробностями направлять напрямую на KB вендора)
    4. Сотрудник поддержки 1 линии может видеть то содержание которое видит клиент. Если он обладает достаточной квалификацией, то может помочь клиенту, подключившись к рабочему месту клиента удалённо, и действуя по закрытой от клиента технологической инструкции.

    Данная инструкция кстати пишется специалистами 2 и 3 линии на основе ранее апробированного и одобренного стандартного решения по описанному инциденту.

    В результате база знаний одна, просто разные люди видят в статье только нужную и полезную им информацию, плюс от клиента не оплатившего определённый уровень консультаций, закрывается халява.

    Что же касается функционала предложений. Здесь, полагаю, максимально допустимое и разумное решение - премодерация. Реализуется простым созданием не отображаемого в клиентом интерфейсе состояния и присвоением его по умолчанию новым предложениям. Такой способ реализации фактически применяется на многих существующих обратной связи, хотя на этот счёт у меня мнение отличное от большинства. Функционал предложений есть не что иное, как "книга отзывов и предложений". Средство разработанное ещё во времена СССР и направленное на создание способа открытого контакта с клиентом. Предложения надо не скрывать, а работать с ними и показывать реальные результаты работы, так чтобы действительно их видели другие. Ведь отзывы на лендингах любят вывешивать.

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

    Здесь хорошо работает такой приём. Негативный отзыв перенаправляется во внутреннюю переписку а во вне лишь отмечается дата и вариант принятого решения "удовлетворено/ не удовлетворено". Для экстремалов, можно указать причину почему "не удовлетворено". Хотя в этом тоже ничего страшного нет, если причина ссылается на (также открыто доступный) регламент, принимаемый либо письменно (рекомендуется в B2B), либо в виде электронной оферты. В результате и "больную мозоль" наружу не выставляем и даём остальным информацию что такие обращения мы тоже готовы рассматривать.

    "Мы белые и пушистые, улыбаемся и машем" - Мадагаскар (с)

    В общем. Частично за. Продуманное разграничение доступа к разделам/статьям FAQ - плюс. Ограничение доступа к предложениям - минус.
  • Вадим Кысса
    Описанный вами вариант разграничения доступа к разделам и статьям звучит неплохо. Подумаем над реализацией чего-то подобного.
  • Ананьев Андрей
    Вадим, я совсем упустил из виду ещё один параметр настройки статей KB в OTRS.

    В ней существуют ещё и статусы самих статей.
    public
    customer
    internal

    Я полагаю и без перевода понятно о чём идёт речь.
  • Ананьев Андрей
    Кстати.
    Вот вам наш региональный пример работы с предложениями.
    https://uslugi.tatarstan.ru/open-gov
  • Андрей Назаров
    Добавлю 5 копеек.
    Причина, по которой нельзя показывать всё всем - это то, что компания, чей helpdesk может оказывать услуги техподдержки для разных конкурирующих предприятий и им не нужно видеть одно и то же.
  • Вадим Кысса
    Спасибо за обратную связь. Тот факт, что этот функционал интересует не только одного клиента, повышает шансы на его реализацию :)
  • Елена Кучерявенко
    Вадим, а как в итоге этот функционал сейчас работает?
    Я очень не хочу, чтобы все вопросы наших клиентов были в общем доступе. Во-первых, там есть конфиденциальная информация. Во-вторых, клиенты пишут нам идеи по новым функциям - в этом наше конкурентное преимущество. Каждый месяц появляется 3-5 копирующих нас сервисов. Мы совершенно не хотим радовать их нашей клиентской базой и базой идей наших клиентов.
  • Вадим Кысса
    Вы можете настроить удалённую аутентификацию (http://blog.omnidesk.ru/post/113430416459) и пускать в центр поддержки только тех, клиентов, которые должны иметь к нему доступ.

    Также вы можете в принципе отказаться от центра поддержки и принимать предложения/вопросы клиентов по почте.