Printer Ran Out of Ink Midday: A Dedicated App or a Lighter Ordering Portal?
The printer reports running out of ink when the accountant needs to complete the documents. The person in charge finds a technician on Zalo, takes a photo of the ink cartridge, sends the machine model and waits for confirmation. The supplier only knows the demand when the customer has been interrupted; If the response is slow, the reorder may be transferred to another unit.
This is a simulation situation, not a case study of a specific customer. It shows the real B2B after-sales problem: the supplier has a contract, an engineering team, and a sales history, but fails to turn device data into a proactive reset flow. The solution can be a portal, PWA, Zalo Mini App or a separate app — and the right choice depends on behavior, data and operations, not on the desire to “have an app”.
Situation: repeated demand but the purchase signal is lost

A business customer may operate multiple printers in multiple departments. Each machine has a different model, serial, ink type, usage level and responsible person. In reality, the counter number may be in the Zalo image; The ink change time is in the technician's notes; orders are in accounting software; The buyer is in the memory of the sales person.
Without a unified equipment profile, suppliers don't know exactly which machines are going to need supplies. Customers also don't have a place to check “which ink is right for this machine, when was the last time they bought it, what status is the request in?”
Business consequences: loss of orders, increased service costs and reduced trust

The first consequence is that reset revenue is unstable. The supplier has spent money on acquiring customers and installing equipment, but repeat orders for supplies still depend on the customer remembering the right person to contact.
Manual processing costs also increase: each request may have to go through sales, engineering, warehouse and accounting to confirm the model, ink code, price and approver. For B2B customers, “machine working continuously” is more important than a beautiful interface.
Limits of current practice

Website and contact form
The website is suitable for customers to find suppliers, view services, read instructions and send the first request. But a general form does not automatically know which device the customer owns, what type of ink is used, what is the history and who has approval rights.
Personal Zalo and OA Zalo
Personal Zalo is convenient for conversation, but relationships and data can follow employees. Zalo OA is suitable for content, care, and some notification streams according to the platform's conditions. That said, a message still doesn't replace structured device records and order statuses.
CRM
CRM is useful for sales teams to manage accounts, opportunities and activities. But customers should not be forced to use the vendor's internal interface. CRM needs to provide data to the portal or application via appropriate API.
Repeat behavior and why customers return

Before choosing a technology, let's describe a measurable loop:
1. The person in charge scans the code on the machine or selects the device from the list.
2. The system displays the correct ink code and most recent history.
3. The user submits the counter number, confirms the ink level, or creates a reset request.
4. The approver receives the request with enough information.
5. Validation repository available; Customers track delivery and installation.
6. History is updated to the correct device.
The reason for coming back is not “reading the news”. This reduces the risk of selecting the wrong material, reduces data re-entry, sees status, and keeps history by asset. If these benefits only appear once or twice a year, it will be difficult for your app to retain. If the user manages dozens of devices and performs weekly operations, the setting value is stronger.
The role of the app and its alternatives

| Plan | suitable when | Main value | Limits need to be verified |
|---|---|---|---|
| Website + Zalo/email | Few devices, low frequency | Low cost of change, easy to access | Many manual steps, fragmented data |
| Customer portal | Need history, accounts, approvals | One source of status, clear decentralization | Frictional login and account support |
| PWA | Want to quickly try it on the web platform | Quick opening link, can add home screen | Platform/device capabilities vary by platform |
| Zalo Mini App | Customers use Zalo regularly | Reduces installation friction, close to the existing channel | Depends on policy and platform limitations |
| App cross-platform | Repetitive behavior is clear | One main codebase, good scan/push | There are still store, QA and maintenance costs |
| Native app | Need deep device/offline integration | Control background experiences and features | Highest cost and complexity |
Apple requires applications to have sufficient utility and long-term value; an app that is primarily a marketing document or link collection runs the risk of not meeting minimum functionality expectations. Therefore, a “mini website” including introduction, news, forms and phone numbers is not a reason to invest in an app.
A practical recommendation is to start with a portal/PWA that incorporates QR. Mini App is an experimental branch when Zalo behavior is strong; Private apps are only considered after pilots demonstrate frequency and value.
Operational process: who updates what?

