چگونه یک وب‌سایت رزرو هتل بسازیم: اتاق‌ها، نرخ‌ها، موجودی و پرداخت

یک وب‌سایت رزرو هتل به مهمانان اجازه می‌دهد تاریخ انتخاب کنند، ببینند کدام اتاق‌ها برای هر شب اقامتشان خالی است، قیمت کل را ببینند و پرداخت کنند یا بیعانه بگذارند — بدون اینکه کسی پشت سر هم ایمیل بزند. برای ساختن آن به انواع اتاق با تعداد اتاق، مدل موجودی شبانه، نرخ‌هایی که بر اساس تاریخ تغییر می‌کنند، جریان رزروی که هنگام ذخیره دوباره موجودی را بررسی کند، و یک نمای مدیریتی برای پذیرش نیاز دارید. سخت‌ترین بخش صفحه‌های زیبا نیست. بخش سخت این است که مطمئن شوید یک اتاق هرگز دوبار فروخته نمی‌شود، به‌ویژه اگر روی سایت‌های رزرو هم می‌فروشید.

سایت به چه چیزهایی نیاز دارد

صفحه‌ها

• عمومی: خانه، اتاق‌ها (عکس، تخت‌ها، متراژ، امکانات، حداکثر مهمان)، جستجوی تاریخ و تعداد مهمان، نتایج با قیمت کل برای هر نوع اتاق، فرم رزرو، پرداخت، و صفحه تأیید با لینک مدیریت رزرو.
• پشتیبانی: موقعیت و مسیریابی، سیاست‌ها (ساعات ورود و خروج، لغو، کودکان، حیوانات خانگی)، سؤالات متداول، تماس.
• خصوصی (کارکنان): ورودی‌ها و خروجی‌های امروز، نمای تقویمی اتاق‌ها بر اساس شب، فهرست رزروها، تاریخ‌های مسدودشده، تنظیمات نرخ و اتاق.

داده‌ها

ورود و خروج را به‌صورت تاریخ ذخیره کنید، نه زمان، و خروج را انحصاری در نظر بگیرید: اقامت از ۱۰ تا ۱۲ شب‌های ۱۰ و ۱۱ را استفاده می‌کند. اشتباه در این، رایج‌ترین باگ موجودی است.

دسترسی‌ها

مهمانان قیمت‌ها و اینکه یک نوع اتاق خالی هست یا نه را می‌بینند — هرگز اینکه چه کس دیگری اقامت دارد. کارکنان پذیرش رزروها و جزئیات مهمانان را می‌بینند؛ فقط مالک نرخ‌ها و سیاست‌ها را تغییر می‌دهد. یعنی یک ورود کارکنان با حداقل دو نقش.

تصمیم‌ها و مصالحه‌ها

رزرو با درخواست یا رزرو فوری

رزرو با درخواست — مهمان تاریخ و جزئیات را می‌فرستد، شما از طریق ایمیل تأیید می‌کنید — بسیار ساده‌تر است و برای یک مهمانخانه کوچک مناسب است. رزرو فوری موجودی و مدیریت پرداخت بی‌نقص می‌خواهد، اما تبدیل بهتری دارد. بسیاری از ملک‌ها با درخواست شروع می‌کنند و بعداً تغییر می‌دهند.

فروش نوع اتاق یا اتاق مشخص

مهمانان معمولاً یک نوع اتاق را رزرو می‌کنند («دو تخته با چشم‌انداز دریا») و کارکنان بعداً اتاق واقعی را تخصیص می‌دهند. فروش اتاق‌های مشخص ساخت ساده‌تری دارد، اما پر کردن تقویم را سخت‌تر می‌کند.

نرخ‌ها

با یک قیمت برای هر نوع اتاق در هر شب شروع کنید، با استثناهای اختیاری برای بازه‌های تاریخی (فصل شلوغ، تعطیلات) و حداقل اقامت. قیمت‌گذاری پویا، کدهای تخفیف و بسته‌ها را برای بعد بگذارید.

