Broker CRM তৈরি হয় এমন ইউনিটের ক্রেতাদের পাইপলাইন ঘিরে, যেগুলোর মালিক অন্য কেউ। ডেভেলপারের সিস্টেম তৈরি হয় ইউনিটগুলোকে ঘিরেই — সেগুলোর প্রাপ্যতা, দাম, পেমেন্ট প্ল্যান, প্রতিটির বিপরীতে আদায় হওয়া টাকা, নিবন্ধনের অবস্থা আর তার পরের দায়। দুটোর মিল কেবল লিড আর ডিলে — এ কারণেই একটি দিয়ে অন্যটি চালানো যুক্তিসংগত মনে হয়, প্রথম মাস শেষ হওয়া পর্যন্ত।
ডেভেলপারের যা থাকে, ব্রোকারের যা থাকে না
| বিষয় | Broker CRM | ডেভেলপারের প্রয়োজন |
|---|---|---|
| ইউনিট ইনভেন্টরি | একটি তালিকা, প্রায়ই আমদানি করা | প্রামাণিক রেকর্ড, স্টেট ও নিয়ন্ত্রণসহ |
| দাম | ডেভেলপার যা বলেছেন | নিয়ম থেকে হিসাব, অনুমোদনের সিঁড়িসহ |
| পেমেন্ট প্ল্যান | কেবল উল্লেখ | প্রজেক্টের সঙ্গে নিবন্ধিত, প্রতিটি ইউনিটে প্রযোজ্য |
| আদায় | নেই | কিস্তি, রসিদ, এজিং, রিমাইন্ডার — বছরজুড়ে |
| Escrow | নেই | প্রজেক্ট ট্রাস্ট অ্যাকাউন্টের সঙ্গে মিলকরণ |
| নিবন্ধন | নেই | Oqood, আর পরে টাইটেল |
| হস্তান্তর | নেই | স্ন্যাগিং, চাবি, ওয়ারেন্টি, ত্রুটি দায় |
| কমিশন | তাঁদের আয় | একটি খরচ, অনেক এজেন্সিজুড়ে, ক্রেডিট ও clawback-সহ |
ধরনটা এই: broker CRM বিক্রিটিকে সামলায়, আর ডেভেলপারের সিস্টেম সামলায় সম্পদ আর বিক্রির পরেও টিকে থাকা দায়।
যে চার জায়গায় বিকল্পটি ভাঙে
ইনভেন্টরিকে প্রামাণিক হতে হয়। একাধিক এজেন্সি একই টাওয়ার বেচলে "available" মানে হতে হবে এই মুহূর্তে খালি, এক জায়গায় — নইলে একই ইউনিট দুবার বিক্রি হবে। এর জন্য মেয়াদ ও অনুমোদনসহ ইউনিট স্টেট লাগে, শেয়ার করা তালিকা নয়। দেখুন ডাবল বুকিং থামানো।
পেমেন্ট প্ল্যান নিবন্ধিত, আলোচনাসাপেক্ষ নয়। প্ল্যান প্রজেক্টের সঙ্গে নিবন্ধিত থাকে, আর নিবন্ধিত প্ল্যান থেকে সরে যাওয়া SPA নিবন্ধনে আটকায়। যে সিস্টেম প্ল্যানকে মুক্ত লেখা হিসেবে দেখে, সে এটি ঠেকাতে পারে না। দেখুন অফ-প্ল্যান পেমেন্ট প্ল্যান।
টাকা escrow-র সঙ্গে মিলতে হয়। ক্রেতার টাকা যায় প্রজেক্ট ট্রাস্ট অ্যাকাউন্টে আর সার্টিফাইড অগ্রগতির বিপরীতে তোলা হয়। আপনার সিস্টেমে যা জমা দেখাচ্ছে আর escrow স্টেটমেন্টে যা আছে — মাসে একবার মেলানো বাধ্যতামূলক, আর broker CRM-এ এর কোনো সমতুল্য নেই। দেখুন DLD escrow রিলিজ।
ক্রেডিট বহু-এজেন্সির প্রশ্ন। একই লঞ্চে পাঁচটি এজেন্সি কাজ করলে একই ক্রেতার উপর একাধিক দাবি আসবেই। রেজিস্ট্রেশনের মেয়াদ, তার শেষ হওয়া আর clawback — এগুলো ডেভেলপারের সমস্যা; broker CRM কেবল নিজের দিকটাই দেখে। দেখুন ব্রোকার পোর্টাল ও লিড ক্রেডিট।
ডেভেলপারের সিস্টেমে যা বাড়তি লাগে
- নিয়ন্ত্রিত স্টেট আর অডিটসহ ইউনিট লাইফসাইকেল।
- দামের নিয়ম, তলা ও ভিউ প্রিমিয়াম, আর ছাড়ের অনুমোদনের সিঁড়ি।
- নিবন্ধিত পেমেন্ট প্ল্যান, ইউনিটভিত্তিক প্রয়োগ, পুনর্গঠনের ইতিহাসসহ।
- এজিং আর স্বয়ংক্রিয় রিমাইন্ডারসহ আদায় — হস্তান্তরের পরের কিস্তিসহ।
- ইউনিটভিত্তিক Oqood ও টাইটেলের অবস্থা, কাগজের সেট যুক্ত করে।
- Escrow মিলকরণ আর রিলিজের কাগজপত্র।
- এজেন্সি ব্যবস্থাপনা: রেজিস্ট্রেশন, মেয়াদ, ক্রেডিট, অর্জিত কমিশন আর clawback।
- হস্তান্তর: স্ন্যাগিং, চাবি, ওয়ারেন্টি, ত্রুটি দায়ের ট্র্যাকিং।
Broker CRM কখন সত্যিই সঠিক টুল
আপনি ব্রোকারেজ হলে এটিই সঠিক টুল, আর ডেভেলপারের সিস্টেম হবে অপ্রয়োজনীয় ভার। ভুলটা হয় তখন, যখন সেলস ডিরেক্টর এজেন্সি থেকে এসেছেন আর তিনি এটিই চেনেন বলে ডেভেলপার এটি নেন। সিদ্ধান্তটি সাধারণত লঞ্চের সময় হয়, যখন কেবল লিডই আছে — আর আঠারো মাস পরে ধরা পড়ে, যখন আদায়, escrow আর নিবন্ধন — তিনটিই মেলাতে হয় অথচ কোনোটিই কোথাও নেই।
এরপর কী
চলমান প্রজেক্টের একটি ইউনিট নিন আর একটিমাত্র সিস্টেম থেকে বের করার চেষ্টা করুন: বর্তমান অবস্থা, ক্রেতা, নিবন্ধিত পেমেন্ট প্ল্যান, এ পর্যন্ত আদায়, Oqood অবস্থা, আর কোন এজেন্সি কমিশন পাবে। একাধিক সিস্টেম লাগলে ফাঁকটা প্রতিটি মাস শেষেই আপনার সময় খাচ্ছে — একটি ইউনিটের ডেভেলপার-দৃষ্টি দেখুন।