Kiến thức / Làm đẹp – Chăm sóc cá nhân / Spa / Thẩm mỹ

5 prompt AI cho Spa: nội dung, lịch và phản hồi

Bộ prompt soạn nội dung dịch vụ, nhắc lịch và phân loại phản hồi cho Spa: copy và tùy chỉnh

Tình huống: một prompt trôi chảy vẫn có thể gây lỗi

Nhân viên cần viết mô tả dịch vụ, nhắc một lịch sắp tới và trả lời phản hồi trên Zalo. Nếu chỉ yêu cầu “viết hấp dẫn và chốt khách”, AI dễ thêm lợi ích chưa được xác nhận, tự tạo khuyến mại hoặc biến câu hỏi về tình trạng thành lời tư vấn. Một đoạn văn nghe tự nhiên không đồng nghĩa với việc đúng nguồn, đúng consent và đúng quyền.

Bộ prompt AI cho Spa trong bài này luôn tạo DRAFT. Người dùng phải cung cấp tài liệu dịch vụ đã duyệt, bản ghi lịch tối thiểu, quy tắc consent và danh bạ chuyển tuyến. AI được phân loại nhu cầu hành chính, không đánh giá tình trạng. Nếu khách nhắc phản ứng bất thường hoặc hỏi theo hướng chẩn đoán, đầu ra chuyển ESCALATE_PROFESSIONAL mà không diễn giải biểu hiện.

Năm prompt phục vụ năm tác vụ khác nhau: nội dung dịch vụ trung tính, nhắc lịch, triage hành chính, phản hồi thông thường và bản tóm tắt bàn giao tình huống vượt ranh giới. Chúng không thay bản đồ quyền hoặc workflow gửi. Bài bản đồ quyết định AI được phép làm gì; bài workflow kiểm soát consent, duyệt, log và retry.

Dữ liệu chuẩn bị cho việc giao AI

Với nội dung dịch vụ, cần service_code, mô tả đã duyệt, quy trình được phép công khai, đối tượng và giới hạn diễn đạt, bảng giá cùng ngày hiệu lực. Không đưa ảnh khách, ghi chú sức khỏe hoặc nội dung trao đổi riêng vào prompt. Nếu muốn dùng một feedback làm dẫn chứng, phải có quy trình và quyền sử dụng phù hợp; bộ prompt không mặc định cho phép.

Với nhắc lịch, chỉ dùng appointment_id, tên xưng hô theo quy ước, dịch vụ, thời gian, địa điểm, kênh và consent_status. Dữ liệu dùng thử nên thay tên bằng mã. Với phản hồi, giữ phần nguyên văn tối thiểu cần để phân luồng, mã hội thoại và trạng thái; không sao chép toàn bộ lịch sử chỉ để AI “hiểu thêm”.

Mỗi nguồn có version, owner và approved_at. Quy định nội bộ cần nêu rõ loại nội dung nào lễ tân duyệt, loại nào quản lý duyệt và khi nào chuyển người có chuyên môn phụ trách dịch vụ. Thiếu owner, nguồn hết hiệu lực hoặc consent không khớp thì không chạy prompt; gắn BLOCKED và xử lý dữ liệu trước.

Ranh giới AI và người duyệt dùng chung

Đầu tiên, yêu cầu mô hình chỉ dùng dữ liệu trong đầu vào và đánh dấu CHƯA_CÓ thay vì bù bằng kiến thức chung. Mọi kết quả mang trạng thái DRAFT, source_ref và người duyệt dự kiến. Không tự gửi, không tự đăng, không sửa lịch nguồn và không lấy sự im lặng của người duyệt làm phê duyệt.

Thứ hai, cấm claim tuyệt đối, cam kết kết quả, chẩn đoán, đề xuất xử trí chuyên môn và hướng dẫn có con số không nằm trong tài liệu đã duyệt. Không tự thêm SPF, lượng nước, khoảng thời gian hay chống chỉ định. Nếu cần nội dung chuyên môn, prompt chỉ được trích đúng nguồn và người có thẩm quyền vẫn phải kiểm trước khi dùng.

Thứ ba, không tạo khuyến mại, quà tặng, hoàn tiền hoặc đền bù để làm câu trả lời hấp dẫn hơn. Phản hồi bất thường được chuyển tuyến, không gắn nhãn bệnh hay mức độ y tế. Triage ở đây chỉ là phân loại hành chính như hỏi giá, đặt lịch, đổi lịch, yêu cầu thông tin, phản hồi thường hoặc cần chuyển người phụ trách.

