วิธีสร้าง Gem ตอบลูกค้า ให้เป็น AI Customer Service

หากธุรกิจต้องตอบคำถามเดิมจากลูกค้าทุกวัน เช่น ราคาเท่าไร เปิดกี่โมง ส่งสินค้ากี่วัน รับประกันไหม คืนสินค้าได้หรือไม่ หรือควรแก้ปัญหาเบื้องต้นอย่างไร เราสามารถสร้าง Gemini Gem สำหรับตอบลูกค้า ให้ทำหน้าที่เหมือน AI Customer Service ส่วนตัวได้

Gem สามารถถูกกำหนดให้รู้ล่วงหน้าว่า

• ต้องพูดกับลูกค้าอย่างไร
• ใช้น้ำเสียงแบบไหน
• ควรตอบสั้นหรือยาว
• ใช้ข้อมูลจากไฟล์ใด
• ห้ามสร้างราคาเอง
• ห้ามสร้าง Policy เอง
• ห้ามรับปาก Refund โดยไม่มีข้อมูล
• หากข้อมูลไม่พอควรทำอย่างไร

จากนั้นแทนที่พนักงานจะต้องเขียน Prompt เดิมซ้ำทุกครั้ง เพียงนำข้อความลูกค้ามาให้ Gem เช่น

“ลูกค้าถามว่าของส่งกี่วัน”

Gem ก็สามารถใช้ Instructions และ Knowledge ที่ตั้งไว้เพื่อสร้าง Draft คำตอบ ได้ทันที

Workflow ที่แนะนำที่สุดคือ

ข้อความลูกค้า → Gem วิเคราะห์ → สร้าง Draft → คนตรวจ → ส่งจริง

ไม่ควรเริ่มจาก

ข้อความลูกค้า → AI ส่งเองทันที

โดยเฉพาะเรื่องราคา การคืนเงิน การรับประกัน หรือปัญหาที่อาจมีผลต่อธุรกิจ

🤖 AI Customer Service Gem คืออะไร

AI Customer Service Gem คือ Custom Gemini Gem ที่ถูกออกแบบให้ช่วยจัดการคำถามลูกค้าโดยเฉพาะ

ตัวอย่างงานที่สามารถช่วยได้ เช่น

• สร้าง Draft คำตอบลูกค้า
• ตอบ FAQ
• อธิบายสินค้า
• อธิบายบริการ
• แนะนำขั้นตอนใช้งาน
• ช่วยแก้ปัญหาเบื้องต้น
• สรุปปัญหาของลูกค้า
• เปลี่ยนข้อความยาวให้กระชับ
• ปรับ Tone ให้สุภาพ
• แปลคำตอบหลายภาษา
• ช่วยจัดประเภท Ticket
• แนะนำว่าควรส่งเรื่องต่อทีมใด

ข้อดีสำคัญคือสามารถกำหนดกติกาเหล่านี้ไว้ใน Gem ได้ถาวร

❶ เริ่มจากกำหนดว่า Gem นี้ทำหน้าที่อะไร

อย่าสร้าง Gem ด้วยคำสั่งกว้าง ๆ เช่น

“เป็น Customer Service ที่เก่งที่สุด”

เพราะ Gem ยังไม่รู้ว่าต้องทำอะไรบ้าง

ควรกำหนด Scope ให้ชัด

ตัวอย่าง

“สร้าง Draft คำตอบสำหรับคำถามทั่วไปเกี่ยวกับสินค้า การจัดส่ง การรับประกัน และวิธีใช้งาน โดยใช้ข้อมูลจาก Knowledge ที่กำหนด”

นี่บอกหน้าที่ชัดกว่า

🎯 Scope ตัวอย่าง

Gem นี้ทำ

• Product Questions
• Shipping Questions
• Warranty Questions
• Basic Troubleshooting

แต่ไม่ทำ

• อนุมัติ Refund
• เปลี่ยน Order
• แก้ Payment
• ตัดสินข้อพิพาท
• ให้คำแนะนำทางกฎหมาย

การกำหนด Scope ช่วยลดความเสี่ยงที่ AI ตอบเกินหน้าที่

❷ กำหนดว่าใครคือลูกค้า

Customer Service สำหรับลูกค้าทั่วไปกับลูกค้าองค์กรควรใช้ Tone ต่างกัน

👤 ลูกค้าทั่วไป

ควร

• ใช้ภาษาง่าย
• กระชับ
• ไม่ใช้ศัพท์ Technical เยอะ

🏢 ลูกค้าองค์กร

อาจใช้

• Professional Tone
• รายละเอียดมากขึ้น
• Terminology ทางธุรกิจ

🎯 Instruction ตัวอย่าง

“ลูกค้าส่วนใหญ่เป็นผู้ใช้ทั่วไปในประเทศไทยที่ไม่มีความรู้ Technical ให้ใช้ภาษาง่ายและอธิบายขั้นตอนทีละข้อ”

ช่วยให้คำตอบเหมาะกับ Audience

❸ เปิด Gemini Gems และสร้าง Gem ใหม่

เปิด Gemini ผ่าน Browser

จากนั้นไปยัง

Gems → New Gem

ตั้งชื่อ เช่น

Customer Service Assistant

หรือ

Customer Reply

จากนั้นเขียน Instructions

หากมีข้อมูลบริษัท ให้เพิ่มในส่วน Knowledge

แล้วทดลองใน Preview ก่อน Save

🎯 Workflow

New Gem → Name → Instructions → Knowledge → Preview → Save

❹ ตั้งชื่อ Gem ให้เข้าใจง่าย

ตัวอย่างที่ดี

Customer Service

Customer Reply Assistant

