Dự án Chuyển đổi số cho UBND phường A - Brief phục vụ prototype và báo giá

Tài liệu này tổng hợp yêu cầu ban đầu để phục vụ làm thuyết minh, slide, prototype hoặc bản thiết kế mẫu cho dự án chuyển đổi số cấp phường. Đây là brief sơ bộ cho giai đoạn prototype/breakdown/quotation, chưa phải PRD sản xuất cuối cùng.

Nguồn tổng hợp:

• Ghi chú yêu cầu tại apps/ubnd-phuong/docs/00-brief.md.
• EasyNote SAM-2606-1498 - Catchup Dự án CDS Phường.

Định hướng sản phẩm

Hệ thống nên được định vị là một cổng điều hành và dịch vụ công cấp phường, gồm ba lớp chính:

• Điều hành nội bộ: lãnh đạo, phòng ban, chuyên viên, văn bản, giao việc, báo cáo.
• Dịch vụ cho người dân/doanh nghiệp: cổng thông tin, đăng ký trực tuyến, phản ánh hiện trường, hỗ trợ doanh nghiệp và an sinh xã hội.
• Dữ liệu - thông báo - AI: dữ liệu dân cư/tổ chức, SMS/Zalo, chatbot điều hướng, dashboard lãnh đạo.

flowchart LR
    Citizen[Người dân / Doanh nghiệp] --> Portal[Cổng thông tin phường]
    Portal --> CMS[Tin tức / nội dung công khai]
    Portal --> Service[Cổng đăng ký và danh sách người tham gia]
    Portal --> Feedback[Phản ánh hiện trường]
    Service --> Routing[Phân tuyến phòng ban]
    Feedback --> Routing
    Routing --> Officer[Chuyên viên xử lý]
    Officer --> Leader[Lãnh đạo theo dõi]
    Officer --> Notify[SMS / Zalo thông báo]
    Portal --> Chatbot[Chatbot AI điều hướng]
    Chatbot --> Service
    Leader --> Reports[Báo cáo tổng hợp]

Tổng hợp module và estimate prototype sơ bộ

Vai trò và phạm vi dữ liệu

1. Cổng thông tin và CMS phường

Mục tiêu

Tạo mặt tiền số chính thức cho UBND phường, nơi người dân và doanh nghiệp có thể xem thông tin, thông báo, danh sách công khai và truy cập nhanh các dịch vụ.

Module này gồm hai lớp rõ ràng:

• Cổng thông tin công khai: phần người dân, doanh nghiệp và tổ chức bên ngoài truy cập.
• CMS quản trị nội bộ: công cụ dành cho admin/cán bộ UBND phường để cập nhật nội dung, biểu mẫu, thông báo và danh sách công khai. Đây không phải phần public.

Phạm vi chức năng

1.1. Cổng thông tin công khai

• Trang chủ cổng thông tin:
  • Banner/tên phường.
  • Tin mới.
  • Thông báo quan trọng.
  • Lối tắt dịch vụ hành chính công.
  • Lối tắt phản ánh hiện trường.
  • Lịch tiếp công dân.
  • Chuyên mục nổi bật.
  • Liên kết nhanh tới Dịch vụ công quốc gia, Cổng 1022, UBND TP.HCM, hotline hoặc Zalo/Facebook nếu có.
• Giới thiệu và tổ chức bộ máy:
  • Giới thiệu chung về phường.
  • Nghị quyết/thông tin thành lập phường.
  • Bản đồ địa giới hành chính.
  • Sơ đồ cơ cấu tổ chức.
  • Danh sách lãnh đạo.
  • Thông tin phòng ban/chức năng nhiệm vụ.
• Tin tức, thông báo và tuyên truyền:
  • Tin tức & sự kiện.
  • Thông báo UBND.
  • Chuyển đổi số.
  • Thông tin tuyên truyền.
  • Tin theo lĩnh vực.
• Công khai - minh bạch:
  • Công khai quy hoạch, kế hoạch sử dụng đất.
  • Công khai dự án đang thi công.
  • Công khai đấu thầu.
  • Công khai tài chính/ngân sách nếu được phép.
  • Thông tin lấy ý kiến nhân dân.
  • Danh sách văn bản công khai.
• Trung tâm phục vụ hành chính công:
  • Dịch vụ hành chính công.
  • Danh mục thủ tục hành chính.
  • Văn bản quy phạm pháp luật.
  • Biểu mẫu tải về.
  • Hướng dẫn nộp hồ sơ.
  • Link Dịch vụ công quốc gia.
  • Link Cổng 1022.
  • Hotline/số điện thoại trung tâm.
• Danh bạ/danh sách công khai theo lĩnh vực:
  • Nhà thuốc.
  • Phòng khám.
  • Cơ sở y học cổ truyền.
  • Trường/lớp/chương trình giáo dục.
  • Nhà văn hóa, thiết chế văn hóa.
  • Di tích, điểm du lịch.
  • Nhà hàng, khách sạn.
  • Sản phẩm OCOP.
  • Doanh nghiệp/hộ kinh doanh nếu được phép công khai.
• Liên hệ và liên kết:
  • Địa chỉ.
  • Email.
  • Hotline.
  • Bản đồ.
  • Link UBND TP.HCM, Dịch vụ công, Cổng 1022 và các kênh liên kết chính thức.

1.2. CMS quản trị nội bộ UBND phường

• Quản lý bài viết và thông báo.
• Quản lý chuyên mục:
  • Giáo dục.
  • Y tế.
  • Kinh tế - hạ tầng - đô thị.
  • Tài chính công khai.
  • Văn hóa, thể thao, du lịch.
  • OCOP.
  • Doanh nghiệp, việc làm.
• Quản lý banner/thông báo nổi bật.
• Quản lý file, tài liệu, biểu mẫu.
• Quản lý danh sách công khai theo lĩnh vực.
• Gửi duyệt, xuất bản, lưu trữ nội dung.
• Phân quyền theo phòng ban hoặc lĩnh vực phụ trách.
• Nhật ký chỉnh sửa nội dung.
• Thống kê lượt xem cơ bản.

flowchart TD
    Citizen[Người dân / Doanh nghiệp] --> Public[Cổng thông tin công khai]
    Public --> News[Tin tức / thông báo]
    Public --> OpenData[Công khai - minh bạch]
    Public --> HCC[Trung tâm phục vụ hành chính công]
    Admin[Admin / cán bộ UBND phường] --> CMS[CMS quản trị nội bộ]
    CMS --> Draft[Tạo nội dung / biểu mẫu / danh sách công khai]
    Draft --> Review[Gửi duyệt]
    Review -->|Duyệt| Public
    Review -->|Yêu cầu sửa| Draft

Đã rõ / đã ghi nhận