An aftermarket product does not operate on its own. Roles need to be clearly assigned:
– Technicians: update asset codes, serials, counters and supplies after each service.
– Sales/account: verify organization, location, user contact and approver.
– Warehouse: maintain replacement product codes, availability and expected delivery time.
– Customer care: monitor slow requests, print errors and post-delivery feedback.
– Accounting: pay the status of quotes, invoices or debts at the necessary level.
– Product owner: responsible for data rules, access rights, KPIs and backlog.
During installation or maintenance, the technician should instruct the customer to scan the QR, confirm the machine, and complete the first task.
Data and integration
Minimum data
Records should include: asset code, model, serial, location, compatible inks, contracts, users, approvers, counters, ink replacement history, orders, tickets and delivery status. There is no need to collect data that does not serve the stated purpose.
Integrated architecture
Portal/app should not be an isolated database. CRM provides accounts; ERP/accounting provides item codes and status; available supply warehouse; ticketing incident management; QR linked to the device.
Firebase Cloud Messaging allows notifications to be sent cross-platform and to registered groups, but notifications do not replace standard data and are not guaranteed to be read. The design must have a status box in the product and a backup reminder mechanism.
Law on Personal Data Protection 91/2025/QH15 takes effect from January 1, 2026. Pilot needs to define the purpose of processing, access rights by role, retention period, logs, and how to respond to data subject requests.
Cost: including part after launch date
Do not publish an overall cost figure without knowing the scope. Let's model it in terms of variables:
– `C_discovery`: survey, process design and data;
– `C_build`: UX, development, integration, testing;
– `C_platform`: hosting, notification, store or platform fee;
– `C_ops`: clean data import, support, training, content;
– `C_maint`: maintenance, operating system upgrade, security;
– `C_activation`: QR, documentation, employee activation time.
Total cost of ownership by period:
`TCO = C_discovery + C_build + C_platform + C_ops + C_maint + C_activation`.
Portal/PWA typically reduces the application release portion, but does not remove data, integration, and operations costs. Private apps can add value when deep device capabilities are needed, while also increasing QA and maintenance.
Payback mechanism
Put:
– `N`: number of guests in the pilot;
– `O`: number of rebooking opportunities per customer during the period;
– `A`: average single value;
– `M`: contribution margin;
– `ΔR`: application retention rate improvement;
– `S`: economical processing hours;
– `H`: cost per hour;
– `C`: TCO of the period.
Estimated benefits:
`B = N × O × A × M × ΔR + S × H`.
ROI:
`ROI = (B – C) / C`.
The conservative scenario uses low activation levels and `ΔR`, high support costs. The base scenario uses the measured values in the pilot. Positive scenarios are only used when customers return regularly, discount codes are incorrect, and data is maintained. This is a calculation framework, not a revenue promise.
Pilot small for 6–8 weeks
Scope
Choose a group of customers who have multiple machines, have recurring orders, and are willing to coordinate. Implement only four tasks: machine acknowledgment, counter sending, reset from history, and status monitoring. Use QR at the machine; No need for complicated loyalty.
Baseline
Measure before the pilot: number of steps, confirmation time, model re-question rate, wrong codes, orders held, staff hours and support costs.
Stop or extend condition
Stop or collapse to the portal if machine records are not updated, customers do not complete the first task, manual handling rates do not decrease, or support costs exceed value. Scaling up when data is sufficient, operations are repeatable, processing times are reduced, and increased contribution margins can offset TCO.
KPIs need to be tracked
– Percentage of machines with enough model, serial, ink type and person in charge.
– Percentage of people invited to activate.
– First task completion rate.
– Percentage of reset requests completed.
– Time from request to confirmation.
– Ratio requires material code correction.
– Percentage of returning guests in the appropriate period.
– Economical operating hours.
– Support costs for each active user.
– Increased contribution margin and ROI according to the formula.
Checklist before deciding to make an app
– [ ] There are specific groups of users and browsers.
– [ ] Has a behavior that is repeated often enough.
– [ ] Benefits immediately after first scanning/confirming the device.
– [ ] Has device data and data owner.
– [ ] There are warehouse operators, tickets and status.
– [ ] Has baseline, KPI and payback formula.
– [ ] Tried portal/PWA or Mini App if more suitable.
– [ ] There are stop conditions, not just expansion conditions.
CTA: start with a reset flow, not with a feature list
FHC helps B2B SMEs survey post-sale contact loss points, design asset data, compare portal/PWA/Zalo Mini App/own app and build pilots with KPIs. The goal is not to sell the app at any cost, but to reduce customer disruption and retain the value of the after-sales relationship.
Contact FHC: 0325.112.310 · [email protected] · https://www.chantroituonglai.com
Source checked on July 31, 2026: Apple App Review Guidelines, Firebase Cloud Messaging, Law on Personal Data Protection 91/2025/QH15.
n
Reference source
- chantroituonglai.com](https: — chantroituonglai.com](https:
- developer.apple.com — developer.apple.com
- firebase.google.com — firebase.google.com
- vanban.chinhphu.vn — vanban.chinhphu.vn
Author
Customer Care