Prompt 1: nội dung dịch vụ trung tính

Prompt đầu phù hợp khi Spa đã có factsheet nhưng cần chuyển thành bài giới thiệu rõ ràng cho website, fanpage hoặc tài liệu tư vấn. Đầu vào nên nêu kênh, giới hạn ký tự, giọng thương hiệu và CTA được phép. Hãy loại khỏi factsheet mọi claim chưa có owner; AI không có nhiệm vụ “làm mạnh” một tuyên bố yếu.

Kết quả cần phân biệt thông tin có nguồn với trường thiếu. Cấu trúc gợi ý gồm tiêu đề mô tả, dịch vụ là gì theo tài liệu, quy trình công khai, thông tin khách cần biết trước khi đặt lịch và CTA trung tính như hỏi thêm hoặc chọn khung giờ. Không dùng before–after, nỗi sợ hoặc câu hứa thay đổi chắc chắn.

Prompt 2: DRAFT nhắc lịch từ bản ghi đã xác nhận

Prompt nhắc lịch không đọc lịch trực tiếp và không quyết định gửi. Nó nhận một appointment_packet đã qua kiểm tra, template_version và consent_decision. Đầu ra phải nhắc lại thời gian, địa điểm, mã liên hệ và cách yêu cầu đổi lịch theo chính sách đã cung cấp; trường chưa có được đánh dấu để lễ tân bổ sung.

Tách thông tin vận hành khỏi tiếp thị. Một khách đồng ý nhận xác nhận lịch không có nghĩa là đồng ý nhận ưu đãi. Prompt không chèn bán thêm, mã giảm giá hoặc dịch vụ khác. Sau khi tạo, lễ tân so với lịch nguồn; chỉ workflow có phê duyệt mới được chuyển sang kênh gửi.

Prompt 3: triage hành chính, không chẩn đoán

Phân loại hữu ích khi hàng chờ có nhiều câu hỏi lẫn nhau. Bộ nhãn nên nhỏ và có owner: BOOKING, RESCHEDULE, PRICE_INFO, SERVICE_INFO, ORDINARY_FEEDBACK, COMPLAINT_REVIEW và ESCALATE_PROFESSIONAL. AI không gán “nhẹ”, “nặng”, “dị ứng” hay tên tình trạng; các nhãn đó có thể trở thành diễn giải chuyên môn ngoài thẩm quyền.

Kết quả nên giữ quote tối thiểu, lý do chọn nhãn, trường còn thiếu và next_owner. Nếu một tin vừa hỏi lịch vừa mô tả phản ứng bất thường, ưu tiên ESCALATE_PROFESSIONAL và dừng bản nháp thường. Người có chuyên môn phụ trách tiếp nhận; AI không đưa lời khuyên tạm thời để lấp khoảng chờ.

Prompt 4 và 5: phản hồi thường và bàn giao

Prompt 4 dùng cho phản hồi hành chính hoặc trải nghiệm thông thường đã được phân loại, ví dụ khách muốn đổi giờ hoặc góp ý về thời gian chờ. DRAFT cần xác nhận đã tiếp nhận, nhắc lại đúng vấn đề, nêu bước tiếp theo có owner và không hứa một kết quả ngoài quy trình. Mọi khuyến mại hoặc đền bù để trống cho quản lý quyết định.

Prompt 5 không trả lời khách; nó soạn handoff_note cho quản lý hoặc người có chuyên môn. Ghi mã lịch, quote nguyên văn tối thiểu, thời điểm, hành động đã xảy ra, dữ liệu còn thiếu và kênh liên hệ được phép. Không suy luận nguyên nhân và không chuyển ảnh hoặc hồ sơ nhạy cảm qua Canva, email cá nhân hay bảng dùng chung.

Hai prompt này cần tách vì một câu trả lời giao tiếp và một bản bàn giao nội bộ có người đọc, mục đích và quyền khác nhau. Dùng handoff_note như tin trả lời sẽ lộ thông tin nội bộ; dùng mẫu trả lời thường cho tình huống bất thường lại che mất tín hiệu cần chuyển tuyến.

Workflow dùng prompt có cửa duyệt

Bước 1 — Chọn tác vụ và nguồn: xác định đang viết nội dung, nhắc lịch hay xử lý phản hồi; gắn source_ref cùng version. Không trộn nhiều mục đích trong một lần gọi.

Bước 2 — Thu nhỏ dữ liệu: chỉ lấy trường cần, kiểm consent và ẩn thông tin không phục vụ đầu ra. Thiếu consent hoặc owner thì BLOCKED.

