Предложение «частной поддержки» в рамках сообщества общественной поддержки

[RGJ (Richard - Communiteq)]

Я уже какое-то время размышляю над этим вопросом и решил поделиться своими идеями в группе, чтобы узнать ваше мнение.

За последние несколько месяцев я говорил с довольно большим количеством людей, которые пытаются организовать прямую поддержку клиентов — где команда поддержки решает (конфиденциальные) специфические для клиента вопросы — в дополнение к существующему (публичному) форуму поддержки сообщества.
Большинство таких решений используют плагины «assign», «solved» и «ticket», и при этом существует несколько подходов (но, похоже, универсального решения нет, именно поэтому я создаю эту тему).

Решение №1: Создание отдельных категорий/групп для каждого клиента

Это работает только при относительно небольшом количестве клиентов, но не в случае, когда их сотни.

Решение №2: Описанное пользователем schungx в теме «Как использовать Discourse как закрытую систему поддержки/тикетов»

Главная проблема здесь заключается в следующем: «(…) что вы создаете специализированную тикетную платформу, или, как минимум, что пользователи интерфейса Discourse и пользователи, создающие тикеты поддержки, не пересекаются.»

Однако эта тема затрагивает одну из главных проблем: «Вы изучили систему безопасности и прав доступа, но не нашли того, что нужно: по сути, чистые права «Создать» и «Создать/Ответить» отсутствуют.» К этому я вернусь ниже.

Решение №3: Групповые почтовые ящики.

Первоначальная идея Сэма «Discourse как закрытый портал поддержки по электронной почте», которая трансформировалась в групповые почтовые ящики. Вы настраиваете групповой ящик, назначаете его команде поддержки, и каждый может отправлять сообщения или письма в этот ящик.
Сейчас это основное решение, и оно работает.

Однако мне оно не очень нравится.

На мой взгляд (!), у этого подхода есть ряд недостатков, и три основных из них:

• Сообщения, отправленные в группу поддержки, трудно найти (на самом деле, по моему мнению, все сообщения трудно найти, если у вас нет уведомления, на которое можно нажать). Хотя у сотрудников поддержки есть хороший обзор, у пользователя его нет. Там, где сотрудники, работающие с тикетами, видят отдельный групповой ящик, пользователи, создавшие тикеты, могут найти их только среди своих обычных личных сообщений.
• Отсутствие поддержки тегов в личных сообщениях: только сотрудники могут добавлять теги к личным сообщениям, а пользователи не могут видеть или фильтровать по тегам.
• Нет «места», куда можно было бы перейти и отправить сообщение. Возможность написать команде поддержки должна быть явно где-то объявлена (и мне трудно найти логичное место для этого; чаще всего это заканчивается каким-то баннером).

В целом, для меня это кажется чем-то «наскоро приделанным», компромиссом между темами в категориях и личными сообщениями.

#4 Закрытые темы

Идея эта высказывалась уже не раз (также здесь, здесь и здесь), и я уже упоминал выше права «Создать» и «Создать/Ответить».

Что, если бы существовала категория типа «почтовый ящик», где люди могли бы создавать темы и взаимодействовать с сотрудниками поддержки (по сути, группа), где видеть тему могли бы только они и члены этой группы?

Это стало бы универсальным решением для данного сценария. У нас была бы четко определенная категория «Поддержка», где каждый пользователь мог бы видеть свои (и только свои) тикеты поддержки. Всё находится в одном месте, и можно использовать теги и всё остальное.

Но и @codinghorror, и @sam много раз говорили нам, что права доступа к отдельным темам реализованы не будут (что я полностью понимаю, так как это добавляет огромную сложность).

---

Я вижу два пути вперед: использовать групповые почтовые ящики (решение №3) и надеяться, что эти недостатки будут устранены, или снова попробовать идею закрытых тем (решение №4).

Тем временем появились несколько плагинов, которые вмешиваются в реализуют права доступа на уровне темы, например, Restricted Replies — разрешает отвечать в категории только определенным группам, и Discourse Private Replies, который делает ответы невидимыми для всех, кроме автора темы (и сотрудников)… и это кажется выполнимым… поэтому я рассматриваю возможность реализации этого в виде плагина.

