تقديم "دعم خاص" كجزء من مجتمع دعم عام

لقد كنت أفكر في هذا لفترة من الوقت وقررت طرح أفكاري على المجموعة وأسألكم جميعًا عما تعتقدون.

في الأشهر القليلة الماضية، تحدثت مع عدد كبير من الأشخاص الذين يحاولون إعداد دعم مباشر للعملاء - حيث يقوم فريق الدعم بحل مشكلات العملاء (السرية) الخاصة - بالإضافة إلى منتدى دعم المجتمع (العام) الحالي الخاص بهم.
تتضمن معظم هذه الحلول الإضافات ‘assign’ و ‘solved’ و ‘ticket’، ثم هناك طرق متعددة (ولكن يبدو أنه لا يوجد حل سحري ولهذا السبب أقوم بإنشاء هذا الموضوع).

الحل رقم 1: إنشاء فئات / مجموعات منفصلة لكل عميل

هذا يعمل فقط عندما يكون لديك عدد قليل نسبيًا من العملاء، وليس عندما يكون لديك المئات.

الحل رقم 2: الحل الذي وصفه schungx “كيفية استخدام Discourse كنظام دعم / تذاكر خاص

العائق الرئيسي هنا هو: " (…) أنك تنشئ منصة تذاكر مخصصة، أو أنه سيكون هناك على الأقل عدم تداخل بين مستخدمي واجهة الويب الخاصة بـ Discourse وأولئك الذين يطلبون تذاكر الدعم. "

لكن هذا الموضوع يعالج إحدى المشكلات الرئيسية: “لقد نظرت في نظام الأمان / الأذونات ولا تجد ما تريده: في الأساس، لا توجد أذونات إنشاء وإنشاء / رد بسيطة.” سأعود إلى هذا أدناه.

الحل رقم 3: صناديق البريد الجماعية.

فكرة Sam الأصلية “Discourse كبوابة دعم بريد إلكتروني خاصة” التي أصبحت صناديق بريد جماعية. تقوم بإعداد صندوق بريد جماعي، وتعيينه لفريق الدعم الخاص بك، ويمكن للجميع إرسال أو إرسال رسائل بريد إلكتروني إلى صندوق البريد.
هذا هو الحل المفضل الآن وهو يعمل.

ومع ذلك، لا أحب ذلك كثيرًا.

في رأيي (!)، هناك عدد من العيوب لهذا النهج، والثلاثة الرئيسيون هم:

  • يصعب العثور على الرسائل المرسلة إلى مجموعة الدعم (في الواقع، في رأيي يصعب العثور على جميع الرسائل إذا لم يكن لديك إشعار للنقر عليه) وعلى الرغم من أن موظفي الدعم لديهم نظرة عامة جيدة، إلا أن المستخدم لا يمتلكها. حيث يرى المستخدمون الذين يعملون على التذاكر صندوق بريد جماعي منفصل، يمكن للمستخدمين الذين أنشأوا التذاكر العثور عليها فقط بين رسائلهم الخاصة ‘العادية’.
  • نقص دعم العلامات في الرسائل الخاصة: يمكن للموظفين فقط وضع علامات على الرسائل الخاصة ولا يمكن للمستخدمين رؤية العلامات أو تصفيتها.
  • لا يوجد “مكان” يمكن للمرء الذهاب إليه وإرسال رسالة إليه. يجب الإعلان صراحة عن إمكانية مراسلة فريق الدعم في مكان ما (وأجد صعوبة في العثور على مكان منطقي لذلك، وفي معظم الأحيان ينتهي الأمر في نوع من اللافتات).

بشكل عام، بالنسبة لي يبدو الأمر وكأنه “مُلحق” وتسوية بين مواضيع الفئة والرسائل الخاصة.

#4 مواضيع خاصة

تم طرح هذه الفكرة عددًا من المرات (أيضًا هنا هنا و هنا) ، ولقد ذكرت بالفعل أذونات “إنشاء” و “إنشاء / رد” أعلاه.