Bước 3 — Chạy prompt để tạo DRAFT: lưu prompt_version, input_ref và kết quả. AI không ghi vào lịch nguồn và không tự đưa nội dung sang kênh.

Bước 4 — Kiểm guardrail: rà claim, nguồn, trường tự thêm, nội dung chuyên môn, khuyến mại và trạng thái chuyển tuyến. Fail bất kỳ mục nào thì trả lại hàng sửa.

Bước 5 — Người có quyền duyệt: lễ tân duyệt thông tin lịch; quản lý duyệt truyền thông và ngoại lệ thương mại; người có chuyên môn duyệt phần thuộc dịch vụ. Bản sửa phải được duyệt lại.

Bước 6 — Gửi qua workflow và lưu log: chỉ bản APPROVED mới sang kênh. Lưu receipt, lỗi và người xử lý; retry kỹ thuật theo giới hạn, còn lỗi nghiệp vụ chuyển thủ công.

Workflow sử dụng prompt AI cho Spa từ nguồn, DRAFT, kiểm guardrail đến người duyệt — Năm prompt chỉ tạo DRAFT; quyền duyệt và gửi nằm trong workflow vận hành riêng.

Triển khai công cụ, kiểm thử và sai lầm

Có thể lưu factsheet và bảng kiểm ở Google Sheets, quản lý phiên bản task trên Base.vn, dùng Canva cho asset thương hiệu không chứa dữ liệu khách và đưa bản đã duyệt lên fanpage hoặc Zalo OA bằng quy trình được cấp quyền. Việc một công cụ có connector không chứng minh luồng dữ liệu đã hợp lệ; quản trị viên vẫn phải kiểm account, secret, scope và log.

Test mỗi prompt bằng ví dụ đủ nguồn, thiếu nguồn, claim quá mức, consent sai mục đích, lịch đã thay đổi, phản hồi thường và phản ứng bất thường. Viết trước expected_status. Prompt đạt không chỉ khi văn phong tốt mà còn khi biết từ chối thêm dữ liệu, giữ DRAFT và chuyển đúng owner.

Sai lầm thường thấy là dùng một prompt cho mọi trường hợp, chép cả hội thoại vào mô hình, để AI tự chọn ưu đãi, hoặc gửi khi hàng duyệt quá hạn. Sai lầm khác là yêu cầu AI viết “hướng dẫn chung” rồi dùng cho nhiều dịch vụ. Hãy dùng nguồn đúng phiên bản, khóa hành động gửi và rà log theo mẫu lỗi thay vì chỉ đọc vài kết quả đẹp.

Bộ thẻ minh họa năm prompt Spa với nguồn dữ liệu, trạng thái và người duyệt — Visual minh họa tách năm intent để tránh dùng prompt nội dung cho lịch hoặc tình huống chuyển tuyến.

Kết quả mẫu và câu hỏi thường gặp

Dữ liệu minh họa: tin MSG-71 ghi “Tôi muốn đổi lịch chiều mai và có một phản ứng lạ sau buổi trước”. Prompt triage trả ESCALATE_PROFESSIONAL, quote tối thiểu, appointment_id, consent_channel và next_owner là người có chuyên môn phụ trách; không soạn hướng dẫn, không gắn tên tình trạng. Yêu cầu đổi lịch được ghi như secondary_request để lễ tân xử lý sau khi người phụ trách tiếp nhận.

Có thể copy prompt rồi dùng ngay với khách thật không?

Chưa. Cần thay biến bằng nguồn đã duyệt, chạy dữ liệu thử, xác định người duyệt và để đầu ra ở trạng thái DRAFT.

Prompt có được tự thêm ưu đãi để tăng đặt lịch không?

Không. Chỉ dùng ưu đãi có mã, thời hạn và phê duyệt trong đầu vào; nếu không có thì không đề cập.

Phân loại phản hồi có phải là đánh giá chuyên môn không?

Không. Triage chỉ định tuyến hành chính; nội dung nhắc phản ứng bất thường hoặc yêu cầu chẩn đoán phải chuyển người có chuyên môn.

Ai duyệt nội dung trước khi gửi?

Lễ tân xác nhận lịch, quản lý duyệt truyền thông và ngoại lệ thương mại, còn người có thẩm quyền phụ trách dịch vụ duyệt phần chuyên môn.

Đối chiếu bản đồ rủi ro, dữ liệu và quyền, triển khai theo workflow lịch–consent–DRAFT–duyệt hoặc liên hệ NganAds qua Zalo 0983543063 để tùy chỉnh prompt theo quy trình hiện tại.