Но.

Прежде чем я продолжу, мне было бы интересно узнать:

• разделяют ли другие люди мое мнение относительно групповых почтовых ящиков, поскольку я осознаю, что эти воспринимаемые недостатки могут быть очень субъективными.
• любые (!!) отзывы об идее плагина для закрытых тем.

[Heliosurge (Dan DeMontmorency)]

Действительно, это очень хорошая тема для обсуждения.

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

Discourse Private Replies

Github: GitHub - communiteq/discourse-private-replies This plugin hides topic replies for everyone but the topic starter and the post author. Use cases This can be used for for instance homework assignments where the teacher opens a topic and posts an assignment, and all students make a post with their answers. When everyone has submitted their work, the teacher can open up the answers so the students will be able to discuss them. A second use case can be an auction where something is offered…

---

Групповая почта — отличная идея, однако, на мой взгляд, системе личных сообщений необходимо добавить удобную функцию поиска или групповые закладки с возможностью использования папок. Например, «Запросы от Клиента А за октябрь 2020 года».

[Simon_Manning]

@RGJ

Но и @codinghorror, и @sam много раз говорили нам, что разрешения, специфичные для тем, реализованы не будут (что я полностью понимаю, поскольку это значительно усложняет систему).

Не зная исходного контекста, разрешения, специфичные для тем, кажутся гораздо более масштабной (и, как вы верно заметили, более сложной) задачей, чем то, что потребуется для реализации #4.

Я представляю это следующим образом: расширение категорий разрешений с добавлением опции «Смотреть свои». Аналогично текущей логике, для добавленной группы должно быть разрешено либо «Смотреть», либо «Смотреть свои».

Поскольку разрешение «Создавать» автоматически подразумевает «Отвечать», разрешение «Смотреть свои» должно автоматически включать «Создавать» — категория, где можно видеть только свои темы, была бы бессмысленной, если нельзя создавать новые темы.

Думаю, для этого потребуется внести всего два дополнительных изменения в область разрешений. Если группы, к которым принадлежит текущий пользователь, имеют только разрешение «Смотреть свои»:

1. Список тем должен фильтроваться так, чтобы отображались только темы, созданные текущим пользователем.
2. Доступ к темам должен быть запрещён, если тему создал не текущий пользователь.

Подозреваю, что на практике возникнет дополнительная сложность при работе с такими вещами, как список «Последние темы», но, вероятно (возможно…), это не потребует огромных дополнительных усилий.

@RGJ

• если другие люди разделяют моё мнение относительно групповых почтовых ящиков, поскольку я осознаю, что эти воспринимаемые недостатки могут быть очень субъективными.

В Discourse в настоящее время нет поддержки частных обращений, поэтому у меня нет опыта работы с этим из первых рук, но, думаю, мои представления совпадают с вашими.

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

[RGJ (Richard - Communiteq)]

@Heliosurge

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

Спасибо за ваш отзыв! Я как раз являюсь автором этого конкретного плагина, и мы (Communiteq) готовы инвестировать в это, если почувствуем, что это верное направление. Так что эти вопросы не станут проблемой.

@Simon_Manning

Думаю, для этого «всего лишь» потребуется внести два дополнительных изменения в область разрешений. Когда группы, к которым принадлежит текущий пользователь, предоставляют только разрешение «Смотреть свои»:

• Список тем должен фильтроваться по темам, созданным текущим пользователем
• Доступ к темам должен быть запрещён, если тему не создал текущий пользователь

Да, это звучит правильно.

Однако я всё ещё немного затрудняюсь с тем, как именно это должно быть структурировано, поскольку «Смотреть свои» подразумевает «Создавать», «Создавать» подразумевает «Отвечать», а «Отвечать» подразумевает «Смотреть».
Но нам не нужно, чтобы «Смотреть свои» подразумевало «Смотреть».

[Heliosurge (Dan DeMontmorency)]

Да, я это вижу. Нужно было лучше внимать.

[Simon_Manning]

@RGJ

Я всё ещё немного затрудняюсь с тем, как именно это должно быть структурировано, так как «Своё» подразумевает «Создание», «Создание» подразумевает «Ответ», а «Ответ» подразумевает «Просмотр».
Но нам не нужно, чтобы «Своё» подразумевало «Просмотр».