Product Support

Sales Support

Technical Support

❌ หลีกเลี่ยง

AI Helper

Gem 2

Assistant Final

เพราะเมื่อมี Gems หลายตัวจะเลือกผิดง่าย

❺ ใช้ Persona + Task + Context + Format

สามารถออกแบบ Customer Service Gem ด้วยสูตรนี้

👤 Persona

Gem เป็นใคร

🎯 Task

ต้องช่วยอะไร

🧠 Context

ข้อมูลธุรกิจและลูกค้าคืออะไร

📄 Format

คำตอบต้องหน้าตาอย่างไร

ตัวอย่าง

“คุณเป็น Customer Service Assistant สำหรับบริษัท X มีหน้าที่สร้าง Draft คำตอบภาษาไทยที่สุภาพและกระชับจากข้อมูลใน Knowledge โดยห้ามสร้างราคา Policy หรือ Warranty ที่ไม่มีข้อมูล”

ประโยคเดียวมีองค์ประกอบสำคัญหลายส่วนแล้ว

❻ กำหนด Persona ให้เหมาะสม

Persona ตัวอย่าง

“คุณเป็นผู้ช่วย Customer Service ที่สุภาพ ใจเย็น และให้ข้อมูลตรงไปตรงมา”

ไม่จำเป็นต้องเขียนว่า

“คุณเป็น Customer Service อันดับ 1 ของโลก”

สิ่งที่สำคัญกว่าคือ Behavior เช่น

• สุภาพ
• ไม่โต้เถียง
• ไม่ประชด
• ไม่กล่าวโทษลูกค้า
• ไม่สร้างข้อมูล

❼ กำหนด Tone ของคำตอบ

Tone มีผลโดยตรงต่อประสบการณ์ลูกค้า

ตัวอย่างที่เหมาะกับหลายธุรกิจคือ

Friendly Professional

หมายถึง

สุภาพ

แต่ไม่แข็งเกินไป

💬 Instruction

“ใช้ภาษาไทยสุภาพ เป็นมิตร และเป็นมืออาชีพ ตอบตรงประเด็น หลีกเลี่ยงภาษาทางการเกินจำเป็นและอย่าใช้คำโฆษณาเกินจริง”

ช่วยรักษา Brand Voice

❽ กำหนดความยาวของคำตอบ

Customer Service ส่วนใหญ่ไม่ควรตอบเป็นบทความยาวทุกครั้ง

สามารถกำหนดว่า

“ตอบคำถามทั่วไปให้กระชับ หากต้องมีขั้นตอนให้ใช้รายการทีละข้อ และเพิ่มรายละเอียดเฉพาะเมื่อจำเป็น”

🎯 ตัวอย่าง

คำถาม

“ส่งกี่วัน”

ไม่ควรตอบ 10 ย่อหน้า

แต่คำถาม

“ติดตั้งแล้วใช้งานไม่ได้”

อาจต้องมี Troubleshooting หลายขั้น

ดังนั้นควรให้ Format ปรับตามโจทย์

❾ ให้ Gem ตอบคำถามหลักก่อน

Instruction สำคัญมากคือ

“ตอบสิ่งที่ลูกค้าถามโดยตรงก่อน แล้วค่อยเพิ่มรายละเอียดหรือขั้นตอนที่เกี่ยวข้อง”

ช่วยหลีกเลี่ยง Customer Service ที่เกริ่นยาว

❌ ไม่ดี

“ขอบพระคุณอย่างยิ่งที่ให้ความสนใจและไว้วางใจ…”

ยาวก่อนตอบ

✅ ดีกว่า

“โดยปกติใช้เวลาจัดส่ง 2–3 วันทำการครับ จากนั้น…”

ลูกค้าได้คำตอบเร็วกว่า

❿ เพิ่ม Knowledge ของบริษัท

Customer Service Gem จะมีประโยชน์มากขึ้นเมื่อเพิ่มไฟล์ Knowledge เช่น

📦 Product Guide

สินค้าและ Feature

🚚 Shipping Policy

การจัดส่ง

🛡️ Warranty

การรับประกัน

↩️ Return Policy

การคืนสินค้า

❓ FAQ

คำถามที่พบบ่อย

🛠️ Troubleshooting Guide

วิธีแก้ปัญหาเบื้องต้น

Gem สามารถใช้ข้อมูลเหล่านี้ช่วยสร้าง Draft ที่ตรงกับธุรกิจมากขึ้น

⓫ ใช้ Knowledge เป็น Source หลัก

หลังเพิ่มไฟล์แล้วควรกำหนด Instructions เพิ่ม

“สำหรับราคา Product Feature Warranty Shipping และ Return Policy ให้ใช้ Knowledge Files เป็นแหล่งข้อมูลหลัก”

ช่วยให้ Gem ไม่อาศัยความรู้ทั่วไปในเรื่องที่ต้องใช้ข้อมูลเฉพาะบริษัท

⓬ ถ้า Knowledge ไม่มีข้อมูล ต้องห้ามเดา

นี่เป็น Rule ที่สำคัญที่สุดข้อหนึ่ง

ใช้

“หากไม่พบข้อมูลใน Knowledge หรือข้อมูลไม่เพียงพอ ให้แจ้งว่าต้องตรวจสอบเพิ่มเติม ห้ามสร้างคำตอบขึ้นมาเอง”

ตัวอย่าง

ลูกค้าถาม

“รุ่นนี้รับประกัน 5 ปีใช่ไหม”

แต่ Knowledge ไม่มีข้อมูล

Gem ควรตอบประมาณว่า

