Olimp POS — единая система для кассы, бронирования, клиентов и операционного контроля бильярдного клуба

Growth Insider спроектировал и разработал специализированную POS-систему для бильярдного клуба, где касса, игровые сессии, бронирования, товары, клиенты, история расчётов и аналитика работают в одном закрытом интерфейсе.

Olimp POS был создан для бизнеса, которому не подходил набор разрозненных инструментов: отдельная касса, отдельная таблица бронирований, отдельные записи клиентов, ручной подсчёт выручки и отсутствие единой картины по столам.

Проект объединил ежедневную работу кассира, административное управление и владельческую аналитику в одну систему. Кассир получил быстрый интерфейс для обслуживания гостей. Администратор — отдельную панель управления столами, товарами, бронированиями и отчётами. Владелец — прозрачность по выручке, играм, оплатам, клиентам и загрузке клуба.

Executive summary

Olimp POS — это специализированная внутренняя система для бильярдного клуба, которая объединила несколько критичных процессов в одном интерфейсе:

• управление столами;
• запуск и завершение игровых сессий;
• расчёт стоимости игры;
• продажа товаров;
• разные способы оплаты;
• скидки;
• история расчётов;
• бронирования;
• CRM клиентов;
• аналитика;
• экспорт данных;
• отдельная панель кассира;
• отдельная панель администратора;
• публичное окно онлайн-бронирования в подтверждённом варианте внедрения.

До проекта такие процессы обычно ведутся через кассовую программу, Excel, бумажные записи, мессенджеры, календарь и память сотрудников. Это создаёт операционный хаос: сложно видеть занятость столов, историю оплат, повторных клиентов, неоплаченные чеки, загрузку клуба и реальную выручку.

Growth Insider спроектировал Olimp POS как систему ежедневной работы: кассир открывает панель, видит столы, запускает игру, добавляет товары, завершает сессию, выбирает оплату и сохраняет расчёт. Администратор управляет столами, тарифами, товарами, календарём, CRM и аналитикой. Владелец получает данные по выручке, количеству игр, среднему чеку, неоплаченным расчётам и активности клиентов.

Бизнес-контекст

Бильярдный клуб — это не просто “место, где стоят столы”. Это операционный бизнес с высокой частотой событий.

Каждый день команда управляет несколькими потоками одновременно:

• гости приходят без брони;
• гости бронируют столы заранее;
• кассир запускает и завершает игровые сессии;
• часть клиентов покупает напитки или товары;
• часть клиентов оплачивает наличными;
• часть — картой;
• часть расчётов требует скидки;
• часть игр нужно добавить исторически;
• администратор меняет тарифы и список столов;
• владелец хочет видеть выручку, загрузку и средний чек.

Если эти процессы не связаны между собой, бизнес теряет прозрачность.

Типичная ситуация до такой системы выглядела так: столы отмечались отдельно, брони хранились в календаре или заметках, клиенты фиксировались вручную, товары продавались отдельно, а выручка сводилась в конце дня. При таком подходе клуб зависел от внимательности кассира и ручной дисциплины.

Olimp POS был создан, чтобы убрать эту зависимость и собрать рабочую операционную логику клуба в одном инструменте.

Главная бизнес-проблема

Проблема была не в том, что у клуба “не было кассы”.

Проблема была в том, что касса, бронирование, столы, клиенты, товары и аналитика жили как отдельные процессы.

Из-за этого появлялись типичные риски:

• сотрудник не всегда видел актуальную занятость столов;
• бронирование не было связано с клиентом и историей посещений;
• продажа товаров не всегда попадала в общую картину по сессии;
• история расчётов требовала ручной проверки;
• скидки и способы оплаты было сложнее контролировать;
• неоплаченные чеки терялись среди обычных операций;
• владелец видел выручку только постфактум;
• повторные клиенты не превращались в управляемую CRM-базу;
• администратор не имел отдельного контура управления;
• каждый новый сотрудник должен был разбираться в нескольких инструментах.

Для бизнеса с почасовой оплатой, товарами, бронированиями и повторными клиентами это создаёт не просто неудобство. Это влияет на деньги, скорость обслуживания и управляемость.

