রেকর্ড অনুরোধ পোর্টাল: কার্যকর গোপনীয়তা নিয়ন্ত্রণ

রেকর্ডের অনুরোধে নিয়ন্ত্রিত প্রক্রিয়া কেন দরকার

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

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

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

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

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

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

কে রেকর্ড চাইতে ও দেখতে পারবেন তা নির্ধারণ করুন

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

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

ছোট টিমে একজনের একাধিক দায়িত্ব থাকতে পারে, তবে পোর্টালে তিনি কোন দায়িত্ব পালন করেছেন তা আলাদা করে নথিভুক্ত করুন। পরে পর্যালোচনা করা এতে অনেক সহজ হয়।

প্রতিনিধিদের জন্য সীমা নির্ধারণ করুন

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

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

সংবেদনশীল বিভাগ সীমিত করুন

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

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

কর্মীদের প্রয়োজনীয় তথ্যই সংগ্রহ করে এমন ফর্ম তৈরি করুন

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

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

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

কর্তৃত্ব নিশ্চিত করার মতো তথ্য সংগ্রহ করুন

রেকর্ডে যার নাম আছে তার সঙ্গে অনুরোধকারীর সম্পর্ক কী, তা জিজ্ঞেস করুন। একটি সহজ তালিকা ব্যবহার করা যায়:

• আমি নিজের রেকর্ড চাইছি
• আমি অভিভাবক বা আইনগত অভিভাবক
• রেকর্ডধারীর লিখিত অনুমতি আমার আছে
• আমি কোনো প্রতিষ্ঠান বা এস্টেটের প্রতিনিধিত্ব করছি

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

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

পরিচয়পত্র সতর্কতার সঙ্গে গ্রহণ করুন

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

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

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

অনুরোধের ওয়ার্কফ্লো তৈরি করুন

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

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

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

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

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

একটি সহজ ডকুমেন্ট অনুরোধের ধারা পাঁচ ধাপে হতে পারে:

1. পোর্টাল একটি গৃহীত অনুরোধ তৈরি করে এবং গ্রহণের নিশ্চয়তা পাঠায়।
2. নির্দিষ্ট কর্মী পরিচয় পরীক্ষা করে এবং ফলাফল অভ্যন্তরীণ নোটে লেখেন।
3. মালিক শেষ তারিখ ঠিক করেন, রেকর্ড খোঁজেন এবং প্রয়োজন হলে অনুমোদন চান।
4. অনুমোদিত উত্তর প্রস্তুত অবস্থায় যায়, তারপর নির্বাচিত নিরাপদ পদ্ধতিতে পাঠানো হয়।
5. মালিক সেটিকে পাঠানো হয়েছে হিসেবে চিহ্নিত করেন এবং ডেলিভারির তারিখ লেখেন।

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

অতিরিক্ত তথ্য প্রকাশ না করে পরিচয় যাচাই করুন

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

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

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

কর্মীদের জন্য একই যাচাইয়ের ধারা রাখুন

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

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

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

সাময়িক ফাইল নির্ধারিত সময়ে মুছে ফেলুন

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

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

AppMaster-এ অনুমতি ও স্ট্যাটাসের ধাপ ভিজ্যুয়ালি সাজানো যায়। পরিচয়ের প্রমাণ সঠিক কর্মীর কাছে পাঠিয়ে অনুমোদন না হওয়া পর্যন্ত চাওয়া রেকর্ড লক করে রাখা যায়।

সময়সীমা ও ডেলিভারি স্ট্যাটাস ট্র্যাক করুন

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

অনুরোধের প্রকৃত অবস্থা বোঝায় এমন স্ট্যাটাস ব্যবহার করুন। অস্পষ্ট «বন্ধ» লেবেল এড়িয়ে চলুন, কারণ এতে সব রেকর্ড পাঠানো হয়েছে কি না তা বোঝা যায় না।

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

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

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

টাইমলাইন অক্ষুণ্ণ রাখুন

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

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

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

উদাহরণ: একজন গ্রাহক নিজের রেকর্ডের কপি চাইছেন

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

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

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

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

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

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

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

ব্যক্তিগত তথ্য প্রকাশ করে এমন সাধারণ ভুল

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

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

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

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

অস্পষ্ট স্ট্যাটাসও বিলম্ব ঘটায়। «অপেক্ষমাণ» বললে পরের কাজ বা দায়িত্বপ্রাপ্ত ব্যক্তি বোঝা যায় না। কাজ ও মালিকের সঙ্গে যুক্ত স্ট্যাটাস ব্যবহার করুন:

• অনুরোধকারীর পরিচয়পত্র দেওয়ার অপেক্ষায়
• নির্দিষ্ট কর্মীর কাছে পরিচয় যাচাই বরাদ্দ
• নির্দিষ্ট তারিখের মধ্যে রেকর্ড অনুসন্ধান শেষ করতে হবে
• প্রকাশ অনুমোদনের অপেক্ষায়
• ডেলিভারির তারিখসহ পাঠানো হয়েছে

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

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

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

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

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

এই লঞ্চ চেকলিস্ট ব্যবহার করুন:

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

ডেলিভারির পথ পরীক্ষা করুন

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

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

কর্মীদের ভিউ পরীক্ষা করুন

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

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

পোর্টাল তৈরির পরবর্তী ধাপ

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

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

প্রথমে অল্প কয়েকটি স্ট্যাটাস রাখুন:

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

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

AppMaster-এ নো-কোড অ্যাপ হিসেবে রেকর্ড অনুরোধ পোর্টাল তৈরি করা যায়। Data Designer দিয়ে অনুরোধ, অনুরোধকারীর তথ্য, পরিচয় যাচাই, নথি ও স্ট্যাটাসের ইতিহাস নির্ধারণ করুন। web UI builder দিয়ে অনুরোধের ফর্ম ও কর্মীদের ভিউ বানান, তারপর Business Processes ব্যবহার করে কাজ বরাদ্দ, শেষ তারিখ নির্ধারণ, প্রবেশাধিকার সীমিত ও স্ট্যাটাস বার্তা পাঠান। AppMaster ব্যাকএন্ড, ওয়েব অ্যাপ ও সোর্স কোড তৈরি করতে পারে, যা AppMaster Cloud, AWS, Azure, Google Cloud বা আপনার নিজস্ব পরিবেশে স্থাপন করা যায়।

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

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