অনলাইন স্টোরে AI কাস্টমার সার্ভিস: কোথায় কাজে লাগে (WISMO, রিটার্ন), কোথায় ক্ষতি করে

একটি মাঝারি অনলাইন স্টোরের সাপোর্ট লিড লম্বা সেল-উইকেন্ডের পর সোমবার সকাল ৭টা ৫০-এ ৪১০টি অপঠিত টিকিটের ইনবক্স থেকে এলোমেলোভাবে বিশটি খুললেন। চৌদ্দটিতেই একই কথা: "আমার order কোথায়?" তিনটি জানতে চায় জ্যাকেটটা ছোট হয় কি না। দুটি return করতে চায়। একজন দুবার চার্জ হয়েছেন এবং বেশ রেগে আছেন।

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

এই লেখা সেই সীমারেখা সচেতনভাবে টানার কথা। ২০২৬ সালে AI customer সার্ভিস কাজ করে তখনই, যখন সে লাইভ order ও courier data থেকে উত্তর দেয়, লিখিত নীতির ভেতরে থেকে কাজ করে, আর পুরো ঘটনা সঙ্গে দিয়ে মানুষের হাতে ছেড়ে দেয়। ক্ষতি হয় সেখানেই, যেখানে সে টাকা, অধিকার বা অনুভূতি নিয়ে আন্দাজে কথা বলে। নিচে আছে কোন ইনটেন্ট কোন দিকে পড়ে, "order কোথায়" উত্তরটা কীভাবে তৈরি হয়, হিসাবসহ একটি উদাহরণ, AI পরিচয় জানানোর নিয়ম এবং চালু করার পরিকল্পনা।

AI সাপোর্ট কোথায় কাজে লাগে, কোথায় ক্ষতি করে

কাজের ভাগটা "সহজ বনাম জটিল" নয়। প্রশ্ন একটাই: উত্তরটা কি আপনার system-এ আগে থেকেই আছে? "আমার order কোথায়?" (সাপোর্ট ইন্ডাস্ট্রিতে একে বলে WISMO) প্রশ্নের উত্তর order টেবিলের একটি রো আর courier-এর একটি স্ট্যাটাসেই আছে। সিদ্ধান্ত নেওয়ার কিছু নেই। যন্ত্রকে শুধু তথ্য আনতে, মিলিয়ে দেখতে আর ভদ্রভাবে লিখতে হয়।

নীতির মেয়াদের ভেতরের return-ও একইভাবে চলে। নিয়ম লেখা আছে (৩০ দিন, ব্যবহার না করা, আসল প্যাকেজিং), order-এর তারিখ database-এ আছে, ফলাফল একটি return অনুমোদন আর একটি লেবেল। পণ্যের প্রশ্ন দাঁড়ায় catalog-এর ওপর: সাইজ, কাপড়, ভ্যারিয়েন্ট অনুযায়ী stock।

ক্ষতিটা হয় উল্টো প্রান্তে। নীতির বাইরে refund মানে টাকা নিয়ে সিদ্ধান্ত। রাগী গ্রাহক আগে চান স্বীকৃতি, তারপর তথ্য। ভোক্তা-অধিকারের প্রশ্ন আসলে আইনি প্রশ্ন। email বা ফোন নম্বর বদলানোর মতো account পরিবর্তন পরিচয়ের প্রশ্ন। প্রতিটি ক্ষেত্রে ভুল উত্তরের দাম বেশি, আর গুছিয়ে বলা ভুল উত্তর আরও বিপজ্জনক, কারণ তা শোনায় প্রতিশ্রুতির মতো।

ঝুঁকিটা কাল্পনিক নয়। Moffatt v. Air Canada (২০২৪) মামলায় ব্রিটিশ কলম্বিয়ার একটি ট্রাইব্যুনাল বলেছে, website-এর চ্যাটবট শোকজনিত ভাড়া-ছাড় নিয়ে ভুল পরামর্শ দিলে দায় এয়ারলাইনেরই। ক্ষতিপূরণ ধার্য হয় $812.02, আর বটকে আলাদা পক্ষ ধরার যুক্তি টেকেনি। আপনার সহকারী আপনার নামে যা বলে, সেটা আপনারই কথা।

