Зменште роботу з меню до 90%: Посібник для менеджерів з кількох локацій

Зміст

• Що таке управління меню для кількох локацій і чому це важливо?
• Що насправді має робити централізована система меню?
• Як впроваджувати зміни в меню, не зламавши нічого?
• Які результати ви повинні побачити після централізації вашого меню?
• Які помилки роблять оператори з кількома локаціями?
• Як RESTOBOT обробляє централізований контроль меню
• Готові централізувати своє меню?
• Джерела
• Часті запитання

Що таке управління меню для кількох локацій і чому це важливо?

Майстер-елемент - це основний запис для кожної страви, модифікатора та комбо, які продає ваш бренд, з одним унікальним ID для кожного елемента в усіх системах, які його використовують. Як тільки цей запис існує, одне редагування (зміна ціни, нове фото, позначка "немає в наявності") повинно поширитися на ваш пункт продажу, кіоски для самостійного замовлення, ваш веб-сайт або додаток, а також на всі платформи доставки третьої сторони, які ви використовуєте, без повторного введення тієї ж інформації шість разів.

Фрагментація проявляється швидко, як тільки ви переходите до кількох локацій або додаєте канал доставки. Централізований майстер-елемент дозволяє одному редагуванню поширюватися всюди, що важливо більше, ніж це звучить на папері, оскільки оператори без нього часто підтримують одне й те ж меню через кілька відокремлених систем. Кожне дублювання - це ще одне місце, де ціна може змінитися, примітка про алерген може застаріти, або знятий з продажу товар може продовжувати приймати замовлення, збільшуючи ризики оперативних помилок.

Критична точка зазвичай настає приблизно на трьох-п'яти локаціях або в момент, коли ви додаєте другий канал замовлення, окрім обслуговування в залі. Декілька ознак того, що ви її перетнули, такі як обробка меню, що містять такі елементи, як сейтан донер, це:

• Менеджери магазинів редагують ціни в POS, не повідомляючи нікого в головному офісі.
• Один і той же бургер коштує по-різному на Uber Eats, ніж на прилавку.
• Сезонний товар знімається з меню кіоску одного місця, але залишається активним у списку доставки.
• Ніхто не може сказати, не перевіривши п’ять систем, чи продає кожен магазин зараз одне й те саме.

Кожен з цих розривів призводить до помилок у замовленнях, запитів на повернення та скарг гостей, які єдине джерело правди могло б виявити ще до того, як це дійшло до клієнта.

Що має насправді робити централізована система меню?

Меню платформа отримує ярлик "централізована" лише якщо вона виконує конкретний набір завдань, а не просто відображення меню. Ось контрольний список, до якого варто притягувати постачальників:

1. Єдина база даних товарів з унікальними ID. Кожна страва, модифікатор і комбо існує один раз, з вкладеними групами модифікаторів (соуси, розміри, доповнення), прикріпленими до батьківського елемента, а не відновленими для кожного місця.
2. Правила, специфічні для каналів. Часові частини, ціни лише для доставки, право на комбо та наявність запасів потребують власного логічного рівня, оскільки обідня спеціальність не повинна з’являтися в додатку доставки о 10 вечора.
3. Групи локацій з перевагами. Магазини за замовчуванням успадковують основне меню, а потім застосовують свої власні винятки щодо цін або наявності, що дозволяє місцевим магазинам адаптуватися в межах встановлених головним офісом рамок, а не змушує кожен ринок відповідати одній ціновій точці.
4. Дозволи на основі ролей та аудиторські сліди. Хтось у головному офісі складає та затверджує; менеджери магазинів отримують більш вузькі права, такі як перемикання "86'd" товарів, а не зміна базових цін.
5. Надійна синхронізація з POS та інтеграціями доставки. Запитайте постачальників, що насправді означає "в реальному часі" в хвилинах, а не в маркетинговій мові, оскільки затримка в 15 хвилин на оновлення цін дуже відрізняється від п’яти секунд.

Порада: *Перед тим, як підписати угоду з будь-якою платформою меню, запитайте про їхній середній час поширення від одного редагування до його появи в додатку доставки третьої сторони. Якщо вони не можуть дати вам число, вважайте, що це повільніше, ніж вам потрібно.*

Як внести зміни в меню, не зламавши щось?

Управління - це частина, яку більшість операторів пропускає, і це та частина, яка насправді запобігає катастрофам. Ставитися до переходу на централізовані меню як до операційної зміни, а не просто до покупки програмного забезпечення, є основним уроком з керівництва з масштабування багатьох одиниць, оскільки нові інструменти без нового процесу просто переміщують той самий хаос.