پرداخت

گزینه‌ها، به ترتیب افزایش پیچیدگی: پرداخت هنگام ورود؛ بیعانه از طریق صفحه پرداخت میزبانی‌شده مانند Stripe Checkout؛ پیش‌پرداخت کامل برای نرخ غیرقابل استرداد؛ یا ذخیره کارت برای شارژ بعدی. قواعد پرداخت، مالیات و عوارض گردشگری بسته به کشور فرق می‌کند — قوانین محلی را بررسی کنید یا از یک مشاور بپرسید. راهنمای پرداخت مکانیزم را پوشش می‌دهد.

کانال‌های دیگر

اگر اتاق‌ها روی آژانس‌های آنلاین سفر یا پلتفرم‌های اجاره تعطیلات هم فهرست شده‌اند، باید تقویم‌ها را هماهنگ نگه دارید. بسیاری از آن پلتفرم‌ها می‌توانند تقویم‌ها را به‌صورت لینک iCal خروجی و ورودی بدهند؛ همگام‌سازی این‌طور برای ملک‌های کوچک رایج است، اما با تأخیر انجام می‌شود، نه لحظه‌ای. مدیر کانال پاسخ حرفه‌ای است.

یک پرامپت اولیه که کار می‌کند

یک وب‌سایت رزرو مستقیم برای Harbour House بسازید، یک مهمانخانه ۹ اتاقه در Tobermory، اسکاتلند. انواع اتاق: دو تخته (۴ اتاق، ۲ مهمان، £۱۲۰ در شب)، دوقلو (۳ اتاق، ۲ مهمان، £۱۱۵)، خانوادگی (۲ اتاق، ۲ بزرگسال + ۲ کودک، £۱۶۵). مهمانان با تاریخ ورود، تاریخ خروج و تعداد مهمان جستجو می‌کنند و فقط انواع اتاقی را می‌بینند که برای هر شب اقامتشان یک اتاق خالی دارند، با جمع کل قیمت. خروج انحصاری است. حداقل اقامت ۲ شب در ژوئیه و اوت. فرم رزرو نام، ایمیل، تلفن و ساعت ورود را جمع می‌کند؛ آن را به‌صورت «در انتظار» ذخیره کنید و موجودی را در سرور دوباره بررسی کنید پیش از ذخیره. یک بخش کارکنان با ورود: ورودی‌ها و خروجی‌های امروز، نمای تقویمی اتاق‌ها بر اساس شب، فهرست رزروها با وضعیت، و راهی برای مسدود کردن تاریخ‌ها. ساعت ورود ۳ تا ۸ بعدازظهر، ساعت خروج ۱۰ صبح و سیاست لغو (رایگان تا ۷ روز پیش) را در هر صفحه رزرو نشان دهید. طراحی آرام ساحلی، اول موبایل.

مراحل ساخت

1. اتاق‌ها و شب‌ها را اول مدل کنید. انواع اتاق، اتاق‌ها، نرخ‌ها و بررسی موجودی. پیش از هر کار طراحی آن را آزمایش کنید.
2. جستجو و نتایج. انتخابگر تاریخ، تعداد مهمان، قیمت کل اقامت، و وضعیت‌های واضح «تمام شده».
3. جریان رزرو. فرم ← بررسی دوباره موجودی در سرور ← رزرو در انتظار ← صفحه تأیید با لینک مدیریت.
4. بخش کارکنان با ورود: ورودی‌ها، خروجی‌ها، تقویم، مسدودسازی تاریخ.
5. تأیید ایمیلی از ارائه‌دهنده خودتان، با تاریخ‌ها، جمع کل، آدرس و سیاست. ارسال ایمیل را ببینید.
6. بیعانه‌ها در حالت آزمایشی Stripe، و تأیید رزرو فقط وقتی پرداخت موفق است. وب‌هوک پرداخت نیاز دارد اپ در یک آدرس عمومی منتشر شده باشد.
7. همگام‌سازی تقویم با کانال‌های دیگر اگر از آن‌ها استفاده می‌کنید، به‌علاوه یک بررسی دستی روزانه در ابتدا.
8. موارد مرزی را آزمایش کنید: دو مرورگر که آخرین اتاق را رزرو می‌کنند، اقامتی که از یک تغییر نرخ عبور می‌کند، لغوی که شب‌ها را آزاد می‌کند، اقامت یک‌شبه در دوره حداقل اقامت.
9. منتشر کنید و خودتان یک رزرو واقعی انجام دهید پیش از کنار گذاشتن فرایند قدیمی.

