মূল কনটেন্টে যান
লাইভ ডেমো
ব্লগ

White label নাকি নিজের বুকিং ইঞ্জিন বানাবেন

Tekravel সম্পাদকীয়

কোটেশন এসেছে আর অঙ্কটা এখনও সামলানোর মতো মনে হচ্ছে। আপনি যাঁকে বিশ্বাস করেন সেই ডেভেলপার একটা বুকিং ইঞ্জিনের দাম ধরেছেন — সার্চ, রেজাল্ট লিস্ট, চেকআউট, একটা অ্যাডমিন স্ক্রিন, তিন মাস — আর সংখ্যাটা অবাস্তব নয়। দুই বছর ধরে আপনি নিজের সিস্টেম চাইছেন। ঠিক এই মুহূর্তেই white label নাকি নিজের বুকিং ইঞ্জিন প্রশ্নটার আসল ফয়সালা হয়, এবং সাধারণত ভুল প্রমাণের ভিত্তিতে হয়: প্রথম মাসের দাম দেখে, দ্বিতীয় বছরের চেহারা দেখে নয়।

কোটেশনটা সৎ। কিন্তু সেটা কাজের কেবল সেই অংশটুকুর, যেটুকু আপনি চোখে দেখতে পান।

একটা এস্টিমেট আসলে কীসের দাম ধরে

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

বাকি অর্ধেকটা কানেকশনের সেই দিকে, যা ব্রাউজার থেকে দেখা যায় না। বছরগুলো ওখানেই যায়।

খরচটা ইন্টিগ্রেশনের সংখ্যায়, ইন্টারফেসে নয়

কোনও supplier-এর কাছে অ্যাক্সেস চান, ইমেলের উত্তরে API key পাবেন না। পাবেন একটা টেস্ট এনভায়রনমেন্ট, একটা certification প্রক্রিয়া, প্রতিটি আইনি সত্তার জন্য আলাদা করে ইস্যু করা ক্রেডেনশিয়াল, নিয়মের একটা নথি, আর একজন যোগাযোগকারী যিনি নিজের সময়সূচিতে উত্তর দেন। তারপর পরিচয় হয় ওই supplier-এর নিজস্ব উপভাষার সঙ্গে: এক জায়গায় static rate আর অন্য জায়গায় live availability, free-sale-এর পাশে release period সহ allotment, একটা cut-off যেটা আপনার ইঞ্জিনকে মানতেই হবে, fare rule যা ঠিক করে পরিবর্তনে চার্জ বসবে কি না, আর এমন একটা ancillary ক্যাটালগ যা অন্য কারও সঙ্গে মেলে না। এবার এটাকে গুণ করুন সেই সংখ্যক supplier দিয়ে, যতজন আছে বলে আপনার ক্লায়েন্টরা ধরেই নেন।

একটা ইন্টিগ্রেশন একটা প্রকল্প। ছয়টা ইন্টিগ্রেশন একটা বিভাগ, আর সেটা কখনও শেষ হয় না, কারণ ওই ছয়জনের কেউই বদলানো থামাতে রাজি হয়নি।

কোটেশনে যে স্ক্রিনগুলোর নাম আছে, তাদের পেছনেও একই ফাঁদ বসে আছে। সার্চকে একটাই ফিচার মনে হয়, যতক্ষণ না দুটো এয়ারলাইন একই ইটিনেরারি দুই দামে ফেরত দেয় আর আপনাকে কোডের ভেতরেই ঠিক করতে হয় যাত্রী কোনটা দেখবেন। রিফান্ডকে একটা বোতাম মনে হয়, যতক্ষণ না fare rule বলে জরিমানা, supplier বলে ভাউচার, আর যাত্রী বলেন কার্ডে ফেরত। markup-কে সেটিংস পাতার একটা সংখ্যা মনে হয়, যতক্ষণ না সেই দিনটা আসে যেদিন আপনি কর্পোরেট ক্লায়েন্টের জন্য এক নিয়ম, চট্টগ্রামের এক sub-agent-এর জন্য আরেক নিয়ম আর কাউন্টারে আসা যাত্রীর জন্য তৃতীয় নিয়ম চান — একই ভাড়ার উপরে।

এই হিসাবটাই কোটেশন বাদ দিয়ে যায়, আর UI-এর তুলনায় এটা সামান্য গরমিল নয় — এটাই পণ্য। white label প্ল্যাটফর্মে কাজটা আগেই হয়ে আছে এবং লোকও নিযুক্ত আছে: supplier-এর কনটেন্ট দোকানে পৌঁছায় supplier group-এর পথে, একে একে সই করা চুক্তির পথে নয়; আর একটা সাইট ফ্লাইট, হোটেল, ট্যুর প্যাকেজ বা দর্শনীয় স্থানের টিকিট চালু করে ঠিক ততটুকু, যতটুকু সে সত্যিই বিক্রি করে।

