Открытый журнал команды. Пишем о продукте, операциях сервисных сетей, и о том, как пилот в SneakNFresh учит нас писать софт. Без маркетинговой воды — только то, что действительно произошло.
История молодого предпринимателя из Астаны, который открылся в 23 года по франшизе и через полгода понял главное: проблема сервисного бизнеса — не в одном инструменте, а в количестве инструментов. О том, почему системность побеждает суету.
Читать полностью →Сервисный бизнес — это люди, операции и клиенты. Три разных продукта — три разных слепых пятна. Я разбираю, почему в Кнопке мы строим один контур данных, а не три интегрированных модуля.
Notion, Google Docs, видео на YouTube, чаты в Telegram — типичная карта обучения сервисной сети. Разбираем, почему сети нужен один продукт вместо пяти и какие фичи делают LMS работающей: куратор, QR-сертификаты, чат внутри платформы.
Большинство партнёров уверены, что у них маржа 80%. По факту — 60–65%. Разбираем формулу полной себестоимости, показываем калькулятор в ERP Кнопка и обезличенный кейс сети из 5 точек.
Кэшбэк 5% — это не лояльность, это скидка. Настоящая лояльность начинается там, где система помнит клиента: его предпочтения, бренд обуви, аллергию на химию. Сегменты, реферальная цепочка, win-back — что должен уметь нормальный модуль лояльности и как он меняет поведение клиентов.
Мы только запустили пилот. Цифр пока нет — и мы не будем их выдумывать. Это статья про то, зачем мы строим Кнопку и какой видим путь впереди. План на лето 2026 и следующую волну партнёров.
Подписывайтесь — присылаем один большой пост по пятницам. Без рекламы, без воды, можно отписаться в любой момент.
Расскажем историю про одного партнёра. Он открылся в 23 года в Астане по франшизе сервисного бизнеса. Молодой, амбициозный, с горящими глазами — он сделал ровно то, что советует любая толковая франшиза. Подписал договор, оплатил паушальный взнос, прошёл обучение, получил мануалы, попал в чаты сети, открыл точку.
Первые три месяца всё работало как обещали. Поток клиентов был. Команду набрали. Управляющая компания поддерживала: вебинары, обновления стандартов, ответы в чатах, разбор кейсов. Партнёр был доволен — он купил систему, и система работала.
А потом — типичный сценарий. К шестому месяцу точка начала «жить своей жизнью». Не плохо, но и не так, как описано в мануале. И когда партнёр сел смотреть, где именно стандарт расходится с реальностью, он увидел картину, знакомую каждому, кто держит сервисный бизнес:
Партнёр сделал то, что делает любой системный человек, — пошёл искать решение. И нашёл его. На самом деле, нашёл сразу несколько решений. И вот здесь начинается главная история.
К концу первого года у партнёра был полный набор инструментов:
И только тогда партнёр понял главное. Проблема его бизнеса — не в одном инструменте. Проблема — в количестве инструментов. Каждый инструмент по отдельности неплохой. Но мастер на смене должен помнить, где что лежит. Администратор должен переключаться между пятью вкладками. Партнёр сам половину рабочего дня тратит на жонглирование сервисами вместо управления.
Сервисный бизнес умирает не от плохих инструментов. Он умирает от количества хороших инструментов, которые никто не успевает связать в единый контур.
Здесь важно сказать честно. Многие управляющие компании франшиз действительно пытаются помочь партнёрам. И делают это серьёзно. Они проводят регулярные вебинары. Выкатывают свежие статьи и разборы кейсов. Снимают хорошие обучающие курсы, нанимают тренеров, проводят оффлайн-встречи. Это огромная работа, и мы относимся к ней с большим уважением — это не формальность, это реальный труд.
Но есть один структурный момент. Вся эта работа происходит по отдельности. Курсы — на одной платформе. Чаты — в Telegram. Отчёты — в Google Sheets. Стандарты — в Notion или Confluence. Каждый партнёр получает кучу всего, но ничего не объединено. И чем больше УК даёт партнёру материалов, тем больше у партнёра становится вкладок, ссылок, паролей и контекстов, которые он должен держать в голове одновременно.
Это не вина УК. Это структура рынка: каждый SaaS делает свой кусок, и никто не делает всё вместе.
Мы понимаем, как важно бизнесу иметь один качественный продукт, а не десять разных. И мы строим именно его.
Кнопка объединяет три ключевых контура сервисного бизнеса в одном продукте:
Главное — это не три отдельных продукта с интеграциями. Это одна база данных и один интерфейс, в котором сотрудник, заказ и клиент связаны напрямую. Мастер прошёл курс — ERP открывает ему допуск к новой услуге. Клиент сделал заказ — CRM фиксирует визит, считает уровень лояльности, обновляет сегмент. Партнёр открывает дашборд — видит всё своё хозяйство сразу.
Партнёр не должен жонглировать инструментами. Он должен управлять своим бизнесом. Это разные глаголы и разные занятия.
Мы строим Кнопку для конкретного сегмента. Это сервисные сети от 3 до 50 точек: химчистки обуви и одежды, барбершопы, студии маникюра, автомойки, шиномонтажи, экспресс-кафе. Для этого сегмента enterprise-решения вроде SAP — слишком тяжелы и дороги, а пакет из десяти отдельных подписок — слишком много швов.
Кнопка занимает середину: цена, как у пары SaaS-подписок, функциональность, как у инфраструктуры взрослой сети. Это сегмент, который последние пять лет рос быстрее всех в сервисе — и в котором никто пока не сделал нормального единого продукта.
Рынок сервисных сетей в СНГ повзрослел. Партнёры перестали покупать франшизу как «готовый бизнес из коробки» — они покупают её как стартовую точку и дальше системно растут. Тем, кто растёт системно, нужны системные инструменты. И таких партнёров с каждым годом всё больше.
Мы строим Кнопку для тех, кто понимает простую вещь: системность побеждает суету. Не на отдельных героических усилиях, а в долгую — за счёт того, что у бизнеса есть нормальный единый контур, в котором не теряются данные, клиенты и время сотрудников.
Сейчас идёт первый пилот в реальной сервисной сети. В блоге мы открыто пишем, что строим, что меняем, что выкидываем. Если у вас сервисная сеть и вы узнали в этой истории себя — напишите. Берём не всех, но смотрим всех.
Here's a story about one partner. He opened a service-business franchise in Astana at the age of 23. Young, ambitious, eyes burning — he did exactly what any sensible franchise tells you to do. Signed the contract, paid the lump-sum fee, completed the training, got the manuals, joined the network chats, opened his location.
The first three months went as promised. Customer flow was there. The team was hired. The franchisor supported him: webinars, standard updates, replies in chats, case reviews. The partner was happy — he bought a system, and the system worked.
Then came the typical scenario. By month six the location started "living its own life." Not badly, but not the way the manual described it. And when the partner sat down to see exactly where the standard diverged from reality, he saw the picture that's familiar to anyone running a service business:
The partner did what any systematic person does — he went looking for a solution. And he found one. In fact, he found several at once. And this is where the main story begins.
By the end of his first year, the partner had a full stack of tools:
And only then did the partner understand the main thing. The problem with his business wasn't any single tool. The problem was the number of tools. Each tool, taken on its own, is decent. But the technician on shift has to remember where everything lives. The front desk has to juggle five tabs. The partner himself spends half his day juggling services instead of managing.
Service businesses don't die from bad tools. They die from the number of good tools that nobody manages to stitch into a single loop.
Let's be fair here. Many franchisors genuinely try to help their partners. And they do it seriously. They run regular webinars. Publish fresh articles and case studies. Shoot good training courses, hire trainers, hold offline meetups. It's huge work, and we have deep respect for it — it's not a formality, it's real labour.
But there's a structural issue. All of this work happens separately. Courses on one platform. Chats in Telegram. Reports in Google Sheets. Standards in Notion or Confluence. Each partner gets a pile of everything, and nothing is connected. The more the franchisor delivers, the more tabs, links, passwords and contexts the partner has to keep in their head at once.
It's not the franchisor's fault. It's the structure of the market: every SaaS does its own slice, nobody does the whole.
We understand how important it is for a business to have one solid product instead of ten different ones. And that's exactly what we're building.
Knopka brings the three core loops of a service business into one product:
The key thing: this isn't three separate products with integrations. It's one database and one interface, where employee, order and client are connected directly. A technician completes a course — ERP unlocks access to a new service. A client places an order — CRM logs the visit, recalculates the loyalty level, updates the segment. The partner opens the dashboard and sees the whole operation in one view.
A partner shouldn't juggle tools. They should run their business. Those are different verbs and different activities.
We're building Knopka for a specific segment. Service networks of 3 to 50 locations: shoe and clothing cleaning, barbershops, nail studios, car washes, tire shops, express cafes. For this segment, enterprise solutions like SAP are too heavy and too expensive, and a stack of ten separate subscriptions has too many seams.
Knopka sits in the middle: priced like a pair of SaaS subscriptions, capable like the infrastructure of a mature network. This is the segment that grew faster than any other in services over the past five years — and nobody has yet built a real unified product for it.
The service-network market in the CIS has grown up. Partners stopped buying franchises as "a business in a box" — they buy them as a starting point and then grow systematically from there. People who grow systematically need systematic tools. And there are more such partners every year.
We're building Knopka for those who get a simple thing: systems beat hustle. Not through heroic one-off efforts, but over the long run — because the business has one coherent loop where data, clients and team time don't go missing.
The first pilot is running in a real service network. In this blog we openly share what we're building, what we're changing, what we're throwing out. If you run a service network and you recognised yourself in this story — write to us. We don't take everyone, but we look at everyone.
Стандартный способ построить SaaS для сервисного бизнеса выглядит так: берёте одну боль, решаете её хорошо, продаёте подписку. Через пару лет добавляете интеграции с соседними системами через API, рисуете слайд про «экосистему» и идёте на следующий раунд.
Мы пошли по-другому. Мы строим три продукта одновременно — LMS, ERP и CRM — и они делят одну базу данных. Не «интегрированы», а живут вместе. Это решение, которое вызывает у инвесторов вопросы. Я в этой статье объясняю, почему это правильно именно для сервисного бизнеса.
Когда вы держите завод, у вас три отдельных мира. Производство — это станки и люди. Продажи — это менеджеры и клиенты. HR — это найм и обучение. Эти миры физически разделены: на станке клиент не появляется, в кабинете менеджера станок не стоит.
Сервисный бизнес устроен принципиально иначе. На точке химчистки мастер, клиент и операция стоят в одной комнате. Когда клиент протягивает кроссовки, происходит сразу всё: сотрудник применяет навык (LMS), создаётся заказ и резервируется химия (ERP), фиксируется визит клиента (CRM). Это одна транзакция, искусственно разделённая на три приложения только потому, что так удобно SaaS-провайдеру.
Каждый раз, когда между LMS, ERP и CRM есть API-граница — это шов. Шов рвётся, шов лагает, шов теряет данные. На заводе с этим можно жить. В сервисе — нет.
Возьмём нового мастера, которого приняли на работу в SneakNFresh во вторник.
Понедельник. HR-менеджер заводит сотрудника в систему. Это карточка в ERP: ФИО, договор, ставка, точка. Одновременно эта же запись становится учеником в LMS — ему назначаются обязательные курсы: «Стандарты SneakNFresh», «Сервис на кассе», «Чистка замши».
Вторник-четверг. Мастер проходит курсы. Каждый завершённый тест поднимает его «уровень компетенций» — это поле в той же карточке. ERP видит: «уровень 1», значит можно ставить на смены и допускать к базовым операциям.
Пятница. Первая смена. ERP открывает доступ к кассе. Каждый заказ, который проходит через мастера, автоматически создаёт две вещи: транзакцию в финансах (ERP) и запись в карточке клиента (CRM). При этом CRM знает, что заказ принял этот конкретный мастер. Если клиент потом оставит отзыв «✦✦✦✦✦», бонусы пойдут именно ему.
Через месяц. Сотрудник прошёл курс «Реставрация кожи». LMS поднимает его уровень до 2. ERP автоматически расширяет список операций, на которые его можно назначить. CRM начинает предлагать его как «специалиста по коже» клиентам с премиум-обувью.
Вся эта цепочка — это один поток данных. В архитектуре с отдельными SaaS-продуктами она потребовала бы 4-5 интеграций, каждая из которых ломалась бы в первой же угловой ситуации.
Технически Кнопка устроена так. Postgres-база с общими сущностями: user, location, order, client, shift, course. Поверх — один API-слой с правами доступа по ролям. И три фронтенда: lms.knopka.tech, erp.knopka.tech, crm.knopka.tech. У каждого свой UI, свой роутинг, свой стейт. Но данные — общие.
Это даёт нам несколько вещей, которых не может дать «интегрированный набор продуктов»:
order. Без задержки. Без рассинхронизации.Делают, но не там, где мы смотрим. Salesforce делает. SAP делает. Все большие enterprise-системы делают, потому что они выросли из эпохи, когда «интеграции через API» ещё не существовали. Маленькие SaaS делают наоборот — каждый берёт свой кусок, потому что так быстрее выйти на рынок.
Сервисный бизнес сегмента 3-50 точек попал между двух стульев. SAP — слишком тяжело и дорого. Десять отдельных подписок — слишком много швов. Мы строим то, чего тут не было: единая платформа в средне-малом сегменте.
Это не легко. Когда у тебя одна база — каждое изменение схемы аффектит всех. Когда у тебя один авторизационный слой — баг в правах ломает доступ ко всему. Команда из 5 человек, которая делает три продукта, должна быть в три раза дисциплинированнее, чем команда из 5 человек, делающая один.
Мы платим эту цену осознанно. В обмен получаем продукт, который чувствуется как один организм, а не как зоопарк.
Сервисный бизнес устроен не как чертёж — он устроен как живое существо. И софт под него должен быть таким же.
The standard way to build SaaS for service businesses goes like this: take one pain point, solve it well, sell a subscription. A couple of years later, add integrations with neighbouring systems via API, draw an "ecosystem" slide, and go raise the next round.
We went the other way. We're building three products at once — LMS, ERP and CRM — and they share a single database. They aren't "integrated", they live together. That decision raises eyebrows with investors. In this piece I explain why it's the right call specifically for service businesses.
When you run a factory, you have three separate worlds. Production — machines and people. Sales — managers and clients. HR — hiring and training. These worlds are physically split: customers don't show up at the machines, the machines don't sit in the sales office.
Service businesses are wired in a fundamentally different way. At a shoe-cleaning location, the technician, the client and the operation are all in the same room. When a client hands over a pair of sneakers, everything happens at once: the employee applies a skill (LMS), an order is created and supplies are reserved (ERP), the client's visit is logged (CRM). It's one transaction, artificially split into three apps only because that's convenient for the SaaS provider.
Every time there's an API boundary between LMS, ERP and CRM — that's a seam. Seams tear, seams lag, seams lose data. A factory can live with that. A service business can't.
Take a new technician who joined SneakNFresh on a Tuesday.
Monday. HR creates the employee in the system. It's a profile in ERP: name, contract, rate, location. The same record automatically becomes a student in LMS — required courses are assigned: "SneakNFresh Standards", "Cashier Service", "Suede Cleaning".
Tuesday–Thursday. The technician works through the courses. Each completed test raises their "competence level" — a field on the same profile. ERP sees: "level 1", which means they can be scheduled and allowed on basic operations.
Friday. First shift. ERP unlocks register access. Each order routed through this technician automatically creates two things: a financial transaction (ERP) and an entry on the client's profile (CRM). At the same time, CRM knows which specific technician took the order. If the client later leaves a "★★★★★" review, the bonus goes to them.
A month in. The employee finishes the "Leather Restoration" course. LMS raises their level to 2. ERP automatically expands the list of operations they can be assigned to. CRM starts pitching them as the "leather specialist" to customers bringing premium footwear.
This whole chain is a single data flow. In an architecture with separate SaaS products, it would need 4–5 integrations, each of which would break on the first edge case.
Technically, Knopka is built like this. A Postgres database with shared entities: user, location, order, client, shift, course. On top of that, a single API layer with role-based permissions. And three front-ends: lms.knopka.tech, erp.knopka.tech, crm.knopka.tech. Each has its own UI, its own routing, its own state. But the data is shared.
This gives us a few things that an "integrated set of products" simply can't:
order. No latency. No desync.They do, but not where we look. Salesforce does. SAP does. All the big enterprise systems do, because they grew out of an era when "API integration" wasn't yet a thing. Small SaaS goes the other way — each one takes a slice, because that's the fastest path to market.
Service businesses in the 3–50 location segment fell between two stools. SAP is too heavy and too expensive. Ten separate subscriptions have too many seams. We're building what wasn't here before: a unified platform for the small-to-mid segment.
This isn't easy. When you have one database, every schema change affects everyone. When you have one auth layer, a permissions bug breaks access to everything. A team of 5 building three products has to be three times more disciplined than a team of 5 building one.
We pay that price knowingly. In return we get a product that feels like one organism, not a zoo.
A service business isn't built like a blueprint — it's built like a living thing. And the software for it should be the same.
Если зайти к типичной сервисной сети и спросить: «как у вас устроено обучение команды?» — почти всегда получится один и тот же список. Notion с регламентами. Папки в Google Drive. Несколько видео-роликов на YouTube или Vimeo. Чат в Telegram для разбора кейсов. Где-то отдельно — тесты в Google Forms. Где-то — PDF-инструкции, которые лежат пятый год и обновляются раз в полгода.
Каждый из этих инструментов сам по себе нормальный. Но мастер, который вышел на смену и хочет вспомнить, как чистить определённый материал, не помнит, где конкретно лежит этот регламент. В Notion? В Drive? Или это видео в общем чате три месяца назад? Он спрашивает в чате — кто-то отвечает через полчаса. К этому моменту клиент уже ушёл с услугой среднего качества.
Сервисной сети не нужно «LMS как у крупных корпораций». Не нужны сложные траектории обучения, геймификация с десятью уровнями, интеграции с HR-системами. Нужен один продукт, в котором собрано всё, что относится к обучению команды:
Один логин, одна точка входа, один поиск. Не «зайди в Drive, потом в чат, потом в Notion». А «открой LMS — там всё».
Курс в LMS Кнопка строится не как «лекция», а как сценарий. Шаг 1 — короткий материал (видео 3–5 минут или текст). Шаг 2 — мини-тест из нескольких вопросов. Шаг 3 — практическое задание на смене с фото-подтверждением. Шаг 4 — куратор смотрит фото и оставляет фидбэк прямо в карточке курса.
Никаких слайдов. Никаких многочасовых вебинаров. Логика простая: посмотри → ответь → сделай → получи комментарий.
Курсы привязаны к ролям и уровням. Новый сотрудник видит обязательный блок. Освоил — система открывает следующий уровень. Администратор и мастер видят разные библиотеки. Сотрудник не тонет в каталоге из 80 курсов — он видит ровно то, что актуально для него прямо сейчас.
Возьмём обезличенный кейс одной из сетей в пилоте — пять точек, около 25 сотрудников. До внедрения LMS у них было: Notion с регламентами (последнее обновление девять месяцев назад), общий чат в Telegram, четыре PDF-инструкции и один отснятый ролик на YouTube. Текучка мастеров — около 40% в год.
За четыре месяца после внедрения LMS:
Высокий средний балл — не потому что тесты простые. Это потому что система разрешает пересдачу под контролем куратора. Цель — не «оценить и зафиксировать оценку», а «довести знание до уровня применения». Если мастер не сдал тест с первого раза, куратор подтверждает пересдачу, и мастер заходит снова. В обычной корпоративной LMS это «провал» — здесь это нормальный шаг.
Текучка за четыре месяца снизилась с прежних ~40% годовых до ~22% в годовом эквиваленте. Сеть это связывает напрямую с тем, что у мастеров появился системный путь роста: новичок видит ясно, какие курсы он должен пройти, чтобы получить следующий уровень и более высокую ставку.
Несколько вещей, которые мы делаем не как «стандартный LMS».
Пересдачи через куратора. Не автоматическая повторная попытка через час, а живой человек, который видит результат, оставляет голосовой или текстовый комментарий и одобряет повторную сдачу. Это превращает обучение в диалог, а не в тестирование.
QR-верификация сертификатов. Каждый сертификат содержит QR-код, ведущий на публичную страницу проверки: какая сеть, какой курс, дата, куратор, оценка. Сертификат становится верифицируемым активом — мастер может предъявить его при переходе в другую сеть, и подлинность подтверждается за секунду.
Чат внутри платформы. Не вынесен в Telegram, не «синхронизирован через бота» — встроен в карточку курса и в карточку ученика. Куратор и сотрудник переписываются прямо там, где идёт обучение. История переписки остаётся привязанной к курсу навсегда.
Лидерборд по точке. Видно, кто сколько курсов прошёл за месяц, у кого какой уровень. В небольших командах это работает как мощный мотиватор. Лидерборд можно отключить — некоторым командам он не подходит культурно.
Партнёрский брендинг. Сеть подгружает свой логотип, фирменные цвета и название — сотрудники видят LMS как продукт своей сети, а не как «внешний сервис». Это мелочь, но она влияет на восприятие.
В первой версии мы пробовали «корпоративные» обучающие ролики: диктор за кадром, схематичная графика, нейтральный голос. Досматриваемость была около 30%. Переснимали в стиле YouTube-блога: конкретный мастер на конкретной точке, со своим лицом, со своими ошибками. Досматриваемость выросла до 81%. Вывод простой: обучение должно быть человеческим, а не институциональным.
Ещё выкинули сложную геймификацию с очками опыта, ачивками и «древом навыков». Команды сервисных сетей реагируют на простые механики: «прошёл курс — получил сертификат», «занял место в лидерборде». Большее усложнение не давало эффекта.
Команда сервисной сети учится не потому, что её мотивируют красивыми словами. Она учится тогда, когда система устроена нормально: понятная роль, понятный путь, один экран, на котором всё видно. Хаотичное обучение из десяти разных инструментов выглядит как «у нас много обучающих материалов», но по факту даёт минимальный эффект — потому что сотрудник не знает, где что лежит.
Если у сети 3–50 точек и она хочет, чтобы команда росла системно, ей нужна не очередная папка в Drive. Ей нужен один продукт, в котором курсы, тесты, сертификаты, чат и лидерборд живут вместе. Тогда обучение становится частью операционного контура, а не отдельной активностью «когда найдётся время».
Walk into a typical service network and ask: "how do you handle team training?" — and you'll almost always get the same list. Notion with regulations. Folders in Google Drive. A few videos on YouTube or Vimeo. A Telegram chat for case discussions. Tests sitting somewhere in Google Forms. PDF guides that have been there for five years, updated maybe twice a year.
Each of these tools, on its own, is fine. But the technician on shift who wants to remember how to clean a specific material doesn't recall where that specific guide lives. In Notion? In Drive? Or was it a video posted in the general chat three months ago? They ask in the chat — someone answers half an hour later. By then the client has already left with a service of average quality.
A service network doesn't need "enterprise-grade LMS." It doesn't need complex learning tracks, gamification with ten levels, integrations with HR systems. It needs one product that holds everything related to training the team:
One login, one entry point, one search. Not "open Drive, then the chat, then Notion." But "open LMS — everything's there."
A course in Knopka LMS is built not as a "lecture" but as a scenario. Step 1 — short content (a 3–5 minute video or some text). Step 2 — a mini-test with a few questions. Step 3 — a practical task on shift with photo confirmation. Step 4 — the curator looks at the photo and leaves feedback right inside the course card.
No slides. No multi-hour webinars. Simple logic: watch → answer → do → get a comment.
Courses are tied to roles and levels. A new employee sees the mandatory block. Once they finish it, the system unlocks the next level. Front-desk staff and technicians see different libraries. Employees don't drown in a catalogue of 80 courses — they see exactly what's relevant for them right now.
Take an anonymised case of one of our pilot networks — five locations, around 25 employees. Before LMS they had: Notion with regulations (last updated nine months ago), a general Telegram chat, four PDF guides and one YouTube video. Technician churn — around 40% a year.
Four months after LMS rollout:
The high average score isn't because the tests are easy. It's because the system allows retakes under curator control. The goal isn't to "score and lock in a grade", it's to "bring knowledge to the level of application". If a technician fails a test on the first try, the curator approves a retake and the technician goes again. In a typical corporate LMS this is a "fail" — here it's a normal step.
Churn over four months dropped from the previous ~40% annualised to ~22% annualised. The network attributes this directly to the fact that technicians now have a systematic growth path: a new hire can see clearly which courses they need to complete to move up a level and earn a higher rate.
A few things we do not in the "standard LMS" way.
Retakes via curator. Not an automatic retry an hour later, but a live person who reviews the result, leaves a voice or text comment and approves the retake. This turns training into a dialogue, not a testing exercise.
QR-verified certificates. Every certificate carries a QR code linking to a public verification page: which network, which course, date, curator, score. The certificate becomes a verifiable asset — a technician can present it when moving to another network, and authenticity is confirmed in a second.
Chat inside the platform. Not piped out to Telegram, not "synced through a bot" — embedded in the course card and the student profile. Curator and employee talk right where the training happens. Conversation history stays attached to the course forever.
Per-location leaderboard. You can see who completed how many courses this month, who's at what level. In small teams this works as a powerful motivator. The leaderboard can be turned off — some teams aren't culturally a fit.
Partner branding. The network uploads its logo, brand colours and name — employees see LMS as their network's own product, not as an "external service". A small thing, but it shifts perception.
In the first version we tried "corporate" training videos: voice-over narrator, schematic graphics, neutral tone. Completion rate was around 30%. We re-shot them in a YouTube-blog style: an actual technician at an actual location, their own face, their own mistakes. Completion rate climbed to 81%. Simple takeaway: training has to feel human, not institutional.
We also dropped the complex gamification with XP points, achievements and a "skill tree". Service-network teams respond to simple mechanics: "finished a course — got a certificate", "took a spot on the leaderboard". Anything more elaborate didn't move the needle.
A service-network team doesn't learn because they're motivated by pretty words. They learn when the system is set up properly: a clear role, a clear path, one screen where everything is visible. Chaotic training across ten different tools looks like "we have lots of training materials" but in practice delivers minimal effect — because the employee doesn't know where anything is.
If a network has 3–50 locations and wants the team to grow systematically, it doesn't need another folder in Drive. It needs one product where courses, tests, certificates, chat and the leaderboard live together. Then training becomes part of the operational loop, not a separate activity for "when there's time".
Если опросить десять партнёров франшизных сервисных сетей и спросить каждого, какая у них маржа на основной услуге, девять ответят «где-то 75–80%». Если потом сесть и посчитать вместе с ними по полной формуле — почти всегда выходит 60–65%. Эта разница в 15 пунктов — то место, в котором у партнёра тихо утекают деньги, и он не понимает почему.
Партнёр считает выручку — она у него на виду каждый день. Партнёр не считает реальную себестоимость одной единицы услуги. И это не вина партнёра. Это вина типичного учёта в сервисной сети, в котором себестоимость считается «по верхам».
Когда партнёр оценивает маржу, он почти всегда учитывает только две статьи: расходники и зарплата исполнителя. Это очевидные затраты, они привязаны к конкретному заказу, их легко вычесть из чека. Если услуга стоит 5 000 ₽, расходники — 250 ₽, мастеру 25% — выходит 3 500 ₽ «маржи». Так и появляется ощущение 70–80%.
В реальности на одну услугу работают ещё четыре статьи затрат, которые партнёры обычно не разносят по единицам:
Никто это не разносит по услугам не потому что не умеет, а потому что в обычном учёте эти статьи живут отдельной строкой «постоянные расходы», и партнёр смотрит на них как на «общий фон» бизнеса, а не как на стоимость каждой конкретной услуги.
В ERP Кнопка себестоимость одной услуги считается по полной формуле:
Себестоимость 1 услуги = (ФОТ + аренда + коммуналка + расходники + амортизация + фиксированные расходы) ÷ N услуг за период
Где N — реальное количество заказов на точке за месяц. Чем выше загрузка точки, тем ниже себестоимость на единицу: фиксированные расходы делятся на большее число заказов. Чем ниже загрузка — тем выше себестоимость, и тем хуже маржа.
Эта формула — не теория. Она зашита прямо в калькулятор ERP. У каждой услуги есть карточка с нормой расходников и нормой времени мастера. У каждой точки — карточка с постоянными расходами. Система берёт данные и считает себестоимость в реальном времени, услуга за услугой, точка за точкой.
Типичная картина: сеть из нескольких точек, считающая выручку в Excel, уверена, что маржа по сети около 80%. Так показывает прежний учёт.
После того как все услуги и все точки прогнали через калькулятор полной себестоимости, картина оказалась другой:
Это типичная картина для сегмента. Не плохой бизнес, не плохой партнёр — просто учёт показывал не то, что есть на самом деле.
Когда у партнёра на руках реальная цифра маржи по каждой услуге и каждой точке, он начинает принимать другие решения.
Пересмотр цен. На услугах с маржой ниже 50% поднимаются цены — на 10–25%, в зависимости от чувствительности клиентов. На услугах с высокой маржой цены не трогаются, чтобы не терять трафик. Это перестаёт быть «прайс по ощущениям» и становится прайсом по цифрам.
Оптимизация смен и часов работы. Если у точки первые два часа работы дают 4–5% дневной выручки, при этом за эти часы платится аренда и зарплата администратора — открытие сдвигается. Партнёры пилота экономили на этом по 1–1,5 млн рублей в месяц по сети.
Выбор поставщиков. Когда становится видна реальная стоимость расходников на заказ, переговорная позиция с поставщиками меняется. Партнёр идёт на смену поставщика не «потому что в чате посоветовали», а потому что калькулятор показывает экономию X на единицу.
Целевая загрузка точки. ERP показывает каждой точке индикатор: «при текущей загрузке маржа X%, чтобы выйти на маржу 65% — нужно Y заказов в день». Абстрактный «KPI выручки» превращается в понятный операционный показатель, к которому можно стремиться.
Партнёр, который точно знает свою маржу, перестаёт принимать эмоциональные решения «по ощущениям». Он перестаёт демпинговать на услугах, на которых уже работает в минус. Он перестаёт держать открытыми часы, в которые точка убыточна. Он перестаёт инвестировать в трафик, который не отбивается.
Сеть, в которой каждый партнёр видит свою маржу в разрезе услуг и точек, в среднем растёт в выручке медленнее, чем сеть, бьющая на объём. Но она растёт в прибыли быстрее. А прибыль — это то, ради чего партнёр и открывал бизнес. Выручка — это вспомогательный показатель.
Калькулятор себестоимости в ERP Кнопка — один из тех модулей, которые партнёры замечают первыми, когда заходят в систему. Не потому что он красиво сделан, а потому что он показывает то, чего они раньше не видели. После этого вернуться в Excel с «маржой по ощущениям» уже не получается.
Ask ten partners running franchised service networks what their margin is on their core service, and nine will say "somewhere around 75–80%." Sit down with them and run the full formula together — and the real number is almost always 60–65%. That 15-point gap is where money quietly leaks out of the partner's pocket, and they don't understand why.
The partner counts revenue — they see it every day. The partner doesn't count the real cost per unit of service. And that's not their fault. It's the fault of typical accounting in service networks, where cost is calculated "from the top".
When a partner estimates margin, they almost always include only two line items: consumables and the executor's wage. These are obvious costs, attached to a specific order, easy to subtract from the receipt. If a service costs 5,000 ₽, consumables are 250 ₽ and the technician gets 25% — you're left with 3,500 ₽ of "margin". That's where the 70–80% feeling comes from.
In reality, four more cost lines feed into each service, and partners don't usually allocate them per unit:
Nobody allocates this per service not because they can't, but because in standard accounting these items sit in a separate "fixed costs" row, and the partner treats them as "background noise" rather than as the cost of each specific service.
In Knopka ERP, the cost of one service is calculated by the full formula:
Cost per service = (Payroll + rent + utilities + consumables + depreciation + fixed costs) ÷ N services per period
Where N is the actual number of orders at a location for the month. The higher the location's load, the lower the per-unit cost: fixed costs are split across more orders. The lower the load, the higher the cost — and the worse the margin.
This formula isn't theory. It's hard-wired into the ERP calculator. Each service has a card with its consumables norm and technician time norm. Each location has a card with its fixed costs. The system pulls the data and calculates cost in real time, service by service, location by location.
Typical picture: a network of several locations, tracking revenue in Excel, certain its network-wide margin is around 80%. That's what the old accounting showed.
After all services and all locations were run through the full-cost calculator, the picture turned out different:
This is a typical picture for the segment. Not a bad business, not a bad partner — accounting just wasn't showing the actual state of things.
When a partner has real margin numbers per service and per location, they start making different decisions.
Price reviews. On services with margin under 50%, prices go up — by 10–25%, depending on client sensitivity. On high-margin services prices don't move, so traffic stays. It stops being a "by-feel price list" and becomes a price list by the numbers.
Shift and hours optimisation. If the first two hours of the day bring in 4–5% of daily revenue, while still paying rent and front-desk wages — opening time shifts. Pilot partners saved 1–1.5M ₽ a month network-wide on this.
Supplier selection. Once the real per-order consumable cost is visible, the negotiating position with suppliers changes. The partner switches suppliers not "because someone in the chat suggested it" but because the calculator shows X savings per unit.
Target location load. ERP shows each location an indicator: "at current load, margin is X%; to hit 65% margin, you need Y orders per day". An abstract "revenue KPI" becomes a concrete operational target.
A partner who knows their margin precisely stops making emotional, gut-feel decisions. They stop discounting services that are already losing money. They stop keeping unprofitable hours open. They stop investing in traffic that doesn't pay back.
A network where every partner sees their margin by service and by location tends to grow revenue more slowly than a network pushing for volume. But it grows profit faster. And profit is what the partner opened the business for. Revenue is a supporting metric.
The cost calculator in Knopka ERP is one of those modules partners notice first when they log in. Not because it looks pretty, but because it shows things they couldn't see before. After that, going back to Excel with "margin by feel" stops being an option.
Стандартная программа лояльности в сервисной сети выглядит одинаково в 90% случаев. Кэшбэк 5% за каждый заказ, накопление на бонусном счёте, возможность потратить на следующий визит. Сеть запускает программу, заносит её в маркетинговые материалы, начинает считать «процент клиентов с картой лояльности».
Через полгода метрики показывают неприятное: средний чек не вырос, частота визитов не выросла, отток не уменьшился. Программа работает не как лояльность — она работает как распределённая скидка. Сеть отдала 5% выручки и получила за это ноль изменений в поведении клиентов.
Скидка — это про цену. Клиент получает скидку, и ему дешевле. Но дешевле ему сейчас, в этот заказ. На следующий заказ через два месяца дешевизна не переносится — она снова в нуле, и клиент снова выбирает сеть на общих основаниях.
Лояльность — это про возвращение. Это поведенческая привычка клиента возвращаться именно сюда, даже когда есть равноценные альтернативы. И это поведение строится не на 5% кэшбэка. Оно строится на памяти системы о клиенте.
Клиент возвращается в кофейню, где бариста спрашивает «вам как обычно — капучино на овсяном без сахара?». Клиент возвращается в химчистку, где мастер говорит «у вас же замшевые, мы их в прошлый раз пропитывали, давайте проверим состояние». В этот момент происходит главное: клиент чувствует себя узнанным как человек, а не как платёжный аккаунт.
Лояльность — это не сумма баллов на счёте. Это ощущение «меня здесь помнят», которое клиент получает каждый раз, когда переступает порог.
Память о клиенте по умолчанию живёт в голове конкретного сотрудника. Бариста, который запомнил предпочтения. Мастер, который помнит, какую обувь сдавал клиент. Администратор, который знает, что клиент не любит, когда его называют на «ты». Это работает — но это хрупкая память. Сотрудник увольняется, уходит в отпуск, переходит на другую точку — и память исчезает. Клиент приходит снова, и его уже не знают.
Задача CRM — перенести эту память из головы сотрудника во внешнюю систему. Чтобы любой новый человек на любой точке за пять секунд знал о клиенте всё, что знала бы вся команда вместе.
В CRM Кнопка у каждого клиента есть карточка. Стандартные поля — телефон, имя, история визитов, баланс баллов. Но главные поля — нестандартные:
Эти поля не обязательны. Но сотрудники мотивированы их заполнять — за каждое заполненное поле мастер получает баллы внутри своей системы мотивации. Чем больше команда узнала о клиенте — тем больше её бонус.
В обычной программе лояльности все клиенты выглядят одинаково — у каждого есть карта, у каждого 5%. В CRM Кнопка клиенты автоматически разбиваются на сегменты по LTV (Lifetime Value) и поведению:
Сегмент клиента видит и администратор, и мастер. К постоянному и VIP-клиенту иное отношение, чем к новому — не лучше, просто другое. Постоянного встречают «как обычно», VIP получает приоритет в записи, новому больше объясняют процесс. Это персонализация, которую невозможно держать в голове на большом потоке.
Отдельный модуль в CRM. Каждый клиент может сгенерировать персональный промокод. Если по нему приходит новый клиент — обоим начисляется бонус. Новичок получает скидку на первую услугу, рекомендатель — баллы.
Главное в этом модуле — граф рефералов. CRM знает, кто кого привёл, и хранит эту связь в карточке клиента. Можно открыть карточку и увидеть: «благодаря этому клиенту пришло 7 человек, из них 4 стали постоянными, общий оборот через цепочку — N рублей за год».
Это превращает активных рекомендателей в видимый актив сети. Их можно отдельно благодарить, давать им что-то особенное — не потому что они «много заплатили», а потому что они приводят других клиентов. Без CRM эта связь невидима — есть просто промокоды и их использование.
Клиент, который не приходил 60–90 дней, — это не потерянный клиент. Это клиент в спящем состоянии. Если ничего не делать, через 6 месяцев он действительно станет потерянным. Если связаться вовремя — около трети возвращается.
В CRM Кнопка win-back автоматизирован. Через 90 дней молчания клиент получает в мессенджер или SMS персональное предложение: «давно вас не было, вернитесь — бесплатная экспресс-услуга на следующий визит». Сообщение отправляется не вручную и не в общую рассылку, а индивидуально и в правильный момент.
Гипотеза, которую закладываем в архитектуру CRM Кнопка: уровни, сегменты, рефералка и win-back должны давать измеримый прирост retention и снижение стоимости привлечения. Это нам и предстоит подтвердить во второй волне пилота.
За 6 месяцев после внедрения:
Это уже не похоже на «программу лояльности как скидку». Это уже похоже на инструмент, который реально влияет на бизнес.
Кэшбэк 5% — это математическая операция. Программа лояльности — это другое. Это система памяти, сегментации, рефералки и автоматизированных коммуникаций, которая работает на удержание клиента. Если у сети есть только кэшбэк — у сети нет программы лояльности, у сети есть встроенная скидка.
Настоящая лояльность строится на том, что система помнит клиента. И это та функция, которую невозможно делегировать одному сотруднику или одной точке. Это должно жить в CRM, и оно должно жить в одном продукте с обучением и операционкой, чтобы данные о клиенте сразу попадали туда, где они принесут пользу.
A standard service-network loyalty program looks the same in 90% of cases. 5% cashback per order, accumulated on a bonus account, spendable on the next visit. The network launches the program, puts it in the marketing, starts tracking "share of clients with a loyalty card".
Six months in, the metrics show something uncomfortable: average ticket hasn't grown, visit frequency hasn't grown, churn hasn't dropped. The program isn't working as loyalty — it's working as a distributed discount. The network gave away 5% of revenue and got zero change in customer behaviour in return.
A discount is about price. The customer gets a discount and it's cheaper for them. But it's cheaper for them right now, on this order. For the next order two months later, the cheapness doesn't carry over — it's back to zero and the customer picks the network on general grounds again.
Loyalty is about return. It's the behavioural habit of a client returning specifically here, even when equivalent alternatives exist. That behaviour isn't built on 5% cashback. It's built on the system remembering the client.
A customer returns to the coffee shop where the barista asks "the usual — oat-milk cappuccino, no sugar?" A customer returns to the cleaner where the technician says "you brought suede last time, we sealed it — let's check how it's holding up." That's the key moment: the customer feels recognised as a person, not as a payment account.
Loyalty isn't a sum of points on an account. It's the "I'm remembered here" feeling the customer gets every time they walk through the door.
By default, the memory of a client lives in a specific employee's head. The barista who remembers preferences. The technician who recalls the kind of shoes the client brought in. The front-desk person who knows the client doesn't like being addressed informally. It works — but it's fragile memory. The employee quits, goes on leave, moves to another location — and the memory disappears. The customer comes back, and they're not known anymore.
The job of CRM is to move that memory out of the employee's head and into an external system. So that any new person at any location knows everything about the customer in five seconds — the same thing the whole team would have known collectively.
In Knopka CRM, every customer has a profile. Standard fields — phone, name, visit history, point balance. But the key fields are the non-standard ones:
These fields are optional. But employees are motivated to fill them in — every filled field earns the technician points inside their motivation system. The more the team learns about the client, the bigger its bonus.
In a typical loyalty program all clients look the same — everyone has a card, everyone gets 5%. In Knopka CRM, clients are split automatically into segments by LTV (Lifetime Value) and behaviour:
The customer's segment is visible to the front desk and the technician. Regulars and VIPs get treated differently from new clients — not better, just differently. A regular is greeted "as usual", a VIP gets booking priority, a new client gets more explanation. This is the kind of personalisation that's impossible to keep in your head at any real volume.
A separate module inside CRM. Every customer can generate a personal promo code. If a new customer comes in through it, both get a bonus. The new arrival gets a discount on their first service, the referrer gets points.
The key thing in this module is the referral graph. CRM knows who brought whom and stores that link on the client profile. You can open a profile and see: "thanks to this customer, 7 people came in, 4 became regulars, total revenue through the chain — N roubles per year".
This turns active referrers into a visible network asset. You can thank them separately, give them something special — not because they "paid a lot" but because they bring in other customers. Without CRM this connection is invisible — there are just promo codes and their usage.
A client who hasn't shown up in 60–90 days isn't a lost client. They're a dormant client. If you do nothing, in 6 months they really will be lost. If you reach out in time — about a third come back.
In Knopka CRM, win-back is automated. After 90 days of silence the client receives a personal offer via messenger or SMS: "we haven't seen you in a while, come back — a free express service on your next visit." The message goes out individually, not as a mass blast, and at the right moment.
The hypothesis we're baking into the Knopka CRM architecture: tiers, segments, referrals and win-back should deliver measurable retention gains and lower acquisition costs. That's what we'll need to confirm in the second pilot wave.
Six months after rollout (target picture):
That no longer looks like "a loyalty program as a discount." That looks like a tool that genuinely moves the business.
5% cashback is an arithmetic operation. A loyalty program is something else. It's a system of memory, segmentation, referrals and automated communication that works on retaining the customer. If a network only has cashback — it doesn't have a loyalty program, it has a built-in discount.
Real loyalty is built on the system remembering the client. And that function can't be delegated to a single employee or a single location. It has to live in CRM, and it has to live in one product together with training and operations, so that data about the client lands immediately where it's useful.
Мы только-только запустили пилот. LMS вышла первой и сейчас тестируется на первой партнёрской сети. ERP и CRM находятся в активной разработке — каркас собран, отдельные модули уже работают, остальное мы доводим до релиза в течение лета и осени 2026.
Эта статья — не про цифры и не про результаты. Их пока нет, и мы не будем их выдумывать. Это статья про то, зачем мы это делаем и какой путь видим впереди.
Сервисный бизнес в России и СНГ построен на людях и привычках, а не на системе. Партнёр открывает точку — и сразу обнаруживает, что у него десять разных инструментов, каждый из которых решает только свой кусочек. Запись клиентов в одном сервисе. Финансы в Excel. Чаты с командой — отдельно в мессенджерах. Обучение — где-то в Google Drive и YouTube-ссылках. Лояльность — таблица с ручным начислением баллов раз в неделю.
Это нормально для одной точки и кошмар для сети. Когда у тебя 5–50 точек, каждый разрозненный инструмент превращается в источник потерь — времени, денег и качества сервиса.
Мы строим Кнопку, потому что считаем: сервисный бизнес заслуживает один связный продукт, а не десять разрозненных. Учить команду, считать деньги, вести клиента — в одном контуре, с одной логикой, с одним местом, куда заходит партнёр утром.
В пилот вошёл первый партнёр. Это сеть, которой мы доверяем и которая доверяет нам — это критично на ранней стадии, когда нужно много итераций и много обратной связи. Мы намеренно не берём широкий пул на первом круге: лучше глубоко проработать сценарии с одним партнёром, чем поверхностно с десятью.
Что сейчас в работе:
Три продукта в одной платформе — это не маркетинговый ход. Это архитектурное решение, которое раскрывается во времени. Когда LMS, ERP и CRM живут в одном контуре данных, появляются вещи, которые невозможны в разрозненных инструментах:
Мы верим, что сервисная сеть из 3–50 точек получает от такой платформы больше, чем от любого из этих инструментов по отдельности — даже если каждый отдельный инструмент в моменте выглядит сильнее.
Лето 2026. Доводим до релиза основные модули ERP и CRM. Стабилизируем то, что уже работает. Никаких новых направлений — только полировка и закрытие технического долга.
Осень 2026. Открываем waitlist на вторую волну пилота. Берём несколько партнёров из смежных вертикалей сервисного бизнеса — барбершопы, бьюти-студии, ремонт обуви, маникюр, автомойки. Цель — проверить, что Кнопка работает не только в нашей домашней нише, но и шире.
Зима 2026/2027. Мобильное приложение для мастера, расширение интеграций (ЭДО, кассы, мессенджеры для уведомлений), готовые отраслевые шаблоны под 10+ ниш — из коробки.
Мы не обещаем результатов, которых ещё нет. Мы строим продукт, в который верим — и приглашаем партнёров строить его вместе с нами.
Если вы держите сервисную сеть и хотите быть в следующей волне пилота — оставьте заявку через форму на сайте или напишите на support@knopka.tech. Берём не всех, но смотрим всех.
We've just launched the pilot. LMS shipped first and is being tested with our first partner network. ERP and CRM are in active development — the skeleton is built, individual modules are already working, the rest we're driving to release over the summer and autumn of 2026.
This piece isn't about numbers or results. There aren't any yet, and we won't invent them. This is about why we're doing this and the path we see ahead.
The service business in Russia and the CIS is built on people and habits, not on systems. A partner opens a location — and immediately finds themselves with ten different tools, each solving only its slice. Bookings in one service. Finance in Excel. Team chats — separate, in messengers. Training — somewhere in Google Drive and YouTube links. Loyalty — a sheet with manual point allocation once a week.
This is fine for one location and a nightmare for a network. When you've got 5–50 locations, each scattered tool turns into a source of loss — time, money and service quality.
We're building Knopka because we believe a service business deserves one coherent product, not ten scattered ones. Train the team, count the money, manage the client — in one loop, with one logic, with one place the partner opens in the morning.
The first partner is in the pilot. It's a network we trust and that trusts us — that matters at this early stage, when you need a lot of iteration and a lot of feedback. We deliberately don't take a wide pool in the first round: it's better to go deep on scenarios with one partner than shallow with ten.
What's in flight right now:
Three products in one platform isn't a marketing move. It's an architectural choice that pays off over time. When LMS, ERP and CRM live in one data loop, things become possible that aren't possible across scattered tools:
We believe a service network of 3–50 locations gets more out of a platform like this than out of any of these tools individually — even if a given single tool, in isolation, looks stronger.
Summer 2026. Driving core ERP and CRM modules to release. Stabilising what already works. No new directions — only polish and closing technical debt.
Autumn 2026. Opening the waitlist for the second pilot wave. Taking on several partners from adjacent service verticals — barbershops, beauty studios, shoe repair, nail salons, car washes. Goal: confirm Knopka works not only in our home niche but more broadly.
Winter 2026/2027. A mobile app for the technician, broader integrations (EDI, registers, messengers for notifications), ready-made industry templates for 10+ niches — out of the box.
We don't promise results that don't exist yet. We're building a product we believe in — and we're inviting partners to build it with us.
If you run a service network and want to be in the next pilot wave — leave a request through the form on the site or write to support@knopka.tech. We don't take everyone, but we look at everyone.