সাপোর্ট ইনটেন্টের ঝুঁকি-তালিকা

কিছু কনফিগার করার আগে স্টোরে আসা প্রতিটি ইনটেন্ট তিনটি লেনের একটিতে বসান। আসল ডিজাইনের কাজ এটাই। software-এর সেটিং পরে আপনা থেকে আসে।

লেন	সাধারণ ইনটেন্ট	AI কী করতে পারে	ভুলের মূল্য
স্বয়ংক্রিয় উত্তর	order স্ট্যাটাস, ডেলিভারির আনুমানিক সময়, return নীতি, পণ্য ও সাইজের প্রশ্ন	data পড়া, উত্তর দেওয়া, নীতির ভেতরে return শুরু করা	একটা ভুল বাক্য, শুধরে নেওয়া সহজ
AI খসড়া, মানুষ অনুমোদন	এক্সচেঞ্জ, ডিসপ্যাচের আগে ঠিকানা বদল, বাতিল, সৌজন্য ভাউচার	কাজটা তৈরি করে রাখা, অনুমোদন দেবেন একজন মানুষ	ভুল parcel বা ভুল ক্রেডিট
শুধু মানুষ	নীতির বাইরে refund, ক্ষতিগ্রস্ত বা হারানো পণ্যের দাবি, রাগী বা অসহায় গ্রাহক, আইনি ও পরিচয় যাচাইয়ের প্রশ্ন	সারসংক্ষেপ লিখে সঠিক জনের কাছে পাঠানো, সিদ্ধান্ত নয়	টাকা, আস্থা বা আইনি ঝুঁকি

লেনগুলো ব্যাক-অফিস agent-এর জন্য ব্যবহৃত একই সিঁড়ির সঙ্গে মেলে: পড়া নিরাপদ, খসড়া যাচাই করে নিতে হয়, টাকার কাজে থাকে অনুমোদনের দেয়াল। বিস্তারিত যুক্তি চাইলে পড়ুন ERP-তে AI agent: কী নিরাপদে করা যায়।

স্ট্যাটিক FAQ বট কেন WISMO-তে ব্যর্থ

হতাশ করা বেশির ভাগ সাপোর্ট বট বানানো হয়েছে একটা ডকুমেন্টের ওপর: FAQ, shipping নীতি, কিছু পুরোনো উত্তর। গ্রাহক জানতে চাইলেন ১০৪৮২ নম্বর parcel কোথায়। বট ডেলিভারি-সময় নিয়ে এক অনুচ্ছেদ শোনাল। সে parcel-টা দেখতেই পায় না, তাই যে প্রশ্নের উত্তর জানে সেটারই জবাব দেয়, যেটা জিজ্ঞেস করা হয়েছে সেটার নয়।

সমাধান হলো লাইভ data-র ওপর দাঁড়ানো (grounding)। সহকারী পায় শুধু পড়ার দুটি টুল: একটি order নম্বর ও মিলে যাওয়া email বা ফোন দিয়ে order আনে, অন্যটি সেই order-এর parcel-এর courier স্ট্যাটাস আনে। উত্তর লেখা হয় শুধু ওই টুলগুলো যা ফেরত দিয়েছে তা থেকে। টুল কিছু না দিলে সে সেটাই বলে এবং মানুষের হাতে ছেড়ে দেয়। স্মৃতি থেকে ফাঁক ভরার অনুমতি তার নেই।

দ্বিতীয় উপাদান তাজা তথ্য। courier-এর স্ট্যাটাস সময়ের ছাপসহ একটি তথ্য। শেষ স্ক্যান ৩১ ঘণ্টা আগের হলে "আপনার parcel পথে আছে" আসলে অনুমান। নিচের ফ্লো পুরোনো স্ট্যাটাসকে আশ্বাস দেওয়ার কারণ ধরে না, ধরে আবার যাচাই বা এসকেলেট করার কারণ হিসেবে।

WISMO উত্তরের গঠন

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

