وایت لیبل یا ساخت موتور رزرو اختصاصی
پیش‌فاکتور می‌رسد و رقمش هنوز قابل تحمل به نظر می‌آید. برنامه‌نویسی که به او اعتماد دارید یک موتور رزرو را قیمت زده است — جست‌وجو، فهرست نتایج، مرحله پرداخت، یک پنل مدیریت، سه ماه — و عدد بی‌اندازه نیست. دو سال است دلتان سامانه خودتان را می‌خواهد. همین‌جاست که پرسش وایت لیبل یا ساخت موتور رزرو واقعاً تعیین تکلیف می‌شود، و معمولاً با شاهد اشتباه تعیین تکلیف می‌شود: با قیمت ماه اول به جای شکل سال دوم.
آن پیش‌فاکتور صادقانه است. فقط بابت آن بخشی از کار است که می‌توانید ببینید.
یک برآورد ساخت در واقع چه چیزی را قیمت می‌زند
تقریباً هر برآوردی که به دستتان می‌رسد سطح را قیمت می‌زند: فرم جست‌وجو، فهرست نتایج، صفحه مشخصات مسافر، مرحله پرداخت، جدول رزروها در پنل مدیریت. آن کار واقعی است و تیم کاربلد خوب انجامش می‌دهد. همان نیمه‌ای هم هست که دیگر کالای عمومی شده — نیمه‌ای که دو آژانس در فروش یک مسیر هرگز سر آن رقابت نمی‌کنند. هیچ‌کس تا امروز آژانسی را به این دلیل انتخاب نکرده که فاصله سطرهای صفحه موجودی‌اش بهتر بوده است.
نیمه دیگر در سمتی از اتصال است که از مرورگر دیده نمی‌شود. سال‌ها همان‌جا می‌روند.
هزینه، تعداد اتصال‌هاست نه ظاهر سایت
از یک supplier دسترسی بخواهید؛ با پاسخ ایمیل، API key تحویل نمی‌گیرید. یک محیط تست تحویل می‌گیرید، یک فرایند certification، اعتبارنامه‌هایی که به ازای هر شخصیت حقوقی صادر می‌شود، یک سند قواعد، و یک رابط که طبق تقویم خودش جواب می‌دهد. بعد با لهجه مخصوص همان supplier آشنا می‌شوید: static rate در یک جا و live availability در جای دیگر، allotment با release period کنار free-sale، یک cut-off که موتور شما باید رعایتش کند، fare rule که تعیین می‌کند تغییر بلیت جریمه دارد یا نه، و کاتالوگ ancillary که با کاتالوگ هیچ‌کس دیگر منطبق نیست. حالا این را در تعداد supplierهایی ضرب کنید که مشتریانتان انتظار دارند داشته باشید.
یک اتصال، یک پروژه است. شش اتصال، یک دپارتمان است و هرگز تمام نمی‌شود، چون هیچ‌کدام از آن شش نفر قبول نکرده‌اند تغییر کردن را کنار بگذارند.
همین دام پشت هر صفحه‌ای که پیش‌فاکتور اسمش را برده هم نشسته است. جست‌وجو تا وقتی یک قابلیت به نظر می‌رسد که دو ایرلاین یک مسیر یکسان را با دو قیمت برنگردانند و شما مجبور نشوید در دل کد تصمیم بگیرید مشتری کدام را ببیند. استرداد تا وقتی یک دکمه است که fare rule بگوید جریمه، supplier بگوید واچر و مشتری بگوید کارت. markup تا روزی یک عدد در صفحه تنظیمات است که بخواهید یک قاعده برای مشتری سازمانی داشته باشید، یک قاعده برای یک sub-agent در مشهد و قاعده سوم برای مسافر حضوری — روی یک نرخ واحد.
همین حساب‌وکتاب است که از پیش‌فاکتور ساخت بیرون می‌ماند، و در برابر رابط کاربری خطای گرد کردن نیست — خودِ محصول است. روی یک پلتفرم وایت لیبل این کار از پیش انجام شده و از پیش نیرو دارد: محتوای supplier از مسیر supplier group به فروشگاه می‌رسد نه از مسیر قراردادهایی که یکی‌یکی امضا می‌کنید، و هر سایت بسته به آنچه واقعاً می‌فروشد پرواز، هتل، تور یا جاذبه را روشن می‌کند.
مقایسه‌ای که تا سال دوم دوام می‌آورد
این جدول را مثل یک مدیر عملیات بخوانید، نه مثل خریدار. پرسش هر سطر یکی است: تعهدش با کیست؟
| خودتان می‌سازید | وایت لیبل | |
|---|---|---|
| زمان تا اولین رزرو واقعی | یک چرخه توسعه، بعد certification با هر supplier | همان روز، روی ساب‌دامنه پلتفرم — ویزارد ثبت‌نام بدون درخواست کارت آن را تحویل می‌دهد |
| اتصال به supplierها | با خودتان است: گرفتن، certification و نگهداری، یکی‌یکی | هست؛ هرکدام را می‌فروشید روشن می‌کنید |
| زبان‌ها و ارزها در زمان راه‌اندازی | هر چه در دامنه کار آوردید و پولش را دادید | ۴۰ زبان، شامل راست‌به‌چپ؛ هر سایت ارز پیش‌فرض و فهرست ارزهایش را خودش می‌چیند |
| یک supplier، API را عوض می‌کند | در بک‌لاگ شما، با ضرب‌الاجل او | مسئله پلتفرم، یک بار برای همه tenantها حل می‌شود |
| صدور بلیت ساعت ۲ بامداد شکست می‌خورد | شما، یا هر برنامه‌نویسی که جواب بدهد | شیفت آنکال پلتفرم |
| تغییر ظاهر سایت | یک انتشار نسخه | یک تنظیم — قالب، رنگ، فونت و لوگو از پنل مدیریت عوض می‌شود، بدون استقرار مجدد |
| فرایندی که هیچ‌کس نمی‌فروشد | ساختنی است، دقیقاً همان‌طور که کار می‌کنید | فقط اگر پلتفرم از پیش آن را مدل کرده باشد |
| مالک کد کیست | شما | شما نه — برند، مشتری و شرایط تجاری مال شماست |
دو سطر از این جدول به نفع ساختن است. جایزه دلداری هم نیستند. اگر آنچه می‌فروشید به قدر کافی غیرمعمول باشد، همان دو سطر بر همه سطرهای بالایی می‌چربد.
اشتباه کردن چه چیزی از شما می‌گیرد
شکست یک موتور خودساخته، پروژه‌ای نیست که فرو بریزد. آن‌ها دیده می‌شوند، درد دارند و از سر گذرانده می‌شوند. نسخه گران‌قیمتش سامانه‌ای است که کار می‌کند — و بعد آرام‌آرام از کار می‌افتد.
برنامه‌نویسی که نوشته است می‌رود، و نفر بعدی هر تغییر کوچک را به قیمت ریسک می‌زند چون هیچ آدم زنده‌ای آن کد را نخوانده است. یک supplier طبق تقویم خودش یک endpoint را حذف می‌کند و رزروها طوری شکست می‌خورند که مشتری زودتر از مانیتورینگ شما متوجه می‌شود. fare rule که سال اول درست پیاده شده بود دیگر بازبینی نمی‌شود و ADM بعدی روی کد IATA شما می‌نشیند، نه روی پیمانکار. اعتبارنامه‌های پرداخت منقضی می‌شوند. گواهی‌ها منقضی می‌شوند. یک فریم‌ورک دو نسخه عقب‌مانده تبدیل به گفت‌وگویی درباره امنیت می‌شود که حتی یک هفته برایش وقت نگذاشته بودید.
هیچ‌کدام اینها به شکل فاکتور نمی‌آید، و دقیقاً به همین دلیل هرگز وارد آن مقایسه‌ای که مردم واقعاً می‌کنند نمی‌شود. به شکل «تمرکز» می‌آید. مدیری که سه‌شنبه‌اش را صرف یک PNR خراب می‌کند، آن سه‌شنبه چیزی نفروخته است؛ و آژانس‌هایی که بعد از ساخت اختصاصی ساکت می‌شوند، به‌ندرت به این دلیل ساکت می‌شوند که نرم‌افزار خراب شد — ساکت می‌شوند چون کسی که کار می‌آورد حالا کسی است که سامانه را نگه می‌دارد.
کی ساختن واقعاً تصمیم درستی است
گاهی هست، و مصداق‌هایش آن‌قدر مشخص است که خودتان را با آن بسنجید.
- خودِ نرم‌افزار مزیت شماست. اگر به جای فروش سفر، فناوری به کسب‌وکارهای گردشگری می‌فروشید، نمی‌توانید همان چیزی را که بابتش پول می‌گیرید برون‌سپاری کنید.
- مهندس دارید و بودجه نفر دوم را هم دیده‌اید. نه آن‌که می‌سازد — آن‌که بعد از رفتن نفر اول تحویلش می‌گیرد. ساختن بدون برنامه جانشینی، همان اجاره است با چند مرحله اضافه.
- فرایندی دارید که هیچ‌کس مدلش نکرده. مجری تورهای زیارتی که تخت‌های خودش را نگه می‌دارد و PNR گروهی را به مراحل ویزا گره می‌زند، کاری نمی‌کند که یک موتور عمومی روزی اندازه‌اش شود.
راه سومی هم هست که هیچ‌کدام نیست: فروشگاه را بخرید و فقط همان تکه‌ای را بسازید که واقعاً مال شماست. پلتفرم دقیقاً برای همین، API پرواز و هتل را در اختیار می‌گذارد، هرچند دسترسی با یک گفت‌وگو شروع می‌شود نه با کلید خودتحویل. پیش از تعهد به ساخت کامل، این مسیر ترکیبی را قیمت بزنید، چون آن بخشی که واقعاً می‌خواستید کنترلش کنید معمولاً یک فرایند است، نه یک موتور کامل.
و اگر مدل کارتان روی sub-agent می‌چرخد، آن را هم درست قیمت بزنید. سقف اعتبار و صورتحساب settlement اینجا مفهوم درجه‌یک‌اند، نه یک فایل اکسل که کسی جمعه‌ها مغایرت‌گیری کند؛ در یک پروژه ساخت، اینها پروژه دومی هستند که هیچ‌کس در پیش‌فاکتور اول نیاورده است.
یک پرسش، از هر دو طرف
پیش از امضای هر چیزی، یک پرسش را هم از برنامه‌نویس بپرسید و هم از پلتفرم: اسفند امسال یک supplier فرایند certification را عوض می‌کند — چه کسی کار را انجام می‌دهد، با ضرب‌الاجل چه کسی، و من از کجا باخبر می‌شوم؟ دو پاسخ شبیه هم نخواهند بود، و فاصله میانشان همان چیزی است که واقعاً دارید انتخاب می‌کنید.
مقایسه یک فروشگاه در حال کار با یک پیش‌فاکتور، آزمون صادقانه‌تری از مقایسه دو سند است؛ پس اگر می‌خواهید پیش از هر تعهدی ببینید چه چیزی تحویل داده می‌شود، یک سایت را در ویزارد شروع کنید — کارت نمی‌خواهد، و ساب‌دامنه‌ای که می‌دهد برای همیشه مال شما می‌ماند، حتی بعد از اینکه دامنه خودتان را وصل کنید.