স্ক্রিন ডিজাইনের আগে কাস্টমার রিকোয়েস্ট লাইফসাইকেল ম্যাপ করুন

রিকোয়েস্টের মানচিত্র ছাড়া স্ক্রিন কেন ব্যর্থ হয়

দৃষ্টিনন্দন রিকোয়েস্ট ফর্মও একটি বিশৃঙ্খল প্রসেস তৈরি করতে পারে। টিমগুলো প্রায়ই আগে ফিল্ড, বোতাম এবং ড্যাশবোর্ড বেছে নেয়। পরে বুঝতে পারে, কাস্টমার «Submit» চাপার পর কী হবে, তা নিয়ে কেউ একমত নয়।

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

ধরা যাক, একটি সাপোর্ট ফর্মে «In progress» নামে একটি স্টেট আছে। এর অর্থ কি কেউ রিকোয়েস্টটি পড়েছে, কাউকে দায়িত্ব দিয়েছে, কাস্টমারের সঙ্গে যোগাযোগ করেছে, নাকি আসল কাজ শুরু করেছে? কর্মীরা একই লেবেল ভিন্ন অর্থে ব্যবহার করতে পারে। কাস্টমার খুব কম অগ্রগতি দেখতে পায়, আর ম্যানেজাররা বুঝতে পারেন না রিকোয়েস্ট কোথায় আটকে আছে।

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

ইন্টারফেস ডিজাইনের আগে রিকোয়েস্ট ওয়ার্কফ্লো ম্যাপিং করলে এসব ফাঁক ধরা পড়ে। টিমকে সিদ্ধান্ত নিতে হবে:

• রিকোয়েস্ট শুরু করতে কী তথ্য দরকার?
• পরবর্তী কাজের মালিক কে?
• প্রতিটি সিদ্ধান্তের পর কোন কোন স্টেট আসতে পারে?
• সময়সীমা কখন শুরু, বিরতি বা শেষ হবে?
• রিকোয়েস্ট বদলালে কাকে নোটিফিকেশন দিতে হবে?

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

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

একটি রিকোয়েস্ট এবং পরিষ্কার ফলাফল দিয়ে শুরু করুন

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

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

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

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

একটি সংক্ষিপ্ত সংজ্ঞা ডিজাইন শুরুর আগেই অনুপস্থিত নিয়ম বের করে আনতে পারে:

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

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

শুরু এবং শেষ নির্দিষ্ট হয়ে গেলে টিম অনুমান না করেই স্টেট, মালিক, সময়সীমা এবং নোটিফিকেশন যোগ করতে পারে। পরে AppMaster এই মানচিত্রকে ব্যবসায়িক প্রসেস এবং স্ক্রিনে রূপ দিতে পারে, তবে কাজের সংজ্ঞা আগে মানচিত্রেই থাকতে হবে।

একটি রিকোয়েস্ট কোন কোন স্টেটে যেতে পারে, তা লিখুন

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

একটি সাধারণ সাপোর্ট বা সার্ভিস রিকোয়েস্টে এমন স্টেট থাকতে পারে:

• New: সিস্টেম রিকোয়েস্ট পেয়েছে, কিন্তু কেউ তা পর্যালোচনা করেনি।
• In review: একজন টিম সদস্য তথ্য যাচাই করে কীভাবে কাজটি সামলানো হবে, তা ঠিক করছেন।
• Waiting for customer: টিম কাস্টমারের কাছ থেকে উত্তর, ফাইল বা নিশ্চিতকরণ চায়।
• In progress: কেউ কাজটি গ্রহণ করে এগিয়ে নিচ্ছেন।
• Waiting for approval or external work: অগ্রগতি ম্যানেজার, সরবরাহকারী, পেমেন্ট প্রোভাইডার বা অন্য কোনো পক্ষের ওপর নির্ভর করছে।
• Resolved: টিম চাওয়া কাজটি শেষ করেছে।
• Closed: কাস্টমার ফলাফল গ্রহণ করেছেন, অথবা নির্ধারিত সময়ের পর টিম রিকোয়েস্ট বন্ধ করেছে।

