پرش به محتویات

مرکز پیام‌ها

مدل موجودیتی مرکز پیام‌ها و ارتباطات تریپیلون

این سند مدل موجودیتی Message Center / مرکز پیام‌ها را برای محصول تریپیلون (Tripylon) تعریف می‌کند.

هدف این مدل این است که همه پیام‌های مرتبط با کاربر، ساختمان، واحد، پرونده‌ها و رویدادهای سیستم در یک مرکز واحد قابل مشاهده باشند؛ اما منطق اصلی هر پیام همچنان در ماژول مربوط به خودش باقی بماند.

در این نسخه، یک تصمیم UX مهم هم اضافه شده است: Message Center فقط محل مشاهده پیام‌ها نیست؛ بلکه نقطه شروع سریع برای ایجاد بعضی آیتم‌ها هم هست. اما اگر آیتم تخصصی باشد، مثل شکایت یا درخواست خدمات، کاربر از Message Center شروع می‌کند ولی وارد فرم ماژول تخصصی همان آیتم می‌شود.


1. هدف مدل موجودیتی

هدف مدل Message Center / مرکز پیام‌ها این است که تریپیلون بتواند همه پیام‌ها، اعلانات، اخطارها، پیام‌های رسمی، یادآوری‌ها و پیام‌های مرتبط با پرونده‌ها را در یک ساختار قابل پیگیری مدیریت کند.

در تریپیلون، پیام‌ها فقط یک متن ساده نیستند. بعضی پیام‌ها فقط اطلاع‌رسانی‌اند، اما بعضی دیگر نیازمند اقدام، پاسخ، تأیید دریافت، ارجاع داخلی، کامنت داخلی، پیگیری و لاگ رسمی هستند.

این مدل باید این نیازها را پوشش دهد:

Message Center
   ├── نمایش همه پیام‌های کاربر در یک Inbox واحد
   ├── تفکیک پیام‌ها با Type و Tag
   ├── اتصال پیام به ماژول اصلی مثل شکایت، پرداخت، رزرو، بسته، مهمان، رأی‌گیری یا درخواست خدمات
   ├── پشتیبانی از پیام‌های ساده و پیام‌های قابل پیگیری
   ├── پشتیبانی از پیام‌های قابل ارجاع مثل تذکر، اخطار، شکایت و پیام مالی
   ├── ثبت وضعیت مشاهده، تأیید دریافت، پاسخ و بستن پیام
   ├── ثبت لاگ برای پیام‌های رسمی و حساس
   ├── جلوگیری از حذف واقعی پیام‌های رسمی، حقوقی و پرونده‌ای
   └── فراهم کردن نقطه شروع سریع برای ساخت پیام، اعلان، شکایت، درخواست خدمات، جلسه یا رأی‌گیری

2. اصل محصولی مهم

در تریپیلون، Message Center جایگزین ماژول‌های اصلی نیست.

مرکز پیام‌ها فقط لایه نمایش، اطلاع‌رسانی، اقدام سریع و نقطه شروع است. منطق اصلی هر موضوع در ماژول خودش باقی می‌ماند.

مثلاً:

پیام مربوط به شکایت
   → در Message Center دیده می‌شود
   → اما جزئیات و تصمیم‌گیری داخل Complaints & Violations است

پیام یادآوری پرداخت
   → در Message Center دیده می‌شود
   → اما پرداخت داخل Finance / Payment انجام می‌شود

پیام رزرو
   → در Message Center دیده می‌شود
   → اما جزئیات داخل Amenity Booking است

بنابراین مدل درست این است:

Message Center = مرکز مشاهده + اقدام سریع + نقطه شروع
Main Module = محل مدیریت کامل پرونده یا عملیات

3. تصمیم‌های محصولی نهایی

3.1 نام ماژول

نام پیشنهادی ماژول:

Message Center / مرکز پیام‌ها

در UI می‌توان عنوان ساده‌تر استفاده کرد:

پیام‌ها

3.2 Inbox واحد داریم

کاربر باید بتواند همه پیام‌های خودش را در یک Inbox واحد ببیند، اما پیام‌ها با Type، Tag، Priority و Related Module از هم جدا شوند.

نمونه فیلترهای Inbox:

همه
خوانده‌نشده
نیازمند اقدام
رسمی
مالی و پرداخت
شکایات و تخلفات
درخواست‌ها
رزروها
بسته‌ها
مهمان‌ها
سیستمی
اضطراری