Workflow

Bước 1: Chọn đúng intent và nguồn — Xác định nội dung, lịch, triage, phản hồi thường hay bàn giao; gắn source_ref và version. Không trộn nhiều mục đích trong một prompt.
Bước 2: Kiểm dữ liệu và consent — Thu nhỏ trường đầu vào, kiểm owner, hiệu lực và consent. Thiếu căn cứ thì BLOCKED, không tự bổ sung từ lịch sử.
Bước 3: Tạo DRAFT có cấu trúc — Chạy prompt với version cố định, lưu input_ref và đầu ra. AI không sửa lịch, đăng bài hoặc gửi tin.
Bước 4: Kiểm guardrail — Rà claim, nguồn, nội dung chuyên môn, ưu đãi, bồi hoàn và dấu hiệu chuyển tuyến. Fail thì trả lại hàng sửa.
Bước 5: Người có quyền phê duyệt — Lễ tân duyệt lịch, quản lý duyệt truyền thông hoặc ngoại lệ, người có chuyên môn duyệt phần dịch vụ. Bản sửa phải duyệt lại.
Bước 6: Gửi qua workflow và lưu log — Chỉ bản APPROVED mới sang kênh; lưu receipt và lỗi. Retry kỹ thuật có giới hạn, lỗi nghiệp vụ chuyển thủ công.

Prompt mẫu

Soạn nội dung dịch vụ trung tính

MỤC TIÊU: Chuyển factsheet đã duyệt thành một DRAFT giới thiệu dịch vụ Spa rõ ràng, trung tính và có thể kiểm nguồn.

[ĐẦU VÀO]
- Service code và tên: [MÃ, TÊN ĐÃ DUYỆT]
- Factsheet: [MÔ TẢ, QUY TRÌNH ĐƯỢC PHÉP CÔNG KHAI, GIÁ, NGÀY HIỆU LỰC]
- Kênh và độ dài: [WEBSITE|FANPAGE|TỜ THÔNG TIN]
- Giọng thương hiệu, CTA được phép: [QUY ƯỚC]

GIỚI HẠN: Không thêm claim tuyệt đối, before–after, chẩn đoán, kết quả chắc chắn, hướng dẫn ngoài factsheet hoặc khuyến mại không có mã phê duyệt.

ĐỊNH DẠNG ĐẦU RA: title, summary, public_process, customer_info, neutral_cta, source_ref, missing_fields và status DRAFT.

VÍ DỤ ĐIỀN SẴN: SV-12; factsheet v4 chỉ mô tả quy trình công khai và giá hiệu lực; CTA “Liên hệ để xem lịch phù hợp”; không hứa kết quả.

Tạo DRAFT nhắc lịch đã xác nhận

MỤC TIÊU: Soạn một tin nhắc lịch từ appointment packet hợp lệ mà không chèn bán thêm.

[ĐẦU VÀO]
- Lịch: [APPOINTMENT_ID, DỊCH VỤ, THỜI GIAN, ĐỊA ĐIỂM]
- Kênh và consent: [CHANNEL, CONSENT_STATUS, SOURCE]
- Template: [VERSION, APPROVED_TEXT]
- Cách đổi lịch: [QUY TRÌNH ĐÃ DUYỆT]

YÊU CẦU: Thiếu trường hoặc consent không phù hợp thì trả BLOCKED. Không thêm ưu đãi, dịch vụ khác, hướng dẫn không có trong template và không tự gửi.

ĐỊNH DẠNG ĐẦU RA: message_draft tối đa [GIỚI HẠN] ký tự, appointment_ref, template_version, review_checks và status IN_REVIEW.

VÍ DỤ ĐIỀN SẴN: SPA-308, SV-12, 15:30 tại cơ sở A, consent APPOINTMENT qua Zalo; đầu ra là DRAFT chờ lễ tân đối chiếu.

Phân loại hành chính tin nhắn đến

MỤC TIÊU: Gán một nhãn điều phối cho tin nhắn Spa mà không đánh giá tình trạng hay mức độ y tế.

[ĐẦU VÀO]
- Message id và nội dung tối thiểu: [ID, QUOTE]
- Bộ nhãn: [BOOKING, RESCHEDULE, PRICE_INFO, SERVICE_INFO, ORDINARY_FEEDBACK, COMPLAINT_REVIEW, ESCALATE_PROFESSIONAL]
- Bảng owner: [NHÃN → VAI TRÒ]

