سیاست ارجاع و تشدید (escalation) در پشتیبانی: الگوی آماده

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

سیاست ارجاع و تشدید (escalation) در پشتیبانی همین قاعده است. این مطلب بخش‌های آن را مرور می‌کند و در پایان الگویی می‌دهد که می‌توانید کپی و با تیم خودتان تنظیم کنید.

سیاست ارجاع و تشدید در پشتیبانی چیست؟

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

«تشدید» دو معنا دارد. تشدید کارکردی یعنی پرونده به کسی می‌رسد که مهارت یا دسترسی دیگری دارد (مالی، فنی). تشدید سلسله‌مراتبی یعنی کسی با اختیار بیشتر وارد می‌شود (سرپرست تیم، مدیر). سیاستتان باید هر دو را اسم ببرد.

سطح‌ها: کم نگه دارید

برای بیشتر تیم‌ها سه سطح کافی است. بیشتر از آن، پرونده‌ها بین آدم‌ها دست‌به‌دست می‌شوند.

تیم کوچکی دارید؟ سطح ۲ می‌تواند هر هفته یک نفر مشخص باشد و لازم نیست واحد جدا باشد.

محرک‌ها: چه زمانی پرونده بالا می‌رود

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

• مهارت یا دسترسی: اپراتور با چیزی که دارد نمی‌تواند حلش کند، مثلاً بررسی تراکنش یا تغییر در کد.
• زمان: پرونده به مهلتش نزدیک است یا از آن گذشته.
• اثر: چند مشتری یک مشکل را گزارش کرده‌اند، یا یک مشتری نمی‌تواند پرداخت کند یا وارد شود.
• نشانهٔ مشتری: مشتری مدیر می‌خواهد، از شکایت به نهاد رسمی حرف می‌زند، یا سه بار نوشته و پیشرفتی ندیده.

در هدهد محرک زمانی را می‌شود خودکار کرد. ارتقای خودکار تیکت‌ها به «از مهلت گذشته»، «مدتی بی‌حرکت» یا «منتظر پاسخ مشتری» واکنش نشان می‌دهد و می‌تواند اولویت را بالا ببرد، تیکت را به تیم دیگری بدهد، دنبال‌کننده اضافه کند، برچسب بزند یا یادداشت بگذارد. پیش از روشن‌کردن هر قانون هم می‌بینید چه تیکت‌هایی را می‌گرفت.

چه کسی مالک چیست؟

رایج‌ترین خرابی، پرونده‌ای است که «ارجاع شده» ولی صاحب ندارد. دو قاعده را تعیین کنید:

1. هر لحظه یک مالک. وقتی پرونده به سطح ۲ می‌رود، نفر سطح ۲ تا زمان حل یا ارجاع بعدی مالک رابطه با مشتری است.
2. اپراتور اول مطلع می‌ماند، مسئول نیست. تیکت را دنبال می‌کند و نتیجه را می‌بیند ولی دیگر پیگیری نمی‌کند.

اینکه چه کسی با مشتری حرف بزند را هم مشخص کنید. انتخاب رایج این است که سطح ۱ یک پیام کوتاه بفرستد که پرونده پیش کارشناس رفته و چه زمانی خبر می‌رسد، و بعد از آن مالک جدید بنویسد. در هدهد تیکت را به تیم یا نفر مورد نظر ارجاع می‌دهید، اپراتور اول را دنبال‌کننده می‌گذارید و بحث داخلی را در یادداشت خصوصی نگه می‌دارید تا مشتری نبیند.

یادداشت تحویل

بیشتر وقت تلف‌شده در لحظهٔ تحویل است. اگر نفر بعدی باید دوباره از مشتری بپرسد، تشدید کار را کندتر کرده. این یادداشت را برای هر تحویل اجباری کنید:

