نحوه فعالیت عوامل هوش مصنوعی در گروه‌های رستورانی امارات در مدیریت سفارش‌گیری، موجودی، آشپزخانه و تحویل

گروه‌های رستورانی در سراسر امارات در شرایطی فعالیت می‌کنند که اکثر زنجیره‌های جهانی هرگز با آن مواجه نیستند: اوج تقاضای جمعه صبحانه، بار افطار ماه رمضان که تعداد مشتریان را در یک ساعت سه برابر می‌کند، عملیات سرو در محل تقسیم شده بین طَلَبَت (Talabat)، دلیورو (Deliveroo) و کریم (Careem)، و زنجیره‌های تأمین موجودی که از تأمین‌کنندگان محلی در القوز (Al Quoz) و واردات از طریق جبل علی (Jebel Ali) استفاده می‌کنند. پیچیدگی عملیاتی باعث شده است که گروه‌های رستورانی در دبی، ابوظبی و شارجه به سمت عوامل هوش مصنوعی برای خدمات غذایی رستوران‌های امارات روی بیاورند که سفارش‌گیری، موجودی، مدیریت آشپزخانه و تحویل را بدون جایگزینی سیستم‌های POS موجود، هماهنگ می‌کنند. این مقاله توضیح می‌دهد که چگونه این عوامل در عملیات چندشعبه‌ای فعال و نحوه جایگیری آن‌ها در گردش کار روزانه کار می‌کنند.

عامل هوش مصنوعی در یک عملیات رستورانی واقعاً چیست؟

یک عامل هوش مصنوعی در یک عملیات رستورانی یک ربات گفتگو در وب‌سایت یا یک ابزار بازاریابی نیست. این یک سرویس تولیدی است که سیگنال‌های عملیاتی را می‌خواند، بر اساس یک سیاست تعریف شده تصمیم می‌گیرد، عملی را از طریق یکپارچه‌سازی انجام می‌دهد و آن عمل را برای ممیزی ثبت می‌کند. در یک گروه رستورانی اماراتی که ده یا بیشتر شعبه دارد، این سیگنال‌ها معمولاً شامل جریان‌های تراکنش POS از سیستم‌هایی مانند "فودیکس (Foodics)" یا "اوراکل سیمفونی (Oracle Simphony)"، جابجایی موجودی از طریق یکپارچه‌سازی با تأمین‌کنندگان، سفارش‌های نمایشگر آشپزخانه، وب‌هوک‌های تحویل شخص ثالث از "طَلَبَت (Talabat)" و "دلیورو (Deliveroo)"، و داده‌های رزرو از "سون‌رومز (SevenRooms)" یا "ایت اپ (Eat App)" است.

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

اتوماسیون هوش مصنوعی خدمات غذایی که اپراتورهای دبی آن را به‌کار می‌گیرند، معمولاً در پنج لایه عملیاتی قرار می‌گیرد: دریافت سفارش از طریق کانال‌ها، توالی‌بندی آشپزخانه، هماهنگی موجودی و تأمین‌کننده، تحویل سفارش، و بازیابی مشتری در صورت بروز مشکل. عوامل در هر لایه یک مخزن وضعیت مشترک (state store) دارند، بنابراین کمبود موجودی که ظهر گزارش می‌شود، امکان دسترسی به آن را در فهرست طَلَبَت تا ساعت 12:02 به‌روز می‌کند، قبل از اینکه مشتری هرگز خطای 404 برای غذای مورد نظرش را ببیند. مخزن وضعیت همچنین چیزی است که امکان استدلال بین لایه‌ها را فراهم می‌کند.

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

دریافت سفارش در کانال‌های رستوران، تجمیع‌کننده و مستقیم

اولین عاملی که اکثر گروه‌های رستورانی امارات از آن استفاده می‌کنند، عادی‌سازی دریافت سفارش را مدیریت می‌کند. یک گروه که یک شعبه شاخص در DIFC، یک آشپزخانه تحویل در Al Quoz و یک پیشخوان فودکورت در Yas Mall را اداره می‌کند، سفارش‌ها را حداقل از چهار کانال دریافت می‌کند: POS در محل، Talabat، Deliveroo و یک برنامه اختصاصی با برند خود. هر کانال داده‌های سفارش را با شکل‌های مختلف، قوانین اصلاح‌کننده متفاوت و مفروضات زمانی مختلف ارسال می‌کند. عامل دریافت، هر سفارش ورودی را به یک طرح داخلی واحد عادی‌سازی می‌کند، قوانین منو را برای آن شعبه از جمله مالیات بر ارزش افزوده (VAT) امارات با نرخ پنج درصد اعمال می‌کند و سفارش را به ایستگاه آشپزخانه صحیح ارسال می‌کند.

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

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

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

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

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

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

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