1. চেনা। order নম্বরের সঙ্গে ফাইলে থাকা email বা ফোন মেলান। না মিললে বিবরণ নয়। সহকারী একবার আবার জিজ্ঞেস করে, তারপর মানুষের কথা বলে।
2. শিপ হয়েছে? order এখনো "প্রসেসিং"-এ থাকলে সৎ উত্তর হলো order-এ থাকা প্যাকিংয়ের আনুমানিক সময়, কারণ courier-এর data তখনো নেই।
3. তাজা? courier-এর শেষ event ও তার সময় দেখুন। আপনার সীমার (দেশের ভেতরের parcel-এ ধরা যাক ২৪ ঘণ্টা) চেয়ে পুরোনো হলে courier API-তে একবার রিফ্রেশ করুন। তাতেও না হলে হস্তান্তর।
4. দেরি? আজকের তারিখ order-এ রাখা ডেলিভারির প্রতিশ্রুতির সঙ্গে মেলান। এক-দুদিন দেরি হলে সহকারী নতুন সময় জানায়। আপনার সীমার বেশি দেরি হলে সে উত্তর দেওয়া থামিয়ে এসকেলেট করে।
5. প্রসঙ্গসহ হস্তান্তর। টিকিট পৌঁছায় order নম্বর, পণ্য, courier-এর event, প্রতিশ্রুত তারিখ ও এ পর্যন্ত কথোপকথন নিয়ে। agent-কে যেন আর কখনো জিজ্ঞেস করতে না হয়, "আপনার order নম্বর কত?"

গ্রাহকের অভিজ্ঞতার বড় অংশ জেতা-হারা হয় হস্তান্তরে। যে agent টিকিট খুলে দেখেন "parcel ১০৪৮২, প্রতিশ্রুত ১৪ আগস্ট, শেষ স্ক্যান ১৬ আগস্ট সর্টিং হাবে, গ্রাহক দুবার জিজ্ঞেস করেছেন, মেজাজ: বিরক্ত", তিনি একটাই কাজের উত্তর লিখতে পারেন। কাঁচা চ্যাট ট্রান্সক্রিপ্ট হাতে পেলে তাঁকে শুরু করতে হয় শূন্য থেকে।

নীতির ভেতরে return ও এক্সচেঞ্জ

return মানে একটি ছোট স্টেট মেশিন: অনুরোধ, অনুমোদন, লেবেল ইস্যু, প্রাপ্তি, পরিদর্শন, refund বা এক্সচেঞ্জ। নীতি যদি গদ্য না হয়ে system-এর চালানো যায় এমন চেক হিসেবে লেখা থাকে, তাহলে প্রথম তিন ধাপ AI নিরাপদে সামলাতে পারে।

• order return-এর সময়সীমার মধ্যে ডেলিভার হয়েছে (ডেলিভারির তারিখের সঙ্গে আজকের তারিখ মেলান)।
• পণ্যের ক্যাটাগরি ফেরতযোগ্য (অন্তর্বাস আর কাস্টম পণ্য অনেক সময় নয়)।
• কারণের কোড আপনার তালিকার একটি: ভুল সাইজ, ত্রুটিপূর্ণ, বর্ণনার সঙ্গে মেলে না, মত বদলেছে।
• পণ্যটি আগে ফেরত দেওয়া হয়নি।

সব চেক পাস করলে সহকারী return অনুরোধ তৈরি করে, লেবেল দেয় এবং পরের ধাপ বুঝিয়ে বলে। একটি ফেল করলে সে তর্ক করে না। নিয়মটা একবার ব্যাখ্যা করে, মানুষের পর্যালোচনার প্রস্তাব দেয় এবং কোন চেক ফেল করেছে তা উল্লেখ করে টিকিট পাঠিয়ে দেয়। refund নিজে থাকে অনুমোদনের পেছনে, অন্তত একটি অঙ্কের সীমার পেছনে, আর তা চলে কেবল গুদাম পণ্যটি গ্রহণ-চিহ্নিত করার পর।

এক্সচেঞ্জ এক ধাপ ওপরের লেনে, কারণ তা stock-এ হাত দেয়। সহকারী এক্সচেঞ্জ তৈরি করে রাখতে পারে (L-এর বদলে M, shipping লোকেশনে stock আছে), নিশ্চিত করেন একজন মানুষ।

