SLA ট্র্যাকার: সময়সীমা, বিরতি এবং টিম রিপোর্ট তৈরি করুন

কাস্টমার অপারেশনস টিমগুলো কেন SLA সময়সীমার হিসাব হারিয়ে ফেলে

কাস্টমার অপারেশনস টিমগুলো সাধারণত কেউ তারিখ উপেক্ষা করার কারণে SLA মিস করে না। সময়সীমা বদলে যায়, টিকিট এক টিম থেকে অন্য টিমে যায়, আর গ্রাহকের উত্তর কাজ কয়েক দিন থামিয়ে রাখতে পারে। প্রতিটি পরিবর্তনের পর কেউ আপডেট না করলে শুধু একটি নির্ধারিত তারিখের কলাম থাকা স্প্রেডশিট দ্রুত অকার্যকর হয়ে পড়ে।

প্রথম সমস্যা হলো প্রতিটি SLA লক্ষ্যকে একটি মাত্র সময়সীমা হিসেবে দেখা। প্রথম উত্তরের লক্ষ্য মাপে একজন এজেন্ট নতুন অনুরোধ পাওয়ার পর কত দ্রুত সেটি গ্রহণের কথা জানায়। সমাধানের লক্ষ্য মাপে টিমের সমস্যাটি সমাধান করতে কত সময় আছে। একটি টিকিট ১৫ মিনিটে উত্তর দেওয়ার লক্ষ্য পূরণ করেও তিন দিন পর সমাধানের লক্ষ্য মিস করতে পারে। একটি মাত্র নির্ধারিত তারিখ কোন প্রতিশ্রুতি ব্যর্থ হয়েছে তা দেখাতে পারে না।

দায়িত্বও আরেকটি সমস্যা তৈরি করে। একজন এজেন্ট উত্তর দিতে পারেন, একজন বিশেষজ্ঞ তদন্ত করতে পারেন, আর একজন ম্যানেজার সমাধান অনুমোদন করতে পারেন। সক্রিয় SLA টাইমারের দায়িত্ব কারও না থাকলে প্রত্যেকে ধরে নিতে পারেন অন্য কেউ এটি দেখছেন। সময় শেষ হওয়া পর্যন্ত টিকিট কিউতেই পড়ে থাকে।

ধরা যাক, সকাল ১০টায় একটি অ্যাকাউন্টে প্রবেশের সমস্যা জানানো হলো। এজেন্ট ১০:১২-এ উত্তর দিলেন, ফলে ৩০ মিনিটের উত্তর দেওয়ার লক্ষ্য পূরণ হলো। এরপর ১০:২০-এ তিনি একটি স্ক্রিনশট চাইলেন। গ্রাহক পরের দিন দুপুরে উত্তর দিলেন। ট্র্যাকার যদি এই অপেক্ষার সময়কে সমাধানের লক্ষ্যের মধ্যে ধরে, তাহলে যে সময়ে সাপোর্ট কাজই করতে পারেনি তার জন্য সাপোর্টকে দোষ দেওয়া হবে। আবার ট্র্যাকার যদি টাইমার থামায় কিন্তু পরে চালু না করে, তাহলে ফল উল্টো দিক থেকে ভুল হবে।

একটি ট্র্যাকারকে প্রতিটি টিকিটের জন্য একটি যৌথ অপারেশনাল রেকর্ড দিতে হবে: মালিক, টিম, অগ্রাধিকার, উত্তর ও সমাধানের সময়সীমা, টাইমারের অবস্থা, বিরতির কারণ এবং পরিবর্তনের ইতিহাস। তখন এজেন্টরা সময়সীমা পেরিয়ে যাওয়ার কাছাকাছি থাকা কাজগুলোতে মন দিতে পারবেন। ম্যানেজাররা কর্মী সংকট, দায়িত্ব হস্তান্তর বা গ্রাহকের অপেক্ষার কারণে হওয়া বিলম্বও চিহ্নিত করতে পারবেন।

ছোট এবং স্থিতিশীল কিউয়ের জন্য ম্যানুয়াল শিট কাজ করতে পারে। কিন্তু সময়সীমা যখন অগ্রাধিকার, কাজের সময়, দায়িত্ব বদল এবং বিরতির ওপর নির্ভর করে, তখন ট্র্যাকারকে একরকম নিয়ম মেনে চলতে হবে।

প্রতিটি SLA রেকর্ডে কী দরকার তা ঠিক করুন

প্রতিটি টিকিটে এমন যথেষ্ট তথ্য থাকা দরকার, যাতে বোঝা যায় এর দায়িত্ব কার, কোন প্রতিশ্রুতি প্রযোজ্য এবং টাইমার চলবে কি না। শুরু করুন মূল তথ্য দিয়ে: গ্রাহক বা অ্যাকাউন্ট, অগ্রাধিকার, নির্ধারিত টিম, টিকিটের মালিক এবং বর্তমান স্ট্যাটাস।

