শেয়ার করা ইমেল অ্যালিয়াসের বদলে কেস ম্যানেজমেন্ট অ্যাপ ব্যবহার করুন

শেয়ার করা অ্যালিয়াস কেন বিভ্রান্তি তৈরি করে

support@ বা it@-এর মতো একটি শেয়ার করা ঠিকানা সহজ মনে হয়। দলের যে কেউ আসা বার্তা পড়ে উত্তর দিতে পারেন। কিন্তু ইনবক্সে সাধারণত বোঝা যায় না কোনো অনুরোধের মালিক কে, কাজ কখন শুরু হয়েছে বা পরবর্তী ধাপ কী।

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

ফলে সেবার মানে অসমতা আসে। সঠিক ব্যক্তি বার্তাটি দেখলে সাধারণ অনুরোধের উত্তর কয়েক মিনিটেই চলে যেতে পারে। আবার আরও জরুরি কোনো অনুরোধ কয়েক দিন পড়ে থাকতে পারে, কারণ সবাই ধরে নেন অন্য কেউ সেটি দেখছেন।

ইমেল মালিকানা আড়াল করে

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

দলগুলো প্রায়ই বিষয়ের লাইনে «[Assigned: Mia]» বা «In progress» নামের ফোল্ডারের মতো পদ্ধতি ব্যবহার করে। সবাই প্রতিবার একই নিয়ম মেনে চললে এগুলো কাজ করতে পারে। কিন্তু কাজ অন্য কারও কাছে গেলে বা একাধিক দলের সহযোগিতা দরকার হলে পদ্ধতিগুলো ভেঙে পড়ে।

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

একাধিক উত্তর সময় ও আস্থা নষ্ট করে

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

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

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

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

স্পষ্ট রিকোয়েস্ট স্ট্যাটাস ট্র্যাকিং এই অভিজ্ঞতা বদলে দেয়। «Received», «Waiting for approval», «In progress» এবং «Completed»-এর মতো লেবেল মানুষকে সরাসরি উত্তর দেয়। শেয়ার করা ইমেল অ্যালিয়াসের বদলে কেস রেকর্ড ব্যবহার করলে প্রতিটি অনুরোধের একটি নির্দিষ্ট জায়গা, একজন নির্দিষ্ট মালিক এবং সমাপ্তির দিকে যাওয়ার দৃশ্যমান পথ থাকে।

কেস ম্যানেজমেন্টে কী বদলে যায়

একটি কেস ম্যানেজমেন্ট অ্যাপ প্রতিটি অনুরোধকে একটি কেসে পরিণত করে, যেখানে স্পষ্ট মালিক, বর্তমান স্ট্যাটাস ও সম্পূর্ণ ইতিহাস থাকে। অনুরোধ ফর্ম, ইমেল বা অন্য দলের বার্তা থেকে শুরু হতে পারে। অ্যাপে ঢোকার পর কর্মীরা ইনবক্সে কপি চালাচালি না করে একই রেকর্ডে কাজ করেন।

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

কেস রেকর্ডে সব প্রাসঙ্গিক তথ্য এক জায়গায় থাকে। কাজ এক দল থেকে অন্য দলে গেলে মালিকানা বদলাতে পারে, কিন্তু কেসটি একই থাকে। «New», «In progress», «Waiting for requester» এবং «Closed»-এর মতো স্ট্যাটাস কর্মী ও রিকোয়েস্টার দুজনকেই অবস্থাটি বুঝতে সাহায্য করে।

অনেক থ্রেডের বদলে একটি রেকর্ড

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

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

প্রতিটি কেসে পরবর্তী কাজের মালিক কে, তা দেখা উচিত। কেউ মালিক না হলে টিম লিড দ্রুত ফাঁকটি ধরতে পারেন। মালিকের অন্য কারও মতামত দরকার হলে ইনবক্সে অনুরোধটি চাপা না রেখে একটি কাজ অ্যাসাইন করতে বা কেসটিকে অপেক্ষমাণ স্ট্যাটাসে নিতে পারেন।

