পুনরায় কাজ কমায় এমন ব্যবসায়িক ফর্মের ডেটা ভ্যালিডেশন নিয়ম

ব্যবসায়িক ফর্ম কেন পুনরায় কাজ তৈরি করে

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

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

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

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

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

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

মানুষের প্রয়োজনীয় তথ্য দিয়ে শুরু করুন

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

একটি গ্রাহক অনুরোধ ফর্ম সাপোর্ট টিমকে কাজ বরাদ্দ করতে, অগ্রাধিকার ঠিক করতে এবং গ্রাহকের সঙ্গে যোগাযোগ করতে সাহায্য করতে পারে। এতে গ্রাহকের নাম, যোগাযোগের একটি পদ্ধতি, অনুরোধের ধরন, পরিষ্কার বিবরণ এবং প্রয়োজনে অ্যাকাউন্ট নম্বর দরকার। «আপনি আমাদের কথা কোথা থেকে জেনেছেন?» প্রশ্নটি তখনই রাখুন, যখন টিম সেই উত্তর ব্যবহার করবে।

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

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

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

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

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

প্রয়োজনীয় ফিল্ড ভেবেচিন্তে নির্ধারণ করুন

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

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

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

ফিল্ডের কাছেই বৈধ এন্ট্রি কেমন হবে, তা জানান। ছোট একটি উদাহরণ এড়ানো যায় এমন ভুল কমায়:

• «কাজের ইমেইল (প্রয়োজনীয়): [email protected]»
• «অর্ডার নম্বর (প্রয়োজনীয়): রসিদে থাকা ৮ সংখ্যার নম্বর ব্যবহার করুন»
• «পছন্দের যোগাযোগের তারিখ (প্রয়োজনীয়): ভবিষ্যতের একটি তারিখ বেছে নিন»

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

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

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

পরস্পরবিরোধী তথ্য ধরতে একাধিক ফিল্ড যাচাই করুন

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

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

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

ডেলিভারির তথ্যও যাচাই করা দরকার। কেউ «গ্রাহকের ঠিকানায় পাঠান» বেছে নিলে সম্পূর্ণ ডেলিভারি ঠিকানা দিতে হবে। «গ্রাহক নিজে সংগ্রহ করবেন» বেছে নিলে ঠিকানাটি সরিয়ে দিন বা ঐচ্ছিক করুন। অপ্রাসঙ্গিক ফিল্ড বিভ্রান্তিকর ডেটা তৈরি করে।

কার্যকর পারস্পরিক যাচাইয়ের নিয়মের মধ্যে থাকতে পারে:

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

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

প্রতিটি যাচাইকে বাস্তব ব্যবসায়িক সিদ্ধান্তের সঙ্গে যুক্ত করুন। কোনো ব্যতিক্রম পরে কর্মীরা নিরাপদে সামলাতে পারলে ফর্ম আটকে দেবেন না। কিন্তু পরস্পরবিরোধী উত্তর ফেরত, কমপ্লায়েন্স সমস্যা বা অপ্রয়োজনীয় ফলো-আপ তৈরি করলে সাবমিশনের আগেই তা ধরুন।

ডুপ্লিকেট রেকর্ড ছড়িয়ে পড়ার আগেই বন্ধ করুন

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

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

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

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

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

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

AppMaster-এ Data Designer-এ ইউনিক ফিল্ড নির্ধারণ করে রেকর্ড তৈরি করার আগে মিল খোঁজার জন্য Business Process ব্যবহার করতে পারেন। এই প্রসেস ওয়েব বা মোবাইল ফর্মে সম্ভাব্য মিল দেখাতে পারে। ব্যবহারকারী পার্থক্য নিশ্চিত করার পর নতুন এন্ট্রি সংরক্ষণ করা যাবে। এতে সিদ্ধান্তটি স্পষ্ট থাকে এবং রেকর্ডসমূহও পরিচ্ছন্ন থাকে।

এমন সংশোধনের বার্তা লিখুন, যার ভিত্তিতে কাজ করা যায়

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

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

পরের কাজটি বোঝায় এমন সহজ ভাষা ব্যবহার করুন। «ERR-104» ধরনের অভ্যন্তরীণ কোড ডেভেলপারের কাজে লাগতে পারে, কিন্তু গ্রাহকের অনুরোধ লিখছেন এমন সেলস কো-অর্ডিনেটরের কোনো উপকার করে না।

