چرا بهترین عوامل هوش مصنوعی برای هتل‌ها و مهمان‌نوازی نیاز به مدیریت استثنائات برای رزروهای بیش از ظرفیت، VIP Holds و اختلالات بلوک‌های گروهی دارند

اکثر استقرارهای هوش مصنوعی هتل در یک نقطه خاص شکست می‌خورند. نه در دمو، نه در ادغام، نه در هفته اول راه‌اندازی. آنها در اولین باری که مشکلی پیش می‌آید که عامل به طور صریح برای مدیریت آن طراحی نشده بود، شکست می‌خورند. رزرو بیش از ظرفیت در یک شنبه پر. یک VIP Hold که با یک رزرو تأیید شده تضاد دارد. یک بلوک گروهی که سرعت تحویل را 48 ساعت قبل از ورود تغییر می‌دهد. اینها موارد استثنائی نیستند. اینها واقعیت عملیاتی مدیریت یک هتل هستند، و دقیقاً در اینجاست که اکثر پلتفرم‌های عامل یا متوقف می‌شوند، همه چیز را به انسان‌ها محول می‌کنند، یا به آرامی تصمیماتی می‌گیرند که مشکلات بزرگ‌تری در ادامه ایجاد می‌کند.

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

واقعیت تولیدی که دموها هرگز نشان نمی‌دهند

عملیات هتل با استثنائات تعریف می‌شود. مسیر عادی، جایی که هر رزرو به موقع می‌رسد، هر اتاق آماده است، هر پرداخت به طور کامل تأیید می‌شود، و هر درخواست مهمان با پیشنهاد استاندارد ملک مطابقت دارد، شاید 60 تا 70 درصد فعالیت روزانه در یک ملک خوب مدیریت شده را شامل شود. 30 تا 40 درصد باقیمانده جایی است که پیچیدگی عملیاتی واقعاً وجود دارد، و در آنجا تفاوت بین اپراتورهای توانمند و اپراتورهای آشفته مشخص می‌شود.

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

VIP Holds مجموعه‌ای موازی از استثنائات را ایجاد می‌کنند. یک عضو وفادار الماس یک اتاق کینگ استاندارد را در یک شب پر رزرو می‌کند. استاندارد برند نیاز به ارتقاء در صورت موجود بودن دارد. ملک در حالت استاندارد پر است، اما یک سوئیت برای یک نگه‌داشت شرکتی رزرو شده است که هنوز تأیید نشده است. عامل باید ارزیابی کند که آیا عضو وفادار را به سوئیت ارتقاء دهد، برای رزرو شرکتی نگه دارد، شرکتی را به یک کینگ استاندارد در صورت تأیید تنزل دهد، یا کل تصمیم را به یک انسان واگذار کند. هر انتخابی پیامدهای بعدی دارد، و پاسخ صحیح به عواملی بستگی دارد که هیچ قانون استاتیکی نمی‌تواند آن‌ها را پوشش دهد.

اختلالات بلوک‌های گروهی همه چیز را تقویت می‌کنند. یک بلوک 200 اتاقه برای یک کنفرانس شرکتی 72 ساعت قبل از ورود به 140 اتاق کاهش می‌یابد. ملک اکنون 60 اتاق برای فروش در بازاری دارد که ممکن است آنها را جذب کند یا نکند، با تصمیمات استراتژی نرخ که از طریق هر کانالی منتشر می‌شود و یک تماس گروهی که باید با دقت مدیریت شود زیرا رابطه فراتر از این رویداد واحد اهمیت دارد. عاملی که نمی‌تواند از طریق این سناریوها دلیل‌ورزی کند، در واقع عملیات را اجرا نمی‌کند. او فقط بخش‌های آسان را اجرا می‌کند و بخش‌های سخت را برای حسابدار شب در ساعت 3 صبح می‌گذارد.

چرا مدیریت استثنائات باید ابتدا طراحی شود

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

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

