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

Workflow AI cho Spa: lịch, consent và chăm sóc

Workflow từ lịch dịch vụ đến chăm sóc trước và sau liệu trình dành cho Spa

Tình huống: vì sao một lịch hẹn chưa phải là workflow

Một khách đặt lịch qua Zalo, lễ tân nhập vào lịch dùng chung, chuyên viên nhận ghi chú và quản lý muốn gửi thông tin trước buổi hẹn. Nếu chỉ nối các công cụ bằng một trigger, hệ thống có thể lấy nhầm phiên bản hướng dẫn, dùng kênh chưa được đồng ý hoặc gửi lại khi lỗi mạng. Điểm khó không nằm ở việc “AI viết được tin nhắn”, mà ở chuỗi trạng thái phải khớp trước khi một nội dung ra khỏi vùng nháp.

Workflow AI cho Spa trong bài này dùng một nguyên tắc: máy chuẩn hóa dữ liệu và tạo DRAFT; con người có thẩm quyền duyệt nội dung và hành động gửi. Tài liệu chăm sóc phải là bản đã được duyệt cho đúng dịch vụ, không phải lời khuyên AI tự tạo. Khi khách mô tả phản ứng bất thường, luồng thông thường dừng và chuyển người có chuyên môn phụ trách; AI không chẩn đoán, đánh giá mức độ hay đề xuất xử trí.

Mục tiêu thực tế là giảm lịch thiếu trường, tránh dùng sai consent, giữ một hàng chờ duyệt rõ ràng và truy vết được mỗi lần gửi. Các số liệu ví dụ dưới đây chỉ là minh họa cho cách thiết kế. Đội Spa cần thay bằng ngưỡng vận hành của mình sau khi kiểm thử trên phạm vi nhỏ.

Đầu ra và phạm vi của quy trình

Mỗi appointment_packet cần có appointment_id, service_code, scheduled_at, contact_channel, consent_scope, template_version và owner. Kết quả không chỉ là một tin nhắn; nó gồm trạng thái lịch, DRAFT, quyết định duyệt, send_receipt hoặc error_code. Nhờ đó quản lý biết nội dung nào đang chờ, nội dung nào đã gửi và nội dung nào phải xử lý thủ công.

Phạm vi nên bắt đầu với một cơ sở, một nhóm dịch vụ có tài liệu ổn định và một kênh liên hệ. Không đưa nội dung tiếp thị vào consent xác nhận lịch. Không tự tạo ưu đãi, tặng thêm, hoàn tiền hay đền bù khi khách phản hồi. Những quyết định đó thuộc người có thẩm quyền và chỉ được chèn khi có bản ghi phê duyệt cụ thể.

Workflow không thu ảnh khách hoặc thông tin sức khỏe để “cá nhân hóa” nội dung. Nếu quy trình chuyên môn riêng cần dữ liệu nhạy cảm, tổ chức phải có cơ sở, biểu mẫu, vùng lưu và quyền phù hợp; dữ liệu đó không đi vào Canva hoặc prompt chung. Trong pilot hành chính, dùng mã khách và chỉ trường cần cho lịch cùng consent.

Dữ liệu nguồn và hợp đồng trạng thái

Lịch là nguồn cho thời gian và dịch vụ; kho tài liệu là nguồn cho nội dung đã duyệt; sổ consent quyết định mục đích và kênh được phép; danh bạ nội bộ xác định người duyệt hoặc người nhận chuyển tuyến. Mỗi nguồn có owner và phiên bản. Khi hai nguồn mâu thuẫn, workflow ghi CONFLICT và dừng, không chọn giá trị mới hơn theo phỏng đoán.

Định nghĩa trạng thái trước khi viết automation: NEW, NEED_INFO, CONSENT_OK, DRAFT_READY, IN_REVIEW, APPROVED, SENT, RETRY_PENDING, MANUAL và ESCALATED. Chỉ người có vai trò phù hợp được chuyển IN_REVIEW sang APPROVED. APPROVED gắn với đúng hash nội dung; nếu DRAFT thay đổi thì phê duyệt cũ hết hiệu lực.

Đặt idempotency_key từ appointment_id, message_type và template_version để một lần retry không tạo hai tin giống nhau. Send_receipt giữ channel_message_id và thời điểm trả về. Nếu kênh không xác nhận, hệ thống không tự kết luận đã gửi; nó đặt UNKNOWN_DELIVERY và đưa vào hàng kiểm tra thủ công.

