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

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

আসল সমস্যা হলো প্রেক্ষাপট, ডেটা নয়

সেলস টিমগুলো ইতিমধ্যেই ড্যাশবোর্ডের ভিড়ে ডুবে আছে। প্রতিটি CRM ডজন ডজন বার চার্ট এবং ফানেল ভিউ তৈরি করে। তবে কেবল একটি সংখ্যা কোনো কাজের নয়। ক্লোজ রেটে ১৫ শতাংশ হ্রাস পাওয়া মানে কিছু একটা ঘটেছে। কিন্তু এটি আপনাকে কিছুই জানায় না যে—একটি SDR টিম কি তাদের কোয়ালিফিকেশন স্ক্রিপ্ট পরিবর্তন করেছে, কোনো পেইড ট্রাফিক সোর্স কি হঠাৎ করে অযোগ্য ভিজিটরদের পাঠিয়েছে, নাকি কোনো প্রতিযোগী মাসের প্রথম দিনেই আক্রমণাত্মক মূল্য নির্ধারণ করেছে।

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

Zoho-এর API নিয়ে লড়াই করা বন্ধ করুন

যেকোনো কিছু বিশ্লেষণ করার আগে, আপনাকে Zoho থেকে ডেটা পরিচ্ছন্নভাবে সরিয়ে নিতে হবে। প্রতিটি স্ট্যান্ডার্ড এবং কাস্টম অবজেক্টের জন্য কাস্টম সিঙ্ক স্ক্রিপ্ট লেখার প্রবণতা ত্যাগ করুন। Zoho-এর API পেজিনেশন, রেট লিমিট এবং OAuth টোকেন ম্যানেজমেন্ট মেনে চলে। আপনার CRM-এ প্রতিটি ছোটখাটো স্কিমা পরিবর্তন একটি রক্ষণাবেক্ষণের ঝামেলা হয়ে দাঁড়ায়, যা ইঞ্জিনিয়ারিংয়ের মূল্যবান সময় আসল প্রোডাক্টের কাজ থেকে সরিয়ে নেয়।

এর পরিবর্তে Airbyte ব্যবহার করুন। এতে একটি Zoho CRM কানেক্টর রয়েছে যা আপনার হয়ে জটিল কাজগুলো সামলে নেয়। এটি মডিফাইড টাইমস্ট্যাম্প ব্যবহার করে ইনক্রিমেন্টালি সিঙ্ক করে, ফলে আপনাকে প্রতি ঘণ্টায় পুরো টেবিল টেনে নিতে হয় না। এটি স্বয়ংক্রিয়ভাবে স্কিমা নরমালাইজ করে, যা অত্যন্ত গুরুত্বপূর্ণ যখন আপনি Lead_Source_Detail বা Qualification_Score-এর মতো কাস্টম ফিল্ড যোগ করেন। যখন এই ফিল্ডগুলো পরিবর্তিত হয়, Airbyte আপনাকে এক্সট্রাকশন লজিক পুনরায় লেখার বাধ্যবাধকতা ছাড়াই নিজেকে মানিয়ে নেয়। এটি সরাসরি Postgres, Snowflake, বা BigQuery-তে ডেটা পৌঁছে দেয়, ফলে রাত ২টায় ভেঙে পড়ার মতো ভঙ্গুর ইন্টারমিডিয়েট ফাইল ড্রপের ঝামেলা থাকে না।

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

ছয়টি লেয়ার, একটি স্পষ্ট কণ্ঠস্বর

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

1. Data Ingestion
Airbyte একটি নির্দিষ্ট সময়সূচী অনুযায়ী Leads, Deals, Contacts, এবং Activities সংগ্রহ করে। এই চারটি অবজেক্ট বেশিরভাগ সেলস অপারেশনের প্রাণ। এক্সট্রাকশন প্রক্রিয়াটি সহজ এবং অনুমানযোগ্য রাখুন।

