What Should a Hong Kong Business Do After the Software Goes Live?

The morning after launch

A tutorial centre in Kowloon Bay switched its Saturday timetable off a shared spreadsheet and onto a booking site last Friday. On Saturday morning the first parent tried to book a Primary 4 English class and the slot was already full. The receptionist still answered WhatsApp, and the tutor still walked in with a printed list. The site was live. The work was not.

After launch the owner still has four jobs. Name who may change a class. Decide what a late FPS payment does. Choose which language the confirmation uses. Decide who reads the dashboard before the first lesson. Leave one of those with nobody on it, and the spreadsheet is back by the second weekend.

Who is allowed to change a class?

Write the rules before the first complaint, not after it.

Three people at this centre touch the timetable. The owner sets term dates and fees. The receptionist moves a student when a parent messages. The tutor only needs the names in the room. If all three can edit every field, Saturday morning has three versions of one class. If only the vendor can edit, a sick student means waiting on a message thread.

Decide it as a short list and stick it next to the login:

• The owner can open or close a class, change the cap, and refund.
• The receptionist can move a student between classes in the same course, and cannot change the fee.
• The tutor can mark attendance, and cannot see phone numbers they do not need for the lesson.

Check it this week by asking each person to do one task they should be blocked from. If the tutor can export the whole parent list, the rule is not in the product yet.

What does the parent receive, in which language?

Hong Kong parents do not all read the same confirmation. One books in Chinese at 11pm from a phone. Another books in English because the child studies in an English-medium school. A third never opens email and will only trust a WhatsApp message.

The centre picked one rule: the confirmation goes out in the language the parent used to book, and a short WhatsApp follows with the date, the room, and the amount. The email is the record. The WhatsApp is how they actually look. Do not send both languages in one block. Parents skim, and a bilingual wall of text gets read as neither.

Walk through one real booking yourself. Book a class in Chinese, then one in English. Check the name order, the address, and the time. "3:00" is not enough when the centre runs a 3pm class and a 3:15pm class in rooms next to each other. Write "3:00–4:30pm, Room B" in both versions.

Who checks the money before Monday?

FPS is how most of these parents pay. It is also where the record and the bank disagree.

A parent books on Sunday night and pays on Monday by FPS from the other parent's account. The site still says unpaid, because the payer name does not match the student. Somebody has to match the bank receipt to the booking before the child arrives, or the tutor does not know whether the seat was paid for.

Pick one person and one time. At this centre it is the receptionist, every Monday before the first lesson, with the FPS receipt list and the unpaid filter open side by side. Three outcomes only:

• Name and amount match: mark paid.
• Amount matches, name does not: message the parent on the same WhatsApp thread and attach the booking number.
• No receipt: the seat holds until noon, then it opens for the waiting list.

Do not leave "we will sort it in the office" as a status. A status nobody can filter is how unpaid seats sit there for a month.

What do you look at before you change anything?

Before the owner adds a class or hires a Saturday tutor, they need the same four numbers in the same place.

For this centre those four are: classes that filled, classes under half full, students who missed two weeks in a row, and payments still open from last week.

Open the dashboard on a Tuesday. If a number takes more than a minute to find, it is in the wrong place. If a number is missing, write it down and ask for it once. Do not start a second spreadsheet "just for this month".

What do you fix in the first month, and what do you leave?

The first month surfaces real use, not design opinions. Keep a single list. Anything a parent or a receptionist hit twice goes on it. Anything one person disliked once does not.

Worth fixing in the first month at a centre like this:

• A parent could not tell two Saturday classes apart because the course names were the internal codes.
• The Chinese confirmation cut off a room name that was fine in English.
• The receptionist could not find unpaid bookings without exporting a file.

Leave it alone:

• A tutor who wants the attendance buttons in a different colour.
• A new report nobody has opened twice.
• A second payment method because one parent asked, while FPS already covers the rest.

Take the list to the vendor as jobs, not as a mood. "Reception cannot filter unpaid bookings from this week" is a job. "The system feels a bit messy" is not.

What you still do, even when the site works

The site will take the booking, send the note, and hold the seat. It will not offer a waiting parent the Wednesday class, call the student who missed two weeks, or notice that Room B is double-booked because a course ran long. Name who makes those calls before Saturday. If the name is missing, the call falls to whoever picks up the phone.