এরপর সময়সীমা নিয়ন্ত্রণ করে এমন ফিল্ড যোগ করুন:

• SLA নীতি, যেমন «Standard support» বা «Priority support»
• শুরুর সময়
• প্রথম উত্তর এবং সমাধানের নির্ধারিত সময়
• বিরতির কারণ এবং বিরতি শুরুর সময়
• আবার চালুর সময় বা মোট বিরতির সময়

প্রথম উত্তর এবং সম্পূর্ণ সমাধান আলাদা রাখুন। কোনো টিম চার কর্মঘণ্টার মধ্যে প্রথম উত্তর দেওয়ার প্রতিশ্রুতি দিতে পারে, কিন্তু সমাধানের জন্য দুই কর্মদিবস সময় রাখতে পারে। একটি মাত্র সময়সীমা দ্রুত স্বীকৃতি জানানোর আড়ালে অমীমাংসিত টিকিট লুকিয়ে ফেলে।

এজেন্টদের ম্যানুয়ালি «breached» নির্বাচন করতে বলবেন না। বর্তমান সময়, নির্ধারিত সময়, টিকিটের স্ট্যাটাস এবং বৈধ বিরতির ভিত্তিতে এটি হিসাব করুন। উদাহরণস্বরূপ, নির্ধারিত সময় পেরিয়ে গেলে, টিকিট খোলা থাকলে এবং টাইমার সক্রিয় থাকলে তার সমাধানের SLA লঙ্ঘিত হয়।

AppMaster এই লজিক এক জায়গায় রাখতে পারে। এর Data Designer দিয়ে টিকিটের ফিল্ড মডেল করা যায়, আর ভিজ্যুয়াল Business Process দিয়ে এজেন্ট টিকিট তৈরি বা আপডেট করলে সময়সীমা এবং লঙ্ঘনের অবস্থা হিসাব করা যায়।

ট্র্যাকার তৈরির আগে SLA নিয়ম ঠিক করুন

স্পষ্ট নিয়ম SLA ফলাফলকে ন্যায্য রাখে। ফর্মুলা বা রিপোর্ট তৈরির আগে প্রতিটি টিকিটের শ্রেণির লক্ষ্য নির্ধারণ করুন। তা না হলে দুই এজেন্ট একই অনুরোধ ভিন্নভাবে সামলাতে পারেন এবং লঙ্ঘনের সংখ্যা আর অর্থবহ থাকে না।

বেশিরভাগ টিম অগ্রাধিকার, গ্রাহকের প্ল্যান এবং অনুরোধের ধরন অনুযায়ী লক্ষ্য বদলায়। প্রথম সংস্করণ ছোট রাখুন। উদাহরণস্বরূপ, জরুরি প্রোডাকশন সমস্যায় এক ঘণ্টার মধ্যে প্রথম উত্তর, পেইড প্ল্যানের অ্যাক্সেস সমস্যায় চার কর্মঘণ্টার মধ্যে প্রথম উত্তর এবং সাধারণ প্রশ্নে দুই কর্মদিবসের মধ্যে প্রথম উত্তর প্রয়োজন হতে পারে।

প্রতিটি নিয়ম সহজ ভাষায় লিখুন। «একজন প্রিমিয়াম গ্রাহকের উচ্চ-অগ্রাধিকার বিলিং সমস্যায় দুই কর্মঘণ্টার মধ্যে প্রথম উত্তর দিতে হবে» বললে ঠিক কোন ডেটা রাখতে হবে তা স্পষ্ট হয়: অগ্রাধিকার, প্ল্যান, অনুরোধের ধরন, তৈরির সময় এবং প্রথম উত্তরের সময়।

কাজের ক্যালেন্ডার নির্ধারণ করুন

লক্ষ্য সারাদিন চলবে, নাকি শুধু সাপোর্টের সময়ে চলবে তা ঠিক করুন। সাপোর্ট যদি সোমবার থেকে শুক্রবার সকাল ৯টা থেকে বিকেল ৫টা পর্যন্ত চলে, তাহলে শুক্রবার ১৬:৩০-এ পাওয়া দুই ঘণ্টার লক্ষ্যযুক্ত টিকিটের সময়সীমা সোমবার ১০:৩০ হবে, শুক্রবার সন্ধ্যায় নয়।

কাজের দিন, সাপোর্টের সময়, টাইম জোন, ছুটি এবং আলাদা ২৪/৭ ইনসিডেন্ট ক্যালেন্ডার লিখে রাখুন। সম্ভব হলে প্রতিটি নীতির জন্য একটি নামযুক্ত ক্যালেন্ডার ব্যবহার করুন। বিভিন্ন দেশের গ্রাহক থাকলে আঞ্চলিক ক্যালেন্ডার দরকার হতে পারে, কিন্তু প্রতিটি গ্রাহকের জন্য আলাদা ক্যালেন্ডার তৈরি করলে অপ্রয়োজনীয় রক্ষণাবেক্ষণ বাড়ে।