2. Data Warehouse
প্রথমে কাঁচা ডেটা একটি স্টেজিং এরিয়াতে লোড করুন। অ্যানালিস্ট বা অ্যালগরিদমগুলোকে সরাসরি Zoho-এর প্রোডাকশন API কুয়েরি করতে দেবেন না। একটি স্টেজিং লেয়ার আপনাকে স্কিমা পরিবর্তনের সময় রিকভারি পয়েন্ট দেয় এবং আপনার CRM-এর গতি কমিয়ে না দিয়ে ইতিহাস পুনরায় প্রসেস করার সুযোগ দেয়।

3. Semantic Layer
এখানেই আপনি সংজ্ঞায়িত করবেন যে ব্যবসায়িক শব্দগুলোর প্রকৃত অর্থ কী। একটি "won deal" হতে পারে এমন কোনো সুযোগ যার স্টেজ হলো Closed Won, সম্ভাবনা ১০০ শতাংশ এবং ক্লোজ ডেট গত ৯০ দিনের মধ্যে। একটি "stalled lead" মানে হতে পারে ১৪ দিনে কোনো লগ করা অ্যাক্টিভিটি নেই। যখন চ্যাটবট পরবর্তীতে একজন রিজিওনাল ম্যানেজারকে বলবে যে স্টলড লিড বেড়েছে, তখন তাকে অবশ্যই সেই একই সংজ্ঞা ব্যবহার করতে হবে যা ত্রৈমাসিক বোর্ড রিপোর্টে দেখা যায়। এই লেয়ারটি ছাড়া আপনি সেই ক্লাসিক বিব্রতকর পরিস্থিতির সম্মুখীন হবেন যেখানে ড্যাশবোর্ড দেখাবে ৪২টি ক্লোজড ডিল এবং বট জেদ করবে যে সেখানে ৩৮টি ডিল আছে।

4. Anomaly Detection
স্পষ্ট আউটলায়ার ধরার জন্য স্ট্যাটিস্টিক্যাল মডেল চালান, যেমন—রবিবার যখন সাধারণত অ্যাক্টিভিটি থাকে, তখন ডিল ক্রিয়েশন শূন্যে নেমে আসা, অথবা একটি বিশাল এন্টারপ্রাইজ সুযোগের কারণে পাইপলাইন ভ্যালু হঠাৎ বেড়ে যাওয়া। সূক্ষ্ম পরিবর্তনের জন্য হালকা ওজনের ML ব্যবহার করুন, যেমন—এক মাসে প্রতি সপ্তাহে ক্লোজ রেট দুই শতাংশ করে কমে যাওয়া। আপনার উভয় দৃষ্টিভঙ্গিই প্রয়োজন। একটি স্থূল যন্ত্র আগুন শনাক্ত করে; আর একটি সংবেদনশীল যন্ত্র ধোঁয়া শনাক্ত করে।

৫. কার্যকারণ বিশ্লেষণ (Causal Analysis)
এই লেয়ারটি "কেন" প্রশ্নের উত্তর দেয়। একটি মেট্রিক ডিপেন্ডেন্সি গ্রাফ (metric dependency graph) তৈরি করুন। রেভিনিউ (Revenue) নির্ভর করে ক্লোজ রেট (close rate) এবং পাইপলাইন ভলিউমের (pipeline volume) ওপর। ক্লোজ রেট নির্ভর করে লিড কোয়ালিটি (lead quality) এবং রেপ পারফরম্যান্সের (rep performance) ওপর। লিড কোয়ালিটি নির্ভর করে ট্রাফিক চ্যানেল (traffic channel) এবং কোয়ালিফিকেশন ক্রাইটেরিয়ার (qualification criteria) ওপর। যখন কোনো ডাউনস্ট্রিম মেট্রিক (downstream metric) ব্যর্থ হয়, সিস্টেমটি গ্রাফের মাধ্যমে আপস্ট্রিম (upstream) দিকে অগ্রসর হয়। এটি কোরিলেশন শক্তি (correlation strength) এবং সময়ের নৈকট্য (timing proximity) অনুযায়ী সম্ভাব্য কারণগুলোকে র‍্যাঙ্ক করে। এভাবেই বটটি একটি সমস্যা বর্ণনা করা থেকে শুরু করে তার মূল কারণ (driver) শনাক্ত করার দিকে এগিয়ে যায়।

