چه زمانی باید از مدیریت خدمات استفاده کنیم!؟

پرسشی که همیشه در هر تصمیمی ذهنمان را درگیر خود می‌کند این است که” آیا وقتش رسیده!؟” زمانی که مجردید و تازه از دانشگاه خارج‌شده‌اید، یک تخت برای تمام زندگی‌تان کافی است. اما وقتی متأهل شوید و با یکی دو فرزند، دیگر یک تخت جوابگو نیست. اگر کسب‌وکاری را با یک میز شروع کردید سپس به یک آپارتمان کوچک می‌روید یعنی زندگی شما در حال وسیع شدن است. یعنی می‌خواهید از همه‌چیز پیشی بگیرید. زندگی همین است. تو تغییر می‌کنی؛ فکرت، پوشش‌ات، حرف‌هایت، اهدافت و داشته‌هایت؛ همه این‌ها پیوسته بنا به نیازت تغییر می‌کنند تا شکل جدید و نسخه‌ی دیگری از تو و زندگی‌ات را ارائه کنند. در مدیریت فناوری اطلاعات هم همین داستان هست. در تمام طول زندگی، چیزی که خیلی مهم است این است که چه زمانی و چگونه باید شرایط فعلی را ترک کنیم؟ چطور این وضع را تغییر دهیم. هرچند هر تغییری مدتی شرایط عادی شما را به هم می‌ریزد و آشفته‌بازاری خواهید داشت. اما تغییرات برای رسیدن به شرایط نرمال همیشه لازم‌اند. گاهی خیلی زود تصمیم می‌گیرید و گاهی شبیه دیگران سخت‌تر از خود تغییر می‌شوید. زیرا درک درست زمان تغییر و این‌که “آیا وقتش شده!” مهم‌ترین نگرانی ماست. ریسک تغییر در زندگی، چیزهای حیاتی را ممکن است در بربگیرد، بنابراین تا زمان دقیقش فرانرسد هرکسی این ریسک را به جان نخواهد خرید. اما در مدیریت خدمات، خوشبختانه همه‌چیز کمی مرتب‌تر است. این یعنی تصمیم‌گیری چندان سخت نیست و آن‌قدر حیاتی نیست که هست و نیست شما را زیرورو کند. چقدر به نشانه‌ها اعتقاد دارید!؟ نشانه‌ها هستند تا برای انجام دادن یا ندادن کاری اقدام کنیم. با این ۸ نشانه می‌توانید بفهمید آیا زمان تغییر فرارسیده یا نه؟

۱- وقتی تعمیر و نگهداری زیادی موردنیاز است.

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

 ۲- وقتی پرسش و پاسخ‌ها در حال تکرارند.

روبرو شدن با پرسش‌ها و درخواست‌های تکراری کاری است که هرروز می‌کنیم. “من رمز خود را فراموش کرده‌ام.” “Wi-Fi کار نمی‌کند.” “شبکه‌ام قطع است!”، من نمی‌توانم ایمیل ارسال کنم.” “کارتریج پرینترم به پایان رسیده” باید بدانید که هرچند وقت یک‌بار کارشناسان فناوری چنین پرسش‌های تکراری را دریافت می‌کنند؟ که بجای تمرکز بر کارهای ارزش‌افزوده و صرف وقت خود بر افزایش کیفیت خدمات و ارتقاء کسب‌وکار بر این کارهای تکراری متمرکزشده‌اند؟ اگر این را می‌دانید پس اتلاف وقت را متوقف کنید. یک پورتال سلف‌سرویس اجرا کنید و کاربران را به آن هدایت کنید. در مورد رفع مشکلات خود به آن‌ها آموزش دهید. اطلاعات حمایتی و سؤالات متداول خود را به‌صورت آنلاین (در پرتال) آورده و کاربران را به آن‌ها نشان دهید. با این کار به این نقطه خواهید رسید که دیگر مجبور نخواهید شد از این جمله‌ی مسخره که ” رایانه‌ات را یک‌بار ریستارت کن!” استفاده کنید.

۳ – وقتی آتش‌نشان هست اما آتش‌سوزی واقعی وجود ندارد!

