১০ আগ, ২০২৫·7 মিনিট পড়তে

ছোট দলের জন্য সহজে রাখার উপযোগী হালকা CRM স্কিমা

Q: What fields should be required on Contacts, Organizations, and Deals?

Keep required fields minimal: an ID, a name, and `created_at` for contacts and organizations, plus core deal fields like stage, owner, value, and close date. Optional fields are fine, but too many required inputs lead to junk values like “N/A.”

Q: Should calls, meetings, notes, and tasks be separate tables?

Use one Activity table with a small fixed `type` set like call, email, meeting, note, task. This makes “last touched,” overdue work, and activity history consistent because everything shares the same timestamps and structure.

Q: Why do I need both due_at and completed_at on activities?

Store both `due_at` and `completed_at` because they answer different questions. `due_at` is for planning and overdue reports, while `completed_at` is for execution and cycle-time analysis; combining them makes both reports unreliable.

একটি হালকা CRM স্কিমা তৈরি করুন যা Contacts, Deals, Activities, এবং permissions সহজ রাখে—তবুও নির্ভরযোগ্য রিপোর্টিং এবং দৈনন্দিন ওয়ার্কফ্লো সমর্থন করে।

এই CRM স্কিমা কোন সমস্যা সমাধান করবে

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

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

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

এই স্কিমা চারটি মূল অবজেক্টে আটকে আছে যা বেশিরভাগ ছোট টিমের CRM কভার করে আবার জটিলও হয় না:

Contacts (এবং অপশনাল Organization) — যাদের সাথে আপনি কথা বলেন
Deals — সেই সুযোগগুলো যা আপনি পাইপলাইনের মাধ্যমে ট্র্যাক করেন
Activities — টাস্ক, মিটিং, কল, এবং নোটের জন্য একক লগ
Permissions — কে কী দেখবে এবং কী সম্পাদনা করতে পারবে সেই প্র্যাকটিক্যাল নিয়ম

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

আপনি যদি AppMaster (appmaster.io) মতো নো-কোড টুলে একটি অভ্যন্তরীণ CRM বানান, এই পদ্ধতিটি ডাটাবেস ছোট রাখে আবার ড্যাশবোর্ড ও সাপ্তাহিক রিভিউর জন্য স্থিতিশীল সংখ্যা দেয়।

হালকা রেখে বন্দী না হওয়ার জন্য নীতিগুলো

একটি হালকা CRM স্কিমা তখনই কাজ করে যখন এটি একটি প্রশ্ন সোজাসাপ্টা উত্তর দেয়: এই তথ্যের সঠিক স্থান কোথায়? যদি একই "সত্য" দুই জায়গায় রাখা যায়, সেটা করা হবে এবং আপনার রিপোর্টগুলি বিকৃত হবে।

কিছু সোর্স-অফ-ট্রুথ অবজেক্ট বেছে নিন এবং বাকিটা সেগুলোর দিকে নির্দেশ করুন। বেশিরভাগ ছোট টিমের জন্য তা হল Contacts, Organizations (ঐচ্ছিক), Deals, এবং Activities। যখন আরও বিশদ প্রয়োজন হবে, একটি নতুন টেবিল যোগ করুন, একটি টেক্সট ফিল্ডে সবকিছু চাপাতে গিয়ে সেটি জাঙ্ক ড্রয়ার না বানান।

কয়েকটি নিয়ম মডেলকে সহজ ও নমনীয় রাখে:

এক তথ্য, এক বাড়ি: ফোন নম্বর Contact-এ থাকে, ডিলের মান Deal-এ থাকে।
ওভারলোডেড ফিল্ডের বদলে স্পষ্ট টেবিল ভালো: স্টেজ ইতিহাস comma-separated স্ট্রিং নয়।
আইডি স্থায়ী রাখুন, নাম সম্পাদনীয় রাখুন: মানুষ কোম্পানি রিনেম করে, প্রাইমারি কী বদলে না।
“স্ট্যাটাস” কে “টাইপ” থেকে আলাদা করুন: একটি টাস্ক একই সময়ে “open” এবং “call” হতে পারে।
ইম্পোর্ট মিশ্র হবে ধরে নিন: ফাঁকা, ডুপ্লিকেট, এবং অদ্ভুত ফরম্যাটিং স্বাভাবিক।

