A training center goes digital, part 1: from scattered course info to a first trustworthy website

This series follows one training center 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 school. Each part covers what was built, what was deliberately not built, and what evidence justified moving to the next phase.

Where the center started

This is a small language-and-skills training center that teaches in classes, with both in-person and online students. Classes ran and students kept coming, but the owner could name three things quietly eating up staff time:

• The same enquiries kept repeating. New students and parents asked the same things on LINE, over and over: what courses do you run, what time are classes, how much, how do I enroll, is there level placement. Admin answered, teachers answered, and the answers drifted.
• Enrollment and payment had no clean trail. Enrollment happened inside chats, payment was a mix of transfers and cash, and placement ran on paper and Excel at the front desk. Asked how many students this term actually enrolled and where they came from, the owner could only guess.
• Writing tests and answering questions consumed teachers. Every term’s test was written by hand, and after-class questions surfaced in chats with no system — whoever was online answered. This was not a need that appeared one day; it existed from day one.

But the owner also knew the thing most missing right now was not a system, and not AI. It was: let a stranger who has never heard of this school, on their phone for the first time, quickly decide “this is real, the course fits me, and I know what to do next.”

What phase one actually was

The first website had exactly four jobs:

1. A course overview — what courses the school runs, what each one teaches, who it is for, how long a term lasts. This is what a first-time visitor checks to decide the school is real.
2. One page per course — class hours, schedule, fees, teachers, whether there is level placement, written once and clearly. This replaced the text that admin and teachers re-typed in chats every day with a single reference that stays valid long-term.
3. An enrollment and enquiry flow page — how to enroll, how to pay, term start dates, make-up and refund rules, plus an entry where a student can “leave details and wait for a reply.”
4. An address and contact page — where the classroom is, how to get there, and the LINE and phone numbers. In-person students most need this.

Every page ends the same way: a LINE button or a phone number. The website’s job is to prepare the conversation and make the school legible, not to replace how it runs its day.

What phase one deliberately was not

This is where most first projects go wrong, so it deserves its own list. Phase one had:

• No online enrollment system. Enrollment kept working the way students already trusted: LINE or a phone call with a human confirmation.
• No online payment. Payment stayed at the counter, by transfer, or with a human confirmation, and each term’s rules stayed as they were.
• No student login portal. No profile, no schedule, no homework, no grades — not yet. Not because these needs weren’t real, but because nobody could yet say what such a system should manage: which data matters, who updates it, which exceptions break the flow.
• No AI test generation, no online Q&A. The portal did not even exist yet, let alone an AI plugged into it. “Not yet” is not a downgraded goal and it is not a claim that the needs don’t exist. It is what kept this phase small enough to finish, gave admin and teachers only a little to absorb, and left the next decision to real data instead of guesses.

What moving to phase two would require

The center already had a longer roadmap. Before authorizing the next build, it agreed to watch two things:

• Whether, with unified course pages live, the hotline-style enquiries on LINE (“do you run X? what time is class?”) actually dropped;
• Whether admin and teachers were still re-answering things the pages already answered — which decides whether to move to the next step: converging enquiries into trackable enrollment data.

Part 2 looks at why the owner did not build a learner portal or AI next, and instead chose to converge enquiries and enrollment into a trackable trail.

---

The boundary matters: the school website, course info pages and an enrollment/enquiry entry point are a normal website project. The learner login portal, online testing, AI test generation and online Q&A in this series are separate system projects with their own scope — they are not part of a standard website package, and the AI features in particular are a later phase plugged in over an API.