0

راهنمای عملی طراحی ServiceDesk Plus MSP برای چند مشتری؛ از Account و SLA تا Contract، Service Plan، Billing، Worklog، لایسنس و تفکیک دسترسی تکنسین‌ها.

شرکت مدانت
شرکت مدانت
[ مجری تخصصی پیاده‌سازی چارچوب ITIL و تحول دیجیتال ]
ServiceDesk Plus MSP برای چند مشتری؛ طراحی Account، SLA، Contract و Billing

فرض کنید شرکت شما هم‌زمان به ۲۰ مشتری سازمانی خدمات فناوری اطلاعات می‌دهد. یکی فقط پشتیبانی کاربران را می‌خواهد، دیگری مدیریت شبکه و سرور را هم واگذار کرده، مشتری سوم قرارداد ۲۴×۷ دارد و مشتری چهارم فقط در ساعات اداری SLA فعال دارد. بعضی مشتری‌ها صورتحساب ثابت ماهانه می‌خواهند، بعضی براساس ساعت کار تکنسین و بعضی براساس تعداد درخواست یا خدمت مصرف‌شده.

اگر همه این مشتری‌ها را داخل یک Help Desk معمولی و بدون تفکیک Account، قرارداد، SLA و فرآیند مالی مدیریت کنید، خیلی زود سه مشکل ایجاد می‌شود: اطلاعات مشتری‌ها با هم مخلوط می‌شود، تیم پشتیبانی نمی‌داند کدام SLA برای کدام مشتری معتبر است و بخش مالی مجبور می‌شود Worklog و صورت‌حساب را از چند سیستم جداگانه جمع کند.

ManageEngine ServiceDesk Plus MSP برای همین سناریو ساخته شده است؛ یعنی یک Service Desk چندمشتری برای Managed Service Providerها که Account Management، ITSM، PSA، قرارداد، Billing، Asset Management و گزارش‌گیری را در یک پلتفرم متمرکز می‌کند. صفحه ServiceDesk Plus MSP مدانت مسیر اصلی بررسی محصول، لایسنس و استقرار این راهکار است.

ServiceDesk Plus MSP دقیقاً چه مسئله‌ای را حل می‌کند؟

در یک تیم داخلی IT معمولاً یک سازمان، یک مجموعه کاربران و یک سیاست کلی Service Management وجود دارد. اما MSP با چند سازمان مستقل کار می‌کند و باید در عین تمرکز عملیاتی، مرز هر مشتری را حفظ کند.

در ServiceDesk Plus MSP هر مشتری در قالب یک Account مدیریت می‌شود. هر Account می‌تواند Contact، Asset، SLA، Business Rule، Service Plan، قرارداد، صورتحساب و تنظیمات عملیاتی خودش را داشته باشد. این مدل باعث می‌شود تیم NOC یا Service Desk یک کنسول مرکزی داشته باشد، ولی داده و قواعد خدمت‌رسانی برای هر مشتری جدا بماند.

ManageEngine در مستندات رسمی محصول، Account Management را یکی از قابلیت‌های اصلی MSP می‌داند و امکان تعریف SLA و Service Plan اختصاصی برای هر Account را مطرح می‌کند.

معماری پیشنهادی: Account را با «مشتری» اشتباه نگیرید

در طراحی اولیه معمولاً وسوسه می‌شویم هر واحد یا شعبه مشتری را یک Account مستقل بسازیم. این کار همیشه درست نیست. Account باید نماینده مرز تجاری و عملیاتی واقعی باشد؛ یعنی جایی که قرارداد، SLA، Billing یا مالکیت داده تفاوت دارد.