شما یک آتش‌نشانید، حتی بااینکه کلاه ایمنی و کت ضد حریق نپوشید. اگر راه‌حل مدیریت خدمات شما فاقد ویژگی‌های خودکارسازی است، فشار زیادی را در گروه ایجاد می‌کند که ناشی از حجم کار است. پاسخ میز خدمت به کاره‌ای خسته‌کننده دستی که در آن اعضای گروه مرتب درگیر روزمرگی می‌شوند، می‌تواند منجر به فرسودگی اعضای گروه و غرق شدن در عدم نوآوری شود. بعلاوه، بقیه اعضای سازمان به‌زودی می‌توانند قربانی این خستگی و فرسودگی شوند. بنابراین اگر هنوز روال کارها به‌صورت دستی و تکراری انجام می‌شود باید به این فکر کنید که وقتش رسیده تا این روال را خودکارسازی کنید. دقت کنید که هر کاری که دو بار انجام می‌شود باید فرایند اتوماسیونی داشته باشد.

۴ – وقتی راه‌حل مدیریت خدمات فعلی با نیاز سازمان شما سازگار نیست.

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

ادامه مطلب در صفحه بعد…

نوشته چه زمانی باید از مدیریت خدمات استفاده کنیم!؟ اولین بار در سرویس دسک پلاس فارسی مدانت. پدیدار شد.

در سرویس دسک پلاس Manageengine چگونه دارایی‌هایی با شناسه یکتا داشته باشیم؟

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

1. شناسه کاوشگر (فقط برای کاوش مبتنی بر کاوشگر) یا Agent ID
2. برچسب خدمات یا Service Tag
3. نام ایستگاه کاری: Workstation Name
4. آدرس مک: MAC Address

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

روشی که در آن ایستگاه‌های کاری برای هر معیار بازنویسی می‌شوند، در زیر توضیح داده‌شده است،

شناسه کاوشگر (فقط برای کاوش مبتنی بر کاوشگر) یا Agent ID

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

برچسب خدمات یا Service Tag چیست؟

سرویس تگ یا Service Tag یک شماره برچسب یا یک شماره‌سریال منحصر است که معمولاً روشی برای شناسایی منحصربه‌فرد یک لپ‌تاپ، یا هر دستگاه دیگری است. با مراجعه به وب‌سایت شرکت‌های تولیدکننده آن تجهیز سخت‌افزاری که OEM معروف هستند می‌توانید برچسب خدمت موردنظر را جستجو کنید. یک تولیدکننده تجهیزات اصلی (OEM) اختصار این عبارت Original Equipment Manufacturer است. از تولیدکنندگان قطعات و تجهیزات بنام OEM یاد می‌شود اینان سازنده‌های اصلی و مادر هستند حتی اگر ممکن است تجهیزاتی که آن‌ها تولید می‌کنند بعدها توسط سازنده دیگری به بازار عرضه شود. مثلاً از CPU شرکت اینتل و یا AMD در نوت بوک و دسکتاپ اکثر برندهای معروف استفاده‌شده یا مادربرد ایسوس در نوت بوک Acer و… درهرصورت قطعه اصلی همیشه دارای یک برچسب یکتا برای شناسایی است حتی اگر آن‌یک قطعه خودرو باشد ممکن است برای خلق یک محصول ارزش‌افزوده این قطعه در هزاران خودرو با برندهای متفاوت و سازنده‌های دیگری مونتاژ و مورداستفاده قرار گیرد علیرغم اینکه ما محصول نهایی را به اسم شرکت سازنده آخر می‌شناسیم اما در حقیقت تمام قطعات بکار رفته در آن مربوط به OEM هاست که برای هر قطعه نیز یک شماره‌سریال یا پارت نامبر و یا سرویس تگ در نظر گرفته‌اند.