• Văn phòng UBND cần công cụ quản trị nội dung CMS nội bộ.
• Các lĩnh vực VHXH, Kinh tế Hạ tầng Đô thị, Giáo dục, Y tế, Du lịch, OCOP đều có nhu cầu đăng tải thông tin.
• Dự án, đấu thầu, tài chính cần có nội dung công khai.
• Trang tham khảo Phường Bến Thành có các nhóm quen thuộc: Giới thiệu, Đảng ủy, HĐND, UBND, MTTQ Việt Nam, Trung tâm phục vụ hành chính công, Tin tức & Sự kiện, Liên hệ.
• Trang tham khảo Phường Bến Thành có cụm Trung tâm phục vụ hành chính công gồm dịch vụ hành chính công, văn bản quy phạm pháp luật, thủ tục hành chính, Dịch vụ công quốc gia và Cổng 1022.

Mặc định / suy luận triển khai

• Prototype nên có giao diện public và giao diện admin tách biệt.
• Phần admin CMS chỉ dành cho cán bộ/admin UBND phường, không hiển thị cho người dân.
• Prototype nên có quản trị bài viết, danh mục chuyên mục và trạng thái duyệt/xuất bản.
• Mỗi bài viết hoặc danh sách công khai nên gắn phòng ban phụ trách để dễ lọc và báo cáo.

Cần xác nhận

• Chuyên mục nào bắt buộc xuất hiện trên màn hình demo đầu tiên.
• Nội dung đăng tải có cần duyệt nhiều cấp hay chỉ một cấp trưởng phòng/lãnh đạo.
• Admin CMS có cần phân quyền theo từng phòng ban ngay trong prototype không.

Cần chú ý khi prototype/test

• Không đưa dữ liệu cá nhân nhạy cảm lên phần công khai.
• Cần phân biệt rõ bài viết tin tức, danh sách công khai và biểu mẫu đăng ký.
• Cần nói rõ với khách hàng: CMS là công cụ vận hành nội bộ, còn public portal là phần người dân nhìn thấy.

2. Quản lý hành chính nội bộ

Mục tiêu

Hỗ trợ cán bộ UBND phường tiếp nhận, phân công, xử lý và báo cáo các việc nội bộ phát sinh từ các lĩnh vực quản lý. Theo EasyNote, phần này gần với nhóm Gov Administration & Reporting: lập chương trình hành chính, gửi danh sách/báo cáo, đánh giá và xử lý hồ sơ, phân quyền theo phòng ban/lãnh đạo.

Trong prototype, module này nên ở mức gọn: cán bộ có hộp tiếp nhận, phân công đơn giản, cập nhật trạng thái, ghi chú xử lý, lập/chia sẻ danh sách hoặc chương trình hành chính và xem báo cáo cơ bản. Không làm sâu hệ thống văn bản hành chính, luồng công văn đến/đi hoặc giao việc phức tạp nếu chưa có yêu cầu rõ.

Phạm vi chức năng

• Hộp tiếp nhận nội bộ cho từng loại việc:
  • Đăng ký từ module 3.
  • Phản ánh từ module 4.
  • Hồ sơ/danh mục cần cập nhật hoặc công khai từ module 5.
• Lập chương trình hành chính/sự kiện nội bộ ở mức đơn giản:
  • Tên chương trình.
  • Thời gian.
  • Đơn vị/phòng ban phụ trách.
  • Danh sách người tham gia hoặc đơn vị liên quan nếu có.
  • Tài liệu hoặc ghi chú đính kèm.
• Phân công đơn giản cho cán bộ/phòng ban phụ trách.
• Cập nhật trạng thái xử lý theo từng loại việc.
• Ghi chú nội bộ và lịch sử cập nhật cơ bản.
• Lọc theo phòng ban, trạng thái, người phụ trách, thời gian.
• Báo cáo cơ bản cho lãnh đạo theo số lượng việc mới, đang xử lý, hoàn tất.
• Gửi/chia sẻ danh sách hoặc gói thông tin nội bộ tới đúng phòng ban/người phụ trách.
• Phân quyền theo cấp:
  • Chủ tịch UBND.
  • Phó chủ tịch UBND.
  • Trưởng phòng Level 1/Level 2.
  • Chuyên viên Level 2/Level 3 theo lĩnh vực như Giáo dục, Y tế.
• Quản lý văn bản hành chính đầy đủ, công văn đến/đi, giao việc độc lập và luồng duyệt văn bản nhiều cấp: để ngoài scope prototype đầu tiên.

flowchart TD
    Source[Đăng ký / phản ánh / hồ sơ / chương trình] --> Inbox[Hộp tiếp nhận nội bộ]
    Inbox --> Classify[Phân loại lĩnh vực/phòng ban]
    Classify --> Assign[Phân công cán bộ/phòng ban]
    Assign --> Officer[Cán bộ xử lý]
    Officer --> Update[Cập nhật trạng thái / ghi chú / danh sách]
    Update --> Result[Kết quả xử lý / báo cáo]
    Result --> Report[Báo cáo lãnh đạo]

Chức năng demo đề xuất: Hộp tiếp nhận và phân công xử lý nội bộ

Đây là chức năng nên demo cho module Quản lý hành chính nội bộ. Nó đủ thể hiện năng lực điều hành của UBND phường, nhưng không kéo prototype vào hệ thống văn bản/giao việc lớn.

Màn hình demo

• Danh sách việc cần xử lý:
  • Nguồn phát sinh: đăng ký, phản ánh, hồ sơ lĩnh vực.
  • Tiêu đề việc.
  • Lĩnh vực/phòng ban.
  • Người gửi hoặc đơn vị liên quan.
  • Trạng thái.
  • Người phụ trách.
  • Ngày tiếp nhận.
• Bộ lọc:
  • Phòng ban.
  • Trạng thái.
  • Người phụ trách.
  • Nguồn phát sinh.
• Chi tiết một việc:
  • Thông tin gốc.
  • File/ảnh đính kèm nếu có.
  • Ghi chú nội bộ.
  • Lịch sử cập nhật.
  • Nút phân công.
  • Nút cập nhật trạng thái.

Data mẫu để demo

WorkItem
- id
- sourceType: registration / feedback / field_record
- title
- sector: Y tế / Văn hóa / Kinh tế - Đô thị
- department
- assignee
- status: new / processing / need_more_info / completed / rejected / archived
- submittedBy
- createdAt
- internalNote
- relatedRecordId

Luồng demo nên dùng