শুরুর পয়েন্ট এবং নীতির দায়িত্ব ঠিক করুন

টাইমার ঠিক কখন শুরু হবে তা নির্দিষ্টভাবে ঠিক করুন। নতুন টিকিট সাধারণত সিস্টেমে পৌঁছানোর সময় শুরু হয়। আবার খোলা টিকিটের জন্য আলাদা নিয়ম দরকার: অবশিষ্ট সময় চালিয়ে যাবেন, আগের টাইমার নতুন করে শুরু করবেন, নাকি নতুন লক্ষ্য শুরু করবেন। একটি পদ্ধতি বেছে নিয়ে ধারাবাহিকভাবে প্রয়োগ করুন।

নীতি পরিবর্তনের দায়িত্ব একজন ব্যক্তি বা ছোট দলের ওপর দিন। এজেন্টরা টিকিটের তথ্য সংশোধন করতে পারেন, কিন্তু লঙ্ঘন সরানোর জন্য তাদের লক্ষ্য সময় বদলানো উচিত নয়। প্রতিটি রেকর্ডে নীতির সংস্করণ রাখুন এবং অনুমোদিত ব্যতিক্রমের কারণ ও তারিখ লিখে রাখুন।

AppMaster অ্যাপ একটি অ্যাডমিন এলাকায় নীতিগুলো রাখতে পারে এবং টিকিট সিস্টেমে ঢোকার সময় মিল থাকা নিয়ম প্রয়োগ করতে পারে। এতে আলাদা স্প্রেডশিট ফর্মুলার বদলে একটি ধারাবাহিক টাইমার পাওয়া যায়।

ট্র্যাকারের পেছনের ডেটা মডেল করুন

প্রথম সংস্করণটি এমন সহজ রাখুন, যাতে একজন অপারেশনস লিড একটি টিকিট দেখে বুঝতে পারেন কেন তার সময়সীমা বদলেছে।

একটি টিকিট টেবিল দিয়ে শুরু করুন। এতে থাকবে আইডি, বিষয়, গ্রাহক, অগ্রাধিকার, স্ট্যাটাস, তৈরির সময়, প্রথম উত্তরের সময়, সমাধানের সময়, সময়সীমা, নির্ধারিত মালিক এবং দায়িত্বপ্রাপ্ত টিম। একাধিক ব্যক্তি মন্তব্য করলেও প্রতিটি টিকিটের একজন বর্তমান মালিক এবং একটি টিম থাকা উচিত।

টিম এবং SLA নীতির জন্য আলাদা রেকর্ড তৈরি করুন। টিমের রেকর্ডে নাম এবং কাজের সময়ের সূচি থাকতে পারে। প্রতিটি নীতিতে কোন টিকিটের ক্ষেত্রে এটি প্রযোজ্য, উত্তর ও সমাধানের লক্ষ্য, টাইমারের ধরন এবং গ্রাহকের অপেক্ষার সময় টাইমার থামাবে কি না তা উল্লেখ করুন।

তারিখ, সংশ্লিষ্ট টিম বা অবস্থান এবং সংক্ষিপ্ত লেবেলসহ একটি ছুটির রেকর্ড যোগ করুন। সব টাইমস্ট্যাম্প একটি নির্দিষ্ট টাইম জোনে, সাধারণত UTC-তে, সংরক্ষণ করুন। প্রয়োজনে ইন্টারফেসে স্থানীয় সময় দেখান। বিভিন্ন টাইম জোন মিশিয়ে ফেললে সপ্তাহান্ত এবং ডেলাইট-সেভিং পরিবর্তনের সময় ভুল হয়।

আগের তথ্য মুছে না দিয়ে স্ট্যাটাসের ইতিহাস রাখুন। প্রতিটি এন্ট্রিতে টিকিট আইডি, পুরোনো ও নতুন স্ট্যাটাস, ঘটনার সময় এবং পরিবর্তনটি যিনি করেছেন বা যে নিয়ম করেছে তা লিখুন। «Waiting for customer», «Customer replied», «Assigned» এবং «Resolved» ধরনের ঘটনাও সংরক্ষণ করুন।

এই ইতিহাস সময়সীমার পরিবর্তন ব্যাখ্যা করে। নির্ধারিত সময় মঙ্গলবার সকাল থেকে মঙ্গলবার বিকেলে সরে গেলে ম্যানেজার দেখতে পারবেন যে গ্রাহকের অপেক্ষায় টিম তিন ঘণ্টা SLA থামিয়েছিল। AppMaster-এর ভিজ্যুয়াল Data Designer দিয়ে এই সম্পর্কিত রেকর্ড মডেল করা যায়, আর Business Process Editor স্ট্যাটাস বদলানোর পর সময়সীমা আপডেট করতে পারে।

