A spa chain goes digital, part 1: from scattered store info to a first chain website

This series follows one multi-branch spa chain through several phases of going digital. The journey is built from real implementation experience in this industry — the stages and challenges should feel familiar if you run this kind of business. Each part covers what was built, what was deliberately not built, and what evidence justified moving to the next phase.

Where the chain started

The owner runs three massage branches with overlapping services but slightly different prices, hours and treatment menus. Business was steady, but the owner could not be in every store, and the information customers saw was inconsistent:

• Prices and hours lived per store. Six months earlier the owner had found a second branch advertising the first branch’s old price list. Nothing pointed to malice — the poster just copy-pasted from memory.
• Services were explained one chat at a time. Each branch’s receptionist re-typed the same menu, duration and availability questions on LINE, and the answers drifted from branch to branch.
• There was nowhere to look a branch up. Google showed scattered map pins and old photos, with no single place a new customer could trust.
• Feedback was invisible. Satisfied and unhappy customers both left comments in LINE, on Google, or just walked out. The owner, in another district, rarely heard about a problem before a customer stopped returning.

The first visible bottleneck was an information and ownership problem: the chain existed in reality but not as a single, controlled digital identity. It could not yet collect comparable feedback across stores because there was no common public foundation to anchor it.

One thing worth being honest about from the start: the owner already knew the long-term picture. A chain like this eventually needs booking, staff scheduling, customer records and review analytics — that need existed on day one, not at some future stage. The question the whole series answers is not “when does the need appear?” but “given the full need already exists, why build in this order?”

What phase one actually was

The first website had exactly four jobs:

1. A chain page — who the chain is, how many branches, how long it has operated, photos of the branches. This is what a first-time visitor checks to decide the chain is real.
2. One page per branch — address, phone, hours, location map, and what is specific to that store, so a customer can pick a branch instead of guessing.
3. One shared services section — the treatment menu and duration written once, properly, instead of re-typed per chat. This single shared reference replaced the most-repeated, most-drifted conversation in the chain’s history.
4. A page preparing the visit — how booking works today (LINE or phone), what to bring, deposit and cancellation expectations, and a contact form for general questions.

Every page ends the same way: a LINE button and a phone number for that branch. The website’s job is to prepare the conversation and make the chain legible, not to replace how each store runs its day.

What phase one deliberately was not

This is the part most first projects get wrong, so it deserves its own list. Phase one had:

• No online booking. Appointments kept working the way customers already trusted: LINE or a phone call with a human confirmation.
• No online payment or deposit capture. Payment, and whether a deposit was taken at all, stayed a per-store decision handled in person.
• No customer accounts, no staff scheduling backend, no review analytics — yet. Not because the needs weren’t real, but because nobody could yet say what such systems should manage: which data matters, who owns each step, which exceptions break the flow.
• No premium online booking engine. The chain was not ready to lock live availability into software while its real turnaround and no-show rules were still unwritten.

“Not yet” is not a downgraded goal, and it is not a claim that these needs don’t exist. It is what kept the project small enough to finish, gave staff a change they could absorb, and left the next decisions to be made with real data instead of guesses.

What moving to phase two would require

The chain already had a longer roadmap. Before authorizing the next build, it agreed to watch both operating evidence and staff readiness:

• Hotline-style questions (“do you offer X? what time are you open?”) that a shared services page could answer automatically;
• How much each branch’s receptionist re-typed the same treatment info, and how often the answers disagreed;
• Whether customers could reliably reach a branch from the website, and whether branch info stayed accurate;
• Whether the owner could not see customer satisfaction across stores — the gap that would justify the next high-value slice.

Part 2 looks at why the owner did not build full booking or a CRM next, and instead chose customer feedback as the first data slice to build.

---

The boundary matters: the chain website, shared services pages and a general contact/enquiry form above can be part of the agreed website scope. Booking engines, online payment, customer accounts, staff scheduling and review analytics in later parts are separate system projects with their own scope — they are not included merely because the process starts on the website.