1. Người dân gửi phản ánh rác thải hoặc gửi đăng ký sử dụng nhà văn hóa.
2. Hệ thống tạo một việc mới trong hộp tiếp nhận nội bộ.
3. Trưởng phòng lọc việc theo lĩnh vực/phòng ban.
4. Trưởng phòng phân công cho một chuyên viên.
5. Chuyên viên mở chi tiết, đọc thông tin gốc, thêm ghi chú nội bộ.
6. Chuyên viên cập nhật trạng thái sang đang xử lý hoặc hoàn tất.
7. Lãnh đạo xem dashboard số việc mới, đang xử lý, hoàn tất theo phòng ban.

flowchart TD
    CitizenAction[Người dân gửi đăng ký/phản ánh] --> WorkItem[Tạo việc trong hộp tiếp nhận]
    WorkItem --> Manager[Trưởng phòng xem danh sách]
    Manager --> Assign[Phân công chuyên viên]
    Assign --> Officer[Chuyên viên xử lý]
    Officer --> Status[Cập nhật trạng thái / ghi chú]
    Status --> Dashboard[Lãnh đạo xem báo cáo]

Vì sao chọn chức năng này để demo

• Khớp EasyNote về xử lý hồ sơ, gửi danh sách/báo cáo và phân quyền phòng ban.
• Kết nối trực tiếp với module 3, 4 và 5.
• Dễ hiểu khi trình bày cho lãnh đạo: mọi yêu cầu đi vào một hộp tiếp nhận, có người phụ trách và có trạng thái.
• Không cần làm công văn đến/đi, quy trình văn bản nhiều cấp hoặc hệ thống giao việc riêng.

Đã rõ / đã ghi nhận

• Có cấp Chủ tịch và Phó chủ tịch UBND.
• Có quyền Trưởng phòng và Chuyên viên theo Level.
• Có nhu cầu quản lý văn bản, giao việc và báo cáo trong bức tranh tổng thể.
• EasyNote ghi nhận nhóm quản trị và báo cáo hành chính gồm lập chương trình hành chính, gửi danh sách/báo cáo, đánh giá và xử lý hồ sơ.
• EasyNote ghi nhận cần phân chia vai trò theo cấp bậc/phòng ban và quyền xem báo cáo tổng hợp.

Mặc định / suy luận triển khai

• Prototype nên thể hiện một module hành chính nội bộ gọn, dùng chung với các module 3/4/5.
• Mỗi item xử lý nên gắn nguồn phát sinh, lĩnh vực, người phụ trách, trạng thái và kết quả.
• Trạng thái xử lý chi tiết có thể khác nhau theo từng module, nhưng nên có bộ trạng thái tối thiểu: mới, đang xử lý, cần bổ sung, hoàn tất, từ chối/lưu trữ.
• Chương trình hành chính trong prototype nên ở mức lịch/chương trình/danh sách liên quan, không phải quản lý sự kiện phức tạp.

Cần xác nhận

• Level 1/2/3 là cấp quyền, cấp duyệt hay cấp tổ chức.
• Có cần duyệt/phê duyệt trong inbox nội bộ không, hay cán bộ được cập nhật trạng thái trực tiếp theo phân quyền.
• Có cần quản lý văn bản hành chính thật, công văn đến/đi hoặc giao việc độc lập trong giai đoạn sau không.
• "Lập chương trình hành chính" trong EasyNote cần hiểu là lịch/chương trình sự kiện, kế hoạch công tác, hay một loại hồ sơ khác.

Cần chú ý khi prototype/test

• Không pitch đây là hệ thống quản lý văn bản/giao việc đầy đủ để tránh đội scope.
• Phân quyền là điểm dễ bị hỏi khi trình bày, nên cần demo rõ người nào thấy gì và được thao tác gì trong inbox dùng chung.
• Nếu khách hàng hỏi về quản lý văn bản/giao việc đầy đủ, nên đưa vào roadmap hoặc gói mở rộng.

3. Cổng đăng ký và danh sách thí sinh/người tham gia

Mục tiêu

Cho phép người dân, tổ chức và doanh nghiệp đăng ký tham gia các chương trình, hoạt động hoặc đợt cập nhật thông tin do UBND phường mở. Trong prototype, module này nên tập trung vào luồng đăng ký theo đợt, quản lý danh sách thí sinh/người tham gia, chống trùng/spam và tra cứu trạng thái.

Phạm vi chức năng

• Đăng nhập trước khi gửi đăng ký để hạn chế spam và giúp tra cứu trạng thái.
• Mở đợt đăng ký theo chương trình/hoạt động:
  • Tên đợt đăng ký.
  • Thời gian mở/đóng đăng ký.
  • Đối tượng được đăng ký.
  • Phòng ban tiếp nhận.
  • Số lượng dự kiến nếu có.
• Người dân/tổ chức gửi thông tin đăng ký.
• Cán bộ xem và quản lý danh sách thí sinh/người tham gia.
• Cập nhật trạng thái đăng ký:
  • Mới gửi.
  • Hợp lệ.
  • Cần bổ sung.
  • Đã duyệt.
  • Từ chối.
  • Đã tham gia.
• Kiểm tra trùng lặp cơ bản theo SĐT, CCCD hoặc thông tin định danh phù hợp.
• Chuyển đăng ký về đúng phòng ban/hộp tiếp nhận.
• Xuất danh sách thí sinh/người tham gia ra Excel/PDF nếu cần.
• Thông báo trạng thái hoặc nhắc lịch bằng SMS/Zalo giả lập trong prototype.
• Các case đăng ký nhẹ có thể dùng để demo:
  • Đăng ký sử dụng văn phòng hoặc nhà văn hóa.
  • Đăng ký tham gia hoạt động văn hóa, thể thao, sự kiện phường.
  • Đăng ký/cập nhật danh sách thí sinh/người tham gia một chương trình cụ thể.
  • Đăng ký quyên góp/hỗ trợ.
• Đăng ký khám chữa bệnh tại Trạm Y tế: ghi nhận là nhu cầu, nhưng không đi sâu hoặc demo chi tiết ở prototype đầu tiên.
• Đăng ký mở lớp, đăng ký học online: ghi nhận là nhu cầu, nhưng không đi sâu hoặc demo chi tiết ở prototype đầu tiên.

flowchart TD
    Citizen[Người dân / Tổ chức] --> Login[Đăng nhập / xác thực cơ bản]
    Login --> Select[Chọn đợt đăng ký đang mở]
    Select --> Form[Điền thông tin đăng ký]
    Form --> Duplicate[Kiểm tra trùng lặp cơ bản]
    Duplicate -->|Không trùng| Submit[Gửi đăng ký]
    Duplicate -->|Có thể trùng| ReviewDuplicate[Cảnh báo / yêu cầu kiểm tra]
    Submit --> Route[Chuyển đúng phòng ban]
    Route --> Inbox[Hộp tiếp nhận của cán bộ]
    Inbox --> Process[Duyệt / yêu cầu bổ sung / từ chối]
    Process --> List[Danh sách thí sinh/người tham gia]
    Process --> Notify[Thông báo trạng thái / nhắc lịch]