নোট ও ইতিহাস অনুরোধের সঙ্গেই থাকে

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

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

আজ যে অনুরোধগুলো পান, সেগুলোর মানচিত্র তৈরি করুন

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

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

ইমেলের ধরনকে কেসের ধরনে পরিণত করুন

প্রতিটি বিভাগের জন্য কাজ শুরু করার আগে দলের কী তথ্য দরকার, তা লিখে রাখুন। অ্যাপ্লিকেশন অ্যাক্সেস রিকোয়েস্টে কর্মীর নাম, বিভাগ, ম্যানেজারের অনুমোদন, অ্যাপ্লিকেশনের নাম ও অ্যাক্সেসের কারণ লাগতে পারে। ল্যাপটপ সমস্যার জন্য ডিভাইস, ত্রুটির বার্তা ও জরুরিতার মতো আলাদা তথ্য দরকার।

ছোট তালিকা দিয়ে শুরু করুন। বেশি বিভাগ ফর্মকে কঠিন করে তোলে এবং মানুষকে আবার ইমেলে ফিরিয়ে দেয়। একই ধরনের প্রয়োজন বারবার দেখা গেলে পরে বড় বিভাগকে ভাগ করুন।

• অনুরোধের ধরন ও সংক্ষিপ্ত বিবরণ
• রিকোয়েস্টারকে যে তথ্য দিতে হবে
• সাধারণ মালিক বা দায়িত্বশীল দল
• স্ট্যাটাসের ধাপ ও প্রত্যাশিত উত্তর দেওয়ার সময়
• প্রয়োজনীয় অনুমোদন, নিরাপত্তা যাচাই বা হস্তান্তর

এই মানচিত্র কিউতে ঢোকার সময় প্রতিটি কেসে যথেষ্ট প্রেক্ষাপট যোগ করে। একই ফলো-আপ প্রশ্ন প্রতিটি রিকোয়েস্টারকে করতে হয় না।

প্রতিটি অনুরোধের জন্য একটি নির্দিষ্ট জায়গা দিন

প্রতিটি বিভাগের জন্য দায়িত্বশীল দল বা ভূমিকার নাম ঠিক করুন, এমনকি কাজটি একাধিক ব্যক্তি শেষ করতে পারলেও। «IT» অনেক সময় খুব বিস্তৃত। «identity administrator», «device support» ও «finance approver»-এর মতো লেবেল কার্যকর রাউটিং নিয়ম তৈরি করে এবং প্রত্যাশা স্পষ্ট করে।

কিছু অনুরোধ একাধিক দলের মধ্যে যায়। একটি কেস রাখুন, একজন বর্তমান মালিক ঠিক করুন এবং রেকর্ডে হস্তান্তর লিখে রাখুন। নতুন ল্যাপটপের অনুরোধে procurement-এর হার্ডওয়্যার অর্ডার করার আগ পর্যন্ত device support মালিক থাকতে পারে। Procurement আলাদা ইমেল থ্রেড নয়, একটি কাজ বা হস্তান্তর পাবে।

ভলিউম ও বিভ্রান্তির ভিত্তিতে প্রথমে কোন অ্যালিয়াস বদলাবেন, তা ঠিক করুন। এমন একটি ইনবক্স দিয়ে শুরু করুন যেখানে নিয়মিত একই ধরনের অনুরোধ আসে এবং একাধিক ব্যক্তি উত্তর দেন, যেমন it-support@ বা access@। দল প্রক্রিয়া নিয়ে একমত না হওয়া পর্যন্ত অস্বাভাবিক বা সংবেদনশীল অনুরোধগুলো পরে রাখুন।

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