Почему стандартные решения не закрывали задачу

Готовые кассовые решения обычно хорошо закрывают продажу товара или базовый чек. Но в бильярдном клубе этого недостаточно.

Здесь нужно учитывать не только товар, но и время игры, занятость стола, тариф, день недели, оплату, скидки, бронирования, клиента и историю. POS-система должна понимать, что “стол” — это не товар, а ресурс, который занят во времени.

Обычная CRM тоже не решала задачу. CRM помогает хранить клиентов, но не запускает игровую сессию, не считает стоимость минуты, не связывает продажу товара со столом и не показывает кассиру текущую занятость зала.

Обычный календарь тоже не решал задачу. Календарь показывает брони, но не управляет оплатами, товарами, клиентской базой, тарифами и аналитикой.

Поэтому клиенту нужна была не одна “программа для кассы”, а custom business system под специфику клуба.

Главная задача проекта

Growth Insider должен был создать систему, которая закрывала полный цикл ежедневной работы бильярдного клуба.

Система должна была:

1. Показать кассиру актуальную сетку столов.
2. Разделить свободные и занятые столы.
3. Позволить быстро начать игру.
4. Позволить указать время старта вручную.
5. Позволить добавить историческую игру.
6. Рассчитать стоимость игры.
7. Добавить товары к сессии или продать товар отдельно.
8. Применить скидку.
9. Выбрать способ оплаты.
10. Сохранить расчёт в историю.
11. Связать сессию с клиентом.
12. Вести CRM клиентов.
13. Управлять бронированиями в календаре.
14. Управлять столами и тарифами.
15. Управлять товарами и ценами.
16. Показывать аналитику по выручке, играм и среднему чеку.
17. Дать экспорт данных.
18. Разделить доступ кассира и администратора.
19. Подготовить интерфейс под реальную работу персонала, а не под техническую демонстрацию.

Подход Growth Insider

Мы начали проект не с дизайна экранов, а с карты операций клуба.

Для таких систем важно понять, что происходит в реальном рабочем дне:

• что делает кассир, когда клиент пришёл без брони;
• что делает кассир, когда клиент уже забронировал стол;
• как начинается игра;
• как считается стоимость;
• как добавляются товары;
• что происходит при оплате;
• что делать, если клиент платит позже;
• как найти старый расчёт;
• как добавить клиента;
• как увидеть историю клиента;
• как администратор меняет тариф;
• как владелец проверяет выручку.

Эта логика стала основой системы.

Olimp POS был спроектирован как два рабочих контура:

1. Контур кассира

Кассир работает с текущим днём: столы, игры, товары, клиенты, бронирования, расчёты.

Ему не нужны сложные настройки. Ему нужен быстрый интерфейс, который помогает обслуживать гостя без лишних действий.

2. Контур администратора

Администратор управляет системой: столы, тарифы, товары, бронирования, CRM, история, аналитика.

Ему нужен более широкий доступ: не только провести расчёт, но и изменить структуру клуба, посмотреть отчёты, выгрузить данные и контролировать работу.

Разделение этих контуров стало важной частью архитектуры. В системе подтверждены отдельные страницы /pos для кассира и /pos-admin для администратора, а также проверка прав pos_cashier, pos_admin и manage_options.

Что было реализовано

В рамках проекта была реализована единая система Olimp POS с несколькими связанными модулями.

1. Панель кассира

Панель кассира стала основным рабочим местом персонала.

В ней были разделы:

• Касса / Бильярд и товары;
• История расчётов;
• Бронирования / Календарь;
• Клиенты / CRM.

Эта структура подтверждена в шаблоне панели кассира: интерфейс содержит навигацию по кассе, истории расчётов, календарю и CRM клиентов.

На скриншотах видно, что кассир сразу видит сетку столов, статус каждого стола и правую рабочую панель для действий. Свободные столы отмечены статусом “Свободен”. После выбора стола кассир начинает сессию или завершает игру.

Панель была сделана не как общий административный экран, а как профильный интерфейс для быстрых операций в зале.

2. Панель администратора

Панель администратора стала отдельным управленческим контуром.

В ней были разделы:

• Дашборд аналитики;
• История расчётов;
• Столы;
• Товары;
• Бронирования;
• Клиенты.