যে তুলনাটা দ্বিতীয় বছর পর্যন্ত টেকে

এই টেবিলটা ক্রেতা হিসেবে নয়, পরিচালক হিসেবে পড়ুন। প্রতিটি সারির প্রশ্ন এক: দায়টা কার ঘাড়ে?

 নিজে বানানোWhite label
প্রথম সত্যিকারের বুকিং পর্যন্ত সময়একটা ডেভেলপমেন্ট চক্র, তারপর প্রতিটি supplier-এর সঙ্গে certificationএকই দিনে, প্ল্যাটফর্মের সাবডোমেইনে — সাইনআপ উইজার্ড কার্ড না চেয়েই সেটা দিয়ে দেয়
supplier কানেকশনআপনাকেই জোগাড়, certification আর রক্ষণাবেক্ষণ করতে হবে, একে একেঅন্তর্ভুক্ত; যেগুলো বিক্রি করেন সেগুলো চালু করে নেন
চালুর সময় ভাষা ও মুদ্রাযতটা স্কোপে ধরেছেন আর দাম দিয়েছেন৪০টি ভাষা, ডান-থেকে-বাঁ লিপিসহ; প্রতিটি সাইট নিজের ডিফল্ট মুদ্রা ও তালিকা বেছে নেয়
supplier API বদলে ফেললআপনার ব্যাকলগ, তাদের সময়সীমায়প্ল্যাটফর্মের সমস্যা, সব tenant-এর জন্য একবারেই সমাধান
রাত দুটোয় টিকিট ইস্যু আটকে গেলআপনি, নয়তো যে ডেভেলপার ফোন ধরেনপ্ল্যাটফর্মের অন-কল
সাইটের চেহারা বদলানোএকটা নতুন রিলিজএকটা সেটিং — থিম, রং, ফন্ট আর লোগো অ্যাডমিন প্যানেল থেকেই বদলায়, রিডিপ্লয় ছাড়া
যে কর্মপ্রবাহ আর কেউ বেচে নাবানানো যায়, ঠিক যেভাবে আপনি চালানকেবল তখনই, যদি প্ল্যাটফর্মে সেটা আগে থেকে মডেল করা থাকে
কোডের মালিক কেআপনিআপনি নন — ব্র্যান্ড, ক্লায়েন্ট আর বাণিজ্যিক শর্ত আপনার

এর মধ্যে দুটো সারি নিজে বানানোর পক্ষে। ওগুলো সান্ত্বনা পুরস্কার নয়। আপনি যা বেচেন তা যথেষ্ট অস্বাভাবিক হলে ওই দুই সারি উপরের সবকিছুকে ছাড়িয়ে যায়।

ভুল করলে খেসারত কী

নিজে বানানো ইঞ্জিনের ব্যর্থতা মানে ধসে পড়া প্রকল্প নয়। ওগুলো চোখে পড়ে, কষ্ট দেয়, কিন্তু পার হওয়া যায়। দামি সংস্করণটা হলো এমন সিস্টেম যা চলে — তারপর ধীরে ধীরে থেমে যায়।

যিনি লিখেছিলেন সেই ডেভেলপার চাকরি বদলান, আর পরেরজন প্রতিটি ছোট বদলকে ঝুঁকি ধরে দাম হাঁকেন, কারণ জীবিত কেউ ওই কোড পড়েননি। কোনও supplier নিজের সময়মতো একটা endpoint তুলে দেয় আর বুকিং এমনভাবে ব্যর্থ হতে থাকে যা আপনার মনিটরিংয়ের আগে যাত্রীরা টের পান। প্রথম বছরে ঠিকভাবে লেখা একটা fare rule আর কখনও ফিরে দেখা হয় না, আর তার পরের ADM চাপে আপনার IATA নম্বরে, ঠিকাদারের নয়। পেমেন্ট ক্রেডেনশিয়ালের মেয়াদ ফুরায়। সার্টিফিকেটের মেয়াদ ফুরায়। দুই সংস্করণ পিছিয়ে থাকা একটা ফ্রেমওয়ার্ক নিরাপত্তার আলোচনায় বদলে যায়, যার জন্য আপনি এক সপ্তাহও বরাদ্দ রাখেননি।

