Чесно про HoReCa: де ми сильні, а де ні
Почнемо з межі, яку ми проводимо ще на першій зустрічі. Операційний облік закладу — каса, кухня, столи, чеки — це робота для спеціалізованого POS на кшталт Poster чи iiko, і це не наш профіль. Ми не вдаємо, що зробимо це на високому рівні, бо братися за чуже — найшвидший спосіб зіпсувати проєкт. Тому в HoReCa ми працюємо там, де справді сильні: з постачальниками, що возять у заклади, і з мережами, яким потрібен relationship-облік контрагентів, замовлень і комунікацій поверх операційної системи. CRM тут стоїть поряд із POS, а не замість нього.
Для постачальника в HoReCa-канал усе тримається на польових продажах. Торгпреди їздять по закладах, ведуть візити й повторні замовлення — і саме тут Uspacy дає максимум: трекінг виїздів (чекін, фото, GPS), історію по кожному закладу й дашборди по представниках. Керівник бачить маршрути й конверсію, а не покладається на усні звіти. Замовлення від закладів зводимо в одну воронку з обовʼязковими полями закладу й каналу, а телефонію підключаємо через Ringostat — вхідний дзвінок одразу відкриває картку закладу. Якщо ж ядро бізнесу — це обробка замовлень із каталогом і складом, ми беремо KeyCRM замість Uspacy: модель «замовлення» лягає на постачання точніше за модель «угода». По суті, HoReCa-постачання — це окремий зріз нашої найсильнішої вертикалі, B2B-дистрибуції, тож тут працює той самий перевірений інструментарій.
Для мережі закладів ми закриваємо мережевий шар: єдина картка по кожній локації, історія замовлень і комунікацій, спільні дашборди — але на рівні відносин і постачання, не операційки. Якщо локації працюють на різних касових системах, CRM стає спільним шаром аналітики над ними, звʼязаним за потреби через API. Це чесна, вузька, але реальна користь — і саме її ми обіцяємо, замість того щоб продавати «CRM для ресторану», яка насправді має бути POS. Якщо на ознайомчій консультації виявиться, що вам потрібен саме операційний облік, ми так і скажемо — і, можливо, порекомендуємо колег, а не візьмемо проєкт, який не зробимо добре.