৬. চ্যাট ইন্টারফেস (Chat Interface)
Retrieval-Augmented Generation (RAG) সহ একটি LLM-এর মাধ্যমে ফলাফলগুলো উপস্থাপন করুন। গুরুত্বপূর্ণ বিষয়টি হলো, LLM-কে আপনার সিম্যান্টিক লেয়ার (semantic layer) থেকে তথ্য নিতে হবে, কখনোই র (raw) ওয়্যারহাউস টেবিল থেকে নয়। র টেবিলগুলো ফরেন কি (foreign keys) এবং ইউনিক্স টাইমস্ট্যাম্প (Unix timestamps) এর ভাষায় কথা বলে। সিম্যান্টিক লেয়ার ব্যবসার ভাষায় কথা বলে। RAG মডেলটিকে আপনার প্রকৃত সংজ্ঞার ওপর ভিত্তি করে কাজ করতে সাহায্য করে, ফলে হ্যালুসিনেশন (hallucinations) কমে এবং সামঞ্জস্যতা বৃদ্ধি পায়।

কেন একটি মেট্রিক গ্রাফ সবকিছু বদলে দেয়

একটি নোটিফিকেশন এবং একটি ইনসাইটের (insight) মধ্যে পার্থক্যটি বিবেচনা করুন। একটি সাধারণ ড্যাশবোর্ড অ্যালার্ট পাঠায়: "এই সপ্তাহে ক্লোজ রেট ১৫ শতাংশ কমেছে।" এটি একটি শিরোনাম মাত্র, কোনো রোগ নির্ণয় (diagnosis) নয়। একটি স্মার্ট সিস্টেম বলে: "ক্লোজ রেট কমেছে কারণ মঙ্গলবার চ্যানেল X থেকে আসা লিড কোয়ালিটি কমে গিয়েছিল।" দ্বিতীয় বাক্যটি একজন সেলস ম্যানেজারকে তাৎক্ষণিক পদক্ষেপ নেওয়ার পথ দেখায়। কোয়ার্টারটি খারাপ হওয়ার আগেই তিনি বিজ্ঞাপন খরচ (ad spend) বন্ধ করতে পারেন, ল্যান্ডিং পেজে কোনো ফর্ম কাজ করছে কি না তা পরীক্ষা করতে পারেন, অথবা SDR কভারেজ পুনরায় বরাদ্দ করতে পারেন।

এটি তৈরি করতে উপরে বর্ণিত কার্যকারণ গ্রাফটি (causal graph) প্রয়োজন। যখন ডাউনস্ট্রিম নোড—ক্লোজ রেট—তার প্রত্যাশিত সীমার বাইরে চলে যায়, সিস্টেমটি তার প্যারেন্ট (parent) নোডগুলো মূল্যায়ন করে। এটি লিড স্কোর, চ্যানেল মিক্স, সাম্প্রতিক প্রাইসিং পরিবর্তন এবং রেপ অ্যাসাইনমেন্টগুলো পরীক্ষা করে। এটি কোনো অনুমান করে না; এটি এমন একটি কাঠামো অনুসরণ করে যা ব্যবসার প্রকৃত কার্যপদ্ধতির প্রতিফলন ঘটায়।

প্রোডাকশনে সঠিকভাবে প্রয়োগ করা

শুধুমাত্র আর্কিটেকচার আপনাকে বিভ্রান্তিকর অ্যালার্ট বা অবিশ্বাস্য উত্তর থেকে রক্ষা করবে না। কার্যকর বাস্তবায়ন (Execution) গুরুত্বপূর্ণ।

ছোট পরিসরে শুরু করুন। ব্যবসা ইতিমধ্যে যে ৩ বা ৪টি মূল মেট্রিক পর্যবেক্ষণ করছে সেগুলো বেছে নিন। পাইপলাইন তৈরি (Pipeline created), গড় ডিল সাইজ (average deal size), ক্লোজ রেট (close rate) এবং সেলস সাইকেল লেন্থ (sales cycle length) একটি শক্তিশালী শুরুর সেট হতে পারে। ওয়েবসাইট বাউন্স রেট (website bounce rates), ইমেল ওপেন রেট (email open rates) বা সোশ্যাল সেন্টিমেন্ট (social sentiment) যুক্ত করার আগে এগুলো সঠিকভাবে সেটআপ করুন। অতিরিক্ত অ্যালার্ট বিভ্রান্তি (noise) তৈরি করে, আর এই বিভ্রান্তি মানুষকে সিস্টেমটি উপেক্ষা করতে শেখায়।

