Content cho sản phẩm — marketing tự rà soát và cập nhật teacher.flyer.us

1Vấn đề và mục tiêu

Nội dung mà giáo viên nhìn thấy trên teacher.flyer.us hiện nằm ở bốn nơi, với bốn cách sửa và bốn mức lịch sử khác nhau. Bảng dưới đây được đối chiếu trực tiếp với mã nguồn partner-web, cơ sở dữ liệu production và admin.flyer.vn ngày 10/09/2026.

Trang giới thiệu khi chưa đăng nhập có tài liệu riêng: PRD trang giới thiệu teacher.flyer.us. Nội dung học liệu (đề, chương trình, video) thuộc đội Academic và không nằm trong phạm vi này.

Ba hệ quả đo được

• Sửa chữ phải “đi nhờ” commit của dev. Trong 90 ngày qua có 100 commit chạm vào file nội dung, nhưng chỉ 2 commit là thuần sửa nội dung. Mọi yêu cầu đổi câu chữ của marketing đều xếp hàng sau việc lập trình.
• Không ai nhìn được toàn bộ nội dung ở một chỗ. 6.515 chuỗi rải trong 120 nhóm của riêng common.json; muốn biết màn hình Gói dịch vụ đang viết gì phải mở mã nguồn.
• Không có ngày cập nhật cho từng mục và không có bước duyệt. Popup thì sửa là lên ngay, không giữ bản cũ; chuỗi giao diện thì có bản cũ trong git nhưng marketing không truy cập được.

Mục tiêu: một nơi liệt kê 100% nội dung sản phẩm, marketing tự rà soát và đề xuất sửa, PM duyệt, hệ thống giữ lịch sử từng mục (ai, khi nào, bản cũ, bản mới, lý do), và bản đã duyệt hiển thị trên production trong vòng một ngày mà không cần build lại mã.

2Giải pháp tổng quan

Xây một Kho nội dung (content registry) gom cả bốn lớp thành một danh sách phẳng. Mỗi mục có mã, màn hình xuất hiện, ba ngôn ngữ, trạng thái, ngày và người cập nhật gần nhất, và dòng lịch sử. Luồng làm việc duy nhất cho mọi lớp:

Ba nguyên tắc thiết kế:

1. Mã nguồn vẫn là gốc, kho chỉ ghi đè. Không đưa nội dung ra khỏi git; dev vẫn làm việc như cũ. Kho giữ một lớp override phủ lên trên, và tự thu hồi khi dev đã đưa bản mới vào mã.
2. Mọi thay đổi đều có bản cũ. Không có thao tác nào ghi đè mà không lưu phiên bản trước; khôi phục về bất kỳ phiên bản nào bằng một thao tác.
3. Danh sách phẳng, lọc theo màn hình. Công cụ nội bộ dùng bảng và bộ lọc, không dùng bảng kéo thả.

Kho được triển khai theo hai phần: Phần A chạy ngay bằng Google Sheet và một script, không cần dev, để đo nhu cầu thật của marketing trong bốn tuần; Phần B xây màn hình trong admin.flyer.vn nếu Phần A chứng minh được giá trị.

3Hành động ngay — không chờ hệ thống mới

Đội marketing đã dùng Google Sheet để đề xuất sửa nhãn nút và nội dung popup. Phần còn thiếu chỉ là đường đưa những đề xuất đó lên production. Khảo sát mã nguồn ngày 10/09/2026 cho thấy hạ tầng cần thiết đã có sẵn trong sản phẩm, chia làm hai nhóm với hai mức sẵn sàng khác nhau.

3.1 Nội dung popup — đã làm được ngay hôm nay, không cần dev

Hai bảng version_notifications (69 bản) và menu_notifications (29 bản) đã có màn nhập trong admin.flyer.vn, và marketing đang thao tác trực tiếp trên đó: lịch sử sửa ghi nhận linhpham 31 lần, nghiepbv 20 lần, kallie 5 lần, uyenemma 4 lần. Nội dung lưu ở cơ sở dữ liệu nên hiển thị ngay sau khi lưu, không qua build.

Ba việc cần bổ sung, làm được trong tuần mà không cần lập trình:

• Dán bản cũ vào tab Nhật ký của sheet trước khi ghi đè. Bảng hiện chỉ lưu người sửa lần cuối, không giữ phiên bản trước.
• Bật lại các popup theo menu. Toàn bộ 29 bản đang tắt từ 06/08/2026; cần rà lại nội dung rồi quyết định bật hay bỏ.
• Cấp quyền admin cho người còn thiếu trong đội marketing, để không phải nhờ người khác thao tác hộ.

3.2 Nhãn nút và chữ trong giao diện — cần đúng một thay đổi nhỏ