কাজ শুরুতেই ঝামেলা কমাতে কয়েকটি সাধারণ কিন্তু শক্তিশালী ফিল্ড যোগ করুন: created_at, updated_at, এবং একটি সাধারণ external_id (বা import_source + import_key) আপনার মূল টেবিলগুলোতে। এটি আপনাকে পুনরায় ইম্পোর্ট করার সময় ডুপ্লিকেট তৈরি না করে নিরাপদ উপায় দেয়।

একটি বাস্তব উদাহরণ: আপনি যদি একটি স্প্রেডশিট ইম্পোর্ট করেন যেখানে “Acme Inc.” অর্ধেক সারিতে “ACME” হিসেবে আছে, যদি Organization.name সম্পাদনীয় এবং Organization.id স্থায়ী হয়, তাহলে পরে রেকর্ডগুলো মিশিয়ে ফেলতে পারবেন বিনা ভাঙচুরে—অর্থাৎ ডিল ও অ্যাক্টিভিটিগুলো অক্ষত থাকবে।

Contacts এবং Organizations: কাজ করা সবচেয়ে সহজ স্ট্রাকচার

একটি হালকা CRM স্কিমা দিয়ে শুরু করার এক সিদ্ধান্ত হল: আপনি কি শুধু মানুষ ট্র্যাক করবেন, নাকি মানুষ প্লাস কোম্পানিও? আপনার দল যদি ব্যবসায় বিক্রি করে (B2B), তাহলে সাধারণত Contact (ব্যক্তি) এবং Organization (কোম্পানি) উভয়ই রাখা উচিত। যদি আপনি কনজিউমারদের কাছে বিক্রি করেন, তবে Organizations বাদ দিয়ে প্রতিটি রেকর্ডকে Contact হিসেবে রাখুন।

B2B সেটআপের জন্য সম্পর্ক সহজ রাখুন: প্রতিটি contact একটি primary organization-এ (nullable) থাকে এবং একটি organization-এ অনেক contact থাকতে পারে। এটি বেশিরভাগ ছোট-টিমের কাজকেই কভার করে, জটিল একাউন্ট হায়ারার্কিতে ঠেলে দেয় না।

আবশ্যক ফিল্ডগুলো হালকা রাখুন

খুব বেশি ফিল্ড বাধ্যতামূলক করলে ডেটা দ্রুত বিশৃঙ্খল হয়। একটি ভালো বেসলাইন হল:

Contact: id, name (বা first_name + last_name), created_at
Organization: id, name, created_at

অন্য সব (জব টাইটেল, ওয়েবসাইট, ঠিকানা, ইন্ডাস্ট্রি, সোর্স) অপশনাল হতে পারে। পরে নিয়ম যোগ করা যায়, কিন্তু "N/A" মতো প্লেসহোল্ডারগুলো দিয়ে ডেটাবেস পরিষ্কার করা কঠিন।

ইমেইল এবং ফোন: ব্যথা না বাড়িয়ে ইউনিকনেস

ইমেইল ইউনিক করা tempting। এটি B2C-র জন্য বা সেই CRM-কে লগইন সিস্টেম হিসেবেই ব্যবহার করলে ভালো কাজ করে। ছোট B2B টিমে শেয়ার্ড ইনবক্স (sales@, info@) এবং পুনর্ব্যবহৃত ফোন নাম্বার সাধারণ। কঠোর ইউনিকনেস নিয়ম বাস্তব রেকর্ড ব্লক করতে পারে।

একটি বাস্তবসম্মত সমাধান:

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

আপনি যদি একাধিক ইমেইল বা ফোন সংরক্ষণ করতে চান, email_2 বা phone_3 মতো কলাম তৈরির বদলে একটি আলাদা টেবিল ব্যবহার করুন (উদাহরণ: ContactMethod যেখানে type, value, is_primary)। রিপোর্টিং পরিষ্কার থাকবে এবং মডেল স্বাভাবিকভাবে স্কেল করবে।

উদাহরণ: দলের একজন Pat-এর সাথে দেখা করে, যিনি কোয়ার্টারের মাঝামাঝি কাজ বদলান। Contact যদি Organization-এ লিঙ্ক থাকে, আপনি Pat-কে নতুন কোম্পানিতে সরাতে পারবেন, পুরনো contact methods ইতিহাস হিসেবে রাখতে পারবেন, এবং আপনার রিপোর্ট কোম্পানি অনুযায়ী ডিলগুলো ঠিকভাবে গণনা করবে।