قدم اول در کاوش دارایی‌ها استفاده از برچسب خدمات است. این برچسب خدمات همان شماره‌سریال مادربرد دستگاه است که توسط شرکت سازنده‌ی اصلی OEM برای آن شناسه یکتایی در نظر گرفته‌شده و این شناسه توسط نرم‌افزارهای کاوش دارایی و سرویس دسک پلاس قابل واکشی است. مثلاً اگر دو ایستگاه کاری، ماشین A و ماشین B با برچسب سرویس مشابه ۱۲۳۴۵ را در نظر بگیرید. پس از کاوش ماشین A و بعد کاوش ماشین B اطلاعات ماشین B روی A رونویسی و جایگزین می‌گردد. برای از بین بردن این مشکل در سرویس دسک پلاس می‌توانید برچسب‌های سرویس نامعتبر و مشابه را پیکربندی نمایید. برای این کار به مدیریت سامانه/کاوش دارایی‌ها/تنظیمات کاوش بروید

 و تگ‌های مشابه و نامعتبر را بیفزایید.

به‌طورکلی، هنگام کاوش ایستگاه‌های کاری، سرویس دسک پلاس ابتدا به دنبال Service Tag می‌گردد. اگر پارامتر و مقدار آن تهی باشد، نام ایستگاه کاری را در نظر گرفته می‌گیرد و بر اساس آن ایستگاه‌های کاری را کاوش می‌کند حال‌آنکه اگر ایستگاه کاری، MachineA.Medanet.ir، از قبل در برنامه وجود داشته باشد و دستگاه دیگری با همین نام کاوش شود، جزئیات موجود در ایستگاه کاری قبلی (MachineA.Medanet.ir) با دستگاه دوم جایگزین می‌شود. برای جلوگیری از چنین پیامدی از یکتا بودن نام ایستگاه‌های کاری و نام‌گذاری استاندارد آن‌ها استفاده نمایید مثلاً WS-12570 که WS نشانگر نوع ایستگاه کاری است، ۱ نام منطقه استقرار سیستم،۲ نام شعبه، ۵ نام ساختمان، ۷ نام طبقه، ۰ نام واحد

سومین معیاری که برنامه هنگام جایگزینی ایستگاه‌های کاری به دنبال آن است، آدرس MAC است. یک ایستگاه کاری حتی اگر دارای نام و برچسب خدمات متفاوتی باشد اما آدرس MAC مشابهی داشته باشد و اگر دستگاهی با MAC در برنامه در موجود باشد هنگام انجام کاوش، ایستگاه کاری تازه کاوش شده جایگزین جزئیات ایستگاه کاری موجود می‌شود.

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

دارایی‌ها چه زمانی تکراری خواهند شد؟

سناریوهای محتمل در تکراری شدن دارایی‌های کاوش شده که با پیشوند _old نمایان می‌شوند

سناریوی ۱:  

هنگامی‌که مادربرد ایستگاه‌های کاری در شبکه مرتب جابجا می‌شوند، دو ایستگاه کاری را در نظر بگیرید، MACHINE-A با برچسب سرویس ST-1 و MACHINE-B با ST-2. در جابجایی‌ها تنظیمات ایستگاه‌های کاری است، MACHINE-A با ST-2 و MACHINE-B با ST-1. اگر شما کاوش ماشین – A، سپس دستگاه ایستگاه کاری – B خواهد شد به‌عنوان ماشین – A بازنویسی شده و دستگاه ایستگاه کاری – A خواهد شد به‌عنوان ماشین تغییر نام A_old. اگر شما کاوش ماشین B دوباره، آن را بازنویسی ماشین A_old عنوان ماشین B.

سناریوی ۲: 

ایستگاه کاری در حال حاضر با برچسب سرویس معتبر کشف‌شده است اما دوباره با یک برچسب خدمات متفاوت کاوش شده است. در این حالت سرویس‌دسک‌پلاس ایستگاه کاری موجود را با ‘_old’ تغییر نام خواهد داد و دستگاه را دوباره با برچسب سرویس جدید اضافه خواهد کرد.

مورد ۱:

در موارد خاص، ایستگاه‌های کاری ممکن است با برچسب سرویس معتبر کشف شوند. اما در طول چرخه‌ی حیات آن‌ها، ممکن است مادربرد ایستگاه کاری را تغییر داده باشید که درنتیجه این موضوع سبب تغییر برچسب خدمات می‌گردد. در این حالت ایستگاه کاری موجود با _old شده و ایستگاه کاری با تگ سرویس جدید دوباره اضافه می‌شود.