হিসাবসহ উদাহরণ: এক মাস, ৬,০০০ টিকিট

নিচের সংখ্যাগুলো উদাহরণ হিসেবে বানানো, শুধু হিসাবটা দেখানোর জন্য। আপনার মিশ্রণ আলাদা হবে, তাই এক মাসের নিজস্ব ট্যাগ-করা টিকিট দিয়ে এগুলো বদলে নিন।

ইনটেন্ট	টিকিট	AI মেটায়	AI-এর মেটানো
order কোথায়	2,100	85%	1,785
return বা এক্সচেঞ্জ শুরু	900	60%	540
পণ্য ও সাইজের প্রশ্ন	900	70%	630
বাতিল বা ঠিকানা বদল	480	25%	120
refund বিতর্ক ও ক্ষতির দাবি	900	0%	0
account, আইনি ও অন্যান্য	720	0%	0
মোট	6,000	51%	3,075

এবার খরচ। ধরা যাক মানুষের সামলানো একটি টিকিটে মোট খরচ $4.00 (লোডেড agent-ঘণ্টার প্রায় সাত মিনিট আর টুলিং), আর AI-এর মেটানো টিকিটে $0.45 (মডেল ব্যবহার, order লুকআপ, platform ফি)। দুটি অঙ্কই উদাহরণের অনুমান।

• আগে: 6,000 × $4.00 = $24,000।
• পরে: 3,075 × $0.45 = $1,384, সঙ্গে 2,925 × $4.00 = $11,700, মোট $13,084।
• টিকিটপ্রতি গড় খরচ $4.00 থেকে নামে প্রায় $2.18-এ, সাশ্রয় প্রায় ৪৫%। ডিফ্লেকশন রেট ৫১% হলেও সাশ্রয় তার সমান হয় না, কারণ AI বিনা খরচে চলে না।

দ্বিতীয় প্রভাব প্রথম সাড়ার সময়ে। ধরুন দল একই, আগে মধ্যম প্রথম সাড়া ৫ ঘণ্টা। AI তার ৩,০৭৫টি টিকিটের উত্তর দেয় এক মিনিটের কম সময়ে। মানুষের queue ৬,০০০ থেকে কমে ২,৯২৫-এ নামে, ফলে সেগুলোর মধ্যম অপেক্ষা নেমে আসে প্রায় ২ ঘণ্টায়। সাশ্রয়ের চেয়েও বড় কথা, শুরুর সেই রাগী গ্রাহক এখন বিকেলে নয়, সকালেই একজন মানুষের কাছে পৌঁছান।

টোন, ভাষা আর অনুমতি

অনুমতি আগে। সহকারীকে order, parcel, catalog ও নীতিতে পড়ার অধিকার দিন, আর লেখার অধিকার দিন শুধু সংকীর্ণ কয়েকটি কাজে: return অনুরোধ তৈরি, নোট যোগ, টিকিট রাউট। টাকা সরানো বা গ্রাহকের প্রোফাইল বদলানোর যেকোনো কাজ যাবে লগসহ অনুমোদনের ধাপ দিয়ে, যেমনটি আছে AI গার্ডরেইল: অনুমোদন, audit ট্রেইল ও human in the loop লেখায়।

ভাষা এখানে নীরব সুবিধা। যে স্টোরের গ্রাহকরা তিন ভাষায় লেখেন, সেখানে সাধারণত এক ভাষার লোক থাকে। একই order data-র ওপর দাঁড়ানো সহকারী গ্রাহকের নিজের ভাষায় উত্তর দিতে পারে, যা সত্যিকারের সেবার উন্নতি। প্রতি মাসে একজন নেটিভ স্পিকারকে কিছু উত্তর দেখিয়ে নিন, কারণ যান্ত্রিক সাবলীলতা ভদ্রতা আর ভাষার স্তরের ছোট ভুল ঢেকে রাখে।