মানুষ আগে থেকেই যে ভাষা ব্যবহার করে, তার সঙ্গে মিল রেখে নাম বেছে নিন। «Waiting for customer» «Pending input»-এর চেয়ে পরিষ্কার। «In progress» সাধারণত «Active»-এর চেয়ে সহজবোধ্য। পোর্টালে দেখানো স্টেট বুঝতে কাস্টমারের কোনো অভ্যন্তরীণ শব্দকোষের দরকার হওয়া উচিত নয়।

অপেক্ষার স্টেটগুলো বিশেষ যত্ন দাবি করে। এগুলো দেখায় কোন কাজ টিম আজ করতে পারে এবং কোন কাজ অন্য কারও ওপর নির্ভর করছে। রিফান্ড রিকোয়েস্টে রসিদ চাওয়ার সময় «In review» থেকে «Waiting for customer» স্টেটে যাওয়া যেতে পারে। আবার অর্থের পরিমাণ অনুমোদনের জন্য ফাইন্যান্স ম্যানেজারের প্রয়োজন হলে এটি «Waiting for approval» হবে। এই দুই ধরনের বিলম্বে আলাদা রিমাইন্ডার ও সময়সীমার নিয়ম দরকার।

একই অর্থের একাধিক লেবেল রাখবেন না। «Open», «Assigned» এবং «Being handled» প্রায়ই একই সাধারণ পরিস্থিতি বোঝায়। প্রতিটি লেবেল মালিক, কর্মীর কাজ বা প্রযোজ্য সময়সীমা বদলালে তবেই আলাদা স্টেট রাখুন। কম কিন্তু পরিষ্কার স্টেট ও ট্রানজিশন রিপোর্টকে আরও বিশ্বাসযোগ্য করে।

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

ট্রানজিশন আঁকুন এবং কে তা শুরু করে, তা লিখুন

শুধু স্টেটের নাম দিয়ে ওয়ার্কফ্লো বোঝানো যায় না। রিকোয়েস্ট কীভাবে বদলাবে, কে বদলাতে পারবে এবং তার আগে কোন শর্ত পূরণ হতে হবে, তা লিখুন। এতে ভুল সময়ে কোনো স্ক্রিনের বোতাম চাপলে রিকোয়েস্ট বদলে যাওয়ার ঝুঁকি কমে।

প্রতিটি ট্রানজিশন সহজ একটি বাক্যে লিখুন। যেমন: «কাস্টমার অর্ডার নম্বর দিয়েছেন কি না যাচাই করার পর সাপোর্ট এজেন্ট রিকোয়েস্টটি New থেকে In review-এ নেন।» এতে কাজ, ব্যক্তি এবং শর্ত তিনটিই থাকে।

একটি সাধারণ মানচিত্রে এমন পরিবর্তন থাকতে পারে:

• কাস্টমার রিকোয়েস্ট পাঠান, ফলে একটি New রিকোয়েস্ট তৈরি হয়।
• সাপোর্ট এজেন্ট এটি একজন বিশেষজ্ঞকে দেন এবং In review স্টেট করেন।
• তথ্য অনুপস্থিত থাকলে বিশেষজ্ঞ এটি Waiting for customer করেন।
• কাস্টমারের উত্তর এলে এটি আবার In review-এ ফেরে।
• কাজ শেষ হলে বিশেষজ্ঞ এটিকে Resolved করেন।
• নিশ্চিতকরণের পর কাস্টমার বা সাপোর্ট লিড রিকোয়েস্টটি Closed করেন।

প্রতিটি তীরের জন্য অনুমোদিত ব্যক্তির ভূমিকা লিখুন। «টিম» খুব অস্পষ্ট। customer, support agent, billing specialist, team lead বা automation-এর মতো ভূমিকা ব্যবহার করুন। সিস্টেমের নিয়মও কোনো পরিবর্তন শুরু করতে পারে। যেমন, নীতির সঙ্গে মিললে ১৪ দিন কোনো উত্তর না এলে automation Waiting for customer থেকে Closed-এ নিতে পারে।

