যে 'বাগ'টি আসলেই ছিল না: কীভাবে এআই খড়ের গাদার মধ্যে সূঁচ খুঁজে বের করল এবং মিনিটের মধ্যে আমাদের ইন্টিগ্রেশনটি ঠিক করে দিল
একজন উচ্চ-মূল্যের গ্রাহক নিশ্চিত ছিলেন যে আমাদের ইন্টিগ্রেশন তাদের ডেটা এলোমেলো করে দিয়েছে, এবং আমাদের এটি বন্ধ করতে বলেছিলেন। APIANT প্ল্যাটফর্মের প্রতিটি স্তরে AI সংযুক্ত থাকায়, এটি মানুষের চেয়েও দ্রুত বিপুল পরিমাণ তথ্যের মধ্যে থেকে সঠিকটি খুঁজে বের করে: যে ফিল্ডটি পরিবর্তিত হয়েছে, ঠিক কোন দিনে এটি পরিবর্তিত হয়েছে, এবং যে থার্ড-পার্টি অ্যাপটি এটি পরিবর্তন করেছে। একটি ইন্টিগ্রেশন এবং ইন্টিগ্রেশন ইনফ্রাস্ট্রাকচারের মধ্যে এটাই পার্থক্য।
পড়া শুরু করার আগে একটি কথা: এই নিবন্ধটি এআই দ্বারা লেখা হয়েছে। এর মধ্যে সংযুক্ত কাস্টমার সাপোর্টের উত্তরটিও এআই দ্বারা তৈরি। দুটোই একই উৎস থেকে এসেছে: একটি কার্যকরী ইন্টিগ্রেশন প্ল্যাটফর্মে গভীর অ্যাক্সেস থাকা একটি এআই। আমরা বলছি না যে এআই খুব অসাধারণ। আমরা একটি আসল (পরিচয় গোপন রাখা) টিকিটের মাধ্যমে আপনাকে দেখাচ্ছি যে, সঠিক পরিকাঠামো পেলে এটি কী করতে পারে।
সকাল ৯টার অগ্নি নির্বাপণ মহড়াটি পাঁচ মিনিট স্থায়ী হয়েছিল।
সেই দৃশ্যটা কল্পনা করুন, যা প্রতিটি সফটওয়্যার কোম্পানি ভয় পায়।
আপনার অন্যতম মূল্যবান গ্রাহক, একটি দ্রুত বর্ধনশীল ওয়েলনেস ও ফিটনেস ব্র্যান্ড, যাদের বিভিন্ন শহরে শাখা রয়েছে, একটি জরুরি টিকিট খোলে। বিষয়: “সিঙ্ক ত্রুটি?”। তাদের ডেটা ভুল। তাদের CRM-এ থাকা সদস্যদের প্রোফাইলগুলো এলোমেলো হতে শুরু করেছে। একটি রেকর্ডে দেখা যাচ্ছে, একজনের নামের উপরে সম্পূর্ণ ভিন্ন আরেকজনের ইমেল, ফোন এবং ইতিহাস রয়েছে। এটি তাদের কর্মীরা দেখতে পাচ্ছে, এটি নীরবে তাদের মার্কেটিং তালিকাগুলোকে দূষিত করছে এবং এটি গ্রাহকদের সাথে প্রকৃত সম্পর্ককে ক্ষতিগ্রস্ত করছে। তারা চিন্তিত, কী কারণে সমস্যাটি হয়েছে সে সম্পর্কে তাদের একটি সুস্পষ্ট ধারণা আছে এবং তারা এটি এখনই সমাধান করতে চায়। এমনকি তারা আমাদেরকে সমস্যাটি সমাধান না হওয়া পর্যন্ত ইন্টিগ্রেশনটি বন্ধ করে দিতেও বলেছে।
এই অনুরোধটির মধ্যেই ফাঁদটি রয়েছে। গ্রাহক সরাসরি আপনার ইন্টিগ্রেশনকেই দায়ী করছেন। ইন্টিগ্রেশনটি তাদের স্ট্যাকের সবচেয়ে নতুন ও রহস্যময় অংশ, তাই একে দোষারোপ করা সবচেয়ে সহজ এবং এর দায়মুক্তি ঘটানো সবচেয়ে কঠিন। আর এটি বন্ধ করে দিলে সঠিক ও বৈধ আপডেটের ধারা থেমে যাবে, অথচ আসল সমস্যার কোনো সমাধানই হবে না।
সাধারণত এই পর্যায়েই ঘণ্টার পর ঘণ্টা সময় নষ্ট হয়। একজন সাপোর্ট ইঞ্জিনিয়ারকে ডাকা হয়। তিনি বিষয়টি একজন ইন্টিগ্রেশন বিশেষজ্ঞের কাছে পাঠান। সেই বিশেষজ্ঞ একেবারে শূন্য থেকে শুরু করেন; ইন্টিগ্রেশনটির কাজ কী, তা পুনর্গঠন করেন, পুরোনো টিকেট পড়েন, লগ সংগ্রহ করেন এবং বিভিন্ন তত্ত্ব দাঁড় করান। যেহেতু গ্রাহক সিঙ্ককে দোষারোপ করেছেন, তাই সিঙ্কটি নির্দোষ হওয়া সত্ত্বেও সেটিকে ভেঙেচুরে দেখাটাই স্বাভাবিক প্রবণতা। একজন ডেভেলপারকে রোডম্যাপ থেকে সরিয়ে নেওয়া হয়। একদিন, হয়তো বা দুইদিন কেটে যায়। সবচেয়ে খারাপ ব্যাপার হলো, টিমটি এমন কিছু "ঠিক" করে ফেলতে পারে যা কখনোই নষ্ট ছিল না, অথবা গ্রাহককে একটি ভালো ইন্টিগ্রেশন নিষ্ক্রিয় করতে বলতে পারে, অথচ আসল কারণটি আপস্ট্রিমে ডেটা নষ্ট করতেই থাকে।
এখানে তেমনটা ঘটেনি। এখানে উত্তরটা মাত্র কয়েক মিনিটের মধ্যেই চলে এসেছিল, এবং তা এসেছিল প্রমাণসহ।
ব্যাপারটা ঠিক কেমন ছিল, তা আমি সহজ ভাষায় ব্যাখ্যা করছি।
সমস্যাটি, পরিভাষা ছাড়া ব্যাখ্যা করা হলো
এক ব্যক্তির জন্য একটিমাত্র সদস্যপদ রেকর্ডের কথা ভাবুন। এতে নাম, ইমেল, ফোন নম্বর, জন্ম তারিখ এবং পরিদর্শনের ইতিহাস সংরক্ষিত থাকে। এই সবকিছুই একজন সদস্যের।
একদিন, CRM-এর সেই রেকর্ডে হঠাৎ করে আসল সমস্ত বিবরণের উপরে সম্পূর্ণ ভিন্ন একজন ব্যক্তির নাম দেখা যায়। গ্রাহকের দলের কাছে, ব্যাপারটা ঠিক এমন মনে হয় যেন ইন্টিগ্রেশনটি দুজন ভিন্ন ব্যক্তিকে নিয়ে একটি রেকর্ডে জুড়ে দিয়েছে। এটি উদ্বেগজনক, এবং এমন সন্দেহ করাটাও যুক্তিসঙ্গত।
গ্রাহকের নিজস্ব তত্ত্বটি ছিল সুনির্দিষ্ট এবং বুদ্ধিদীপ্ত: হতে পারে ইন্টিগ্রেশনটি একটি আইডি নম্বরের ভিত্তিতে লোকজনকে মেলাচ্ছিল, এবং দুটি ভিন্ন স্থানের দুজন ভিন্ন ব্যক্তির একই আইডি থাকায় সিস্টেমটি বিভ্রান্ত হয়ে তাদের এক করে ফেলছিল। আপনি যদি সঠিক গ্রাহক তথ্যের ওপর ভিত্তি করে ব্যবসা চালান, তবে এই ধরনের বিষয়ই আপনার রাতের ঘুম কেড়ে নেয়।
কঠিন প্রশ্নটা কখনোই এমন ছিল না যে, “আমরা ডেটাটা কীভাবে ঠিক করব।” বরং কঠিন প্রশ্নটা ছিল, “আসলে কে এটা পরিবর্তন করেছে, এবং ইন্টিগ্রেশনটি কি দোষী নাকি বার্তাবাহক।” যতক্ষণ না আপনি এর উত্তর খুঁজে পাচ্ছেন, ততক্ষণ নিরাপদে কিছুই ঠিক করতে পারবেন না। ভুল অনুমান করলে হয় আপনাকে বিনা কারণে একটি সুস্থ ইন্টিগ্রেশন নতুন করে তৈরি করতে হবে, অথবা আসল কারণটিকেই চালু রেখে দিতে হবে এবং ক্ষতি চলতেই থাকবে।
এআই আসলে কীভাবে এটি সমাধান করেছে
আপনি যদি একটি সফটওয়্যার ব্যবসা পরিচালনা করেন, তবে এই অংশটিই সবচেয়ে গুরুত্বপূর্ণ।
এটি একটি নির্দিষ্ট রেকর্ডের সম্পূর্ণ ইতিহাস, ক্ষেত্র অনুযায়ী পড়ে শোনালো। তত্ত্বকথা বলার পরিবর্তে, এআই প্রভাবিত কন্ট্যাক্টটির সম্পূর্ণ ইতিহাস সংগ্রহ করে এবং উৎস সিস্টেম থেকে আসা প্রতিটি পরিবর্তনকে একেবারে স্বতন্ত্র ঘটনা পর্যন্ত অনুসরণ করে। এটি কোনো সারসংক্ষেপ নয়। বরং কী পরিবর্তিত হয়েছে এবং ঠিক কখন, তার প্রকৃত ক্রম।
এটি এমন একটি তথ্য খুঁজে পেয়েছিল যা মামলাটির সমাধান করে দেয়। রেকর্ডে থাকা শুধু নামটাই বদলেছিল। ইমেল, ফোন, জন্মতারিখ এবং সম্পূর্ণ ইতিহাস আগে ও পরে অপরিবর্তিত এবং হুবহু একই ছিল। এই একটি পর্যবেক্ষণই সবকিছুর উত্তর দিয়ে দিয়েছিল। যদি সত্যিই একই আইডি নিয়ে দুজন ভিন্ন ব্যক্তিকে গুলিয়ে ফেলা হতো, তাহলে শুধু নাম নয়, তাদের সমস্ত বিবরণই আলাদা হতো। বাকি সবকিছু একই থাকা সত্ত্বেও একটি ফিল্ডের পরিবর্তন হওয়ার মানে এই নয় যে দুটি রেকর্ড একীভূত করা হয়েছে। এর মানে হলো, উৎস থেকে একটি রেকর্ডের নাম পরিবর্তন করা হয়েছিল।
এর মাধ্যমে চিহ্নিত করা হয়েছে কীভাবে এই পরিবর্তন এসেছে এবং এর জন্য কারা দায়ী। এআই দেখতে পাচ্ছিল যে, নাম পরিবর্তনের কাজটি আমাদের ইন্টিগ্রেশন থেকে হয়নি, এবং কোনো কর্মীও হাতে করে এটি সম্পাদনা করেননি। এটি এসেছিল সোর্স প্ল্যাটফর্মের নিজস্ব প্রোগ্রামিং ইন্টারফেসের মাধ্যমে, যা একটি আলাদা থার্ড-পার্টি অ্যাপ দ্বারা চালিত হয়েছিল। গ্রাহক সেই অ্যাপটিকে সংযুক্ত করেছিলেন এবং তার অ্যাকাউন্টে লেখার অনুমতি দিয়েছিলেন। আমাদের ইন্টিগ্রেশনটি ঠিক যেভাবে ডিজাইন করা হয়েছে, সেভাবেই সেই আপস্ট্রিম পরিবর্তনটিকে সহজভাবে এবং সঠিকভাবে সিআরএম-এ পৌঁছে দিয়েছে। উল্লেখ্য, ইন্টিগ্রেশনটি শুধুমাত্র সোর্স প্ল্যাটফর্ম থেকে সদস্যের ডেটা পড়ে। এটি কেবল একটি অভ্যন্তরীণ সিঙ্ক ফ্ল্যাগ লিখে পাঠায়। এটি কখনও কোনো নাম, ইমেল বা প্রোফাইলের কোনো ফিল্ড স্পর্শ করে না।
অন্য কথায়, ইন্টিগ্রেশনটি দোষী ছিল না। এটি ছিল কেবল একজন বার্তাবাহক, যে চেইনের আরও উপরের স্তরে অন্য কোনো কিছুর করা একটি পরিবর্তন বিশ্বস্তভাবে জানাচ্ছিল। গ্রাহকের আইডি-সংঘর্ষের তত্ত্বটি একটি ভালো অনুমান ছিল, কিন্তু প্রমাণ সম্পূর্ণ ভিন্ন একটি দিকেই ইঙ্গিত করছিল।
সম্পূর্ণ ডায়াগনোসিস (সঠিক রেকর্ড, রিনেমটি কার্যকর হওয়ার সঠিক তারিখ, যে সুনির্দিষ্ট প্রক্রিয়ার মাধ্যমে এটি করা হয়েছে, এবং ইন্টিগ্রেশনটি যে সঠিকভাবে কাজ করছিল তার প্রমাণ) কয়েক মিনিটের মধ্যেই চলে আসে। গ্রাহক পরবর্তী পদক্ষেপ সম্পর্কেও একটি স্পষ্ট নির্দেশনা পান: যে আপস্ট্রিম থার্ড-পার্টি অ্যাপটি রেকর্ডগুলোর নাম পরিবর্তন করছে, সেটি খুঁজে বের করা এবং উৎস থেকেই ডেটা সংশোধন করা। ইন্টিগ্রেশনের কোনো কিছুই নতুন করে তৈরি, পুনর্বিন্যাস বা বন্ধ করার প্রয়োজন হয়নি।
একজন মানব বিশেষজ্ঞও একই সিদ্ধান্তে পৌঁছাতে পারেন। প্রশ্ন হলো, গ্রাহক যখনই কোনো অভিযোগ তোলে, তখন শুধু ইন্টিগ্রেশনকে দোষারোপ করার দ্রুততর এবং অনেক বেশি বিপজ্জনক শর্টকাটটি না নিয়ে, প্রতিবারই সেই ফরেনসিক কাজটি করার মতো সময় ও ধৈর্য তাদের আছে কি না।
আমরা যে উত্তরটি পাঠিয়েছিলাম, সেটি এআই দ্বারা লিখিত।
গ্রাহকের কাছে পাঠানো আসল সাপোর্ট উত্তরটি এখানে দেওয়া হলো। প্রতিটি নাম, ইমেল, আইডি এবং অবস্থান পরিবর্তন করা হয়েছে, কিন্তু প্ল্যাটফর্মগুলো আসল এবং এর মূল বিষয়বস্তু হুবহু তাই যা এআই তৈরি করেছে, খুঁটিনাটিসহ: একদম সঠিক ক্লায়েন্ট আইডি, সঠিক তারিখ, সঠিক কার্যপ্রণালী। এটি কোনো মানুষের দ্বারা খসড়া করে পরিমার্জন করা হয়নি। এটি এআই তার আগে থেকে সংগ্রহ করা প্রমাণের ভিত্তিতে লিখেছে।
টিকিট: বিষয়: সিঙ্ক ত্রুটি?
গ্রাহক: ক্যালাম
হাই ক্যালাম,
বিস্তারিত প্রতিবেদন এবং নমুনা রেকর্ডগুলোর জন্য ধন্যবাদ, এগুলো বিষয়টি আরও দ্রুত চিহ্নিত করতে সাহায্য করেছে। আমরা আমাদের APIANT MCP AI টুলিং ব্যবহার করে একটি পূর্ণাঙ্গ তদন্ত চালিয়েছি, যা আমাদের প্রতিটি পরিবর্তনকে একেবারে স্বতন্ত্র Mindbody ইভেন্ট পর্যন্ত অনুসরণ করতে সাহায্য করেছে। এভাবেই আমরা এত নির্ভুলভাবে এবং এত দ্রুত উৎসটি শনাক্ত করতে পেরেছি।
সারসংক্ষেপ
সংক্ষেপে বলতে গেলে: প্রোফাইলের এই গড়বড়গুলো CRMConnect সিঙ্ক বা HubSpot-এর কারণে হচ্ছে না। সিঙ্কটি সঠিকভাবে কাজ করছে। এটি Mindbody-র ভেতরে, অর্থাৎ উৎস থেকে পরিবর্তিত হওয়া ডেটা বিশ্বস্ততার সাথে প্রতিফলিত করছে। আপনার Mindbody অ্যাকাউন্টের সাথে সংযুক্ত একটি বাহ্যিক অ্যাপ্লিকেশনের মাধ্যমে Mindbody-তে রেকর্ডগুলো পরিবর্তন করা হচ্ছে, এবং সিঙ্কটি তখন পরিকল্পনা অনুযায়ীই সেই পরিবর্তনগুলো HubSpot-এ পৌঁছে দিচ্ছে।
ফলাফল (আপনার মেগান হার্টলি / ব্রনউইন কিন উদাহরণ ব্যবহার করে, হাবস্পট যোগাযোগ নম্বর ৫১০০৩৪১২৯৮৬)
- ওই HubSpot কন্টাক্টটি Mindbody Northside ক্লায়েন্ট আইডি 100004217 থেকে প্রাপ্ত।
- ২ জুন পর্যন্তও মাইন্ডবডি আমাদের কাছে মেগান হার্টলি (megh82@example.com) নামে সেই ক্লায়েন্টের তথ্য পাঠাচ্ছিল।
- ৩-৪ জুন, মাইন্ডবডির সেই একই ক্লায়েন্ট রেকর্ডটি ব্রনউইন কিন নামে পরিবর্তন করা হয়, কিন্তু এর বাকি সবকিছু (ইমেল, ফোন, জন্ম তারিখ, ভিজিটের ইতিহাস, চিকিৎসার নোট) হুবহু একই ছিল। শুধু নামটি মুছে দেওয়া হয়েছিল।
- আপনি মাইন্ডবডিতে নিজেই এটি নিশ্চিত করতে পারেন: ক্লায়েন্টের কন্টাক্ট লগ দেখাচ্ছে যে ২ জুন “মেগান হার্টলি” (megh82@example.com)-কে এবং ১০ জুনের মধ্যে ব্রনউইন কিন-কে সিস্টেম ইমেল পাঠানো হয়েছে। একই ক্লায়েন্ট রেকর্ড, কিন্তু দুটি ভিন্ন পরিচয়।
কীভাবে পরিবর্তন করা হয়েছিল
সম্পাদনাটি Mindbody-র পাবলিক এপিআই (Public API)-এর মাধ্যমে করা হয়েছে, যার অর্থ হলো, আপনার Mindbody অ্যাকাউন্টে এপিআই অ্যাক্সেস আছে এমন কোনো বাহ্যিক অ্যাপ্লিকেশন এই আপডেটটি পাঠিয়েছে। এটি Mindbody ইন্টারফেসে কোনো কর্মী দ্বারা সম্পাদিত হয়নি, এবং এটি CRMConnect-ও করেনি। (প্রসঙ্গত: CRMConnect শুধুমাত্র Mindbody থেকে ক্লায়েন্টের ডেটা পড়ে; এটি কেবল একটি অভ্যন্তরীণ সিঙ্ক ফ্ল্যাগ লিখে পাঠায়। এটি কখনোই কোনো ক্লায়েন্টের নাম, ইমেল বা প্রোফাইল ফিল্ড পরিবর্তন করে না।)
তাই যখন Mindbody সিঙ্ককে জানায় যে “ক্লায়েন্ট 100004217 এখন ব্রনউইন কিন”, তখন CRMConnect সঠিকভাবে লিঙ্ক করা HubSpot কন্টাক্টটি আপডেট করে, যে কারণে মেগানের রেকর্ডে এখন ব্রনউইনের বিবরণ দেখাচ্ছে। যতক্ষণ পর্যন্ত সেই Mindbody রেকর্ডটি অপরিবর্তিত থাকবে, যেকোনো পুনঃসিঙ্ক এটিকে পুনরায় প্রয়োগ করতে থাকবে।
আমরা আশা করি, তারা হুইটফিল্ড / এরিন ডয়েলের ঘটনা (এবং অন্য যেকোনো ঘটনা) একই ধরনের হবে: মাইন্ডবডির উৎস-পক্ষের পরিবর্তন।
পরবর্তী প্রস্তাবিত পদক্ষেপ
- Mindbody-এর দিক থেকে দোষী অ্যাপটি শনাক্ত করুন। অনুগ্রহ করে পর্যালোচনা করুন কোন কোন থার্ড-পার্টি ইন্টিগ্রেশন/অ্যাপের আপনার Mindbody সাইটগুলিতে API (রাইট) অ্যাক্সেস আছে। আমরা এমন একটি অ্যাপ্লিকেশন খুঁজছি যা ক্লায়েন্টের রেকর্ডগুলির নাম পরিবর্তন বা একীভূত করে। প্রয়োজনে, আপনার Mindbody অ্যাকাউন্ট ম্যানেজার নিশ্চিত করতে সাহায্য করতে পারেন যে ৩-৪ জুন কোন অ্যাপটি এই পরিবর্তনটি করেছে।
- উৎসস্থলে (Mindbody) রেকর্ডগুলো সংশোধন করুন, যাতে প্রত্যেক ব্যক্তি সঠিক বিবরণসহ তাদের নিজস্ব স্বতন্ত্র ক্লায়েন্ট রেকর্ডে ফিরে আসতে পারে।
সমাধান
গুরুত্বপূর্ণ বিষয় হলো, CRMConnect বা HubSpot-এর দিকে কোনো কিছুই পুনরায় লিঙ্ক বা কনফিগার করার প্রয়োজন নেই। আপনার HubSpot কন্ট্যাক্টগুলো ইতিমধ্যেই সঠিক Mindbody ক্লায়েন্টগুলোর সাথে ম্যাপ করা আছে। একমাত্র সমস্যা হলো Mindbody সোর্সের ডেটাতে। আপনি Mindbody-তে সেটি সংশোধন করে নিলেই, পরবর্তী সিঙ্কের সময় সঠিক তথ্যগুলো স্বয়ংক্রিয়ভাবে বিদ্যমান HubSpot কন্ট্যাক্টগুলোতে সরাসরি চলে যাবে।
সিঙ্ক বন্ধ করার বিষয়ে আপনার আগের পরামর্শের প্রসঙ্গে বলছি: আমরা এটি চালু রেখেছি, কারণ এটি সঠিকভাবে কাজ করছে এবং এটি থামিয়ে রাখলে মাইন্ডবডির মূল ডেটার কোনো পরিবর্তন বা সমাধান হবে না।
যেকোনো প্রশ্নের জন্য নির্দ্বিধায় যোগাযোগ করুন। আমরা সাহায্য করার জন্য আছি!
শুভেচ্ছা সহ, এপিয়েন্ট এআই সাপোর্ট এটি আবার পড়ুন এবং লক্ষ্য করুন এটি কী করছে। এটি উপসংহার দিয়েই শুরু করে। এটি ক্রমানুসারে প্রমাণগুলো তুলে ধরে। এটি গ্রাহকের নিজস্ব তত্ত্বকে এড়িয়ে না গিয়ে সরাসরি তার মোকাবিলা করে। ইন্টিগ্রেশনটি কী কী বিষয় অন্তর্ভুক্ত করে এবং কী কী করে না, তার একটি সুস্পষ্ট সীমারেখা টেনে দেয়। এবং এটি সিঙ্ক বন্ধ করে দেওয়ার সহজ পথটি বেছে নিতে অস্বীকার করে, কারণ সেটি একটি ভুল সিদ্ধান্ত হতো। এটি কোনো পূর্বনির্ধারিত ম্যাক্রো নয়। এটি একটি রেকর্ডের প্রকৃত ইতিহাস থেকে তৈরি একটি যুক্তিযুক্ত উত্তর।
আগে ও পরে: হাতে খোঁজাখুঁজি বনাম এআই-এর সাহায্যে উত্তর
এই ধরনের একটি ডেপ্লয়মেন্টে কাজের পরিধি কতটা বিশাল, তা কল্পনা করে নেওয়া দরকার। Mindbody এবং HubSpot-এর মধ্যে একটি CRMConnect ইন্টিগ্রেশন কোনো একক পাইপলাইন নয়। একটি ক্রমবর্ধমান ব্র্যান্ড একাধিক স্থানে তাদের কার্যক্রম পরিচালনা করে, এবং একই ক্লায়েন্ট একাধিক সাইটে উপস্থিত থাকতে পারে, তাই এই লজিকে একটি সাইট গার্ড থাকে: যে কন্ট্যাক্ট দুটি স্থানে উপস্থিত থাকে, তার রেকর্ড যেন একটি স্থানের রেকর্ড দ্বারা অন্যটি কখনো পরিবর্তিত না হয়। প্রতিটি Mindbody ইভেন্ট (একজন নতুন ক্লায়েন্ট, একটি সেল, একটি অ্যাপয়েন্টমেন্ট, একটি ক্লাস বুকিং, একটি মেম্বারশিপ, একটি কন্ট্রাক্ট) ইনস্ট্যান্ট ওয়েবহুক এবং শিডিউলড সুইপের মাধ্যমে স্ট্যান্ডার্ড HubSpot রেকর্ড এবং পাঁচটি ডেডিকেটেড কাস্টম অবজেক্টে প্রবাহিত হয়: অ্যাপয়েন্টমেন্ট, ক্লাস বুকিং, ক্লায়েন্ট সার্ভিস, মেম্বারশিপ এবং কন্ট্রাক্ট। এই রাইটগুলোর মধ্যে অনেকগুলোই দ্বৈত: একটি সম্পন্ন হওয়া অ্যাপয়েন্টমেন্ট একই সাথে একটি কাস্টম পাইপলাইনে 'ডিল' হিসেবে এবং একটি পৃথক কাস্টম-অবজেক্ট রেকর্ড হিসেবে যুক্ত হতে পারে। এর গভীরে, পুনঃব্যবহারযোগ্য সাবরুটিনগুলো সম্মিলিত কাজটি করে, এবং প্রতিটি রাইট অপারেশন একটি বহু-ধাপের ডিসিশন ট্রি চালায়: এটি একটি ক্যাশ করা রেকর্ড আইডি পরীক্ষা করে, সেটিকে আপডেট করার চেষ্টা করে, এবং একটি নির্দিষ্ট ত্রুটির ক্ষেত্রে প্রপার্টি দ্বারা রেকর্ডটি খোঁজা বা তার পরিবর্তে একটি নতুন রেকর্ড তৈরি ও সংযুক্ত করার দিকে অগ্রসর হয়, যেখানে হাবস্পট দ্বারা ফেরত আসা সুনির্দিষ্ট ত্রুটির উপর ভিত্তি করে পরবর্তী শাখাগুলো তৈরি হয়। অটোমেশনের সঠিক সংখ্যা এবং শাখার গভীরতা গ্রাহকের ডেপ্লয়মেন্ট ও কনফিগারেশন অনুযায়ী পরিবর্তিত হয়, কিন্তু এর গঠন সর্বত্র একই: একটি ঘন, বহু-স্তরযুক্ত জাল, যেখানে একটি রেকর্ডের একটি ফিল্ডকে বিভিন্ন দিক থেকে প্রভাবিত করা যায়। সেই জালের মধ্যে, গুরুত্বপূর্ণ রেকর্ডের পরিবর্তিত ফিল্ডটি খুঁজে বের করা আক্ষরিক অর্থেই খড়ের গাদায় সূঁচ খোঁজার মতো।
দুটি ওয়ার্কফ্লোকে পাশাপাশি রাখলে সুবিধা হয়, কারণ পার্থক্যটা সামান্য নয়।
ম্যানুয়াল পদ্ধতি। এরকম একটি টিকেট এলে সময় গণনা শুরু হয়ে যায়। একজন সাপোর্ট ইঞ্জিনিয়ার টিকেটটি বাছাই করেন, কিন্তু একা ইন্টিগ্রেশনটির সমাধান করতে না পেরে একজন ইন্টিগ্রেশন বিশেষজ্ঞের কাছে পাঠিয়ে দেন। সেই বিশেষজ্ঞ একেবারে শূন্য থেকে শুরু করেন: ইন্টিগ্রেশনটির কাজ কী, তা নতুন করে শেখেন, পুরোনো টিকেটগুলো পড়েন, হাতে করে লগ সংগ্রহ করেন এবং বিভিন্ন তত্ত্ব তৈরি করেন। যেহেতু গ্রাহক সিঙ্ককে দোষারোপ করেছেন, তাই সিঙ্কটিকে ভেঙে বিশ্লেষণ করার একটি প্রবণতা তৈরি হয়। সাহায্য করার জন্য একজন ডেভেলপারকে রোডম্যাপ থেকে সরিয়ে আনা হয়। প্রতিটি চক্র (লগ সংগ্রহ করা, তত্ত্ব তৈরি করা, পরীক্ষা করা, বাতিল করা, পুনরাবৃত্তি) ধীর এবং হাতে করতে হয়, এবং এটিকে ধরে রাখার জন্য কোনো একক রেকর্ডের ইতিহাস থাকে না। এই পোস্টে আগে যেমন বর্ণনা করা হয়েছে, এভাবেই একটি, কখনও কখনও দুটি দিন উধাও হয়ে যায়, এবং সবচেয়ে খারাপ পরিস্থিতি হলো এমন কিছু "ঠিক" করা যা কখনোই ভাঙা ছিল না।
এআই-এর সহায়তায়। এআই একবারে নির্দিষ্ট রেকর্ডের সম্পূর্ণ ফিল্ড-লেভেল ইতিহাস সংগ্রহ করে, পরিবর্তিত হওয়া নির্দিষ্ট ফিল্ডটি চিহ্নিত করে, যে প্রক্রিয়ার মাধ্যমে পরিবর্তনটি আনা হয়েছে তা শনাক্ত করে এবং প্রমাণসহ ইন্টিগ্রেশনের অনুমোদন দেয়। এতে কোনো এস্কেলেশন চেইন নেই, রোডম্যাপে কোনো বাধা নেই, বা অনুমান ও যাচাইয়ের কোনো চক্র নেই। এটি সেই একই সিদ্ধান্তে পৌঁছায় যা একজন সিনিয়র বিশেষজ্ঞ পৌঁছাতে পারতেন, তবে পার্থক্য হলো এটি কয়েক মিনিটের মধ্যেই এবং প্রমাণসহ সেই সিদ্ধান্তে পৌঁছায়।
| কী পরিবর্তন হয় | পূর্বে: ম্যানুয়াল তদন্ত | পরে: এআই-সহায়তায় | প্রভাব |
|---|---|---|---|
| একটি প্রমাণিত উত্তরের সময় এসেছে | কয়েক ঘন্টা, প্রায়শই এক বা দুই দিন (উপরের পরিস্থিতি অনুযায়ী) | মিনিট | ঘণ্টা মিনিটে রূপান্তরিত (আনুমানিক) |
| লোকজনকে টেনে আনা হলো | সাপোর্ট ইঞ্জিনিয়ার, ইন্টিগ্রেশন স্পেশালিস্ট, এবং প্রায়শই রোডম্যাপ থেকে বাদ পড়া একজন ডেভেলপার। | একজন ব্যক্তি দ্বারা পর্যালোচিত একটি এআই পাস | পণ্য সংক্রান্ত কাজের জন্য সিনিয়র ইঞ্জিনিয়ারদের সময় মুক্ত হলো |
| প্রতি টিকিটের খরচ | ফরেনসিক কাজে বেশ কয়েক ঘন্টা সিনিয়র আওয়ার | তার একটি ভগ্নাংশ | প্রতি ঘটনায় কম সহায়তা খরচ (গুণগত অনুমান) |
| উপসংহারে কীভাবে পৌঁছানো হয় | তত্ত্বগুলো হাতে-কলমে, অনুমান ও যাচাইয়ের মাধ্যমে পরীক্ষা করা হয়েছে, পড়ার মতো কোনো পূর্ণাঙ্গ ইতিহাস নেই। | মাঠপর্যায়ের ইতিহাস সরাসরি পড়ুন, প্রমাণই প্রথম। | উচ্চতর আত্মবিশ্বাস, কম ভুল পদক্ষেপ |
| একটি সুস্থ সিস্টেমের জন্য ঝুঁকি | একটি নির্দোষ একীকরণকে থামানো বা পুনর্গঠনের বাস্তব সম্ভাবনা | মূল কারণ সঠিকভাবে চিহ্নিত করা হয়েছে (উৎস পর্যায়ে), ইন্টিগ্রেশন চালু রাখা হয়েছে। | অপ্রয়োজনীয় পুনঃকাজ বা কর্মবিরতি নেই |
| গ্রাহক অভিজ্ঞতা | উদ্বেগজনক অপেক্ষা, “এটি বন্ধ করে দিন” অনুরোধ, সম্ভাব্য ভুল সমাধান | মিনিটের মধ্যেই প্রমাণ-সমর্থিত উত্তর, ইন্টিগ্রেশন সচল থাকে। | আস্থা অটুট, গ্রাহক হারানোর ঝুঁকি হ্রাস পেয়েছে |
সংখ্যাগুলো সম্পর্কে একটি কথা: উপরের সময় এবং খরচের পরিসংখ্যানগুলো আনুমানিক, এগুলো পরিমাপকৃত মানদণ্ড নয়। এগুলো এই পোস্টে বর্ণিত বহু-ধাপের ম্যানুয়াল এস্কেলেশন পদ্ধতির (যা সম্পন্ন হতে এক বা দুই দিন সময় লাগতে পারে) সাথে এই একটিমাত্র টিকেটে এআই-এর নেওয়া কয়েক মিনিটের তুলনা করে। প্রকৃত পার্থক্য টিকেট, টিম এবং স্ট্যাক অনুযায়ী ভিন্ন হবে।
এই গল্পের ভেতরে লুকিয়ে থাকা পরিবর্তন
একক দৃষ্টিকোণ থেকে সরে এসে যা ঘটেছে তার সামগ্রিক চিত্রটি দেখুন।
ইন্টিগ্রেশন সাপোর্টের সবচেয়ে কঠিন অংশটি খুব কমই কোনো বাগ ঠিক করা। আসল কঠিন কাজটা হলো, সমস্যাটি আসলে কার দোষে হচ্ছে তা খুঁজে বের করা। যখন ডেটা ভুল মনে হয়, তখন ইন্টিগ্রেশনকে দোষারোপ করা সবচেয়ে সহজ, কিন্তু দোষমুক্ত করা সবচেয়ে কঠিন। "ইন্টিগ্রেশন নির্দোষ, ডেটা আপস্ট্রিমে অন্য কিছু দ্বারা পরিবর্তিত হয়েছে"—এটা প্রমাণ করা ঠিক সেই ধরনের প্রমাণ-নির্ভর গোয়েন্দা কাজ, যা সিনিয়র ইঞ্জিনিয়ারদের ঘণ্টার পর ঘণ্টা সময় নষ্ট করে, যদি আদৌ কেউ এই কাজটি করার প্রয়োজন মনে করে। বেশিরভাগ সময়ই, ইন্টিগ্রেশনকে দোষারোপ করা হয়, সেটিকে থামিয়ে দেওয়া হয় বা নতুন করে তৈরি করা হয়, এবং আসল কারণটি নীরবে ক্ষতি করে যেতে থাকে।
এআই পরিকাঠামো এই ধারণাটা পাল্টে দেয়। এটি কয়েক মিনিটের মধ্যেই এই টিকিটটিকে ‘জরুরি, এটি বন্ধ করুন’ অবস্থা থেকে ‘ঠিক কী ঘটেছে, তার প্রমাণসহ’ অবস্থায় নিয়ে আসে। এটি অনুমান করেনি। এটি উৎস খুঁজে বের করেছে। এবং এটি আমাদের নিজেদের ইন্টিগ্রেশনকে ত্রুটিমুক্ত করতে ইচ্ছুক ও সক্ষম ছিল, যা শুনতে যতটা সহজ মনে হয়, তার চেয়ে অনেক বেশি কঠিন ও মূল্যবান, কারণ এখানকার আসল উত্তরটি ছিল, “সমস্যাটা সেখানে নয় যেখানে আপনি খুঁজছেন।”
প্ল্যাটফর্মটিকে যখন আমরা ‘এআই-ফার্স্ট’ বলি, তখন আমরা এটাই বোঝাই। এআই কোনো জোড়াতালি দেওয়া চ্যাটবট নয়। প্ল্যাটফর্মের প্রতিটি স্তরে এর প্রভাব রয়েছে: প্রতিটি এক্সিকিউশন, লেখা প্রতিটি ফিল্ড, সোর্স থেকে আসা প্রতিটি ইভেন্ট। এই বিস্তৃতির কারণেই এটি এই প্যারাগ্রাফটি পড়তে যে সময় লাগে, তার মধ্যেই “এই নির্দিষ্ট রেকর্ডটির সাথে আসলে কী ঘটেছে এবং কেন”—এই প্রশ্নের উত্তর দিতে পারে।
কেন আপনি ভাইব-কোড ব্যবহার করে এটি অর্জন করতে পারবেন না
এই অংশেই সরাসরি কথা বলাটা জরুরি।
আপনি অবশ্যই নিজেই একটি সাধারণ, পয়েন্ট-টু-পয়েন্ট ইন্টিগ্রেশন তৈরি করতে পারেন, এবং আধুনিক এআই কোডিং টুলগুলো আগের চেয়ে অনেক দ্রুত এটি চালু করার সুযোগ করে দেয়। ক্লড কোড সেই কোডটি লেখার ক্ষেত্রে সত্যিই অসাধারণ। ভালো দিনে, আপনার তৈরি করা জিনিসটি কাজ করে। সমস্যাটা হয় খারাপ দিনে।
হাতে তৈরি ইন্টিগ্রেশন হলো একটি পাইপ। এটি ডেটা স্থানান্তর করে এবং তারপর ভুলে যায়। এটি কোনো এক্সিকিউশন হিস্ট্রি রাখে না, কখন কী পরিবর্তন হয়েছে তার কোনো ফিল্ড-লেভেল রেকর্ড রাখে না, এবং CRM-এর কোনো ভ্যালু থেকে সেই নির্দিষ্ট সোর্স ইভেন্টের সাথে কোনো লিঙ্কও রাখে না যা এর কারণ। তাই কয়েক মাস পরে, যখন কোনো রেকর্ড ভুল মনে হয় এবং একজন গ্রাহক উত্তর দাবি করেন, তখন তদন্ত করার মতো কিছুই থাকে না। পড়ার মতো কোনো মেমরি নেই। অনুসরণ করার মতো কোনো সূত্র নেই। আপনি এবং আপনার এআই অ্যাসিস্ট্যান্ট দুজনেই আবার অনুমান করতে শুরু করেন, এবং সবচেয়ে সহজ অনুমান হলো পাইপটিকে দোষারোপ করা এবং এটিকে উপড়ে ফেলা শুরু করা।
এটা কোডিং টুলটির সমালোচনা নয়। মূল বিষয় হলো, টুলটিকে কী নিয়ে কাজ করতে হয়। একটি এআই-কে যদি একটি সাধারণ পাইপের দিকে নির্দেশ করা হয়, তবে তার পড়ার মতো কোনো ইতিহাস থাকে না, ফলে সবচেয়ে বুদ্ধিমান মডেলটিও কেবল তত্ত্বকথায় সীমাবদ্ধ হয়ে পড়ে। সেই একই এআই-কে এমন একটি প্ল্যাটফর্মের দিকে নির্দেশ করুন যা প্রতিটি এক্সিকিউশন, প্রতিটি রাইট এবং প্রতিটি সোর্স ইভেন্ট রেকর্ড করেছে, তাহলে এটি সেই ফরেনসিক কাজটি করতে পারবে যা আপনি এইমাত্র তাকে করতে দেখলেন।
APIANT কোনো পাইপ নয়। এটি একটি পরিকাঠামো। এর প্রতিটি এক্সিকিউশন, প্রতিটি রাইট, প্রতিটি সোর্স ইভেন্ট পরিকল্পিতভাবেই ক্যাপচার করা হয়, পর্যবেক্ষণযোগ্য এবং কোয়েরিযোগ্য। এই রেকর্ড করা ইতিহাসই হলো সেই ভিত্তি যা এআই-এর প্রয়োজন। একটি চলমান ইন্টিগ্রেশন এবং একটি বিশ্লেষণযোগ্য ইন্টিগ্রেশনের মধ্যে এটাই হলো পার্থক্য। আপনি ডেটা আদান-প্রদানের জন্য কোনো কিছুকে ভাইব-কোড করতে পারেন। কিন্তু আপনি সেই ফরেনসিক মেমরি এবং প্ল্যাটফর্ম-ব্যাপী পর্যবেক্ষণযোগ্যতাকে ভাইব-কোড করতে পারবেন না, যা সবচেয়ে গুরুত্বপূর্ণ মুহূর্তে এআই-কে মিনিটের মধ্যে সেই ডেটা বিশ্লেষণ করতে সাহায্য করে। একটি ইন্টিগ্রেশন এবং ইন্টিগ্রেশন পরিকাঠামোর মধ্যে এটাই হলো সীমারেখা।
মূল কথা হলো: পুরো কাজটা এআই-ই করেছে।
বিষয়টা স্পষ্টভাবে বলা প্রয়োজন, কারণ এটাই এখানকার আসল দৃষ্টান্ত।
এআই শুধু সাহায্যই করেনি। এটি রোগ নির্ণয়ের কাজটিও করেছে, রেকর্ডের সম্পূর্ণ ইতিহাস পড়ে পরিবর্তিত হওয়া একটিমাত্র ফিল্ডকে আলাদা করেছে। উপরে আপনি যে গ্রাহক উত্তরটি পড়েছেন, সেটিও এটি লিখেছে; যেটিতে শুরুতেই উত্তরটি দেওয়া হয়েছিল এবং সিঙ্ক চালু রাখার ব্যাপারে নিজের অবস্থানে অটল ছিল। আর এই নিবন্ধটিও এটি লিখেছে, যেটি আপনি এই মুহূর্তে পড়ছেন, এবং আপনাকে পুরো বিষয়টি আবার ব্যাখ্যা করছে।
একটি এআই, তিনটি চাকরি, যার সবগুলোই একই জিনিসের উপর নির্ভরশীল: এমন একটি প্ল্যাটফর্ম যা সবকিছু মনে রাখে এবং এআই-কে সেই স্মৃতি থেকে প্রশ্ন করার সুযোগ দেয়। এটাই এর মূল আকর্ষণ। এর মানে এই নয় যে, “এআই বুদ্ধিমান”। এআই এবং এর সাথে সমন্বিত পরিকাঠামোই কফি ঠান্ডা হওয়ার আগেই একটি ভীতিকর সমস্যার সমাধান করে দিয়েছে।
আপনি যদি সফটওয়্যার বিক্রি করেন তবে এর মানে কী?
যদি আপনার প্রোডাক্ট অন্যান্য টুলের সাথে সংযুক্ত হয়, এবং এখন প্রায় প্রতিটি গুরুত্বপূর্ণ SaaS প্রোডাক্টই তা করে, তাহলে ইন্টিগ্রেশনগুলো আপনার প্রবৃদ্ধির সবচেয়ে বড় চালিকাশক্তি এবং সাপোর্টের ক্ষেত্রেও সবচেয়ে বড় বোঝা। আপনার দেওয়া প্রতিটি কানেক্টরই একটি নতুন ক্ষেত্র, যা ভেঙে যেতে পারে বা ভাঙা বলে মনে হতে পারে। এর প্রতিটিই আপনার সাপোর্ট কিউতে যুক্ত হয় এবং আপনার সেরা ইঞ্জিনিয়ারদের রোডম্যাপ থেকে সরিয়ে আনে। আর এই টিকেটগুলোর একটি বড় অংশ আপনার দোষেই হয় না। এগুলো হলো আপস্ট্রিম পরিবর্তন, থার্ড-পার্টি অ্যাপ এবং সোর্স-সাইডের সম্পাদনা, যা যে আপনার করা নয়, তা আপনাকে প্রমাণ করতে হয়।
সমস্যাটা ঠিক এটাই। বিল্ডারদের জন্য অ্যাপিয়েন্ট, হোয়াইট লেবেল অপসারণ করার জন্যই তৈরি করা হয়েছে।
আপনি আপনার নিজস্ব হোয়াইট-লেবেল ইন্টিগ্রেশন প্ল্যাটফর্ম পাবেন, যা আপনার ব্র্যান্ডের অধীনে চলবে এবং এর নিচে এই একই এআই পরিকাঠামো থাকবে। আপনার গ্রাহকরা সেই গভীর ও নির্ভরযোগ্য ইন্টিগ্রেশনগুলো পাবেন, যা তারা দাবি করছেন। আপনার টিমকে সকাল ৯টায় প্রতিটি অভিযোগ হাতে ধরে নির্ণয় করার কাজ থেকে মুক্তি দেওয়া হয়। এআই ইতিহাস পড়ে, মূল কারণ খুঁজে বের করে এবং একটি সুনির্দিষ্ট, প্রমাণ-সমর্থিত উত্তর প্রদান করে, সমাধানটি আপনার হোক বা আপস্ট্রিমের কোনো কিছুর হোক।
এই গল্পের গ্রাহক মিনিটের মধ্যেই একটি সঠিক ও প্রমাণ-সমর্থিত উত্তর পেয়েছিলেন, একটি সচল ইন্টিগ্রেশন চালু রেখেছিলেন এবং ভয়ে একটি ভালো সিস্টেম বন্ধ করা থেকে বিরত ছিলেন। কোনো বিশেষজ্ঞ ক্ষতিগ্রস্ত হননি। কোনো রোডম্যাপও লাইনচ্যুত হয়নি। এখন কল্পনা করুন, আপনার লোগোসহ আপনার সম্পূর্ণ ইন্টিগ্রেশন ক্যাটালগ জুড়ে এটাই ডিফল্ট হিসেবে থাকছে।
নিজেই দেখে নিন
এটা একটা টিকিট মাত্র। আমরা প্রতিদিন এরকম ইন্টিগ্রেশন চালাই, এবং এর ফলাফল একই থাকে: কঠিন অংশটা, অর্থাৎ ফরেনসিক অংশটা, যেটা করতে আগে ঘণ্টার পর ঘণ্টা সময় লাগত, তা এআই করে ফেলে, আর এখন তা করে মিনিটের মধ্যে। আপনার ব্র্যান্ড গ্রাহক সম্পর্ক বজায় রাখে। আপনার ইঞ্জিনিয়াররা তাদের কাজে মনোযোগ ধরে রাখতে পারে।
আপনি যদি এমন একটি SaaS কোম্পানি হন যা ইন্টিগ্রেশন সাপোর্টের বাড়তি খরচ দিতে দিতে এবং একটি একটি করে টিকেট জিতে আপনার ইন্টিগ্রেশনগুলোকে নির্দোষ প্রমাণ করতে করতে ক্লান্ত, তাহলে আসুন আমরা আপনাকে দেখাই আপনার নিজস্ব হোয়াইট-লেবেল APIANT For Builder সার্ভারটি কেমন হবে।
এই কেস স্টাডিটি বেনামী করা হয়েছে: প্রতিটি ব্যক্তি, ইমেল ঠিকানা, আইডি এবং অবস্থান পরিবর্তন করা হয়েছে। প্ল্যাটফর্মগুলো বাস্তব। সাধারণ পাঠকদের জন্য প্রযুক্তিগত বিবরণ সরলীকরণ করা হয়েছে। এই নিবন্ধটি এবং এর সাথে সংযুক্ত সাপোর্ট রিপ্লাই—উভয়ই এআই দ্বারা লেখা হয়েছে।
পড়তে থাকুন
আমরা একটি এআই-কে একটি সাপোর্ট টিকেট দিয়েছিলাম। এটি ইন্টিগ্রেশনটি পুনর্গঠন করে প্রক্রিয়াটি সম্পূর্ণ করেছে।
একজন গ্রাহক ৮,৪০০ ডলার পরিশোধ করেছিলেন, কিন্তু সিআরএম-এ ৪০০ ডলার দেখানো হচ্ছিল। আমরা বাগটি এপিআইএএনটি (APIANT)-এর একটি এআই (AI)-এর কাছে হস্তান্তর করি এবং এটিকে শুরু থেকে শেষ পর্যন্ত সমস্যাটি নির্ণয়, পুনর্গঠন এবং সমাধানটি পরীক্ষা করতে দিই।
ক্লড কোডের সাথে এআই-ফার্স্ট ইন্টিগ্রেশন ইঞ্জিনিয়ারিং: একটি বাস্তব ডিবাগ সেশন
আসল প্রম্পটগুলো সহ একটি বাস্তব APIANT ডিবাগিং সেশন। দেখুন কীভাবে একটি AI একটি সিibling ইন্টিগ্রেশন এবং চার বছরের ভার্সন হিস্ট্রি পড়ে, এবং দেখুন কীভাবে একজন নির্মাতার সহজাত ধারণা এমন একটি রিগ্রেশন থামিয়ে দেয় যা কোডবেসে কখনও রেকর্ড করা হয়নি।
ক্লড কোড ব্যবহার করে CSV ফাইল থেকে স্বয়ংক্রিয়ভাবে HubSpot প্রোপার্টি তৈরি করুন
APIANT-এর উপর নির্মিত এই বিনামূল্যের ইম্পোর্ট অটোমেশন ব্যবহার করে কীভাবে স্বয়ংক্রিয়ভাবে HubSpot প্রপার্টি (কন্টাক্ট, ডিল বা কোম্পানি) তৈরি করবেন।