سناریو طراحی پیشنهادی دلیل
یک شرکت با ۱۰ شعبه و یک قرارداد واحد یک Account + تفکیک Site/Location قرارداد و SLA مشترک است
هلدینگ با شرکت‌های مستقل و قراردادهای جدا Account مجزا برای هر شرکت Billing و SLA متفاوت است
مشتری با دو برند ولی تیم پشتیبانی مشترک بسته به قرارداد؛ معمولاً یک Account با Portal/Branding مناسب از تکثیر غیرضروری Account جلوگیری می‌شود
مشتری با سرویس IT و OT با SLA کاملاً متفاوت یک Account با Service/SLA تفکیک‌شده یا دو Account در صورت مرز قراردادی مستقل تصمیم باید براساس قرارداد و Data Boundary باشد

قاعده ساده این است: اگر دو بخش یک سازمان صورت‌حساب، قرارداد، SLA و مسئولیت حقوقی مشترک دارند، ساختن Account اضافی معمولاً فقط مدیریت را پیچیده‌تر می‌کند.

چه داده‌ای باید قبل از ساخت Account آماده باشد؟

قبل از Import مشتری‌ها، حداقل این اطلاعات را برای هر سازمان جمع کنید:

  • نام حقوقی و نام تجاری مشتری
  • Account Manager و Technical Owner
  • دامنه ایمیل و روش شناسایی Requester
  • Siteها و Locationها
  • ساعات کاری و تعطیلات
  • سطوح SLA
  • Service Catalog مورد قرارداد
  • Asset Scope
  • روش Billing
  • تاریخ شروع و پایان قرارداد
  • Escalation Matrix
  • محدودیت دسترسی تکنسین‌ها

اگر این اطلاعات قبل از ورود به سیستم استاندارد نشوند، بعداً مجبور می‌شوید SLA، Contract و Reporting را روی داده‌های ناسازگار بازطراحی کنید.

SLA را برای هر Account چطور طراحی کنیم؟

یکی از تفاوت‌های مهم MSP با Service Desk داخلی این است که SLA معمولاً قراردادی است و نقض آن می‌تواند پیامد مالی یا اعتباری داشته باشد.

برای مثال دو مشتری یک Incident با Priority=High ثبت می‌کنند، اما قرارداد مشتری A پاسخ اولیه ۳۰ دقیقه‌ای و مشتری B پاسخ اولیه دو ساعته دارد. اگر فقط یک SLA عمومی روی همه درخواست‌ها اعمال شود، یا تیم بی‌دلیل Over-service می‌دهد یا تعهد قراردادی مشتری مهم‌تر را نقض می‌کند.

در ServiceDesk Plus MSP می‌توان SLAهای Account-specific تعریف کرد و آن‌ها را براساس Priority، Category، Service یا شرایط دیگر به درخواست‌ها اعمال کرد.

چهار لایه SLA که بهتر است جدا شوند

  • Response SLA: حداکثر زمان پاسخ اولیه.
  • Resolution SLA: حداکثر زمان حل یا بازگرداندن سرویس.
  • Operational Hours: ساعات و تقویم کاری معتبر برای محاسبه SLA.
  • Escalation: چه زمانی و به چه فرد یا گروهی هشدار داده شود.

برای محتوای عمیق‌تر درباره مفاهیم SLA و مدیریت خدمات، مجموعه مطالب فارسی ServiceDeskPlus.ir می‌تواند به تیم فرآیند و Service Management کمک کند.

یک اشتباه رایج: SLA را با Priority یکی نکنید

Priority نشان می‌دهد یک Ticket چقدر مهم یا فوری است؛ SLA نشان می‌دهد براساس قرارداد چه تعهدی داریم. ممکن است دو مشتری هر دو Incident با Priority=Critical داشته باشند، اما Contract متفاوتی داشته باشند.

طراحی بهتر این است که Priority از Impact و Urgency یا Ruleهای عملیاتی ساخته شود و سپس SLA مناسب براساس Account، Service و Contract اعمال شود.

Service Plan؛ حلقه اتصال عملیات و درآمد

برای MSP فقط حل Ticket مهم نیست؛ باید بدانیم چه خدمتی فروخته شده، چه مقدار از آن مصرف شده و هزینه اضافه چطور محاسبه می‌شود.