মানুষের জ্ঞান এবং গণিতের সমন্বয় ঘটান। আপনার সেলস অপারেশন টিমকে কার্যকারণ গ্রাফের (causal graph) প্রথম সংস্করণটি তৈরি করতে দিন। তারা অভিজ্ঞতা থেকে জানেন যে যখন লিড স্কোর কমে যায়, তখন এর কারণ প্রায়শই একটি নির্দিষ্ট ক্যাম্পেইন বা কোয়ালিফিকেশন স্ক্রিপ্টে সাম্প্রতিক কোনো পরিবর্তন। পরিসংখ্যানগত কোরিলেশন (Statistical correlation) সেই লিঙ্কগুলোকে নিশ্চিত করতে বা চ্যালেঞ্জ করতে পারে, কিন্তু এটি শূন্য থেকে (in a vacuum) খুব কমই প্রথম কোনো কারণ খুঁজে পায়। সেলস অর্গানাইজেশনে কার্যকারণ সম্পর্ক ডোমেইন সংক্রান্ত সূক্ষ্মতায় (domain nuance) ভরপুর। এটিকে সম্মান করুন।

সবকিছু অডিট করুন। চ্যাটবটের প্রতিটি উত্তরের সাথে সেই উত্তরটি তৈরি করতে ব্যবহৃত সঠিক সিম্যান্টিক সংজ্ঞা, SQL ফ্র্যাগমেন্ট বা মেট্রিক ভার্সনটি লগ (log) করুন। যখন কোনো রেপ প্রশ্ন করেন যে বট কেন একটি অ্যাকাউন্টকে উচ্চ ঝুঁকিপূর্ণ (high risk) হিসেবে চিহ্নিত করেছে, তখন তার পেছনের যুক্তিটি দেখান। সেলস টিমের কাছে বিশ্বাসই হলো মূল সম্পদ। ব্যবহারকারীরা যদি সন্দেহ করেন যে বটটি কেবল অনুমান করছে, তবে তারা আবার তাদের সহজাত প্রবৃত্তি এবং স্প্রেডশীট খোঁজার পুরনো পদ্ধতিতে ফিরে যাবে।

আসল শিক্ষা

এমন লুকআপ টুল (lookup tools) তৈরি করা বন্ধ করুন যা ব্যবহারকারীদের কাছে কেবল CRM ফিল্ডগুলোকেই পুনরাবৃত্তি করে। এর চেয়েও উন্নত হওয়ার প্রযুক্তি—Airbyte-এর মাধ্যমে স্ট্রিমিং ইনজেশন (streaming ingestion), একটি নিয়ন্ত্রিত সিম্যান্টিক লেয়ার (governed semantic layer), পরিসংখ্যানগত ও কার্যকারণ মডেল (statistical and causal models), এবং প্রকৃত ব্যবসায়িক যুক্তির ওপর ভিত্তি করে তৈরি একটি LLM—এখনই হাতের নাগালে রয়েছে। কঠিন অংশটি মডেল ওয়্যারিং (model wiring) নয়। কঠিন হলো আপনার মেট্রিকগুলোকে নির্ভুলভাবে সংজ্ঞায়িত করার শৃঙ্খলা, আপস্ট্রিম পর্যায়ে কারণগুলোকে সাজানো, এবং সিস্টেমকে কেবল স্মার্ট দেখানোর জন্য অপ্রয়োজনীয় তথ্য বা 'নয়েজ' তৈরি করতে না দেওয়া। উত্তরের জন্য তৈরি করুন, তাহলেই চ্যাটবট সেলস মিটিংয়ে তার জায়গা করে নিতে পারবে।

Based on the architecture described by Mayu2008. For more discussions on data engineering and AI systems, join the GyaanSetu community.