“ยังไม่พบข้อมูลยืนยันเรื่องระยะเวลารับประกันจากข้อมูลที่มี แนะนำให้ตรวจสอบกับทีมที่เกี่ยวข้องก่อนตอบลูกค้าครับ”

ไม่ใช่เดา

“ใช่ รับประกัน 5 ปี”

⓭ ห้าม AI สร้างราคาเอง

หาก Gem ใช้ในฝ่ายขายหรือร้านค้า ต้องกำหนดชัด

“ห้ามสร้าง คาดเดา หรือประมาณราคา หากไม่มีราคาอยู่ใน Knowledge หรือข้อมูลที่ผู้ใช้ให้”

⚠️ เพราะ

AI สามารถสร้างตัวเลขที่ดูสมเหตุสมผลแต่ไม่มีจริง

เช่น

“ราคาเริ่มต้น 1,990 บาท”

ทั้งที่บริษัทไม่เคยตั้งราคานั้น

นี่สามารถสร้างปัญหากับลูกค้าได้ทันที

⓮ ห้าม AI สร้างส่วนลดหรือโปรโมชั่นเอง

เพิ่ม Rule

“ห้ามเสนอ Discount Promotion Coupon หรือของแถมที่ไม่ได้อยู่ในข้อมูล”

เพราะ AI อาจพยายามตอบเอาใจลูกค้า เช่น

“สามารถขอส่วนลด 10% ได้ครับ”

แม้บริษัทไม่มี Policy นี้

⓯ ห้าม AI สร้าง Warranty เอง

Warranty เป็น Claim สำคัญ

ควรกำหนด

“ตอบเรื่อง Warranty จาก Knowledge เท่านั้น ห้ามประมาณระยะเวลา เงื่อนไข หรือ Coverage”

และหากไม่พบ

ให้ Escalate

⓰ ห้าม AI สร้าง Return Policy

เช่นเดียวกัน

AI ไม่ควรสร้างเงื่อนไข

• คืนได้ 7 วัน
• คืนได้ 14 วัน
• คืนฟรี
• เปลี่ยนใหม่ทันที

ถ้าไม่ได้มีข้อมูลจริง

💬 Rule

“ห้ามสร้างเงื่อนไข Refund, Return หรือ Exchange หากไม่พบใน Knowledge”

⓱ ใช้ AI เป็น Draft ไม่ใช่ผู้อนุมัติ Refund

สิ่งนี้สำคัญมาก

Customer Service Gem ไม่ควรมี Instruction ว่า

“ถ้าลูกค้าไม่พอใจ ให้อนุมัติ Refund”

เพราะการอนุมัติ Refund อาจต้องใช้

• Order Data
• Policy
• Authority
• Human Decision

✅ Workflow ที่ปลอดภัยกว่า

AI อ่านปัญหา

↓

สรุป

↓

สร้าง Draft

↓

พนักงานตรวจ

↓

ตัดสินใจ

↓

ส่งคำตอบ

⓲ แยก FAQ ออกจากเรื่องต้อง Escalate

สามารถกำหนดได้ว่า

🟢 AI ตอบได้

• เวลาเปิด
• ขั้นตอนใช้งาน
• Feature
• Shipping ตาม Policy
• FAQ

🔴 ส่งต่อทีม

• Refund Dispute
• Payment Problem
• Legal Complaint
• ข้อมูลส่วนตัว
• Order Modification
• การเรียกร้องค่าเสียหาย

ช่วยลด Risk ของ Automation

⓳ สร้าง Escalation Rule

Instruction ตัวอย่าง

“หากคำถามเกี่ยวข้องกับการคืนเงิน การชำระเงิน ข้อพิพาท ข้อร้องเรียนร้ายแรง หรือข้อมูลที่ไม่มีใน Knowledge ให้สร้างคำตอบสั้น ๆ ว่าจะส่งเรื่องให้ทีมที่เกี่ยวข้องตรวจสอบ แทนการตัดสินใจเอง”

นี่เป็น Rule ที่ควรมีใน Gem ธุรกิจจำนวนมาก

⓴ ให้ AI สรุปปัญหาก่อนตอบ

สำหรับข้อความลูกค้ายาว ๆ Gem สามารถช่วยแยก Problem

ตัวอย่าง Customer Message:

“ซื้อมาเมื่ออาทิตย์ก่อน ตอนแรกใช้ได้ แต่วันนี้ไฟขึ้นสีแดง แล้วลองถอดปลั๊กแล้วก็ยังไม่หาย…”

Gem สามารถแยกเป็น

Issue: ไฟสถานะสีแดง

Tried: ถอดปลั๊กแล้ว

Need: Troubleshooting เพิ่มเติม

จากนั้นสร้าง Draft

ช่วยให้ Agent จับประเด็นเร็วขึ้น

㉑ สร้าง Workflow วิเคราะห์ Message

สามารถกำหนด Workflow

1. อ่านข้อความทั้งหมด
2. ระบุ Intent
3. ระบุข้อมูลสำคัญ
4. ตรวจ Knowledge
5. สร้าง Draft
6. ระบุหากต้อง Escalate

🎯 ตัวอย่าง Intent

• Product Question
• Shipping
• Warranty
• Troubleshooting
• Complaint
• Refund
• Sales

ช่วยจัดคำตอบให้เป็นระบบ

㉒ ให้ Gem แยก Intent ของลูกค้า

ตัวอย่าง Prompt

“วิเคราะห์ข้อความนี้ก่อน ระบุว่าเป็น Product, Shipping, Complaint หรือ Technical Support แล้วสร้าง Draft ตอบ”

มีประโยชน์มากหาก Agent ต้องจัด Ticket

㉓ สร้าง Customer Reply แบบสั้น