ماذا لو كان هناك نوع من فئة “صندوق الإسقاط” حيث يمكن للأشخاص بدء موضوع والتفاعل مع موظفي الدعم (بشكل أساسي: مجموعة)، حيث يمكنهم هم وأعضاء تلك المجموعة فقط رؤية الموضوع؟
سيكون هذا حلاً سحريًا لهذه الحالة الاستخدام. سيكون لدينا فئة “دعم” محددة بوضوح حيث يمكن لكل مستخدم رؤية تذاكر الدعم الخاصة به (و فقط الخاصة به). كل شيء في مكان واحد ويمكنك استخدام العلامات وكل شيء.

لكن كل من @codinghorror و @sam أخبرونا مرارًا وتكرارًا أن الأذونات الخاصة بالموضوع لن تحدث (وهو ما أفهمه تمامًا، لأنه يضيف الكثير من التعقيد).


أرى طريقتين للمضي قدمًا: استخدام صناديق البريد الجماعية #3 ونأمل أن يتم حل تلك العيوب، أو إعطاء فكرة المواضيع الخاصة #4 فرصة أخرى.

في هذه الأثناء، ظهر عدد قليل من الإضافات التي تعبث بـ تطبق أذونات لكل موضوع، مثل Restricted Replies - تسمح فقط لمجموعات معينة بالرد في فئة و Discourse Private Replies التي تجعل الردود غير مرئية للجميع باستثناء بادئ الموضوع (والموظفين) … ويبدو أن هذا ممكن … لذلك كنت أفكر في إعطاء هذا فرصة أخرى في إضافة.

لكن.

قبل أن أتابع هذا، سأكون مهتمًا بالاستماع

  • إذا كان الآخرون يشاركونني رأيي فيما يتعلق بصناديق البريد الجماعية، حيث أدرك أن هذه العيوب المتصورة يمكن أن تكون ذاتية للغاية.
  • أي (!!) ملاحظات حول فكرة إضافة المواضيع الخاصة
24 إعجابًا

هذا بالفعل موضوع جيد لمناقشته.
قد يتمكن الردود الخاصة من الانقسام ربما للتوصل إلى شيء يتماشى مع فكرتك. ولكن سيتطلب ذلك شخصًا يعرف ما يفعله أو يناقشه ربما مع مؤلف المكون الإضافي إذا كان هناك انقسام لمكون إضافي مدعوم. مع الرعاية، سيكون من الرائع استكشاف شكل من أشكال مفهوم التمويل الجماعي.


صندوق البريد الجماعي فكرة رائعة، ومع ذلك، في رأيي، يحتاج نظام الرسائل الخاصة إلى خيار بحث سهل الاستخدام، أو إشارات مرجعية جماعية مع استخدام خيار مجلد. على سبيل المثال، طلبات العميل أ أكتوبر 2020.

7 إعجابات

بدون معرفة السياق الأصلي، تبدو الأذونات الخاصة بالموضوع وكأنها احتمال أوسع بكثير (وكما ذكرت، أكثر تعقيدًا) مما هو مطلوب لجعل #4 يعمل.

الطريقة التي أتصور بها هذا العمل هي عن طريق توسيع أذونات الفئة لتشمل “رؤية خاصة”. على غرار كيفية عمل الأذونات الآن، يجب السماح بواحدة من “رؤية” أو “رؤية خاصة” لمجموعة تمت إضافتها.

نظرًا لأن السماح بالإنشاء يسمح تلقائيًا بالرد، فإن “رؤية الآن” ستسمح تلقائيًا بالإنشاء - ستكون الفئة التي يمكنك فيها رؤية مواضيعك الخاصة فقط بلا فائدة إذا لم تتمكن من إنشاء مواضيع.

أعتقد أن هذا سيحتاج “فقط” إلى تغييرين إضافيين في منطقة الأذونات. عندما تمنح المجموعات التي ينتمي إليها المستخدم الحالي إذن “رؤية خاصة” فقط:

  1. يجب أن يقوم سرد الموضوع بتصفية المواضيع التي أنشأها المستخدم الحالي
  2. يجب رفض الوصول إلى المواضيع ما لم يتم إنشاء الموضوع بواسطة المستخدم الحالي

