Di halaman ini
Tiket dukungan bisa berstatus “selesai” padahal pelanggan belum dapat memakai fiturnya. Dalam contoh permintaan ekspor CSV yang hipotetis, kode untuk tiket T-104 sudah digabung, tetapi peluncuran fitur masih nonaktif. Mengatakan “fitur Anda sudah tersedia” berarti mengingkari janji.
Hubungkan satu permintaan dengan satu rilis yang terkonfirmasi dan satu orang yang dapat dihubungi. Contoh GTM Loop Closer dari xAI membahas pencarian komitmen, penampilan bukti, dan persiapan jawaban. Di sini pengujiannya lebih ketat: pemilik produk harus memastikan apa yang dirilis dan siapa yang dapat memakainya.
Mulailah ketika bukti rilis tersedia
Gunakan catatan rilis produk sebagai pemicu, bukan perubahan status tiket. Catatan itu membutuhkan feature_id dan release_id yang stabil, perilaku fitur setelah rilis, tanggal rilis, status peluncuran, serta nama penanggung jawab. Pemilik harus memastikan fitur tersedia bagi akun atau paket pelanggan yang meminta. Perubahan kode yang digabung, demo staging, atau catatan rilis yang masih direncanakan tidak lolos.
Petakan permintaan ke rilis dengan ID fitur, dan permintaan ke pelanggan dengan ID kontak dalam sistem dukungan. Simpan hanya pemetaan dan status. Grok Bot tidak memerlukan seluruh kotak masuk atau katalog. Jika salah satu ID hilang, kembalikan sebagai item peninjauan, jangan menebak dari nama yang mirip.
| Masukan | Bidang minimum | Yang harus diverifikasi |
|---|---|---|
| Permintaan | ID tiket, ID fitur, tanggal permintaan, ID kontak pemohon | Orang itu benar-benar meminta fitur tersebut |
| Rilis | ID rilis, ID fitur, perilaku yang dirilis, ketersediaan, persetujuan pemilik | Akun itu dapat memakainya sekarang |
| Kontak | ID kontak, jalur dukungan yang disetujui, status pemblokiran pengiriman | Orang ini boleh menerima jawaban jenis ini |
Permintaan bukan persetujuan pemasaran. Gunakan jalur komunikasi dukungan yang disetujui untuk menjawab permintaan itu secara faktual. Jika draf mempromosikan fitur lain, menawarkan peningkatan paket, atau menargetkan orang yang tidak meminta, perlakukan sebagai kampanye pemasaran terpisah dengan aturan kelayakannya sendiri. Hormati berhenti berlangganan dan status pemblokiran pengiriman untuk saluran terpilih. Panduan konfirmasi dua tahap menjelaskan mengapa tiket tidak dapat menggantikan catatan langganan.
Tulis satu jawaban dengan prompt terbatas
Keluaran hipotetis memetakan T-104 ke F-7 dan R-22, tetapi menemukan peluncuran nonaktif. Tunggu; jangan kirim.
Salin prompt ini setelah menyediakan catatan yang disetujui:
Periksa hanya catatan permintaan, rilis, dan kontak yang saya berikan. Cocokkan dengan ID fitur dan ID kontak yang stabil, bukan kemiripan kata. Untuk setiap kandidat, tampilkan ID tiket, ID fitur, ID rilis, persetujuan pemilik, ketersediaan akun, tujuan komunikasi yang disetujui, dan status pemblokiran pengiriman. Tandai bukti yang hilang atau bertentangan sebagai terhalang. Tulis jawaban faktual singkat hanya untuk rilis yang terkonfirmasi dan tersedia. Jelaskan apa yang berubah, di mana pelanggan dapat memakainya, dan di mana mereka mendapat bantuan, hanya berdasarkan fakta yang diberikan. Jangan menganggap ada persetujuan pemasaran, menambah klaim promosi, membuat atau memperbarui kontak, mengirim pesan, atau menutup tiket. Kembalikan tabel bukti dan draf di sini untuk ditinjau.
Periksa: pemilik membandingkan draf dengan catatan rilis dan menguji ketersediaan di akun pemohon. Pemilik dukungan memeriksa identitas penerima dan tujuan komunikasi. Biarkan draf di chat jika pemeriksaan gagal. Panduan awal Grok Bot dan Brevo menjelaskan koneksi MCP yang terdokumentasi dan mengapa operasi yang tersedia masih perlu diperiksa; alur khusus ini belum dijalankan di akun Grok Bot.
Kirim sekali, lalu catat buktinya
Sebelum memasukkan pengiriman yang disetujui ke antrean, hitung kunci deduplikasi dari feature_id + contact_id + release_id dan reservasi kunci itu secara atomik dalam catatan yang disimpan secara persisten. Kunci yang sudah direservasi, menunggu, belum pasti, atau berhasil menghalangi pengantrean kedua. Dua pekerja tidak boleh lolos lewat pemeriksaan baca-lalu-tulis yang terpisah. Setelah batas waktu habis, cocokkan peristiwa dan bukti dari penyedia sebelum mempertimbangkan pengulangan; tidak adanya respons bukan bukti pesan gagal disampaikan.
Setelah ditinjau, atur jalur yang disetujui di Brevo. Di Automations > Workflows > Create an automation, jika akun Anda menampilkan pemicu peristiwa khusus dan tindakan email, petakan peristiwa usulan feature_followup_approved ke templat dengan tujuan dukungan yang disetujui. Peristiwa memerlukan pengenal kontak terverifikasi; ID fitur dan rilis adalah properti peristiwa usulan Anda, bukan nilai bawaan Brevo. Uji dengan kontak internal sebelum aktivasi. Keluarkan satu peristiwa hanya setelah persetujuan dan reservasi kunci berhasil. Jika tidak, gunakan jawaban dukungan manual. Brevo mendokumentasikan peristiwa khusus dan penyiapan alur; periksa tindakan yang tersedia di akun Anda. Draf Grok Bot tidak mengizinkan eksekusi. Panduan API Brevo membahas jalur API terpisah. Catat penerimaan peristiwa secara terpisah dari bukti pengiriman pesan. Peristiwa yang diterima tidak membuktikan email terkirim. Catat penerima tepat, teks yang disetujui, bukti rilis, tujuan, saluran, ID pengiriman penyedia, dan waktunya. Tandai tiket sudah ditindaklanjuti hanya setelah bukti pengiriman terkonfirmasi atau jawaban dukungan manual terdokumentasi. Dokumentasi MCP Brevo menetapkan kemungkinan permukaan integrasi, bukan jaminan bahwa setiap operasi tulis atau izin tersedia di klien Anda.
Tetapkan batas pengamatan untuk setiap rilis, misalnya tujuh hari setelah pemilik memastikan ketersediaan. Pada batas itu, ukur penyelesaian sebagai permintaan yang memenuhi syarat dengan satu tindak lanjut terkonfirmasi dibagi semua permintaan yang memenuhi syarat untuk rilis tersebut. Tampilkan permintaan terhalang dan tidak terjangkau sebagai jumlah terpisah. Status penyampaian dan balasan pelanggan membantu menemukan kegagalan; email yang dibuka tidak membuktikan pelanggan melihat atau memakai fitur. Rilis tanpa penerima terverifikasi masih menjadi pekerjaan terbuka. Disiplin bukti yang sama berlaku untuk eksperimen kampanye, meskipun hasilnya diukur berbeda.
Pertanyaan yang sering diajukan
Kapan fitur yang diminta siap untuk ditindaklanjuti kepada pelanggan?
Hanya setelah penanggung jawab memastikan ID rilis, ketersediaan fitur untuk akun pelanggan tersebut, dan perilaku yang benar-benar dirilis. Tiket yang ditutup, pull request yang digabung, atau draf catatan rilis tidak membuktikan pelanggan sudah dapat memakainya.
Apakah permintaan dukungan mengizinkan email pemasaran?
Tidak. Kirim jawaban faktual tentang permintaan pelanggan itu melalui proses komunikasi dukungan yang disetujui. Kampanye promosi yang lebih luas memerlukan audiens yang diizinkan dan dasar langganannya sendiri; tiket tidak menciptakan izin tersebut.
Bisakah Grok Bot mengirim pemberitahuan rilis melalui Brevo secara otomatis?
Panduan ini memakai Grok Bot untuk mencocokkan bukti dan menulis draf jawaban. Setiap penulisan data atau pengiriman melalui Brevo memerlukan koneksi yang diverifikasi secara terpisah, pemeriksaan izin, dan persetujuan. Kompatibilitas MCP yang didokumentasikan belum diuji dalam akun nyata di sini.