Đã rõ / đã ghi nhận

• EasyNote ghi nhận nhu cầu mở cổng đăng ký thông tin cho các đối tượng, ví dụ khoảng 30 thí sinh.
• EasyNote ghi nhận nhu cầu cập nhật thông tin và lưu lại danh sách người tham gia.
• Có nhu cầu đăng ký mở lớp hoặc học online.
• Có nhu cầu đăng ký khám chữa bệnh.
• Có nhu cầu đăng ký sử dụng nhà văn hóa/văn phòng và tham gia hoạt động.
• Có nhu cầu đăng ký quyên góp/hỗ trợ.
• Cần yêu cầu đăng nhập trước khi gửi đăng ký để chống spam.

Mặc định / suy luận triển khai

• Prototype nên có một bộ form dùng chung: thông tin người đăng ký, lĩnh vực, nội dung, file/ảnh đính kèm, trạng thái xử lý.
• Nên thiết kế form đăng ký theo mẫu cấu hình để mỗi đợt đăng ký có thể chọn trường thông tin cần thu thập.
• Nên demo các form ít ràng buộc nghiệp vụ trước: đăng ký sử dụng nhà văn hóa/văn phòng, đăng ký tham gia hoạt động, đăng ký/cập nhật danh sách thí sinh/người tham gia, đăng ký quyên góp/hỗ trợ.
• Đăng nhập trong prototype có thể dùng xác thực cơ bản bằng SĐT/tài khoản mẫu, chưa cần tích hợp định danh phức tạp nếu chưa được yêu cầu.
• Đăng ký khám chữa bệnh và đăng ký mở lớp/học online nên để ở mức thông tin/điều hướng/roadmap vì có nhiều ràng buộc nghiệp vụ, lịch, đối tượng, hệ thống liên quan và trách nhiệm chuyên môn.
• Hộp tiếp nhận đăng ký của cán bộ nên lọc theo đợt đăng ký, trạng thái, phòng ban, thời gian gửi và người phụ trách.

Cần xác nhận

• Cơ chế đăng nhập giai đoạn prototype dùng SĐT, CCCD, tài khoản mẫu, hay liên kết một hệ thống xác thực hiện có.
• Có cần ký số, thanh toán lệ phí hoặc kết nối cổng dịch vụ công Thành phố trong giai đoạn đầu không.
• Các loại đăng ký nào đủ an toàn để demo public trong giai đoạn đầu.
• Danh sách thí sinh/người tham gia cần những trường bắt buộc nào.
• Có cần giới hạn số lượng người đăng ký theo từng đợt không.
• Trùng lặp được xác định theo SĐT, CCCD, email, hay tổ hợp thông tin khác.

Cần chú ý khi prototype/test

• Cần tránh làm người xem hiểu nhầm prototype đã thay thế hệ thống dịch vụ công Thành phố.
• Với tuyển sinh, nguồn ghi nhận rằng Thành phố đã có hệ thống, nên prototype chỉ nên làm điều hướng/thông tin/phụ trợ nếu chưa có xác nhận khác.
• Với khám chữa bệnh, không nên mô phỏng sâu lịch khám, chuyên môn y tế, hồ sơ sức khỏe hoặc xác nhận điều trị nếu chưa có phạm vi rõ.
• Cần test chống spam cơ bản: chưa đăng nhập không gửi được form, người dùng đăng nhập xem lại được danh sách yêu cầu đã gửi.
• Cần test trường hợp đăng ký trùng, hết hạn đăng ký, vượt số lượng dự kiến và cán bộ xuất danh sách.

4. Tiếp nhận phản ánh và xử lý

Mục tiêu

Tập trung phản ánh của người dân về một nơi xử lý, có ảnh/hình ảnh gửi kèm nếu có, phân tuyến phòng ban và báo cáo tiến độ cho lãnh đạo.

Phạm vi chức năng

• Người dân đăng nhập hoặc xác thực cơ bản trước khi gửi phản ánh để hạn chế spam.
• Người dân gửi phản ánh kèm hình ảnh.
• Thông tin phản ánh cần thu thập:
  • Loại phản ánh.
  • Nội dung phản ánh.
  • Ảnh/video nếu có.
  • Vị trí hoặc tổ dân phố/khu phố nếu có.
  • Thông tin liên hệ của người gửi.
• Phân loại phản ánh theo lĩnh vực:
  • Môi trường.
  • Rác thải.
  • Nước.
  • Hạ tầng.
  • Y tế.
  • An sinh.
• Tự động hoặc bán tự động chuyển phản ánh về phòng ban phụ trách.
• Cán bộ cập nhật trạng thái xử lý ở phần nội bộ.
• Trạng thái xử lý hiện tại để private, chỉ cán bộ/lãnh đạo xem theo quyền. Người dân có thể xem trạng thái phản ánh của chính mình sau khi đăng nhập.
• Phản ánh có thể hiển thị công khai ở cổng thông tin hoặc danh sách phản ánh công khai, nhưng không public thông tin người gửi.
• Tạm giả định phản ánh không cần duyệt trước khi vào hộp tiếp nhận xử lý. Nếu khách hàng yêu cầu kiểm duyệt trước khi công khai hoặc trước khi chuyển xử lý thì cần bổ sung luồng duyệt.
• Lãnh đạo xem báo cáo sự cố/phản ánh.

flowchart TD
    Citizen[Người dân] --> Login[Đăng nhập / xác thực cơ bản]
    Login --> Evidence[Gửi ảnh / nội dung / vị trí]
    Evidence --> Classify[Phân loại lĩnh vực]
    Classify --> Department[Chuyển phòng ban phụ trách]
    Department --> Resolve[Cán bộ xử lý]
    Resolve --> Update[Cập nhật trạng thái / kết quả xử lý]
    Update --> Close[Đóng phản ánh]
    Close --> PublicList[Dữ liệu công khai đã ẩn thông tin người gửi]
    Classify --> Dashboard[Báo cáo lãnh đạo]
    Close --> Dashboard

Đã rõ / đã ghi nhận

• Có nhu cầu nhận tin báo và hình ảnh từ hộ dân.
• Có nhu cầu tiếp nhận phản ánh môi trường như rác thải, nước.
• Có nhu cầu tự động báo cáo sự cố hoặc phản ánh về Ủy ban.
• Trạng thái xử lý chưa xác định có public hay private; hiện tại chọn private để an toàn.
• Thông tin phản ánh có thể công khai, nhưng không công khai thông tin người gửi.

Mặc định / suy luận triển khai

