Bạn muốn tạo một ứng dụng để team tiếp nhận và xử lý yêu cầu hỗ trợ khách hàng.
Ý tưởng ban đầu khá rõ: ghi lại khách cần gì, giao người xử lý và theo dõi đến khi hoàn tất. Nhưng khi bắt đầu xây, bạn gặp một loạt thuật ngữ: Space, App, Entity, Field, Record.
Mỗi từ gọi tên một phần khác nhau trong hệ thống. Hãy thử nhìn chúng qua một tình huống cụ thể.
Khách hàng Lan gửi yêu cầu: “Mình không đăng nhập được tài khoản.”
Team cần lưu yêu cầu này, ghi nhận người phụ trách và cập nhật tiến độ xử lý.
1. Space: không gian làm việc chứa các ứng dụng
Space là nơi các app được tạo và vận hành, thường gắn với việc quản trị người dùng và quyền truy cập.
Trong ví dụ này, công ty có một Space chứa các ứng dụng phục vụ công việc. App hỗ trợ khách hàng được tạo trong không gian đó.
Khi bắt đầu, câu hỏi cần làm rõ là: ứng dụng sẽ nằm ở đâu và những ai sẽ tham gia sử dụng?
2. App: ứng dụng tổ chức một công việc cụ thể
Team tạo App “Hỗ trợ khách hàng” để tiếp nhận và xử lý các yêu cầu.
Trong app, team thiết kế dữ liệu cần lưu, màn hình làm việc, luồng xử lý và quyền của từng vai trò.
Chẳng hạn:
- Nhân viên tiếp nhận ghi nhận yêu cầu.
- Người phụ trách cập nhật kết quả xử lý.
- Leader theo dõi những yêu cầu còn tồn đọng.
Câu hỏi ở bước này là: app giúp những ai thực hiện công việc gì, từ lúc bắt đầu đến khi hoàn tất?
3. Entity: nhóm đối tượng cần lưu dữ liệu
Entity là thực thể dữ liệu, có thể hình dung như một bảng chứa các cột và dòng.
Trong App “Hỗ trợ khách hàng”, team cần lưu các yêu cầu nên tạo Entity “Yêu cầu hỗ trợ”.
Nếu cần quản lý thông tin khách hàng riêng, team có thể thiết kế thêm Entity “Khách hàng”. Việc lựa chọn phụ thuộc vào dữ liệu và cách công việc thực tế diễn ra.
Câu hỏi cần trả lời là: mình đang quản lý những loại đối tượng nào?
4. Field: từng thông tin cần biết về đối tượng
Field là một thuộc tính trong Entity, tương tự một cột trong bảng.
Với Entity “Yêu cầu hỗ trợ”, các field có thể gồm:
- Mã yêu cầu.
- Khách hàng.
- Nội dung cần hỗ trợ.
- Người phụ trách.
- Trạng thái.
- Thời điểm tiếp nhận.
Mỗi field nên phục vụ một nhu cầu rõ ràng. “Người phụ trách” giúp biết ai đang xử lý. “Thời điểm tiếp nhận” giúp theo dõi yêu cầu đã chờ bao lâu.
Trước khi thêm một field, hãy hỏi: ai sẽ dùng thông tin này, và dùng để làm gì?
5. Record: một đối tượng cụ thể được ghi nhận
Record là một bản ghi trong Entity, tương tự một dòng trong bảng.
Yêu cầu của khách hàng Lan sẽ được lưu thành một record:
| Field | Giá trị minh họa |
|---|---|
| Mã yêu cầu | HT-001 |
| Khách hàng | Lan |
| Nội dung cần hỗ trợ | Không đăng nhập được tài khoản |
| Người phụ trách | Minh |
| Trạng thái | Đang xử lý |
Khi khách hàng khác gửi một yêu cầu mới, team tạo thêm record trong cùng Entity “Yêu cầu hỗ trợ”.
Khi Minh xử lý xong yêu cầu HT-001, Minh cập nhật thông tin trên record đó.
Nhìn lại toàn bộ cấu trúc
| Thành phần | Trong ví dụ |
|---|---|
| Space | Không gian làm việc của công ty |
| App | Hỗ trợ khách hàng |
| Entity | Yêu cầu hỗ trợ |
| Field | Nội dung, người phụ trách, trạng thái… |
| Record | Yêu cầu HT-001 của khách hàng Lan |
Một điểm dễ nhầm khi mới bắt đầu: thêm trường “Người phụ trách” là tạo Field. Nhập một yêu cầu hỗ trợ mới là tạo Record trong Entity đã thiết kế.
Hiểu cấu trúc này giúp Solution Builder chuyển một tình huống công việc thành dữ liệu rõ ràng: cần quản lý đối tượng nào, lưu thông tin gì và cập nhật ra sao.
Theo bạn, trong app Hỗ trợ khách hàng, “Yêu cầu hỗ trợ” và “Yêu cầu HT-001 của khách hàng Lan”, đâu là Entity, đâu là Record?