ServiceDesk Plus MSP از Service Plan برای تعریف مدل مصرف و Charge استفاده می‌کند. طبق راهنمای رسمی ManageEngine، Service Plan می‌تواند Plan Type، Billing Cycle، Allowance و Usage Charge را مشخص کند و سپس به Contract مشتری متصل شود.

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

  • هزینه ثابت ماهانه
  • هزینه براساس ساعت کار
  • هزینه براساس تعداد Request
  • Allowance مشخص + هزینه مصرف اضافه
  • Prepaid Credit
  • ترکیب Fixed Base Charge و Usage

مثال: قرارداد ۴۰ ساعت پشتیبانی در ماه

فرض کنید مشتری ماهانه ۴۰ ساعت پشتیبانی خریداری کرده است. در طول ماه ۳۳ ساعت Worklog ثبت می‌شود؛ مشکلی وجود ندارد. اما اگر مصرف به ۴۷ ساعت برسد، سیستم باید مشخص کند ۷ ساعت اضافه چگونه محاسبه شود.

اگر این مدل از ابتدا در Service Plan و Contract تعریف شده باشد، گزارش‌گیری و Billing قابل ردیابی است. اگر نباشد، تیم مالی در پایان ماه باید از Excel، ایمیل و Worklogهای پراکنده استفاده کند.

Contract باید فقط یک PDF اسکن‌شده نباشد

در یک MSP بالغ، Contract باید به یک Object عملیاتی تبدیل شود. یعنی تاریخ اعتبار، Assetهای تحت پوشش، Notification Rules، Service Plan و Billing به آن متصل باشند.

مستندات رسمی ServiceDesk Plus MSP نشان می‌دهد Contract می‌تواند براساس Account فیلتر شود و شامل Contract Details، Contract Rules و Notification Rules باشد. این ساختار کمک می‌کند تیم عملیات بداند کدام Asset یا Service واقعاً تحت قرارداد است.

فیلدهای مهم Contract

  • Contract ID
  • Account
  • Start/Expiry Date
  • Service Plan
  • Asset Scope
  • Renewal Notification
  • Billing Cycle
  • Currency و Tax
  • Account Manager
  • Exceptionها و Exclusionها

Billing Automation؛ جایی که PSA از Help Desk جدا می‌شود

یک Help Desk معمولی ممکن است Ticket و SLA را خوب مدیریت کند، اما MSP برای سودآوری باید زمان، مصرف خدمت و قرارداد را به Billing متصل کند.

ManageEngine در ServiceDesk Plus MSP امکان Contract Billing و تولید دوره‌ای Bill را براساس Service Contract ارائه می‌کند. در سناریوی رسمی Billing Automation، می‌توان Currency، Tax، Billing Cycle و Notification را در Contract تعریف کرد تا Billها براساس دوره قرارداد تولید شوند.

این قابلیت وقتی ارزش بیشتری پیدا می‌کند که Technicianها Worklog را دقیق ثبت کنند. اگر Worklog کیفیت نداشته باشد، حتی بهترین Billing Engine هم خروجی قابل اعتماد تولید نمی‌کند.

Worklog باید جزئی از طراحی سرویس باشد

در MSP، Worklog فقط یک یادداشت داخلی نیست. Worklog می‌تواند ورودی محاسبه هزینه، Utilization تکنسین، Profitability مشتری و Capacity Planning باشد.

برای همین بهتر است Standard مشخصی داشته باشید:

  • شروع و پایان زمان کار
  • Billable یا Non-billable بودن
  • نوع فعالیت
  • Remote یا On-site
  • تکنسین اجراکننده
  • Service/Contract مرتبط
  • توضیح کوتاه قابل دفاع برای مشتری

تفکیک دسترسی تکنسین‌ها بین مشتری‌ها

در معماری چندمشتری، همه Technicianها نباید همه Accountها را ببینند. تیم پشتیبانی یک مشتری ممکن است نباید به Ticket، Asset یا Contract مشتری دیگر دسترسی داشته باشد.