• Prototype nên có bản đồ hoặc danh sách phản ánh theo trạng thái để nhìn trực quan.
• Phản ánh không cần duyệt trước khi vào hộp tiếp nhận xử lý nếu chưa có quyết định khác.
• Nếu hiển thị phản ánh công khai, cần ẩn tên, SĐT, CCCD, địa chỉ chi tiết hoặc các thông tin định danh của người gửi.

Đề xuất thêm cho prototype/demo

• Có thể cho cán bộ upload ảnh kết quả/ảnh sau xử lý để câu chuyện demo trực quan hơn, nhưng đây là đề xuất, chưa phải yêu cầu từ EasyNote.
• Có thể bổ sung SLA/thời hạn xử lý, cảnh báo sắp quá hạn/quá hạn và thống kê theo phòng ban, nhưng đây là đề xuất, chưa phải yêu cầu từ EasyNote.

Cần xác nhận

• Phản ánh có cần xác định theo tổ dân phố/khu phố không.
• Trạng thái xử lý có chỉ private như hiện tại hay cần public một phần cho cộng đồng xem.
• Phản ánh công khai có cần duyệt trước khi hiển thị không.
• Phản ánh có cần duyệt trước khi chuyển cán bộ xử lý không. Nếu chưa có quyết định, prototype mặc định không cần duyệt.
• Có cần đưa ảnh kết quả/ảnh sau xử lý vào scope chính không.
• Có cần đưa SLA/thời hạn xử lý hoặc cảnh báo quá hạn vào scope chính không. EasyNote hiện không ghi rõ yêu cầu SLA.
• Có cần tích hợp hoặc đồng bộ với Cổng 1022 không, hay chỉ điều hướng/link ra 1022.

Cần chú ý khi prototype/test

• Cần che hoặc không dùng thông tin cá nhân thật khi demo.
• Cần có bộ dữ liệu mẫu đủ nhiều để dashboard nhìn có sức nặng.
• Không nói hệ thống thay thế Cổng 1022 nếu chưa có tích hợp chính thức.
• Tránh demo các phản ánh nhạy cảm như tranh chấp, khiếu nại pháp lý, y tế hoặc an sinh chi tiết nếu chưa có phạm vi rõ.

5. Quản lý danh mục và hồ sơ lĩnh vực

Mục tiêu

Centralize các dữ liệu chuyên môn của nhiều phòng ban vào một module dùng chung, thay vì xây riêng nhiều module lớn như Giáo dục, Y tế, Dự án, Văn hóa, OCOP. Module này quản lý dữ liệu có cấu trúc theo lĩnh vực, cho phép cán bộ nhập/cập nhật danh sách, chọn phần được công khai lên cổng thông tin, phục vụ tra cứu, phản ánh và báo cáo lãnh đạo.

Nói ngắn gọn: đây là một dạng "Excel có phân quyền + có trạng thái + có công khai ra website + có báo cáo".

Khác với Cổng thông tin/CMS

Phạm vi chức năng

• Tạo nhóm lĩnh vực:
  • Giáo dục.
  • Y tế tư nhân.
  • Kinh tế - hạ tầng - đô thị.
  • Dự án/Tài chính.
  • Văn hóa - thể thao - du lịch.
  • OCOP.
  • Chính sách xã hội nếu được xác nhận.
• Tạo loại hồ sơ/danh mục theo lĩnh vực:
  • Cơ sở y tế tư nhân.
  • Dự án/công trình.
  • Thiết chế văn hóa.
  • Sản phẩm OCOP.
  • Danh sách thí sinh/người tham gia nếu cần dùng chung với module 3.
• Cấu hình trường thông tin cơ bản cho từng loại hồ sơ:
  • Text.
  • Số.
  • Ngày.
  • Select/dropdown.
  • File/tài liệu.
  • Hình ảnh.
  • Có/không.
• Quản lý bản ghi:
  • Tạo/sửa/lưu trữ.
  • Tìm kiếm/lọc theo lĩnh vực, trạng thái, phòng ban phụ trách.
  • Import hoặc nhập tay danh sách nếu có dữ liệu mẫu.
  • Xuất Excel/PDF nếu cần.
• Quản lý trạng thái bản ghi:
  • Nháp.
  • Nội bộ.
  • Chờ công khai.
  • Đã công khai.
  • Lưu trữ.
• Chọn trường/bản ghi được phép công khai ra cổng thông tin.
• Gắn phòng ban phụ trách và người cập nhật.
• Gắn phản ánh/feedback liên quan đến một bản ghi nếu cần.
• Dashboard cơ bản: tổng số bản ghi theo lĩnh vực, trạng thái, phòng ban, số bản ghi đang công khai.
• Cổng tự phục vụ dành cho đối tác (Self-service Partner Portal):
  • Đại diện cơ sở đăng nhập bằng tài khoản liên kết MST/Mã cơ sở.
  • Tự quản lý và chỉnh sửa thông tin chi tiết hồ sơ công khai của đơn vị.
  • Soạn thảo và đăng tải tin tức hoạt động, tuyển dụng, sự kiện thuộc cơ sở.
• Quy trình kiểm duyệt tin bài bên thứ ba (Moderation Queue):
  • Bài đăng hoặc thông tin cập nhật của đơn vị bên ngoài mặc định ở trạng thái Chờ duyệt.
  • Chuyển tiếp yêu cầu duyệt về Hộp việc nội bộ của chuyên viên phụ trách lĩnh vực của UBND phường.
  • Chuyên viên thẩm định nội dung, xem trước Live Preview và ấn Duyệt xuất bản để đồng bộ lên Portal công cộng.

Data model đề xuất cho prototype

Sector / Lĩnh vực
- id
- name: Giáo dục / Y tế / Kinh tế / Văn hóa / OCOP
- owningDepartment

RecordType / Loại hồ sơ
- id
- sectorId
- name: Cơ sở y tế tư nhân / Dự án / Nhà văn hóa / Sản phẩm OCOP
- description
- publicLabel

FieldDefinition / Trường dữ liệu
- id
- recordTypeId
- fieldName
- label
- fieldType: text / number / date / select / file / image / boolean
- required
- publicVisible
- options

Record / Bản ghi
- id
- recordTypeId
- title
- status: draft / internal / pending_public / published / archived
- owningDepartment
- createdBy
- updatedBy
- publicVisible

RecordValue / Giá trị từng trường
- recordId
- fieldDefinitionId
- value

Attachment / Tệp đính kèm
- id
- recordId
- fileUrl
- fileType
- publicVisible

Use case mẫu 1: Cơ sở y tế tư nhân