টিকিটের নির্ধারিত সময় হিসাব করুন

একটি স্পষ্ট ঘটনা থেকে টাইমার শুরু করুন, যেমন সাপোর্ট টিকিট সিস্টেমে পৌঁছানোর সময়। কেউ টিকিটটি দেখেছেন এমন সময় থেকে টাইমার শুরু করবেন না। শুরুর সময় সংরক্ষণ করুন, যাতে পরের প্রতিটি হিসাব একই রেফারেন্স পয়েন্ট ব্যবহার করে।

এরপর গ্রাহকের প্ল্যান, টিকিটের ধরন, অগ্রাধিকার বা অঞ্চল অনুযায়ী সঠিক SLA নীতি বেছে নিন। তারপর নির্ধারিত সময় হিসাব করুন:

1. টিকিটের লক্ষ্য পড়ুন, যেমন চার ঘণ্টার উত্তর দেওয়ার সময়।
2. নীতিতে অনুমোদিত কর্মসময়ই যোগ করুন।
3. নীতিতে বাদ থাকলে বন্ধের সময়, সপ্তাহান্ত এবং ছুটি এড়িয়ে চলুন।
4. টিকিটে সময়সীমা সংরক্ষণ করুন।
5. অগ্রাধিকার, প্ল্যান বা শ্রেণি বদলে অন্য নীতি প্রযোজ্য হলে আবার হিসাব করুন।

কাজের সময়ের বিষয়টি শুনতে যত সহজ, বাস্তবে ততটা নয়। চার ঘণ্টার SLA বিকেল ৪টায় শুরু হলে এবং সাপোর্ট সকাল ৯টা থেকে বিকেল ৫টা পর্যন্ত চললে, সেদিন এক ঘণ্টা সময় অবশিষ্ট থাকে। টিকিটের সময়সীমা পরবর্তী কর্মদিবসে দুপুর ১২টা হবে, রাত ৮টা নয়।

টিকিটের অগ্রাধিকার বদলালে আগের শুরুর সময় রাখুন এবং লিখিত এসকেলেশন নিয়ম প্রয়োগ করুন। কিছু টিম মূল শুরুর সময় থেকেই জরুরি লক্ষ্য প্রয়োগ করে, অন্যরা টিকিট এসকেলেট হওয়ার সময় নতুন লক্ষ্য শুরু করে। সবাই একই নিয়ম মানলে যেকোনো পদ্ধতি কাজ করতে পারে।

সঠিক সময়সীমা এবং বাকি সময় দুটোই দেখান। «২ ঘণ্টা ১৫ মিনিট বাকি», «১ দিনের মধ্যে নির্ধারিত» এবং «৩৫ মিনিট বিলম্বিত» ধরনের লেবেল এজেন্টদের টাইমস্ট্যাম্পের চেয়ে দ্রুত কিউ স্ক্যান করতে সাহায্য করে। সময়মতো থাকা টিকিটে নিরপেক্ষ অবস্থা, সময়সীমার কাছাকাছি সতর্কতা এবং সময় পেরিয়ে গেলে স্পষ্ট লঙ্ঘনের অবস্থা ব্যবহার করুন।

গ্রাহকের উত্তরের জন্য টাইমার থামান

টিম গ্রাহক ছাড়া টিকিট এগিয়ে নিতে না পারলেই কেবল টাইমার থামান। সাধারণ কারণের মধ্যে আছে তথ্য, নিশ্চিতকরণ, অ্যাক্সেস, অনুমোদন বা ফাইলের অপেক্ষা। সহকর্মীর জন্য অপেক্ষার মতো অভ্যন্তরীণ বিলম্ব SLA থামাবে না।

অল্প এবং পরিষ্কার কিছু স্ট্যাটাস ব্যবহার করুন:

• গ্রাহকের তথ্যের অপেক্ষায়
• গ্রাহকের অনুমোদনের অপেক্ষায়
• গ্রাহকের অ্যাক্সেসের অপেক্ষায়
• গ্রাহকের পাঠানো ফাইলের অপেক্ষায়

এজেন্ট এসব স্ট্যাটাসের একটি বেছে নিলে সঠিক বিরতির সময় এবং কারণ সংরক্ষণ করুন। গ্রাহকের উত্তর চাওয়া বার্তা বা ঘটনাটিও রাখুন। এতে সুপারভাইজাররা বিরতিটি যুক্তিসঙ্গত ছিল কি না যাচাই করতে পারবেন।

গ্রাহক উত্তর দিলে উত্তরের সময় থেকে টাইমার আবার চালু করুন। total paused time-এ অপেক্ষার সময় যোগ করুন, তারপর কাজের সময়ের নিয়ম অনুযায়ী বাকি সময় আবার হিসাব করুন। গ্রাহক ৯০ মিনিট অপেক্ষা করলে বন্ধের সময়ের নিয়ম প্রযোজ্য রেখে সময়সীমা ৯০ মিনিট এগিয়ে যাবে।