Sáu bước từ lịch đến log và retry

Bước 1 — Nhận và kiểm lịch: đọc bản ghi lịch mới hoặc thay đổi, chuẩn hóa mã dịch vụ, múi giờ và kênh. Thiếu appointment_id, dịch vụ hoặc thời điểm thì ghi NEED_INFO; lễ tân bổ sung tại hệ nguồn. AI không tự điền từ hội thoại cũ.

Bước 2 — Kiểm consent đúng mục đích: đối chiếu consent cho liên hệ lịch hẹn hoặc nội dung chăm sóc theo quy định nội bộ. Consent hết hiệu lực, bị rút hoặc không rõ phạm vi khiến packet chuyển BLOCKED. Không dùng consent tiếp thị để thay cho consent vận hành.

Bước 3 — Tạo DRAFT từ tài liệu đã duyệt: lấy đúng template_version cho service_code, chèn trường lịch và giữ nguyên các lưu ý đã được người phụ trách phê duyệt. Không thêm con số về thời gian, lượng nước, SPF hoặc hành vi chăm sóc nếu tài liệu nguồn không có.

Bước 4 — Con người duyệt rồi mới gửi: lễ tân kiểm lịch và cách xưng hô; người có thẩm quyền phụ trách dịch vụ duyệt phần chuyên môn khi nội dung có phần đó. Chỉ bản nháp có APPROVED_BY, APPROVED_AT và content_hash mới được chuyển sang bước gửi.

Bước 5 — Ghi nhận sau dịch vụ và soạn DRAFT tiếp theo: sau khi chuyên viên xác nhận hoàn tất, hệ thống có thể chọn đúng mẫu chăm sóc đã duyệt để tạo nháp. Phản hồi chứa biểu hiện bất thường lập tức đi ESCALATED; không đưa qua mẫu trả lời thường.

Bước 6 — Lưu log, retry và đối soát: ghi input_version, decision, người duyệt, send_receipt và lỗi. Chỉ retry lỗi kỹ thuật theo giới hạn đã cấu hình; lỗi consent, nội dung hoặc quyền phải chuyển MANUAL. Hết số lần thử thì dừng, không vòng lặp vô hạn.

Workflow AI cho Spa từ lịch, consent, DRAFT, duyệt đến log và retry — Luồng minh họa giữ cửa duyệt trước mỗi lần gửi và tách retry kỹ thuật khỏi lỗi nghiệp vụ.

Nhánh lỗi, sai lầm và điều kiện dừng

Lịch thiếu trường quay lại lễ tân; không tìm thấy template đúng phiên bản quay về owner tài liệu; consent không hợp lệ dừng ở BLOCKED. Nếu nội dung được sửa sau phê duyệt, hệ thống tạo content_hash mới và yêu cầu duyệt lại. Không có khái niệm “quá hạn thì tự thông qua”.

Lỗi gửi được chia thành tạm thời, không xác định và vĩnh viễn. Lỗi tạm thời có thể retry với cùng idempotency_key; trạng thái không xác định cần đối soát channel_message_id; sai người nhận, sai quyền hoặc kênh bị từ chối chuyển MANUAL. Mọi retry đều có giới hạn và khoảng cách do quản trị viên cấu hình, không lấy một con số chung cho mọi nền tảng.

Nội dung có dấu hiệu phản ứng bất thường, câu hỏi yêu cầu chẩn đoán hoặc khiếu nại phức tạp đi thẳng ESCALATED. AI chỉ tóm tắt nguyên văn tối thiểu, mã lịch và kênh liên hệ; người có chuyên môn hoặc quản lý tiếp nhận. Không tự gửi khuyến mại, lời xin lỗi kèm bồi hoàn hay hướng dẫn chăm sóc để “xoa dịu”.

Năm prompt hỗ trợ từng cửa kiểm soát

Prompt 1 kiểm appointment_packet, Prompt 2 đánh giá consent theo quy tắc nội bộ, Prompt 3 tạo DRAFT từ tài liệu đã duyệt, Prompt 4 lập checklist cho người duyệt và Prompt 5 đối soát log–retry. Chúng phục vụ trạng thái workflow, khác với bộ prompt nội dung, nhắc lịch và phản hồi ở bài chuyên biệt.