টোনের নিয়ম হোক ছোট ও পরীক্ষাযোগ্য: একবার দুঃখ প্রকাশ, তথ্য বলা, পরের ধাপ বলা, তারিখ দেওয়া। system যে প্রতিশ্রুতি রাখতে পারে না তা নিষিদ্ধ ("কালই পৌঁছে যাবে"), যদি না তারিখটা কোনো টুল থেকে এসে থাকে। গ্রাহক রাগ দেখালে বা "আইনজীবী", "চার্জব্যাক", "প্রতারণা" শব্দ লিখলে সহকারী থেমে গিয়ে এসকেলেট করে। খারাপ দিনের গ্রাহকের দরকার চ্যাটবট নয়।

জানিয়ে দিন যে এটি AI

গ্রাহক যন্ত্রের সঙ্গে কথা বলছেন কি না, তা জানান। এটি সবখানেই ভালো রীতি, আর ইউরোপীয় ইউনিয়নে আইন। EU AI Act-এর Article 50 অনুযায়ী যে AI system সরাসরি মানুষের সঙ্গে ইন্টারঅ্যাক্ট করে, তার প্রদানকারীকে এমনভাবে ডিজাইন করতে হবে যাতে ব্যক্তি জানতে পারেন তিনি AI-এর সঙ্গে কথা বলছেন, যদি না পরিস্থিতি থেকেই তা স্পষ্ট হয়। Article 50-এর স্বচ্ছতার বাধ্যবাধকতা কার্যকর ২ আগস্ট ২০২৬ থেকে। EU-এর ডিজিটাল ওমনিবাস হাই-রিস্ক system-এর নিয়ম পিছিয়ে দিয়েছে, কিন্তু Article 50-এর প্রকাশের দায় সরেনি। শুধু তৈরি-করা কনটেন্টে মেশিন-রিডেবল চিহ্ন দেওয়ার একটি ছোট ছাড় চলবে ২ ডিসেম্বর ২০২৬ পর্যন্ত, আর সেটি সিনথেটিক মিডিয়ার ব্যাপার, চ্যাটের নয়।

বাস্তবে: চ্যাট উইজেটে দৃশ্যমান লেবেল, প্রথম বার্তায় সেটা বলে দেওয়া, আর এক ক্লিকে মানুষের কাছে যাওয়ার পথ। ভাষা সহজ রাখুন ("আমি স্টোরের AI সহকারী। order দেখতে আর return শুরু করতে পারি। চাইলে যেকোনো সময় একজন মানুষকে ডাকুন।")। অন্য দেশ থেকে EU-তে বিক্রি করলে ধরে নিন এটি আপনার ওপরও খাটে, আর জাতীয় নিয়ম আইনজীবীর সঙ্গে মিলিয়ে নিন। বিস্তারিত আছে EUR-Lex-এ AI Act-এর পাঠে।

আস্থা অর্জনের রোলআউট পরিকল্পনা

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

1. সপ্তাহ ১-২: মাপুন। এক মাসের টিকিট ইনটেন্ট ধরে ট্যাগ করুন এবং নিজের মিশ্রণ, প্রথম সাড়ার সময় আর টিকিটপ্রতি খরচ হিসাব করুন।
2. সপ্তাহ ৩-৪: শ্যাডো মোড। AI WISMO ও নীতির প্রশ্নের খসড়া বানায়, agent পাঠান বা সম্পাদনা করেন। কতবার খসড়া অপরিবর্তিত যাচ্ছে তা দেখুন।
3. সপ্তাহ ৫-৬: WISMO চালু। শুধু order-স্ট্যাটাস ফ্লো-র জন্য স্বয়ংক্রিয় উত্তর চালু করুন, সঙ্গে পরিচয়ের লেবেল আর পুরোনো-স্ট্যাটাসের নিয়ম। প্রতি সপ্তাহে ৫০টি কথোপকথন পর্যালোচনা করুন।
4. সপ্তাহ ৭-৮: নীতির ভেতরে return। চারটি চেক আর refund-এ অঙ্কের সীমা দিয়ে return শুরু যোগ করুন।
5. সপ্তাহ ৯ থেকে: সাবধানে বাড়ান। catalog-এর ওপর দাঁড় করিয়ে পণ্য ও সাইজের প্রশ্ন যোগ করুন। নীতির বাইরে refund, অভিযোগ আর আইনি প্রশ্ন মানুষের হাতেই থাকুক।

কী মাপবেন