Да, это оказывается сложнее, чем я думал. Похоже, что «Ответ» на самом деле не подразумевает «Просмотр», но добавление группы к разрешениям категории в целом это делает.

Разрешения представлены в виде перечисления, где у группы есть ровно одно из значений: readonly, create_post или full. Определение того, может ли пользователь отвечать или создавать посты в данной категории, сводится к получению списка всех категорий, где пользователь состоит в группе, имеющей разрешение create_post или full для ответов, и full для создания тем, и проверке, находится ли нужная категория в этом списке.

Создание тем — это просто: достаточно добавить дополнительное значение в перечисление, например full_own, и включить его в константу TOPIC_CREATION_PERMISSIONS в файле category.rb. Если у пользователя есть разрешение full или full_own для соответствующей категории, он может создать тему.

Ответы сложнее, но я думаю, что уместно добавить новую область видимости, возвращающую все категории, где у пользователя есть разрешение full_own. Что-то вроде:

  OWN_TOPIC_POST_CREATION_PERMISSIONS ||= [:full_own]
  scope :own_topic_post_create_allowed,  -> (guardian) { scoped_to_permissions(guardian, OWN_TOPIC_POST_CREATION_PERMISSIONS) }

Затем в файле post_guardian.rb метод can_create_post? должен получить дополнительное условие, например:

    (!SpamRule::AutoSilence.prevent_posting?(@user) || (!!parent.try(:private_message?) && parent.allowed_users.include?(@user))) && (
      !parent ||
      !parent.category ||
      Category.post_create_allowed(self).where(id: parent.category.id).count == 1 ||
      (parent.is_my_own? && Category.own_topic_post_create_allowed(self).where(id: parent.category.id).count == 1)
    )

Однако обеспечение возможности видеть только свои темы и гарантировать это на соответствующей странице категории, в разделе «Последние», в результатах поиска и в любом другом месте выглядит гораздо более сложной задачей. Я пока не придумал, как это реализовать.

[tobiaseigen]

Думаю, самый простой вариант здесь — это дверь №3: улучшение групповых почтовых ящиков, чтобы они хорошо работали для поддержки людей, которые входят в систему, а не только для тех, кто пишет на электронную почту.

@RGJ

• Сообщения, отправленные в группу поддержки, трудно найти (на самом деле, по моему мнению, все сообщения трудно найти, если у вас нет уведомления, на которое можно нажать). Хотя у сотрудников поддержки есть хороший обзор, у пользователей его нет. В то время как сотрудники, работающие с тикетами, видят отдельный групповой почтовый ящик, пользователи, создавшие тикеты, могут найти их только среди своих «обычных» личных сообщений.
• Отсутствие поддержки тегов в личных сообщениях: только сотрудники могут добавлять теги к личным сообщениям, а пользователи не могут видеть или фильтровать их по тегам.
• Нет «места», куда можно перейти и отправить сообщение. Возможность написать в команду поддержки должна быть явно объявлена где-то (и я считаю, что найти логичное место для этого сложно; чаще всего это заканчивается каким-то баннером).

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

У меня есть несколько пользователей, с которыми я общаюсь через @support-teams здесь на meta, поэтому я спрошу их, как это работает для них, и есть ли у них какие-либо предложения. Я также проведу дополнительные тесты самостоятельно, чтобы посмотреть, как это работает сейчас. Мне кажется, что запрос состоит в следующем:

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

Возможность начать новое сообщение группе — это то, что заметил даже я, как член группы @support-teams, предоставляющей поддержку Discourse for Teams по электронной почте. Если я хочу начать новое сообщение от имени команды поддержки, мне нужно включить как команду поддержки, так и адрес электронной почты человека, которому я хочу написать. Это немного неудобно.

Кроме того, способ, которым мы используем групповые почтовые ящики, заключается в том, что мы обычно не закрываем сообщения так, как закрываем темы, когда они решены. Мы просто архивируем их. Это позволяет нам убрать их из виду для себя, когда они решены, но также позволяет клиенту продолжить общение по электронной почте и вернуть сообщение в почтовый ящик.