Mỗi prompt nhận dữ liệu có mã nguồn, không nhận ảnh khách hoặc đoạn hội thoại dư thừa. Đầu ra cần có status, missing_fields và next_owner. Nếu không tìm thấy tài liệu hoặc quy tắc tương ứng, mô hình phải trả BLOCKED; một câu trả lời ngắn nhưng truy vết được tốt hơn một bản nháp trôi chảy mà không có căn cứ.

Triển khai công cụ mà không mở quyền quá rộng

Google Calendar hoặc phần mềm quản lý Spa giữ lịch chính. Google Sheets có thể làm hàng chờ DRAFT và log trong pilot nếu cột nguồn được bảo vệ. Base.vn hoặc hệ quản lý việc theo dõi người duyệt và hạn xử lý. Zalo OA nhận nội dung sau khi phê duyệt và khi consent phù hợp; không dùng thao tác quét hội thoại hàng loạt để tự gom dữ liệu.

Một lớp automation có thể đọc sự kiện, gọi AI, tạo task duyệt và đẩy bản đã duyệt sang connector. Cần service account riêng, secret nằm ngoài Sheet, quyền tối thiểu, log bất biến và môi trường thử. Canva không tham gia luồng chứa lịch, consent, ảnh hoặc ghi chú sức khỏe; nếu cần thiết kế template, chỉ đưa asset thương hiệu không gắn khách.

Bảng trạng thái minh họa cho lịch hẹn, DRAFT, phê duyệt, gửi và lỗi tại Spa — Bảng trạng thái minh họa giúp đội vận hành biết bản ghi đang chờ dữ liệu, chờ duyệt hay cần xử lý thủ công.

AI làm gì và từng người duyệt gì

AI chuẩn hóa packet, so khớp service_code, kiểm trường consent theo quy tắc, chọn template và tạo DRAFT. Nó có thể phát hiện thay đổi nội dung, gắn nhãn lỗi và soạn tóm tắt chuyển tuyến. AI không xác nhận lịch thay khách, không phê duyệt, không diễn giải phản ứng và không tự thay đổi tài liệu nguồn.

Lễ tân chịu trách nhiệm lịch, danh tính kênh liên hệ và thao tác sửa tại hệ nguồn. Quản lý Spa sở hữu SLA, quyền, mẫu giao tiếp và quyết định ngoại lệ thương mại. Người có chuyên môn phụ trách dịch vụ duyệt tài liệu cùng trường hợp vượt ranh giới. Quản trị viên quản lý kết nối, retry, log và khôi phục. Không để một vai trò tự soạn, tự duyệt và tự gửi.

Kiểm thử trước khi dùng với khách thật

Chạy test với lịch hợp lệ, lịch thiếu trường, lịch đổi sau khi tạo DRAFT, consent bị rút, template hết hiệu lực, hai lần trigger trùng và lỗi kênh không rõ trạng thái. Thêm tình huống khách mô tả phản ứng bất thường để xác nhận luồng dừng. Dùng dữ liệu giả hoặc đã ẩn danh và viết trước kết quả mong đợi.

Đo tỷ lệ packet đủ trường, DRAFT dùng đúng phiên bản, phê duyệt còn hiệu lực, lần gửi có receipt, retry không trùng và chuyển tuyến đúng. Đếm riêng phần người duyệt phải sửa. Không lấy số tin đã gửi hoặc tỷ lệ đặt lịch làm bằng chứng AI tạo ra hiệu quả nếu chưa có thiết kế đo phù hợp.

Pilot nên có nút tắt connector, cách xuất hàng chờ, người trực xử lý thủ công và lịch rà quyền. Một lỗi vượt consent, gửi chưa duyệt hoặc tiếp tục trả lời tình huống bất thường là điều kiện dừng ngay, điều tra log và sửa trước khi chạy lại.

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

Dữ liệu minh họa: appointment_id SPA-204, service_code SV-07, scheduled_at 14:00, consent_scope APPOINTMENT, template_version PRE-SV07-v3. AI tạo DRAFT-91 và trạng thái IN_REVIEW. Lễ tân xác nhận lịch, người phụ trách duyệt nội dung, hệ thống gửi bằng idempotency_key SPA-204|PRE|v3 rồi lưu channel_message_id. Một sự kiện lặp lại được nhận diện là duplicate và không gửi thêm.

Có thể tự gửi tin ngay khi có lịch mới không?

Không theo workflow này. Hệ thống chỉ tạo DRAFT; nội dung và thông tin lịch phải được người có quyền duyệt trước khi gửi.

Nếu khách không có consent phù hợp thì sao?