Deals এবং পাইপলাইন: এমন স্ট্রাকচার যা পড়তে সহজ থাকে

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

শুরু করুন এমন ফিল্ড দিয়ে যেগুলো টিমের যে কাউকে বোঝানো যায়:

Deal name: একটি সংক্ষিপ্ত লেবেল যা লিস্টে অর্থ দেয়
Stage: পাইপলাইন স্টেজের রেফারেন্স (হাতে টাইপ করা নয়)
Value: প্রত্যাশিত পরিমাণ (একটি সিস্টেমব্যাপী মুদ্রা বেছে নিন)
Owner: যে ব্যক্তি এটি এগিয়ে নিয়ে যাওয়ার জন্য দায়ী
Close date: বন্ধ হওয়ার বর্তমান সেরা অনুমান

রিলেশনশিপের জন্য, ডিলের উপর একটি primary contact বেছে নিন। এতে রিপোর্টিং সরল থাকে (যেমন, কনট্যাক্ট অনুযায়ী রাজস্ব, সেগমেন্ট অনুযায়ী জেতার হার)। যদি মাঝে মাঝে আরও লোকের দরকার হয়, একটি deal_contacts টেবিল যোগ করুন যাতে অতিরিক্ত কন্ট্যাক্ট যুক্ত করা যায়—প্রতিটি ডিলকে শুরু থেকেই জটিল many-to-many না বানিয়েই। বেশিরভাগ ছোট টিম 1 primary contact এবং ঐচ্ছিক অংশগ্রহণকারীদের নিয়ে ভালো চলে।

স্টেজই সেই জায়গা যেখানে CRM-গুলো প্রায়শই গণ্ডগোল হয়। স্টেজকে ফ্রি টেক্সট হিসেবে সংরক্ষণ করবেন না। স্টেজগুলোকে রেফারেন্স ডেটা হিসেবে রাখুন যাতে পরে স্টেজের নাম পরিবর্তন করলে রিপোর্ট ভাঙে না। একটি মিনিমাম স্টেজ টেবিলে থাকতে পারে:

stage_id
pipeline_id
stage_name
stage_order
is_closed (বা জেতা ও হারানো আলাদা ফ্ল্যাগ)

আপনার দল ছোট হলে, "lead" এবং "deal" বিভক্ত করে ফেলবেন না যদি না আপনি সত্যিই ভিন্নভাবে লিড ম্যানেজ করেন। একটি সহজ নিয়ম কাজ করে: যখন আপনার কাছে বাস্তব সুযোগ আছে ট্র্যাক করার মতো, সেটি একটি deal। এর আগ পর্যন্ত এটিকে একটি contact হিসেবে রাখুন যার স্ট্যাটাস হতে পারে “new” বা “nurture”। এতে পাইপলাইন পড়তে সহজ থাকে এবং আড়ম্বরহীন ডিল সংখ্যা পাল্টা যাবে না।

উদাহরণ: দুই-ব্যক্তির সেলস টিম "Acme Renewal" নামে একটি ডিল ট্র্যাক করে, মালিক Sam, স্টেজ "Proposal Sent", ভ্যালু 12,000, ক্লোজ ডেট আগামী মাসে। প্রাইমারি কনট্যাক্ট হচ্ছে বায়ার, এবং দ্বিতীয় কনট্যাক্ট হচ্ছে ফাইন্যান্স অ্যাপ্রুভার। কারণ স্টেজ নাম ও অর্ডিং স্থির, রিপোর্টগুলো কনসিসটেন্ট থাকে।

Activities: টাস্ক, মিটিং, এবং নোটের জন্য এক মডেল

Add practical permissions

Start with simple RBAC so people can work without permission headaches.

Create roles

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

একটি একক Activity টেবিল

একটি ঘটনা বা হওয়ার কথা এমন প্রতিটি জিনিসের জন্য একটি রেকর্ড রাখুন। এতে একটি সরল type ফিল্ড রাখবেন, ছোট ফিক্সড সেট যেমন: call, email, meeting, note, task। তালিকাটি ছোট রাখুন যাতে মানুষ একই শব্দ বেছে নেয়।