Эта структура подтверждена в коде панели администратора: навигация включает dashboard, history, tables, products, calendar и CRM.

Администратор получил доступ к настройке элементов, которые кассир не должен менять каждый день: столы, тарифы, товары, отчёты, календарь, клиентская база.

3. Управление столами

Для клуба была реализована логика столов как ключевых ресурсов бизнеса.

В системе были столы, типы столов, тарифы и ставки. На скриншотах видно управление столами: администратор добавляет или изменяет стол, указывает название, тип, тариф в будни, тариф в выходные и тип расчёта. В списке столов отображаются ID, название, тип и тарифы.

Это было важно, потому что бильярдный стол в такой системе — не просто объект в списке. Это ресурс, который имеет статус, тариф, историю игр, бронирования и связь с выручкой.

В рабочем режиме кассир видел карточки столов и их статусы. Система возвращала по каждому столу status, session_id, время старта, тип тарифа, будний и выходной тариф, а также сумму товаров в текущей сессии.

4. Игровые сессии

Модуль игровых сессий отвечал за запуск, ведение и завершение игры.

Система учитывала:

• выбранный стол;
• старт игры;
• ручное указание времени старта;
• активную сессию;
• длительность игры;
• стоимость бильярда;
• товары в рамках сессии;
• итоговую сумму;
• способ оплаты;
• скидку;
• комментарий;
• клиента;
• исторические игры.

На скриншотах видно, что в кассовой панели есть быстрые действия: “Товар отдельно”, “Указать время старта”, “Историческая игра”. Эти действия важны для реальной работы клуба, потому что не все операции происходят идеально “сейчас и сразу”. Иногда игру нужно внести задним числом, иногда товар продаётся без игровой сессии, иногда старт нужно указать вручную.

В коде также подтверждены use cases для завершения сессии, добавления исторической сессии, продажи товаров, обновления и удаления расчётов.

5. Продажа товаров

Olimp POS включал управление товарами и продажами.

Администратор управлял каталогом товаров: название, категория, цена. На скриншотах видно раздел “Управление товарами”, форму добавления товара и список товаров.

Для кассира товары были частью ежедневного процесса. Товар можно было добавить к игровой сессии или продать отдельно.

Система работала с таблицами товаров и товаров внутри сессии, а модуль Products был связан с Sessions и Analytics. Это подтверждено в карте модулей: Products отвечал за каталог товаров, цены, продажу товаров и связь с аналитикой.

6. Расчёты и история операций

История расчётов стала отдельным модулем контроля.

На скриншотах видно, что в истории были фильтры:

• дата от;
• дата до;
• оплата;
• тип;
• стол;
• количество записей на странице;
• поиск по ID, клиенту, телефону, e-mail и комментарию.

В таблице отображались записи с детализацией: игра, товары, скидка, итог, способ оплаты, статус оплаты.

Это важно для владельца и администратора. История расчётов превращает кассовые операции в проверяемый журнал, где можно найти конкретный чек, клиента, стол, период, оплату или спорную операцию.

В коде подтверждена работа history-фильтров по дате, оплате, типу, столу, поиску и количеству записей, а также загрузка списка истории.

7. Оплаты и скидки

Система поддерживала разные сценарии оплаты и скидок.

На скриншотах истории видно оплату “Карта” и “Наличные”, а в коде подтверждены варианты оплаты cash, card, blik и unpaid.

Для бизнеса это важно, потому что не каждый чек одинаковый. У клуба есть разные способы оплаты, скидки, неоплаченные расчёты и товары. Если эти элементы не фиксируются структурированно, владелец не видит реальную картину.

Olimp POS связал оплату, скидку, товары, игровое время и итоговую сумму в одном расчёте.

8. Бронирования

Модуль бронирования был одним из ключевых элементов системы.

На скриншотах видно календарь с выбором стола, переключением режимов “День”, “Неделя”, “Месяц”, “Все столы”, навигацией по датам, кнопкой “Сегодня”, кнопкой “Добавить бронь” и возможностью скопировать ссылку.

Это показывает, что бронирование было реализовано не как простая форма, а как отдельный рабочий календарь для операционного планирования.

