فرض کنید یک شرکت همزمان چهار برند، سه خط محصول و چند شعبه خدماتی دارد. مشتری برند اول نباید Knowledge Base، فرمها یا SLAهای برند دوم را ببیند؛ تیم پشتیبانی هم نباید برای هر برند وارد یک نرمافزار جدا شود. از طرف دیگر، مدیر خدمات میخواهد یک نمای متمرکز از حجم Ticketها، قراردادها، زمان پاسخ، Accountها و عملکرد کارشناسان داشته باشد.
در چنین سناریویی، مسئله دیگر صرفاً «داشتن سیستم تیکتینگ» نیست. سازمان به معماری پشتیبانی چندبرندی و چندپرتالی نیاز دارد؛ یعنی هر برند یا واحد، تجربه مستقل خودش را داشته باشد، اما عملیات پشتیبانی از یک هسته مشترک مدیریت شود. ManageEngine SupportCenter Plus دقیقاً برای همین مدل Customer Support طراحی شده است.
در نسخههای جدید SupportCenter Plus، مفهومی که قبلاً با عنوان Business Unit شناخته میشد با عنوان Portal ارائه میشود. هر Portal میتواند تنظیمات، محصولات، مشتریان، SLAها، فرمها و تجربه پشتیبانی خودش را داشته باشد؛ در حالی که Support Repها میتوانند بر اساس مجوز و Role در چند Portal فعالیت کنند.
برای آشنایی با مفهوم عمومی Service Desk و تفاوت نقطه تماس خدمات با یک سامانه صرفاً ثبت Ticket، مقاله «میز خدمت چیست؟» را نیز میتوانید مطالعه کنید. این مقاله اما روی سناریوی مشخص پشتیبانی مشتریان بیرونی، چند برند، چند Portal و مدل لایسنس SupportCenter Plus تمرکز دارد.
SupportCenter Plus دقیقاً برای چه مسئلهای ساخته شده است؟
SupportCenter Plus یک پلتفرم Customer Support و Customer Service است. محور آن Account، Contact، Product، Contract، SLA، Customer Portal و Request است؛ یعنی برخلاف Service Desk داخلی که معمولاً با Employee، Asset، Incident، Change و CMDB سروکار دارد، اینجا مرکز ثقل روی مشتری و رابطه خدماتی با مشتری قرار میگیرد.
طبق مستندات رسمی ManageEngine، SupportCenter Plus قابلیتهایی مانند Multi-channel Support، Request Tracking، Portal، Account & Contact Management، Time Tracking & Billing، Knowledge Base، Customer Portal، SLA، Live Chat، Field Service، Survey، Request Life Cycle و API/Integration را در یک محصول ارائه میکند.
صفحه فعلی معرفی مدانت برای این محصول نیز SupportCenter Plus را بهعنوان سامانه مدیریت پشتیبانی مشتریان معرفی میکند. اگر هدف شما ارزیابی محصول، لایسنس، بومیسازی، استقرار یا پشتیبانی است، صفحه سامانه مدیریت پشتیبانی مشتریان مدانت نقطه شروع تجاری این Cluster است.
Portal در SupportCenter Plus چیست؟
Portal را میتوان یک فضای مستقل پشتیبانی در همان Installation دانست. برای مثال یک هلدینگ میتواند برای «برند A»، «برند B»، «خدمات سازمانی» و «شبکه نمایندگان» Portalهای جدا داشته باشد.
مزیت اصلی این است که جداسازی تجربه مشتری بدون تکثیر کامل زیرساخت انجام میشود. هر Portal میتواند منطق خدماتی متفاوتی داشته باشد، اما کارشناسان مشترک همچنان از یک محیط عملیاتی استفاده کنند.
| سناریو | مدل پیشنهادی Portal | دلیل |
|---|---|---|
| چند برند مستقل | یک Portal برای هر برند | فرم، SLA، Knowledge Base و هویت مستقل |
| چند کشور یا منطقه | Portal بر اساس Region در صورت تفاوت واقعی فرآیند | ساعات کاری، زبان، Holiday و تیم متفاوت |
| چند خط محصول | Portal جدا فقط اگر تیم/فرآیند واقعاً مستقل است | جلوگیری از ایجاد Portal بیش از نیاز |
| MSP یا خدمات برونسپاری | Portal بر اساس مشتری یا Segment | تفکیک تجربه و اطلاعات مشتریان |
| شعب یک برند با فرآیند یکسان | معمولاً یک Portal + Account/Sub-account | کاهش پیچیدگی مدیریت |
نکته مهم این است که Portal را نباید صرفاً چون «میتوانیم» بسازیم. هر Portal یک Boundary عملیاتی ایجاد میکند و باید دلیل مشخصی مثل Branding، SLA متفاوت، تیم مستقل، Privacy، Product Catalog متفاوت یا Workflow مستقل داشته باشد.
تغییر مهم لایسنس از نسخه 14.7 به بعد
یکی از مهمترین تغییرات SupportCenter Plus از نسخه 14.7 به بعد، مدل جدید Licensing برای Portalها و Support Repهاست. طبق FAQ رسمی ManageEngine، Support Repها اکنون Global هستند؛ یعنی یک کارشناس برای فعالیت در چند Portal لازم نیست برای هر Portal مجوز جداگانه داشته باشد.
در مدل فعلی، تعداد Portalهای پیشفرض هر Edition چنین است:
| Edition | Portal پیشفرض | جایگاه کلی |
|---|---|---|
| Standard | 1 | Help Desk پایه |
| Professional | 10 | Help Desk + Billing |
| Enterprise | 20 | Help Desk + Billing + Automation Bundle |
این تغییر برای سازمانهای چندبرندی بسیار مهم است. مثلاً اگر ۱۲ Support Rep دارید و هر ۱۲ نفر باید روی چهار Portal مختلف کار کنند، مبنای خرید همچنان تعداد Support Rep موردنیاز سازمان است، نه ۱۲ ضربدر ۴.
ManageEngine همچنین اعلام کرده Portal اضافی بهصورت جداگانه قابل خرید نیست. اگر تعداد Portal موردنیاز شما از سقف Edition بیشتر شود، باید Edition مناسبتر انتخاب شود. بنابراین Portal Sizing باید قبل از خرید لایسنس انجام شود، نه بعد از استقرار.
لایسنس را با تعداد مشتری اشتباه نگیرید
در صفحه Pricing فعلی ManageEngine، مبنای قیمت بر Administrator و Support Rep است و برای تعداد End User محدودیت مستقیمی ذکر نشده است. این تفاوت در برآورد هزینه مهم است؛ زیرا سازمانی ممکن است صدها یا هزاران Contact داشته باشد اما فقط یک تیم ۱۰ یا ۲۰ نفره پاسخگویی داشته باشد.
برای تهیه Quote متناسب با شرایط ایران، تعداد Support Rep، Edition، Portal، زبان، Add-on و مدل تمدید را مشخص کنید و سپس از صفحه استعلام قیمت لایسنس محصولات ManageEngine استفاده کنید. قیمت عمومی سایت سازنده صرفاً یک Reference جهانی است و هزینه نهایی میتواند به Region، Subscription، شرایط خرید و خدمات مدانت وابسته باشد.
Account و Contact؛ ستون فقرات Customer Support
یکی از تفاوتهای مهم SupportCenter Plus با یک Ticketing ساده، مدل Account & Contact است. Account میتواند سازمان مشتری باشد و Contact افراد مرتبط با همان مشتری.
این ساختار به تیم پشتیبانی اجازه میدهد فقط یک Ticket نبیند؛ بلکه Context مشتری را ببیند: تاریخچه تعامل، SLA، Product Ownership، Noteهای مهم، Accountهای زیرمجموعه و اطلاعات مرتبط.
در مستندات فعلی ManageEngine، قابلیت Sub-account، Account History، Account Notes، فیلتر پیشرفته و اتصال Knowledge Base به Accountها نیز ارائه شده است. در نسخه 15.1 و Build 15110 که در 22 ژانویه 2026 منتشر شد، Account Module بازطراحی شد و Account Template، Sub-account Template، Note، History و Advanced Filter بهبود پیدا کردند.
چه زمانی Sub-account بهتر از Portal است؟
فرض کنید یک مشتری بزرگ ۲۰ شعبه دارد. اگر تمام شعب یک قرارداد، یک برند و فرآیند پشتیبانی مشابه دارند، ساخت ۲۰ Portal تصمیم خوبی نیست. در چنین حالتی Account و Sub-account معمولاً مدل تمیزتری ایجاد میکند.
Portal زمانی ارزش دارد که تجربه یا فرآیند واقعاً باید مستقل باشد. Sub-account زمانی ارزش دارد که ساختار مشتری سلسلهمراتبی است اما Logic پشتیبانی مشترک باقی میماند.
| سؤال | اگر پاسخ «بله» است |
|---|---|
| Branding و Portal مشتری باید مستقل باشد؟ | Portal جدا را بررسی کنید |
| Category، SLA، Holiday یا Workflow کاملاً متفاوت است؟ | Portal جدا منطقیتر است |
| فقط ساختار حقوقی/شعبهای مشتری متفاوت است؟ | Account/Sub-account کافی است |
| Support Repهای مشترک روی همه بخشها کار میکنند؟ | Global Support Rep مدل مناسبی است |
| اطلاعات مشتریان باید از هم تفکیک شود؟ | Portal/Account Boundary را دقیق طراحی کنید |
SLA را بر اساس قرارداد مشتری طراحی کنید، نه فقط Priority
در پشتیبانی B2B، یک Incident با Priority یکسان الزاماً برای همه مشتریان SLA یکسان ندارد. مشتری Premium ممکن است First Response یکساعته داشته باشد و مشتری Standard چهار ساعت.
SupportCenter Plus برای مدیریت SLA، قرارداد و Account Context طراحی شده است. در طراحی واقعی بهتر است SLA حداقل این ابعاد را ببیند:
- نوع قرارداد یا Support Plan؛
- Criticality محصول؛
- Account یا Segment مشتری؛
- Operational Hours و Holiday؛
- Response و Resolution Target؛
- Escalation Level؛
- Channel ورودی و نوع Request.
اگر SLA فقط با یک Priority عمومی ساخته شود، خیلی زود استثناها بیشتر از Ruleها میشوند. طراحی Contract-aware از ابتدا، گزارشگیری و Billing را هم قابل اعتمادتر میکند.
Customer Portal باید چه چیزی را از تماس تلفنی حذف کند؟
هدف Customer Portal این نیست که مشتری را مجبور کنیم «خودش مشکلش را حل کند». هدف این است که کارهای قابل Self-Service از صف تماس تلفنی خارج شوند و مشتری برای کارهای واقعی به کارشناس دسترسی سریعتری داشته باشد.
Portal فعلی SupportCenter Plus میتواند امکان ثبت Ticket، مشاهده وضعیت، جستوجوی Knowledge Base و دسترسی به اطلاعات مرتبط را فراهم کند. یک Portal خوب باید حداقل این چهار کار را ساده کند:
- ثبت درخواست با اطلاعات کامل و فرم مناسب؛
- پیگیری Status بدون تماس تلفنی؛
- پیدا کردن Solution برای سؤالهای تکراری؛
- مشاهده Announcement یا اطلاعیههای سرویس.
اگر مشتری بعد از ورود به Portal باز هم برای پرسیدن «تیکتم کجاست؟» تماس میگیرد، مسئله معمولاً UI نیست؛ Workflow، Status Naming یا Notification Design نیاز به اصلاح دارد.
Knowledge Base را برای مشتری بنویسید، نه برای تیم فنی
Knowledge Base در SupportCenter Plus میتواند سؤالهای تکراری را از صف پشتیبانی خارج کند، اما فقط وقتی Solution واقعاً برای Contact قابل فهم باشد.
یک مقاله داخلی با دستورهای Debug و جزئیات فنی ممکن است برای Support Rep مفید باشد، اما نسخه Customer-facing باید مسئله، اقدام ایمن، نتیجه مورد انتظار و مسیر Escalation را روشن کند.
مدل پیشنهادی برای هر Solution:
- نشانه یا سؤال مشتری؛
- علتهای محتمل بدون اصطلاحات اضافه؛
- مراحل قابل انجام توسط مشتری؛
- مواردی که مشتری نباید انجام دهد؛
- شرط ثبت Ticket یا Escalation؛
- Product/Version مربوط.
Multi-channel یعنی یک Timeline، نه چند Inbox
SupportCenter Plus کانالهایی مانند Email، Portal، Phone و سایر مسیرهای ارتباطی را در یک Customer Support Context متمرکز میکند. ارزش این قابلیت زمانی مشخص میشود که مشتری امروز Email بزند و فردا تماس بگیرد؛ کارشناس باید تاریخچه را ببیند، نه اینکه دوباره از ابتدا سؤال کند.
برای هر Channel بهتر است Ownership و Conversion Rule روشن باشد. مثلاً Email باید به Ticket تبدیل شود، تماس تلفنی باید توسط Support Rep ثبت شود و Chat در صورت نیاز به Request قابل پیگیری تبدیل شود.
Billing و Time Tracking چه زمانی ارزش تجاری پیدا میکند؟
اگر خدمات پشتیبانی شما Contract-based است، Time Entry فقط ابزار سنجش کارشناس نیست؛ میتواند مبنای Billing، Capacity Planning و Profitability Analysis باشد.
Professional و Enterprise در ساختار Pricing فعلی به Billing مجهز هستند. پیش از فعال کردن Billing، این موارد باید استاندارد شوند:
- چه فعالیتی Billable است؟
- Travel Time چگونه محاسبه میشود؟
- Remote و On-site Rate متفاوت است؟
- Minimum Billable Unit چند دقیقه است؟
- کارهای شامل قرارداد از Credit یا Entitlement کم میشوند؟
- چه کسی Time Entry را تأیید میکند؟
بدون این قواعد، گزارش Billing دقیق به نظر میرسد اما از نظر مالی قابل اتکا نیست.
Field Service برای تیمهای حضوری
برای کسبوکارهایی که بخشی از پشتیبانی در محل مشتری انجام میشود، Field Service Management اهمیت پیدا میکند. ManageEngine در SupportCenter Plus امکان برنامهریزی خدمات On-site و استفاده از Map Integration برای مشاهده موقعیت کارشناسان و تخصیص کار بر اساس Location را ارائه میکند.
در ایران، حتی اگر از تمام Integrationهای نقشه استفاده نشود، اصل معماری همچنان مهم است: درخواست حضوری باید Appointment، Location، Technician، Travel Time، Work Log و نتیجه بازدید داشته باشد؛ نه اینکه در Comment یک Ticket گم شود.
SupportCenter Plus یا ServiceDesk Plus؟
این دو محصول همخانوادهاند اما مسئله یکسانی را حل نمیکنند.
| نیاز اصلی | انتخاب محتمل |
|---|---|
| پشتیبانی کارمندان و خدمات IT داخلی | ServiceDesk Plus |
| Incident، Change، CMDB و IT Asset در ITSM | ServiceDesk Plus |
| پشتیبانی مشتری بیرونی، Account و Contact | SupportCenter Plus |
| چند برند/Portal مشتری | SupportCenter Plus |
| Contract، Billing و Product-based Support | SupportCenter Plus |
| ESM برای HR/Finance/Facilities داخلی | ServiceDesk Plus |
اگر سازمان هم Help Desk داخلی و هم Customer Support بیرونی دارد، لازم نیست یکی را جای دیگری استفاده کند. Boundary درست بین Employee Service و Customer Service مهمتر از تلاش برای یکسانسازی مصنوعی دو مسئله متفاوت است.
یک سناریوی Sizing واقعی
فرض کنیم یک شرکت چهار برند دارد، ۱۲ Support Rep، حدود ۸۰۰ Account فعال و پنج هزار Contact. هر برند Branding، SLA و Product Catalog خودش را دارد، اما کارشناسان بین برندها مشترکاند.
از نظر Portal، چهار Portal موردنیاز است. از نظر مدل فعلی SupportCenter Plus، Professional با ۱۰ Portal میتواند از نظر ظرفیت Portal پاسخگو باشد؛ تعداد Support Rep نیز ۱۲ نفر محاسبه میشود و چون Repها Global هستند، برای فعالیت در هر چهار Portal چهار بار لایسنس نمیشوند.
اما انتخاب نهایی Edition فقط با تعداد Portal انجام نمیشود. اگر سازمان به Automation Bundle و قابلیتهای Enterprise نیاز داشته باشد، Enterprise میتواند انتخاب صحیحتری باشد. بنابراین فرآیند Sizing باید دو مرحله داشته باشد:
- Capacity Sizing: تعداد Portal و Support Rep؛
- Feature Sizing: Billing، Automation، Failover، CTI، Live Chat و سایر نیازها.
اشتباههای رایج در استقرار چندپرتالی
ساخت Portal برای هر Department
Department با Portal یکسان نیست. اگر فقط Team داخلی فرق دارد، ممکن است Group و Role کافی باشد.
کپی کامل Workflow بین همه برندها
اگر برندها SLA و Product متفاوت دارند، Clone کورکورانه خیلی زود به استثناهای متعدد منجر میشود.
یک Knowledge Base مشترک بدون Scope
Solution مربوط به یک Product نباید به مشتری Product دیگر پیشنهاد شود مگر اینکه واقعاً عمومی باشد.
نامگذاری Status با زبان تیم فنی
Statusهایی مثل Pending L2 یا Awaiting RCA برای مشتری الزاماً قابل فهم نیستند. Customer-facing Status باید وضعیت واقعی سرویس را توضیح دهد.
خرید Edition قبل از طراحی Portal Map
چون Portal اضافی جداگانه قابل خرید نیست، تعداد Portal موردنیاز مستقیماً میتواند Edition را تغییر دهد.
نکته امنیتی مهم برای On-Premises در 2026
اگر SupportCenter Plus را On-Premises اجرا میکنید، Build امنیتی را بخشی از پروژه بدانید، نه کار بعد از Go-Live.
ManageEngine در 22 ژوئن 2026 Build 15150 را منتشر کرد. طبق Security Advisory رسمی، یک آسیبپذیری High Severity با شناسه CVE-2026-12507 در Reports/Query Reports میتوانست به کاربر احراز هویتشده دارای مجوز Create Query Reports اجازه سوءاستفاده از Queryهای خاص و اجرای Command بدهد. نسخههای 15140 و پایینتر در SupportCenter Plus تحت تأثیر بودند و Fix در 15150 ارائه شد.
بنابراین برای استقرار جدید یا Upgrade:
- از Build پشتیبانیشده و بهروز استفاده کنید؛
- Permission ساخت Query Report را محدود کنید؛
- Upgrade را ابتدا در Test Environment اجرا کنید؛
- Backup و Rollback Plan داشته باشید؛
- بعد از Upgrade، Mail، Portal، SLA، API و Reportهای حیاتی را Smoke Test کنید.
Checklist طراحی قبل از خرید
| موضوع | سؤال تصمیمگیری |
|---|---|
| Portal | چند تجربه واقعاً مستقل برای مشتری داریم؟ |
| Support Rep | چند نفر واقعاً Login و پاسخگویی میکنند؟ |
| Account | مدل مشتری ساده است یا Parent/Sub-account داریم؟ |
| SLA | سطح خدمت بر اساس Contract، Product یا Segment فرق دارد؟ |
| Billing | خدمت Billable، Credit-based یا شامل قرارداد است؟ |
| Knowledge Base | چه محتوایی Public، Account-specific یا Internal است؟ |
| Channel | Email، Phone، Portal، Chat و Field Service چگونه یکپارچه میشوند؟ |
| Automation | چه Workflow و Escalationهایی باید خودکار شوند؟ |
| Integration | CRM، AD، API، Telephony یا سایر سیستمها لازماند؟ |
| Security | Build، Role، Report Permission، Backup و Patch Policy چیست؟ |
مدانت در پروژه SupportCenter Plus چه خدماتی میتواند پوشش دهد؟
خرید نرمافزار فقط یک بخش پروژه است. برای اینکه SupportCenter Plus واقعاً به مرکز عملیات Customer Support تبدیل شود، طراحی Portal، Account Model، SLA، Contract، Workflow، Template، Notification، Knowledge Base و گزارشها باید با مدل کسبوکار سازمان هماهنگ شود.
مدانت برای محصولات ManageEngine مسیرهای تجاری مشخصی برای استعلام لایسنس، جلسه دمو و پروپوزال، آموزش تخصصی و پشتیبانی دارد. در پروژه SupportCenter Plus نیز بهتر است قبل از Quote نهایی، Portal Map و تعداد Support Rep مشخص شوند تا Edition و هزینه بر مبنای معماری واقعی انتخاب شوند.
نکات کلیدی
- Portal در SupportCenter Plus برای تفکیک واقعی تجربه و فرآیند پشتیبانی است؛ نه صرفاً تفکیک Department.
- در مدل لایسنس نسخه 14.7 به بعد، Support Repها Global هستند و برای هر Portal مجوز جداگانه لازم ندارند.
- Standard یک Portal، Professional ده Portal و Enterprise بیست Portal پیشفرض دارد.
- Portal اضافی جداگانه قابل خرید نیست؛ تعداد Portal میتواند Edition را تعیین کند.
- Account/Sub-account برای ساختار شعب و مشتریان سلسلهمراتبی اغلب بهتر از Portal اضافی است.
- Customer Portal، SLA، Knowledge Base و Billing باید با Contract و Product واقعی طراحی شوند.
- برای On-Premises در 2026، Build 15150 یا نسخه امنتر بعدی را مبنا قرار دهید و CVE-2026-12507 را نادیده نگیرید.
سخن پایانی
SupportCenter Plus زمانی بیشترین ارزش را ایجاد میکند که سازمان از «یک Inbox برای پشتیبانی» عبور کرده باشد و بخواهد خدمات مشتری را به یک سیستم عملیاتی قابل اندازهگیری تبدیل کند.
در سازمان چندبرندی، Portal میتواند تجربهها را از هم جدا کند؛ Account و Contact، Context مشتری را حفظ میکنند؛ SLA و Contract تعهدات را قابل اندازهگیری میکنند؛ Knowledge Base بار Ticketهای تکراری را کم میکند؛ و Support Repهای Global اجازه میدهند تیم مشترک بدون تکثیر غیرضروری لایسنس روی چند Portal کار کند.
اگر قرار است SupportCenter Plus را برای چند برند، نمایندگی، مشتری سازمانی یا تیم خدمات پس از فروش پیادهسازی کنید، پیش از خرید یک نقشه ساده از Portal، Account، Support Rep، SLA و Integrationها تهیه کنید. برای بررسی Edition، معماری استقرار و هزینه میتوانید از مشاوره و دمو مدانت و استعلام لایسنس ManageEngine استفاده کنید.
منابع
- ManageEngine SupportCenter Plus Features
- SupportCenter Plus Pricing FAQs – Licensing 14.7+
- SupportCenter Plus Pricing
- SupportCenter Plus 15.1 ReadMe and Release Notes
- SupportCenter Plus Security Advisory
- Account and Contact Management