Đây là nhóm đang phải chờ release. Điểm mấu chốt tìm được: sản phẩm đã tích hợp sẵn Firebase Remote Config và đang chạy trên production.

Nghĩa là đã có sẵn một kênh đẩy dữ liệu từ ngoài vào ứng dụng đang chạy. Việc còn lại là nối kênh đó vào lớp ngôn ngữ.

3.3 Thay đổi cần làm

Thư viện next-translate 3.1.1 cho phép lồng I18nProvider, và bản lồng bên trong ghi đè lên bản bên ngoài. Vì vậy chỉ cần thêm một thành phần đọc giá trị từ Remote Config, trộn lên bộ chuỗi hiện có, rồi bọc quanh nội dung trang.

3.4 Thứ tự đề nghị

1. Tuần này: chốt phạm vi được phép sửa qua kênh này. Đề nghị giới hạn ở nhãn nút, tiêu đề, mô tả gói và chuỗi cẩm nang; loại trừ thông báo lỗi và chuỗi có biến nội suy.
2. Tuần này: áp dụng ba việc ở mục 3.1 cho nhóm popup.
3. Tuần sau: dev làm thay đổi ở mục 3.3, thử với đúng một chuỗi trước, ví dụ partner_package.plan_desc_1 đang ghi “hơn 6000 đề” trong khi trang giới thiệu và email đã dùng số 20.000.
4. Sau khi chạy ổn hai tuần: quyết định có xây màn quản lý ở Phần B hay giữ nguyên sheet cộng Remote Config.

4Phần A — quy trình trên Google Sheet

Đội marketing đã dùng Google Sheet cho việc đề xuất sửa. Phần này chuẩn hoá lại sheet đó để phủ đủ 6.515 chuỗi và nối được với kênh phát hành ở mục 3.

A1. Xuất toàn bộ nội dung ra một Google Sheet

Script đọc 16 file JSON của ba ngôn ngữ, gắn mỗi chuỗi với màn hình bằng bảng route → namespace sẵn có trong i18n.js (ví dụ /program → program.json, /flyer-ai → flyer_ai.json, /tuition-management → tuition_management.json) và nhóm cấp một trong common.json (partner_package, home_new, user_guide…). Kết quả là sheet “Kho nội dung teacher.flyer.us”:

A2. Marketing rà soát trên sheet

Lọc theo cột Màn hình để rà từng khu vực. Sửa chữ ngay trong ô VI/EN, đổi trạng thái sang “Đề xuất sửa”, ghi lý do. Google Sheet giữ lịch sử phiên bản của từng ô, nên yêu cầu “ghi lại ngày cập nhật” được đáp ứng mà không cần xây gì thêm.

A3. Nhịp duyệt hằng tuần

• Thứ Tư: PM lọc các dòng “Đề xuất sửa”, duyệt hoặc trả lại (ghi vào cột Lý do).
• Thứ Năm: script đọc các dòng “Đã duyệt”, ghi ngược vào file JSON, mở một pull request duy nhất content: tuần 38. Dev merge cùng release gần nhất.
• Script đồng thời ghi một dòng vào tab Nhật ký: mã, bản cũ, bản mới, người đề xuất, người duyệt, ngày lên production.

A4. Popup và trung tâm trợ giúp

Giữ nguyên admin.flyer.vn và GitBook. Sheet có thêm tab Popup & Help liệt kê 69 popup phiên bản, 29 popup theo menu và 35 bài help kèm link và ngày sửa gần nhất, để marketing rà soát cùng một chỗ. Khi sửa popup trên admin, marketing dán bản cũ vào tab Nhật ký trước khi ghi đè.

5Phần B — Kho nội dung trong admin.flyer.vn

Xây khi Phần A cho thấy nhu cầu ổn định (gợi ý: từ 20 đề xuất mỗi tuần trở lên, hoặc thời gian chờ lên production là điểm nghẽn chính).

4.1 Vị trí và phân quyền

Mục Nội dung sản phẩm trong admin.flyer.vn, đặt cạnh mục Thông báo hiện có (nơi popup đang được sửa). Ba vai trò:

4.2 Màn hình danh sách

Một bảng phẳng, mỗi dòng là một mục nội dung. Bộ lọc: màn hình, ngôn ngữ, trạng thái, ngày sửa, người sửa; ô tìm kiếm theo chữ hoặc theo mã. Nút Mở trên sản phẩm nhảy tới đúng trang teacher.flyer.us nhờ bảng route → namespace.

Mô phỏng bố cục màn hình danh sách; số liệu trong bảng lấy từ production ngày 10/09/2026.

4.3 Sửa một mục