[Simon_Manning]

@tobiaseigen

Кроме того, при использовании общих почтовых ящиков мы обычно не закрываем сообщения так, как закрываем темы, когда они решены. Мы просто архивируем их. Это позволяет нам убрать их из виду после решения, но также дает возможность клиенту продолжить общение по электронной почте и вернуть сообщение в почтовый ящик.

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

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

[RGJ (Richard - Communiteq)]

Я не уверен, что изменение full, create_post и readonly — это правильный путь, поскольку full и create_post во многих местах подразумевают «просмотр всего». Создание поддерживаемого плагина таким образом будет нелегким. Кроме того, я думаю, что это будет не очень интуитивно понятно.

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

Сейчас моя идея состоит в том, чтобы оставить права доступа без изменений и добавить раздел ниже групп безопасности:

---

Включить приватные темы в этой категории
Разрешить следующим группам просматривать все темы [x support staff] [x sales support]

---

@Simon_Manning

Однако видеть только свои собственные темы и гарантировать, что это верно для соответствующей страницы категории, последних тем, поиска и в любом другом месте, выглядит гораздо более сложной задачей. Я еще не разобрался с этим.

Я делал что-то подобное в плагине для приватных ответов, но тогда для постов в теме, а не для тем в категории.
Думаю, с некоторыми исправлениями в TopicGuardian я смогу продвинуться довольно далеко.

@tobiaseigen

Думаю, самая доступная цель здесь — дверь номер 3: улучшение групповых почтовых ящиков, чтобы они хорошо работали для оказания поддержки людям, которые входят в систему, а не только тем, кто пишет на почту для поддержки.

Да, это может быть очень легкой задачей. Ваше резюме моего запроса точное, и я нашел еще два момента, которые приведут сообщения в соответствие с темами.

• Когда я ищу на форуме, мне нужно явно добавлять in:private к своему поисковому запросу, чтобы искать свои сообщения. Иногда я действительно не помню, было ли что-то (более или менее публичной) темой или личным сообщением группе. Почему бы не включать их по умолчанию?

• Кроме того, я думаю, было бы здорово, если бы в правой вкладке гамбургер-меню была простая ссылка на сообщения. Да, есть иконка конверта, но она показывает список сообщений, а не ссылку на экран сообщений по адресу /my/messages. Этот экран кажется спрятанным.

Элементы в выпадающем меню частично совпадают с вкладками на следующем экране, за исключением Сообщений и Значков. Поэтому, когда мне нужно перейти к своим сообщениям, я всегда нажимаю «Сводка», а затем «Сообщения».

Сравните элементы в выпадающем меню

со вкладками на экране профиля

Там есть Сводка, Активность, Пригласительные и Настройки в обоих случаях, но Черновики в одном, а Уведомления, Сообщения и Значки — в другом. Поэтому «Сообщения» для меня кажутся очень скрытыми (то же самое касается Уведомлений и Значков, но я использую их не так часто).

[tobiaseigen]

@RGJ

• Когда я ищу на форуме, мне приходится явно добавлять in:private к своему поисковому запросу, чтобы искать свои сообщения. Иногда я действительно не помню, было ли это (более или менее публичной) темой или личным сообщением группе. Почему бы не включать их по умолчанию?

Хорошая мысль. Не уверен, какая логика стоит за этим ограничением. Я также заметил, что когда вы находитесь в своих сообщениях, по умолчанию добавляется in:personal, что хорошо! Но не добавляется, например, in:support-teams для поиска только в групповом ящике сообщений, что, на мой взгляд, было бы хорошей идеей. В расширенном поиске, насколько мне известно, нет простого способа отфильтровать по групповому ящику. (cc @pmusaraj)

@RGJ

Кроме того, я думаю, было бы неплохо, если бы в правой вкладке гамбургер-меню была простая ссылка на сообщения. Да, есть значок конверта, но он показывает список сообщений, а не ссылку на экран сообщений по адресу /my/messages. Этот экран кажется спрятанным.