3.3 Message Center نقطه شروع ایجاد هم هست

از نظر UX، اگر کاربر در مرکز پیام‌ها پیام‌های شکایت، درخواست خدمات، پرداخت یا رأی‌گیری را می‌بیند، طبیعی است که انتظار داشته باشد بتواند از همان‌جا هم یک مورد جدید ایجاد کند.

پس در Message Center یک دکمه اصلی داریم:

+ جدید

یا:

+ ایجاد

با باز شدن این دکمه، کاربر بر اساس نقش و دسترسی خودش گزینه‌های مرتبط را می‌بیند.

نمونه:

+ جدید
   ├── ارسال پیام
   ├── ثبت اعلان
   ├── ثبت پیام رسمی
   ├── ثبت شکایت / تخلف
   ├── ثبت درخواست خدمات
   ├── دعوت به جلسه
   └── ایجاد رأی‌گیری

اما نکته مهم:

اگر آیتم ساده باشد
   → داخل Message Center ساخته می‌شود

اگر آیتم تخصصی باشد
   → از Message Center شروع می‌شود
   → ولی فرم واقعی در ماژول تخصصی ساخته می‌شود

مثلاً:

ارسال پیام عمومی
   → Message Center

ثبت اعلان قطعی آب
   → Message Center

ثبت شکایت / تخلف
   → Message Center → Complaints & Violations / New Case

ثبت درخواست خدمات
   → Message Center → Service Requests / New Request

ایجاد رأی‌گیری
   → Message Center → Voting / New Vote

دعوت جلسه
   → Message Center → Meetings / New Meeting

این مدل شبیه Google Drive است:

Google Drive
   ├── همه فایل‌ها را نشان می‌دهد
   └── New
        ├── Docs
        ├── Sheets
        └── Slides

اما ساختار واقعی Docs و Sheets داخل ماژول تخصصی خودش است.

در تریپیلون هم:

Message Center
   ├── همه پیام‌ها را نشان می‌دهد
   └── + جدید
        ├── پیام
        ├── اعلان
        ├── شکایت
        ├── درخواست خدمات
        ├── رأی‌گیری
        └── جلسه

3.4 گزینه‌های ایجاد بر اساس نقش متفاوت است

همه نقش‌ها نباید گزینه‌های یکسان ببینند.

مثلاً ساکن:

+ جدید
   ├── ثبت شکایت / تخلف
   ├── ثبت درخواست خدمات
   └── پیام به مدیریت

مدیر ساختمان:

+ جدید
   ├── ارسال پیام
   ├── ثبت اعلان
   ├── ثبت پیام رسمی
   ├── ثبت شکایت / تخلف
   ├── ثبت درخواست خدمات
   ├── دعوت به جلسه
   └── ایجاد رأی‌گیری

بازرس:

+ جدید
   └── ثبت تذکر نظارتی

حسابدار:

+ جدید
   ├── یادآوری پرداخت
   └── پیام مالی

رئیس هیئت‌مدیره:

+ جدید
   ├── پیام هیئت‌مدیره
   ├── دعوت جلسه
   └── ایجاد رأی‌گیری

3.5 همه پیام‌ها Thread ندارند

همه پیام‌ها نباید شبیه تیکت باشند.

بدون Thread:
   ├── اعلان عمومی
   ├── اطلاع بسته
   ├── اطلاع مهمان
   ├── پیام سیستمی ساده
   └── بروزرسانی ساده رزرو

دارای Thread:
   ├── پیام رسمی
   ├── اخطار
   ├── تذکر بازرس
   ├── پیام مرتبط با شکایت
   ├── پیام مرتبط با درخواست خدمات
   ├── پیام مالی نیازمند بررسی
   └── پیام پشتیبانی

3.6 فقط پیام‌های مهم قابل ارجاع هستند

پیام‌های قابل ارجاع:

Assignable Messages
   ├── Official Notice
   ├── Warning
   ├── Audit Notice
   ├── Board Notice
   ├── Case-related Message
   ├── Service Request Message
   ├── Financial Review Message
   └── Support Message

پیام‌های غیرقابل ارجاع:

Not Assignable
   ├── Announcement
   ├── Package Notice
   ├── Visitor Notice
   ├── Simple Booking Update
   ├── Simple System Notification
   └── Emergency Alert

نکته مهم: Emergency Alert نباید وارد چرخه ارجاع شود. این نوع پیام باید سریع دیده شود و برای اقدام فوری طراحی شود.