ব্যতিক্রমের জন্য আলাদা ট্রানজিশন দরকার। কাস্টমার New রিকোয়েস্ট বাতিল করতে পারেন, কিন্তু ইতিমধ্যে সম্পূর্ণ হওয়া রিকোয়েস্ট নয়। সমস্যা ফিরে এলে টিম লিড Closed রিকোয়েস্ট আবার খুলতে পারেন। ভুল করে কাউকে দায়িত্ব দেওয়া হলে এজেন্ট In review থেকে New-এ নিতে পারেন। এই নিয়মগুলো মালিকানা রক্ষা করে এবং কেন কিছু স্টেট পরিবর্তন করা যায় না, তা পরিষ্কার করে।

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

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

প্রতিটি হ্যান্ডঅফের জন্য মালিক নির্ধারণ করুন

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

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

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

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

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

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

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

অ্যাপে ওয়ার্কফ্লো তৈরি করার সময় স্টেট ট্রানজিশনের মধ্যেই মালিকানা পরিবর্তন রাখুন। AppMaster একই ব্যবসায়িক প্রসেসে স্টেট পরিবর্তন, অ্যাসাইনমেন্ট নিয়ম এবং অডিট রেকর্ড যুক্ত করতে পারে। টিম বড় হওয়ার সঙ্গে মালিকানা পরিষ্কার রাখতে এটি সাহায্য করে।

কাজের সঙ্গে মিল রেখে সময়সীমা নির্ধারণ করুন

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

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

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

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

সময়সীমার কাছাকাছি যাওয়ার আগেই এসকেলেশন রাখুন। অনুমোদিত সময়ের ৭৫ শতাংশ পার হলে মালিককে রিমাইন্ডার দিলে কাজ করার সুযোগ থাকে। ৯০ শতাংশে তার ম্যানেজার বা পরবর্তী দায়িত্বশীল টিমকে জানান। সময়সীমা পেরিয়ে গেলে রিকোয়েস্টকে overdue করুন এবং পরবর্তী কাজ লিখুন।

একটি সহজ নীতি এমন হতে পারে:

• কাস্টমার রিকোয়েস্ট জমা দিলে সাড়া দেওয়ার সময় গণনা শুরু হবে।
• টিম নির্দিষ্ট প্রশ্ন করে রিকোয়েস্টকে Waiting for customer করলে সম্পূর্ণ করার সময় থামবে।
• কাস্টমার উত্তর দিলে সময় আবার শুরু হবে এবং রিকোয়েস্ট বর্তমান মালিকের কাছে ফিরবে।
• সময়সীমা ঘনিয়ে এলে মালিক রিমাইন্ডার পাবেন, তারপর ম্যানেজার এসকেলেশন পাবেন।
• সময়সীমা পেরিয়ে গেলে ম্যানেজার পুনরুদ্ধার পরিকল্পনা তৈরি করবেন এবং কাস্টমারকে আপডেট দেবেন।

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

অতিরিক্ত শব্দ তৈরি না করে নোটিফিকেশন পরিকল্পনা করুন

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

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

অভ্যন্তরীণ অ্যালার্টেরও একজন প্রাপক এবং কাজ করার কারণ থাকা দরকার। রিকোয়েস্ট «Needs review»-এ গেলে রিভিউয়ারকে জানান। কাস্টমার প্রশ্নের উত্তর দিলে ফলো-আপের দায়িত্বে থাকা ব্যক্তিকে জানান। দুই ক্ষেত্রেই পুরো টিমকে অ্যালার্ট দেওয়ার দরকার নেই।

বার্তা সহজ ও নির্দিষ্ট রাখুন। রিকোয়েস্টের নাম বা নম্বর, বর্তমান স্টেট এবং পরবর্তী কাজ লিখুন। যেমন:

• কাস্টমার: «আমরা আপনার equipment request #1842 পেয়েছি। মঙ্গলবারের মধ্যে এটি পর্যালোচনা করব।»
• রিভিউয়ার: «Request #1842-এর অনুমোদন মঙ্গলবার বিকেল ৩টার মধ্যে দরকার।»
• কাস্টমার: «আপনার request #1842 অনুমোদিত হয়েছে। আমাদের টিম ডেলিভারি নির্ধারণ করে শুক্রবারের মধ্যে আপনাকে জানাবে।»

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

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

একটি সাধারণ কাস্টমার রিকোয়েস্ট অনুসরণ করুন