টিকিটের ভিউতে বিরতির সময় দেখান। একটি টিকিট ১৫ মিনিট নাকি তিন দিন অপেক্ষা করেছে তা এজেন্টদের জানা দরকার। সুপারভাইজারদেরও এমন টিকিট চিহ্নিত করতে পারা উচিত, যেগুলো বারবার অপেক্ষার স্ট্যাটাসে ফিরে যায়।

SLA নীতিতে অনুমোদিত বিরতির কারণেই সীমাবদ্ধ থাকুন। বিরতি গ্রহণের আগে গ্রাহকের কাছে অনুরোধ পাঠানোর ঘটনা থাকা বাধ্যতামূলক করুন। AppMaster-এ একটি Business Process নতুন স্ট্যাটাস পরীক্ষা করতে, বিরতি শুরুর সময় সংরক্ষণ করতে এবং SLA রেকর্ড আপডেটের আগে অবৈধ পরিবর্তন প্রত্যাখ্যান করতে পারে।

স্বয়ংক্রিয় «we received your message» ইমেল টাইমার আবার চালু করবে না। গ্রাহকের পাঠানো ইনবাউন্ড বার্তা বা এজেন্টের নিশ্চিত করা উত্তর ব্যবহার করুন এবং টিকিটের সঙ্গে পুরো বিরতির ইতিহাস রাখুন।

একটি কাস্টমার সাপোর্ট উদাহরণ দেখুন

একজন গ্রাহক মঙ্গলবার সকাল ১০টায় একটি বিলিং প্রশ্ন পাঠালেন: «আমার ইনভয়েসে দুটি চার্জ কেন দেখাচ্ছে?» ট্র্যাকার B-184 টিকিট তৈরি করে, সেটি Support-এ দেয় এবং বিলিং SLA প্রয়োগ করে। টিমের কাছে প্রথম কার্যকর উত্তর দেওয়ার জন্য চার কর্মঘণ্টা এবং সমাধানের জন্য আট কর্মঘণ্টা আছে।

Support সোমবার থেকে শুক্রবার সকাল ৯টা থেকে বিকেল ৫টা পর্যন্ত কাজ করে। ১০:৩৫-এ একজন এজেন্ট জানান যে টিম অ্যাকাউন্টটি পরীক্ষা করছে। প্রথম উত্তরের টাইমার ৩৫ মিনিটে থামে, ফলে ৩ ঘণ্টা ২৫ মিনিট বাকি থাকে। টিকিটটি প্রথম উত্তরের লক্ষ্য পূরণ করে।

১১:০০-এ এজেন্টের একটি ইনভয়েস নম্বর দরকার হয় এবং তিনি টিকিটটিকে «Waiting for customer» করেন। এক ঘণ্টা সক্রিয় কাজের পর সমাধানের টাইমার থামে। ট্র্যাকার বিরতির শুরুর সময় এবং কারণ সংরক্ষণ করে।

গ্রাহক ১৫:৩০-এ উত্তর দেন। ট্র্যাকার বিরতিতে থাকা ৪ ঘণ্টা ৩০ মিনিট মূল সময়সীমায় যোগ করে। মূল সমাধানের সময়সীমা ছিল মঙ্গলবার ১৮:০০। তাই অবশিষ্ট সময় পরবর্তী কর্মদিবসে যাওয়ার পর সংশোধিত সময়সীমা হয় বুধবার ১৪:৩০।

একজন এজেন্ট বুধবার ১৫:১০-এ সমস্যাটি সমাধান করেন। টিকিটটি ৪০ মিনিট দেরিতে সমাধান হয়। Support-এর জন্য এটি একটি বিলম্বিত সমাধান হিসেবে গণনা হবে, কিন্তু প্রথম উত্তর সময়মতো ছিল।

লঙ্ঘনের রিপোর্টে বিভাজনটি স্পষ্ট থাকা উচিত: Support একটি বিলিং টিকিট পেয়েছে, প্রথম উত্তরের লক্ষ্য পূরণ করেছে, সমাধানের লক্ষ্য ৪০ মিনিট মিস করেছে এবং গ্রাহকের অপেক্ষায় ৪ ঘণ্টা ৩০ মিনিট কাটিয়েছে। টিকিটের মোট বয়স একা দেখলে ভুল চিত্র পাওয়া যেত।

টিম অনুযায়ী SLA লঙ্ঘন রিপোর্ট করুন

প্রয়োজনীয় কাজ হওয়ার আগে নির্ধারিত সময় পেরিয়ে গেলে টিকিটের SLA লঙ্ঘিত হয়। বৈধ গ্রাহক-অপেক্ষার বিরতির পর সংশোধিত সময়সীমা ব্যবহার করুন।

