مرکز پیامها
مدل موجودیتی مرکز پیامها و ارتباطات تریپیلون
این سند مدل موجودیتی 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
3.9 همه پیامها Related Item دارند یا میتوانند داشته باشند
برای برخی پیامها 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
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 / کامنت داخلی
کامنت داخلی فقط برای تیم مجاز است و نباید برای مخاطب عمومی دیده شود.
کاربردها:
تحلیل داخلی مدیر
نظر حسابدار
نظر خزانهدار
نظر عضو هیئتمدیره
یادداشت بازرس
تصمیمسازی قبل از ارسال پیام رسمی
کامنت داخلی میتواند بعداً توسط نقش مجاز به یک پاسخ رسمی تبدیل شود.
5.8 Related Item / ارتباط با ماژول اصلی
هر پیام میتواند به یک ماژول یا موجودیت اصلی وصل شود.
مثلاً:
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. جمعبندی نهایی
- Message Center ماژول اصلی ارتباطات است.
- Announcement / Official Notice / Notification / Case Message همه Type داخل Message Center هستند.
- Message Center جایگزین ماژولهای تخصصی نیست.
- Message Center هم مرکز مشاهده است، هم Entry Point ایجاد سریع.
-
- جدید باید ساده باشد و بر اساس Permission ساخته شود.
- همه پیامها Thread ندارند.
- فقط پیامهای رسمی، پروندهای، مالی نیازمند بررسی و پشتیبانی قابل ارجاعاند.
- SMS فقط برای پیامهای حساس، رسمی، اضطراری و مالی استفاده میشود.
- پیام رسمی حذف واقعی ندارد؛ فقط آرشیو میشود.
- UI وضعیتها را ساده نشان میدهد، ولی دیتامدل کاملتر است.