In a service business the client, the order and the employee meet in one room. I'll go through when one product is enough, when you need two and when it's worth putting everything together — and how to make sure data isn't lost at the joints.
The standard way to build subscription software for a service business looks like this: you take one pain, solve it well, sell a subscription. A couple of years later you add integrations with neighboring systems, draw a slide about an “ecosystem” and go to the next funding round.
We went a different way. We are building four products — CRM, ERP, LMS and ID. Each works on its own, and together they share data and the employee account. In this article I explain why this matters for a service business and how to tell what you need.
a service business is not three separate circuits
When you run a factory, you have three separate worlds. Production is machines and people. Sales are managers and clients. HR is hiring and training. These worlds are physically separate: the client never appears at the machine, and there is no machine in the manager's office.
A service business is built differently. At a shoe cleaning location the technician, the client and the operation stand in one room. When a client holds out their sneakers, everything happens at once: the front-desk administrator creates the order and assigns a technician (CRM), the technician applies the skill they were trained in (LMS), the work done becomes output, from which pay is calculated, and the payment becomes money in the location's cash register (ERP). This is one event, which in software is usually split across three unconnected applications.
There is always a joint between products. The question is who stitches it. If the joint between orders and money accounting is stitched by an administrator — by moving numbers from one spreadsheet to another — it tears, lags and loses data. In a factory you can live with that. In a service business, where everything happens within one minute at the counter, you can't.
how knopka's products share data
- One employee account. ID.Knopka is the sign-in to all products by an SMS code or a password. Roles are by location: one person can be a technician at one location and a location manager at another.
- A shared directory. Locations, cities, time zones and currencies live in ID, and all products take them from there.
- Money comes from orders. The ERP receives orders, payments, refunds and technician output from the CRM. Nobody moves numbers by hand.
- An action log. ID shows who did what and when.
The data exchange between products is described explicitly, in one place. How this works on the money side was explained by the ERP developer in the article how we built ERP.Knopka: money you can trust.
one employee: from the invitation to pay
Take a new technician who has been hired at a shoe cleaning location.
The first day. The location manager sends them an invitation link. The technician gets an account in ID.Knopka with a role at their location — and signs in to all the products with this same account.
The first days. The technician takes the required courses in LMS.Knopka — network standards, service at intake, suede cleaning — and passes the final certification. For the certification they get a certificate with QR verification.
The first shift. In the CRM they are the performer of order items: for each item you can see who is doing it and its status — pending, in progress, ready.
The pay period. The ERP has already received their output from the CRM and calculated pay by the location's rate. The location manager doesn't need to check the technician's notebook against a timesheet — in detail in the article how to calculate technician pay by location rates.
At none of these steps does an administrator move data from one system to another.
when to take one product, when two, when all
the LMS only
An online school or a company that needs to train staff: courses, lessons, quizzes, certification, certificates with QR verification, webinars, a knowledge base, chat and a leaderboard. There may be no client orders here at all — and no CRM needed. More in LMS.Knopka for online schools and staff training and knopka for online schools.
LMS and CRM
A business where clients are served by trained employees: a service location, a salon, a studio. CRM.Knopka handles orders, online booking, the unified inbox, the loyalty club and the client portal, and the LMS trains the team in the standards used to work with those clients. The sign-in to both products is one, through ID.
CRM and ERP
When the main thing is money from orders: a location or a network where a technician is paid from output. ERP.Knopka receives orders, payments, refunds and output from the CRM and shows revenue and cash by day, location profit for the month, technician pay by rates and royalties.
all together — with ID
A network of locations or a franchise: clients, money, training and access. ID provides one employee account, roles by location and a shared directory of locations, cities, time zones and currencies. Which products you need, you can put together on the home page, like building blocks.
why not everyone does it this way
They do — but not where we are looking. Salesforce does it. SAP does it. Large systems grew up in an era when integrations between services didn't exist yet, and they built everything inside themselves. Small subscription services go the opposite way — each takes its own piece, because that is the faster way to the market.
A business with clients and a team — from a single location to a network — has ended up with no good option. SAP is too heavy and expensive. Ten separate subscriptions mean too many seams. We are building what was missing here: products you can take one at a time and, when needed, connect without moving data by hand.
the difficulties
It isn't easy. When products share an account and a directory, a mistake in roles hits all of them at once. When the ERP calculates money from CRM data, any difference in how the products understand an order turns into wrong pay. That's why the agreement on data between the products is written explicitly and in one place.
We pay this 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 creature. And software for it should be the same.
frequently asked questions
can I take just one product?
Yes. Each Knopka product works on its own. For example, LMS.Knopka suits an online school that has no client orders and doesn't need a CRM.
does an employee need a separate login for each product?
No. An employee signs in to all products with one ID.Knopka account — by an SMS code or a password. Roles are set by location.
what data does the ERP get from the CRM?
Orders, payments, refunds and technician output. From these the ERP shows revenue and cash by day and location profit for the month, and calculates technician pay by the location's rates.
are CRM, ERP and LMS in knopka one system?
No, they are separate products. Together they share data and the employee account: the ERP receives data from the CRM, while the sign-in to all products and the shared directory of locations are in ID.Knopka.