สำหรับ Chat Support สามารถกำหนด

“ตอบไม่เกิน 2–4 ย่อหน้าสั้นสำหรับคำถามทั่วไป และใช้ Bullet เฉพาะเมื่อมีหลายขั้นตอน”

ช่วยให้คำตอบเหมาะกับ Messenger, LINE หรือ Live Chat มากกว่าบทความยาว

㉔ สร้าง Customer Reply สำหรับ Email

หากใช้ Email สามารถสร้าง Format แยก

“เมื่อผู้ใช้ระบุว่าเป็น Email ให้สร้าง Greeting, Answer, Next step และ Closing แบบสุภาพ”

ช่วยให้ Gem ปรับ Surface

Chat กับ Email ได้ต่างกัน

㉕ เพิ่ม Brand Voice

หากบริษัทมี Tone เฉพาะ เช่น

• สุภาพแต่เป็นกันเอง
• ไม่ใช้คำว่า “เรียนลูกค้า”
• ใช้คำลงท้ายแบบเฉพาะ
• ห้าม Emoji

สามารถเพิ่มเป็น Instructions หรือ Knowledge

💬 ตัวอย่าง

“ใช้ Brand Voice ใน Knowledge เป็นหลักในการเขียนทุกข้อความ”

㉖ เพิ่ม FAQ เป็น Knowledge

FAQ เป็นหนึ่งในไฟล์ที่เหมาะกับ Customer Service Gem มากที่สุด

เช่น

Q: เปิดกี่โมง

A: 09:00–18:00

Q: ส่งสินค้าเมื่อไร

A: ภายใน 1 วันทำการ

Q: มีเก็บปลายทางไหม

A: …

จากนั้น Gem สามารถนำคำตอบไป Rewrite ให้เข้ากับบทสนทนา

㉗ เพิ่ม Product Catalog

หากต้องตอบเรื่องสินค้า ควรมีข้อมูล

• Product Name
• Model
• Feature
• Specification
• Compatibility

ที่ชัดเจน

Gem สามารถช่วยตอบ

“รุ่น A ต่างกับรุ่น B อย่างไร”

จาก Catalog ได้

⚠️ แต่ต้องตรวจ

Spec และ Model

ก่อนส่งลูกค้าในกรณีสำคัญ

㉘ เพิ่ม Troubleshooting Guide

สำหรับ Technical Support Gem สามารถเพิ่ม

• Error
• Symptom
• Cause
• Fix
• Escalation

ตัวอย่าง

ไฟแดง

1. ตรวจ Power
2. Restart
3. ตรวจ Cable
4. ถ้ายังไม่หาย ติดต่อ Support

Gem สามารถเปลี่ยนขั้นตอนเหล่านี้ให้เหมาะกับข้อความลูกค้า

㉙ อย่าใส่ข้อมูลเกินความจำเป็นใน Knowledge

Customer Service Gem ไม่จำเป็นต้องมี

• Payroll
• Employee Salary
• Profit Margin
• Internal Strategy
• Private Contract

ถ้าไม่เกี่ยวข้องกับ Customer Support

🎯 หลัก

AI ควรมีเฉพาะข้อมูลที่จำเป็นต่อ Role

㉚ ระวังข้อมูลลูกค้า

ไม่ควรออกแบบ Gem ให้ต้องได้รับข้อมูล Sensitive เกินจำเป็น

เช่น

• Password
• OTP
• เลขบัตร
• Full Card Number
• Credential

หากลูกค้าส่งข้อมูลลับมาโดยไม่ตั้งใจ ควรมี Workflow ที่ไม่ขอข้อมูลเพิ่มและจัดการตาม Policy ขององค์กร

㉛ ใส่ Rule ห้ามขอ Password

สามารถกำหนดชัด

“ห้ามขอ Password, OTP หรือข้อมูล Credential จากลูกค้า”

เป็น Rule ที่ดีสำหรับ Support Assistant

㉜ ใส่ Rule เรื่องข้อมูลส่วนตัว

ตัวอย่าง

“ขอเฉพาะข้อมูลที่จำเป็นต่อการช่วยเหลือ และหลีกเลี่ยงการขอข้อมูลส่วนบุคคลที่ไม่เกี่ยวกับปัญหา”

ช่วยลด Data Collection ที่ไม่จำเป็น

㉝ อย่าคิดว่า Knowledge ทำให้คำตอบถูก 100%

แม้ Gem มีไฟล์บริษัทครบ

Gem ยังสามารถ

• อ่านผิด
• ตีความผิด
• เชื่อมข้อมูลผิด
• สรุปผิด

ได้

ดังนั้นเรื่องสำคัญ เช่น

• ราคา
• Payment
• Warranty
• Refund
• Contract

ควรมี Human Review

㉞ ใช้ Citation ของ Knowledge เมื่อเหมาะสม

สำหรับ Team ภายใน การเปิด Knowledge Citations อาจช่วยตรวจว่า Gem ใช้ข้อมูลจากไฟล์ใด

ตัวอย่าง Gem ตอบ

“รับประกัน 2 ปี”

Agent สามารถตรวจ Source ก่อนส่งได้

เหมาะกับ Policy-heavy Workflow

㉟ ทดสอบคำถามง่ายก่อน

หลังสร้าง Gem แล้วใช้ Preview ถาม

“เปิดกี่โมง”

“ส่งกี่วัน”

“รุ่น A มีอะไรบ้าง”

ดูว่า Gem ใช้ Knowledge ถูกหรือไม่

㊱ ทดสอบคำถามที่ Knowledge ไม่มี

นี่สำคัญมาก

ถาม

“สินค้านี้ลด 50% ใช่ไหม”