مدیریت استثنائات که ابتدا طراحی شده باشد به این معنی است که عامل از روز اول برای تشخیص لحظه‌ای که به مرز اختیارات تصمیم‌گیری خود رسیده است، ثبت کامل زمینه در مورد وضعیت، هدایت به انسان مناسب با تمام آنچه آن انسان برای تصمیم‌گیری سریع نیاز دارد، و یادگیری از راه‌حل انسان برای گسترش مرز تصمیم‌گیری خود در طول زمان، طراحی شده است. این اساساً با عاملی که موارد روتین را مدیریت می‌کند و استثنائات را بدون زمینه به انسان‌ها واگذار می‌کند، متفاوت است.

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

معماری استثنائات سه لایه

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

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

لایه سوم بستن حلقه یادگیری است. هر تصمیم انسانی در مورد یک استثنای تشدید شده ثبت و ساختاریافته می‌شود. با گذشت زمان، عامل یک کتابخانه از الگوهای استثنا و تصمیماتی که انسان‌ها واقعاً گرفته‌اند، می‌سازد که به محدوده تصمیم‌گیری عامل بازگردانده می‌شود. یک استثنا که عامل ماه گذشته 50 بار آن را تشدید کرده بود، جایی که انسان همیشه همان تصمیم را گرفته بود، برای ماه آینده به یک تصمیم خودکار تبدیل می‌شود و بررسی انسانی به بررسی نقطه‌ای به جای تأیید هر مورد منتقل می‌شود.

این معماری سه لایه چیزی است که عوامل مقیاس‌پذیر را از عوامل ثابت جدا می‌کند. بدون آن، عامل یا بیش از حد تشدید می‌کند و کارکنان را ناامید می‌کند، یا تصمیمات بی‌صدا می‌گیرد که مشکلات بعدی ایجاد می‌کند که هیچ‌کس آنها را به عامل مرتبط نمی‌کند. با آن، محدوده تصمیم‌گیری عامل به طور مداوم گسترش می‌یابد در حالی که انسان‌ها بر استثنائات واقعاً جدید تمرکز می‌کنند که نیاز به قضاوتی دارند که سیستم هنوز یاد نگرفته است.

مدیریت استثنائات رزرو بیش از ظرفیت به تفصیل

رزرو بیش از ظرفیت دسته‌ای از استثنائات است که در آن عوامل هوش مصنوعی مهمان‌نوازی یا ارزش خود را ثابت می‌کنند یا محدودیت‌های خود را نشان می‌دهند. تصمیم درگیر هنگام oversold شدن یک ملک چند بعدی است. اینکه کدام مهمان به هتل دیگری فرستاده شود یک قانون ساده نیست. به وضعیت وفاداری، منبع رزرو، روش پرداخت، مدت اقامت، وابستگی گروهی، درخواست‌های ویژه، و روابط ملک با مقاصد احتمالی انتقال بستگی دارد.

یک عامل با معماری خوب، جمع‌آوری داده‌ها را به طور خودکار انجام می‌دهد. هنگامی که ملک به oversold می‌رسد، عامل هر رزرو را با زمینه کامل مورد نیاز برای تصمیم‌گیری انتقال نشان می‌دهد. رتبه وفاداری، ارزش طول عمر، زمینه سفر فعلی، پرچم‌های مناسبت خاص، وابستگی گروهی، و هزینه انتقال هر نامزد بر اساس الگوهای جبرانی قبلی. تصمیم انتقال انسانی در چند دقیقه رخ می‌دهد به جای 30 تا 60 دقیقه که یک مدیر معمولاً صرف بازسازی دستی همان زمینه می‌کند.

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

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

استثنائات VIP Hold و سلسله مراتب لغو