Система также проверяла занятые слоты по столу и дате. В коде подтверждён use case Get Taken Slots, который возвращал занятые интервалы для выбранного стола и дня.

В подтверждённом варианте внедрения также был публичный модуль онлайн-бронирования. Это важно: клиент мог отправить ссылку или принимать бронирования через внешний интерфейс, а команда видела их внутри системы. В коде есть Public Booking use case и связь Public Booking с Reservations, CRM и Tables.

9. CRM клиентов

Olimp POS включал CRM-модуль для клиентов.

На скриншоте видно CRM клиентов с поиском, кнопкой “Добавить клиента” и таблицей, где отображаются:

• имя;
• телефон;
• e-mail;
• время игры;
• сумма по бильярду;
• сумма по товарам;
• общий итог;
• комментарий.

Это важно, потому что в локальном клубе повторные клиенты — часть выручки. Если клиентская база не связана с играми, бронированиями и оплатами, бизнес теряет возможность видеть ценность клиента.

CRM в Olimp POS была связана с Sessions, Settlements и Reservations. Карта модулей подтверждает, что CRM работала с wp_pos_customers и wp_pos_sessions, поддерживала получение клиентов, поиск клиентов и агрегаты.

Также в коде подтверждён поиск клиентов с ограничением результатов и проверкой минимальной длины запроса.

10. Аналитика

Для владельца и администратора был реализован дашборд аналитики.

На скриншоте видно показатели:

• выручка за бильярд;
• выручка за товары;
• выручка всего;
• количество игр;
• оплаченные чеки;
• неоплаченные;
• средний чек;
• заметки по дням;
• топ столов;
• топ клиентов.

Также есть выбор периода, фильтр оплаты, кнопка “Применить” и скачивание CSV.

В коде подтверждён yearly report с месяцами, клиентами, временем игры, бильярдом, товарами, итогом и средним чеком.

Это критично для бизнеса: владелец перестаёт смотреть только “сколько денег в кассе сегодня” и начинает видеть структуру выручки — что приносит деньги, какие столы работают, сколько продаётся товаров, какой средний чек и где есть неоплаченные операции.

11. Экспорт данных

Система включала экспорт данных.

Экспорт был важен для владельца и администратора, потому что данные из POS должны быть доступны для дальнейшего анализа, сверки, бухгалтерии или внутреннего контроля.

В документации модулей Analytics подтверждён CSV Export, а в коде присутствует генерация CSV по аналитике с данными сессий, оплат, длительности, сумм, скидок, столов, клиентов и товаров.

12. Роли и маршруты

Olimp POS был построен с разделением ролей.

Кассир работал в одном интерфейсе, администратор — в другом. Доступ к POS-страницам был закрыт для гостей. Для /pos-admin требовалась роль POS Admin или WP Admin. Для /pos допускались POS Cashier, POS Admin или WP Admin.

Это защищало систему от хаоса в правах доступа. Кассиру не нужно видеть настройки тарифов и административные отчёты. Администратору нужен полный контур управления. Владелец получает контроль без смешивания ролей.

Как система работала в ежедневной операции

Сценарий 1. Клиент пришёл играть без брони

Кассир открывал панель Olimp POS и видел сетку столов.

Свободные столы были отмечены статусом “Свободен”. Кассир выбирал нужный стол, запускал игровую сессию и система начинала учитывать время. Если клиент был уже в CRM, его можно было найти и привязать к игре. Если клиента не было, его данные можно было добавить в процессе обслуживания.

Когда игра завершалась, система рассчитывала стоимость бильярда, добавленные товары, скидку и итоговую сумму. Кассир выбирал способ оплаты и сохранял расчёт.

В результате операция попадала в историю, CRM и аналитику.

Сценарий 2. Клиент купил товар без игры

Не каждая продажа в клубе связана с бильярдной сессией. Поэтому в кассе было отдельное действие “Товар отдельно”.

Кассир мог провести продажу товара без запуска игрового времени. Это важно для реального клуба, где гости покупают напитки, снеки или другие позиции независимо от игры.

Такая продажа попадала в историю и аналитику товаров, а владелец видел товарную выручку отдельно от выручки за бильярд.