3.7 کامنت داخلی فقط برای پیام‌های قابل پیگیری است

Internal Comment
   ├── فقط برای Thread / Case / Assignable Message
   ├── قابل مشاهده برای تیم داخلی یا نقش‌های مجاز
   ├── جدا از Reply عمومی
   └── قابل استفاده برای تصمیم‌گیری داخلی

مثلاً در پرونده شکایت، مدیر می‌تواند پیام را به خزانه‌دار یا عضو هیئت‌مدیره ارجاع دهد و آن فرد کامنت داخلی بگذارد؛ اما آن کامنت نباید برای ساکن گزارش‌دهنده یا طرف مقابل دیده شود مگر اینکه به پیام رسمی تبدیل شود.


3.8 پیام‌های رسمی نیازمند Acknowledge هستند

برای پیام‌های عادی، Seen کافی است.
برای پیام‌های رسمی و حساس، Acknowledge لازم است.

Requires Acknowledgement
   ├── Official Notice
   ├── Warning
   ├── Audit Notice
   ├── Board Notice
   ├── Fine Notice
   ├── Legal Notice
   ├── Critical Emergency Alert
   └── Critical Building Announcement

برای برخی پیام‌ها Related Item اجباری است:

Required Related Item
   ├── Complaint-related Message
   ├── Service Request Message
   ├── Payment Reminder
   ├── Fine Notice
   ├── Booking Update
   ├── Package Notice
   ├── Visitor Notice
   ├── Vote Reminder
   └── Official Notice related to a case

برای برخی پیام‌ها Related Item اختیاری است:

Optional Related Item
   ├── General Announcement
   ├── Emergency Alert
   ├── General Official Notice
   └── Simple System Notification

3.10 کانال‌های ارسال

Inbox داخل اپ همیشه مقصد اصلی است.

Delivery Channel
   ├── In-app Inbox
   ├── Push Notification
   ├── SMS
   └── Email / External Channels later

قانون پیشنهادی:

In-app
   └── همه پیام‌ها

Push
   ├── پیام‌های مهم
   ├── پیام‌های نیازمند اقدام
   ├── پرداخت
   ├── شکایت / اخطار
   ├── رزرو
   ├── بسته
   └── اضطراری

SMS
   ├── Emergency Alert
   ├── Legal / Official Notice
   ├── Payment Overdue
   ├── Fine Notice
   ├── Critical Building Announcement
   └── مواردی که مدیر ساختمان یا ادمین ساختمان فعال کرده

SMS نباید برای همه پیام‌ها آزاد باشد؛ چون هم هزینه‌زا است و هم ممکن است برای کاربران آزاردهنده شود.


3.11 حذف واقعی برای پیام‌های رسمی ممنوع است

Normal Announcement
   = قابل آرشیو یا حذف از دید کاربر

Official Notice
   = قابل آرشیو، نه حذف واقعی

Case-related Message
   = غیرقابل حذف، فقط آرشیو از دید کاربر

Legal / Warning / Audit Notice
   = رکورد رسمی و غیرقابل حذف

4. Mermaid — Message Center Entity Model