• Panel bên phải hiển thị bản đang chạy, ô sửa cho từng ngôn ngữ, và ô lý do. Bản EN/ES để trống thì giữ nguyên bản hiện tại.
• Xem trước với biến thật ({{name}}, {{count}}) để tránh vỡ cú pháp nội suy.
• Cảnh báo khi bản mới dài hơn 120% bản cũ, vì nhãn nút và tiêu đề có thể tràn khung.
• Một mục có thể đang được dùng ở nhiều màn hình; panel liệt kê tất cả nơi dùng trước khi cho gửi duyệt.

4.4 Duyệt và phát hành

PM thấy hàng chờ, so sánh bản cũ và bản mới cạnh nhau, chọn Duyệt hoặc Trả lại kèm ghi chú. Phát hành ghi bản ghi đè lên kho phân phối; ứng dụng nạp bản mới trong tối đa năm phút, không cần build. Có nút Phát hành thử cho tôi để người duyệt thấy bản mới trên tài khoản của người duyệt trước khi phát hành cho tất cả.

4.5 Lịch sử

• Mỗi mục có dòng thời gian: phiên bản, người, thời điểm, lý do, và nút khôi phục về phiên bản bất kỳ (khôi phục tạo phiên bản mới, không xoá lịch sử).
• Trang Nhật ký toàn hệ thống lọc theo tuần, người, màn hình; xuất được ra sheet để báo cáo.
• Khi dev đưa bản mới vào mã nguồn, kho ghi thêm một phiên bản “từ mã nguồn” để lịch sử không bị đứt đoạn.

4.6 Popup và trung tâm trợ giúp trong cùng danh sách

Hai bảng version_notifications và menu_notifications được đọc và ghi qua các mutation đã có của admin; kho chỉ thêm lớp lịch sử và bước duyệt. Bài trên help.flyer.vn được liệt kê kèm ngày sửa từ GitBook, có thể gắn với màn hình tương ứng để marketing thấy chỗ nào của sản phẩm đang thiếu bài hướng dẫn.

4.7 Đồng bộ với mã nguồn

Một tác vụ đọc nhánh dev mỗi giờ. Mục mới trong JSON được gắn nhãn Mới — chưa rà; mục đã xoá khỏi mã được gắn Đã xoá khỏi mã và bản ghi đè của nó tự vô hiệu. Nếu dev sửa chính chuỗi đang có bản ghi đè, kho báo xung đột cho PM chọn giữ bản nào.

6Cơ chế kỹ thuật

Rủi ro cần xử lý trong thiết kế chi tiết: chuỗi chứa HTML hoặc biến nội suy (kiểm tra cú pháp trước khi phát hành); một khoá dùng ở nhiều màn hình (hiển thị mọi nơi dùng); xung đột khi dev và marketing cùng sửa một khoá (quy ước bản ghi đè có hiệu lực cho đến khi dev merge và kho tự thu hồi); tiếng Tây Ban Nha hiện dùng bản EN khi thiếu khoá, cần giữ nguyên hành vi đó với lớp ghi đè.

7Lộ trình

8Chỉ số thành công

9Câu hỏi mở

1. Người duyệt cuối là PM hay trưởng nhóm marketing? Có cho phép marketing tự phát hành với các mục không phải nhãn nút và tiêu đề chính không?
2. teacher.teado.ai dùng chung mã nguồn: một kho chung với cột tên miền, hay hai kho tách biệt? Bảng popup đã có trường show_domain, gợi ý dùng một kho chung.
3. Tiếng Tây Ban Nha đang dùng bản EN khi thiếu khoá. Có cho marketing dịch ES trực tiếp trong kho không, hay ES vẫn đi qua đội dịch?
4. Lịch sử trước ngày kho ra đời: nhập lại từ git log (có thể tới 2022) hay bắt đầu từ ngày phát hành?
5. Có cần luồng “sửa khẩn” bỏ qua duyệt cho lỗi chính tả trên trang đăng nhập không, và ai được dùng?

10Phụ lục — mẫu danh sách từ dữ liệu thật

Mười dòng dưới đây lấy trực tiếp từ src/locales/vi/common.json ngày 10/09/2026, theo đúng định dạng sheet của Phần A. Đây là những nhóm marketing nhiều khả năng muốn sửa trước: mô tả gói dịch vụ, chỉ số trên trang chủ, và cẩm nang trong ứng dụng.

Quy mô đầy đủ theo nhóm file: common 3.607 · my_exam 770 · flyer_ai 661 · centralized_exam 264 · tuition_management 249 · onboarding 229 · program 168 · challenge 121 · auth 106 · title 82 · bank_account 58 · modal 50 · course 47 · student_info_modal 47 · và 2 file nhỏ còn lại.