Customer-এর প্রশ্নের দ্রুত উত্তর দিতে AI translation ব্যবহার করা সুবিধাজনক। কিন্তু “কাল delivery হবে” ভুল অনুবাদ হয়ে “কালকের মধ্যে delivery নিশ্চিত” হলে business এমন promise করে ফেলতে পারে যা রাখা সম্ভব নয়। Product model, টাকা, date, return condition ও ভদ্রতার tone—সবই customer-এর সিদ্ধান্তে প্রভাব ফেলে। তাই translated message-কে final উত্তর নয়, review করার draft হিসেবে ধরুন। নিচের workflow ছোট online business, support desk বা local service team-কে বাংলা এবং English customer message পাঠানোর আগে অর্থ ও action ঠিক রাখতে সাহায্য করবে।

Original message আগে পরিষ্কার করুন

অস্পষ্ট source text থেকে নির্ভুল translation আশা করা যায় না। “ওটা আজ হবে না” লিখলে “ওটা” কোন order বা service বোঝাচ্ছে AI জানে না। Order number, product name, date এবং expected action স্পষ্ট করে source message লিখুন। এক বাক্যে অনেক শর্ত জুড়বেন না। Internal abbreviation যেমন “RTO” customer বোঝেন কি না দেখুন। Original message-এ ভুল price বা policy থাকলে translation সেই ভুলই অন্য ভাষায় পৌঁছে দেবে। তাই প্রথম approval source content-এর, দ্বিতীয় approval translation-এর।

Product term-এর ছোট glossary বানান

Google Cloud Translation glossary documentation domain-specific term consistent রাখার জন্য custom dictionary ব্যবহারের কথা বলে। আপনার tool-এ glossary feature না থাকলেও একটি shared sheet রাখা যায়। Brand name, model, feature, delivery status, refund term এবং যেসব নাম translate হবে না সেগুলি লিখুন। যেমন “Store Credit” কে কখন “স্টোর ক্রেডিট” বলা হবে আর কখন policy-র approved Bengali phrase হবে তা একবার ঠিক করুন। একই term কখনও বাংলা, কখনও আলাদা English phrase হলে customer বিভ্রান্ত হন।

Meaning review-এ চারটি anchor ধরুন

প্রথম pass-এ grammar polish না করে চারটি বিষয় মিলান: কে কাজ করবে, কী কাজ হবে, কখন হবে এবং কোনো শর্ত আছে কি না। “আপনি parcel পাঠালে আমরা inspect করব” আর “আমরা parcel পাঠিয়ে inspect করব” দেখতে কাছাকাছি, দায়িত্ব সম্পূর্ণ আলাদা। Negative word বাদ গেছে কি না দেখুন; “refund available নয়” থেকে “নয়” হারালে অর্থ উল্টে যায়। Number, currency, unit, phone number ও tracking code character ধরে মিলিয়ে নিন। AI যেন Bengali digit ও English digit বদলে কোনো value নষ্ট না করে।

Tone business পরিস্থিতির সঙ্গে মিলান

শব্দের অর্থ ঠিক হলেও tone ভুল হতে পারে। Complaint-এর উত্তরে অতিরিক্ত cheerful emoji customer-কে অসম্মানজনক লাগতে পারে। আবার routine delivery update খুব formal হলে অস্বাভাবিক শোনায়। Team-এর তিনটি tone sample রাখুন: সাধারণ তথ্য, দেরির জন্য apology এবং action চাওয়া। “দুঃখিত” বলার পরে কী করবেন ও কবে update দেবেন সেটি যোগ করুন। Customer-এর ভাষা নকল করতে গিয়ে slang বা অসম্মানজনক সম্বোধন ব্যবহার করবেন না। সহজ “আপনি” সাধারণত নিরাপদ; brand voice অনুযায়ী approved form বেছে নিন।

একটি বাস্তব message তিন ধাপে দেখুন

ধরুন customer লিখেছেন, “আমি M-24 blue order করেছিলাম, black এসেছে।” Source reply: “ভুল item-এর ছবি ও label পাঠান; verify করে আগামী working day-এ replacement option জানাব।” AI যদি “replacement পাঠাব” লেখে, তাহলে verification-এর আগেই promise হয়ে গেল। Reviewer glossary দেখে M-24 অপরিবর্তিত রাখবেন, “working day” approved Bengali-তে লিখবেন এবং action sequence মিলাবেন। Final reply হতে পারে: “দুঃখিত। ভুল item ও parcel label-এর পরিষ্কার ছবি পাঠাবেন। যাচাই করে আগামী working day-এ replacement-এর available option জানাব।” এটি একটি example, universal policy নয়।

High-risk message-এ human approval বাধ্যতামূলক করুন

Payment dispute, refund refusal, medical বা safety instruction, legal notice এবং account access-এর message routine translation নয়। এগুলিতে qualified person source fact ও translated wording দুটোই দেখবেন। Google-এর custom translation overview বলে general model domain-specific content-এ সবসময় সেরা নাও হতে পারে; example translation ও domain context দিয়ে output adapt করা যায়। তবু tool configuration human accountability সরায় না। Reviewer-এর নাম, revision এবং approval time রাখুন।

Highlighted pre-send checklist

  • Reference: order number, model এবং customer-এর নাম source record-এর সঙ্গে মিলেছে।
  • Meaning: কে, কী, কখন এবং কোন শর্তে কাজ করবে তা বদলায়নি।
  • Numbers: price, date, quantity, phone ও tracking code character ধরে দেখা হয়েছে।
  • Glossary: brand, product ও policy term approved form-এ আছে।
  • Tone: apology, request এবং promise পরিস্থিতি অনুযায়ী স্বাভাবিক।
  • Links: customer-facing URL সঠিক page-এ খুলছে; private admin link নেই।
  • Approval: high-risk message দায়িত্বপ্রাপ্ত reviewer দেখেছেন।

Back-translation-কে signal হিসেবে নিন

বাংলা output আবার English-এ translate করলে বড় অর্থবদল চোখে পড়তে পারে। কিন্তু দুটি model একই ভুল করলে back-translation সুন্দর দেখাবে। তাই এটি native reviewer-এর বিকল্প নয়। Reviewer না থাকলে low-risk acknowledgement যেমন “message পেয়েছি, team দেখে জানাবে” সীমিত রাখুন; policy সিদ্ধান্ত পাঠাবেন না। Customer-এর original language, source draft, AI output ও approved final আলাদা রাখলে পরে complaint এলে কী পরিবর্তন হয়েছিল বোঝা যায়। Personal data অপ্রয়োজনে public AI tool-এ paste করবেন না; organisation-এর approved privacy rule মানুন।

Published template নিয়মিত test করুন

Support team একই reply template ব্যবহার করলে মাসে একবার কয়েকটি real, anonymised example দিয়ে review করুন। নতুন product বা policy এলে glossary update হয়েছে কি না দেখুন। Customer যে phrase বারবার বুঝতে পারছেন না তা note করে সহজ ভাষায় লিখুন। AI model বা prompt বদলালে পুরোনো approved result ধরে নেবেন না; number, negative sentence ও mixed Bengali-English term থাকা test set চালান। লক্ষ্য perfect literary translation নয়—customer যেন সঠিক তথ্য, পরের action ও সময়সীমা পরিষ্কার বুঝতে পারেন এবং team এমন প্রতিশ্রুতি না দেয় যা business record সমর্থন করে না।