খোলা অবস্থায় বিলম্বিত টিকিট এবং দেরিতে সমাধান হওয়া টিকিট আলাদা রাখুন। খোলা বিলম্বিত টিকিটে এখনই মনোযোগ দরকার। দেরিতে সমাধান হওয়া টিকিট কর্মদক্ষতার রিপোর্টে থাকবে। এগুলো একসঙ্গে রাখলে জরুরি কাজ আড়ালে চলে যায় এবং রিপোর্ট ব্যবহার করা কঠিন হয়।

প্রতিটি সময়কালে সময়সীমা পেরোনোর মুহূর্তে যে টিম টিকিটটির মালিক ছিল, সেই টিম অনুযায়ী ফলাফল সাজান। নীতি, অগ্রাধিকার এবং তারিখের পরিসর দিয়ে ফিল্টার করুন। চার ঘণ্টার উত্তর নীতির বিলিং টিমকে সরাসরি দুই কর্মদিবসের সমাধান নীতির টেকনিক্যাল এসকেলেশন টিমের সঙ্গে তুলনা করা উচিত নয়।

হারের পাশাপাশি সংখ্যাও ব্যবহার করুন:

• সক্রিয় SLA থাকা মোট টিকিট
• নির্ধারিত সময়ের মধ্যে সমাধান হওয়া টিকিট
• খোলা অবস্থায় সময় পেরিয়ে যাওয়া টিকিট
• সময়সীমার পরে সমাধান হওয়া টিকিট
• SLA থাকা টিকিটের মধ্যে লঙ্ঘিত টিকিটের অনুপাত হিসেবে হিসাব করা লঙ্ঘনের হার

দুটি টিকিটের মধ্যে একটি দেরিতে হওয়া ৫০% হার এবং ১০০টির মধ্যে ৫০টি টিকিট দেরিতে হওয়া ৫০% হার এক নয়। টিকিটের বিস্তারিত তথ্যের সঙ্গে প্রবণতাও পর্যালোচনা করুন। উচ্চ-অগ্রাধিকার টিকিটে বারবার লঙ্ঘন হলে সামগ্রিক কাজের চাপের বদলে এসকেলেশন নিয়ম বা দায়িত্ব হস্তান্তরের সমস্যা বোঝাতে পারে।

একটি কার্যকর রিপোর্টে ম্যানেজার দেরি হওয়া টিকিটের তালিকা খুলে নীতি ও অগ্রাধিকার দেখতে এবং লঙ্ঘনের সময় দায়িত্ব কার ছিল তা যাচাই করতে পারবেন। রিপোর্টের লক্ষ্য হওয়া উচিত ঠিক করা দরকার এমন কাজ পর্যালোচনা করা, খুব দ্রুত টিকিট বন্ধ করার জন্য টিমকে পুরস্কৃত করা নয়।

এজেন্ট এবং ম্যানেজারের জন্য আলাদা ভিউ তৈরি করুন

এজেন্টদের পুরোনো টিকিটে ভরা রিপোর্ট নয়, ছোট একটি কাজের তালিকা দরকার। প্রতিটি খোলা টিকিটে মালিক, টিম, অগ্রাধিকার, সময়সীমা, টাইমারের অবস্থা এবং বাকি সময় দেখানো উচিত। টিকিট এক টিম থেকে অন্য টিমে গেলে সঙ্গে সঙ্গে দায়িত্বের পরিবর্তন রেকর্ড করুন।

সহজ টাইমার লেবেল ব্যবহার করুন। «Active» মানে পরবর্তী কাজের দায়িত্ব টিমের। «Paused - waiting for customer» মানে টাইমার থেমে আছে। সক্রিয় সময় এবং বিরতির সময় আলাদা দেখান, যাতে ব্যবহারকারীরা বুঝতে পারেন কেন একটি টিকিট কয়েক দিন ধরে খোলা আছে।

এজেন্ট ভিউতে পরবর্তী চার ঘণ্টায় নির্ধারিত টিকিট, সময় পেরিয়ে যাওয়া টিকিট, গ্রাহকের উত্তরের অপেক্ষায় থাকা টিকিট এবং আজ পুনরায় নির্ধারিত টিকিট রাখা যেতে পারে। সময়সীমার আগে সতর্কতা পাঠান। চার ঘণ্টার উত্তর লক্ষ্যে তিন দিনের সমাধান লক্ষ্যের তুলনায় আগে সতর্ক করা দরকার।

ম্যানেজারদের জন্য ভিন্ন ভিউ দরকার। সাপ্তাহিক রিপোর্টে টিম অনুযায়ী বিলম্বিত টিকিট সাজিয়ে লঙ্ঘনের সংখ্যা, পূরণ হওয়া লক্ষ্যের শতাংশ, গড় বিলম্বের সময় এবং সময়সীমা পেরিয়েও খোলা থাকা টিকিট দেখানো যেতে পারে। প্রতিটি বিলম্বিত টিকিটের মালিক এবং সর্বশেষ আপডেট রাখুন।