یادداشت تحویل
مشتری / شمارهٔ تیکت:
مشکل در یک جمله:
انتظار مشتری:
چه چیزی را بررسی یا امتحان کرده‌ام:
از شما چه می‌خواهم:
اولویت و دلیلش:
مهلت (برای مشتری و داخلی):
به مشتری چه گفته شده:

مهم‌ترین سطر «به مشتری چه گفته شده» است. جلوی این را می‌گیرد که نفر بعدی قولی را نقض کند که خبر نداشته.

سقف زمان

برای هر سطح سقف «اقدام روی پرونده» بگذارید، نه سقف حل. نمونه‌ای برای یک پرونده فوری، بر حسب ساعت کاری:

جمعشان کنید: پرونده فوری حداکثر ظرف ۳ ساعت و نیم به سطح ۳ می‌رسد و مشتری دست‌کم در دقیقهٔ ۱۵ و ۹۰ از یک آدم خبر می‌گیرد. این عددها فقط نقطهٔ شروع‌اند. مثل SLA، از آنچه تیمتان امروز می‌تواند شروع کنید و بعد سخت‌ترش کنید. برای اولویت‌های پایین‌تر سقف‌ها را بزرگ‌تر بگیرید. خود اولویت‌گذاری در اولویت‌بندی و تریاژ تیکت‌ها آمده است.

ارجاع به مهندسی

وقتی علت یک نقص است، ده تیکت جدا را برای برنامه‌نویس‌ها نفرستید. تیکت‌ها را به یک مسئله وصل کنید تا مهندسی یک مشکل ببیند، با تعداد مشتری‌های درگیر. در هدهد این کار با پیگیری مسئله‌ها انجام می‌شود و مسئله را می‌شود به Jira فرستاد. بعد از رفع، می‌توانید یک‌جا به گفت‌وگوهای وصل‌شده پیام بدهید.

الگوی قابل‌کپی

سیاست ارجاع و تشدید (نام تیم، نسخه، تاریخ)

سطح‌ها
  ۱: [نام‌ها/تیم]  - رسیدگی به: [فهرست]
  ۲: [نام‌ها/تیم]  - رسیدگی به: [فهرست]
  ۳: [نام‌ها/تیم]  - رسیدگی به: [فهرست]

تشدید کنید وقتی (یکی کافی است)
  - دسترسی یا مهارتی لازم است که سطح فعلی ندارد
  - تیکت تا مهلتش [X] مانده یا از آن گذشته
  - [N] مشتری یا بیشتر همان مشکل را گزارش کرده‌اند
  - مشتری نمی‌تواند پرداخت کند یا وارد شود
  - مشتری مدیر می‌خواهد یا از شکایت رسمی می‌گوید

مالکیت
  - هر لحظه یک مالک؛ مالک با مشتری حرف می‌زند
  - مالک قبلی دنبال‌کننده می‌ماند و پیگیری نمی‌کند
  - بحث داخلی فقط در یادداشت خصوصی

یادداشت تحویل (اجباری)
  مشکل / انتظار / بررسی‌شده‌ها / درخواست / اولویت /
  مهلت / آنچه به مشتری گفته شده

سقف زمان (ساعت کاری)
  پاسخ سطح ۱: [  ]   تحویل سطح ۱: [  ]
  تحویل‌گرفتن سطح ۲: [  ]   تحویل یا حل سطح ۲: [  ]
  اعلام وضعیت سطح ۳: [  ]

خارج از ساعت کاری
  چه کسی برای موارد فوری آماده است و چطور در دسترس است: [  ]

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

مرور سیاست

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

بازبینی کیفیت هدهد هم می‌تواند کمک کند: بازبین می‌تواند هنگام نمره‌دادن به نمونه‌ای از گفت‌وگوها، «تشدید در زمان درست» را یکی از معیارها بگذارد.

برای اجرای قانون‌های تشدید و تحویل در تیم خودتان دموی رایگان بگیرید. تیکت با اولویت، مهلت و ارتقای خودکار را در سیستم تیکتینگ ببینید.

سؤالات متداول