Kategori: Inbox
Tahap: 🟢 Beginner
Sasaran: 👤 Client, 👥 Team Member & 🛠 Agency Administrator
Masa Membaca: ±12 minit

---

Pengenalan

Apabila pelanggan menghantar mesej, perkara pertama yang kita nampak biasanya ialah apa yang pelanggan tulis.

Namun untuk memberikan bantuan yang baik, kadangkala mesej sahaja tidak mencukupi.

Ejen juga perlu memahami:

Siapa pelanggan ini?
Dari channel mana mereka datang?
Adakah mereka pernah menghubungi kita sebelum ini?
Apakah konteks conversation sebelumnya?

Di sinilah Contact Details dan Customer Context menjadi penting.

Maklumat pelanggan membantu ejen melihat conversation bukan sekadar sebagai satu mesej, tetapi sebagai sebahagian daripada hubungan pelanggan dengan perniagaan.

---

🎯 Objektif

Selepas membaca panduan ini, anda akan memahami:

• Apa yang dimaksudkan dengan Contact Details.
• Perbezaan antara Contact dan Conversation.
• Kenapa Customer Context penting.
• Bagaimana maklumat pelanggan membantu ejen memberikan bantuan.
• Kenapa maklumat contact mungkin berbeza mengikut channel.
• Cara menggunakan sejarah conversation dengan lebih baik.
• Kepentingan menjaga privasi data pelanggan.
• Hubungan antara Inbox dan CRM.

Nota: Maklumat contact yang tersedia bergantung kepada channel, integrasi, permission dan konfigurasi AnyChat. Tidak semua conversation akan mempunyai maklumat pelanggan yang sama lengkap.

---

👤 Apa Itu Contact?

Secara mudah:

Contact ialah rekod individu yang berkomunikasi dengan perniagaan anda.

Contohnya:

Contact
──────────────
Nama: Ahmad
Telefon: ...
Email: ...
Channel: ...

Maklumat sebenar yang tersedia bergantung kepada bagaimana pelanggan berinteraksi dengan perniagaan dan data yang diterima melalui channel tersebut.

---

💬 Apa Itu Conversation?

Conversation pula ialah rekod komunikasi yang berlaku dengan pelanggan.

Contohnya:

Ahmad

Pelanggan:
Domain saya belum aktif.

Agent:
Baik, kami bantu semak.

Pelanggan:
Saya dah tukar DNS semalam.

Jadi:

👤 Contact = Siapa pelanggan?

💬 Conversation = Apa yang dibincangkan?

Dua perkara ini berkait rapat tetapi bukan perkara yang sama.

---

🧠 Cara Mudah Memahaminya

Bayangkan sebuah fail pelanggan.

             CONTACT
             Ahmad
                │
       ┌────────┼────────┐
       ↓        ↓        ↓
   Maklumat   Channel   Conversation
   Contact              History

Contact memberikan identiti.

Conversation memberikan konteks komunikasi.

Apabila kedua-duanya digunakan bersama, ejen boleh memberikan bantuan yang lebih tepat.

---

📇 Apakah Maklumat Yang Mungkin Tersedia?

Bergantung kepada channel dan konfigurasi, maklumat pelanggan boleh merangkumi perkara seperti:

• Nama.
• Nombor telefon.
• Alamat email.
• Channel.
• Identiti atau maklumat berkaitan channel.
• Sejarah conversation.
• Maklumat tambahan yang disimpan oleh sistem.

Jangan anggap semua maklumat ini akan sentiasa tersedia.

---

🌐 Kenapa Maklumat Berbeza Mengikut Channel?

Setiap channel mempunyai cara tersendiri untuk mengenal pasti pengguna.

Contohnya secara konsep:

WhatsApp
   ↓
Nombor telefon / identiti channel

Live Chat
   ↓
Maklumat yang diberikan atau tersedia

Messenger
   ↓
Identiti berkaitan platform

Instagram
   ↓
Identiti berkaitan platform

Oleh sebab itu, satu conversation mungkin mempunyai maklumat pelanggan yang lengkap, manakala conversation lain mungkin mempunyai maklumat yang sangat sedikit.

---

❓ Bagaimana Jika Nama Pelanggan Tidak Diketahui?

Ini perkara biasa, terutama pada permulaan conversation tertentu.

Contohnya pelanggan berkata:

“Hai, saya nak tanya pasal Landing Page.”

Jika nama diperlukan untuk proses seterusnya, ejen boleh bertanya secara natural:

Boleh saya tahu nama anda untuk rujukan kami?

Tetapi jangan meminta maklumat hanya kerana mahu memenuhi semua ruangan contact.

Minta maklumat yang benar-benar diperlukan.