VIP holds استثنائاتی را ایجاد می‌کنند که سلسله مراتب لغوی واضحی را می‌طلبند که عامل بتواند از آن دلیل‌ورزی کند. یک رزرو استاندارد برای یک مهمان تأیید شده نگه داشته می‌شود. یک VIP hold یک بلوک نرم برای مهمانی است که هنوز تأیید نشده است اما به اندازه کافی کسب و کار را نشان می‌دهد که ملک مایل است از سایر درآمدها صرف نظر کند تا در دسترس بودن را حفظ کند. یک نگه‌داشت شرکتی یک تعهد قراردادی است که ممکن است محقق شود یا نشود. نیاز به ارتقاء وفاداری یک استاندارد برند است که باید در صورت موجود بودن رعایت شود.

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

سلسله مراتب لغو که عوامل تولیدی پیاده‌سازی می‌کنند، معمولاً الگوی تعریف شده‌ای را دنبال می‌کند. رزروهای تأیید شده با تأیید پرداخت غیرقابل نقض هستند. ارتقاء استاندارد برند برای اعضای وفادار در صورت موجود بودن قبل از ارتقاء اختیاری رعایت می‌شود. VIP holds برای تبدیل با احتمال بالا در برابر انتشار موجودی عمومی محافظت می‌شوند. نگه‌داشت‌های شرکتی در برابر نرخ‌های تبدیل تاریخی و تقاضای بازار فعلی ارزیابی می‌شوند. عامل این سلسله مراتب را به طور خودکار برای موارد روتین اعمال می‌کند و موارد واقعاً مبهم را با دلیل‌ورزی کامل قابل مشاهده برای انسان تشدید می‌کند.

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

اختلالات بلوک گروهی و مشکل پی‌آمدهای زنجیره‌ای

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

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

آنچه این را دشوار می‌کند این است که تصمیمات به هم وابسته هستند. انتشار موجودی با نرخ‌های تهاجمی بر قیمت‌گذاری فروش اضافی تأثیر می‌گذارد. اطلاع‌رسانی جریمه‌های کاهش بر رابطه با مخاطب گروه تأثیر می‌گذارد، که بر احتمال رزرو آینده تأثیر می‌گذارد. تنظیم ارتباط شرکت‌کنندگان گروهی بر نرخ عدم نمایش تأثیر می‌گذارد، که بر میزان تهاجمی بودن انتشار موجودی حاصل از کاهش تأثیر می‌گذارد. عاملی که هر تصمیم را به طور جداگانه مدیریت می‌کند، انتخاب‌های محلی بهینه را انجام می‌دهد که به نتایج کلی غیربهینه منجر می‌شود.

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

مشکل کالیبراسیون مرز تصمیم‌گیری

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

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

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

ارزیابی عملیاتی 19 سؤاله که استقرارهای هوش مصنوعی هتل را به خوبی تعریف می‌کند، شامل سؤالات صریح در مورد انتظارات مرز تصمیم‌گیری و تحمل ریسک است. املاکی که قبل از انتخاب عامل، به این سؤالات فکر کرده‌اند، تصمیمات بهتری در مورد فروشنده می‌گیرند و سریع‌تر مستقر می‌شوند. املاکی که از این مرحله صرف نظر می‌کنند، یا با پیش‌فرض‌های عامل مبارزه می‌کنند یا مرزهای تصمیم‌گیری را می‌پذیرند که با مشخصات ریسک عملیاتی آنها مطابقت ندارد.

هزینه مدیریت استثنائات در سطح تولیدی

معماری مدیریت استثنائات در وهله اول بیشتر از شروع با اتوماسیون مسیر عادی هزینه دارد. کار نقشه‌برداری در هفته اول واقعاً دشوار است زیرا اکثر املاک الگوهای استثنائات خود را مستند نکرده‌اند. کار معماری در هفته دوم به قضاوت مهندسی ارشد نیاز دارد که در استقرارهای مختلف مورد استفاده مجدد قرار نمی‌گیرد زیرا ترکیب استثنائات هر ملک متفاوت است. زیرساخت مسیریابی در هفته سوم یکپارچه‌سازی سفارشی در ابزارهای ارتباطی و گردش کار موجود ملک است.