একজন কাস্টমার সাপোর্ট ফর্মে একই চার্জ দুবার হওয়ার কথা জানালেন। ফর্মটি #4821 নম্বরের একটি রিকোয়েস্ট তৈরি করল, স্টেট হলো «New» এবং এটি সাপোর্ট কিউতে বরাদ্দ হলো। কাস্টমার সঙ্গে সঙ্গে রিকোয়েস্ট নম্বরসহ একটি নিশ্চিতকরণ পেলেন, যেখানে বলা হলো টিম এক কর্মদিবসের মধ্যে কেসটি পর্যালোচনা করবে।

একজন সাপোর্ট এজেন্ট রিকোয়েস্ট খুলে অর্ডার ও পেমেন্ট রেকর্ড দেখলেন, তারপর স্টেট «In review» করলেন। রিকোয়েস্টের মালিক হলেন এজেন্ট। পেমেন্ট রেকর্ডে যথেষ্ট তথ্য না থাকলে এজেন্ট «Waiting for customer» বেছে নিয়ে ব্যাংক স্টেটমেন্টের স্ক্রিনশট বা কার্ডের শেষ চারটি সংখ্যা চাইবেন।

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

কাস্টমার উত্তর দিলে রিকোয়েস্ট আবার «In review»-এ ফিরবে এবং সম্ভব হলে একই এজেন্টের কাছে যাবে। ধারাবাহিকতা গুরুত্বপূর্ণ, কারণ নতুন এজেন্টকে একই প্রশ্ন আবার করতে হওয়া উচিত নয়।

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

ফাইন্যান্স রিভিউয়ার সিদ্ধান্ত রেকর্ড করবেন। অনুমোদিত রিকোয়েস্ট «Refund processing»-এ যাবে, যেখানে পেমেন্ট টিম রিফান্ড দিয়ে তার রেফারেন্স নম্বর লিখবে। প্রত্যাখ্যাত রিকোয়েস্ট কারণসহ সাপোর্টে ফিরবে, যাতে এজেন্ট তা পরিষ্কারভাবে ব্যাখ্যা করতে পারেন।

টিম রিফান্ড দেওয়ার পর বা প্রত্যাখ্যানের কারণ ব্যাখ্যা করার পরই সাপোর্ট চূড়ান্ত বার্তা পাঠাবে। এরপর এজেন্ট স্টেট «Closed» করবেন। কাস্টমার ফলাফলসহ বন্ধ হওয়ার নোটিশ পাবেন, আর টিম প্রতিটি মালিক, সিদ্ধান্ত, সময়সীমা এবং বার্তার রেকর্ড রাখবে।

এই মানচিত্র একটি সাধারণ ফাঁক ঠেকায়: এক স্ক্রিনে রিকোয়েস্ট শেষ মনে হলেও অন্য টিমের কিউতে কাজের অপেক্ষায় পড়ে থাকা।

ওয়ার্কফ্লোকে বিভ্রান্ত করে এমন সাধারণ ভুল

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

অস্পষ্ট লেবেলের বদলে অপেক্ষার কারণ বোঝায় এমন স্টেট ব্যবহার করুন। «Waiting for customer details» রিকোয়েস্টদাতাকে বলে কী করতে হবে। «Waiting for manager approval» ম্যানেজারকে বলে কী কারণে অগ্রগতি আটকে আছে। টিম যদি বলতে না পারে পরবর্তী কাজ কে করবেন, স্টেটের নাম বদলান বা সেটি বাদ দিন।

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

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

কোনো স্টেট দরকারি শোনাচ্ছে বলে শুধু তার জন্য স্ক্রিন তৈরি করবেন না। প্রতিটি স্ক্রিনের একটি পরিষ্কার কাজ, সিদ্ধান্ত বা হ্যান্ডঅফকে সহায়তা করা উচিত। «Quality review» স্ক্রিন তখনই যুক্তিসঙ্গত, যখন কেউ নির্দিষ্ট মানদণ্ড যাচাই করে রিকোয়েস্ট অনুমোদন বা কারণসহ ফেরত দেন। টিম যদি সেই কাজ সহজ ভাষায় ব্যাখ্যা করতে না পারে, অনিশ্চয়তা লুকিয়ে নতুন পেজ যোগ না করে স্টেটটি বাদ দিন।