Gắn BLOCKED và chuyển lễ tân xử lý theo quy trình của tổ chức; không đổi sang một kênh khác hoặc dùng consent tiếp thị thay thế.

AI có được viết hướng dẫn chăm sóc mới không?

Không. AI chỉ lắp ghép DRAFT từ tài liệu đúng dịch vụ, đúng phiên bản đã được người phụ trách phê duyệt; thiếu nguồn thì dừng.

Retry thế nào để không gửi trùng?

Dùng idempotency_key, giới hạn số lần thử, lưu receipt và đối soát trạng thái không xác định trước khi thử lại.

Đọc bản đồ dữ liệu và quyền cho Spa, dùng bộ prompt giao tiếp có guardrail hoặc liên hệ NganAds qua Zalo 0983543063 để thiết kế pilot trên công cụ hiện có.

Workflow

Bước 1: Nhận và kiểm bản ghi lịch — Chuẩn hóa appointment_id, service_code, thời gian và kênh. Thiếu trường thì NEED_INFO và chuyển lễ tân; AI không sửa hệ nguồn.
Bước 2: Đối chiếu consent — Kiểm scope, kênh, hiệu lực và nguồn consent cho đúng mục đích. Không phù hợp thì BLOCKED, không tự đổi kênh hoặc mục đích.
Bước 3: Tạo DRAFT chăm sóc — Chọn đúng template đã duyệt theo dịch vụ và phiên bản, chèn trường lịch tối thiểu. Không có tài liệu hợp lệ thì dừng.
Bước 4: Duyệt trước khi gửi — Lễ tân kiểm lịch; người có thẩm quyền duyệt phần chuyên môn. Chỉ content_hash đã ký nhận mới được chuyển sang kênh.
Bước 5: Ghi nhận và tạo DRAFT tiếp theo — Sau xác nhận hoàn tất, chọn mẫu sau dịch vụ đã duyệt. Phản ứng bất thường chuyển ESCALATED, không dùng kịch bản thường.
Bước 6: Lưu log, retry và đối soát — Ghi phiên bản, quyết định, receipt và lỗi. Chỉ retry lỗi kỹ thuật có giới hạn; lỗi nghiệp vụ hoặc quyền chuyển MANUAL.

Prompt mẫu

Kiểm appointment packet

MỤC TIÊU: Kiểm tra một bản ghi lịch trước khi đi vào workflow chăm sóc của Spa.

[ĐẦU VÀO]
- Bản ghi: [APPOINTMENT_ID, SERVICE_CODE, SCHEDULED_AT, CONTACT_CHANNEL]
- Schema bắt buộc: [DANH SÁCH TRƯỜNG VÀ KIỂU]
- Quy tắc trùng lịch: [QUY TẮC NỘI BỘ]

YÊU CẦU: Không lấy dữ liệu từ cuộc trò chuyện cũ để tự bù. Trường thiếu phải nêu rõ và giao lại lễ tân; không sửa lịch nguồn.

ĐỊNH DẠNG ĐẦU RA: {status: READY|NEED_INFO|CONFLICT, normalized_fields: {}, missing_fields: [], next_owner: ..., source_ref: ...}.

VÍ DỤ ĐIỀN SẴN: SPA-204 có service_code SV-07 và thời gian 14:00 nhưng thiếu contact_channel; kết quả NEED_INFO, next_owner lễ tân.

Mở cửa consent cho đúng mục đích

MỤC TIÊU: Đối chiếu consent của một lịch hẹn với loại nội dung và kênh dự kiến.

[ĐẦU VÀO]
- Consent record: [SCOPE, CHANNEL, GRANTED_AT, WITHDRAWN_AT, SOURCE]
- Message purpose: [XÁC NHẬN LỊCH|CHĂM SÓC|TIẾP THỊ]
- Chính sách hiện hành: [PHIÊN BẢN VÀ QUY TẮC]

NGUYÊN TẮC: Không suy diễn consent, không dùng scope tiếp thị thay cho vận hành và không đổi kênh để né trạng thái bị chặn.

ĐỊNH DẠNG ĐẦU RA: quyết định CONSENT_OK hoặc BLOCKED, evidence_fields, lý do ngắn và người xử lý tiếp.

VÍ DỤ ĐIỀN SẴN: consent chỉ cho APPOINTMENT qua Zalo; yêu cầu gửi nội dung tiếp thị; kết quả BLOCKED, chuyển quản lý consent.

