Help Center cho SaaS - kho chứa user manual

[Series Tập sự học nói]

Xin chàoooooo là mình đây.

Cũng kha khá lâu ngày mình không ‘ngọ nguậy’ trên đây, có ai nhớ mình không ạ =)))

Mình có. Mình tự nhớ mình, nhớ ngồi hý hoáy viết blog dạt dào ý tưởng và sắp xếp nó có hệ thống mỗi cuối tuần.

Dạo giờ mình trải qua một số ‘công chuyện’ cá nhân, có lẽ ‘mải mê’ đắm chìm một xíu nên đã có người nhắc: “Tháng 6 chưa ra bài mới đâu đấy!”

(Thoắt cái hết nửa năm mọi người nhỉ, thật lòng không nghĩ nhiều quá, chỉ là biết ơn, biết ơn vì chúng ta vẫn ổn theo một cách nào đó, vẫn ở đây để đọc được bài của nhau.)

Tuần này mình khởi động bằng 1 bài topic nhẹ nhàng không quá nặng về chuyên môn, về cách team mình đã thiết lập kho user manual - Help Center cho app. Cùng bắt đầu thôi!

---

1. Product manual/user guide là gì?

Là tài liệu hướng dẫn cách sử dụng các tính năng cần thiết của sản phẩm, cung cấp đầy đủ thông tin về installation, operation, maintenance hay troubleshooting.

Help Center chính là nơi tập hợp user guide về ‘một hệ thống’, nơi ‘cứu cánh’ người dùng lúc cần kíp khi sử dụng ứng dụng.

Tại sao chúng ta lại cần xây Help Center?

• Giảm bớt sự phụ thuộc vào email/chat support của user, tăng chất lượng customer onboarding

• Giảm tải khối lượng cho team support/CS

• Định hình trải nghiệm 1 sản phẩm SaaS chuyên nghiệp

2. Các bước tạo nên Help Center

2.1 Ai là người sẽ dùng Help Centre của bạn?

Là người dùng cuối không rành kỹ thuật? Là các chủ shop bận rộn? Là developer cần cấu hình API?

Viết cho người dùng phổ thông sẽ khác hẳn với viết cho team kỹ thuật – về từ ngữ, cách trình bày, và cả giọng điệu. Nên tùy thuộc vào Product, hãy xác định đúng Target User sử dụng Help Center để biết được mình nên viết như thế nào nhé ^^

2.2 Thiết kế cấu trúc của Help Center

Đây là bước quan trọng để định hình Help Center của bạn trông như thế nào. Đặt mình vào vị trí người dùng app kết hợp những core function của app, tự vạch ra những mục chính mà một user chưa biết gì về app có thể vào đọc - hiểu - làm theo - sử dụng.

Tham khảo cấu trúc Help Center của các SaaS như:

• Notion

• Slack

• Shopify

• Intercom
  → Xem cách họ chia nhỏ feature, dùng headline, format nội dung thế nào để học hỏi thêm.

Có nhiều cách thiết kế cấu trúc 1 Help Center, phần nhiều phụ thuộc vào tính chất product & người dùng của app.

Ta có thể chia thành những function chính như Intercom, chia theo topic người dùng cần tìm khi có hệ sinh thái lớn như Shopify, hoặc chia dạng Troubleshooting như Slack.

Nhìn chung, 1 Help Center thường có:

• Getting Started
  Cho user mới: hướng dẫn thiết lập cơ bản, cài đặt, connect account, v.v.

• Core Features
  Mỗi tính năng lớn là một category riêng, trong đó có các bài:

  • What is [feature]?

  • How to use [feature]

  • Best practices

• Settings & Configuration
  Cho user muốn tinh chỉnh: thông báo, phân quyền, tag, triggers,...

• Integrations
  Hướng dẫn kết nối với các nền tảng bên thứ ba partnerships

• Troubleshooting
  Các lỗi phổ biến & cách xử lý (dành cho CS, giảm số ticket)

2.3 Set up articles list & content structure

Sau khi bạn đã xác định được nhóm chủ đề/tính năng chính cần viết, giờ cần lên danh sách các bài viết (mục 2.2) và thiết lập content structure chung cho từng bài viết. Mục đích của bước này:

• Tạo danh sách bài viết hướng dẫn người dùng (how-to) cho mọi tính năng quan trọng trong app.

• Đảm bảo không sót tính năng, kể cả các bước nhỏ hoặc ngữ cảnh phụ (edge case).

• Giúp team tài liệu luôn cập nhật được khi app thay đổi logic, UI hoặc thêm feature.

✅ Bước 1: Xác định các nhóm chức năng chính

Lấy từ: Sitemap → Navigation trong app → Sidebar menu → Main tab

Tips: Nếu bạn có file Product requirement, Feature spec, hoặc User onboarding map - dựa vào đó để bắt đầu gom nhóm.

---

✅ Bước 2: Với mỗi nhóm chức năng, liệt kê tất cả các user action có thể làm được

Tự hỏi:

• Người dùng có thể làm gì với tính năng này?