• Cán bộ Y tế tạo loại hồ sơ "Cơ sở y tế tư nhân".
• Cấu hình trường: tên cơ sở, loại hình, địa chỉ, tổ dân phố/khu phố, người phụ trách, SĐT, giấy phép nếu có, trạng thái hoạt động, hiển thị công khai.
• Nhập danh sách nhà thuốc, phòng khám, cơ sở y học cổ truyền.
• Chọn bản ghi/trường được phép công khai lên cổng thông tin.
• Người dân tra cứu danh sách cơ sở đã công khai.
• Nếu có phản ánh về một cơ sở, phản ánh có thể gắn với đúng bản ghi cơ sở đó.
• Lãnh đạo xem số lượng cơ sở theo loại hình, trạng thái và số phản ánh liên quan.

Use case mẫu 2: Dự án/Tài chính công khai

• Cán bộ Kinh tế - Hạ tầng - Đô thị tạo loại hồ sơ "Dự án/Công trình".
• Cấu hình trường: tên dự án, địa điểm, đơn vị phụ trách, loại dự án, thời gian bắt đầu, thời gian dự kiến hoàn thành, trạng thái, thông tin đấu thầu, tài liệu công khai.
• Nhập danh sách dự án đang thi công hoặc dự án cần công khai.
• Công khai một phần thông tin ra mục "Công khai - minh bạch" trên cổng thông tin.
• Lãnh đạo xem dashboard số dự án theo trạng thái.
• Nếu có phản ánh liên quan dự án/công trình, phản ánh có thể liên kết với hồ sơ dự án.

Use case mẫu 3: Thiết chế văn hóa / nhà văn hóa

• Cán bộ Văn hóa tạo loại hồ sơ "Thiết chế văn hóa".
• Cấu hình trường: tên địa điểm, loại hình, địa chỉ, sức chứa, người quản lý, SĐT liên hệ, khung giờ sử dụng, có cho đăng ký sử dụng hay không, hiển thị công khai.
• Nhập danh sách nhà văn hóa, phòng sinh hoạt cộng đồng, sân thể thao nếu có.
• Công khai danh sách cơ sở được phép cho người dân xem.
• Người dân bấm "Đăng ký sử dụng" để chuyển sang module 3 - Cổng đăng ký và danh sách thí sinh/người tham gia.
• Lãnh đạo xem cơ sở nào được sử dụng nhiều nếu module đăng ký có dữ liệu liên quan.

Nhóm roadmap theo brief gốc

• Giáo dục: đăng tải thông tin, danh sách/chương trình, liên kết danh sách thí sinh/người tham gia nếu có đợt đăng ký.
• OCOP: sản phẩm, chủ thể OCOP, địa chỉ, SĐT liên hệ, hình ảnh, trạng thái công khai.
• Văn hóa - du lịch: di tích, địa điểm du lịch, nhà hàng, khách sạn.
• Chính sách xã hội/người có công: chỉ nên đưa vào sau khi xác nhận phạm vi dữ liệu nhạy cảm và quyền xem.

flowchart LR
    Admin[Admin / cán bộ phòng ban] --> Sector[Tạo lĩnh vực]
    Sector --> Type[Tạo loại hồ sơ]
    Type --> Fields[Cấu hình trường dữ liệu]
    Fields --> Record[Nhập bản ghi]
    Record --> Visibility[Chọn trường/bản ghi công khai]
    Visibility --> Portal[Cổng thông tin công khai]
    Record --> Feedback[Phản ánh/feedback liên quan]
    Record --> Report[Báo cáo lãnh đạo]

Đã rõ / đã ghi nhận

• Các lĩnh vực chính đã được nêu: Giáo dục, Y tế, Y tế tư nhân, Kinh tế Hạ tầng Đô thị, Môi trường, Văn hóa TDTT, Du lịch, Chính sách xã hội, OCOP.
• EasyNote nhấn mạnh thêm Giáo dục, Y tế tư nhân, Dự án/Kế hoạch/Tài chính là các mảng đang được nhắc nhiều.
• EasyNote xoay quanh các hành động chung: đăng tải/công bố thông tin, cập nhật danh sách, công khai thông tin cho đúng đối tượng và định tuyến thông tin theo phòng ban.

Mặc định / suy luận triển khai

• Không xây nhiều module chuyên môn riêng trong prototype đầu tiên; dùng một engine danh mục/hồ sơ lĩnh vực dùng chung.
• Prototype nên làm sâu 2-3 loại hồ sơ mẫu: Cơ sở y tế tư nhân, Dự án/Công trình, Thiết chế văn hóa.
• Các lĩnh vực còn lại hiển thị ở mức cấu hình mẫu, dashboard/menu/roadmap để thể hiện khả năng mở rộng.
• Chỉ công khai các trường được đánh dấu public; ghi chú nội bộ, dữ liệu nhạy cảm và thông tin định danh không public.

Cần xác nhận

• Loại hồ sơ nào cần demo đầu tiên: cơ sở y tế tư nhân, dự án/công trình, thiết chế văn hóa, OCOP hay loại khác.
• Mỗi loại hồ sơ cần những trường bắt buộc nào.
• Dữ liệu danh sách cơ sở y tế tư nhân, nhà văn hóa, di tích, OCOP, dự án có sẵn dạng file hay phải nhập tay.
• Quy trình công khai bản ghi có cần duyệt không, hay cán bộ có quyền public trực tiếp theo phân quyền.
• Có cần import Excel trong prototype đầu tiên không.
• Chính sách xã hội có cần quản lý thông tin nhạy cảm chi tiết hay chỉ để roadmap.

Cần chú ý khi prototype/test

• Không gọi đây là nhiều module riêng khi chào scope thấp; nên gọi là một module dùng chung cho nhiều lĩnh vực.
• Cần demo rõ khác biệt với CMS: CMS là bài viết, module này là dữ liệu có cấu trúc.
• Nếu cấu hình trường quá linh hoạt, prototype sẽ phức tạp. Giai đoạn đầu nên cấu hình ở mức vừa đủ cho 2-3 loại hồ sơ mẫu.
• Dữ liệu an sinh và y tế có tính nhạy cảm, cần quy định quyền xem kỹ hơn các module tin tức công khai.

6. Doanh nghiệp, việc làm và tín dụng

Mục tiêu

Không tách thành module độc lập trong prototype đầu tiên, vì doanh nghiệp, việc làm và tín dụng có thể nhanh chóng phình thành nhiều nghiệp vụ riêng như đăng ký kinh doanh, tuyển dụng, matching ứng viên, chương trình vay vốn và đo lường hiệu quả. Giai đoạn prototype nên đưa nhóm này về hai module đã có:

• Module 5 - Quản lý danh mục và hồ sơ lĩnh vực: quản lý danh sách doanh nghiệp/hộ kinh doanh, tin tuyển dụng, chương trình tín dụng/vay vốn như các loại hồ sơ có cấu trúc.
• Module 3 - Cổng đăng ký và danh sách thí sinh/người tham gia: tiếp nhận đăng ký tham gia chương trình, đăng ký tìm việc, đăng ký nhận thông tin tín dụng theo từng đợt.

Mục tiêu là vẫn thể hiện được chức năng hỗ trợ kinh tế địa phương, nhưng không xây một hệ thống việc làm/tín dụng riêng trong phạm vi ngân sách thấp.

Phạm vi chức năng

• Dưới module 5, có thể cấu hình các loại hồ sơ:
  • Doanh nghiệp/hộ kinh doanh.
  • Tin tuyển dụng.
  • Hồ sơ người lao động/tìm việc nếu được phép.
  • Chương trình tín dụng/vay vốn.
  • Quy định/chính sách hỗ trợ doanh nghiệp.
• Dưới module 3, có thể mở các đợt đăng ký:
  • Đăng ký tham gia chương trình hỗ trợ doanh nghiệp.
  • Đăng ký tìm việc hoặc cập nhật nhu cầu việc làm.
  • Đăng ký nhận thông tin chương trình tín dụng.
  • Đăng ký tham gia hội nghị/tư vấn/kết nối doanh nghiệp.
• Cổng thông tin/CMS công khai các nội dung phù hợp:
  • Chính sách hỗ trợ.
  • Danh sách chương trình.
  • Tin tuyển dụng được duyệt công khai.
  • Thông tin tín dụng do cán bộ nhập hoặc ngân hàng cung cấp.
• Matching tuyển dụng tự động, kết nối trực tiếp doanh nghiệp - ứng viên và đo lường hiệu quả nâng cao: để roadmap hoặc cần xác nhận riêng.

flowchart TD
    Officer[Cán bộ phụ trách] --> Records[Module 5: Hồ sơ doanh nghiệp / tuyển dụng / tín dụng]
    Records --> Public[Công khai thông tin phù hợp]
    Public --> Portal[Cổng thông tin]
    Citizen[Người dân / Doanh nghiệp] --> Register[Module 3: Đăng ký tham gia / tìm việc / nhận thông tin]
    Register --> Inbox[Hộp tiếp nhận nội bộ]
    Records --> Dashboard[Báo cáo lãnh đạo]
    Register --> Dashboard

Đã rõ / đã ghi nhận

• Module doanh nghiệp gồm quy định chính sách, thông tin và tuyển dụng.
• Có nhu cầu đăng ký kinh doanh doanh nghiệp/hộ kinh doanh.
• Có nhu cầu kết nối việc làm và chương trình hỗ trợ tín dụng/vay vốn.

Mặc định / suy luận triển khai

• Prototype đầu tiên không xây riêng module doanh nghiệp/việc làm/tín dụng.
• Các dữ liệu doanh nghiệp, tuyển dụng và tín dụng được xem như hồ sơ lĩnh vực trong module 5.
• Các nhu cầu đăng ký tham gia chương trình hoặc tìm việc được xem như đợt đăng ký trong module 3.
• Nếu cần thể hiện matching, chỉ nên để mức gợi ý thủ công hoặc roadmap, không gọi là tự động matching trong prototype.

Cần xác nhận

• Phường có quyền xử lý đăng ký kinh doanh tới mức nào, hay chỉ tiếp nhận/điều hướng hồ sơ.
• Ngân hàng tham gia đăng tin trực tiếp hay cán bộ phường nhập thay.
• Có được công khai danh sách doanh nghiệp/hộ kinh doanh, tin tuyển dụng hoặc hồ sơ người lao động không.
• Người lao động có cần đăng nhập/ẩn danh thông tin cá nhân khi đăng ký tìm việc không.
• Matching tuyển dụng có thật sự cần trong giai đoạn đầu không, hay chỉ cần danh sách/tin tuyển dụng và form đăng ký.

Cần chú ý khi prototype/test

• Không nên thể hiện các thủ tục vượt thẩm quyền của phường nếu chưa được xác nhận.
• Không public thông tin cá nhân người lao động nếu chưa có cơ chế đồng ý và phân quyền rõ.
• Không pitch matching tự động hoặc chương trình tín dụng như nghiệp vụ đã chốt nếu khách chưa xác nhận.

7. Dữ liệu dân cư, tổ chức và đối tượng quản lý

Mục tiêu

Xây dựng lõi dữ liệu dùng chung cho các module, giúp phường quản lý công dân, tổ chức, tổ dân phố và các nhóm đối tượng cần hỗ trợ.

Phạm vi chức năng

• Quản lý cá nhân theo CCCD và số điện thoại.
• Quản lý tổ chức/doanh nghiệp theo mã số thuế.
• Quản lý đơn vị cơ sở/tổ dân phố.
• Import danh sách dân cư khoảng 84.000 dân.
• Lên yêu cầu xin hoặc truy xuất thông tin công dân.
• Quản lý nhóm đối tượng:
  • Người có công.
  • Hộ nghèo.
  • Trẻ em mồ côi.
  • Người già.
  • Cơ sở y tế, giáo dục, văn hóa, doanh nghiệp.

flowchart TD
    Import[Import dữ liệu dân cư] --> Validate[Kiểm tra CCCD / SĐT / tổ dân phố]
    Validate --> Master[Kho dữ liệu dùng chung]
    Master --> Services[Dịch vụ công]
    Master --> Welfare[Chính sách xã hội]
    Master --> Reports[Báo cáo lãnh đạo]
    Request[Yêu cầu truy xuất thông tin] --> Permission[Kiểm tra quyền truy cập]
    Permission --> Master

Đã rõ / đã ghi nhận

• Cá nhân quản lý theo CCCD và SĐT.
• Tổ chức quản lý theo doanh nghiệp và MST.
• Đơn vị cơ sở là tổ dân phố.
• Có nhu cầu import danh sách dân cư khoảng 84.000 dân.
• Có nhu cầu xin hoặc truy xuất thông tin công dân.

Mặc định / suy luận triển khai

• Prototype nên dùng dữ liệu mẫu, có chức năng import file minh họa và dashboard thống kê.
• Cần có lịch sử truy cập hoặc ít nhất là kiểm soát quyền xem dữ liệu công dân.

Cần xác nhận

• Nguồn dữ liệu dân cư có được phép import vào hệ thống này không.
• File import dự kiến có các trường nào.
• Quy trình xin/truy xuất thông tin công dân gồm ai yêu cầu, ai duyệt, ai được xem.

Cần chú ý khi prototype/test

• Đây là phần nhạy cảm nhất về bảo mật và dữ liệu cá nhân.
• Không dùng dữ liệu dân cư thật trong demo nếu chưa có phê duyệt.