Сценарий 3. Нужно указать время старта вручную

В реальной работе кассир не всегда запускает сессию в идеальный момент. Клиент мог начать играть раньше, сотрудник мог быть занят, или операция могла быть внесена с задержкой.

Поэтому система включала действие “Указать время старта”.

Это помогло сохранить корректность расчёта и не заставляло персонал обходить систему вручную.

Сценарий 4. Нужно добавить историческую игру

В системе был сценарий “Историческая игра”.

Он закрывал случаи, когда операция должна быть добавлена постфактум: например, игра уже прошла, но её нужно корректно внести в историю, аналитику и расчёты.

Это особенно важно для точности отчётности: вместо того чтобы держать такие случаи в заметках, администратор или кассир фиксировал их в системе.

Сценарий 5. Клиент забронировал стол

Кассир или администратор открывал календарь, выбирал стол, день, неделю, месяц или режим “Все столы”. Затем добавлял бронь.

Система учитывала занятые слоты и давала команде рабочую сетку бронирований. В подтверждённом варианте внедрения был также публичный модуль онлайн-бронирования, связанный с внутренним календарём.

Это снижало риск двойных броней и помогало команде заранее понимать загрузку клуба.

Сценарий 6. Администратор проверил историю расчётов

Администратор открывал историю расчётов, выбирал период, тип, способ оплаты, стол и при необходимости использовал поиск.

Так он находил конкретную операцию, проверял оплату, скидку, итоговую сумму или клиента.

Это давало клубу прозрачность, которой нет в бумажных записях и отдельных таблицах.

Сценарий 7. Владелец проверил аналитику

Владелец или управляющий открывал дашборд аналитики и видел данные за выбранный период:

• сколько выручки пришло от бильярда;
• сколько от товаров;
• сколько всего;
• сколько было игр;
• сколько чеков оплачено;
• сколько неоплачено;
• какой средний чек;
• какие столы и клиенты были наиболее значимыми.

Так система стала не только кассой, но и инструментом управленческого контроля.

Что получил бизнес

1. Единый рабочий контур вместо разрозненных инструментов

Клуб получил одну систему, где касса, столы, бронирования, клиенты, товары, расчёты и аналитика работали вместе.

Это сократило количество ручных операций и снизило зависимость от памяти сотрудников.

2. Быструю работу кассира

Кассир получил интерфейс, построенный вокруг ежедневной работы: выбрать стол, начать игру, добавить товар, завершить расчёт, выбрать оплату, найти клиента, открыть календарь.

Это уменьшило количество лишних действий во время обслуживания клиента.

3. Управляемые бронирования

Бронирования перестали быть отдельной таблицей или записью в мессенджере. Они стали частью системы, связанной со столами, временем и клиентами.

4. Контроль продаж товаров

Товары стали частью POS-логики. Продажи товаров попадали в историю и аналитику, а не жили отдельно от основной выручки клуба.

5. CRM клиентов

Клиентская база стала связана с играми, бронированиями и денежной историей. Это дало основу для лучшего сервиса, повторных визитов и понимания клиентской ценности.

6. Историю расчётов

Каждая операция фиксировалась в истории. Администратор мог фильтровать расчёты, искать по клиенту, телефону, e-mail, комментарию, столу, типу и оплате.

7. Аналитику для владельца

Владелец получил не только список чеков, а управленческую картину: выручка, средний чек, игры, товары, оплаченные и неоплаченные чеки.

8. Разделение ролей

Кассир и администратор получили разные интерфейсы. Это повысило безопасность и упростило ежедневную работу.

9. Экспорт данных

Данные можно было выгружать для анализа, сверки и отчётности.

10. Систему под специфику клуба

Olimp POS был сделан под реальный процесс бильярдного клуба, а не под абстрактную торговую точку.

Почему это не обычная POS-система

Olimp POS нельзя оценивать как “кассу для продажи товаров”.

Это custom business system для клуба, где деньги появляются из нескольких операционных источников:

• игровое время;
• товары;
• бронирования;
• повторные клиенты;
• скидки;
• разные способы оплаты;
• исторические операции;
• неоплаченные расчёты.