• Có hành động nào cần nhiều bước không?

• Có thao tác nào thường bị nhầm lẫn hoặc hỏi support nhiều không?

• Có gì liên quan đến config / cài đặt / enable / disable / auto / manual?

→ Mỗi user action nên có 1 bài how-to riêng
→ Không dồn quá nhiều thao tác vào 1 bài (đọc khó, SEO không tốt)

Ví dụ:

❌ Bad: “How to use the widget” (quá rộng)
✅ Good:

• How to set up data collection

• How to add welcome message

---

✅ Bước 3: Đưa vào bảng tổng hợp article

Tạo bảng với các cột như:

• Category

• Article title (How to…)

• Meta Description

• Slug

Ảnh: Articles list template tham khảo của team mình

Content structure:

1. Introduction (1–3 câu): Tóm tắt mục đích của bài viết, kết quả người dùng sẽ đạt được, và nếu cần, định nghĩa khái niệm mới.

2.Prerequisites (nếu có): Những điều kiện cần chuẩn bị trước khi làm theo hướng dẫn.

3. Step-by-step instructions: Viết từng bước cụ thể, mỗi bước 1 đoạn riêng

4. Troubleshooting / FAQs (nếu có): Trả lời các câu hỏi thường gặp hoặc vấn đề thường phát sinh

5. Related articles: Liệt kê các bài viết liên quan giúp người đọc hiểu sâu hơn hoặc thao tác tiếp theo

6. Outro: Encourage customers to take action và Customer support details

   • Email address

   • Live chat link

2.4 Xây Writing guideline

Phần này, mình thấy team mình rất chi tiết và hệ thống, cụ thể là chị Leader cũ của mình đã xây ra được bộ guideline writing để đảm bảo đúng format của 1 user guide, vừa đảm bảo bài viết chuẩn SEO.

Title

Title của user guide cần ngắn gọn, rõ ràng và tập trung vào hành động. Lý tưởng nhất, nó nên dài từ 45 đến 70 ký tự, sử dụng thì hiện tại (không dùng -ing), và đưa từ khóa chính lên đầu.

Các từ khóa kiểu “How to”, “What is”, “Where to find” thường rất hiệu quả, vì chúng đánh trúng vào nhu cầu tìm kiếm của người dùng.

Ví dụ, thay vì viết “Setting up auto-tagging for tickets” → “How to set up auto-tagging in MooseDesk”.

Một lưu ý nhỏ nhưng quan trọng: title và H1 (heading đầu tiên trong bài) không nên giống hệt nhau, nhưng vẫn cần dùng cùng từ khóa chính để giữ sự nhất quán trong định vị bài viết.

Meta description

Meta description không ảnh hưởng đến thứ hạng SEO, nhưng nó lại cực kỳ quan trọng để tăng tỷ lệ người dùng click vào bài. Xem nó như phần giới thiệu trong thư mời – nếu hấp dẫn, người ta sẽ mở tiếp =)))

Meta description dài khoảng 140–160 ký tự.

Slug

Slug là phần cuối của URL. Dù người dùng thường không để ý đến nó, nhưng đối với team content, đây là nơi thể hiện sự chỉn chu và tối ưu SEO.

Nhớ rằng luôn dùng từ khóa chính, giữ slug ngắn gọn (tầm 3–5 từ), không dùng ký tự đặc biệt, viết thường và ngăn cách bằng dấu gạch ngang. Tránh lặp từ khóa, tránh thêm các từ vô nghĩa như “the”, “a”, “of”, vì sẽ làm slug dài dòng mà không thêm giá trị gì.

Ví dụ: clarify.app/docs/add-custom-domain thay vì clarify.app/docs/how-to-add-a-custom-domain-to-your-workspace.

Writing guideline

Nên sử dụng ngôi thứ nhất số nhiều trong mọi bài viết (“we”, “our team”) để giữ tone trung tính và chuyên nghiệp. Tránh dùng “I” hay “me” vì nó dễ khiến bài viết trở nên quá cá nhân hoặc thiếu nhất quán nếu nhiều người cùng tham gia viết.

Mỗi bài viết đều được chia thành các bước cụ thể, mỗi bước là một đoạn văn tách biệt, tránh để user thấy lằng nhằng =)))

Khi nhắc đến các phần trong giao diện, làm nổi bật bằng cách viết hoa tên tính năng hoặc nút bấm (như “Settings”, “Inbox”), và để tên nút trong dấu ngoặc kép (ví dụ: click “Save”).

Không dùng dấu “>” để mô tả thao tác (kiểu: click > chọn > kéo). Dấu “>” chỉ nên dùng để mô tả đường dẫn vị trí, như: Dashboard > FAQ > Create.

Mỗi khi bài viết có nhắc đến thuật ngữ kỹ thuật hoặc chức năng đặc biệt, giải thích ngắn gọn ngay lần đầu xuất hiện. Không ai thích đang đọc hướng dẫn lại phải bật tab Google để tìm hiểu một khái niệm lạ lẫm.