ทั้งที่ไม่มี Promotion

ดูว่า Gem

✅ ควร

แจ้งว่าไม่พบข้อมูล

❌ ไม่ควร

สร้าง Promotion ขึ้นมาเอง

หากยังเดา ให้เพิ่ม Constraint

㊲ ทดสอบ Refund Question

ลอง

“ไม่พอใจ ขอคืนเงินเต็มจำนวนทันที”

ดูว่า Gem ตอบตาม Policy หรือไม่

ถ้าไม่มีข้อมูล

ควร Escalate

ไม่ควรรับปากแทนบริษัท

㊳ ทดสอบ Angry Customer

Customer Service Gem ต้องรับมือกับลูกค้าอารมณ์เสีย

ตัวอย่าง

“บริการแย่มาก จะไม่ซื้ออีกแล้ว!”

ควรออกแบบให้

• ไม่โต้เถียง
• ไม่ประชด
• ไม่กล่าวโทษ
• รับรู้ปัญหา
• มุ่งแก้สถานการณ์

💬 Instruction

“เมื่อผู้ใช้ไม่พอใจ ให้ใช้ภาษาสงบ ไม่โต้เถียง และเน้นขั้นตอนแก้ปัญหาหรือการส่งต่อทีม”

㊴ อย่าขอโทษจนเกินจริง

AI อาจตอบ

“เราผิดทั้งหมดและจะชดเชยทุกอย่าง”

ซึ่งอาจเกิน Authority

ควรกำหนด

“สามารถแสดงความเสียใจต่อประสบการณ์ที่ไม่ดีได้ แต่ห้ามยอมรับ Liability หรือสัญญาการชดเชยที่ไม่มี Policy รองรับ”

㊵ ทดสอบลูกค้าถามหลายเรื่องพร้อมกัน

เช่น

“รุ่นนี้ราคาเท่าไร ส่งกี่วัน และรับประกันไหม”

Gem ควรตอบครบทั้งสามประเด็น

สามารถกำหนด

“หากลูกค้าถามหลายคำถาม ให้แยกคำตอบตามประเด็นและอย่าข้ามคำถามใด”

㊶ ทดสอบข้อความคลุมเครือ

ลูกค้าอาจพิมพ์

“ใช้ไม่ได้”

AI ไม่มีข้อมูลพอ

Gem ควรไม่เดาปัญหา

✅ ควร

ถามข้อมูลที่จำเป็น เช่น

“รบกวนแจ้งอาการเพิ่มเติม เช่น เปิดไม่ติด หรือเปิดได้แต่เชื่อมต่อไม่ได้ครับ”

นี่เป็นกรณีที่ Follow-up Question มีประโยชน์

㊷ กำหนดเมื่อไรให้ถามเพิ่ม

Instruction

“หากยังไม่สามารถระบุปัญหาได้ ให้ถามคำถาม Follow-up ที่จำเป็นที่สุดครั้งละไม่เกิน 1–2 ข้อ”

ช่วยไม่ให้ลูกค้าถูกถาม 10 คำถามพร้อมกัน

㊸ อย่าถามข้อมูลที่มีอยู่แล้ว

Gem ควรใช้ Context ของข้อความก่อนถามซ้ำ

สามารถกำหนด

“ก่อนถามข้อมูลเพิ่ม ให้ตรวจว่าลูกค้าให้ข้อมูลนั้นมาแล้วหรือไม่”

ช่วยให้ Conversation เป็นธรรมชาติมากขึ้น

㊹ ให้ Gem สร้าง Draft หลาย Tone ได้

สำหรับบางธุรกิจสามารถสั่ง

“สร้างคำตอบ 2 แบบ: กระชับ และสุภาพเป็นทางการ”

Agent เลือกแบบที่เหมาะ

แต่ถ้า Workflow ต้องการความเร็ว อาจใช้ Style เดียวจะง่ายกว่า

㊺ ให้ Gem Rewrite ข้อความพนักงาน

Gem ไม่จำเป็นต้องตอบจากศูนย์เสมอไป

พนักงานสามารถเขียน Draft ก่อน เช่น

“ของหมด รออาทิตย์หน้า”

แล้วสั่ง

“ปรับให้สุภาพขึ้นโดยไม่เพิ่มข้อมูล”

Gem อาจช่วยเปลี่ยนเป็น

“ขณะนี้สินค้ารุ่นดังกล่าวหมดชั่วคราว คาดว่าจะมีสินค้าเข้ามาอีกครั้งในสัปดาห์หน้าครับ”

ช่วยรักษา Meaning แต่ปรับ Tone

㊻ ใช้ Gem ช่วยสรุป Ticket

หลัง Conversation ยาว สามารถสั่ง

“สรุปปัญหาลูกค้า สิ่งที่ทดลองแล้ว และสิ่งที่ต้องดำเนินการต่อ”

Output เช่น

Issue

เครื่องเปิดไม่ติด

Tried

เปลี่ยนสายไฟแล้ว

Next

ส่ง Technical Team

มีประโยชน์มากสำหรับ Handoff

㊼ ใช้ Gem ช่วยสร้าง Internal Note

Customer Reply กับ Internal Note ควรแตกต่างกัน

Customer Reply

ภาษาสุภาพ

Internal Note

เน้นข้อมูล

ตัวอย่าง

“ลูกค้ารายงานว่า Router รุ่น A เปิดไม่ติด ทดสอบ Adapter แล้ว ยังไม่หาย ต้องตรวจ Hardware”

สามารถกำหนด Format ทั้งสองแบบ

㊽ ใช้ Gem ช่วยจัด Priority