أشك في أنه في الواقع هناك تعقيد إضافي يتعلق بأشياء مثل قائمة أحدث المواضيع ولكن ربما (ربما…) ليس الكثير من العمل الإضافي.

نحن لا نقدم حاليًا دعمًا خاصًا في Discourse لذلك ليس لدي خبرة مباشرة ولكن أعتقد أن تصوراتي تتماشى مع تصوراتك.

قابلية الاكتشاف مهمة، سواء في العثور على مكان لطرح طلبات الدعم أو في مراجعة استعلامات الدعم الحالية والسابقة، والتي تبدو صعبة محتملة مع نهج رسائل البريد الإلكتروني الجماعية.

7 إعجابات

شكراً لملاحظاتك! أنا مؤلف هذا المكون الإضافي المحدد، ونحن (Communiteq) على استعداد للاستثمار في هذا إذا حصلنا على شعور بأن هذا هو الاتجاه الصحيح. لذلك لن تكون هذه الأمور مشكلة.

نعم، هذا يبدو صحيحًا.

ما زلت أواجه صعوبة بعض الشيء في كيفية هيكلة هذا بالضبط، نظرًا لأن “رؤية الخاصة” تعني “الإنشاء”، و"الإنشاء" يعني “الرد”، و"الرد" يعني “الرؤية”.
لكننا لا نريد أن تعني “رؤية الخاصة” “الرؤية”.

8 إعجابات

نعم، أرى ذلك. كان يجب أن أنتبه بشكل أفضل.

:clinking_beer_mugs::smiling_face_with_sunglasses::vulcan_salute::sparkles:

5 إعجابات

نعم، يبدو أن هذا أصعب مما كنت أعتقد. يبدو أن الرد لا يعني في الواقع الرؤية ولكن إضافة مجموعة إلى أذونات الفئة على الإطلاق.
الأذونات هي تعداد حيث تمتلك المجموعة واحدة بالضبط من 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)
    )

ومع ذلك، فإن رؤية مواضيع المرء فقط وضمان أن هذا صحيح عبر صفحة الفئة ذات الصلة، والأحدث، والبحث، وأي مكان آخر يبدو أكثر صعوبة بكثير. لم أكتشف ذلك بعد.

6 إعجابات

أعتقد أن أسهل الحلول هنا هو الباب رقم 3، وهو تحسين صناديق البريد الجماعية لتعمل بشكل جيد في تقديم الدعم للأشخاص الذين يسجلون الدخول، وليس فقط للأشخاص الذين يرسلون بريدًا إلكترونيًا للدعم.

شكواك الرئيسية بشأن صناديق البريد الجماعية تبدو تتعلق بنقص الوظائف من جانب المستخدم، وهو أمر مشروع إذا كان المستخدمون يسجلون الدخول لمتابعة التذاكر ويستخدمون أيضًا الرسائل الخاصة للتحدث مع أشخاص آخرين على الموقع. لم أواجه هذا كثيرًا حتى الآن في استخدامنا لصناديق البريد الجماعية لتقديم الدعم هنا في ميتا. معظم الأشخاص الذين نقدم لهم الدعم عبر صناديق البريد الجماعية لا يسجلون الدخول أبدًا - فهم يستخدمون بريدهم الإلكتروني الخاص في الغالب، وبالتالي يمكنهم استخدام بريدهم الإلكتروني لتنظيم وأرشفة مراسلاتهم معنا حسب ما يرونه مناسبًا.