قبل از Go-live باید Role و Scope دسترسی Technicianها مشخص شود. حداقل این سؤال‌ها پاسخ داده شوند:

  • کدام Technician به کدام Account دسترسی دارد؟
  • آیا NOC مرکزی همه Accountها را می‌بیند؟
  • آیا تیم Field Service فقط Ticketهای تخصیص‌یافته را می‌بیند؟
  • چه کسی Contract و Billing را ویرایش می‌کند؟
  • چه کسی Reportهای مالی را می‌بیند؟
  • Account Manager چه دسترسی‌ای دارد؟

این موضوع هم امنیت داده را تقویت می‌کند و هم جلوی خطاهای عملیاتی را می‌گیرد.

Portal و تجربه هر مشتری را جدا طراحی کنید

یکی از مزیت‌های MSP این است که مشتری احساس نکند وارد یک Help Desk عمومی و بی‌نام شده است. Portal، Catalog و Formها باید متناسب با خدمات واقعی همان مشتری باشند.

بهتر است Request Templateهایی که مشتری A اصلاً نخریده برای او نمایش داده نشوند. همین موضوع هم تجربه کاربری را ساده‌تر می‌کند و هم از ایجاد درخواست‌های خارج از Scope قرارداد جلوگیری می‌کند.

Service Catalog را از قرارداد استخراج کنید

اشتباه رایج این است که Service Catalog را تیم IT مستقل از قرارداد می‌سازد. در MSP بهتر است Catalog از Service Offering واقعی استخراج شود.

مثلاً اگر قرارداد مشتری شامل این خدمات است:

  • Endpoint Support
  • Microsoft 365 Administration
  • Network Monitoring
  • Backup Monitoring
  • On-site Support

Catalog، SLA، Assignment Rule و Billing باید همین ساختار را منعکس کنند. این کار Traceability میان «چیزی که فروخته‌ایم» و «چیزی که تحویل می‌دهیم» ایجاد می‌کند.

چطور Request Routing را برای چند مشتری طراحی کنیم؟

در MSP تعداد Ruleها خیلی سریع رشد می‌کند. اگر برای هر Account ده‌ها Rule جدا بسازید، نگهداری سیستم دشوار می‌شود.

مدل بهتر معمولاً ترکیبی است:

شرط کاربرد
Account تفکیک مشتری و تیم مسئول
Service/Category تعیین تخصص لازم
Priority تعیین سطح Escalation
Site/Location تخصیص تیم محلی
Contract/Plan تشخیص سطح خدمت خریداری‌شده
After-hours ارسال به On-call Team

ServiceDesk Plus MSP با SupportCenter Plus چه فرقی دارد؟

هر دو محصول می‌توانند در سناریوهای پشتیبانی مشتری دیده شوند، اما هدف اصلی آن‌ها یکسان نیست. ServiceDesk Plus MSP برای Managed Service Providerهایی طراحی شده که ITSM، PSA، Asset، Contract و Billing چند مشتری را مدیریت می‌کنند. SupportCenter Plus بیشتر روی Customer Support و پشتیبانی بیرونی چندبرندی تمرکز دارد.

اگر هنوز بین این دو مسیر مردد هستید، مقاله SupportCenter Plus برای پشتیبانی چندبرندی را کنار صفحه ServiceDesk Plus MSP مقایسه کنید و براساس مدل کسب‌وکار تصمیم بگیرید.

ServiceDesk Plus MSP با ServiceDesk Plus عادی چه تفاوتی دارد؟

نسخه عادی ServiceDesk Plus برای مدیریت سرویس داخل یک سازمان یا ESM چند واحد داخلی بسیار مناسب است. اما ServiceDesk Plus MSP از ابتدا با مفهوم Account مشتری، Service Provider، Contract و Billing چندمشتری طراحی شده است.

