Управління мережею ресторанів: три заклади, один екран і спільні цифри для власника

Проблема починається при порівнянні, а не на кухні

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

Масштаб цього видно вже на рівні одного ресторану, перш ніж справа дійде до мережі. Серед 245 ресторанів і кейтерингових компаній у Варшаві, чиї сайти відкрилися і були автоматично проаналізовані, 112 не мають ні форми запиту, ні форми запису. Це 45,7% цієї групи. Запит від гостя тоді ніде не зберігається, тому немає з чим порівнювати між закладами.

Як цифри з закладу потрапляють на екран власника

Запит з телефону, з картки в Google, з Messenger або з WhatsApp потрапляє в одне місце, а не до блокнота одного керівника. Кожен заклад записує подію тим самим способом, тому керівник уже не вирішує сам, що вважається бронюванням. Адмін-панель показує всі три заклади поруч, на одному екрані, з тими самими колонками. Весь механізм базується на спільній CRM-системі для всіх закладів — без неї кожен заклад повертається до власного формату.

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

Хто це веде щодня: ролі, інструменти та відповідальність за цифри

Мережа потребує чіткого поділу, хто за що відповідає. Інакше екран з цифрами нікому не допоможе. Менеджер зали в кожному закладі відповідає за те, щоб один і той самий процес реєстрації подій працював однаково в кожному закладі. Шеф-кухар подає замовлення постачальнику через ту саму CRM, тому постачання трьох закладів видно поруч, а не в трьох окремих повідомленнях. Бухгалтер розраховує виручку дня на основі тих самих звітів, а не на основі того, що надішле йому керівник поштою. Власник дивиться на панель раз на день і приймає рішення на основі фактів, а не пам'яті одного з керівників.

На практиці ці потоки об'єднує автоматизація. n8n або Make отримує запит з картки Google Business Profile, з Messenger або з WhatsApp, і вносить його до CRM з міткою закладу. SMSAPI надсилає гостю підтвердження бронювання, а Google Calendar тримає терміни банкетних залів, щоб два заклади не забронювали ту саму залу на весілля в той самий день. Більше про цей механізм в одному закладі знайдете в окремому тексті про бронювання, постачальників та відгуки в одному ресторані. За об'єднання цих джерел відповідають інтеграції, які з'єднують касу, календар та месенджери.

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

Та сама проблема видна ще до того, як мережа почне розростатися. Серед 359 ресторанів і кейтерингових компаній у Варшаві, чиї сайти ми проаналізували автоматично, 66 відображаються виключно на чужій платформі. Це 18,4% цієї групи. Така платформа - це каталог, портал для бронювання або профіль у соцмережах. Такий заклад не має власного місця, де гість залишить запит, тому немає що вносити до спільної CRM мережі.

Скільки коштує спільний екран для кількох закладів: від чого залежить вартість

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

Інтеграція з e-mail відкриває перший канал, інтеграція з Telegram або WhatsApp - другий: кожен канал віддає дані по-своєму, тому кожен це інший шматок роботи. CRM-автоматизації об'єднують ці джерела в один потік, і лише тоді панель показує всю мережу, а не її шматок. Обсяг визначаємо після розмови про те, чим сьогодні користується ваша мережа.

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

Коли спільний екран для кількох закладів - погана ідея

Сенсу немає для одного закладу, який власник бачить щодня власними очима. Там проблема порівняння просто не існує, бо немає з чим порівнювати. Не варто також впроваджувати його в мережі, яка лише тестує другий заклад і за півроку може його закрити. Вартість підтримки інтеграції тоді перевищить вигоду від одного звіту. Іноді заклади мають абсолютно різні меню, різних гостей та різну бізнес-модель - один - це буфет для працівників, інший - ресторан à la carte. Тоді спільні цифри все одно нічого осмисленого не скажуть без окремого аналізу для кожного закладу.

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

Найчастіші запитання

Чи кожен заклад повинен мати окрему CRM, чи достатньо однієї спільної?

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

Що робити, якщо заклади мають різних власників, наприклад у моделі франшизи?

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

Скільки часу займає впровадження спільної панелі для двох або трьох закладів?

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

Чи потрібно міняти систему POS в кожному закладі, щоб це працювало?

Ні, інтеграція зазвичай з'єднується з тим, що вже стоїть на касі, замість її міняти. Винятком є каса, яка не має жодного API і фізично з неї нічого не витягти. Тоді потрібно окремо оцінити, чи заміна виправдається. Ми не обіцяємо, що кожну касу вдасться підключити без змін. Це залежить від конкретного виробника.

Давайте обговоримо один екран для вашої мережі ресторанів у Варшаві.