ক্লিয়ার নিয়মাবলী ব্যবহার করুন:

এটি যদি ব্যক্তির ব্যাপারে হয় (follow-up call, intro email), contact-এ লিঙ্ক করুন।
এটি যদি রাজস্ব বাড়ানোর ব্যাপারে হয় (pricing call, negotiation meeting), deal-এ লিঙ্ক করুন।
যদি সত্যিই উভয়ের সাথে সম্পর্কিত হয়, দুটোই লিঙ্ক করুন, কিন্তু পাইপলাইন রিপোর্টিংয়ের জন্য deal-কে প্রাইমারি ধরুন।

প্র্যাকটিক্যালি, Activity-তে থাকতে পারে contact_id (nullable) এবং deal_id (nullable), এবং একটি অপশনাল owner_id (কে দায়িত্বে)।

রিপোর্টিং-ফ্রেন্ডলি টাইমস্ট্যাম্প

due_at এবং completed_at উভয় রাখুন। তারা আলাদা প্রশ্নের উত্তর দেয়। due_at বলে কী হওয়া উচিত ছিল (পরিকল্পনা ও কাজের বোঝা)। completed_at বলে বাস্তবে কী হয়েছে (প্রয়োগ ও সাইকেল টাইম)।

আপনি একটি আলাদা স্ট্যাটাস ফিল্ড ছাড়াই স্তিতি নির্ধারণ করতে পারেন: যদি completed_at সেট করা থাকে, সেটা সম্পন্ন; না হলে ওপেন। এতে ভাসমান স্ট্যাটাস ভ্যালুগুলি এড়ানো যায়।

অ্যাক্টিভিটি টেক্সটের জন্য একটি সার্চেবল ফিল্ড রাখুন যেমন summary বা body। প্রথমে নোট অতিরিক্ত কষ্ট করে স্ট্রাকচার করবেন না। উদাহরণ: “Call with Maya: confirmed budget, send proposal Friday.” পরে যখন সত্যিই দরকার হবে তখন বিশেষায়িত ফিল্ড যোগ করুন।

Ownership এবং দৃশ্যমানতা: বাস্তবসম্মত রাখুন

Ownership মানে পরবর্তী কী পদক্ষেপের জন্য কে দায়ী। একটি হালকা CRM স্কিমায় সাধারণত একটি ক্ষেত্র থাকে যেমন owner_user_id ডিলে (এবং প্রায়শই contacts-এও)।

“owner” দুইভাবে ব্যবহার হয়: ইউজার অ্যাসাইনমেন্ট (একটি নির্দিষ্ট ব্যক্তি) এবং টিম অ্যাসাইনমেন্ট (একটি গ্রুপ)। যদি শুরুতেই সবকিছু টিম-ওনড করে দিলে, আপনি আজকে কার কাজ তা বুঝতে পারছেন না।

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

কঠোর দৃশ্যমানতা দরকার হলে সেটি এক স্যুইচ হিসেবে রাখুন, জটিল ম্যাট্রিক্স নয়। উদাহরণস্বরূপ, ডিল ও অ্যাক্টিভিটিতে একটি visibility ফিল্ড যোগ করুন যার মান হতে পারে public বা private—private মানে "মালিক (এবং অ্যাডমিন) ছাড়া কেউ দেখতে পারবে না"।

আপনি তখনই টিম বা টেরিটরি প্রয়োজন when:

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

Ownership রিপোর্টিংকে প্রভাবিত করে। যদি আপনি পরিষ্কার "প্রতি রিপ" সংখ্যাটি চান, ডিলের বর্তমান owner_user_id দিয়ে রিপোর্ট করুন। যদি আপনি "দলে" যোগও চান, owner_team_id যোগ করুন (বা মালিকের প্রোফাইল থেকে ডেরাইভ করুন), কিন্তু স্পষ্টভাবে নির্দিষ্ট করুন কোনটা সূত্র।

উদাহরণ: দুই রেপ একটি ইনবক্স শেয়ার করে। একটি নতুন ডিল শুরুতে unassigned থাকে owner_user_id = null এবং owner_team_id = Sales। যখন Alex এটি নেন, সেট করুন owner_user_id = Alex (টিম হিসেবে Sales রাখুন)। আপনার পাইপলাইন পড়তে সহজ থাকবে এবং টিম টোটালও কাজ করবে।