برای مقایسه مستقیم این دو محصول، مقاله مقایسه ServiceDesk Plus با ServiceDesk Plus MSP مسیر خوبی برای تصمیم‌گیری اولیه است.

مدل لایسنس را قبل از معماری نهایی بررسی کنید

طبق صفحه Pricing فعلی ManageEngine، هزینه ServiceDesk Plus MSP براساس تعداد Administrator/Technician و در صورت استفاده از IT Asset Management براساس تعداد IT Asset مدیریت‌شده محاسبه می‌شود. End User محدودیت مستقیم مشابه Technician ندارد.

در همان FAQ رسمی، ManageEngine اعلام می‌کند یک License می‌تواند تا ۱۵۰ Account را پشتیبانی کند و برای بیشتر از آن باید با Sales هماهنگ شود. در عین حال، صفحه معرفی محصول ظرفیت Scale بالاتری برای Accountها اعلام می‌کند. این تفاوت نشان می‌دهد Cloud/On-Premises، Build، Edition یا مدل تجاری می‌تواند روی ظرفیت و Licensing اثر داشته باشد؛ بنابراین عدد Account را نباید بدون بررسی Quote و Build نهایی وارد RFP کرد.

Checklist لایسنس قبل از خرید

  • تعداد Technician و Administrator واقعی
  • تعداد Accountهای مشتری
  • تعداد IT Assetهای Managed
  • Edition موردنیاز
  • Cloud یا On-Premises
  • نیاز به ESM Instance
  • Remote Control/Remote Support
  • Billing و Contract Scope
  • Growth سه‌ساله مشتری‌ها

برای برآورد اولیه و استعلام نسخه مناسب می‌توانید از صفحه لایسنس محصولات ManageEngine مدانت استفاده کنید.

چرا Account Count تنها معیار Scale نیست؟

دو MSP ممکن است هر دو ۵۰ مشتری داشته باشند، اما Complexity کاملاً متفاوتی داشته باشند. یکی برای هر مشتری فقط Help Desk ساده دارد و دیگری هزاران Asset، چندین SLA، Contract Billing، Field Service و CMDB را هم مدیریت می‌کند.

برای Capacity Planning این شاخص‌ها مهم‌ترند:

  • Requests per day
  • Concurrent Technicians
  • Asset Count
  • Mail Fetch Volume
  • Automation Rules
  • Reports و Scheduled Reports
  • API/Integration Load
  • Attachment Volume
  • Database Growth

یک سناریوی طراحی برای MSP با ۳۰ مشتری

فرض کنید MSP شما ۳۰ مشتری دارد، ۲۵ Technician و ۵۰۰۰ Endpoint را مدیریت می‌کند.

مدل پیشنهادی می‌تواند این باشد:

  1. ۳۰ Account براساس مرز قرارداد ایجاد شود.
  2. هر Account Site و Contactهای خودش را داشته باشد.
  3. سه SLA Package استاندارد Bronze، Silver و Gold تعریف شود.
  4. Accountها براساس Contract به SLA Package مناسب نگاشت شوند.
  5. Service Planهای ثابت، ساعتی و Hybrid ساخته شوند.
  6. Worklog اجباری برای فعالیت‌های Billable باشد.
  7. Business Ruleها ابتدا عمومی و فقط در موارد ضروری Account-specific باشند.
  8. تکنسین‌ها براساس Account و Team Scope دسترسی بگیرند.
  9. برای هر مشتری Dashboard و Report دوره‌ای تعریف شود.
  10. Contract Expiry و SLA Breach به Account Manager Escalate شود.

KPIهایی که یک MSP باید از سیستم بگیرد

KPI چرا مهم است؟
SLA Compliance per Account کیفیت خدمت هر مشتری را نشان می‌دهد
First Response Time سرعت واکنش تیم را اندازه می‌گیرد
Resolution Time کارایی عملیات را نشان می‌دهد
Billable Hours مبنای درآمد و Profitability است
Technician Utilization برای Capacity و Staffing مهم است
Requests per Account مصرف واقعی خدمت را نشان می‌دهد
Contract Margin کمک می‌کند مشتری زیان‌ده شناسایی شود
Reopen Rate کیفیت Resolution را نشان می‌دهد
CSAT دید مشتری را به عملیات متصل می‌کند