8. Thông báo, chatbot AI và báo cáo lãnh đạo

Mục tiêu

Tăng khả năng điều hành và tương tác bằng thông báo SMS/Zalo, chatbot hướng dẫn và dashboard báo cáo theo thời gian gần thực.

Phạm vi chức năng

• Gửi SMS/Zalo tới người dân hoặc nhóm đối tượng về chính sách mới.
• Nhắc lịch đăng ký, khám, hẹn hoặc hoạt động.
• Tích hợp SMS qua Omicall.
• Đơn giá SMS dự kiến: 180-200đ/tin.
• Chatbot AI hoạt động trong phạm vi chức năng đã nêu.
• Chatbot hướng dẫn người dân/doanh nghiệp sử dụng hệ thống.
• Chatbot định tuyến người dùng đến đúng dịch vụ.
• Dashboard lãnh đạo:
  • Số phản ánh theo trạng thái.
  • Số hồ sơ/đăng ký theo lĩnh vực.
  • Số tin đã công khai.
  • Số đối tượng chính sách/hỗ trợ.
  • Báo cáo theo phòng ban và thời gian.
• Thư viện điện tử:
  • Đăng tải sách.
  • Đăng ký đọc.
  • Tìm kiếm và phân loại tài liệu.

flowchart TD
    Data[Dữ liệu hồ sơ / phản ánh / bài viết] --> Dashboard[Dashboard lãnh đạo]
    Data --> Segment[Nhóm người nhận]
    Segment --> SMS[SMS/Zalo Omicall]
    Citizen[Người dân / Doanh nghiệp] --> Bot[Chatbot AI]
    Bot --> Guide[Hướng dẫn thủ tục]
    Bot --> Link[Điều hướng đến form / tin / phòng ban]
    SMS --> Citizen

Đã rõ / đã ghi nhận

• Có nhu cầu SMS/Zalo cho đối tượng về chính sách mới.
• Có định hướng tích hợp SMS qua Omicall.
• Có đơn giá SMS dự kiến 180-200đ/tin.
• Có nhu cầu chatbot AI hướng dẫn sử dụng và định tuyến người dùng.
• Có nhu cầu thư viện điện tử.

Mặc định / suy luận triển khai

• Prototype nên demo gửi thông báo giả lập trước, chưa cần bắn SMS thật.
• Chatbot nên giới hạn câu trả lời trong các chức năng/câu hỏi của hệ thống phường.
• Dashboard nên ưu tiên lãnh đạo xem nhanh tình hình thay vì báo cáo chi tiết phức tạp.

Cần xác nhận

• Dùng Zalo OA, SMS, hay cả hai trong giai đoạn đầu.
• Omicall đã có tài khoản/API key chưa.
• Chatbot dùng dữ liệu nội bộ nào để trả lời, và có cần kiểm duyệt câu trả lời trước không.
• Thư viện điện tử có nằm trong gói prototype đầu tiên hay là roadmap.

Cần chú ý khi prototype/test

• Chi phí SMS cần được tách khỏi phí khởi tạo/tích hợp.
• Chatbot phải tránh trả lời vượt phạm vi hoặc đưa thông tin pháp lý không được xác nhận.

Kế hoạch chuẩn bị thuyết minh, slide và prototype

Deadline ghi nhận: Thứ 6 tuần sau.

Các hạng mục cần chuẩn bị:

• Thuyết minh dự án.
• Slide thuyết trình.
• Prototype hoặc bản thiết kế mẫu.
• Câu chuyện demo theo hành trình người dân, cán bộ, lãnh đạo.

Gói ngân sách ban đầu ghi nhận:

• Ngân sách/gói: khoảng 30.000.000 VNĐ, có thể là phí khởi tạo hoặc phí tích hợp.
• Tích hợp SMS qua Omicall.
• Đơn giá SMS dự kiến: 180-200đ/tin.
• Có phí bảo trì hàng tháng.

Gợi ý phạm vi prototype để đi chốt dự án

Không nên làm dàn trải cả 8 module ở cùng độ sâu. Prototype nên tập trung vào các màn hình có sức thuyết phục cao:

1. Trang chủ cổng thông tin công khai và CMS admin nội bộ.
2. Dashboard lãnh đạo.
3. Cổng đăng ký mẫu: đợt đăng ký sử dụng nhà văn hóa/văn phòng, đăng ký hoạt động, danh sách thí sinh/người tham gia.
4. Phản ánh hiện trường kèm ảnh và quy trình xử lý.
5. Quản lý danh mục và hồ sơ lĩnh vực mẫu: Cơ sở y tế tư nhân, Dự án/Công trình, Thiết chế văn hóa.
6. SMS/Zalo giả lập và chatbot AI điều hướng.

flowchart LR
    Demo1[Trang chủ public / CMS admin nội bộ] --> Demo2[Cổng đăng ký và danh sách người tham gia]
    Demo2 --> Demo3[Phản ánh hiện trường]
    Demo3 --> Demo4[Cán bộ xử lý]
    Demo4 --> Demo5[SMS/Zalo thông báo]
    Demo5 --> Demo6[Dashboard lãnh đạo]
    Demo6 --> Demo7[Chatbot hỏi đáp]

Câu hỏi cần xác nhận với khách hàng

• Giai đoạn đầu ưu tiên module nào để triển khai thật: CMS, phản ánh, dịch vụ công, y tế, giáo dục hay dashboard?
• Cơ chế đăng nhập khi gửi đăng ký/phản ánh nên dùng SĐT, CCCD, tài khoản mẫu, hay hệ thống xác thực hiện có?
• Dữ liệu dân cư 84.000 dân có file mẫu và quyền sử dụng cho prototype không?
• Level 1/2/3 trong phân quyền được hiểu là cấp duyệt, cấp tổ chức hay nhóm quyền thao tác?
• SMS/Zalo cần tích hợp thật trong prototype hay chỉ demo giả lập?
• Có cần đồng bộ/kết nối với hệ thống dịch vụ công hoặc tuyển sinh của Thành phố không?
• Danh sách cơ sở y tế tư nhân, OCOP, du lịch, nhà văn hóa đã có dữ liệu sẵn chưa?

Kết luận định vị

Dự án nên được trình bày như một nền tảng chuyển đổi số cấp phường có thể mở rộng theo từng giai đoạn. Giai đoạn prototype cần chứng minh ba giá trị:

• Người dân và doanh nghiệp có một cửa số để xem thông tin, đăng ký dịch vụ và gửi phản ánh.
• Cán bộ có nơi tiếp nhận, phân công, xử lý và báo cáo công việc.
• Lãnh đạo có dashboard, thông báo và công cụ AI để điều hành nhanh hơn.