graph LR USER["کاربر / مخاطب"] --> MC["Message Center / مرکز پیام‌ها"] MC --> INBOX["Inbox / لیست پیام‌ها"] INBOX --> INBOX1["همه پیام‌ها"] INBOX --> INBOX2["خوانده‌نشده"] INBOX --> INBOX3["نیازمند اقدام"] INBOX --> INBOX4["رسمی"] INBOX --> INBOX5["مالی و پرداخت"] INBOX --> INBOX6["شکایات و تخلفات"] INBOX --> INBOX7["درخواست‌ها"] INBOX --> INBOX8["رزروها"] INBOX --> INBOX9["سیستمی"] INBOX --> INBOX10["اضطراری"] MC --> CREATE["Create / ایجاد سریع"] CREATE --> CREATE1["ارسال پیام"] CREATE --> CREATE2["ثبت اعلان"] CREATE --> CREATE3["ثبت پیام رسمی"] CREATE --> CREATE4["ثبت شکایت / تخلف"] CREATE --> CREATE5["ثبت درخواست خدمات"] CREATE --> CREATE6["دعوت به جلسه"] CREATE --> CREATE7["ایجاد رأی‌گیری"] CREATE --> CREATE8["پیام مالی / یادآوری پرداخت"] CREATE --> CREATE9["تذکر نظارتی"] CREATE --> CREATE10["پیام پشتیبانی"] CREATE --> ROUTE["مسیر ایجاد"] ROUTE --> ROUTE1["پیام و اعلان ساده: داخل Message Center"] ROUTE --> ROUTE2["شکایت / تخلف: رفتن به Complaints & Violations"] ROUTE --> ROUTE3["درخواست خدمات: رفتن به Service Requests"] ROUTE --> ROUTE4["رأی‌گیری: رفتن به Voting"] ROUTE --> ROUTE5["جلسه: رفتن به Meetings"] ROUTE --> ROUTE6["پیام مالی پیچیده: رفتن به Finance"] ROUTE --> ROUTE7["پیام پشتیبانی: رفتن به Support"] CREATE --> CREATE_ACCESS["دسترسی ایجاد بر اساس نقش"] CREATE_ACCESS --> CA1["ساکن: شکایت / درخواست خدمات / پیام به مدیریت"] CREATE_ACCESS --> CA2["مدیر ساختمان: پیام / اعلان / رسمی / شکایت / خدمات / جلسه / رأی‌گیری"] CREATE_ACCESS --> CA3["بازرس: تذکر نظارتی"] CREATE_ACCESS --> CA4["حسابدار: یادآوری پرداخت / پیام مالی"] CREATE_ACCESS --> CA5["رئیس هیئت‌مدیره: پیام هیئت‌مدیره / جلسه / رأی‌گیری"] MC --> MSG["Message / پیام"] MSG --> MSG1["عنوان"] MSG --> MSG2["خلاصه پیام"] MSG --> MSG3["متن کامل"] MSG --> MSG4["فرستنده"] MSG --> MSG5["گیرنده / مخاطب"] MSG --> MSG6["تاریخ ایجاد"] MSG --> MSG7["تاریخ ارسال"] MSG --> MSG8["پیوست‌ها"] MSG --> TYPE["نوع پیام"] TYPE --> TYPE1["Announcement / اعلان عمومی"] TYPE --> TYPE2["Emergency Alert / هشدار اضطراری"] TYPE --> TYPE3["Official Notice / پیام رسمی"] TYPE --> TYPE4["Warning / اخطار"] TYPE --> TYPE5["Audit Notice / تذکر بازرس"] TYPE --> TYPE6["Board Notice / پیام هیئت‌مدیره"] TYPE --> TYPE7["Payment Reminder / یادآوری پرداخت"] TYPE --> TYPE8["Fine Notice / اعلام جریمه"] TYPE --> TYPE9["Meeting Invitation / دعوت جلسه"] TYPE --> TYPE10["Vote Reminder / یادآوری رأی‌گیری"] TYPE --> TYPE11["Case-related Message / پیام مرتبط با پرونده"] TYPE --> TYPE12["Service Request Update / بروزرسانی درخواست خدمات"] TYPE --> TYPE13["Booking Update / بروزرسانی رزرو"] TYPE --> TYPE14["Package Notice / اطلاع بسته"] TYPE --> TYPE15["Visitor Notice / اطلاع مهمان"] TYPE --> TYPE16["System Notification / پیام سیستمی"] TYPE --> TYPE17["Support Message / پیام پشتیبانی"] MSG --> TAG["Tag / برچسب"] TAG --> TAG1["رسمی"] TAG --> TAG2["مالی"] TAG --> TAG3["نیازمند اقدام"] TAG --> TAG4["نیازمند پاسخ"] TAG --> TAG5["نیازمند تأیید دریافت"] TAG --> TAG6["اضطراری"] TAG --> TAG7["پرونده‌ای"] TAG --> TAG8["سیستمی"] MSG --> SEV["اهمیت / شدت"] SEV --> SEV1["اطلاع‌رسانی"] SEV --> SEV2["معمولی"] SEV --> SEV3["مهم"] SEV --> SEV4["هشدار"] SEV --> SEV5["بحرانی"] SEV --> SEV6["رسمی / حقوقی"] MSG --> AUD["مخاطب / Audience"] AUD --> AUD1["کل ساختمان"] AUD --> AUD2["بلوک مشخص"] AUD --> AUD3["طبقه مشخص"] AUD --> AUD4["واحد مشخص"] AUD --> AUD5["شخص مشخص"] AUD --> AUD6["مالکین"] AUD --> AUD7["مستأجران"] AUD --> AUD8["ساکنین اصلی"] AUD --> AUD9["اعضای خانواده با دسترسی"] AUD --> AUD10["هیئت‌مدیره"] AUD --> AUD11["تیم ساختمان"] AUD --> AUD12["نقش مشخص"] MSG --> VIS["سطح مشاهده / Visibility"] VIS --> VIS1["عمومی برای ساختمان"] VIS --> VIS2["فقط مخاطبان هدف"] VIS --> VIS3["اعضای واحد"] VIS --> VIS4["فقط ساکن اصلی"] VIS --> VIS5["فقط مالک"] VIS --> VIS6["فقط مستأجر"] VIS --> VIS7["فقط مدیر / ادمین"] VIS --> VIS8["فقط هیئت‌مدیره / نظارت"] VIS --> VIS9["فقط تیم داخلی"] VIS --> VIS10["فقط شخص مشخص"] MSG --> REL["ارتباط با ماژول / Related Item"] REL --> REL1["واحد"] REL --> REL2["پرداخت / صورتحساب"] REL --> REL3["پرونده شکایت / تخلف"] REL --> REL4["درخواست خدمات"] REL --> REL5["رزرو امکانات"] REL --> REL6["بسته"] REL --> REL7["مهمان"] REL --> REL8["رأی‌گیری"] REL --> REL9["جلسه"] REL --> REL10["سند"] REL --> REL11["قانون ساختمان"] REL --> REL12["شیفت / نیروی ساختمان"] REL --> REL13["درخواست فروش / اجاره"] REL --> REL14["معامله فروش / اجاره"] MSG --> SOURCE["منبع پیام"] SOURCE --> SOURCE1["دستی"] SOURCE --> SOURCE2["سیستمی"] SOURCE --> SOURCE3["اتوماسیون قانون‌محور"] SOURCE --> SOURCE4["رویداد ماژول"] SOURCE --> SOURCE5["اقدام داخل پرونده"] SOURCE --> SOURCE6["پشتیبانی"] MSG --> STATUS["وضعیت پیام"] STATUS --> STATUS1["خوانده‌نشده"] STATUS --> STATUS2["خوانده‌شده"] STATUS --> STATUS3["ارسال‌شده"] STATUS --> STATUS4["تحویل‌شده"] STATUS --> STATUS5["دیده‌شده"] STATUS --> STATUS6["دریافت تأیید‌شده"] STATUS --> STATUS7["پاسخ داده‌شده"] STATUS --> STATUS8["نیازمند اقدام"] STATUS --> STATUS9["در انتظار پاسخ"] STATUS --> STATUS10["حل‌شده"] STATUS --> STATUS11["بسته‌شده"] STATUS --> STATUS12["منقضی‌شده"] MSG --> ACTION["اقدام اصلی / Primary Action"] ACTION --> ACTION1["مشاهده"] ACTION --> ACTION2["تأیید دریافت"] ACTION --> ACTION3["پاسخ دادن"] ACTION --> ACTION4["پرداخت"] ACTION --> ACTION5["ثبت اعتراض"] ACTION --> ACTION6["افزودن مدرک"] ACTION --> ACTION7["رأی دادن"] ACTION --> ACTION8["مشاهده پرونده"] ACTION --> ACTION9["ارجاع"] ACTION --> ACTION10["تأیید / رد"] ACTION --> ACTION11["بستن"] MC --> THREAD["Thread / گفت‌وگو و پیگیری"] THREAD --> THREAD1["فعال فقط برای پیام‌های قابل پیگیری"] THREAD --> THREAD2["پاسخ‌های عمومی"] THREAD --> THREAD3["کامنت‌های داخلی"] THREAD --> THREAD4["پیوست‌های داخلی"] THREAD --> THREAD5["تاریخچه تصمیم‌ها"] THREAD --> THREAD6["نتیجه نهایی"] THREAD --> ASSIGN["Assignment / ارجاع"] ASSIGN --> ASSIGN1["قابل ارجاع بودن پیام"] ASSIGN --> ASSIGN2["ارجاع به شخص"] ASSIGN --> ASSIGN3["ارجاع به نقش"] ASSIGN --> ASSIGN4["مهلت پاسخ"] ASSIGN --> ASSIGN5["توضیح ارجاع"] ASSIGN --> ASSIGN6["برگشت به ارجاع‌دهنده"] ASSIGN --> ASSIGN7["وضعیت ارجاع"] THREAD --> COMMENT["Internal Comment / کامنت داخلی"] COMMENT --> COMMENT1["فقط برای تیم داخلی"] COMMENT --> COMMENT2["فقط برای نقش‌های مجاز"] COMMENT --> COMMENT3["قابل تبدیل به پاسخ رسمی"] COMMENT --> COMMENT4["غیرقابل مشاهده برای مخاطب عمومی"] MC --> DELIVERY["Delivery / کانال ارسال"] DELIVERY --> DELIVERY1["داخل اپ"] DELIVERY --> DELIVERY2["پوش نوتیفیکیشن"] DELIVERY --> DELIVERY3["پیامک"] DELIVERY --> DELIVERY4["ایمیل / کانال خارجی در آینده"] DELIVERY --> D_RULE["قانون ارسال"] D_RULE --> D_RULE1["داخل اپ برای همه پیام‌ها"] D_RULE --> D_RULE2["پوش برای پیام‌های مهم یا نیازمند اقدام"] D_RULE --> D_RULE3["پیامک فقط برای رسمی، اضطراری، مالی یا حقوقی"] D_RULE --> D_RULE4["قابل تنظیم توسط ادمین ساختمان"] MC --> PREF["تنظیمات کاربر"] PREF --> PREF1["اعلان‌های مالی"] PREF --> PREF2["رزروها"] PREF --> PREF3["بسته‌ها"] PREF --> PREF4["درخواست خدمات"] PREF --> PREF5["اعلانات عمومی"] PREF --> PREF6["پیام‌های غیرضروری"] PREF --> PREF7["پیام‌های غیرقابل خاموش شدن"] PREF7 --> PREF7A["هشدار اضطراری"] PREF7 --> PREF7B["پیام رسمی"] PREF7 --> PREF7C["اخطار حقوقی"] PREF7 --> PREF7D["اعلان بحرانی ساختمان"] MC --> DELETE["حذف / آرشیو"] DELETE --> DELETE1["پیام عادی: حذف از دید کاربر"] DELETE --> DELETE2["پیام رسمی: فقط آرشیو"] DELETE --> DELETE3["پیام پرونده‌ای: غیرقابل حذف واقعی"] DELETE --> DELETE4["پیام حقوقی / اخطار / تذکر بازرس: رکورد غیرقابل حذف"] MC --> LOG["Audit Log / لاگ"] LOG --> LOG1["ایجادکننده"] LOG --> LOG2["زمان ایجاد"] LOG --> LOG3["زمان ارسال"] LOG --> LOG4["زمان تحویل"] LOG --> LOG5["زمان مشاهده"] LOG --> LOG6["زمان تأیید دریافت"] LOG --> LOG7["زمان پاسخ"] LOG --> LOG8["تاریخچه ارجاع"] LOG --> LOG9["تاریخچه کامنت داخلی"] LOG --> LOG10["تاریخچه تغییر وضعیت"] LOG --> LOG11["بسته شدن پیام"]