Это хорошая идея, но, я думаю, проблема в нехватке места в этом выпадающем меню — не стоит добавлять больше 7 пунктов в этот список. Кроме того, для большинства сообществ я не считаю, что нам нужно продвигать личные сообщения… мы хотим, чтобы люди общались публично! Для тех, кто общается в личных сообщениях, выпадающее меню уведомлений и уведомления по электронной почте и т. д. предоставляют достаточно оперативного доступа к сообщениям, требующим внимания.

Тем не менее, мы активно работаем над улучшением системы меню (ключевое слово: sideburger), поэтому учтём эту проблему. Боковая панель в Discourse for Teams уже обеспечивает быстрый доступ к групповым ящикам и отслеживаемым тегам, что мы можем перенести в ядро Discourse вместе с проектом sideburger.

Вот как это выглядит сейчас, когда я нахожусь в групповом ящике Kabissa на моём сайте Discourse for Teams:

[Simon_Manning]

@tobiaseigen

• предоставить ссылку для начала нового сообщения группе (я думаю, что это есть на странице группы, если отправка сообщений группе разрешена)

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

• 0 групп назначено для поддержки — записи в меню нет
• 1 группа назначена — запись «Сообщить в поддержку», которая открывает новое сообщение этой группе

• 1 групп назначено — запись «Поддержка», ведущая на страницу, похожую на страницу «Группы», где отображаются все назначенные группы с кнопками «Сообщить»

Возможно, дополнительная запись в меню и отдельная страница избыточны. Может быть, лучше добавить дополнительный сгенерированный раздел на страницу «О проекте»?

@RGJ

• Кроме того, я считаю, что было бы удобно добавить простую ссылку на сообщения в правой вкладке меню-бургера. Да, есть значок конверта, но он показывает список сообщений, а не ссылку на экран сообщений по адресу /my/messages. Этот экран кажется слишком скрытым.

Это не совсем очевидно, но такая возможность есть на вкладке «Сообщения»: стрелка вниз в нижней части списка сообщений ведёт на экран /my/messages. Количество кликов такое же, как при переходе через «Сводка» → «Сообщения», но загружается на одну страницу меньше.

@tobiaseigen

Вот как это выглядит сейчас, когда я нахожусь в входящих сообщениях группы Kabissa на моём сайте Discourse for Teams:

Если бы я был пользователем, отправляющим сообщение в Kabissa, была бы эта тема каким-то образом преимущественно связана с группой или у темы не было бы ничего, кроме моего пользователя и группы Kabissa, имеющей доступ?

Если тема действительно преимущественно связана с группой, было бы возможно отображать этот ящик входящих сообщений Kabissa на моей странице сообщений аналогичным образом, разумеется, включая только те сообщения, к которым у меня есть доступ.

[tobiaseigen]

Когда я тестировал это здесь на meta, создав пользователя tl0, я смог перейти на страницу группы support-teams и выбрать кнопку Сообщение, чтобы отправить группе сообщение. После публикации сообщение попало в мою папку «Отправленные». Таким образом, функционал работает, хотя в некоторых случаях он может быть слишком скрытым. Вы всегда можете добавить ссылки в меню-бургер по своему усмотрению, чтобы они соответствовали целям вашего сайта, или разместить их в баннере на главной странице и т. д. Поэтому я не вижу, что здесь нужно сделать ещё что-то существенное?

Входящие сообщения Kabissa на этом скриншоте видны только участникам группы Kabissa. Люди, отправляющие сообщения в Kabissa, будут видеть их в своих личных сообщениях.

[jomaxro (Joshua Rosenfeld)]

@RGJ

• Когда я ищу на форуме, мне приходится явно добавлять in:private к своему поисковому запросу, чтобы найти свои сообщения. Иногда я действительно не помню, было ли это (более или менее публичной) темой или личным сообщением группе. Почему бы не включать их по умолчанию?

Стоит отметить, что существует in:all. Это покажет и публичные, и личные сообщения в одном поиске.

Если я правильно помню историю, идея заключалась в том, чтобы обеспечить разделение между личными сообщениями и публичными темами. Минимизировать любую путаницу относительно того, что является публичным, а что личным. Тем не менее, групповые почтовые ящики довольно сильно размывают это разделение.

[Simon_Manning]

@tobiaseigen

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