1. Спочатку налаштуйте таксономію. Визначте структуру категорій, правила найменування та логіку модифікаторів перед тим, як мігрувати хоча б один елемент. Впровадження таксономії після запуску значно болісніше, ніж зробити це заздалегідь.
2. Визначте, хто може робити що. Чернетка, затвердження, публікація та скасування повинні бути чотирма окремими дозволами, часто чотирма різними людьми, щоб жоден один клік не міг запустити неперевірену зміну ціни по всій мережі.
3. Розгорніть оновлення в три етапи. Спочатку внесіть зміни в середовище розробки/тестування, потім в пілотну групу з двох або трьох реальних магазинів, а потім в повну мережу, як тільки пілот пройде 48-72 години без помилок.
4. Запустіть фіксований контрольний список тестування на кожному редагуванні. Підтверджуйте, що ціни відображаються правильно на кожному каналі, етикетки алергенів зберігаються, переходи між частинами дня спрацьовують за розкладом, а попередній перегляд у додатку для доставки відповідає тому, що гості насправді побачать перед оформленням замовлення.
5. Складіть план скасування до того, як він вам знадобиться. Знайте точно, як скасувати погане оновлення ціни або терміново 86 зняти товар з усіх каналів за лічені хвилини, а не години, і призначте когось для моніторингу обсягу замовлень на аномалії відразу після кожного оновлення.

Контрольний список для впровадження, побудований навколо цих етапів, як структуровані шаблони розгортання, які менеджери використовують у свої перші 90 днів, надає новим локаціям повторюваний шлях замість імпровізації управління магазин за магазином.

Які результати ви повинні побачити після централізації вашого меню?

Вигода вимірюється протягом тижнів, а не кварталів, якщо ви відстежуєте правильні показники. Дані з випадків постачальників показують, що централізація може скоротити зусилля з управління меню до 90% для деяких операторів, перетворюючи те, що раніше було циклом оновлення на кілька днів по магазинах, на одне післяобіднє оновлення.

Показник, який має найбільше значення: відстежуйте точність замовлень на доставку та рівень замовлень, що не в наявності, окремо від цифр для їдальні. Замовлення на винос тепер складають майже 75% трафіку ресторанів у багатьох брендів, тому розрив синхронізації меню, який впливає лише на доставку, все ще вплине на більшість вашого обсягу.

Окрім економії часу, щомісяця звертайте увагу на чотири показники:

• Час на публікацію обмеженої пропозиції на кожному каналі, від рішення до живого меню.
• Частота повернень, пов'язана з помилками в меню (неправильна ціна, товар, що закінчився, але все ще доступний для замовлення, відсутній модифікатор).
• Консистентність між каналами, що означає, як часто один і той же товар показує одну й ту ж ціну та опис скрізь, де його продають.
• Обсяг скарг від гостей конкретно щодо неправильних замовлень, який повинен знижуватися протягом одного повного розрахункового циклу централізації.

Якщо ці показники не покращуються протягом 60 днів після централізації, система налаштована неправильно або в робочому процесі управління є прогалини.

Які помилки роблять оператори з кількома локаціями?

Найпоширеніша помилка не є програмним розривом. Це сприйняття "централізованого" як синоніма "заблокованого", що породжує обхідні рішення, які знищують весь сенс.

• Надмірне обмеження місцевої гнучкості. Якщо менеджери магазинів не можуть налаштуватися на місцеві проблеми з постачанням або регіональне ціноутворення, вони знайдуть ручні обхідні шляхи поза системою, відтворюючи фрагментацію, яку ви намагалися виправити.
• Дозволяючи майстру товарів ставати безладним. Дублікати товарів з трохи різними назвами ("Чізбургер" проти "Класичного чізбургера") швидко множаться, якщо ніхто не відповідає за чистоту даних, а очищення стає експоненційно складнішим, чим довше ви чекаєте.
• Пропуск тестів інтеграції від початку до кінця. Кожен партнер з доставки та постачальник POS має свої особливості; документація платформи щодо версій меню та обмежень UI чітко вказує, що припущення, що кожна система успадковує зміни однаково, є помилкою, яку варто уникати до запуску, а не після.
• Недостатнє навчання щодо прав доступу. Випадкове публікування від когось, хто не повинен мати доступ, є найпоширенішою причиною помилки в ціноутворенні по всій мережі.

Порада: *Проводьте щоквартальний аудит того, хто має права на публікацію у вашій системі меню. Зміна персоналу означає, що списки доступу швидко застарівають, а колишній менеджер з залишковими адміністративними правами є ризиком, який ніхто не помічає, поки щось не зламається.*

*— АДМІН*

Як RESTOBOT керує централізованим контролем меню

RESTOBOT будує свою систему меню навколо одного майстра товарів, який постачає ваше замовлення на вебсайті, бота Telegram і підключені кіоски з однієї точки редагування, тому зміна ціни або новий товар з'являється скрізь одночасно, а не чекає окремих оновлень для кожного каналу. Рольові права доступу в панелі управління означають, що менеджер локації може позначити товар як відсутній на складі, не торкаючись базової ціни, тоді як контроль затвердження для більших змін залишається за тим, хто керує обліковим записом у головному офісі.