Tạo DRAFT từ tài liệu đã duyệt

MỤC TIÊU: Soạn bản nháp chăm sóc cho đúng dịch vụ bằng cách chỉ dùng tài liệu nguồn được phê duyệt.

[ĐẦU VÀO]
- Lịch đã kiểm: [MÃ LỊCH, DỊCH VỤ, THỜI GIAN]
- Tài liệu: [TEMPLATE_VERSION, APPROVED_TEXT, OWNER]
- Cách xưng hô cho phép: [QUY ƯỚC]

RÀNG BUỘC: Giữ nguyên ý chuyên môn; không thêm thời gian, lượng nước, SPF, cam kết kết quả, ưu đãi hoặc chẩn đoán. Thiếu đúng phiên bản thì trả BLOCKED.

ĐỊNH DẠNG ĐẦU RA: DRAFT gồm subject, body, template_version, source_ref, content_hash và status IN_REVIEW.

VÍ DỤ ĐIỀN SẴN: SV-07 dùng PRE-SV07-v3; chèn khung giờ 14:00; mọi lưu ý lấy nguyên từ approved_text; chưa gửi.

Lập checklist phê duyệt

MỤC TIÊU: Giúp người duyệt rà một DRAFT trước khi ký nhận, không thay người duyệt ra quyết định.

[ĐẦU VÀO]
- DRAFT: [NỘI DUNG, CONTENT_HASH]
- Appointment packet: [TRƯỜNG LỊCH]
- Consent decision: [KẾT QUẢ VÀ SOURCE]
- Template source: [PHIÊN BẢN]

KIỂM TRA: đúng người, lịch, dịch vụ, consent, tài liệu; không claim tuyệt đối; không lời khuyên ngoài nguồn; không khuyến mại hoặc bồi hoàn tự phát.

ĐỊNH DẠNG ĐẦU RA: checklist PASS/FAIL theo từng mục, điểm cần sửa và trường APPROVER_ACTION để trống cho con người.

VÍ DỤ ĐIỀN SẴN: DRAFT-91 khớp lịch nhưng template_version đã đổi; đánh FAIL và yêu cầu tạo lại, không kế thừa phê duyệt cũ.

Đối soát log và quyết định retry

MỤC TIÊU: Phân loại sự kiện gửi lỗi để quyết định retry kỹ thuật, kiểm tra thủ công hoặc dừng.

[ĐẦU VÀO]
- Send log: [IDEMPOTENCY_KEY, ATTEMPT, ERROR_CODE, CHANNEL_MESSAGE_ID]
- Giới hạn hệ thống: [MAX_ATTEMPT, RETRYABLE_CODES]
- Trạng thái consent và approval: [STATUS, CONTENT_HASH]

QUY TẮC: Chỉ retry khi consent và approval còn hiệu lực, lỗi nằm trong danh sách kỹ thuật cho phép và chưa có receipt. Sai quyền, sai nội dung hoặc trạng thái không rõ phải MANUAL.

ĐỊNH DẠNG ĐẦU RA: RETRY_PENDING|UNKNOWN_DELIVERY|MANUAL|STOP, lý do, bằng chứng và next_action.

VÍ DỤ ĐIỀN SẴN: attempt 1 gặp timeout, chưa có channel_message_id, approval còn hiệu lực; kết quả RETRY_PENDING với cùng idempotency_key.

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

Có thể tự gửi tin ngay khi có lịch mới không?

Không theo workflow này. Hệ thống chỉ tạo DRAFT; nội dung và thông tin lịch phải được người có quyền duyệt trước khi gửi.

Nếu khách không có consent phù hợp thì sao?

Gắn BLOCKED và chuyển lễ tân xử lý theo quy trình của tổ chức; không đổi sang một kênh khác hoặc dùng consent tiếp thị thay thế.

AI có được viết hướng dẫn chăm sóc mới không?

Không. AI chỉ lắp ghép DRAFT từ tài liệu đúng dịch vụ, đúng phiên bản đã được người phụ trách phê duyệt; thiếu nguồn thì dừng.

Retry thế nào để không gửi trùng?

Dùng idempotency_key, giới hạn số lần thử, lưu receipt và đối soát trạng thái không xác định trước khi thử lại.

Bài liên quan

Thử workflow trên một nhóm lịch đã ẩn danh, giữ cửa duyệt trước khi gửi và chỉ mở rộng sau khi các nhánh consent, lỗi kênh và chuyển tuyến đều đạt.