5. توضیح موجودیت‌های اصلی

5.1 Message Center / مرکز پیام‌ها

مرکز پیام‌ها یک نقطه واحد برای مشاهده همه پیام‌های مرتبط با کاربر است. کاربر نباید برای دیدن پیام‌های پرداخت، شکایت، رزرو، بسته یا اعلان عمومی به چند جای مختلف برود.

اما مرکز پیام‌ها فقط مرکز نمایش و اقدام سریع است. مدیریت کامل هر موضوع در ماژول اصلی خودش انجام می‌شود.


5.2 Create / ایجاد سریع

ایجاد سریع یک Entry Point داخل Message Center است.

هدف آن این است که کاربر لازم نباشد برای شروع یک اقدام جدید، حتماً منوی تخصصی آن ماژول را پیدا کند.

اما ایجاد سریع نباید باعث شود منطق ماژول‌ها با هم قاطی شود.

قانون:

پیام ساده، اعلان، پیام رسمی عمومی
   → داخل Message Center ایجاد می‌شود

شکایت، تخلف، درخواست خدمات، رأی‌گیری، جلسه، پیام مالی پیچیده
   → از Message Center شروع می‌شود
   → اما در ماژول تخصصی خودش ساخته و مدیریت می‌شود

این طراحی باعث می‌شود UX ساده بماند و همزمان معماری محصول تمیز بماند.