Обычная POS-система фиксирует продажу. Olimp POS управлял процессом: от занятости стола до аналитики владельца.

Система учитывала не только “что продали”, но и:

• кто играл;
• за каким столом;
• сколько времени;
• какие товары были добавлены;
• какая скидка применена;
• чем оплатили;
• была ли операция оплачена;
• как это повлияло на аналитику;
• как это связано с клиентом;
• как это связано с бронированием.

Это делает проект не просто кассовым интерфейсом, а операционной системой клуба.

Почему это проект уровня custom business system

Olimp POS объединил несколько уровней сложности.

Бизнес-уровень

Система была спроектирована под конкретный тип бизнеса: бильярдный клуб с почасовой оплатой, товарами, бронированиями, клиентами и повторными визитами.

Операционный уровень

Система закрыла ежедневную работу персонала: запуск игры, завершение, товары, оплаты, скидки, история, брони, клиенты.

Управленческий уровень

Администратор получил отдельный интерфейс управления столами, тарифами, товарами, CRM, календарём и историей.

Аналитический уровень

Владелец получил дашборд, показатели, годовой отчёт и экспорт данных.

Технический уровень

Система включала роли, маршруты, модули, репозитории, use cases, служебные таблицы и бизнес-правила.

UX-уровень

Интерфейс был сделан под реальную работу: тёмная панель, крупные действия, понятные статусы столов, быстрые сценарии кассира, отдельный административный контур.

Подробно по модулям

Sessions — игры и продажи

Модуль Sessions управлял жизненным циклом игр и продаж.

Он отвечал за:

• запуск игры;
• завершение игры;
• расчёт суммы;
• добавление исторической игры;
• продажу товаров в рамках сессии;
• продажу товаров отдельным чеком;
• передачу данных в аналитику;
• обновление клиентских агрегатов;
• формирование строк для истории расчётов.

В карте модулей Sessions связан с wp_pos_sessions, wp_pos_session_products, wp_pos_tables и wp_pos_customers.

Settlements / History — история расчётов

Этот модуль отвечал за историю операций.

Он позволял видеть, фильтровать, редактировать и контролировать расчёты.

История была важна для сверки смен, поиска ошибок, проверки оплат и управленческого контроля.

Reservations — бронирования

Reservations отвечал за внутренние бронирования, календарь и работу со слотами.

Он был связан со столами, клиентами и публичным бронированием.

Благодаря этому бронирования не жили отдельно от POS, а были встроены в операционную систему клуба.

CRM — клиентская база

CRM отвечал за клиентов, поиск клиентов и агрегаты.

Система связывала клиентов с играми, расчётами и бронированиями. Это позволяло видеть не только контакт, но и поведение клиента: сколько он играл, сколько потратил, какие товары покупал, когда приходил.

Analytics — аналитика и экспорт

Analytics собирал данные из сессий, столов, клиентов, товаров и продаж.

Он давал сводку, годовой отчёт и CSV-экспорт. Это превращало операционные данные в управленческую информацию.

Products — товары

Products отвечал за каталог товаров, цены и продажи.

Товары были связаны с сессиями и аналитикой, поэтому владелец видел отдельно выручку за бильярд и за товары.

Tables — столы и тарифы

Tables отвечал за каталог столов, тарифы и связь с игровыми сессиями и бронированиями.

Это был центральный модуль для бизнеса, потому что стол — главный ресурс клуба.

Public Booking — публичное бронирование

Public Booking отвечал за внешнюю форму бронирования и проверку занятых слотов.

В подтверждённом варианте внедрения это позволило связать внешний запрос клиента с внутренней системой клуба.

Операционная ценность для клуба

До системы

Работа клуба была распределена между разными процессами:

• столы контролировались отдельно;
• брони фиксировались отдельно;
• клиенты не всегда связывались с историей посещений;
• товары не всегда попадали в общую аналитику;
• расчёты требовали ручной проверки;
• владелец видел не процесс, а только результат;
• новые сотрудники зависели от объяснений и привычек команды.

После системы

Olimp POS собрал эти процессы в один интерфейс:

• столы получили статусы;
• игры стали сессиями;
• товары стали частью расчёта;
• клиенты стали частью CRM;
• брони вошли в календарь;
• расчёты попали в историю;
• данные попали в аналитику;
• администратор получил управление;
• владелец получил контроль.

Почему это важно для владельца

Для владельца бильярдного клуба главная ценность не в том, что “есть программа”.

Главная ценность — в управляемости.

Olimp POS дал владельцу ответы на вопросы:

• какая выручка за период;
• сколько принес бильярд;
• сколько принесли товары;
• сколько было игр;
• сколько чеков оплачено;
• есть ли неоплаченные операции;
• какой средний чек;
• какие столы работают лучше;
• какие клиенты приносят больше;
• какие операции были в конкретную дату;
• кто был привязан к конкретной игре;
• какие бронирования есть впереди.

Такие данные помогают управлять бизнесом, а не просто обслуживать текущий поток гостей.

Почему это важно для персонала

Для кассира система упростила ежедневную работу.

Вместо нескольких инструментов кассир получил один рабочий экран:

• видит столы;
• выбирает стол;
• запускает игру;
• добавляет товары;
• ищет клиента;
• завершает расчёт;
• выбирает оплату;
• смотрит историю;
• открывает календарь;
• добавляет бронь.

Это снижает нагрузку на сотрудника и уменьшает количество ручных ошибок.

Почему это важно для администратора

Администратор получил контроль над структурой клуба:

• столы;
• тарифы;
• товары;
• цены;
• бронирования;
• клиенты;
• история;
• отчёты;
• экспорт.

Это значит, что бизнес не зависит от разработчика для каждой мелкой правки. Администратор управляет значительной частью операционной логики сам.

Результат проекта

Growth Insider разработал Olimp POS — специализированную систему для бильярдного клуба, которая объединила кассу, столы, игровые сессии, товары, бронирования, CRM, историю расчётов и аналитику.

Клиент получил:

• рабочее место кассира;
• отдельную панель администратора;
• управление столами и тарифами;
• управление товарами;
• запуск и завершение игровых сессий;
• продажу товаров отдельно и внутри сессии;
• разные способы оплаты;
• скидки;
• исторические игры;
• историю расчётов с фильтрами;
• календарь бронирований;
• CRM клиентов;
• аналитику по выручке и операциям;
• экспорт данных;
• разделение ролей;
• основу для публичного онлайн-бронирования.

Главный результат — клуб получил не просто кассовый интерфейс, а собственную операционную систему под специфику бизнеса.

Что этот кейс показывает о Growth Insider

Этот проект показывает, что Growth Insider умеет строить сложные внутренние системы для локального бизнеса.

Мы работаем не только со страницами, SEO и маркетингом. Мы проектируем системы, которые затрагивают операционную работу компании:

• касса;
• процессы;
• роли;
• данные;
• клиенты;
• бронирования;
• товары;
• история;
• аналитика;
• отчёты;
• ежедневные сценарии сотрудников.

Olimp POS показывает, что Growth Insider умеет переводить реальные процессы бизнеса в понятный цифровой продукт.

Не “нарисовать интерфейс”, а спроектировать рабочую систему, которой пользуются сотрудники.

Почему это сильный пример custom business system

Olimp POS — это хороший пример проекта, где готовое решение было неудобно, потому что бизнес работал по своей логике.

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

В этом кейсе были объединены:

• UX для кассира;
• административная панель;
• управление ресурсами;
• временная тарификация;
• товарные продажи;
• CRM;
• бронирования;
• история операций;
• отчёты;
• аналитика;
• права доступа;
• экспорт данных.

Такой проект относится к классу custom business system, потому что он автоматизирует не одну функцию, а целый операционный контур бизнеса.

Ключевой вывод

Olimp POS превратил работу бильярдного клуба из набора разрозненных действий в единую управляемую систему.

Кассир получил быстрый интерфейс для обслуживания гостей.
Администратор получил инструменты управления столами, товарами, бронированиями и клиентами.
Владелец получил прозрачность по выручке, играм, товарам, оплатам и клиентам.

Главная ценность проекта — не в том, что система “считает кассу”. Главная ценность в том, что она связывает операционную работу клуба с деньгами, клиентами и управленческими данными.