مورد ۲:

ایستگاه کاری MACHINE-A با برچسب سرویس ST-1 در حال حاضر در شبکه کاوش شده است. ایستگاه کاری دیگری به نام MACHINE-A با برچسب سرویس ST-2 به شبکه اضافه می‌شود. اگر شما MACHINE-A را دوباره کاوش کنید، ایستگاه کاری به‌عنوان MACHINE-A_old تغییر نام پیدا می‌کند و ایستگاه کاریی که به‌تازگی اضافه‌شده به‌عنوان MACHINE-A اضافه می‌شود.

مورد ۳:

در صورت ماشین‌های VMware، هنگامی‌که تغییر می‌کند، برچسب سرویس نیز تغییر می‌کند.

  ایستگاه‌های کاری بازنویسی شده با _old در طول عامل مبتنی بر کاوش:

اگر شما از طریق کاوشگر یا Agent استفاده می‌کنید. به خاطر داشته باشید که شناسه هر کاوشگر (زمانی که کاوشگر بر روی آن‌ها برای اولین بار نصب شود یک شناسه منحصربه‌فرد در تمام ایستگاه‌های کاری ایجاد می‌گردد) این شناسه به‌عنوان یک پارامتر منحصربه‌فرد برای واکشی جزئیات ایستگاه کاری در نظر گرفته‌شده است.

اگر کاوشگر از طریق یک Image ویندوزی که از طریق نرم‌افزارهای WDS-Acronis-OS Deployer-Notron Gouts مستقر شود، یعنی اگر شما یک ایمیج ویندوزی از یک سیستم تهیه‌کرده‌اید که دارای کاوشگر از قبل نصب‌شده است پس همان شناسه یکتای کاوشگر به تمام ماشین‌های دیگر کپی خواهد شد. این به‌نوبه خود، سبب می‌شود اطلاعات تکراری برای ایستگاه‌های کاری در حین کاوش و پس‌ازآن با _old. نمایان شوند بنابراین لازم است به‌طور کامل کاوشگر را از رجیستری هر سیستم حذف کنید و از طریق گروپ‌پالیسی اکتیودایرکتوری AD GPO آن را نصب و توزیع کنید.

برای حذف دارایی‌های تکراری:

دارایی‌ها را تنها می‌توان از رابط کاربری در قسمت CMDB و یا Asset حذف کرد زیرا هر دارایی در جداول مختلف دیتابیس روابط چند سویه دارد پس حذف آن به‌طور مستقیم از طریق کوئری و در پایگاه داده باعث بروز مشکلاتی بسیاری خواهد شد. اگر می‌خواهید اطلاعات کلاینت‌های دارای “_old” را به‌صورت عمده حذف کنید، لطفاً در قسمت دارایی‌ها آن‌ها را Sort کنید و از لیست نمایشی حذف کنید.

نوشته در سرویس دسک پلاس Manageengine چگونه دارایی‌هایی با شناسه یکتا داشته باشیم؟ اولین بار در سرویس دسک پلاس فارسی مدانت. پدیدار شد.

تنها نقطه‌ی تماس

حتما به یک شرکت یا سازمانی رفته‌اید و برای پیگیری یک چیزی مجبور شده‌اید کاغذ به‌دست مرتبا از این طبقه به آن طبقه از این اتاق به آن اتاق بروید! و هیچ چیز بیهوده‌تر و اعصاب‌خوردکن‌تر از سرگردانی بر سر یک امضا یا یک تایید و یا شنیدن یک جمله نیست!

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