Я рассматривал возможность повышения заметности групп, посвящённых поддержке. Добавление ссылок в меню-бургер, безусловно, подойдёт для сообщества с одной группой поддержки (что на самом деле идеально для моих целей), но сообществу с множеством групп поддержки могла бы помочь отдельная страница или раздел на странице «О нас», автоматически генерируемый для указанных групп.

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

@tobiaseigen

Входящие сообщения Kabissa на этом скриншоте видны только пользователям, состоящим в группе Kabissa. Пользователи, отправляющие сообщения Kabissa, будут видеть их в своём личном разделе сообщений.

То, что я пытался спросить, возможно, не очень чётко, это: достаточно ли у текущей модели информации, чтобы в будущем было возможно отображать пользователям фильтрованные входящие сообщения для групп, с которыми они взаимодействуют, но в которые не входят? Это связано с опасением @RGJ о том, что сообщения, отправленные группам, трудно найти.

Например, я, как обычный пользователь вашего сайта Discourse for Teams, мог бы видеть в своём разделе сообщений папку «Входящие» для Kabissa, где отображались бы все сообщения, которые я отправил группе Kabissa. (Или, возможно, сообщения, в которых я являюсь участником.)

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

[schungx (Stephen Chung)]

@RGJ

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

Отлично, что это набирает популярность! Это потому, что я считаю, что Discourse — это одна из великолепных систем для частных заявок в службу поддержки, и когда она работает, то работает чудесно.

Я прекрасно понимаю, что это не то, для чего создан Discourse, и что я пытаюсь втиснуть Discourse в выполнение задачи, для которой он не предназначен, но между личными ящиками и полным величием и возможностями основных тем, я в любой день выберу последнее и продолжу пытаться втиснуть его…

[codinghorror (Jeff Atwood)]

@schungx

Я прекрасно понимаю, что для этого не предназначен Discourse, и что я пытаюсь втиснуть его в рамки, не предназначенные для таких задач. Однако между личными сообщениями и полным функционалом и возможностями основных тем я в любой день выберу последнее и продолжу пытаться это сделать…

Мы хотим поддерживать это (как в переносном, так и в прямом смысле), но не хотим оказаться загнанными в угол «инструмента поддержки». Если у вас есть конкретные предложения, как улучшить Discourse в этой роли, дайте нам знать.

Мы всегда на связи

[jrgong]

@RGJ

А что, если создать категорию типа «ящик для заявок», где пользователи смогут создавать темы и взаимодействовать с сотрудниками поддержки (по сути, группу), где видеть тему смогут только они и участники этой группы?

Отличная идея! Даже у нас в сообществе поступают запросы на отдельные тикеты поддержки, не связанные с их личной почтой. Такая категория, где пользователи видят только свои тикеты, была бы очень полезна.

[jerry0 (Jerry)]

@codinghorror

Мы хотим поддерживать это (как в переносном, так и в прямом смысле), но не хотим оказаться загнанными в угол «инструмента поддержки». Если у вас есть конкретные предложения, как улучшить Discourse в этой роли, дайте нам знать.

Спасибо!

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

Мы пытались объяснить им, что для поиска по сообщениям нужно добавить код in:personal к поисковому запросу, но это не интуитивно понятно. Честно говоря, я не видел ни одного пользователя, который бы реально справился с этим; они просто сдаются и жалуются, что не могут искать по своим сообщениям.

Они даже не понимают, для чего предназначена эта «подсказка» под полем поиска.

А если они перейдут к расширенному поиску, то, возможно, найдутся достаточно продвинутые, чтобы отметить переключатель «искать сообщения», но всё начинает выглядеть странно, когда туда автоматически добавляются слова in:personal, и на этом этапе они тоже сдаются.

Если бы существовал гораздо более интуитивный способ поиска по сообщениям, не требующий добавления кода в поле поиска, это стало бы огромным улучшением.

Если нет, то хотя бы использование более понятных формулировок, например, кода «in:messages», стало бы небольшим улучшением.

[pfaffman (Jay Pfaffman)]

Или, может быть, просто включить личные сообщения в поиск по умолчанию?

[jerry0 (Jerry)]

Действительно, это было бы замечательно!

Настройка «По умолчанию искать в личных сообщениях» (которая обычно отключена) была бы идеальным решением.

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