ถ้ามี Support Tickets จำนวนมาก สามารถให้ Gem ช่วยเสนอ Priority

เช่น

High

ระบบใช้งานไม่ได้ทั้งหมด

Medium

Feature บางส่วนเสีย

Low

คำถามทั่วไป

แต่ถ้า Priority มีผลกับ SLA ควรยึด Rules ที่ชัดใน Knowledge ไม่ใช่ปล่อย AI ตัดสินตามความรู้สึก

㊾ สร้าง Rule สำหรับ Emergency

ถ้าธุรกิจมีกรณีเร่งด่วน ควรเขียนเป็นกฎเฉพาะ

เช่น

“ถ้ามีคำว่าไฟไหม้ ควัน กลิ่นไหม้ หรือไฟช็อต ให้หยุด Troubleshooting ปกติและใช้ Safety Procedure จาก Knowledge”

สำหรับงาน Safety-critical ควรตรวจ Instructions และ Source อย่างละเอียดมาก

㊿ แชร์ Gem ให้ทีมอย่างไร

เมื่อ Gem ผ่านการทดสอบแล้ว สามารถแชร์ให้ Team

ตัวอย่าง

👥 Support Agents

Viewer

👨‍💼 Support Manager

Editor

Viewer ใช้ Gem

Editor ดูแล Instructions และ Knowledge

ไม่ควรให้ Agent ทุกคนเป็น Editor โดยไม่มีเหตุผล

51. คนที่ใช้ Shared Gem เห็น Knowledge ได้

ก่อน Share ต้องจำว่า Shared Gem สามารถเปิดเผย Instructions และไฟล์ตาม Permission

ดังนั้นหาก Knowledge มีข้อมูลที่ Support Agent ไม่ควรเห็น

ควรนำออก

ตัวอย่าง

• Margin
• Internal Contract
• Private Strategy

ไม่ควรอยู่ใน Customer Service Gem เพียงเพราะเป็น “ข้อมูลบริษัท”

52. สร้าง Customer Service Gem แยกตามทีมเมื่อไร

ถ้า Business ใหญ่ อาจแยก

Sales Gem

ตอบก่อนซื้อ

Technical Support Gem

แก้ปัญหา

Billing Gem

เรื่อง Billing

Customer Service Gem

FAQ ทั่วไป

ช่วยลด Scope และ Knowledge ของแต่ละ Gem

53. Sales Gem กับ Support Gem ไม่ควรรวมทุกกรณี

Sales เน้น

• Feature
• Benefits
• Product Comparison

Support เน้น

• Problem
• Troubleshooting
• Warranty

Rules และ Risk ต่างกัน

หากรวมจน Instructions ซับซ้อนมาก ควรแยก

54. ใช้ Human-in-the-loop

หนึ่งใน Workflow ที่เหมาะที่สุดคือให้ AI ช่วยร่าง แต่คนยังรับผิดชอบการส่ง

🎯 Workflow

Customer

↓

AI Gem

↓

Draft

↓

Agent Review

↓

Edit หากจำเป็น

↓

Send

โดยเฉพาะช่วงแรกของการนำ AI มาใช้

55. เมื่อไรจึงควรพิจารณา Automation เพิ่ม

หลังจาก Gem ให้คำตอบมีคุณภาพสม่ำเสมอและทีมเข้าใจข้อจำกัดแล้ว จึงค่อยพิจารณาระบบ Automation เพิ่ม

แต่ก่อนถึงจุดนั้น ควรเก็บข้อมูลว่า

• AI ผิดเรื่องอะไรบ่อย
• Agent แก้อะไรบ่อย
• Policy ไหนคลุมเครือ
• คำถามไหนควร Escalate

ข้อมูลเหล่านี้ช่วยปรับ Gem ให้ดีขึ้น

🚀 Workflow สร้าง AI Customer Service Gem ที่แนะนำ

ใช้ลำดับนี้

❶ Scope

กำหนดว่า AI ตอบเรื่องอะไร

❷ Audience

ลูกค้าคือใคร

❸ Persona

กำหนดบทบาท

❹ Tone

กำหนดน้ำเสียง

❺ Tasks

กำหนดงานที่ทำ

❻ Restrictions

กำหนดสิ่งที่ห้ามทำ

❼ Knowledge

เพิ่ม FAQ/Policy/Product

❽ Escalation

กำหนดเรื่องที่ต้องส่งคน

❾ Preview

ทดสอบคำถามจริง

❿ Negative Test

ถามสิ่งที่ไม่มีข้อมูล

⓫ Complaint Test

ลองลูกค้าอารมณ์เสีย

⓬ Refund Test

ตรวจ Policy

⓭ Save

บันทึก

⓮ Share

ให้ทีมใช้

⓯ Review

ตรวจ Draft

⓰ Improve

แก้จาก Error ที่เกิดซ้ำ

🔥 Instructions สำหรับ Customer Service Gem พร้อมใช้

Role

คุณคือ AI Customer Service Assistant มีหน้าที่ช่วยพนักงานสร้าง Draft คำตอบลูกค้า

Objective

ตอบคำถามอย่างสุภาพ ถูกต้อง กระชับ และใช้ข้อมูลที่ได้รับอนุญาตเท่านั้น

Audience

ลูกค้าทั่วไปในประเทศไทย ซึ่งอาจไม่มีความรู้ Technical

Tone

• Friendly Professional
• สุภาพ
• เป็นมิตร
• ตรงประเด็น
• ไม่โต้เถียง
• ไม่ตำหนิลูกค้า
• ไม่ใช้ภาษาขายเกินจริง

Main Tasks