Permissions ডিজাইন: জটিলতা ছাড়া যথেষ্ট নিয়ন্ত্রণ

Deploy when your team is ready

Push your internal CRM to AppMaster Cloud or your own cloud when ready.

Deploy now

সহজ RBAC দিয়ে শুরু করুন

পারমিশন সবচেয়ে ভালো কাজ করে যখন তিনটি ধারণাকে আলাদা রাখেন: roles (কে), resources (কী), এবং actions (কি করতে পারে)। এটিই role-based access control (RBAC), এবং টিম বাড়লে সেটি বোঝা সহজ থাকে।

রিসোর্সগুলো আপনার মূল অবজেক্টের নিকটেই রাখুন: Contacts, Organizations, Deals, Activities, এবং সম্ভবত Pipelines (যদি স্টেজ এডিটেবল হয়)। তাদের উপর একটি ছোট, স্বচ্ছ action সেট নির্ধারণ করুন: view, create, edit, delete, export।

Export আলাদা রাখা ভালো। অনেক টিম রিপোর্ট দেখতে প্রায় সবাইকে দেয়, কিন্তু বড় ডাটা একসাথে নামানোর ওপর সীমা রাখতে চায়।

অবজেক্ট-লেভেল পারমিশন শুরু করার সহজ জায়গা: “এই রোল কি ডিল এডিট করতে পারে?” বেশিরভাগ ছোট টিমের ক্ষেত্রে কয়েক মাসের জন্য এটিই যথেষ্ঠ। রেকর্ড-লেভেল নিয়ম (প্রতি কন্ট্যাক্ট বা ডিল) জটিলতা বাড়ায়, সেগুলো যোগ করুন কেবল বাস্তব প্রয়োজন পড়লে।

একটি বাস্তবসম্মত প্রথম ধাপ হল একটি মালিকানা নিয়ম: প্রতিটি রেকর্ডে আছে owner_user_id, এবং নন-অ্যাডমিনস কেবল তাদেরই সম্পাদনা করতে পারবে যা তারা own করে। যদি আরেকটি স্তর লাগবে, team_id যোগ করুন এবং টিম-ওয়াইড ভিউ অনুমতি দিন কিন্তু এডিটিং মালিক-ওয়াইড রাখুন।

রেকর্ড-লেভেল নিয়ম যোগ করুন যখন সত্যিই প্রয়োজন

রেকর্ড-লেভেল পারমিশন যোগ করুন এমন কেসগুলোর জন্য যেমন:

সেলস রিপরা একে অপরের ডিল দেখতে পাবে না
সাপোর্ট ডিল দেখতে পারবে কিন্তু কখনও এডিট করতে পারবেনা
ম্যানেজাররা সব দেখবে এবং মালিক পুনঃঅ্যাসাইন করতে পারবে

অডিট ট্রেইলের জন্য হালকা কিন্তু বাস্তব জিনিস রাখুন। প্রতিটি মূল টেবিলে যোগ করুন created_at, created_by, updated_at, এবং updated_by। যদি পরে গভীর ইতিহাস দরকার পড়ে, একটি ছোট audit_log টেবিল রাখুন: object type, record id, action, who, when, এবং পরিবর্তিত ফিল্ডগুলোর সংক্ষিপ্ত JSON।

ধাপে ধাপে: একটি উইকেন্ডে স্কিমা বানান

Put your CRM on mobile

Give reps a native mobile CRM for tasks and notes right from the same backend.

Build mobile

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

দিন ১: ডাটা মডেল লক করুন

কাগজ বা হোয়াইটবোর্ডে একটি দ্রুত ERD স্কেচ করে শুরু করুন। টেবিলের সংখ্যা ছোট রাখুন, কিন্তু লিঙ্কগুলো স্পষ্ট রাখুন: contact একটি organization-এ (ঐচ্ছিক), deal একটি pipeline-এ আছে এবং মালিক আছে, activity একটি contact ও/অথবা deal-এ সম্পর্কিত হতে পারে।

তারপর বেসিকগুলো নিন:

অবজেক্ট ও সম্পর্ক নির্ধারণ করুন: contacts, organizations, deals, activities, users/roles, এবং প্রয়োজনে ছোট লুকআপ টেবিল।
আবশ্যক ফিল্ড ও ডিফল্ট নির্ধারণ করুন: created_at, owner_id, এবং মূল নাম গুলো আবশ্যক; স্টেজ ও মুদ্রার জন্য ডিফল্ট সেট করুন যদি আপনি অ্যামাউন্ট ব্যবহার করেন।
এনাম বা লুকআপ টেবিল নির্ধারণ করুন: ডিল স্টেজ ও অ্যাক্টিভিটি টাইপ যাতে রিপোর্টিং কনসিস্টেন্ট থাকে।
সাধারণ ফিল্টারগুলোর জন্য ইনডেক্স যোগ করুন: owner_id, stage, due_at, created_at, এবং যে_FOREIGN_KEYS_ আপনি দৈনন্দিনে ফিল্টার করবেন।
20টি বাস্তব রেকর্ড দিয়ে পরীক্ষা করুন: বাস্তব নাম, তারিখ, এবং মিশ্র নোট ব্যবহার করে দেখুন কোথায় ভেঙে যায়।

দিন ২: রিপোর্টিং পরিষ্কারভাবে কাজ করে কিনা প্রমাণ করুন

ফর্ম বানানোর আগে আপনার টিমের 6-8টি প্রশ্ন লিখে নিন যা তারা প্রতি সপ্তাহে জিজ্ঞাসা করে। উদাহরণ: “Deals in Negotiation by owner”, “Overdue activities”, “New contacts this month”, “Won revenue by month”。 যদি কোনো প্রশ্ন জটিল জয়েন বা স্পেশাল কেস চায়, তখনই স্কিমা ঠিক করুন।

একটি সিম্পল টেস্ট দৃশ্য তৈরি করুন: একটি কোম্পানিতে 3টি কন্ট্যাক্ট, বিভিন্ন স্টেজে 2টি ডিল, এবং তাদের মধ্যে 6টি অ্যাক্টিভিটি (একটি কল, একটি মিটিং, দুইটি টাস্ক, এবং দুইটি নোট)। তারপর দেখুন আপনি সহজে উত্তর পেতে পারছেন কিনা—কে মালিক, পরবর্তী কী, এবং গত সপ্তাহে কী পরিবর্তন হয়েছিল—অনুমান ছাড়া।

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

রিপোর্টিং ময়লা করে ফেলা সাধারণ ভুলগুলো

রিপোর্টিং ময়লা হওয়ার প্রাথমিক কারণ সাধারণত "আজ দ্রুত সমাধান" ভাবনা যা আজ দ্রুত লাগে কিন্তু প্রতিটি সপ্তাহে ব্যয় বাড়ায়। একটি হালকা CRM স্কিমা কাজ করে যখন আপনার ডেটার স্পষ্ট আকৃতি থাকে এবং টিম কিছু নিয়ম মানে।

একটি সাধারণ ফাঁদ হল সবকিছু একটিই “customer” টেবিলে ঠেসে দেওয়া। এটি সহজ শোনায় যতক্ষণ না আপনাকে প্রশ্ন করতে হয়: "কতগুলো ডিল একটি কোম্পানির সাথে যুক্ত?" বা "কোন ব্যক্তি চাকরি বদলেছে?"। মানুষ (contacts) এবং কোম্পানি (organizations) আলাদা রাখুন এবং লিংক করুন।

আরেকটি রিপোর্ট কিলার হল ডিল স্টেজকে ফ্রি টেক্সট হিসেবে দেখা। যদি একজন টাইপ করে "Negotiation" এবং আরেকজন করে "negotiating", আপনার পাইপলাইন চার্টই ভুল হয়ে যাবে। একটি নির্ধারিত স্টেজ তালিকা (বা স্টেজ টেবিল) ব্যবহার করুন যাতে প্রতিটি ডিল একই সেটকে পয়েন্ট করে।

একাধিক মান এক ফিল্ডে প্যাক করা এড়িয়ে চলুন। কমা-সেপারেটেড ইমেইল বা ফোন নামানো সার্চ, ডেডুপিং, এবং এক্সপোর্ট কে কষ্টকর করে দেয়। যদি সত্যিই একাধিক মান দরকার, সেগুলো আলাদা রো হিসেবে সংরক্ষণ করুন (উদাহরণ: প্রত্যেক ইমেইল একটি চাইল্ড টেবিলে)।

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