اکثر سازمان‌ها و کسب و کارهای خصوصی و دولتی روند رسیدگی به درخواست‌های مشتریان(کاربران نهایی) را از چندین درگاه و توسط چندین فرد یا دپارتمان پیگیری می‌کنند این یعنی آنها از طریق: تلفن، مراجعه‌ی حضوری، ایمیل، سامانه‌های نرم‌افزاری، شبکه‌های اجتماعی، گفتگو(چت آنلاین)، پیام‌رسان‌ها، نامه‌نگاری کاغذی، پورتال سازمانی، اپلیکیشن‌های موبایل و… به درخواست‌کنندگان خود خدماتی را ارایه می‌کنند. اما این چیز بدی نیست! اگرچه بهتر بود که همه از یک درگاه استفاده کنند زیرا تنوع ابزارها طیف متنوعی از مخاطبین را هم پوشش می‌دهد(که البته باید تمامی این داده‌های ورودی در نهایت برای داده‌کاوی‌های آینده در یکجا متمرکز شوند) آنچه که بد است تنوع نفرات و دپارتمان‌ها برای هر نقطه‌ی تماس است! این یعنی در هر کدام از این روش‌ها چندین درگاه و نقطه‌ی تماس وجود دارد این همان چالشی است که سبب نارضایتی بسیار می‌شود. مثلا اگر شما که در حال گفتگوی تلفنی و یا پیگیری تلفنی باشید و اگر از این طریق قرار است نیازمندی خود را مطرح کنید چندین نفر هر بار پاسخگوی شما هستند که متاسفانه چون پیشینه مکالمات را ثبت نمی‌کنند و یا تا انتها پیگیری نمی‌کنند و یا بخاطر نمی‌آورند؛ شما می‌شوید درخواست‌کننده و مامور پیگیری! و کارکنان آن سازمان هم می‌شوند فقط ربات‌های ارجاع بی‌هدف! بنابراین مجبور خواهید بود هرباری که پیگیری می‌کنید و یا دنبال دریافت توضیح بیشتر هستید، مرتبا جملات قبلی را برای نفر جدیدی که تلفن را برداشته بازگو کنید.

و یا مثلا حضورا چیزی را پیگیری می‌کنید، یک نفر در اتاق نخست هست که شما باید کل نیازتان را برایش توضیح می‌دهد اما او اظهار بی‌اطلاعی می‌کند و شما را پاس می‌دهد به اتاق بعدی و یک نفر دیگر! و شما مجدد کل شرح‌ماوقع را به نفر دوم هم ارایه می‌کنید که می‌گوید این مربوط به من نیست و باید از فلان… پیگیری کنید و از شما می‌خواهد منتظر بمانید تا شیفت‌تان بدهد به نفر بعدی…! و این دور باطل!

این سناریو را در تمامی روش‌های ارایه خدمت نظیر: ایمیل، سامانه‌های نرم‌افزاری، شبکه‌های اجتماعی، گفتگو(چت آنلاین)، پیام‌رسان‌ها، نامه‌نگاری کاغذی، پورتال سازمانی، اپلیکیشن‌های موبایل و… تعمیم دهید، نتیجه، همان است!

مشکل کجاست؟

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

شما به‌عنوان یک ذی‌نفع میزخدمت (درخواست‌کننده) نباید برای پیگیری نیاز یا مشکلات خود با تمامی نفرات یک واحد/سازمان صحبت کنید! اولین شخصی که تلفن را برمی‌دارد باید آخرین شخصی هم باشد که شما با او در ارتباط خواهید بود. حتی اگر موضوع نیاز شما در سطح دانش و اطلاعات او نباشد، حتی اگر او مجوز برخی کارها را نداشته باشد، حتی اگر آن موضوع در شرح وظایف او نباشد و حتی اگر ارتباطی به او نداشته باشد در هر صورت در میزخدمت، پیگیری باید فقط از”تنها نقطه‌ی تماس” صورت بگیرد. این یعنی نفر اول، بلافاصله درخواست شما را دریافت، آنالیز و بررسی می‌کند چه اینکه درخواست را بخواهد ارجاع دهد چه نه در هر صورت او کاربر را ارجاع نخواهد داد!

اولین نفر پاسخگو، آخرین نفر هم خواهد بود زیرا او خوب می‌داند که کار را باید ارجاع دهد نه کاربر را!

ادامه مطلب در صفحه بعد…

نوشته تنها نقطه‌ی تماس اولین بار در سرویس دسک پلاس فارسی مدانت. پدیدار شد.