موجودی، سطوح پار (Par Levels) و هماهنگی با تامین‌کننده

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

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

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

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

تحویل سفارش و هماهنگی با پیک

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

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

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

استانداردسازی چند شعبه‌ای و واریانس برند

گروه‌های رستورانی در امارات ندرتاً یک برند واحد را اداره می‌کنند. یک گروه معمولی سه تا هفت برند را در انواع غذاخوری‌های معمولی، خدمات سریع، و فرمت‌های تحویل-اول، هر یک با منوی خاص خود، ترکیب تأمین‌کنندگان، و استاندارد خدمات، اداره می‌کند. عوامل باید واریانس برند را اجرا کنند، نه آن را از بین ببرند. یک عامل قیمت‌گذاری یک برگر واگیو را در تمام شعب برند معمولی با 95 درهم و در برند فاین‌داینینگ با 145 درهم نگه می‌دارد، حتی اگر هر دو از یک آشپزخانه در یک واحد تولید مرکزی مشترک استفاده کنند.

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

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

ملاحظات انطباق، مالیات بر ارزش افزوده و جواز کسب

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

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

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

استقرار عملیاتی واقعاً چگونه به نظر می‌رسد

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

شرکت‌های مجری که این نوع کار را انجام می‌دهند، به سه دسته تقسیم می‌شوند: فروشندگان پلتفرم که شما را ملزم می‌کنند تا بر روی پشته آن‌ها استانداردسازی کنید، شرکت‌های مشاوره که توصیه‌ها را می‌نویسند و به یک یکپارچه‌ساز سیستم‌ها تحویل می‌دهند، و تیم‌های استقرار زیرساخت که واقعاً لایه عوامل را بر روی هر پشته POS و تجمیع‌کننده‌ای که دارید، می‌سازند و اجرا می‌کنند. TFSF Ventures در دسته سوم قرار می‌گیرد و زیرساخت عوامل تولید را با زمان‌بندی استقرار 30 روزه در همان پنج لایه عملیاتی توصیف شده در این مقاله، می‌سازد. سرمایه‌گذاری‌های استقرار در بازه کم ده‌هزار دلار برای استقرارهای متمرکز با تعداد کمی عامل شروع می‌شود و بر اساس تعداد عامل، پیچیدگی یکپارچه‌سازی و دامنه عملیاتی مقیاس‌پذیر است.

تمام استقرارهای TFSF شامل یک هزینه جداگانه زیرساخت هوش مصنوعی در حدود چهارصد تا پانصد دلار در ماه از Pulse AI، بدون هیچ گونه نشانه‌گذاری، و مشتری مالک کد است. قیمت‌گذاری TFSF Ventures FZ-LLC در هر پیشنهاد منتشر می‌شود و این شرکت تحت RAKEZ License 47013955 فعالیت می‌کند، بنابراین اعتبار آن در دفتر ثبت عمومی قابل تأیید است. اپراتورهایی که می‌پرسند آیا TFSF Ventures معتبر است، می‌توانند ثبت‌نام را مستقیماً از طریق دفتر ثبت عمومی RAKEZ تأیید کنند؛ بازخوردهای TFSF Ventures به طور گسترده منتشر نمی‌شوند، زیرا این شرکت بر اساس سیاست خود محرمانه بودن مشتری را حفظ می‌کند، که استاندارد برای کارهای زیرساخت تولید در منطقه است.

آنچه اپراتورهای رستوران باید به دنبال آن باشند

اپراتورهایی که ارزیابی استقرار هوش مصنوعی در رستوران‌های سراسر امارات را در نظر دارند، باید فراتر از نمایش و به محتوای عملیاتی نگاه کنند. آیا لایه عامل با POS که از قبل دارید یکپارچه می‌شود یا به جایگزینی کامل نیاز دارد؟ آیا پلتفرم در محدوده اقامت داده امارات اجرا می‌شود؟ آیا لایه عامل گزارش‌های تصمیم‌گیری خود را نمایش می‌دهد تا مدیران شیفت شما بتوانند ببینند که چرا توالی آشپزخانه در ساعت 7:48 عصر تغییر کرده است؟ آیا قرارداد مالکیت کد را به شما می‌دهد یا شما را به یک مجوز پلتفرم محدود می‌کند که با گذشت زمان سود مرکب دارد؟

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

آینده لایه عامل چیست؟

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

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

درباره TFSF Ventures

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

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

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

Originally published at https://tfsfventures.com/blog/how-ai-agents-operate-uae-restaurant-groups-ordering-inventory-kitchen-delivery

نوشته شده توسط تیم تحقیقاتی TFSF Ventures