A boutique aesthetic clinic goes digital, part 3: converging scattered consultations into trackable requests

This series follows one boutique aesthetic clinic 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.

The problem with midnight chats

The website was working. The physician, clinic and equipment pages were being read, and the form caught some requests. But the receptionist was still living in LINE, and this is where the real consultation volume lived and disappeared.

A patient at midnight asks: “How much for cheek fillers, is it safe, can I see the doctor first?” The receptionist answers, the chat drifts, and three days later nobody can say whether that person came in or vanished. The request existed — a real consultation signal — but it lived inside a private chat thread that nobody counted and nothing tracked.

The clinic knew what it wanted: a way for every consultation request, from any channel, to land in one place with a minimal record: who, which treatment, which channel, and what happened next.

What was built

The build was deliberately small, built on surfaces that already existed:

1. A structured consultation form on the website. Instead of a free-text box, it asked: treatment of interest, time preference, and how they heard about the clinic. The form fed straight into one request list — no human re-typing.
2. A LINE fallback that stays in one place. Patients who preferred LINE were gently invited to use the form once, but nothing forced the switch. Requests that still came by chat were logged into the same list by the receptionist — a few seconds, not a workflow.
3. One request list as the source of truth. Every request, whatever its channel, became a row: date, channel, treatment, and an open “what happened next” status that the receptionist updates.
4. A simple weekly read. The founder and receptionist spent ten minutes a week looking at the list, not a dashboard. What matters at this stage is seeing the shape of the requests, not a chart.

Nothing about this asked the receptionist to maintain a full customer record. It only recorded what was already happening, once, in one place.

What the list immediately revealed

Within the first month, the clinic saw things it had never seen:

• The midnight questions had volume. Dozens of consultations a week had been happening invisibly in LINE. The clinic’s real interest level was far higher than its booking numbers suggested.
• The form converted attention into requests. Visitors who reached the consultation entry left requests at a rate the founder had not expected — because the form let them ask a question without committing to a call.
• Most requests were asking, not booking. The gap between “asked about” and “came in” was the clinic’s real bottleneck, and it was now visible for the first time.
• Some questions repeated mechanically. The same “is it safe / what’s the price / can I see the doctor” questions appeared over and over — a list of what a future entry point should answer automatically.

The value here was not a booking. It was a decision signal: the clinic could finally see how much interest existed, where it came from, and where it leaked.

What this phase deliberately was not

To be explicit, this phase had:

• No booking engine and no live availability. Appointments still required a human confirmation, because the clinic had not yet decided same-day, deposit and cancellation rules.
• No CRM and no patient accounts. The request list was not a patient database; it carried no medical history and no consent workflow beyond what the clinic already had.
• No auto-reply chatbot. The form collected the repeated questions, but answering them still happened by hand. Automating that would come only after the questions proved stable.
• No online payment or deposit capture. Whether a deposit was taken stayed a per-case decision handled in person.

The evidence that would justify phase four

The clinic wrote down what to watch next:

• Whether the request list stayed accurate as the receptionist’s habit, rather than a chore she resented;
• Whether the weekly read actually changed a decision (channel, pricing or timing) instead of just being a report;
• Whether the gap between “asked” and “came” was being narrowed by any single change the list made visible;
• Whether staff could name who follows up and what “done” looks like for a request.

For this scenario, assume the list became the clinic’s working reference and the gap between consultation and visit stayed the sharpest number in it. Part 4 covers the quieter, harder part: turning the request list from a record into a follow-up habit that actually converts consultations into visits.

---

The boundary matters: the clinic website, a structured consultation/enquiry form, and a simple request log maintained by the clinic can be part of the agreed website scope. Booking engines, live availability, CRM, patient accounts, medical records, deposit capture and online payment in later parts are separate system projects with their own scope — they are not included merely because the process starts on the website.