PRD 00 · Overview and architecture

Proposed design

This set is the shell every other PRD sits in: one top bar with the branch switcher, one sidebar shared by every module, and a Dashboard whose content changes with the signed-in role; parents and teachers get their own mobile surfaces instead of reusing the sidebar.

1 · Application shell · owner dashboard

/dashboard · desktop

2 · Branch switcher and data scope

/dashboard · desktop

3 · Role-based home · branch manager

/dashboard · desktop

4 · Role-based home · accountant

/dashboard · desktop

5 · Parent portal

/parent · mobile

6 · Teacher today

/teach · mobile

1Product vision

Trường Số (truongso.net) is FLYER's operating system for English centers and small private schools in Vietnam. It starts from the admissions CRM that exists today at b2c.truongso.net and grows into the daily tool for the whole center: the receptionist who enrolls a child, the academic admin who builds the timetable, the teacher who marks attendance on a phone, the accountant who collects tuition and chases debt, and the owner who reads one dashboard across branches.

The competitive baseline is the category of Vietnamese center-management suites (PSE ONE and peers) that advertise seven modules: admissions, students, training, reports, inventory, finance and the parent contact book, sold per student tier from roughly 199,000 to 1,000,000 VND per month. Trường Số covers the same operational surface, but with three differences that the market leaders do not have:

1. Learning data inside the operations record. Every student is a FLYER learner. Placement scores, assigned homework, completion rates and AI-graded speaking and writing results already exist in the FLYER platform and appear in the student profile without integration work.
2. Money flows through verified bank transfer. The existing SePay bank-account link and payment QR make receipts self-reconciling; cash is the exception, not the default.
3. One design system. The Cloud theme used across FLYER teacher products is the UI language, so a center that already uses teacher.flyer.us recognises every screen.

Success measures (12 months after P1 launch)

2Personas

3Multi-branch tenancy

The existing backend already has two containers: the CRM Center (center_id, string id, created at onboarding) and the FLYER School (school_id, int64, the unit that owns classes, students, tuition and teacher membership). The CRM Customer carries both ids, and GET /v3/crm/me/accessible-schools already returns several schools per CRM user.

4Roles and permission matrix

The CRM already has tenant-defined roles with a permission catalog (GET /v3/crm/permissions-catalog, codes grouped by module) and per-user scope own | team | all. School membership uses the fixed SchoolRole enum OWNER / ADMIN / TEACHER. Decision D2: one role catalog. The CRM role model is extended with the new modules' permission codes; school membership role is derived (teacher flag, admin flag) when a Trường Số role is assigned, so the FLYER teacher apps keep working.

Default roles shipped with every tenant (cloneable, not deletable):

The full code list per module is in each PRD's Permissions section and consolidated in PRD 10.

5Information architecture and navigation map

The current sidebar shows Tổng quan, Khách hàng, Nhập dữ liệu and Cài đặt trung tâm. The constants file already declares routes for students, classes, attendance and tuition with Vietnamese nav labels, grouped as Tổng quan / CRM & Hiệu suất / Quản lý trường học / Tài chính / Cài đặt. The target navigation keeps that grouping and adds the new modules.

Route prefix note: existing CRM routes stay under /crm/* so links in notifications and bookmarks keep working. New modules live at the root (/students, /classes ...) inside the same (dashboard) layout. Settings consolidates under /settings with a redirect from /crm/settings/*.

Object model at a glance

6What exists today versus what the PRDs add

Known inconsistencies to resolve in P1

• Two PermissionGate implementations; the stub in src/components/crm always allows. Remove the stub.
• Permission scope vocabularies differ: matrix editor uses none/read/write/manage, /me/permissions returns own/team/all. PRD 10 fixes the vocabulary to own | branch | all plus action codes.
• Placement-test status labels in i18n (scheduled) do not match the API enum (not_started, in_progress, completed, cancelled).
• Endpoints referenced in the frontend but absent from the spec: customers/{id}/convert, do-not-call, transfer-school, tasks, meetings, saved-views, users/{id}/school-access. PRD 01 and 10 specify the replacements.
• Several settings and form bodies are hard-coded English; all strings move to vi/en message files.

7Phasing

8Decisions to ratify

1. D1 Tenant = Center, Branch = School (section 3).
2. D2 One role catalog extending CRM roles; school role derived (section 4).
3. D3 Lists over boards: the pipeline keeps its Kanban as an option, but every new module ships a table view first and no board.
4. D4 The enrolled student is the FLYER learner profile; conversion always creates or links a learner account so learning data is attached from day one.
5. D5 Sessions are materialised rows generated from the class schedule, and attendance and timesheets hang off sessions, not off the schedule template.
6. D6 Finance reuses the Tuition and GroupInvoice models; session packages are a fee plan type, and the student session balance is a maintained summary.
7. D7 Guardians are contacted through Zalo ZNS first, in-app second, email third; SMS is not built.
8. D8 Existing CRM routes stay under /crm; new modules are root routes in the same shell.
9. D9 Vietnamese is the product language; English is a full second locale from day one, and all strings live in message files.
10. D10 Inventory, staff pay and e-invoice are phase 2; phase 1 ships the daily loop of enroll, schedule, attend, collect, report.