শুধু ডিফ্লেকশন দেখা অর্থহীন। গ্রাহককে হাল ছাড়তে বাধ্য করা বটও "ডিফ্লেক্ট" করে। তাই এগুলো একসঙ্গে দেখুন:

• সমাধানের হার: AI যেসব কথোপকথন বন্ধ করেছে, যেগুলো আর খোলা হয়নি এবং ৭ দিনের মধ্যে মানুষের সঙ্গে যোগাযোগও হয়নি।
• গ্রাহক সন্তুষ্টি (CSAT): AI-সামলানো বনাম মানুষ-সামলানো টিকিটে। AI অনেক কম পেলে তার পরিধি ছোট করুন।
• হস্তান্তরের মান: কত শতাংশ হস্তান্তরে agent-কে মৌলিক তথ্য আবার চাইতে হয়নি।
• ভুল উত্তরের হার: সাপ্তাহিক নমুনা থেকে ইনটেন্ট ধরে গোনা, সঙ্গে থামার নিয়ম: সীমা ছাড়ালে ওই ইনটেন্ট আবার খসড়ায় ফিরবে।
• সমাধানপ্রতি খরচ আর প্রথম সাড়ার সময়: সামগ্রিকভাবে এবং মানুষের queue-য়ের জন্য আলাদা করে।

সোমবার সকালে ফেরা

সেই ৪১০টি অপঠিত টিকিটে ফিরুন। লেনগুলো থাকলে প্রায় অর্ধেকের উত্তর তিনি ল্যাপটপ খোলার আগেই চলে গেছে: order স্ট্যাটাস, সাইজের প্রশ্ন, নীতির ভেতরের return। বাকিগুলো সাজানো, প্রতিটি আসছে order, courier-এর ইতিহাস আর এক লাইনের সারসংক্ষেপ নিয়ে। দুবার চার্জ হওয়া গ্রাহক তাঁর তালিকার সবার ওপরে, ডুপ্লিকেট payment আগে থেকেই চিহ্নিত।

তিনি সকালটা কাটান refund, মেরামত আর মানুষের পেছনে। সহকারীর সকাল কাটে খোঁজাখুঁজিতে। কেউ কারও কাজে ভাগ বসাচ্ছে না।

মূল কথা

• AI সাপোর্ট কাজ করে সেখানে, যেখানে উত্তর আগে থেকেই আপনার order, courier ও নীতির data-য় আছে। টাকা, অধিকার বা আবেগ নিয়ে আন্দাজ করতে হলে সে ব্যর্থ হয়।
• উত্তর দাঁড় করান লাইভ টুলের ওপর, স্ট্যাটিক FAQ-এর ওপর নয়, আর পুরোনো courier স্ট্যাটাসকে রিফ্রেশ বা এসকেলেশনের কারণ ধরুন।
• কিছু কনফিগার করার আগে ইনটেন্টগুলো স্বয়ংক্রিয় উত্তর, অনুমোদন ও শুধু-মানুষ লেনে ভাগ করুন। পড়ার অধিকার দিন বিস্তৃত, লেখার অধিকার সংকীর্ণ।
• হস্তান্তর সবসময় প্রসঙ্গসহ: order, courier-এর event, প্রতিশ্রুত তারিখ আর এ পর্যন্ত কথোপকথন।
• গ্রাহককে জানান যে তিনি AI-এর সঙ্গে কথা বলছেন। EU-তে Article 50-এর দায় ২ আগস্ট ২০২৬ থেকে কার্যকর।
• শুধু ডিফ্লেকশন নয়, সমাধান, সন্তুষ্টি, ভুল উত্তরের হার আর সমাধানপ্রতি খরচ একসঙ্গে মাপুন।

আনিছুর রহমান একজন সফটওয়্যার আর্কিটেক্ট এবং StoreConsole-এর নির্মাতা। বাড়তে থাকা ব্যবসার জন্য তিনি কমার্স ও ERP সিস্টেম ডিজাইন করেন — বিশেষ মনোযোগ event-driven আর্কিটেকচার, ডেটার নির্ভুলতা আর নিজের সার্ভারে চালানো সিস্টেমের ওপর।