Escalation چیست؟

Escalation در ITSM یعنی ارجاع کنترل‌شده یک Incident، Request یا Problem به سطحی دیگر؛ زمانی که تیم فعلی مهارت، اختیار یا زمان کافی برای حل آن ندارد. هدف تشدید این نیست که «تیکت را پاس بدهیم»، بلکه باید شانس حل سریع‌تر و جلوگیری از نقض SLA را افزایش دهد.

دو نوع اصلی Escalation

Functional Escalation یعنی ارجاع موضوع به فرد یا تیمی با تخصص فنی بالاتر؛ مثلاً انتقال یک Incident شبکه از Service Desk به تیم Network. Hierarchical Escalation یعنی ورود سطح مدیریتی بالاتر به دلیل ریسک، اثر کسب‌وکار، تأخیر یا نیاز به تصمیم و اختیار بیشتر.

Escalation چه زمانی باید انجام شود؟

• وقتی زمان پاسخ یا حل به آستانه SLA نزدیک می‌شود.
• وقتی تیم فعلی مهارت یا دسترسی لازم را ندارد.
• وقتی Incident چند سرویس یا تعداد زیادی کاربر را تحت تأثیر قرار داده است.
• وقتی تصمیمی مدیریتی، امنیتی یا مالی لازم است.
• وقتی یک مشکل تکرارشونده بدون Root Cause روشن باقی مانده است.

یک سناریوی ساده

فرض کنید کاربران واحد مالی به ERP دسترسی ندارند. Service Desk بررسی اولیه را انجام می‌دهد، اما مشکل به Database مربوط است؛ اینجا Functional Escalation به DBA انجام می‌شود. اگر اختلال ادامه پیدا کند و پایان ماه مالی در خطر باشد، مدیر فناوری هم وارد جریان می‌شود؛ این بخش Hierarchical Escalation است.

Escalation و SLA

یک فرایند Escalation خوب باید قبل از نقض SLA فعال شود، نه بعد از آن. در ابزارهایی مثل ServiceDesk Plus می‌توان Ruleهای Escalation را بر اساس Priority، زمان پاسخ، زمان حل و گروه پشتیبانی تعریف کرد. برای درک بهتر ساختار تیم نیز مقاله شرح وظایف کارشناس میز خدمت و سطوح L1/L2/L3 مفید است.

اشتباه رایج

اگر Escalation بیش از حد زود انجام شود، تیم‌های تخصصی غرق تیکت‌های ساده می‌شوند؛ اگر بیش از حد دیر انجام شود، SLA و تجربه کاربر آسیب می‌بیند. نقطه درست، تعریف معیارهای روشن برای زمان، Priority، Impact و Ownership است.

سخن پایانی

Escalation موفق یعنی رساندن مسئله به «سطح درست» در «زمان درست». هرچه مسیر ارجاع، مالکیت و آستانه‌های SLA شفاف‌تر باشند، زمان حل کمتر و تجربه کاربر بهتر خواهد بود.