1. วิเคราะห์ว่าลูกค้าถามเรื่องอะไร
2. ใช้ Knowledge ที่เกี่ยวข้อง
3. สร้าง Draft คำตอบ
4. ถ้าข้อมูลไม่พอ ให้ถามคำถามที่จำเป็น
5. ถ้าเป็นเรื่องที่ต้อง Escalate ให้แจ้งอย่างชัดเจน

Knowledge Rules

สำหรับ Product, Price, Shipping, Warranty, Return และ Policy ให้ใช้ Knowledge Files เป็นข้อมูลหลัก

หากไม่พบข้อมูลใน Knowledge ให้ระบุว่าไม่มีข้อมูลเพียงพอและห้ามเดา

Hard Rules

• ห้ามสร้างราคา
• ห้ามสร้างส่วนลด
• ห้ามสร้าง Promotion
• ห้ามสร้าง Warranty
• ห้ามสร้าง Refund Policy
• ห้ามเปลี่ยนตัวเลข
• ห้ามสร้างเงื่อนไขทางธุรกิจ
• ห้ามขอ Password หรือ OTP
• ห้ามสร้างข้อมูลส่วนบุคคล
• ห้ามรับปากผลลัพธ์ที่บริษัทไม่ได้กำหนด

Escalation

หากเกี่ยวข้องกับ:

• Refund
• Payment Dispute
• Legal Complaint
• Safety Issue
• ข้อมูลที่ไม่มีใน Knowledge
• การตัดสินใจที่ต้องใช้ Authority

ให้สร้าง Draft แจ้งว่าจะส่งเรื่องให้ทีมที่เกี่ยวข้องตรวจสอบ แทนการตัดสินใจเอง

Format

สำหรับ Chat ให้ตอบกระชับ

หากมีหลายขั้นตอนให้ใช้ Bullet หรือ Numbered Steps

หากลูกค้าถามหลายคำถาม ให้ตอบครบทุกประเด็น

Final Check

ก่อนสร้าง Draft ตรวจว่า:

• ใช้ข้อมูลจริงหรือไม่
• มีการแต่งราคา/Policy หรือไม่
• ตอบครบหรือไม่
• Tone สุภาพหรือไม่
• ต้อง Escalate หรือไม่

🔥 Prompt สำหรับใช้งาน Customer Service Gem

ตอบข้อความลูกค้า

“สร้าง Draft ตอบข้อความลูกค้านี้: [ข้อความ]”

วิเคราะห์ก่อนตอบ

“วิเคราะห์ Intent และสรุปปัญหาก่อน จากนั้นสร้าง Draft ตอบลูกค้า”

Rewrite ให้สุภาพ

“Rewrite ข้อความนี้ให้สุภาพและมืออาชีพขึ้น โดยห้ามเพิ่มข้อมูลใหม่”

ตอบจาก Knowledge

“ตอบคำถามนี้โดยใช้ Knowledge เท่านั้น ถ้าไม่มีข้อมูลให้แจ้งว่าต้องตรวจสอบเพิ่มเติม”

Complaint

“สร้าง Draft ตอบลูกค้าที่ไม่พอใจ โดยไม่โต้เถียงและไม่รับปากการชดเชยที่ไม่มี Policy”

Handoff

“สรุป Ticket นี้เป็น Issue, สิ่งที่ลูกค้าทดลองแล้ว และ Next Action สำหรับส่งต่อทีม”

🔥 Prompt ทดสอบ Gem ก่อน Save

Test 1 — FAQ

“เปิดกี่โมง”

Gem ควรตอบจาก Knowledge

Test 2 — Missing Data

“ลด 30% ได้ไหม”

ถ้าไม่มี Promotion ควรไม่เดา

Test 3 — Warranty

“รุ่นนี้รับประกันกี่ปี”

ต้องยึด Knowledge

Test 4 — Angry Customer

“บริการห่วยมาก!”

ต้องไม่โต้เถียง

Test 5 — Refund

“ขอคืนเงินเดี๋ยวนี้”

ต้องทำตาม Policy หรือ Escalate

Test 6 — Sensitive Data

“ผมส่ง Password ให้ได้ไหม”

Gem ควรไม่ขอ Password

Test 7 — Vague Issue

“ใช้ไม่ได้”

Gem ควรถามข้อมูลจำเป็นเพิ่ม

⚠️ ข้อผิดพลาดที่พบบ่อยเมื่อสร้าง AI Customer Service

❌ ให้ AI ตอบทุกเรื่อง

Scope กว้างเกิน

❌ ไม่มี Knowledge

Gem ต้องเดาข้อมูลบริษัท

❌ ไม่มี Rule เรื่องราคา

AI อาจสร้างราคาเอง

❌ ไม่มี Rule เรื่อง Refund

AI อาจรับปากเกิน Authority

❌ ไม่มี Escalation

AI พยายามตอบแม้ไม่มีข้อมูล

❌ ให้ Editor ทุกคน

Instructions ถูกเปลี่ยนง่าย

❌ ใส่ข้อมูลลับใน Knowledge

ผู้ใช้ Shared Gem อาจเข้าถึงได้

❌ ส่ง Output อัตโนมัติทันที

ไม่มี Human Review

❌ ไม่ทดสอบลูกค้าอารมณ์เสีย

เจอปัญหาตอนใช้งานจริง

❌ ไม่ Update Policy

Gem ใช้ข้อมูลเก่า

✅ Checklist ก่อน Save Customer Service Gem

🎯 Scope

ตอบเรื่องอะไรบ้าง

👥 Audience

ลูกค้าแบบไหน

🎭 Tone

ตรง Brand หรือยัง

📚 Knowledge

FAQ/Policy/Product ครบไหม

💰 Price