প্রথম রোলআউটের সময় পুরোনো অ্যালিয়াস সক্রিয় রাখুন, তবে নতুন অনুরোধ কেস ফর্মে পাঠান। কয়েক সপ্তাহ নতুন কেস ও আসা ইমেল মিলিয়ে দেখুন। কর্মীরা পরিবর্তনের সময় মানুষকে সাহায্য করতে পারবেন, আর অনুপস্থিত বিভাগ ও অস্পষ্ট ফিল্ডগুলোও স্পষ্ট হয়ে উঠবে।

ধাপে ধাপে অ্যাপ সেট আপ করুন

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

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

সহজবোধ্য স্ট্যাটাস ফ্লো তৈরি করুন

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

• New: অ্যাপ অনুরোধ পেয়েছে, কিন্তু কেউ কাজ শুরু করেনি।
• In progress: একজন মালিক অনুরোধটি নিয়ে কাজ করছেন।
• Waiting: মালিকের অন্য কারও তথ্য, অনুমোদন বা কাজ দরকার।
• Closed: দল অনুরোধটি শেষ করেছে বা নিশ্চিত করেছে যে কোনো কাজ দরকার নেই।

রিকোয়েস্টারের জন্য প্রাসঙ্গিক স্ট্যাটাস দেখান। তারা শেয়ার করা ইনবক্সে «Any update?» না লিখে অগ্রগতি দেখতে পারবেন। একটি সংক্ষিপ্ত সমাপ্তি নোট যোগ করুন, যাতে দল কী করেছে তা তারা বুঝতে পারেন।

রাউটিং ও পুনরায় অ্যাসাইনমেন্টের নিয়ম যোগ করুন

প্রতিটি ধরনের অনুরোধ কে পাবেন, তা ঠিক করুন। নিয়মে বিভাগ, ক্যাটাগরি, অবস্থান বা জরুরিতার মতো ফর্মের উত্তর ব্যবহার করা যায়। ফাইন্যান্স সফটওয়্যারের অ্যাক্সেস রিকোয়েস্ট finance systems owner-এর কাছে যেতে পারে, আর ল্যাপটপের সমস্যা desktop support-এর কাছে যেতে পারে।

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

মালিকের জন্য সহজ পুনরায় অ্যাসাইনমেন্টের সুযোগও দরকার। কেউ ছুটিতে যেতে পারেন, কাজের চাপ বদলাতে পারে বা অনুরোধ ভুল কিউতে ঢুকতে পারে। মালিককে নতুন মালিক বেছে নিয়ে একটি সংক্ষিপ্ত অভ্যন্তরীণ নোট লিখতে বলুন, যেমন «IT অ্যাক্সেস দেওয়ার আগে payroll-এর অনুমোদন দরকার।» এতে রিকোয়েস্টারের কাছে অভ্যন্তরীণ আলোচনা প্রকাশ না করেই ইতিহাসে হস্তান্তরটি বোঝা যাবে।

AppMaster-এ দলগুলো ফর্ম, স্ট্যাটাস ফ্লো ও রাউটিং নিয়ম ভিজ্যুয়ালি মডেল করতে পারে। রিকোয়েস্টারের বর্তমান স্ট্যাটাস ও পাবলিক আপডেট দেখানোর জন্য আলাদা পেজ এবং অ্যাসাইনমেন্ট ও অভ্যন্তরীণ আলোচনার জন্য কর্মীদের আলাদা জায়গাও তৈরি করা যায়।

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

একাধিক উত্তর ছাড়াই কাজ রুট করুন

একাধিক উত্তর সাধারণত একটি ছোট ফাঁক থেকে শুরু হয়: দুজন একই ইমেল দেখেন, কিন্তু কেউ জানেন না অন্যজন কাজ শুরু করেছেন কি না। কেস ম্যানেজমেন্ট অ্যাপ প্রতিটি অনুরোধকে একজন মালিকসহ একটি দৃশ্যমান রেকর্ডে পরিণত করে এই ফাঁক বন্ধ করে।

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

