A home-repair company goes digital, part 4: phase two — a PWA as the repeat-customer entry, not a native app

This series follows a home-repair company in Chonburi, step by step, into digital. The story comes from our real implementation experience in the home-services industry — if you run a small service company living off repeat customers, you should see your own vans in every chapter. Each chapter explains: what was built, what was deliberately not built, and what evidence earned the right to move on.

The repeat customer’s problem is not “service is bad” — it’s “can’t find you”

Phase-one data told the owner one thing: repeat calls were above thirty percent — customers were willing to come back. But how did they come back? By remembering the phone number, by having the LINE chat, or by searching and finding the company again.

That’s the problem — the neighborhood pool is only so big, and every time a customer “can’t find you,” you’re sending that customer to the shop on the corner. And a home’s problems aren’t one-time: the AC needs service every year, the tap will need replacing, there’s always a next thing to fix. Whoever the customer can “find again fast” gets the next order.

The owner wanted a “repeat-customer entry point.” But his first thought — building an app — was quickly rejected.

Why a PWA, not a native app

The idea of an app is natural: install the app and the customer sees you every day. But for a small regional company, a native app carries ongoing and heavy costs:

• App-store listing and review. The App Store and Google Play each have review processes, and every release goes through them again;
• Dual-platform upkeep. Some customers use iPhones, some Android — both have to be maintained;
• The download hurdle. Making a customer search a store, download, and register loses someone at every step;
• Long-term maintenance. An app nobody updates and that can’t adapt to new OS versions turns from an “entry” into “bad reputation.”

A PWA (Progressive Web App) is different. It is a web page at heart, but it can be “added to the home screen” like an app: a customer opens it once in the browser, taps “add to home screen,” and gets an icon — next time they tap it like an app. And it:

• needs no listing and no review — changes take effect immediately;
• runs on one codebase across every platform — iPhone, Android, and desktop;
• costs far less than an app — a realistic choice for a small regional company;
• fully covers the core scenario — the customer finds the company again, fast.

For a home-repair business, the PWA is not a cheap substitute for an app. It is the exactly-right answer.

How the repeat-customer entry is built

The phase-two PWA does three things only:

1. Add to home screen. After service, the technician or staff guides the customer to open the company page and tap “add to home screen.” Next time the customer needs anything, the icon on the home screen is one tap away — no searching, no scrolling through chats, no trying to remember the company name.
2. One simple re-book entry. In the PWA, it’s the same quote-request form from phase one — the customer describes the new problem and picks a time. Repeat customers learn nothing new; the interface is identical to the website they already used.
3. An “I’m a returning customer” signal. The PWA remembers who the customer is, so describing the problem takes fewer fields next time — the customer feels taken care of, and the company knows a regular has come back.

The post-service notification: the start of the loop

The PWA’s other capability is notifications. This goes further than a mere “entry”: after service is done, the company uses the PWA to send a notification to the customer, inviting feedback on this service — whether the technician was on time, whether the problem was fixed, whether the quote was fair.

This step turns “waiting for the customer to come back” into “staying in the customer’s life actively”: the end of the repair is not the end — it is the start of the next service relationship. How feedback becomes a loop is the full subject of Part 5.

What this phase was deliberately not

• Not a native app. The reasons are above — the PWA is the right choice between cost and experience;
• Not a dispatch scheduling system. The PWA faces customers, not technician scheduling;
• Not a full customer-account system. No loyalty points, no tiers, no login/password system — “remembering you’re a returning customer” is enough; customers aren’t dragged into complex accounts;
• It doesn’t solve new-customer acquisition. New customers still come through the website, maps, LINE, and word of mouth; the PWA is a re-discovery entry for customers already served.

How the PWA is judged a success

After the PWA has run a while, the company looks at three things:

• Do returning customers re-book through the PWA — the most direct proof the entry is being used;
• Are the post-service notifications opened and answered — whether the loop has actually started turning;
• Are the technicians and staff willing to naturally guide customers to add to home screen — if this becomes an awkward sales pitch, the entry breaks.

Part 5 is about how feedback becomes the lifeline: the service, feedback, improve, re-discovery loop, and how technicians view “feedback will be tied to me.”

---

Boundary matters: the PWA repeat-customer entry and post-service notifications in this phase are the company’s phase-two independent project, outside standard website-package scope, and face returning customers rather than replacing new-customer acquisition. Dispatch scheduling, online payment, customer-account systems, and CRM remain separate systems and do not become part of a standard website package by appearing in this case.