Cuối mỗi bài, nếu có điều gì cần lưu ý hoặc cảnh báo, đặt trong các khung chú thích nhỏ với định dạng thống nhất – ví dụ: Note, Tip, hoặc Caution. Điều này giúp người đọc dễ nhận diện thông tin quan trọng mà không bị chìm giữa dòng chữ.

2.5 Blog Publishing Checklist

Về nội dung

Kiểm tra bài viết đã tuân theo đúng content guideline ở trên chưa?
Đảm bảo đầy đủ cấu trúc cơ bản gồm: phần mở đầu, phần hướng dẫn chi tiết, mục liên kết bài viết liên quan và block FAQ/troubleshooting nếu có.

Đảm bảo full document gồm:

• 1. Summary section

• 2. SEO Analysis

• 3. Outline

• 4. Topic research References

• 5. The actual piece of content

Về từ khoá và độ dài bài viết

Check từ khoá chính xuất hiện ở tiêu đề và đoạn mở đầu. Sau đó, kiểm tra độ phủ keyword trong toàn bài ở mức 2–3%, bằng các công cụ như wordcounter.net.

Độ dài chuẩn cho một bài Help Centre chi tiết thường từ 1500–1800 từ, tối đa khoảng 2800 từ nếu là hướng dẫn sâu hoặc bài tổng hợp.
Mỗi đoạn văn chỉ nên giới hạn trong khoảng 150 từ, để người đọc không bị "đuối" giữa một khối chữ dài ngoằng.

Về hình ảnh

Ảnh trong bài viết cần:

• Rõ ràng, chụp đúng UI ở ngữ cảnh đang nói tới

• Không chứa email, order ID hay thông tin nhạy cảm

• Kích thước không vượt quá 1024px, dung lượng < 200KB

Có thể nén ảnh bằng công cụ tinypng.com trước khi đưa lên. Nếu dùng GIF hướng dẫn nhanh, tụi mình dùng ezgif.com để cắt gọn và tối ưu.

Về link

Kiểm tra kỹ:

• Internal Link sẽ mở trong cùng tab

• External Link sẽ mở ở tab mới – tránh mất flow đọc của người dùng

2.5 Gắn manual vào trong in-app

Viết tài liệu hay đến mấy mà người dùng không biết nó tồn tại thì cũng bằng không kkk.

Help Centre không chỉ là một nơi người dùng đến, mà cần phải là một phần trong hành trình trải nghiệm của họ.

A Help Centre should come to the user — not wait for the user to come to it.

1. Tooltip hoặc nút “?” ngay cạnh từng field

Ở trong app sẽ có những khái niệm hơi mới với người dùng. Thay vì mô tả dài dòng, ta có thể thêm một nút “?” nhỏ bên cạnh mỗi mục. Khi người dùng rê chuột vào, sẽ hiện ra tooltip giải thích ngắn + liên kết mở bài viết Help Centre liên quan.

Ví dụ: “Auto-Tagging rules?” → hover vào nút sẽ hiện:
“Automatically assign tags based on condition. Learn how it works”

2. Gợi ý FAQ theo ngữ cảnh trong Live Chat widget

Ta có thể tích hợp phần gợi ý bài viết ngay trong widget chat. Khi người dùng mở widget, nếu họ đang ở trang “Orders”, hệ thống sẽ ưu tiên gợi ý các bài như:

• “How to track my order?”

• “Where to find order history?”

Tất nhiên, điều này đòi hỏi hệ thống hiểu được context người dùng đang ở đâu.

3. Embed tài liệu ở các trang Settings

Ở những trang như “Settings”, “Team management”, hoặc “Billing” – dành một góc nhỏ (thường là bottom hoặc sidebar) để embed đường dẫn hoặc preview mini của bài viết Help Centre tương ứng.

Không cần phải đọc hết – nhưng nếu có nhu cầu, người dùng luôn biết nơi để tìm hiểu thêm.

Việc gắn tài liệu vào trong app chính là contextual support – hỗ trợ đúng thời điểm người dùng cần mà không làm gián đoạn trải nghiệm.

---

TẠM KẾT

Vậy là xong rồi, xin phép ‘tự hào’ nhẹ vì cuối cùng tui cũng sắp xếp được bài này thành 1 hệ thống, đâu đó vẫn chắp vá, đâu đó vẫn chưa thông suốt, nhưng ít ra có dày công, có tâm sức, vậy là đủ giải phóng những gì còn kẹt trong đầu.

Dạo giờ app tui đang làm mấy feature mới, dòng đời đưa đẩy nên khả năng sắp tới mình cũng sẽ học thêm về PO. Rất mong hữu duyên được kết nối về mảng sản phẩm này, mình quá nhỏ bé để có thể thảo luận sâu, nhưng mình có chí, chắc mọi thứ lại ổn thui nhỉ.

Có câu này mình tâm đắc: Bạn không chọn công việc, bạn chọn phong cách sống. Làm Product, có thể ‘kiến tạo’ giá trị & thấy được sự tác động của mình tới users - thiết nghĩ, một lifestyle như thế, rất đáng để thử!