Оскільки створення вебсайту на деяких платформах відбувається автоматично після підтвердження заявки, нова локація може бути активною зі своєю власною брендовою сторінкою замовлення, вбудованим меню та налаштуванням резервування за дуже короткий час, а не чекаючи в черзі на розробку. Ця швидкість має значення, коли ви підключаєте п'яту або п'ятдесят локацію і не можете дозволити собі багатотижневий цикл налаштування для кожного магазину.

Деякі платформи пропонують модель замовлення без комісії, яка усуває приховану вартість, до якої більшість централізованих систем не доторкаються: ви не платите відсоток з кожного замовлення лише для того, щоб підтримувати синхронізацію меню між каналами, що змінює математику при додаванні доставки без втрати маржі на обсязі. Для частин дня, цінових надбавок за групами локацій та екстреного видалення товарів через кожен підключений канал, та сама панель, що керує вашим меню, забезпечує видимість замовлень у реальному часі, тому погане оновлення виявляється в момент, коли замовлення починають виглядати неправильно, а не наступного ранку.

Готові централізувати своє меню?

Якщо ви зараз керуєте одним і тим же меню в трьох, десяти або п'ятдесяти локаціях вручну, рішенням не є більше електронних таблиць. Це одна панель управління, де одне редагування досягає вашого веб-сайту, вашого бота для замовлень у Telegram та ваших кіосків в момент публікації, без комісії за кожне замовлення, що з'їдає маржу, яку ви тільки що намагалися захистити. Деякі платформи надають операторам з кількома локаціями єдиний майстер-елемент разом з доступом на основі ролей, щоб менеджер зміни міг позначити проданий товар, в той час як зміни цін залишаються заблокованими для того, хто володіє обліковим записом.

Налаштування на деяких платформах не вимагає черги розробки. Підтверджена заявка може призвести до створення живого, брендингового сайту для замовлень протягом короткого часу, що дозволяє новим локаціям швидко почати приймати замовлення на централізованому меню. Якщо ваш поточний процес меню залежить від того, щоб хтось пам'ятав оновити шість різних систем щоразу, коли змінюється ціна, почніть налаштування RESTOBOT і подивіться, як насправді виглядає один майстер-елемент, що постачає кожен канал.

Джерела

Для технічних деталей щодо поширення меню читайте власну документацію Toast про версії меню для кількох локацій та покроковий посібник з налаштування меню Square, обидва з яких охоплюють специфічні особливості платформи, які варто знати перед міграцією. Щоб дізнатися, як синхронізація меню пов'язана з логістикою кур'єрських і доставочних послуг, дивіться це роз'яснення програмного забезпечення для управління доставкою, створеного для ресторанів з кількома локаціями.

• Менеджер меню та ресторани з кількома локаціями — Документація Toast

Питання та відповіді

Що таке правило 30/30/30 для ресторанів?

Правило 30/30/30 зазвичай стосується підтримки витрат на їжу, витрат на працю та накладних витрат на рівні близько 30% від доходу, залишаючи приблизно 10% як маржу. Це орієнтир для бюджету, а не правило управління меню, хоча централізована система меню допомагає захистити відсотки витрат на їжу, підтримуючи ціни та порції на одному рівні в кожній локації.

Яке найкраще програмне забезпечення для управління меню ресторанів у кількох локаціях?

Найкращий варіант залежить від кількості каналів, які ви використовуєте, але найсильніші варіанти мають однакові характеристики: єдиний майстер-елемент, переваги на рівні локацій та синхронізацію в реальному часі з POS та додатками для доставки. Платформи, такі як RESTOBOT, поєднують цей централізований контроль меню з безкомісійним замовленням, що важливо, якщо доставка становить велику частку вашого обсягу.

Яку POS-систему використовує Chick-fil-A?

Конкретного постачальника POS для Chick-fil-A не розкривають публічно в деталях, і він варіюється в залежності від покоління системи в мережі франшиз. Відомо, що великі мережі, такі як ця, покладаються на централізовану архітектуру меню, щоб підтримувати тисячі локацій синхронізованими в цінах та акціях.

Як називається, коли ресторан має кілька локацій?

Ресторан, що працює більше ніж на одному майданчику під одним брендом, зазвичай називається багатопунктовою або багатомісною операцією, а більші версії часто називають мережами або групами ресторанів. Операційна дисципліна, необхідна для їх стабільного управління, зазвичай описується як управління багатопунктовими операціями або стратегія ресторанів з багатьма локаціями.

Як часто слід синхронізувати оновлення меню між каналами?

Синхронізація в реальному часі або майже в реальному часі, що означає, що зміни з'являються на POS, кіосках та платформах доставки протягом кількох хвилин, є стандартом, якого слід дотримуватися постачальникам. Усе, що повільніше за це, створює можливість, коли гості можуть замовити товари за неправильною ціною або замовити щось, що вже розпродано.

Рекомендовано

• 90-денний контрольний список і шаблони для onboarding ресторанів для менеджерів
• Налаштування QR для замовлення за столом: посібник для менеджера ресторану