5.3 Message / پیام

هر پیام یک رکورد مستقل است که می‌تواند ساده، رسمی، سیستمی، مالی، پرونده‌ای یا اضطراری باشد.

فیلدهای پایه پیام:

Title
Summary
Body
Sender
Recipient / Audience
Created Date
Sent Date
Attachments
Message Type
Status
Priority / Severity
Related Item

5.4 Message Type / نوع پیام

نوع پیام تعیین می‌کند پیام چه رفتاری دارد.

مثلاً:

Announcement
   = اطلاع‌رسانی عمومی، معمولاً بدون پاسخ و بدون ارجاع

Official Notice
   = پیام رسمی، قابل پیگیری، معمولاً نیازمند تأیید دریافت

Warning
   = اخطار رسمی، ممکن است به پرونده یا تخلف وصل باشد

Case-related Message
   = پیام مرتبط با پرونده شکایت، تخلف یا درخواست

Payment Reminder
   = یادآوری پرداخت یا بدهی

Emergency Alert
   = پیام فوری و حساس، بدون چرخه ارجاع

5.5 Thread / گفت‌وگو و پیگیری

Thread فقط برای پیام‌هایی فعال می‌شود که نیاز به پیگیری دارند.

Thread می‌تواند شامل این موارد باشد:

Replies
Internal Comments
Assignments
Public Responses
Attachments
Decision History
Resolution