এখানে একটি দ্রুত "ভবিষ্যৎ-আপনি-রক্ষা" চেকলিস্ট:

Contacts এবং Organizations আলাদা করুন, তারপর লিংক দিন
স্টেজ আইডি ব্যবহার করুন, টাইপ করা স্টেজ নাম নয়
প্রতি ফিল্ডে এক মান রাখুন; একাধিক মানের জন্য চাইল্ড টেবিল ব্যবহার করুন
due_at এবং completed_at আলাদা রাখুন
সাধারণ ভূমিকা দিয়ে শুরু করুন; বাস্তব ওয়ার্কফ্লো দেখা পরেই রেকর্ড-লেভেল নিয়ম যোগ করুন

উদাহরণ: যদি আপনার দল কলগুলো নোট হিসেবে লকি করে এবং পরে সেটাকে "done" করে একই ফিল্ড এডিট করে, আপনি কখনো রিপোর্ট করতে পারবেন না কতক্ষণ ফলো-আপ নিতে হয়েছিল। আলাদা ফিল্ড থাকলে সেই রিপোর্ট সরাসরি করা যায়।

স্কিমা চূড়ান্ত করার আগে দ্রুত চেকলিস্ট

Prototype in a weekend

Validate stages, ownership, and activities with real sample data before you build UI.

Build prototype

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

এই চেকগুলো বাস্তব স্যাম্পল ডেটা দিয়ে চালান (20 contacts এবং 10 deals যথেষ্ট)। যদি আটকে যান, সাধারণত এটি মানে একটি মিসিং ফিল্ড, একটি অসঙ্গত পিকলিস্ট, বা খুব ঢিলা সম্পর্ক।

5টি চেক যা বেশিরভাগ সমস্যা ধরে

রিপোর্টিং বেসিক: আপনি কি স্টেজ, মালিক, এবং ক্লোজ মাস অনুযায়ী ডিল গ্রুপ করতে পারেন অতিরিক্ত জায়গায় কোন তারিখ ব্যবহার করতে হবে তা নিয়ে বিভ্রান্ত ছাড়া?
কাজ পরিচালনা: আপনি কি "overdue activities by owner" এক রিপোর্টে টানতে পারেন, যেখানে overdue নির্ধারণ একটি একক due date এবং পরিষ্কার done স্ট্যাটাসের উপর ভিত্তি করে?
Contact থেকে Organization: একটি contact কি organization ছাড়া থাকতে পারে, এবং পরে তাদের লিংক করা যায় কি ইতিহাস (ইমেইল, নোট, ডিল অংশগ্রহণ) ভেঙে না দিয়ে?
কনসিস্টেন্সি: স্টেজ এবং activity টাইপ কি একটি ফিক্সড লিস্ট থেকে আসছে, যাতে আপনি "Follow up", "Follow-up", এবং "Followup"—এই তিনটি আলাদা মান না পান?
নিরাপত্তা: আপনি কি কাউকে রেকর্ড ডিলিট বা এক্সপোর্ট করা থেকে সীমাবদ্ধ করতে পারবেন, সেইসাথে স্বাভাবিক আপডেট যেমন ডিলকে পরবর্তী স্টেজে সরানো ব্লক না করে?

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

একটি ব্যবহারিক টিপ: স্টেজ এবং activity টাইপ একবার নির্ধারণ করুন (টেবিল বা এনাম হিসেবে) এবং সব জায়গায় সেটা পুনরায় ব্যবহার করুন যাতে প্রতিটি স্ক্রীন ও প্রসেস একই ভ্যালুগুলো ব্যবহার করে।

একটি বাস্তবসম্মত ছোট-টিম উদাহরণ এবং পরবর্তী ধাপ

একটি 5-ব্যক্তির এজেন্সি হালকা CRM স্কিমার জন্য ভাল টেস্ট। টিম ব্যস্ত, লিড আসে নানা যায়গা থেকে, এবং কেউই ডেটা বেবি সিট করতে চায় না। কল্পনা করুন: 1 admin, 2 sales, 1 ops lead, এবং 1 read-only টিমমেট (founder যিনি কেবল সংখ্যা চেক করেন)।