এর কোনওটাই ইনভয়েস হয়ে আসে না, তাই মানুষ যে তুলনাটা আসলে করে, তাতে এগুলো কখনও ঢোকে না। এগুলো আসে মনোযোগ হয়ে। যে মালিক মঙ্গলবারটা একটা নষ্ট PNR নিয়ে কাটান, তিনি মঙ্গলবার কিছু বিক্রি করেননি; আর নিজে বানানোর পর যে এজেন্সিগুলো চুপ হয়ে যায়, তারা খুব কমই চুপ হয় সফটওয়্যার ব্যর্থ হওয়ায় — চুপ হয় কারণ যিনি কাজ আনতেন তিনি এখন সিস্টেম সামলানোর লোক।

কখন নিজে বানানোই সত্যিই ঠিক সিদ্ধান্ত

কখনও কখনও সেটাই ঠিক, আর ক্ষেত্রগুলো যথেষ্ট নির্দিষ্ট যাতে নিজেকে মিলিয়ে নিতে পারেন।

  • সফটওয়্যারই আপনার পার্থক্য। ভ্রমণ না বেচে যদি অন্য ট্রাভেল ব্যবসাকে প্রযুক্তি বেচেন, তাহলে যেটার জন্য টাকা নেন সেটাই বাইরে দিয়ে দেওয়া যায় না।
  • আপনার প্রকৌশলী আছে, আর দ্বিতীয়জনের বাজেটও ধরা আছে। যিনি বানাবেন তিনি নন — প্রথমজন চলে যাওয়ার পর যিনি দায়িত্ব নেবেন তিনি। উত্তরাধিকারের পরিকল্পনা ছাড়া নিজে বানানো মানে বাড়তি ধাপসহ ভাড়া নেওয়া।
  • আপনার কর্মপ্রবাহ কেউ মডেল করেনি। যে হজ-ওমরাহ অপারেটর নিজের বেড ধরে রাখেন আর দলগত PNR-কে ভিসার ধাপে বেঁধে দেন, তিনি এমন কিছু করছেন যা কোনও সাধারণ ইঞ্জিনে ঠিকঠাক বসবে না।

তৃতীয় একটা পথও আছে, যা কোনওটাই নয়: দোকানটা কিনে নিন, আর কেবল সেই অংশটা বানান যা সত্যিই আপনার। প্ল্যাটফর্ম ঠিক এই কারণেই ফ্লাইট আর হোটেলের API খুলে রাখে, যদিও অ্যাক্সেস শুরু হয় আলোচনা দিয়ে, নিজে তুলে নেওয়া key দিয়ে নয়। পুরো বানানোর প্রতিশ্রুতি দেওয়ার আগে এই মিশ্র পথটার দাম কষে দেখুন, কারণ যেটুকু আপনি সত্যিই নিয়ন্ত্রণে রাখতে চেয়েছিলেন তা সাধারণত একটা কর্মপ্রবাহ, গোটা ইঞ্জিন নয়।

আর আপনার মডেল যদি sub-agent-এর উপর চলে, সেটারও দাম ঠিকভাবে কষুন। ক্রেডিট লিমিট আর settlement ইনভয়েস এখানে মূল ধারণা, রবিবারে কেউ মিলিয়ে দেখা স্প্রেডশিট নয়; নিজে বানানোর কাজে ওগুলো দ্বিতীয় প্রকল্প, যা প্রথম কোটেশনে কেউ ধরেনি।

একটাই প্রশ্ন, দুই পক্ষকেই

কিছু সই করার আগে ডেভেলপার আর প্ল্যাটফর্ম — দুজনকেই একই প্রশ্নটা করুন: আগামী মার্চে কোনও supplier তার certification বদলে দিল, কাজটা কে করবে, কার সময়সীমায় করবে, আর আমি জানব কীভাবে? উত্তর দুটো এক হবে না, আর ওই দুইয়ের ফারাকটাই আসলে আপনার বেছে নেওয়ার জিনিস।

দুটো নথি পাশাপাশি রেখে মেলানোর চেয়ে চালু একটা দোকানের সঙ্গে কোটেশন মেলানো অনেক সৎ পরীক্ষা, তাই প্রতিশ্রুতি দেওয়ার আগে কী কী তৈরি হয়ে আসে দেখতে চাইলে উইজার্ডে একটা সাইট শুরু করে দেখুন — কার্ড চায় না, আর যে সাবডোমেইন দেয় সেটা চিরকাল আপনারই থাকে, নিজের ডোমেইন যুক্ত করার পরেও।

Tekravel সম্পাদকীয়

ট্রাভেল টেকনোলজি ডেস্ক

Tekravel-এর ট্রাভেল টেকনোলজি ডেস্ক লেখে ইন্ডাস্ট্রির জন্য: এজেন্সি মালিক, কনসলিডেটর এবং যেসব ডেভেলপার তাঁদের সংযুক্ত করেন। প্রতিটি লেখা প্রকাশের আগে সেই প্ল্যাটফর্মেই যাচাই করা হয় যেটির কথা সেখানে বলা হয়েছে।