📑 Mục lục bài nghiên cứu
Type: Research Essay
Stage: Working Hypothesis
Evidence basis: Public product signals, SME workflow observation, and operational inference
Last updated: July 2026
Boundary: An outside-in hypothesis with no access to ZaloPay’s internal roadmap, merchant data, or operating model.
#Reading Route
Quick orientation: Observation → Share of Operations → Practical question
Concept logic: Work after payment → Pathway Lens read → operating boundary
Critical review: Drift / boundary / governance notes → dependency and permission questions
Original LinkedIn post: Part 1 — My Thesis About the Pattern of Operations: Case Study #1 — ZaloPay & SMEs ↗
#Observation
This case began with a public signal: ZaloPay appeared to be moving closer to SMEs.
At first, the obvious interpretation was payment expansion. A payment wallet working with small merchants naturally brings up questions about QR adoption, merchant acceptance, settlement, transaction volume, and payment convenience. That reading made sense. ZaloPay is a payment app, and payment is the visible layer.
But the more I looked at the daily workflow of small merchants and household businesses in Vietnam, the more that explanation felt incomplete. The merchant’s problem did not seem to end at receiving money. In many cases, that was where another layer of work began.
Receiving payment does not end the merchant’s work. It simply marks the point where another layer begins: matching orders, updating inventory, tracking cash flow, remembering returning customers, arranging delivery, following up, and making dozens of small decisions throughout the day. Much of that work still lives across notebooks, spreadsheets, chat groups, memory, and offline conversations.
So the question started to shift.
At first, the question seemed to be:
How can a payment platform help SMEs receive money more easily?
But after mapping the merchant workflow, the better question became:
What operational problems do SMEs still face after payment succeeds?
That was the moment the case became more interesting. Payment was still important, but it began to look less like the whole problem and more like the first visible signal in a much larger operating pathway.
That was when I realized I was no longer studying only a payment product. I was studying the work that begins after payment.
A payment confirms that something happened. It does not automatically organize the business reality around that event. It does not tell the merchant whether the order was fulfilled, whether inventory changed, whether the customer should be remembered, whether cash flow is improving, or whether today’s sales pattern should affect tomorrow’s decision.
This led to the core observation of the case:
SMEs do not struggle only because they lack payment tools. Many operational challenges begin after money enters the business.
From there, ZaloPay became interesting not only as a payment app, but as a possible case for thinking about SME operations. If a platform already sits close to payment activity, it may also sit close to signals about orders, customers, cash flow, repeat behavior, inventory movement, and business rhythm.
The question is not whether every payment platform should become a full business operating system. That would be too simple. The more useful question is whether payment can become the entry point into a calmer operational layer for small merchants.
That realization led me to a different way of looking at platform businesses. Instead of asking only which feature a company owns, I started asking which part of people’s daily work flows through it.
This is where I started thinking about Share of Operations.
Most platform questions focus on users, transactions, payment volume, or merchant adoption. Those metrics still matter. But for SME infrastructure, another question may be more revealing:
How much of a merchant’s daily operation flows through the platform?
A company that owns only one feature can be replaced. A company that becomes part of daily operations is harder to remove, not because the merchant is locked in, but because the system has become part of how the merchant works.
A merchant can switch payment providers. A merchant can switch marketing channels. But if a system helps organize orders, customers, cash flow, inventory signals, and daily decisions, then it is no longer only a payment tool. It becomes part of the operating layer.
The broader lesson is that I no longer look at businesses only by asking what product they offer. I start by asking what people rely on to run their daily operations.
And in this case, the question became:
Who becomes part of the merchant’s daily operating rhythm after payment succeeds?
#Pathway Lens read
The pathway is not simply payment → settlement. It can become:
- payment signal → order record;
- transaction history → cash-flow view;
- merchant activity → business recommendation;
- customer behavior → retention / loyalty workflow;
- operational data → future system input.
The visible moment is payment success. The hidden pathway is the merchant work that begins after that moment: recording, matching, remembering, planning, correcting, and deciding.
#Drift / boundary / governance notes
- Drift: merchant reality may be reduced to payment data if inventory, labor, informal credit, family operations, offline orders, seasonal demand, or supplier constraints are missing.
- Boundary: payment output can become business advice, business record, credit signal, or platform dependency.
- Evidence: transaction source, merchant action, recommendation basis, record update, and downstream effect should remain reconstructable.
- Authority: ZaloPay should not silently move from payment processor to business operator without clear permission boundaries.
- Recovery: wrong recommendations should be reversible, explainable, and correctable before they affect credit, cash flow, or merchant trust.
#Practical question
Can a local payment platform become a calm commerce infrastructure layer without turning small merchants into dependent data subjects?