لدي بعض المستخدمين الذين أتواصل معهم عبر @support-teams هنا في ميتا، لذا سأسألهم كيف يعمل الأمر معهم وما إذا كانت لديهم أي اقتراحات. سأقوم أيضًا ببعض الاختبارات الإضافية بنفسي لمعرفة كيف يعمل هذا الآن. يبدو لي أن الطلب هو:

  • السماح للمستخدمين غير الموظفين برؤية علامات الرسائل (حاليًا يرى الموظفون فقط العلامات. ربما يمكننا استخدام مجموعات العلامات لهذا الغرض، لتوفير بعض العلامات التي يمكن للمستخدمين غير الموظفين رؤيتها في الرسائل؟ :thinking: )
  • توفير رابط لصناديق البريد الجماعية في قائمة الرسائل للمستخدمين عند مراسلة المجموعات، لرؤية رسائلهم الخاصة مع المجموعات (يعمل هذا بالفعل للموظفين، لست متأكدًا من كيفية عمله للمستخدمين غير الموظفين. هناك مشاكل هنا بين صندوق الوارد والأرشيف، والتي لا يتم التحكم فيها بشكل فردي على أساس كل مستخدم)
  • توفير رابط لبدء رسالة جديدة إلى مجموعة (أعتقد أن هذا موجود في صفحة المجموعة إذا كان إرسال رسائل إلى المجموعة مسموحًا به)

القدرة على بدء رسالة جديدة إلى مجموعة هو شيء لاحظته حتى أنا، بصفتي عضوًا في مجموعة @support-teams لتقديم دعم البريد الإلكتروني لـ Discourse for Teams. إذا كنت أرغب في بدء رسالة جديدة من فريق الدعم، يجب علي تضمين كل من فريق الدعم وعنوان البريد الإلكتروني للشخص الذي أريد مراسلته. هذا أمر مربك بعض الشيء.

أيضًا، الطريقة التي نستخدم بها صناديق البريد الجماعية، لا نغلق الرسائل عادةً كما نفعل مع المواضيع عند حلها. نقوم فقط بأرشفتها. هذا يسمح لنا بإخراجها من مجال رؤيتنا عندما يتم حلها، ولكنه يسمح أيضًا للعميل بالمتابعة عبر البريد الإلكتروني وإعادة الرسالة إلى صندوق الوارد.

5 إعجابات

هذه نقطة مثيرة للاهتمام حقًا لم أفكر فيها حقًا. مع دعم البريد الإلكتروني، من الشائع جدًا أن يجد العملاء رسائل البريد الإلكتروني القديمة ويردوا عليها بدلاً من إرسال بريد إلكتروني جديد. إذا تم إغلاق موضوع، فمن المحتمل أن يكون ذلك مربكًا في أحسن الأحوال عندما يجدون أن بريدهم الإلكتروني مرفوض.

خلف الباب رقم 4، بأي طريقة يمكن أن يحدث ذلك، سيكون من الصعب على جانب الموظفين تحديد المواضيع التي لم يتم التعامل معها إذا لم يكن من الممكن إغلاقها، خاصة مع زيادة أعداد موظفي الدعم. لن يساعد المكون الإضافي “تم الحل” حقًا هنا لأن العميل يمكنه الرد على موضوع قديم ولن يعرف موظفو الدعم المختلفون ما إذا كان يحتاج إلى اهتمام أو ما إذا كان عضو آخر في الفريق قد قام بحله بالفعل.

6 إعجابات

لست متأكدًا مما إذا كان العبث بـ full و create_post و readonly هو الطريقة الصحيحة، نظرًا لأن full و create_post يعنيان “رؤية كل شيء” في العديد من الأماكن. لن يكون من السهل إنشاء إضافة قابلة للصيانة بهذه الطريقة. بالإضافة إلى ذلك، أعتقد أنها لن تكون بديهية للغاية.

أيضًا، سيكون من الرائع إذا تمكن مؤلف الموضوع من إضافة أشخاص إضافيين (على سبيل المثال، زميل) إلى الموضوع، على سبيل المثال عن طريق الإشارة إليهم، وفي هذه الحالة لن يكون هذا الآلية كافية.

في الوقت الحالي، فكرتي هي ترك الأذونات كما هي وإضافة قسم أسفل مجموعات الأمان:


تمكين المواضيع الخاصة في هذه الفئة
السماح للمجموعات التالية برؤية جميع المواضيع [x موظفو الدعم] [x دعم المبيعات]


لقد فعلت شيئًا مشابهًا في إضافة الردود الخاصة، ولكن بعد ذلك للمشاركات في موضوع بدلاً من المواضيع في فئة.
أعتقد أنني سأتقدم كثيرًا ببعض التصحيحات في TopicGuardian.