هزینه در در سرمایه‌گذاری استقرار آشکار می‌شود. هتل‌هایی که معماری عامل استثنا-محور را از یک شرکت معماری سرمایه گذاری سفارش می‌دهند، شاهد سرمایه‌گذاری‌های استقرار هستند که از ده‌ها هزار دلار برای استقرارهای متمرکز با تعداد کمی عامل شروع می‌شود و با تعداد عامل، پیچیدگی یکپارچه‌سازی و دامنه عملیاتی مقیاس می‌یابد. همه استقرارها شامل هزینه پردازش زیرساخت هوش مصنوعی جداگانه‌ای حدود چهارصد تا پانصد دلار در ماه از Pulse AI، به قیمت تمام شده و بدون مارک‌آپ، می‌شوند. مشتری پس از تحویل مالک کد است، که قفل فروشنده‌ای را که اکثر قراردادهای هوش مصنوعی مهمان‌نوازی را تعریف می‌کند، از بین می‌برد.

TFSF Ventures FZ-LLC (RAKEZ License 47013955) قیمت‌گذاری خود را به طور شفاف در هر پیشنهاد منتشر می‌کند و اپراتورهایی که در حال ارزیابی مشروعیت TFSF Ventures هستند، می‌توانند شرکت را از طریق RAKEZ License 47013955 در ثبت عمومی تأیید کنند.

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

آنچه اپراتورها واقعاً می‌خرند، عامل نیست. آنها معماری را می‌خرند که به عامل اجازه می‌دهد واقعیت عملیاتی مدیریت یک هتل را تحمل کند. خود عامل به طور فزاینده‌ای کالایی شده است. معماری مدیریت استثنائات، کالیبراسیون مرز تصمیم‌گیری، حلقه یادگیری که تشدیدها را به اتوماسیون گسترده تبدیل می‌کند، اینجاست که ارزش پایدار زندگی می‌کند. 21 صنعتی که این معماری در آنها اثبات شده است، مهمان‌نوازی را به عنوان یکی از پرتقاضاترین آنها به دلیل تراکم و تنوع استثنائات که یک هتل هر هفته مدیریت می‌کند، شامل می‌شود.

سؤالات ارزیابی فروشنده که قابلیت واقعی را آشکار می‌کند

اکثر فرآیندهای ارزیابی فروشنده برای عوامل هوش مصنوعی مهمان‌نوازی بر سؤالات اشتباهی تمرکز دارند. فهرست ویژگی‌ها، تعداد ادغام‌ها، و لوگوهای مشتری نشان نمی‌دهند که آیا پلتفرم استثنائات را در تولید مدیریت می‌کند یا خیر. سؤالاتی که قابلیت را آشکار می‌کنند، عملیاتی و خاص هستند. عامل چگونه پاسخ می‌دهد وقتی یک کارت 24 ساعت قبل از ورود در یک رزرو تأیید شده رد می‌شود. مسیر دقیق تصمیم‌گیری، داده‌هایی که عامل استفاده می‌کند، و مسیر تشدید در صورتی که عامل نتواند مشکل را حل کند، را توضیح دهید.

عامل چگونه یک VIP hold را که با یک رزرو تأیید شده در زمانی که ملک پر است در تضاد است، مدیریت می‌کند؟ فرآیند استدلال واقعی که عامل استفاده می‌کند، متغیرهایی که در نظر می‌گیرد، و ساختار انتقال انسانی در صورتی که عامل مشکل را تشدید کند را نشان دهید. عامل چگونه پاسخ می‌دهد وقتی یک بلوک گروهی 200 اتاقه 72 ساعت قبل از ورود به 140 اتاق کاهش می‌یابد؟ پاسخ هماهنگ را در نرخ، موجودی، فروش اضافی، ارتباطات، و دفتر پشتیبان توضیح دهید و توالی واقعی اقدامات عامل را در یک محیط Sandbox نشان دهید.

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