প্রতিটি কেসের ওপরের দিকে মালিক ও স্ট্যাটাস রাখুন। New, Assigned, Waiting for requester, In progress এবং Closed-এর মতো স্পষ্ট লেবেল ব্যবহার করুন। কিউ দেখলেই যে কেউ বুঝতে পারবেন অনুরোধটি কে দেখছেন এবং তাদের কোনো কাজ করা দরকার কি না।

একটি সরল অ্যাসাইনমেন্ট নিয়মও সাহায্য করে। অ্যাকাউন্ট অ্যাক্সেসের অনুরোধ IT support queue-তে যেতে পারে, যেখানে একজন সাপোর্ট কর্মী সেটি গ্রহণ করবেন। গ্রহণের পর কেসে সেই ব্যক্তির নাম দেখা যাবে এবং এটি unassigned তালিকা থেকে সরে যাবে। অন্যরা রেকর্ড পড়তে পারবেন, তবে মালিক পুনরায় অ্যাসাইন না করা পর্যন্ত আলাদা উত্তর পাঠানো উচিত নয়।

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

একটি স্পষ্ট ফলো-আপ নিয়ম ঠিক করুন: একাধিক সহকর্মী অভ্যন্তরীণ নোট যোগ করলেও পরবর্তী বাইরের উত্তর মালিকই পাঠাবেন। ম্যানেজারকে দায়িত্ব নিতে হলে আগে কেসটি তার কাছে পুনরায় অ্যাসাইন করতে হবে। এই অভ্যাস পরস্পরবিরোধী উত্তর ঠেকায় এবং রিকোয়েস্টারকে একজন নির্ভরযোগ্য যোগাযোগের ব্যক্তি দেয়।

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

উদাহরণ: অভ্যন্তরীণ IT অ্যাক্সেস রিকোয়েস্ট

Maya সেলস দলে যোগ দিয়েছেন এবং প্রথম ক্লায়েন্ট কলের আগে একটি রিপোর্টিং টুলে অ্যাক্সেস দরকার। শেয়ার করা IT অ্যালিয়াসে তিনি সংক্ষিপ্ত একটি ইমেল পাঠিয়ে অপেক্ষা করতে পারেন। অনেকে সেটি দেখতে পারেন, কেউ দায়িত্ব না-ও নিতে পারেন, আর Maya দুই দিন পর আবার যোগাযোগ করতে পারেন।

কেস ম্যানেজমেন্ট অ্যাপে Maya «Access request» ফর্ম খোলেন। তিনি রিপোর্টিং টুলটি বেছে নেন, ব্যবসায়িক কারণ লেখেন, ম্যানেজার নির্বাচন করেন এবং অনুরোধ জমা দেন। অ্যাপ IT-1042 কেস তৈরি করে এবং স্ট্যাটাস «Submitted» দেখায়।

কেসটি একটি স্পষ্ট পথে এগোয়:

1. অ্যাপ অনুমোদনের জন্য কেসটি Maya-এর ম্যানেজারের কাছে পাঠায়।
2. অনুমোদনের পর রাউটিং নিয়ম এটি IT access queue-তে পাঠায়।
3. IT দলের একজন কর্মী কেসটি গ্রহণ করে মালিক হন।
4. মালিক অ্যাক্সেস দেন, কাজটি রেকর্ড করেন এবং কেস বন্ধ করেন।

প্রত্যেকে নিজের কাজটি দেখতে পান। ম্যানেজার একটি ইমেল থ্রেডের বদলে অনুমোদনের অনুরোধ পান। IT-এর মালিক Maya-এর বেছে নেওয়া টুল ও কারণসহ অনুমোদিত অনুরোধটি পান। অন্য IT কর্মীরা দেখতে পারেন যে IT-1042-এর মালিক একজন সহকর্মী, তাই তারা দুবার অ্যাক্সেস দেন না বা আরেকটি উত্তর পাঠান না।

