An online booking service for beauty salons in Almaty has 1,200 paying salons. At a meeting with an investor the word "ecosystem" comes up: add prepayment for bookings, a client app with a catalogue of every salon, supplies purchasing and loans for salons, "like Kaspi". The team has the capacity for one direction per quarter. The service's numbers are made up.
What an ecosystem is
In a 2022 article, BCG describes an ecosystem as a group of largely independent companies that together give the customer something none of them could deliver alone. There are two types. In a transaction ecosystem a platform connects two sides of a market, such as buyers and sellers. In a solution ecosystem a core company gathers add-ons from other participants, the complementors, around its own product. BCG calls that core company the orchestrator: it sets the rules and decides who gets in.
The most familiar example in Kazakhstan is Kaspi. In its Form 20-F annual report for 2025, signed on 16 March 2026, the company describes its two-sided model in Kazakhstan: the Kaspi.kz Super App for consumers and Kaspi Pay for merchants and entrepreneurs, with payments, a marketplace and financial services for both sides. As of 31 December 2025, Kaspi.kz in Kazakhstan had about 15.7 million average monthly active users and Kaspi Pay about 764,000 active merchants. The company names the network effects between the two sides as one of its strengths. The same report lists among its risks that a change consumers welcome may hurt merchants. The next step is our inference, not the report's: the more sides there are, the more such conflicts you get.
A service with 1,200 salons has no reason to build its own Kaspi. What it needs is to find where the customer's job breaks and close that gap, with a module of its own or with someone else's service.
The picture shows the same logic on an online shop order: one purchase has three participants, and on a return one of them has to own the problem.
Start with the end-to-end job
The salon's job is a schedule without empty hours. The client's job is to see her own stylist at a convenient time. The booking path goes like this: the client finds a time, books, gets a reminder, turns up, pays, books again. The service covers the first two steps; the rest bypass it:
- the receptionist sends reminders by hand on WhatsApp, if she has time;
- payment happens at the front desk, by card terminal or a bank's QR code, and the service never hears about it;
- if the client does not turn up, the stylist loses an hour, and a no-show can only be marked in the calendar by hand.
No-shows are the first thing receptionists mention on calls, and they show up in the database: in salons that mark them by hand, there are 8 no-shows per 100 online bookings.
Cross-sell or network effect
| What to add | Which gap it closes | Type of link | What is already known |
|---|---|---|---|
| Prepayment for online bookings | No-shows | Add-on: its value to a salon does not depend on how many other salons use it | 8 no-shows per 100 online bookings, receptionists are asking for prepayment |
| WhatsApp reminders | No-shows and the receptionist's manual work | Add-on | Receptionists send reminders by hand |
| A client app with a catalogue of salons | Finding a new salon | Two-sided marketplace: the more salons, the more useful it is to clients, and the other way round | In the service's first pilot the catalogue did not pay off |
By HBS Online's definition, a network effect is when the value of a product depends on the number of buyers, sellers or users. A direct effect grows with the number of users in one group, as on social networks. An indirect one arises between groups: more sellers make the product more useful to buyers, more buyers make it more attractive to sellers.
The catalogue could create an indirect effect. Prepayment and reminders do not: a salon does not care whether other salons have switched them on. That is cross-sell, and there is nothing wrong with it as long as it closes a gap in the same customer's job. Supplies purchasing and loans serve other jobs of the owner, unrelated to booking, and need partners from a different business.
The catalogue is the most tempting option: "network effect" sounds like protection from competitors. But the service started out with exactly this idea, and in its first pilot regular clients booked 340 times through their salons' own pages, while 26 new clients turned up. So the place to start is prepayment: the gap is backed by a number, there is one side, and the value can be measured.
Who owns it when something goes wrong
Prepayment is 2,000 ₸ per online booking, credited towards the price of the service. The service does not take the money itself: a payment provider processes it, and the salon receives it. There are three participants, and before launch they agree who does what on a failure:
| Situation | Who handles it | What the client gets |
|---|---|---|
| The client cancelled before the deadline the salon set | The service issues a refund through the provider automatically | Her money back and a cancelled booking |
| The stylist fell ill and the salon cancelled | The salon cancels in the calendar, full refund | An apology and a different time |
| The money was taken but the booking was not saved | The service reconciles provider payments against bookings every day | A refund or a booking the same day |
| The client turned up and disputes the amount | The salon resolves it on the spot, the service shows the payment history | A receipt showing the prepayment |
The salon writes its own cancellation rules and shows them before payment: how many hours ahead a booking can be cancelled for free, and what happens on a no-show. If the rules appear after payment, the disputes will be with the service the client paid through, not with the salon.
A shared booking number links the payment, the booking and the visit. But a number does not assign an owner: without the table above, a refund for a broken booking will bounce between three chats.
Each participant gets only its own data
The provider needs the amount and the booking number to take a payment, not the client's visit history. The catalogue, if it is launched after all, does not need the phone numbers of a salon's clients. The salon collected those numbers for bookings. On our reading of the Law "On Personal Data and Their Protection", as amended up to 14 September 2026, data may be used only for the purposes stated when it was collected (Article 14). Advertising the catalogue to those people is a new purpose and needs a separate legal basis. Decide which one with a lawyer before you join up participants' databases. This is not legal advice.
Measure the value of one link
At first prepayment was switched on for every salon that asked, and a month later the product manager brought a comparison: 180 salons with prepayment had 3 no-shows per 100 online bookings, the rest had 8. It looks like a win, but those 180 salons chose prepayment themselves. Perhaps they offer expensive treatments and have clients who turn up anyway. A comparison like that shows how the salons differ; it cannot show what prepayment did.
So for the next 300 salons that asked, it was switched on differently: for a random half (a flag by salon ID) straight away, for the other half two months later, as in an A/B test of a product feature. After the first month, averages per salon:
| With prepayment | Without prepayment | |
|---|---|---|
| Salons | 150 | 150 |
| No-shows per 100 online bookings | 4 | 7 |
| Online bookings per month | 112 | 118 |
| Visits from online bookings | 107.5 | 109.7 |
No-shows went down, but so did online bookings. Perhaps some clients did not want to pay in advance, or perhaps it is chance: without the spread across salons you cannot tell whether a gap of six bookings is noise. In the end visits are about the same, two fewer. On top of that, a client who would not pay online may have called the receptionist instead, and she does not show up among online bookings. So in the second month you compare all of the salon's bookings, booking_created with source = online and admin, and split the result by treatment length: perhaps prepayment is only worth it for long appointments.
And do not add the participants' money up into one revenue figure. In a month, 112 × 150 × 2,000 ₸ = 33.6 million ₸ passed through prepayment in 150 salons. That is clients' money for salons' services; the service's revenue is the subscriptions plus whatever it charges for the module, if anything.
Retention through inconvenience is not value
The more modules a salon uses in the service, the harder it is to leave: bookings, payments, the client base, everything is inside. Retention goes up, and it is tempting to credit the ecosystem. But a salon that stays only because it cannot export its client base is not a happy customer; it is a hostage, and it will leave with a bad review as soon as it finds a way. Exporting the base, switching off a module and changing plan should take a couple of clicks, and retention is measured among those who could leave and stayed.
Exercise: one link for your own product
Finally, a report that is easy to mistake for success. Six months later the product manager writes: "600 salons have connected the prepayment module, the ecosystem works." It turns out that after an update, evening slots can only be opened for booking with prepayment switched on. Can 600 connections be taken as proof of value?
No. Salons connected the module because they could not open evening slots without it, and the number of connections describes a forced action. Value will show in no-shows and in all of a salon's bookings, counted against a control group as in the test above, and in churn: if salons with evening hours started leaving more often after the update, the link is doing harm. A mandatory module also breaks the measurement: every salon that wants evening slots has prepayment on, and there is no one left to compare with.
Video: business ecosystems
The first part of a lecture on the types of ecosystems.