الگوی سؤالات به نحوه مدیریت نقض‌های مرز عامل توسط فروشنده گسترش می‌یابد. چه اتفاقی می‌افتد وقتی عامل تصمیمی می‌گیرد که کارکنان با آن مخالف هستند؟ این مخالفت چگونه ثبت می‌شود؟ مرز تصمیم‌گیری عامل بر اساس الگوهای مخالفت چگونه تنظیم می‌شود؟ وقتی مالکیت می‌پرسد چرا عامل یک تصمیم مهم خاص را گرفته است، سابقه حسابرسی چیست؟ این سؤالات حاکمیت عملیاتی به اندازه خود قابلیت تصمیم‌گیری مهم هستند.

چرا این معماری فراتر از مهمان‌نوازی اهمیت دارد

معماری مدیریت استثنائات شرح داده شده در اینجا در مثال‌هایش خاص عملیات هتل است اما در اصولش عمومی است. هر بخش عملیاتی معادل رزروهای بیش از ظرفیت، VIP holds، و اختلالات گروهی خود را دارد. برنامه‌ریزی مراقبت‌های بهداشتی دارای آبشار لغو و تضادهای در دسترس بودن ارائه‌دهنده است. مدیریت املاک دارای همپوشانی اجاره و اورژانس‌های نگهداری است. لجستیک دارای اختلالات ظرفیت حمل‌کننده و نگه‌داشت‌های گمرکی است. الگوی تصمیمات روتین با حجم بالا که با استثنائات مهمی که نیاز به قضاوت دارند، در هر جایی که عملیات پیچیده می‌شود، ظاهر می‌شود.

آنچه مهمان‌نوازی را به یک میدان آزمایش مفید تبدیل می‌کند، تراکم انواع استثنائات و فوریت پیامدها است. یک تصمیم بد رزرو بیش از ظرفیت در عرض چند ساعت به رابطه با مهمان آسیب می‌رساند. یک تصمیم بد VIP hold یک حادثه شهرت ایجاد می‌کند که از طریق کانال‌های جامعه وفاداری منتشر می‌شود. یک پاسخ بد به بلوک گروهی به قرارداد six ماهه آسیب می‌رساند. حلقه بازخورد به اندازه‌ای سریع است که معماری یا دوام می‌آورد یا نه، و اپراتورهایی که عوامل را در چندین فصل اوج اجرا کرده‌اند، تفاوت بین پلتفرم‌هایی که دوام می‌آورند و پلتفرم‌هایی که به آرامی بازنشسته می‌شوند را می‌دانند.

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

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

درباره TFSF Ventures

TFSF Ventures FZ-LLC (RAKEZ License 47013955) یک شرکت معماری سرمایه گذاری است که زیرساخت عامل هوشمند را در کسب و کارها از طریق سه ستون یکپارچه مستقر می‌کند: زیرساخت عامل‌محور، پرداخت‌های غیرسنتی، و یک موتور سرمایه‌گذاری کامل. با 27 سال سابقه در پرداخت‌ها و نرم‌افزار، TFSF در سطح جهانی فعالیت می‌کند و به 21 صنعت با متدولوژی استقرار 30 روزه خدمات ارائه می‌دهد. اطلاعات بیشتر را در https://tfsfventures.com بدست آورید.

ارزیابی هوش عملیاتی رایگان را انجام دهید

به چند سؤال کوتاه درباره کسب و کار خود پاسخ دهید. یک طرح اولیه استقرار هوش مصنوعی سفارشی را ظرف 24 تا 48 ساعت دریافت کنید که شامل توصیه‌های عامل، معماری، و یک نقشه راه خاص برای عملیات شماست. بدون تماس فروش. بدون تعهد. فقط داده. شروع کنید در https://tfsfventures.com/assessment

اولین بار در https://tfsfventures.com/blog/why-the-best-ai-agents-for-hotels-and-hospitality-need-exception-handling منتشر شد.

نوشته شده توسط TFSF Ventures Research