اشتباه‌های رایج

• بررسی موجودی فقط در مرورگر. دو مهمان در نهایت آخرین اتاق را همزمان رزرو می‌کنند.
• شمردن شب خروج به‌عنوان اشغال‌شده (یا نشمردن شب ورود). برای یک اقامت دو شبه تست بنویسید.
• یک قیمت ثابت. بیشتر ملک‌ها حداقل استثناهای فصلی لازم دارند.
• پنهان کردن جمع کل تا آخرین مرحله. کل قیمت اقامت، از جمله هزینه‌های شناخته‌شده، را در نتایج نشان دهید.
• سیاست‌ها در پاورقی پنهان. شرایط لغو را کنار دکمه پرداخت نشان دهید.
• فرض لحظه‌ای بودن همگام‌سازی iCal. اینطور نیست؛ وقتی تقریباً پر هستید تاریخ‌ها را دستی ببندید.

وقتی یک محصول آماده بهتر است

اگر بیش از چند اتاق دارید، از چند آژانس آنلاین می‌فروشید، یا به صورتحساب، نظافت و گزارش نیاز دارید، یک سیستم مدیریت ملک با موتور رزرو و مدیر کانال داخلی معمولاً انتخاب درست است. این محصولات برای حل رزرو دوباره در کانال‌های مختلف وجود دارند، و بازساختن آن به‌خوبی هزینه‌بر است.

یک سایت سفارشی وقتی منطقی است که ملک کوچک است و بیشتر رزروهای مستقیم می‌گیرد، یا موجودی غیرمعمول دارد (کمپ‌های لوکس، کلبه‌هایی با امکانات مشترک، اتاق‌هایی که همراه فعالیت فروخته می‌شوند)، یا وقتی می‌خواهید طراحی و تجربه مهمان خودتان را بدون هزینه ماهانه برای هر اتاق داشته باشید. بعضی صاحبان ملک یک سایت سفارشی را با یک موتور رزرو میزبانی‌شده که در آن جاسازی شده ترکیب می‌کنند — که اغلب بهترین هر دو است.

ساخت با Mythex

در Mythex ملک را در گفتگو توصیف می‌کنید، سایت را در پیش‌نمایش زنده بررسی می‌کنید (از جمله قاب اندازه گوشی)، و وقتی درست شد منتشرش می‌کنید. رزروها، اتاق‌ها و نرخ‌ها در یک پایگاه داده Postgres زندگی می‌کنند که عامل وقتی اپ نیاز به ذخیره داده داشته باشد اضافه می‌کند؛ وقتی بیکار است می‌خوابد و با درخواست بعدی بیدار می‌شود. ورود کارکنان، ایمیل‌های تأیید و بیعانه‌ها به ارائه‌دهندگان و کلیدهای خودتان وصل‌اند — Mythex محصول داخلی ورود کاربر نهایی، ایمیل یا پرداخت ندارد — پس پیش از افزودن بیعانه دستور Stripe را بخوانید. از /test استفاده کنید تا عامل جستجو و رزرو را طی کند، و نقاط بازگشت برای برگرداندن تغییری که موجودی را خراب می‌کند.

برای یک پرامپت شروع، سازنده سیستم رزرو هتل، سازنده سیستم رزرو مهمانخانه یا قالب سایت رزرو گلمپینگ را ببینید. برای رزروهای ساعتی یا نوبتی به‌جای شبانه، راهنمای اپ رزرو را ببینید.

پرسش‌ها