برای پیام‌های ساده مثل اطلاع بسته یا اعلان عمومی، Thread لازم نیست.


5.6 Assignment / ارجاع

بعضی پیام‌ها باید مثل تیکت قابل ارجاع باشند.

مثلاً در پرونده شکایت:

ساکن شکایت ثبت می‌کند
مدیر ساختمان بررسی می‌کند
مدیر پرونده را به خزانه‌دار یا عضو هیئت‌مدیره ارجاع می‌دهد
ارجاع‌شونده کامنت داخلی می‌گذارد
مدیر پیام رسمی به طرف مقابل ارسال می‌کند

فیلدهای Assignment:

Assigned To Person
Assigned To Role
Due Date
Assignment Note
Return To Sender
Assignment Status

5.7 Internal Comment / کامنت داخلی

کامنت داخلی فقط برای تیم مجاز است و نباید برای مخاطب عمومی دیده شود.

کاربردها:

تحلیل داخلی مدیر
نظر حسابدار
نظر خزانه‌دار
نظر عضو هیئت‌مدیره
یادداشت بازرس
تصمیم‌سازی قبل از ارسال پیام رسمی

کامنت داخلی می‌تواند بعداً توسط نقش مجاز به یک پاسخ رسمی تبدیل شود.


هر پیام می‌تواند به یک ماژول یا موجودیت اصلی وصل شود.

مثلاً:

Payment Reminder → Invoice / Payment
Fine Notice → Complaint Case + Unit Charge
Package Notice → Package
Visitor Notice → Visitor Pass
Booking Update → Amenity Booking
Complaint Message → Complaint / Violation Case
Service Update → Service Request

این اتصال برای گزارش‌گیری، لاگ، پیگیری و حفظ منطق محصول ضروری است.


5.9 Visibility / سطح مشاهده

Visibility مشخص می‌کند چه کسی پیام را می‌بیند.

این بخش برای حریم خصوصی بسیار مهم است.

مثلاً:

پیام عمومی قطعی آب → کل ساختمان
یادآوری شارژ → واحد مربوطه
اخطار تخلف → طرف مقابل / واحد متخلف
کامنت داخلی پرونده → فقط تیم داخلی
تذکر بازرس → مدیر یا هیئت‌مدیره

5.10 Status / وضعیت پیام

پیام‌های ساده و پیام‌های رسمی وضعیت یکسان ندارند.

برای پیام ساده:

Unread
Read

برای پیام رسمی:

Sent
Delivered
Seen
Acknowledged
Responded
Closed

برای پیام قابل ارجاع:

Open
Assigned
In Review
Returned
Waiting for Response
Ready for Decision
Closed

5.11 Delivery / کانال ارسال

هر پیام داخل اپ ثبت می‌شود، اما ممکن است از کانال‌های دیگری هم اطلاع‌رسانی شود.

In-app Inbox
Push Notification
SMS
Email / External later

قانون مهم: پیامک فقط برای پیام‌های مهم، رسمی، اضطراری یا مالی استفاده شود.


5.12 Audit Log / لاگ

برای پیام‌های رسمی، پرونده‌ای و حساس، لاگ اجباری است.

لاگ باید بتواند نشان دهد:

چه کسی پیام را ساخته
چه زمانی ارسال شده
چه زمانی دیده شده
آیا تأیید دریافت شده یا نه
چه کسی پاسخ داده
به چه کسی ارجاع شده
چه کامنت داخلی ثبت شده
چه زمانی بسته شده