Maya রিকোয়েস্ট পেজ খুলে বর্তমান ধাপ দেখতে পারেন। ম্যানেজার পর্যালোচনা করার সময় পেজে লেখা থাকে «Waiting for manager approval.» অনুমোদনের পর লেখা হয় «Assigned to IT.» মালিকের আরও তথ্য দরকার হলে Maya কেসের ভেতরেই বার্তা পান এবং একই জায়গায় উত্তর দেন।

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

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

পরিবর্তনের সময় সাধারণ ভুল

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

মালিকানা দৃশ্যমান রাখুন

স্মৃতি, মৌখিক সমঝোতা বা অনানুষ্ঠানিক চ্যাট বার্তার মাধ্যমে কেস অ্যাসাইন করবেন না। কেউ এক দিন ছুটিতে গেলে, দ্রুত কথোপকথনের মধ্যে বিষয়টি হারিয়ে গেলে বা দুজন একই অনুরোধ পড়লে এসব পদ্ধতির তথ্য আর থাকে না। প্রতিটি খোলা কেসের অ্যাপে একজন নির্দিষ্ট মালিক থাকা দরকার।

অগ্রাধিকার বদলালে সাপোর্ট লিড কেসটি পুনরায় অ্যাসাইন করতে পারেন, তবে রেকর্ডে বর্তমান মালিকের নাম দেখা চাই। কোনো কর্মী ফাইন্যান্স ফোল্ডারে অ্যাক্সেস চাইলে কেসটি service desk থেকে security approver-এর কাছে যেতে পারে। অনুরোধটি কোথায় গেল, তা কর্মীকে অনুমান করতে হওয়া উচিত নয়।

প্রতিটি কিউয়ের জন্য একজন ব্যাকআপ মালিক ঠিক করুন। নির্ধারিত সময়ের মধ্যে অ্যাসাইন করা ব্যক্তি কাজ না করলে ব্যাকআপ মালিক সতর্কবার্তা পাবেন এবং দায়িত্ব নেবেন কি না ঠিক করবেন। ছুটি, অসুস্থতা ও ব্যস্ত সময়ে এই নিয়ম কাজে আসে।

স্ট্যাটাস লেবেল একইভাবে ব্যবহার করুন

দীর্ঘ স্ট্যাটাস মেনু বিভ্রান্তি তৈরি করে। লেবেলগুলো সহজ রাখুন এবং প্রতিটির অর্থ স্পষ্ট করুন:

• New: দল অনুরোধ পেয়েছে, কিন্তু পর্যালোচনা করেনি।
• In progress: একজন মালিক সক্রিয়ভাবে কাজ করছেন।
• Waiting for requester: মালিকের তথ্য বা অনুমোদন দরকার।
• Waiting for another team: অন্য কারও ওপর কাজটি নির্ভর করছে।
• Closed: রিকোয়েস্টার ফলাফল বা স্পষ্ট চূড়ান্ত আপডেট পেয়েছেন।

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

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

AppMaster-এ এসব নিয়ম অ্যাপের মধ্যেই তৈরি করা যায়। ভিজ্যুয়াল ব্যবসায়িক প্রক্রিয়ায় কাজ শুরুর আগে মালিক বাধ্যতামূলক করা, বন্ধ করার আগে রিকোয়েস্টারকে আপডেট পাঠানো এবং মূল অ্যাসাইনি অনুপস্থিত হলে কেসটি ব্যাকআপ মালিকের কাছে পাঠানো সম্ভব।

লঞ্চের আগে দ্রুত যাচাই

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

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

সাধারণ অনুরোধের বিপরীতে অ্যাসাইনমেন্ট নিয়ম পরীক্ষা করুন। পাসওয়ার্ড রিসেট সরাসরি IT support-এ যেতে পারে, কিন্তু নতুন সফটওয়্যার লাইসেন্সে আগে অনুমোদন লাগতে পারে। ভুল কিউতে ঢোকা কেসের জন্য কর্মীদের একটি সহজ বিকল্প নিয়ম দিন।

প্রত্যেকের ভিউ পরীক্ষা করুন