একটি ইনবাউন্ড অনুরোধ আসে (ওয়েব ফর্ম বা ইমেইল): “Need a website refresh, budget $15k, timeline 6 weeks.” নিয়ম সহজ: একটি organization তৈরি করুন (যদি এটি একটি কোম্পানি) এবং একটি contact তৈরি করুন (ব্যক্তি)। তারপর একটি deal তৈরি করুন যা organization-এ লিঙ্ক করা, এবং contact-কে ঐ ডিলের primary contact রাখুন।

দ্রুত রাখার জন্য তারা একটি ছোট intake checklist ব্যবহার করে:

যদি ডোমেইন বা কোম্পানি নাম কোন existing organization-র সাথে ম্যাচ করে, সেটি পুনঃব্যবহার করুন।
যদি ব্যক্তির ইমেইল আছে, সেই contact reuse করুন।
বাস্তব কেনাকাটার ইচ্ছা হলে সর্বদা একটি deal তৈরি করুন।
মূল মেসেজটি ডিল ডিসক্রিপশনে রাখুন।
সোর্স (referral, form, outbound) একটি সিঙ্গেল ফিল্ড হিসেবে রাখুন।

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

রোলগুলো বাস্তবসম্মত থাকে: Admin সবকিছু এডিট ও সেটিংস ম্যানেজ করতে পারে, Sales তাদের কন্ট্যাক্ট, ডিল, এবং তাদের অ্যাক্টিভিটিগুলো ক্রিয়েট ও আপডেট করতে পারে, Ops ডেলিভারি-সংক্রান্ত ফিল্ড ও অ্যাক্টিভিটি আপডেট করতে পারে, এবং Read-only পাইপলাইন ও রিপোর্ট দেখলেও ডেটা পরিবর্তন করতে পারে না।

যদি আপনি দ্রুত এইটা কাজ করা টুলে রূপান্তর করতে চান, AppMaster (appmaster.io) একটি সরল অপশন: আপনি Data Designer-এ (PostgreSQL) স্কিমা মডেল করতে পারেন, Business Process editor-এ ওয়ার্কফ্লো নিয়ম যোগ করতে পারেন, একটি ছোট lead inbox ও deal পেজ বানাতে পারেন, এবং পরে AppMaster Cloud বা আপনার নিজস্ব ক্লাউডে ডিপ্লয় করতে পারেন।

প্রশ্নোত্তর

Start with four core objects: Contacts (people), Organizations (optional companies), Deals (opportunities), and Activities (one unified log). If every question your team asks maps to one of those, you’ll stay fast without breaking reporting.

Track organizations if you sell B2B and need reporting by company, or if multiple contacts can belong to the same customer. Skip organizations for B2C or when “person” is the only thing you sell to, and keep it all in Contacts.

Avoid free text for stages because spelling and naming drift will ruin dashboards. Use a fixed list (a stages table) and store a stage ID on each deal so you can rename stages later without changing historical data.

Keep required fields minimal: an ID, a name, and created_at for contacts and organizations, plus core deal fields like stage, owner, value, and close date. Optional fields are fine, but too many required inputs lead to junk values like “N/A.”

Don’t hard-block duplicates unless you’re sure it matches your workflow. A practical default is allowing duplicates but showing a warning when a similar email or phone is found, and adding an external_id (or import keys) so re-imports don’t create extra records.

Use one Activity table with a small fixed type set like call, email, meeting, note, task. This makes “last touched,” overdue work, and activity history consistent because everything shares the same timestamps and structure.

Store both due_at and completed_at because they answer different questions. due_at is for planning and overdue reports, while completed_at is for execution and cycle-time analysis; combining them makes both reports unreliable.

Default to one primary contact per deal so reporting stays clear and the UI stays simple. If you sometimes need extra people involved, add a deal_contacts join table for participants instead of turning every deal into a complex many-to-many from day one.

A good default is: everything visible to everyone, but each deal has exactly one owner responsible for next steps. If you need privacy later, add a simple visibility field like public/private rather than building a complicated permission matrix upfront.

Model the tables first, then test with real sample data before building screens. If you can’t easily answer common questions like deals by stage, overdue activities, and last activity per deal, fix the schema while it’s still small.