6. قوانین پیشنهادی برای نوع پیام‌ها

نوع پیام Thread قابل ارجاع کامنت داخلی Acknowledge Related Item مسیر ایجاد
Announcement / اعلان عمومی نه نه نه معمولاً نه اختیاری Message Center
Emergency Alert / هشدار اضطراری نه نه نه بله، در موارد بحرانی اختیاری Message Center
Official Notice / پیام رسمی بله بله بله بله اختیاری / گاهی اجباری Message Center
Warning / اخطار بله بله بله بله معمولاً اجباری ماژول مربوطه / گاهی Message Center
Audit Notice / تذکر بازرس بله بله بله بله معمولاً اجباری Message Center یا Governance
Board Notice / پیام هیئت‌مدیره بله بله بله بله اختیاری / گاهی اجباری Message Center یا Board
Payment Reminder / یادآوری پرداخت نه / محدود نه / محدود نه نه اجباری Finance یا Message Center برای نقش مجاز
Fine Notice / اعلام جریمه بله بله بله بله اجباری Complaints & Violations / Finance
Meeting Invitation / دعوت جلسه محدود نه / محدود نه گاهی اجباری Meetings یا Message Center
Vote Reminder / یادآوری رأی‌گیری نه نه نه نه اجباری Voting
Case-related Message / پیام پرونده‌ای بله بله بله بسته به نوع اجباری ماژول پرونده مربوطه
Service Request Update / بروزرسانی درخواست خدمات بله / محدود بله بله نه اجباری Service Requests
Booking Update / بروزرسانی رزرو نه نه نه نه اجباری Amenity Booking
Package Notice / اطلاع بسته نه نه نه نه اجباری Packages
Visitor Notice / اطلاع مهمان نه نه نه نه اجباری Visitors
System Notification / پیام سیستمی نه نه نه نه اختیاری System
Support Message / پیام پشتیبانی بله بله بله گاهی اجباری Support

7. UX Rule — مشاهده و ایجاد از یک جا، مدیریت در ماژول تخصصی

قانون نهایی UX:

Message Center
   = مشاهده همه پیام‌ها
   = اقدام سریع روی پیام‌ها
   = شروع ایجاد آیتم جدید

Specialized Modules
   = ساختار کامل
   = مدیریت کامل
   = وضعیت‌ها
   = قوانین
   = لاگ تخصصی

مثال‌ها:

مدیر می‌خواهد قطعی آب را اعلام کند
   → Message Center → ثبت اعلان

مدیر می‌خواهد به واحد متخلف اخطار بدهد
   → Complaints & Violations → ایجاد یا باز کردن پرونده → ارسال اخطار
   → اخطار در Message Center هم دیده می‌شود

ساکن می‌خواهد شکایت ثبت کند
   → Message Center → + جدید → ثبت شکایت
   → انتقال به فرم New Complaint Case

ساکن می‌خواهد درخواست تعمیر ثبت کند
   → Message Center → + جدید → ثبت درخواست خدمات
   → انتقال به فرم New Service Request

رئیس هیئت‌مدیره می‌خواهد رأی‌گیری ایجاد کند
   → Message Center → + جدید → ایجاد رأی‌گیری
   → انتقال به Voting / New Vote

این مدل باعث می‌شود مرکز پیام‌ها برای کاربر طبیعی و قابل فهم باشد، اما منطق محصولی ماژول‌ها خراب نشود.


8. جمع‌بندی نهایی

  1. Message Center ماژول اصلی ارتباطات است.
  2. Announcement / Official Notice / Notification / Case Message همه Type داخل Message Center هستند.
  3. Message Center جایگزین ماژول‌های تخصصی نیست.
  4. Message Center هم مرکز مشاهده است، هم Entry Point ایجاد سریع.
    • جدید باید ساده باشد و بر اساس Permission ساخته شود.
  5. همه پیام‌ها Thread ندارند.
  6. فقط پیام‌های رسمی، پرونده‌ای، مالی نیازمند بررسی و پشتیبانی قابل ارجاع‌اند.
  7. SMS فقط برای پیام‌های حساس، رسمی، اضطراری و مالی استفاده می‌شود.
  8. پیام رسمی حذف واقعی ندارد؛ فقط آرشیو می‌شود.
  9. UI وضعیت‌ها را ساده نشان می‌دهد، ولی دیتامدل کامل‌تر است.

بازگشت