Manajemen Pelanggan (CRM) & Strategi Harga
1. Filosofi Strategi Harga
Zhuzhe POS menyadari bahwa di dunia enterprise, harga tidak bersifat statis. Harga dapat berbeda berdasarkan lokasi geografis toko dan loyalitas pelanggan. Oleh karena itu, sistem ini menggabungkan data Pelanggan (CRM) dengan data Grup Harga (Pricing) untuk menciptakan ekosistem penjualan yang personal dan fleksibel.
2. Fitur Utama CRM & Pricing
2.1 Price Groups (Grup Harga)
Grup Harga adalah kategori kebijakan harga yang dapat dibuat secara mandiri oleh setiap toko.
Penggunaan Cabang: Toko Jakarta Selatan dapat memiliki grup harga "Retail Jakarta" yang berbeda nilainya dengan grup harga "Retail Bandung" di cabang lain.
Fleksibilitas: Satu produk dapat memiliki banyak harga sekaligus tergantung pada grup harga yang aktif.
2.2 Customer Levels (Tingkatan Pelanggan)
Fitur ini berfungsi untuk mengelompokkan pelanggan ke dalam kategori loyalitas.
Relasi Kunci: Setiap Customer Level (seperti Silver, Gold, Platinum) wajib dihubungkan ke satu Price Group.
Otomatisasi POS: Saat kasir memilih pelanggan "Andi" yang berlevel "Gold", sistem akan secara otomatis menarik harga dari grup harga "Gold" untuk semua produk di keranjang belanja.
2.3 Database Pelanggan Terisolasi (Privacy Ready)
Sesuai dengan arsitektur Multi-Tenant, data pelanggan bersifat privat per toko.
Privasi Data: Pelanggan yang didaftarkan di Toko A tidak akan muncul di database Toko B (kecuali jika diatur global oleh Super Admin). Ini memberikan perlindungan privasi data pelanggan antar cabang.
Identitas: Menyimpan data esensial seperti Nama Lengkap dan Nomor WhatsApp untuk keperluan pemasaran (marketing) di masa depan.
3. Penjelasan Teknis (Technical Deep Dive)
3.1 Hierarki Relasi Data
Untuk menjalankan logika harga dinamis, sistem mengikuti alur relasi berikut:
stores memiliki banyak price_groups.
price_groups dihubungkan ke customer_levels.
customer_levels dihubungkan ke customers.
Saat checkout, sistem melakukan query: Customer -> Level -> PriceGroup -> ItemUnitPrice.
3.2 Implementasi Unique Scoping
Setiap data master di bagian ini menggunakan Composite Unique Key.
Logika: unique(['store_id', 'name']).
Dampak: Memungkinkan dua toko yang berbeda memiliki nama level yang sama (misal: keduanya punya level "Member") tanpa menyebabkan konflik data di database pusat.
3.3 Penanganan ID (Type Casting)
Di sisi frontend (React), semua ID pelanggan dan level dikonversi menjadi tipe data String sebelum dikirim ke API.
Alasan: Menjamin sinkronisasi yang stabil dengan elemen HTML <select> dan menghindari kegagalan pencocokan data (Type Mismatch) antara Integer dari MySQL dan String dari input browser.
4. Penjelasan Non-Teknis (User Experience)
4.1 Registrasi Pelanggan yang Cepat
Di menu Terminal POS, sistem menyediakan akses cepat ke data pelanggan. Kasir dapat dengan mudah mencari pelanggan berdasarkan nama atau nomor telepon hanya dalam hitungan detik (Server-side search).
4.2 Feedback Visual pada Tabel
Pada menu "Referensi", Admin dapat melihat ringkasan setiap level pelanggan. Jika sebuah level belum terhubung ke grup harga, sistem akan memberikan label "TIDAK TERSET" berwarna abu-abu untuk memperingatkan Admin agar segera mengatur harganya.
5. Ringkasan Objek Data (Data Dictionary)
5.1 Tabel price_groups
Field
Tipe Data
Fungsi
name
String
Label grup harga (e.g., "Grosir", "Retail").
store_id
Foreign Key
Pemilik kebijakan harga.
5.2 Tabel customer_levels
Field
Tipe Data
Fungsi
name
String
Nama tingkatan (e.g., "VIP").
price_group_id
Foreign Key
Referensi harga yang didapatkan level ini.
5.3 Tabel customers
Field
Tipe Data
Fungsi
name
String
Nama lengkap pelanggan.
phone
String
Nomor kontak untuk identifikasi unik.
customer_level_id
Foreign Key
Penentu harga pelanggan tersebut saat belanja.
Volume 5 akan membahas Detail Fitur Operasional POS (Terminal Kasir, Multi-Payment, dan Cetak Struk).
Last updated