---

🎯 Apa Itu Customer Context?

Customer Context ialah maklumat yang membantu ejen memahami keadaan pelanggan sebelum memberikan balasan.

Ia bukan hanya nama dan nombor telefon.

Context boleh datang daripada:

mesej sebelumnya,

masalah yang pernah dilaporkan,

channel yang digunakan,

maklumat yang sudah diberikan,

tindakan yang sudah dilakukan,

atau sejarah bantuan sebelumnya.

---

📖 Kenapa Context Sangat Penting?

Bayangkan conversation seperti ini:

Pelanggan:

Masih sama.

Tanpa context:

“Apa yang masih sama?”

Tetapi selepas membaca sejarah:

Pelanggan:

SSL saya tak aktif.

Agent:

Kami sudah kemas kini konfigurasi. Cuba semula selepas beberapa ketika.

Pelanggan:

Masih sama.

Sekarang ejen memahami bahawa:

“Masih sama” = SSL masih belum aktif.

Inilah nilai context.

---

🔁 Jangan Paksa Pelanggan Mengulangi Semuanya

Salah satu pengalaman customer support yang paling menjengkelkan ialah:

Pelanggan menerangkan masalah kepada Agent A.

Kemudian conversation bertukar kepada Agent B.

Agent B bertanya:

“Boleh terangkan masalah dari mula?”

😑

Jika sejarah conversation tersedia, Agent B sepatutnya membacanya terlebih dahulu.

Lebih baik:

Hai Ahmad. Saya sudah baca conversation sebelumnya mengenai SSL domain anda. Saya akan teruskan semakan dari bahagian tersebut.

Pelanggan merasakan bahawa pasukan bekerja sebagai satu organisasi, bukan beberapa individu yang terpisah.

---

👥 Customer Context Sangat Penting Ketika Assignment

Sekarang kita boleh hubungkan kembali dengan 4.5 – Assign Conversation.

Apabila conversation dipindahkan:

Agent A
   ↓
Conversation History
   ↓
Agent B

Sejarah tersebut membantu Agent B memahami:

Apa masalah pelanggan?

Apa yang sudah ditanya?

Apa yang pelanggan sudah berikan?

Apa tindakan yang telah dibuat?

Apa yang masih belum selesai?

Sebab itu kita menggunakan prinsip:

Transfer conversation, bukan transfer masalah kepada pelanggan.

---

🤖 Context Selepas AI

Perkara sama berlaku apabila AI digunakan.

Bayangkan:

Customer
    ↓
AI
    ↓
AI bertanya nama
    ↓
AI mendapatkan domain
    ↓
AI cuba troubleshooting
    ↓
Human Agent

Apabila human agent mengambil alih, jangan bertanya:

“Nama apa?”

“Domain apa?”

jika pelanggan sudah memberikan semua maklumat tersebut.

Baca conversation dahulu.

Kemudian:

Hai Ahmad. Saya sudah lihat maklumat mengenai contohdomain.com yang diberikan tadi. Saya akan teruskan semakan dari sini.

Inilah pengalaman AI → Human Handoff yang lebih baik.

---

🔀 Pelanggan Sama, Channel Berbeza

Dalam 4.7 kita sudah melihat situasi ini.

Contohnya:

Ahmad
├── WhatsApp
├── Live Chat
└── Instagram

Pelanggan mungkin menganggap:

“Semua ni ResellerMY.”

Tetapi sistem mungkin menerima identiti yang berbeza daripada setiap channel.

Jangan terus menganggap semua rekod bernama Ahmad ialah orang yang sama.

---

⚠️ Elakkan Duplicate Contact Secara Melulu

Dalam sistem customer communication, kemungkinan wujud rekod yang kelihatan seperti pelanggan sama.

Tetapi sebelum melakukan apa-apa penggabungan atau perubahan rekod — jika fungsi tersebut tersedia — pastikan identiti benar-benar sepadan.

Contohnya:

Nama sama sahaja

tidak mencukupi untuk membuktikan dua contact ialah individu yang sama.

Gunakan maklumat yang lebih kukuh jika tersedia.

---

🏷️ Maklumat Pelanggan Bukan Untuk Dikumpul Sebanyak Mungkin

Ada kecenderungan apabila mempunyai CRM:

“Kita isi semua.”

Nama.

Telefon.

Email.

Alamat.

Tarikh lahir.

Syarikat.

Jawatan.

Dan macam-macam lagi.

Tetapi prinsip yang lebih baik ialah:

Kumpulkan maklumat yang mempunyai tujuan.

Contohnya untuk Landing Page:

Nama
Contact
Nama perniagaan
Domain
Produk/perkhidmatan berkaitan