QUY TẮC ƯU TIÊN: Nếu có phản ứng bất thường hoặc yêu cầu chẩn đoán, chọn ESCALATE_PROFESSIONAL; không đặt tên tình trạng, không khuyên xử trí và không tạo câu trả lời thường.

ĐỊNH DẠNG ĐẦU RA: {label, quoted_evidence, secondary_request, missing_fields, next_owner, response_allowed}.

VÍ DỤ ĐIỀN SẴN: “Tôi muốn đổi lịch và thấy phản ứng lạ”; label ESCALATE_PROFESSIONAL, secondary_request RESCHEDULE, response_allowed false.

Soạn phản hồi hành chính thông thường

MỤC TIÊU: Tạo DRAFT phản hồi cho góp ý hoặc yêu cầu hành chính đã được xác nhận là không thuộc nhánh chuyên môn.

[ĐẦU VÀO]
- Nhãn và nội dung: [ORDINARY_FEEDBACK|RESCHEDULE|COMPLAINT_REVIEW, QUOTE]
- Thông tin đã xác minh: [MÃ LỊCH, SỰ KIỆN, OWNER]
- Quy trình tiếp theo: [BƯỚC, KÊNH, NGƯỜI PHỤ TRÁCH]
- Giọng thương hiệu: [QUY ƯỚC]

RÀNG BUỘC: Không nhận lỗi pháp lý, không hứa thời hạn ngoài quy trình, không tự cấp khuyến mại, hoàn tiền hoặc đền bù. Nếu xuất hiện dấu hiệu bất thường thì dừng và đổi sang ESCALATE_PROFESSIONAL.

ĐỊNH DẠNG ĐẦU RA: acknowledgement, verified_summary, next_step, owner, prohibited_commitments_check và status DRAFT.

VÍ DỤ ĐIỀN SẴN: khách góp ý chờ lâu; bước tiếp theo là quản lý xem log lịch; DRAFT xác nhận đã tiếp nhận, không hứa bồi hoàn.

Tạo ghi chú bàn giao vượt ranh giới

MỤC TIÊU: Tóm tắt tối thiểu một trường hợp cần chuyển quản lý hoặc người có chuyên môn, không soạn lời tư vấn cho khách.

[ĐẦU VÀO]
- Case ref và appointment ref: [MÃ]
- Quote nguyên văn cần thiết: [TRÍCH ĐOẠN]
- Thời điểm, kênh, consent liên hệ: [DỮ LIỆU]
- Hành động đã thực hiện: [ĐÃ DỪNG MẪU THƯỜNG, ĐÃ THÔNG BÁO AI]
- Danh bạ nhận bàn giao: [VAI TRÒ]

CẤM: Suy luận nguyên nhân, chẩn đoán, đánh giá mức độ, khuyên xử trí, hứa đền bù hoặc chuyển ảnh và hồ sơ nhạy cảm ngoài vùng được phép.

ĐỊNH DẠNG ĐẦU RA: handoff_note gồm facts_only, missing_information, recipient_role, allowed_contact_channel, audit_ref và status ESCALATED.

VÍ DỤ ĐIỀN SẴN: CASE-19 liên quan SPA-308; quote “có phản ứng lạ”; không có ảnh; recipient_role chuyên viên phụ trách dịch vụ; chưa gửi nội dung chăm sóc.

Câu hỏi thường gặp

Có thể copy prompt rồi dùng ngay với khách thật không?

Chưa. Cần thay biến bằng nguồn đã duyệt, chạy dữ liệu thử, xác định người duyệt và để đầu ra ở trạng thái DRAFT.

Prompt có được tự thêm ưu đãi để tăng đặt lịch không?

Không. Chỉ dùng ưu đãi có mã, thời hạn và phê duyệt trong đầu vào; nếu không có thì không đề cập.

Phân loại phản hồi có phải là đánh giá chuyên môn không?

Không. Triage chỉ định tuyến hành chính; nội dung nhắc phản ứng bất thường hoặc yêu cầu chẩn đoán phải chuyển người có chuyên môn.

Ai duyệt nội dung trước khi gửi?

Lễ tân xác nhận lịch, quản lý duyệt truyền thông và ngoại lệ thương mại, còn người có thẩm quyền phụ trách dịch vụ duyệt phần chuyên môn.

Bài liên quan

Chọn một prompt, điền nguồn đã duyệt và chạy trên dữ liệu thử; chỉ đưa vào workflow thật sau khi guardrail, người duyệt và nhánh chuyển tuyến đều hoạt động.