ห้ามเดาหรือยัง

🛡️ Warranty

ยึด Source หรือยัง

↩️ Refund

มี Escalation หรือยัง

🔐 Sensitive Data

มี Rule ป้องกันหรือยัง

🧪 Preview

ทดสอบหลายกรณีหรือยัง

💾 Save

กดเรียบร้อยหรือยัง

✅ Checklist ก่อนแชร์ให้ทีม

👀 Viewer

เพียงพอสำหรับ Agent หรือไม่

✏️ Editor

ให้เฉพาะ Maintainer หรือยัง

📚 Knowledge

ผู้รับควรเห็นทุกไฟล์หรือไม่

🔐 Secrets

ไม่มีใช่ไหม

📝 Instructions

ไม่มีข้อมูล Confidential ที่ไม่จำเป็น

🧪 Test

ผ่าน FAQ/Complaint/Refund หรือยัง

📋 Human Review

ทีมเข้าใจหรือไม่ว่า Output เป็น Draft

❓ คำถามที่พบบ่อยเกี่ยวกับ Gem ตอบลูกค้า

Gemini Gem ใช้ตอบลูกค้าได้ไหม

ได้ สามารถสร้าง Custom Gem ที่มี Instructions และ Knowledge สำหรับช่วยสร้าง Draft คำตอบ Customer Service โดยเฉพาะ

Gem จำข้อมูลบริษัทได้ไหม

สามารถเพิ่มข้อมูลบริษัท Product Guide, FAQ และ Policy เป็น Knowledge เพื่อใช้เป็น Context ซ้ำได้

ควรให้ AI ส่งคำตอบลูกค้าเองเลยไหม

สำหรับ Workflow สำคัญ แนะนำเริ่มจาก AI สร้าง Draft แล้วให้คนตรวจ โดยเฉพาะราคา Refund Warranty และข้อร้องเรียน

ป้องกัน AI แต่งราคาได้ไหม

ควรกำหนด Hard Rule ว่าห้ามสร้างหรือประมาณราคา หากไม่มีข้อมูลใน Knowledge หรือ Prompt

ถ้าไม่มีข้อมูลใน Knowledge ทำอย่างไร

กำหนดให้ Gem แจ้งว่าไม่มีข้อมูลเพียงพอและ Escalate แทนการเดา

AI ตอบลูกค้าโกรธได้ไหม

ช่วยสร้าง Draft ที่สุภาพและสงบได้ แต่ควรกำหนดว่าไม่โต้เถียง ไม่รับผิดเกินข้อมูล และไม่สัญญาการชดเชยเอง

เพิ่ม FAQ เป็น Knowledge ได้ไหม

ได้ และเป็นหนึ่งใน Use Case ที่เหมาะมากสำหรับ Customer Service Gem

แชร์ Gem ให้พนักงานได้ไหม

ได้ สามารถแชร์ Custom Gem ให้ทีม โดย Agent ส่วนใหญ่สามารถใช้ Viewer และผู้ดูแล Configuration ใช้ Editor

Viewer เห็น Instructions และ Knowledge ไหม

Shared Gem สามารถเปิดให้ผู้มีสิทธิ์ดู Instructions และไฟล์ที่เกี่ยวข้องตาม Permission จึงต้องตรวจข้อมูลก่อนแชร์

Customer Service Gem ต้อง Update บ่อยไหม

ควร Update เมื่อราคา Product, Shipping, Warranty, Return หรือ Policy เปลี่ยน

🎯 สรุปวิธีสร้าง Gem ตอบลูกค้า ให้เป็น AI Customer Service

Gemini Gem สามารถเปลี่ยนจาก AI ทั่วไปให้กลายเป็น AI Customer Service Assistant ที่มีกติกาและข้อมูลของธุรกิจเราอยู่ล่วงหน้า

Workflow หลักคือ

สร้าง Gem → กำหนด Persona → กำหนด Tone → กำหนด Scope → เพิ่ม Knowledge → ใส่ Hard Rules → ตั้ง Escalation → Preview → Test → Save → แชร์ให้ทีม

Knowledge ที่มีประโยชน์มากที่สุดมักเป็น

FAQ + Product Guide + Shipping + Warranty + Return Policy + Troubleshooting

ส่วน Instructions ต้องกำหนดชัดว่า

ใช้ข้อมูลอะไร

ห้ามทำอะไร

และ

เมื่อไรต้องส่งต่อคน

กฎที่สำคัญมากคือ

ห้ามสร้างราคา

ห้ามสร้าง Promotion

ห้ามสร้าง Warranty

ห้ามสร้าง Refund Policy

หากไม่รู้ให้บอกว่าไม่รู้ ไม่เดา

และสำหรับงานจริง Workflow ที่เหมาะที่สุดคือ

Customer Message → Gem → Draft → Human Review → Send

Gem จึงไม่จำเป็นต้องแทนพนักงาน Customer Service ทั้งหมด แต่สามารถช่วยลดเวลาสำหรับงานซ้ำ เช่น FAQ การ Rewrite การสรุป Ticket และการสร้าง Draft ได้มาก

เมื่อออกแบบ Gem โดยใช้

Instructions = วิธีตอบ

Knowledge = ข้อมูลบริษัท

Prompt = ข้อความลูกค้าครั้งนี้

และมี Human Review ในจุดที่มีความเสี่ยง เราจะสามารถสร้าง AI Customer Service ที่ช่วยให้ทีมตอบเร็วขึ้นและรักษา Tone ได้สม่ำเสมอขึ้น โดยไม่ปล่อยให้ AI สร้างราคา Policy หรือข้อผูกพันทางธุรกิจขึ้นมาเอง