mungkin sudah mencukupi untuk banyak workflow.

---

🧩 Contact Details Membantu Personalisation

Maklumat pelanggan boleh membantu ejen memberikan pengalaman yang lebih personal.

Daripada:

“Hello customer.”

lebih natural:

Hai Ahmad.

Tetapi personalisation bukan sekadar menggunakan nama.

Ia juga bermaksud memahami konteks.

Contohnya:

Hai Ahmad. Saya nampak sebelum ini anda menghubungi kami mengenai konfigurasi domain. Adakah pertanyaan kali ini masih berkaitan domain yang sama?

Itu jauh lebih berguna.

---

💼 Customer Context Untuk Sales

Context bukan hanya berguna untuk support.

Ia juga sangat berguna untuk sales.

Contohnya pelanggan sebelum ini bertanya:

Landing Page untuk restoran.

Beberapa hari kemudian pelanggan kembali:

“Saya nak teruskan.”

Jika sejarah tersedia, sales tidak perlu bertanya semula:

“Nak website apa?”

Sebaliknya:

Baik. Sebelum ini kita berbincang mengenai Landing Page untuk restoran. Kita boleh teruskan daripada keperluan tersebut.

Conversation terasa lebih profesional.

---

🛠️ Customer Context Untuk Technical Support

Untuk technical support, context lebih penting lagi.

Contohnya:

Customer: Ahmad

Product:
Landing Page

Domain:
contohdomain.com

Previous Issue:
DNS

Current Issue:
SSL

Ejen boleh melihat bahawa masalah sekarang mungkin berkait dengan konfigurasi sebelumnya.

Tanpa context, troubleshooting mungkin bermula dari kosong setiap kali.

---

📚 Customer Context + Knowledge Base

Context juga membantu menentukan artikel Knowledge Base yang patut diberikan.

Contohnya pelanggan:

“Domain tak aktif.”

Daripada memberikan semua artikel domain:

Cara Beli Domain
Cara Tukar Nameserver
DNS
SSL
Custom Domain
Troubleshooting

ejen membaca context dan mendapati:

DNS sudah dikonfigurasikan tetapi baru sahaja berubah.

Maka artikel paling relevan ialah:

DNS Belum Dikemas Kini

Context membantu memberikan jawapan yang tepat, bukan sekadar banyak jawapan.

---

🔎 Customer Context + Search

Search yang kita pelajari dalam 4.6 juga menjadi semakin berguna.

Pelanggan berkata:

“Saya pernah contact bulan lepas.”

Ejen boleh mencari maklumat yang tersedia.

Kemudian:

Search
   ↓
Contact
   ↓
Conversation History
   ↓
Context
   ↓
Continue Support

Daripada:

Pelanggan datang
   ↓
Terangkan semuanya semula

---

👥 Maklumat Contact dan Permission

Tidak semua team member semestinya perlu melihat semua maklumat pelanggan.

Contohnya:

Support Agent

mungkin memerlukan:

nama,
channel,
conversation history.

Tetapi tidak semestinya memerlukan akses kepada:

konfigurasi administrator,

billing organisasi,

API,

atau bahagian sistem lain yang tidak berkaitan.

Gunakan permission berdasarkan tugas.

---

🔐 Privasi Data Pelanggan

Ini bahagian yang sangat penting.

Maklumat seperti:

nama,
telefon,
email,
conversation history

ialah data pelanggan yang perlu dikendalikan dengan bertanggungjawab.

Jangan:

• salin data tanpa keperluan,
• berkongsi kepada pihak tidak berkaitan,
• menggunakan data pelanggan untuk tujuan lain tanpa asas yang sesuai,
• atau meninggalkan dashboard terbuka pada komputer awam.

---

🚫 Jangan Simpan Password Dalam Contact

Ini perlu disebut secara khusus.

Jangan gunakan:

Contact Notes,

Custom Field,

Conversation,

atau mana-mana bahagian CRM untuk menyimpan password pelanggan secara sembarangan.

Begitu juga:

OTP,
recovery code,
private API key,
token akses.

Maklumat seperti ini memerlukan kaedah pengurusan credential yang sesuai, bukan CRM biasa.

---

🌍 Contoh Workflow ResellerMY

Bayangkan pelanggan menghantar:

“Landing Page saya tak boleh buka.”

Ejen membuka conversation.

Daripada terus bertanya banyak soalan, ejen memeriksa context yang tersedia.

Didapati:

Nama: Ahmad

Produk:
Landing Page

Domain:
contohdomain.com

Conversation sebelumnya:
DNS baru dikonfigurasikan

Sekarang ejen boleh menjawab:

Hai Ahmad. Saya nampak domain contohdomain.com baru dikonfigurasikan sebelum ini. Saya akan bantu semak sama ada isu sekarang masih berkaitan DNS atau terdapat masalah lain.

Bandingkan dengan:

“Domain apa?”

Context menjimatkan masa pelanggan dan ejen.

---

💡 Tip ResellerMY

Sebelum bertanya pelanggan sesuatu, biasakan satu perkara:

Semak dahulu sama ada pelanggan sudah memberikan maklumat tersebut.

Ini sangat mudah tetapi mempunyai impak besar.

Pelanggan tidak mahu ditanya:

nama,

domain,

masalah,

nombor tempahan,

berulang kali jika semuanya sudah berada dalam conversation.

---

🚀 Pro Tip: Bina “Customer 360° View”

Dalam sistem yang lebih matang, matlamatnya ialah membina gambaran pelanggan yang lebih menyeluruh.

Secara konsep:

             CUSTOMER
                │
     ┌──────────┼──────────┐
     ↓          ↓          ↓
 Contact    Conversations  Channel
 Details       History
     │          │          │
     └──────────┼──────────┘
                ↓
          Customer Context

Kemudian apabila pelanggan menghubungi:

ejen tidak bermula daripada kosong.

Inilah asas kepada apa yang sering disebut sebagai Customer 360° View.

Kita belum masuk CRM sepenuhnya lagi, tetapi konsepnya bermula di sini.

---

🧠 Inbox vs CRM

Sekarang sempadannya semakin jelas.

💬 Inbox

Fokus kepada:

Apa yang sedang pelanggan bincangkan?

👤 CRM / Contacts

Fokus kepada:

Siapa pelanggan tersebut dan apakah maklumat hubungan mereka?

Apabila digabungkan:

Contact + Conversation = Customer Context

Dan itulah sebabnya Inbox dan CRM saling berkait rapat.

---

❌ Kesilapan Lazim

Elakkan:

• Bertanya maklumat yang pelanggan sudah berikan.
• Menganggap dua contact bernama sama ialah orang yang sama.
• Mengumpulkan data yang tidak diperlukan.
• Tidak membaca conversation history.
• Mengabaikan context selepas AI handoff.
• Agent baharu meminta pelanggan menerangkan semuanya semula.
• Memberikan semua pengguna akses kepada semua data pelanggan.
• Menyimpan password atau OTP dalam contact.
• Menggunakan data pelanggan di luar tujuan yang sepatutnya.
• Menganggap Contact dan Conversation perkara yang sama.

---

❓ Soalan Lazim

Apa beza Contact dengan Conversation?

Contact ialah rekod pelanggan. Conversation ialah rekod komunikasi dengan pelanggan tersebut.

Kenapa sesetengah contact tidak mempunyai email atau telefon?

Maklumat yang tersedia bergantung kepada channel, data yang diberikan pelanggan dan konfigurasi sistem.

Perlukah saya meminta semua maklumat pelanggan?

Tidak. Minta hanya maklumat yang mempunyai tujuan dan diperlukan untuk proses berkaitan.

Bagaimana jika pelanggan menggunakan beberapa channel?

Jangan terus menganggap semua rekod tersebut ialah individu yang sama. Gunakan data yang tersedia untuk mengenal pasti pelanggan dengan betul.

Bolehkah ejen membaca conversation lama?

Ia bergantung kepada permission, konfigurasi dan fungsi yang tersedia dalam workspace AnyChat.

Bolehkah password pelanggan disimpan dalam Contact?

Elakkan menyimpan password, OTP, recovery code atau credential sensitif dalam rekod contact atau conversation biasa.

---

📑 Ringkasan

Maklumat pelanggan memberikan identiti, manakala conversation memberikan konteks.

Ingat formula ini:

👤 Contact → Siapa pelanggan?

💬 Conversation → Apa yang dibincangkan?

🌐 Channel → Dari mana pelanggan datang?

📖 History → Apa yang pernah berlaku?

🧠 Context → Apa yang perlu ejen fahami sekarang?

Apabila semua maklumat ini digunakan dengan baik, pelanggan tidak perlu bermula daripada kosong setiap kali mereka menghubungi support.

---

📖 Learning Path

✅ 4.7 – Mengurus Perbualan Daripada Pelbagai Communication Channels
✅ 4.8 – Quick Replies: Membalas Pertanyaan Pelanggan Dengan Lebih Pantas

📍 Anda sedang membaca:
4.9 – Maklumat Pelanggan Dalam Conversation: Memahami Contact Details & Customer Context

➡️ Seterusnya: 4.10 – Internal Notes: Berkomunikasi Dengan Team Tanpa Dilihat Pelanggan