مدیریت رزرو چند واحد در یک مجتمع روی سه قاعده می‌ایستد: هر واحد یک هویت مشخص و ثابت دارد، همه‌ی واحدها در یک تقویم مشترک دیده می‌شوند، و هر رزرو دقیقاً به یک واحد و یک بازه‌ی شب وصل است. بقیه‌ی کار، از جابجایی مهمان تا بازبینی هفتگی، فقط حفظ همین سه قاعده است.
اگر هنوز با تقویم کاغذی یا اکسل کار می‌کنید، اول مقایسه‌ی روش‌های مدیریت تقویم را ببینید؛ این مقاله فرض می‌گیرد که به‌دنبال کارکردن با چند واحد در یک مجموعه هستید. تصویر کلی‌تر پیشگیری از تداخل رزرو هم در راهنمای کامل جلوگیری از رزرو تکراری آمده است.
چرا چند واحد، مشکل را غیرخطی می‌کند؟
با یک واحد، تقویم یک ردیف دارد و کافی است به آن نگاه کنید. با هشت واحد، هشت ردیف دارید که هرکدام ممکن است شش‌هفت رزرو آینده داشته باشد، و هر تماس تازه باید با همه‌ی آن‌ها سنجیده شود. خطای معمول هم این نیست که کسی عمداً دو نفر را در یک واحد بگذارد؛ این است که ذهن آدم‌ها جای واحد را قاطی می‌کند.
چند الگوی خطای واقعی که در مجتمع‌های چندواحدی تکرار می‌شود:
مهمان «همان واحد طبقه‌ی دوم» را می‌خواهد و شما در دفترچه فقط «طبقه‌ی دوم» نوشته‌اید، در حالی که دو واحد در آن طبقه هست.
پذیرش، مهمان را موقتاً به واحد دیگری می‌برد (کولر خراب بوده) ولی تقویم همان‌طور باقی می‌ماند. دو هفته بعد کسی واحد اول را «خالی» می‌بیند.
نفر دوم برای پیدا کردن واحد خالی ردیف‌ها را با چشم اسکن می‌کند و ردیفی را جا می‌اندازد.
رزرو از یک پلتفرم آنلاین می‌رسد و در مجموعه‌ای با ده واحد، «یک ساعت دیرتر ثبت‌شدن» کافی است تا همان شب را کس دیگری هم بگیرد.
نتیجه این‌که روش خوب برای چند واحد، به‌جای حافظه‌ی آدم‌ها، یک ساختار سخت‌گیر می‌خواهد.
گام اول: ساختار ساختمان و واحد را یک بار و درست بسازید
هر واحد باید یک نام یکتا و بی‌ابهام داشته باشد که حتی پذیرش تازه‌کار هم اشتباه نگیرد. «واحد بالایی» یا «اتاق بزرگ‌تر» اسم نیست؛ «۲۰۱» و «۲۰۲» یا «یاس» و «نرگس» اسم است. قاعده‌ها:
اسم یا شماره‌ی واحد را همان چیزی بگذارید که روی در نوشته شده، یا روی در بنویسید.
اگر چند ساختمان دارید، اسم ساختمان را جدا نگه دارید و تکرارش نکنید در اسم واحد؛ ساختار «ساختمان ← واحد» خودش جا را مشخص می‌کند.
به هر واحد یک رنگ متمایز بدهید. رنگ، جدا از متن، سریع‌ترین راه تشخیص بصری است، مخصوصاً وقتی تقویم چند روز پشت‌سرهم را همزمان نشان می‌دهد.
واحد غیرفعال (در تعمیر یا فروخته‌شده) را حذف نکنید؛ غیرفعال کنید تا سابقه‌ی رزروهای قدیمی بماند.
در شاه‌کلید صفحه‌ی «واحدها» همین ساختار را می‌سازد: ابتدا ساختمان با نام و آدرس، و بعد واحدها با نام و رنگ. افزودن ساختمان تازه هم مرحله‌به‌مرحله است و می‌توانید واحدهایش را همان‌جا با هم تعریف کنید.
گام دوم: یک تقویم مرجع، نه چند تقویم موازی
توصیه‌ی مشترک راهنماهای مدیریت اجاره‌ی کوتاه‌مدت این است که برای هر مجموعه فقط یک تقویم «مرجع» داشته باشید و بقیه‌ی منابع، از دفتر تلفن تا اپلیکیشن پلتفرم‌ها، ورودی آن باشند نه رقیبش. راهنمای کاهش رزرو دوباره‌ی Guesty هم یکی از علت‌های اصلی تداخل را همین پراکندگی تقویم‌ها و خطای انسانی در بلوکه‌کردن واحد اشتباه می‌داند و تقویم متمرکز را راه‌حل می‌گیرد.
عملاً یعنی چه؟ یعنی این جمله را به همه‌ی تیم بگویید: «اگر در سامانه نیست، رزرو نیست.» کسی که تلفنی قول می‌دهد، باید همان لحظه در سامانه ثبت کند؛ نه بعد از ظهر، نه آخر شیفت. اگر ثبت تلفنی برایتان مسئله است، رزرو تلفنی و پیام‌رسان را چطور ثبت کنیم ریزه‌کاری‌هایش را باز کرده است.
«واحد رزروشده» با «واحد تحویل‌شده» فرق دارد
بیشتر ابزارهای ساده فقط یک ستون واحد دارند. اما در عمل دو سؤال متفاوت هست: مهمان چه واحدی را رزرو کرد، و الان واقعاً کجا نشسته است؟ اگر این دو را یکی بگیرید، هر جابجایی یا باعث می‌شود سابقه‌ی رزرو گم شود یا تقویم دروغ بگوید.
در شاه‌کلید هر رزرو یک «واحد» دارد (آنچه رزرو شده) و یک «واحد تحویل‌شده» (آنچه مهمان در آن اسکان یافته). به‌طور پیش‌فرض یکی هستند. اگر مهمان را جابجا کنید، فقط واحد تحویل‌شده را عوض می‌کنید؛ رزرو روی تقویم زیر ستون واحد جدید نمایش داده می‌شود ولی رنگش همان رنگ واحد رزروشده می‌ماند، تا دیده شود این رزرو جابجا شده است. بررسی تداخل هم روی واحد فیزیکی، یعنی واحد تحویل‌شده، انجام می‌شود.
مثال: فرض کنید مهمانی واحد ۲۰۱ را برای سه شب رزرو کرده و شب اول معلوم می‌شود شیر آب خراب است. او را به ۲۰۴ می‌برید. اگر فقط نام واحد را در ۲۰۱ نگه دارید، همان سه شب در تقویم «خالی» دیده می‌شود. اگر واحد تحویل‌شده را ۲۰۴ کنید، ۲۰۴ پر می‌شود و ۲۰۱ برای تعمیر آزاد دیده می‌شود. در عین حال اگر ۲۰۴ برای همان شب قبلاً رزرو داشته، سیستم همان لحظه هشدار تداخل می‌دهد، و شما قبل از جابجایی می‌فهمید که مقصد خالی نیست.
قاعده‌ی شب‌ها: خروج و ورود در یک روز تداخل نیست
اشتباه رایج دیگر، شمردن «روز» به‌جای «شب» است. رزروی که روز دهم ورود و روز دوازدهم خروج دارد، شب‌های دهم و یازدهم را اشغال می‌کند. رزرو بعدی می‌تواند روز دوازدهم وارد شود، چون تا ظهر روز دوازدهم واحد از اولی تخلیه می‌شود. تنها وقتی تداخل داریم که شبی در هر دو رزرو باشد.
رزرو اول | رزرو دوم | نتیجه |
|---|---|---|
۱۰ تا ۱۲ | ۱۲ تا ۱۴ | بدون تداخل (خروج و ورود در یک روز) |
۱۰ تا ۱۲ | ۱۱ تا ۱۳ | تداخل در شب ۱۱ |
۱۰ تا ۱۲ | ۸ تا ۱۱ | تداخل در شب ۱۰ |
۱۰ تا ۱۲ | ۸ تا ۱۰ | بدون تداخل |
(اعداد روزهای یک ماه فرضی‌اند.)
سامانه‌ی شاه‌کلید دقیقاً با همین منطق کار می‌کند: رزروی که لغو شده یا خروجش انجام شده در محاسبه‌ی تداخل نمی‌آید، و خروج و ورود هم‌روز بدون هشدار پذیرفته می‌شود. اگر بازه‌ی تازه با رزرو فعال دیگری شب مشترک داشته باشد، پنجره‌ای نام مهمان، کد و بازه‌ی رزرو متداخل را نشان می‌دهد و تأیید می‌گیرد. این تأیید یعنی تصمیم با شماست؛ مثلاً وقتی می‌دانید رزرو قبلی در حال لغو است. اما قاعده‌ی خوب این است که بدون هماهنگی با مسئول مجتمع، تأیید نهایی را نزنید.
چند ساختمان در شهرهای مختلف: یک نمای واحد یا چند نما؟
مجموعه‌ای با دو مجتمع در دو منطقه‌ی شهر، دو نیاز متفاوت دارد: مدیر باید همه را ببیند، و پذیرش هر مجتمع فقط مجتمع خودش را. این دو را با هم قاطی نکنید.
در تقویم رزرو شاه‌کلید، شما یک ساختمان انتخاب می‌کنید و ستون‌های آن، یعنی واحدهای همان ساختمان، با بازه‌ی روزهای دلخواه دیده می‌شود. این طراحی عمداً ساختمان‌به‌ساختمان است: وقتی ۲۰ واحد در یک صفحه بریزیم، برای تشخیص مشکل کمکی نمی‌کند. برای دید کلی، داشبورد ورودی‌ها، خروجی‌ها، تسویه‌های باز و واحدهای خالی امروز و فردا را نشان می‌دهد و فیلتر ساختمان دارد. اگر کار شما چند مجتمع است، راهنمای رشد از یک اقامتگاه تا چند مجتمع نگاه کلان‌تری دارد.
برای دسترسی تیم، کاربر در شاه‌کلید می‌تواند «محدود به ساختمان‌های مشخص» تعریف شود. در این حالت رزرو، واحد، مالی و داشبورد فقط برای همان ساختمان‌ها دیده می‌شود و تلاش برای انتقال رزرو به ساختمان غیرمجاز رد می‌شود؛ مدیر کل همه را می‌بیند. جزئیات سازمان‌دهی نیرو در مدیریت تیم نظافت و پذیرش در چند شعبه آمده است.
پلتفرم‌های آنلاین و دفتر تلفن؛ ورودی‌ها را یکی کنید
اگر بخشی از رزروها از پلتفرم‌های اجاره‌ی کوتاه‌مدت می‌آید، مسئله‌ی اصلی فاصله‌ی زمانی است. راهنماهای فروشندگان کانال‌منیجر می‌گویند همگام‌سازی با iCal ممکن است ساعت‌ها تأخیر داشته باشد و در همین فاصله دو نفر یک شب را بگیرند؛ این ادعا از منبع تجاری است و عدد دقیقش بسته به پلتفرم فرق می‌کند، اما منطق آن روشن است.
شاه‌کلید همگام‌سازی خودکار با جاباما، جاجیگا و پلتفرم‌های مشابه ندارد. پس قاعده‌ی عملی این است: به‌محض رسیدن رزرو از هر کانال، همان‌جا ثبتش کنید و در فیلد «منبع رزرو» نامش را بزنید (منابع از تنظیمات قابل ویرایش‌اند). بعد در پلتفرم‌های دیگر تاریخ را ببندید. ترتیب هم مهم است: اول تقویم مرجع خودتان، بعد بقیه.
بازبینی هفتگی، ده دقیقه‌ای
حتی بهترین سامانه از اشتباه ورودی جلوگیری نمی‌کند. یک جلسه‌ی کوتاه هفتگی، مثلاً هر شنبه صبح، چند چیز را می‌گیرد:
در تقویم هر ساختمان، برای هفته‌ی پیش‌رو رزروهای «در انتظار» را مرور کنید. هرکدام بیعانه یا تأیید دارد؟
واحدهایی که شب خالی بین دو رزرو دارند را ببینید؛ شاید بشود با تخفیف پر شوند.
رزروهایی که جابجا شده‌اند (رنگ واحد با ستون‌شان فرق دارد) بررسی شود که دلیل جابجایی ثبت شده باشد.
ورودی و خروجی سه روز آینده را با تیم نظافت چک کنید.
تقویم پلتفرم‌های بیرونی را با تقویم مرجع یکی‌یکی مقایسه کنید.
چک‌لیست راه‌اندازی برای مجتمع چندواحدی
هر واحد اسم یکتا و رنگ جدا دارد.
یک تقویم مرجع مشخص شده و همه‌ی ورودی‌ها به آن برمی‌گردد.
ثبت رزرو توسط هر کانال، با منبع درست، در همان لحظه انجام می‌شود.
جابجایی مهمان با تغییر واحد تحویل‌شده انجام می‌شود، نه با پاک‌کردن و ثبت دوباره.
هشدار تداخل بدون هماهنگی نادیده گرفته نمی‌شود.
دسترسی هر کاربر به ساختمان‌های خودش محدود شده است.
بازبینی هفتگی در برنامه است.
شاه‌کلید برای این کار چه می‌دهد؟
شاه‌کلید برای میزبانانی ساخته شده که چند واحد دارند: ساختمان و واحد با رنگ، تقویم ستونی هر ساختمان، فرم «رزرو سریع» برای ثبت از روی موبایل، هشدار تداخل هنگام ثبت و ویرایش، واحد تحویل‌شده برای جابجایی، و دسترسی محدود به ساختمان برای هر عضو تیم. چیزی که ندارد همگام‌سازی خودکار با پلتفرم‌های بیرونی است؛ این بخش با ثبت دستی شما انجام می‌شود.
سؤال‌های پرتکرار
برای ۱۰ واحد هم باید از نرم‌افزار استفاده کرد؟
لازم نیست، ولی دفترچه و اکسل به‌سرعت زیر بار تعداد واحد و تعداد نفرات تیم خم می‌شوند. معیار ساده: اگر بیش از یک نفر رزرو ثبت می‌کند یا بیش از یک کانال دارید، ساختاری که تداخل را خودکار نشان بدهد خطای انسانی را به شکل محسوسی کم می‌کند.
بهتر است هر مجتمع تقویم جدا داشته باشد یا همه یکی؟
داده را در یک سامانه نگه دارید ولی نمایش را بر اساس ساختمان جدا کنید. مدیر با داشبورد کلی کار می‌کند و پذیرش هر مجتمع فقط ساختمان خودش را می‌بیند. تقویم جدا برای هر مجتمع در فایل‌های مجزا، دید مدیر را از بین می‌برد.
اگر مهمان را به واحد دیگری بردیم، رزرو را حذف کنیم و دوباره بسازیم؟
نه. حذف، سابقه‌ی پرداخت‌ها و یادداشت‌ها را از بین می‌برد. بهتر است واحد تحویل‌شده را تغییر دهید تا رزرو، قیمت و تاریخچه همان‌طور بماند و فقط محل اسکان عوض شود.
هشدار تداخل را نادیده بگیرم یا نه؟
فقط وقتی دلیل مشخصی دارید، مثلاً رزرو قبلی در شرف لغو است یا اشتباه ثبت شده. بهتر است قبل از تأیید، رزرو قدیمی را اصلاح یا لغو کنید تا تقویم دوباره درست شود، و دلیل را در یادداشت رزرو بنویسید.
رزروهای لغوشده تقویم را پر نگه می‌دارند؟
در شاه‌کلید رزرو لغوشده در محاسبه‌ی تداخل نمی‌آید، پس شب‌هایش دوباره قابل رزرو است. رزرو لغوشده روی تقویم کمرنگ دیده می‌شود تا سابقه‌اش پنهان نشود.
مطالب مرتبط
رزرو تکراری در اقامتگاه؛ علت و راه جلوگیری — رزرو تکراری یعنی دو مهمان برای یک واحد و یک شب قول گرفته‌اند. اینجا می‌بینید از کجا شروع می‌شود، چطور با یک تقویم…
ثبت رزرو تلفنی و واتساپی اقامتگاه — بیشتر رزروهای گم‌شده در تماس تلفنی و چت واتساپ شروع می‌شوند. فهرست حداقل اطلاعاتی که باید ثبت شود، ترتیب درست کارها…
تقویم اقامتگاه؛ دفترچه، اکسل یا نرم‌افزار؟ — دفترچه برای یک واحد با رزرو کم کافی است، اکسل تا چند واحد جواب می‌دهد و نرم‌افزار وقتی لازم می‌شود که ثبت‌کننده‌ها یا…
نظرها