نعم، يمكن أن يكون هذا أسهل شيء. ملخصك لطلبي دقيق، وقد وجدت شيئين آخرين من شأنهما أن يجعلا الرسائل متساوية مع المواضيع.

  • عندما أبحث في المنتدى، يتعين عليّ إضافة in:private بشكل صريح إلى استعلام البحث الخاص بي للبحث في رسائلي. في بعض الأحيان لا أتذكر حقًا ما إذا كان شيئًا ما موضوعًا (عامًا إلى حد ما) أو رسالة خاصة لمجموعة. لماذا لا يتم تضمينها افتراضيًا؟

  • بالإضافة إلى ذلك، أعتقد أنه سيكون من الجيد أن يكون هناك رابط بسيط للرسائل في علامة التبويب اليمنى في قائمة الهامبرغر. نعم، هناك أيقونة الظرف، ولكنها تحتوي على قائمة بالرسائل، وليس رابطًا إلى شاشة الرسائل في /my/messages. تبدو تلك الشاشة مخفية.

العناصر الموجودة في القائمة المنسدلة هي جزئيًا نفس علامات التبويب في الشاشة التالية، باستثناء الرسائل و الشارات. لذلك عندما أحتاج إلى الانتقال إلى رسائلي، أنقر دائمًا على الملخص ثم الرسائل.

قارن العناصر في القائمة المنسدلة

مع علامات التبويب في شاشة الملف الشخصي

image

هناك الملخص والنشاط والدعوات والتفضيلات في كليهما، ولكن المسودات في أحدهما والإشعارات والرسائل والشارات في الآخر. لذلك تبدو “الرسائل” مخفية جدًا بالنسبة لي (وهذا ينطبق أيضًا على الإشعارات والشارات ولكنني لا أستخدمها كثيرًا).

7 إعجابات

نقطة جيدة. لست متأكدًا من التفكير وراء هذا الحاجز. لقد لاحظت أيضًا أنه عندما تكون في رسائلك، فإنه يضيف in:personal افتراضيًا وهو أمر جيد! ولكنه لا يضيف على سبيل المثال in:support-teams للبحث فقط في صندوق البريد الجماعي عن الرسائل، وهو ما أعتقد أنه سيكون فكرة جيدة. البحث المتقدم أيضًا لا يحتوي على طريقة سهلة للتصفية حسب صندوق البريد الجماعي على حد علمي. (إشارة إلى @pmusaraj)

هذه فكرة جيدة ولكن أعتقد أن هناك مشكلة في المساحة المتاحة في هذه القائمة المنسدلة - لا تريد أن يكون لديك أكثر من 7 عناصر في هذه القائمة. أيضًا، بالنسبة لمعظم المجتمعات، لا أعتقد أننا نريد حقًا الترويج للرسائل … نريد أن يتحدث الناس علنًا! بالنسبة لأولئك الذين يتحدثون في الرسائل، توفر قائمة الإشعارات وإشعارات البريد الإلكتروني وما إلى ذلك وصولًا كافيًا في الوقت المناسب إلى الرسائل التي تحتاج إلى اهتمام.

ومع ذلك، نحن نعمل بنشاط على تحسينات لنظام القوائم (كلمة مفتاحية: sideburger) لذلك سنأخذ هذه المشكلة في الاعتبار. توفر الشريط الجانبي في Discourse for Teams بالفعل وصولاً سهلاً إلى صناديق البريد الجماعية والعلامات التي تمت مراقبتها، والتي يمكننا جلبها إلى Discourse الأساسي جنبًا إلى جنب مع مشروع sideburger.

إليك كيف يبدو الأمر الآن عندما أكون في صندوق البريد الجماعي Kabissa، على موقع Discourse for Teams الخاص بي:

5 إعجابات