قبل از Go-live چه چیزهایی را Pilot کنیم؟

به‌جای Import همه مشتری‌ها، دو یا سه Account با مدل متفاوت انتخاب کنید: یک مشتری ساده، یک مشتری با SLA سخت و یک مشتری با Billing پیچیده.

در Pilot این موارد را تست کنید:

  • Email-to-ticket برای هر Account
  • Requester Mapping
  • SLA Calculation
  • After-hours Calendar
  • Escalation
  • Service Catalog
  • Worklog
  • Contract Expiry
  • Bill Generation
  • Technician Data Isolation
  • Customer Report
  • Backup و Upgrade Procedure در On-Premises

چه زمانی سفارشی‌سازی لازم می‌شود؟

بعضی MSPها فرآیندهای خاصی دارند که با Configuration استاندارد کامل پوشش داده نمی‌شود؛ مثلاً اتصال Ticket به سیستم حسابداری داخلی، واکشی قرارداد از ERP، ایجاد مشتری از CRM، ثبت خودکار هزینه On-site، Integration با NMS یا تولید گزارش مالی خاص.

در این شرایط بهتر است قبل از توسعه، اول API و Integrationهای استاندارد بررسی شوند و فقط Gap واقعی سفارشی‌سازی شود. توسعه بی‌ضابطه می‌تواند Upgradeهای بعدی را سخت کند.

مدانت خدمات طراحی، استقرار، Integration، مهاجرت، آموزش و سفارشی‌سازی محصولات ManageEngine را ارائه می‌کند. برای Scopeهای عملیاتی پیچیده می‌توانید از برنامه پشتیبانی مدانت و صفحه درخواست دمو/مشاوره استفاده کنید.

نکات کلیدی

  • Account باید مرز واقعی مشتری و قرارداد باشد، نه صرفاً یک شعبه.
  • SLA باید Account-specific و Contract-aware طراحی شود.
  • Service Plan حلقه اتصال عملیات، مصرف و Billing است.
  • Contract باید Object عملیاتی باشد، نه فقط فایل PDF.
  • Worklog برای MSP داده مالی است؛ کیفیت آن حیاتی است.
  • دسترسی Technicianها باید براساس Account محدود شود.
  • Service Catalog باید خدمات فروخته‌شده را منعکس کند.
  • لایسنس فقط با تعداد Ticket سنجیده نمی‌شود؛ Technician، Asset، Account و Growth مهم‌اند.
  • قبل از Rollout کامل، چند Account متفاوت را Pilot کنید.

سخن پایانی

موفقیت ServiceDesk Plus MSP به این نیست که چند مشتری را داخل یک پنل وارد کنید؛ ارزش واقعی زمانی ایجاد می‌شود که Account، SLA، Contract، Service Plan، Worklog و Billing یک زنجیره واحد بسازند.

اگر این زنجیره درست طراحی شود، تیم عملیات دقیقاً می‌داند برای چه مشتری، چه خدمتی، با چه SLA و تحت چه قراردادی کار می‌کند؛ مدیر MSP نیز می‌تواند کیفیت و سودآوری هر Account را جداگانه ببیند.

برای بررسی Edition، ظرفیت Account/Technician، معماری Cloud یا On-Premises و طراحی فرآیند چندمشتری، صفحه ServiceDesk Plus MSP مدانت نقطه شروع مناسب است. برای استعلام لایسنس نیز فروش و تمدید لایسنس ManageEngine و برای استقرار و نگهداری خدمات پشتیبانی مدانت در دسترس است.

منابع

مطالب مرتبط جهت افزایش سطح دانش شما:

32

دیدگاه شما

دیدگاه مرتبط و محترمانه بنویسید.