কর্মীদের খোলা কেসের একটি স্পষ্ট তালিকা দরকার, যেখানে প্রতিটি রেকর্ড না খুলেই স্ট্যাটাস, মালিক, পাওয়ার তারিখ ও রিকোয়েস্টার দেখা যায়। দলের ব্যবহৃত ভাষার সঙ্গে মেলে এমন স্ট্যাটাস নাম ব্যবহার করুন, যেমন New, Waiting for requester, In progress এবং Closed।

অ্যাপের ইতিহাস দৃশ্যমান থাকা উচিত। যে কেউ কেসের দায়িত্ব নিলে আগের বার্তা, অনুমোদন ও স্ট্যাটাস পরিবর্তন দেখতে পাবেন। এতে নতুন প্রত্যেক ব্যক্তিকে একই সমস্যা আবার বলতে হয় না।

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

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

এই লঞ্চ যাচাই ব্যবহার করুন:

• স্বাভাবিক ও অস্বাভাবিক পরিস্থিতিসহ পাঁচটি পরীক্ষামূলক অনুরোধ জমা দিন।
• প্রত্যাশিত সময়ের মধ্যে প্রতিটি কেসে একজন মালিক ঠিক হচ্ছে কি না নিশ্চিত করুন।
• কর্মীদের ভিউতে New, In progress ও overdue কেস ফিল্টার করুন।
• রিকোয়েস্টার স্পষ্ট স্ট্যাটাস বার্তা পাচ্ছেন কি না দেখুন।
• ইমেলের অনুরোধ কীভাবে অ্যাপে নিতে হবে, সে বিষয়ে কর্মীদের একটি লিখিত নিয়ম দিন।

AppMaster ভিজ্যুয়াল ডেটা মডেল, রাউটিং লজিক এবং ওয়েব বা মোবাইল স্ক্রিনের মাধ্যমে এই ওয়ার্কফ্লো সমর্থন করে। দল প্রতি সপ্তাহে যে অনুরোধ পায়, প্রথম সংস্করণটি সেগুলোকে ভিত্তি করে তৈরি করুন। কয়েক দিন ব্যবহারের পর ফিল্ড ও নিয়ম ঠিক করুন।

পরবর্তী পদক্ষেপ বেছে নিন

এমন একটি শেয়ার করা অ্যালিয়াস দিয়ে শুরু করুন, যা নিয়মিত বিভ্রান্তি তৈরি করে। এর সঙ্গে এমন একটি অনুরোধের ধরন নিন, যার পথ স্পষ্ট, যেমন সফটওয়্যার অ্যাক্সেস, ইনভয়েসের প্রশ্ন বা সরঞ্জামের অনুরোধ। ছোট পরিসরের প্রথম লঞ্চে একসঙ্গে সব ইনবক্সে প্রভাব না ফেলে দল প্রক্রিয়াটি শিখতে পারে।

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

AppMaster-এর সাহায্যে দলগুলো কাস্টম কোড দিয়ে শুরু না করেই একটি নো-কোড কেস ম্যানেজমেন্ট অ্যাপ তৈরি করতে পারে। Data Designer দিয়ে কেস ও রিকোয়েস্টারের তথ্য মডেল করুন, তারপর Business Process Editor দিয়ে কাজ অ্যাসাইন ও স্ট্যাটাস পরিবর্তন করুন। ওয়েব বা মোবাইল স্ক্রিনে রিকোয়েস্টাররা নিজেদের কেসের অগ্রগতি দেখতে পারবেন।

প্রথম ওয়ার্কফ্লোতে ব্যবহারিক ফিল্ড রাখুন:

• অনুরোধের শিরোনাম ও বিবরণ
• রিকোয়েস্টারের নাম ও যোগাযোগের তথ্য
• অ্যাসাইন করা মালিক
• স্ট্যাটাস ও নির্ধারিত তারিখ, যদি দল এটি ব্যবহার করে
• রিকোয়েস্টার দেখতে পারবেন না এমন অভ্যন্তরীণ নোট

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

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

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