أتساءل عن تعيين المجموعات كمجموعات دعم ووجود إدخال قائمة هامبرغر بناءً على ذلك، مع هذه الحالات:

  • 0 مجموعات معينة للدعم، لا يوجد إدخال قائمة
  • مجموعة واحدة معينة، إدخال “رسالة دعم” يبدأ رسالة إلى المجموعة
  • أكثر من مجموعة واحدة معينة، إدخال “دعم” يربط بصفحة تشبه المجموعات، تعرض جميع المجموعات المعينة مع أزرار رسائل

ربما يكون إدخال القائمة الإضافي والصفحة مبالغًا فيهما. قسم إضافي تم إنشاؤه في صفحة “حول”؟

ليس واضحًا تمامًا، ولكن هذا موجود في علامة تبويب الرسائل، والسهم لأسفل في أسفل قائمة الرسائل سيأخذك إلى شاشة /my/messages. لا يوجد عدد أقل من النقرات مقارنة بـ “الملخص” ثم “الرسائل”، ولكن تحميل صفحة أقل.

إذا كنت مستخدمًا يرسل رسالة إلى كابيسا، فهل سيتم ربط هذا الموضوع بشكل أساسي بالمجموعة بطريقة ما، أم أن الموضوع لن يكون له شيء أكثر من المستخدم الخاص بي والسماح بالوصول إلى مجموعة كابيسا؟

إذا تم ربطه بشكل أساسي بالمجموعة، فهل سيكون من الممكن إظهار صندوق الوارد الخاص بكابيسا في صفحة الرسائل الخاصة بي بنفس الطريقة، مع تضمين الرسائل التي يمكنني الوصول إليها فقط بالطبع.

6 إعجابات

عندما اختبرت هذا هنا في ميتا، عن طريق إنشاء مستخدم tl0، تمكنت من الانتقال إلى صفحة مجموعة فرق الدعم وتحديد زر الرسالة لإرسال رسالة إلى المجموعة. بمجرد نشر الرسالة، وصلت إلى مجلد الرسائل المرسلة. لذا، هذا يعمل على الرغم من أنه قد يكون مدفونًا قليلاً في بعض الحالات. يمكنك دائمًا إضافة روابط إلى قائمة الهامبرغر حسب ما تراه مناسبًا لتلبية أغراض موقعك، أو في لافتة على صفحتك الرئيسية وما إلى ذلك. لذا، لا أرى أن هناك الكثير مما يجب القيام به هنا؟

صندوق الوارد الخاص بكابيسّا في تلك لقطة الشاشة معروض فقط للأشخاص في مجموعة كابيسّا. سيرى الأشخاص الذين يراسلون كابيسّا الرسائل في رسائلهم الخاصة.

5 إعجابات

لاحظ أن in:all موجود. سيُظهر هذا كلاً من الرسائل العامة والشخصية في بحث واحد.

إذا كنت أتذكر التاريخ بشكل صحيح، كانت الفكرة هي فرض الفصل بين الرسائل الشخصية والمواضيع العامة. تقليل أي ارتباك حول ما هو عام وما هو شخصي. ومع ذلك، فإن صناديق البريد الجماعية تطمس هذا الفصل إلى حد كبير.

8 إعجابات

كنت أفكر في زيادة إمكانية اكتشاف المجموعات الخاصة بالدعم. ستكون إضافة الروابط إلى قائمة الهامبرغر مناسبة بالتأكيد لمجتمع به مجموعة دعم واحدة (وهو أمر مثالي لأغراضي الخاصة) ولكن مجتمعًا به العديد من مجموعات الدعم قد يستفيد من صفحة أو قسم في صفحة “حول” تم إنشاؤه للمجموعات المحددة.

بالنظر إلى الوراء، ربما يكون هذا أكثر ملاءمة للمكون الإضافي إذا احتاج المجتمع إلى ذلك.

ما كنت أحاول طرحه، ربما بشكل سيء، هو ما إذا كان النموذج يحتوي حاليًا على معلومات كافية لجعله ممكنًا (في المستقبل) لعرض صناديق وارد مصفاة للمستخدمين الذين يتفاعلون معها ولكنهم لا ينتمون إليها. هذا يتعلق بقلق @RGJ بشأن صعوبة العثور على الرسائل المرسلة إلى المجموعات.