• «কাজের ইমেইল লিখুন, যেমন [email protected]» লিখুন, «ভুল ইমেইল ফরম্যাট» নয়।
• «শেষ তারিখ শুরুর তারিখের সমান বা তার পরের হতে হবে» লিখুন, «তারিখের পরিসরে ত্রুটি» নয়।
• «এই ইমেইলসহ একজন গ্রাহক আগে থেকেই আছেন। নতুন রেকর্ড তৈরির আগে গ্রাহককে খুঁজুন» লিখুন, «ডুপ্লিকেট রেকর্ড» নয়।
• «০-এর বেশি একটি পরিমাণ লিখুন» লিখুন, «মান সীমার বাইরে» নয়।

ভালো বার্তা কাউকে দোষ না দিয়ে সমস্যাটি ব্যাখ্যা করে। «অ্যাকাউন্ট নম্বরে ৮টি সংখ্যা দরকার বলে আমরা আপনার অনুরোধটি সংরক্ষণ করতে পারিনি» বাক্যটি «আপনি ভুল অ্যাকাউন্ট নম্বর দিয়েছেন» এর চেয়ে পরিষ্কার।

ফর্মে ত্রুটি ধরা পড়লেও বৈধ এন্ট্রিগুলো রেখে দিন। কেউ ১৪টি ফিল্ড পূরণ করলে শুধু যে ফিল্ডটি ব্যর্থ হয়েছে সেটিই সংশোধন করতে হবে। ভ্যালিডেশন ত্রুটির পর পুরো পৃষ্ঠা খালি করে দিলে ২০ সেকেন্ডের সংশোধন বারবারের কাজে পরিণত হয়।

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

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

ধাপে ধাপে ভ্যালিডেশন নিয়ম তৈরি করুন

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

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

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

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

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

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

যে ভুলগুলো ফর্ম ব্যবহারকারীদের বিরক্ত করে

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

প্রতিটি ফিল্ড বাধ্যতামূলক করা

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

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

নির্দেশনা না দিয়ে মানুষকে থামানো

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

«কাজের ইমেইল ঠিকানা লিখুন, যেমন [email protected]» লিখুন, «ইমেইল ত্রুটি» নয়। শেষ তারিখ শুরুর তারিখের আগে হলে বলুন, «শুরুর তারিখের সমান বা তার পরের একটি শেষ তারিখ বেছে নিন।» এ ধরনের নির্দেশনা বারবার চেষ্টা এবং সাপোর্টের অনুরোধ কমায়।

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

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

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

প্রকাশের আগে দ্রুত যাচাই

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

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

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

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

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

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

ব্যর্থ পরীক্ষাগুলো লিখে রেখে প্রকাশের আগে ঠিক করুন। বাস্তবসম্মত পরীক্ষায় দশ মিনিট ব্যয় করলে ফর্ম চালু হওয়ার পর ঘণ্টার পর ঘণ্টা পরিষ্কার করার কাজ বাঁচতে পারে।

উদাহরণ: একটি গ্রাহক অনুরোধের ফর্ম

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

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

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

ফর্মটি গ্রাহকের রেকর্ড তৈরি করার আগে ডুপ্লিকেট শনাক্তকরণে কোম্পানির নাম, ইমেইল ডোমেইন এবং ফোন নম্বর বিদ্যমান রেকর্ডের সঙ্গে মিলিয়ে দেখা হয়। একই প্রধান ফোন নম্বরসহ «Northline Food Ltd» পাওয়া যায়। ফর্মে বিদ্যমান গ্রাহক দেখানো হয় এবং কো-অর্ডিনেটরকে সেই রেকর্ড খুলে অনুরোধ যোগ করা, অথবা এটি ভিন্ন আইনি সত্তা বা যোগাযোগ নম্বরসহ নতুন গ্রাহক বলে নিশ্চিত করার সুযোগ দেওয়া হয়।

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

আপনার পরের ফর্মে আরও ভালো ভ্যালিডেশন যোগ করুন

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

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

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

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

বাস্তব ব্যবসায়িক ব্যতিক্রমের দিকে নজর রাখুন। অনুমোদিত কিছু গ্রাহকের জন্য খালি ক্রয় অর্ডার নম্বর গ্রহণযোগ্য হতে পারে। পরে কর্মীদের হাতে হাতে রেকর্ড সম্পাদনা করতে বাধ্য না করে ওই গ্রুপের জন্য দৃশ্যমান ব্যতিক্রমের পথ দিন।

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

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