নীতি পরিবর্তনের জন্য অডিট রেকর্ড রাখুন। অপারেশনস টিম যদি লক্ষ্য আট ঘণ্টা থেকে ১২ ঘণ্টা করে, কে এবং কখন পরিবর্তন করেছে, আর কোন নতুন টিকিটে নতুন নিয়ম প্রযোজ্য হবে তা রেকর্ড করুন। ঐতিহাসিক ফলাফলে প্রতিটি টিকিট শুরু হওয়ার সময় যে নিয়ম প্রযোজ্য ছিল, সেটিই থাকা উচিত।

AppMaster একই টিকিট ডেটা এবং ব্যবসায়িক নিয়ম ব্যবহার করে এজেন্ট ও ম্যানেজারের জন্য আলাদা ওয়েব ভিউ তৈরি করতে দেয়।

যেসব ভুল SLA ফলাফলকে বিকৃত করে

ভিতরের নিয়ম ভুল হলে পরিষ্কার চার্টও ভুল গল্প বলতে পারে।

সময়ের নিয়ম আক্ষরিকভাবে প্রয়োগ করবেন না

চুক্তিতে কর্মঘণ্টা বলা থাকলে ক্যালেন্ডারের ঘণ্টা দিয়ে হিসাব করবেন না। শুক্রবার বিকেল ৪:৩০-এ খোলা আট কর্মঘণ্টার উত্তর লক্ষ্যের টিকিট শনিবার রাত ১২:৩০-এ SLA লঙ্ঘন করবে না। নীতিতে নির্ধারিত কর্মঘণ্টা এবং ছুটিই গণনা করুন।

বিরতির ক্ষেত্রেও একই সতর্কতা প্রয়োজন। «waiting for customer» স্ট্যাটাস তখনই SLA থামাবে, যখন টিম স্পষ্ট অনুরোধ পাঠিয়েছে এবং উত্তর ছাড়া এগোতে পারছে না। এই লেবেল থাকা প্রতিটি টিকিট থামালে টিমের নিজের বিলম্ব আড়ালে চলে যায়।

প্রতিটি ফলাফল ব্যাখ্যা করে এমন তারিখ সংরক্ষণ করুন: মূল সময়সীমা, ব্যবহৃত নীতি, প্রতিটি বিরতির শুরুর ও শেষের সময়, বিরতির কারণ, সংশোধিত সময়সীমা, সমাধানের সময় এবং টিকিট বন্ধ করা ব্যক্তির তথ্য। এই ইতিহাস না থাকলে কোনো টিকিট কেন সময়মতো দেখাচ্ছে তা যাচাই করা যায় না।

দায়িত্ব একবারই গণনা করুন

টিমভিত্তিক রিপোর্টে একটি দায়িত্বের নিয়ম ব্যবহার করুন। Support কোনো টিকিট Billing-এ পাঠালে একই লঙ্ঘন দুই টিমের জন্য গণনা করবেন না। সময়সীমা পার হওয়ার মুহূর্তে যে টিমের দায়িত্ব ছিল, ফলাফল সেই টিমকে দিতে পারেন এবং হস্তান্তর আলাদাভাবে রিপোর্ট করতে পারেন।

টিকিট বন্ধ করার আগে সমাধানের টাইমস্ট্যাম্প বাধ্যতামূলক করুন। Closed স্ট্যাটাস কাজ কখন শেষ হয়েছে তা প্রমাণ করে না। উদাহরণস্বরূপ, টিকিটটি ১৪:০০-এ Support থেকে Billing-এ গেলে এবং ১৫:০০-এ সময়সীমা পেরোলে, লঙ্ঘনের সময়কার দায়িত্বের নিয়ম অনুযায়ী Billing লঙ্ঘনের মালিক হবে। রিপোর্টে আগের Support হস্তান্তর দেখা যাবে, কিন্তু দ্বিতীয় লঙ্ঘন যোগ হবে না।

চালু করার আগে ট্র্যাকার পরীক্ষা করুন

এজেন্টরা ট্র্যাকার ব্যবহার শুরু করার আগে প্রতিটি SLA নীতি পর্যালোচনা করুন। প্রতিটি নীতিতে স্পষ্ট লক্ষ্য, যেমন চার ঘণ্টার প্রথম উত্তর বা দুই কর্মদিবসের সমাধান, এবং তার প্রযোজ্য ক্যালেন্ডার থাকতে হবে। কোনো গ্রাহক, প্ল্যান বা অগ্রাধিকার নিয়মের সঙ্গে না মেলা টিকিটের জন্য একটি ডিফল্ট নীতি নির্ধারণ করুন।

শুধু সাধারণ ঘটনা নয়, অস্বস্তিকর সময়ের ঘটনাও পরীক্ষা করুন:

• কর্মদিবস শেষ হওয়ার কিছু আগে একটি টিকিট তৈরি করে দেখুন বাকি সময় পরবর্তী কর্মদিবসে যায় কি না।
• সপ্তাহান্ত বা ছুটির আগে একটি টিকিট তৈরি করে দেখুন নির্ধারিত সময় বন্ধ সময় এড়িয়ে যায় কি না।
• গ্রাহকের উত্তরের জন্য টিকিট থামিয়ে উত্তর পাঠান এবং টাইমার সঠিকভাবে আবার চালু হয় কি না দেখুন।
• টিকিট এক টিম থেকে অন্য টিমে পাঠিয়ে পরের লঙ্ঘনের দায়িত্ব কোন টিমের হয় তা পরীক্ষা করুন।
• সময়সীমার পরে টিকিট বন্ধ করে দেখুন ট্র্যাকার লঙ্ঘন রেকর্ড করছে কি না।

ড্যাশবোর্ডের মোট সংখ্যার সঙ্গে তার পেছনের টিকিট তালনা করুন। রিপোর্টে Team A-এর ১২টি লঙ্ঘন দেখালে রেকর্ড ফিল্টার করে সেগুলো গুনুন। এতে ডুপ্লিকেট টিকিট, অনুপস্থিত টিম এবং দুবার গণনা হওয়া আবার খোলা টিকিট ধরা পড়বে।

রিলিজের আগে অ্যাক্সেসের নিয়ম ঠিক করুন। এজেন্টরা তাদের পরিচালিত টিকিট আপডেট করবে, ম্যানেজারদের টিম রিপোর্ট দরকার হবে এবং অ্যাডমিনিস্ট্রেটররা নীতির সেটিং নিয়ন্ত্রণ করবেন। AppMaster-এ আলাদা অ্যাকাউন্ট দিয়ে প্রতিটি ভূমিকা পরীক্ষা করুন, যাতে SLA লঙ্ঘনের রিপোর্ট দেখতে ম্যানেজারকে অ্যাডমিনিস্ট্রেটরের অ্যাক্সেস নিতে না হয়।

ছোটভাবে শুরু করুন এবং ওয়ার্কফ্লো উন্নত করুন

একটি টিকিটের ধরন এবং একটি SLA নীতি দিয়ে শুরু করুন। কোনো সাপোর্ট টিম সাধারণ ইমেল অনুরোধ এবং ২৪ ঘণ্টার প্রথম উত্তরের লক্ষ্য দিয়ে শুরু করতে পারে। সময়সীমা, অনুমোদিত বিরতি এবং লঙ্ঘনের রেকর্ড পরীক্ষা করার জন্য এটুকুই যথেষ্ট।

কয়েকজন কাস্টমার অপারেশনস কর্মীকে বাস্তব টিকিট দিয়ে ওয়ার্কফ্লো চালাতে বলুন। একটি সাধারণ ঘটনা, গ্রাহকের অপেক্ষার ঘটনা এবং সময়সীমা মিস হওয়া ঘটনা রাখুন। নির্দিষ্ট মতামত সংগ্রহ করুন। এজেন্টদের গ্রাহকের জন্য অপেক্ষা এবং অন্য টিমের জন্য অপেক্ষার আলাদা স্ট্যাটাস দরকার হতে পারে। ম্যানেজাররা দেখতে পারেন যে সাধারণ «paused» লেবেল অতিরিক্ত তথ্য লুকিয়ে রাখছে।

স্প্রেডশিট প্রক্রিয়াকে সীমাবদ্ধ করলে AppMaster-এ নো-কোড অ্যাপ হিসেবে ট্র্যাকার তৈরি করুন। টিকিট ফর্ম তৈরি করুন, ভিজ্যুয়াল Business Process Editor-এ টাইমারের লজিক নির্ধারণ করুন এবং এজেন্ট ও ম্যানেজারের জন্য আলাদা ড্যাশবোর্ড দিন। ট্র্যাকারকে শেয়ার করা টেবিলের বাইরে ব্যবহার করতে হলে AppMaster ব্যাকএন্ড, ওয়েব অ্যাপ এবং নেটিভ মোবাইল অ্যাপ তৈরি করতে পারে।

শুরুতে রিপোর্ট সংক্ষিপ্ত রাখুন: খোলা টিকিট, লঙ্ঘনের কাছাকাছি টিকিট, বিরতিতে থাকা টিকিট এবং টিম অনুযায়ী লঙ্ঘন। নমুনা সময়সীমা ম্যানুয়ালি যাচাই করুন, লঙ্ঘিত টিকিট ও তাদের বিরতির সময় পর্যালোচনা করুন এবং আবার পরীক্ষা করার আগে একবারে একটি নিয়ম বদলান। কর্মীরা হিসাবের ওপর আস্থা পেলে আরও একটি টিকিটের ধরন বা অগ্রাধিকার নীতি যোগ করুন এবং একই পরীক্ষা আবার করুন।