W WOW Studio CRM · UI Prototype GMT+8 ·

Phase 5 · Review with branch admins

One session of about 90 minutes with the branch admins, the Owner (for salary sign-off) and one teacher with a phone. Walk the screens in the order below, then settle every decision item. Nothing here changes the prototype; the decisions go back into requirements.md.

Reviewed 2026-09-07 22:42 GMT+8Alvin stood in for the branch admins. 8 items confirmed, 8 changed, 4 left open; one new requirement (audit log). The outcome is pre-filled below, written into requirements.md §10 and §11, and the "Change" decisions are already applied to the prototype. You can still re-run the checklist with the real branch admins: change any row and copy the Markdown out again.

How to run it

  1. Serve the prototype and open the hub: python -m http.server 8765 --directory prototype, then http://localhost:8765/. A projector for the admin screens, a phone or the phone frame for the teacher portal.
  2. Use the top-right menu on any admin screen to view as Super Admin, Owner, Branch Admin or Operator. Role-gated buttons (Fee Run, Salary Run, Owner sign-off) appear and disappear; ask the room whether that matches who does the work today.
  3. Follow the walkthrough script. For each screen the question is the same: does this screen let the person do the job the way the studio actually works? Wording, colours and layout can wait; missing fields, wrong rules and wrong owners cannot.
  4. Record decisions in the checklist below (kept in this browser). Copy them out as Markdown at the end.

Walkthrough script

Mock data is Kuala Lumpur, week of 2026-09-07. Roughly 5 minutes per row.

ModuleOpenWhat to check with the room
Dashboarddashboard.htmlAre these the numbers a branch admin looks at on Monday morning? Is the "needs your action" list the right list? HQ consolidated view for Super Admin and Owner.
CRMcrm-leads.html → lead detail → convert wizardPipeline stages, sources, follow-up log. Trial booking free vs paid. Convert wizard creates Customer, Student, optional Parent, Enrolment and first invoice in one go: is that the real order of events at the front desk?
Timetabletimetable.html, year, class detailWeek by room vs by teacher. Holiday on class day is shifted, never skipped: confirm with 2026-09-16. Term break shown as dates 29–31 (decision A2). Chargeable flag on per-slot products.
Room bookingroom-availability.html30-minute cells, 1-hour minimum, deposit locks the booking, refund window 48 h. Tentative bookings do not block (decision A5).
Attendancepending-work.html, credits24-hour rule and marking on behalf. Credit rules: informed 24 h before, or proof. Half credit for a 30-minute extension. Reset on 1 January.
Products, enrolmentproducts.html, enrolmentsSyllabus (fixed monthly) vs per-slot pricing. Discount codes admin-only and bound to products. Freeze, extend, transfer between siblings.
Billinginvoice-new.html, overduePer-customer multi-line invoice, branch number plus global ID, open-amount line with remark for pro-rating, void with reason.
Fee Runfee-run.htmlFrom/To, Calculate Fees, the four buckets, Checking Table decisions (confirm, pick other, mark unpaid, leave open). Who presses the button and when in the month.
Salarysalary-run.htmlsheetpayoutDraft → Confirmed → Signed off by role (switch to Owner to see sign-off). Flagged unpaid students at RM 0 on per-head rates, full pay on flat rates. Pending-attendance block. Rule bound at engagement.
Settingssettings.htmlYearly calendar per branch entered by hand in December. Thresholds (24 h chargeable, 24 h attendance). Invoice numbering. Teacher-branch links and contact visibility.
Teacher portalt-home.html on a phoneHand the phone to the teacher: mark today's class, mark a pending one, find a student, read the statement. Watch where they hesitate. Switch to Mr Daniel Raj for the two-branch case.

Decisions

Every assumption made while building Phases 2–4, plus questions that came up during the build. Pick Confirm, Change or Drop and add a note; the state is kept in this browser.

After the review

  1. Paste the Markdown into requirements.md: update the affected sections, replace the assumption lists in section 11 with the decisions, add a Change Log row with the review timestamp.
  2. Apply any "Change" decisions to the prototype so the build team sees the agreed behaviour, not the assumption.
  3. Tick Phase 5 in section 11 and hand over: requirements.md, the prototype folder, and a short build brief (data model from the mock data, screen-to-section traceability). Steps 1–2 and the tick are done as of 2026-09-07 22:42; the build brief is Phase 6.