على سبيل المثال، أنا، كمستخدم عادي في موقع Discourse for Teams الخاص بك، يمكنني رؤية صندوق وارد Kabissa في رسائلي والذي يعرض جميع الرسائل التي أرسلتها إلى مجموعة Kabissa. (أو ربما الرسائل التي أشارك فيها.)

شكي هو أنه لا يفعل ذلك، ربما لديه فقط المشاركين للانطلاق منهم، والذين يمكن أن يكونوا أي عدد من المستخدمين والمجموعات.

7 إعجابات

من الرائع أن هذا الأمر ينتشر! هذا لأنني أجد أن Discourse هو نظام رائع لتذاكر الدعم الخاصة، وعندما يعمل، فإنه يعمل بشكل رائع.

أعلم جيدًا أن هذا ليس ما تم تصميم Discourse من أجله، وأنني أحاول فرض استخدام Discourse لشيء لا يفترض به القيام به، ولكن بين صناديق البريد الخاصة مقابل المجد الكامل والميزات للمواضيع الرئيسية، سأختار الخيار الأخير في أي يوم وأستمر في محاولة فرضه…

4 إعجابات

هذا شيء نريد دعمه، (مجازيًا وحرفيًا)، لكننا لا نريد أن نُجبر على زاوية “أداة دعم”. :wink: إذا كان لديك ملاحظات محددة حول كيفية تحسين Discourse في هذا الدور، فأخبرنا بذلك.

نحن نستمع دائمًا :ear::hugs:

8 إعجابات

أحببت الفكرة! حتى من مجتمعنا لدينا طلبات لتذاكر دعم منفصلة عن صندوق الوارد الخاص بالمستخدم. هذا النوع من الفئات التي يمكن للمستخدمين فيها رؤية تذاكرهم الخاصة فقط سيكون مفيدًا للغاية.

4 إعجابات

شكرًا!

نحن نستخدم مجموعة رسائل خاصة للدعم الخاص - إنها تعمل بشكل جيد. الشكوى الرئيسية التي لدى المستخدمين المكثفين لنظام الدعم هي عدم القدرة على البحث في رسائلهم.

لقد حاولنا تعليمهم أنه يجب عليهم إضافة الرمز in:personal إلى استعلام البحث من أجل البحث في رسائلهم، لكنه ليس بديهيًا، وبصراحة لم أرَ مستخدمًا واحدًا تمكن من فعل ذلك، فهم يستسلمون ببساطة ويشتكون من عدم قدرتهم على البحث في رسائلهم.

إنهم لا يفهمون حتى ما هو الغرض من “الاقتراح” الموجود أسفل مربع البحث.

وإذا انتقلوا إلى البحث المتقدم، فقد يكونون متقدمين بما يكفي لتحديد زر الاختيار “البحث في الرسائل” ولكن كل شيء يبدأ في الظهور غريبًا عندما يضيف ذلك الكلمات in:personal ويستسلمون عند تلك النقطة.

إذا كانت هناك طريقة أكثر بديهية للبحث في الرسائل لا تتضمن إضافة رمز إلى مربع البحث، فسيكون ذلك تحسينًا هائلاً.

إذا لم يكن الأمر كذلك، فإن مجرد استخدام لغة أكثر بديهية، على سبيل المثال الرمز “in:messages”، سيكون تحسينًا طفيفًا.

6 إعجابات

أو ربما يجب أن يتضمن البحث رسائل خاصة افتراضيًا؟

4 إعجابات

بالتأكيد - سيكون ذلك رائعًا!

إعداد “البحث في الرسائل الخاصة افتراضيًا” (وهو معطل عادةً) سيكون مثاليًا حقًا.

بهذه الطريقة، يمكن موازنة أي مخاوف بشأن اختلاط المستخدمين بين نتائج البحث للمواضيع العادية ومواضيع الرسائل الخاصة (التي لا أملكها) مقابل عدم قدرة الأشخاص على البحث في مواضيع الرسائل الخاصة على الإطلاق (وهو ما أملكه).

3 إعجابات