স্ক্রিন ডিজাইনের আগে লাইফসাইকেলের প্রতিটি অংশে চারটি প্রশ্ন করুন:

• এই স্টেটের সঠিক অর্থ কী?
• এখানে থাকাকালীন রিকোয়েস্টের মালিক কে?
• কোন ঘটনা এটিকে পরবর্তী স্টেটে নিয়ে যায়?
• সময়সীমা পেরিয়ে গেলে কী হয়?

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

স্ক্রিন ডিজাইনের আগে দ্রুত যাচাই করুন

UI builder খোলার আগে একটি সাধারণ পর্যালোচনায় রিকোয়েস্টের মানচিত্র টিকে থাকা উচিত। ব্যস্ত মঙ্গলবারে বাস্তব একটি রিকোয়েস্ট সামলানো কর্মীর দৃষ্টিতে এটি পড়ুন। এরপর কী হবে, তা না বুঝলে কোনো স্ক্রিন সেই ফাঁক পূরণ করতে পারবে না।

প্রতিটি স্টেটের একটি পরিষ্কার কাজ এবং অন্তত একটি বের হওয়ার পথ দিন। «Waiting for customer» মানে টিমের তথ্য দরকার। তাই কাস্টমার উত্তর দিলে, বাতিল করলে বা নির্ধারিত সময়ে উত্তর না দিলে এটি অন্য স্টেটে যাওয়া উচিত। «In progress»-এর মতো সাধারণ অনুভূতি বোঝানো স্টেট এড়িয়ে চলুন, যদি না টিম জানে সেখানে ঠিক কী কাজ হয়।

প্রতিটি ট্রানজিশন দেখে প্রশ্ন করুন, কী তা শুরু করে এবং কে করতে পারে। উত্তর পাঠানোর পর সাপোর্ট এজেন্ট রিকোয়েস্টকে resolved করতে পারেন। কাস্টমার এটি আবার খুলতে পারেন। ১৪ দিন উত্তর না এলে সিস্টেম নিয়ম এটি বন্ধ করতে পারে। এই অনুমতিগুলো লিখে রাখুন, যাতে কেউ ভুল করে রিকোয়েস্ট পরিবর্তন না করেন।

এই তালিকা ব্যবহার করুন:

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

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

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

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

মানচিত্রকে একটি অ্যাপে রূপ দিন

কাস্টমার রিকোয়েস্ট লাইফসাইকেল পরিষ্কার হলে মানচিত্রের প্রতিটি অংশের অ্যাপে সরাসরি জায়গা হয়। স্টেট একটি status field হবে। মালিক assigned user বা team হবে। সময়সীমা date and time field হবে। ট্রানজিশন «Assign», «Ask for details», «Resolve» এবং «Reopen»-এর মতো অ্যাকশনে রূপ নেবে।

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

ওয়ার্কফ্লো শুধু লেবেল দেখাবে না, অ্যাকশন নিয়ন্ত্রণ করবে। সাপোর্ট এজেন্ট রিকোয়েস্টকে «New» থেকে «In review» করতে পারেন। শুধু নির্ধারিত resolver এটি «Resolved» করতে পারবেন। সমাধানের পর কাস্টমার উত্তর দিলে অ্যাপ রিকোয়েস্ট আবার খুলে উপযুক্ত কিউতে পাঠাতে পারে।

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

সেই মতামত দিয়ে স্ক্রিনের পাশাপাশি মানচিত্রও ঠিক করুন। দুই টিমের মধ্যে হ্যান্ডঅফ বিভ্রান্তিকর হলে «Waiting for approval»-এর মতো স্টেট দরকার হতে পারে। কোনো রিকোয়েস্ট বেশি সময় পড়ে থাকলে আরও পরিষ্কার নির্ধারিত তারিখ বা মালিকের জন্য রিমাইন্ডার দরকার হতে পারে। প্রতিটি ছোট কাজ বোঝাতে নতুন স্টেট যোগ করবেন না। অতিরিক্ত বিকল্প ওয়ার্কফ্লো অনুসরণ করা কঠিন করে।

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

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