OpenAI Decisions API: Triase Support untuk Tim Indonesia

Apa itu OpenAI Decisions API?

OpenAI Decisions API membantu aplikasi mengelompokkan dan menilai input teks atau gambar. Untuk tim support Indonesia, titik awal yang berguna adalah menyarankan antrean penanganan tiket. Keputusan tentang refund, pemulihan akun, dan balasan pelanggan tetap perlu aturan operasional sendiri.

OpenAI mengumumkan beta pada 6 Oktober 2026 dalam changelog API. Saat diperiksa pada 7 Oktober 2026, panduan Decisions menyebut public beta, endpoint POST /v1/decisions, dan gpt-6-luna sebagai satu-satunya model yang tersedia.

Artikel ini menawarkan rancangan pilot dan contoh sintetis. Contohnya belum dijalankan ke API, bukan hasil implementasi klien, dan tidak menunjukkan akurasi atau penghematan terukur.

Pilih bentuk jawaban yang dibutuhkan

Decisions menyediakan tiga jenis pertanyaan: predicate untuk probabilitas suatu kondisi, choice untuk memilih opsi, dan score untuk penilaian rubrik. Skor memakai rata-rata berbobot probabilitas dari indeks level yang dimulai dari nol, sehingga dapat berupa pecahan. Lihat jenis pertanyaan Decisions.

Untuk pilot, gunakan satu choice bernama support_queue. Tetapkan empat antrean:

• pembayaran: tagihan, bukti bayar, atau permintaan pengembalian dana.
• teknis: fitur atau proses penggunaan produk bermasalah.
• pengiriman: resi, status kirim, atau paket belum diterima.
• review: masalah di luar kategori, konteks belum cukup, atau beberapa masalah tanpa prioritas yang jelas.

Tulis juga batasnya. “Tidak bisa bayar karena halaman checkout kosong” masuk teknis dalam rancangan ini; “pembayaran berhasil tetapi ditagih lagi” masuk pembayaran. Bila tim berbeda pendapat, perbaiki definisi sebelum mengubah prompt. Model tidak dapat menyelesaikan kebijakan antrean yang belum disepakati.

Butuh nomor pesanan, ringkasan, dan penjelasan dalam objek JSON? Pertimbangkan Structured Outputs dengan schema yang didukung. Butuh model meminta pemanggilan alat? Gunakan function calling; aplikasi Anda tetap menjalankan kode alat dan memeriksa kewenangannya.

Susun contoh uji Bahasa Indonesia

Mulai dengan tiket sintetis untuk menyepakati aturan. Setelah itu, gunakan sampel yang sudah disamarkan dan diizinkan pemilik data. Sertakan singkatan, salah ketik, campuran Bahasa Indonesia–Inggris, serta pesan lanjutan yang membutuhkan konteks.

Berikut label harapan untuk aturan pilot di atas, bukan prediksi API:

Pesan contoh	Antrean harapan	Hal yang diperiksa
“Kak, status paket belum berubah sejak Senin.”	pengiriman	Status kirim tetap dikenali tanpa kata “resi”.
“Udah bayar, kok invoice muncul lagi?”	pembayaran	Keluhan tagihan dibedakan dari gangguan checkout.
“Pas klik bayar layarnya putih, belum kepotong.”	teknis	Kata “bayar” tidak mendominasi konteks.
“Pesanan sudah datang, tapi akun saya gabisa login.”	teknis	Kata “pesanan” tidak otomatis berarti pengiriman.
“Yang kemarin itu gimana ya?”	review	Konteks yang hilang tidak ditebak.
“Paket belum datang dan ada tagihan ganda.”	review	Dua masalah tidak dipaksa menjadi satu.

Minta dua anggota tim melabeli sebagian sampel secara terpisah. Bahas perbedaan dan simpan alasan keputusan manusia. Pisahkan data penyetelan dari data uji akhir agar evaluasi tidak hanya mengukur contoh yang sudah dipakai memperbaiki instruksi.

Tentukan kapan sistem harus menahan diri

Respons choice menyertakan probabilities dan confidence; jangan menganggap keduanya sama. Format juga mengizinkan jawaban refusal. Gambar harus berupa inline base64 data URL, bukan URL HTTP(S) atau file_id. Detail kontrak ada di referensi Decisions dan batas input gambar.

Untuk versi pertama, cukup proses teks. Berikut kebijakan aplikasi yang disarankan:

1. Tolak input kosong dan batasi data pada konteks yang diperlukan untuk triase.
2. Baca jawaban yang sesuai dengan nama pertanyaan, lalu validasi jenis dan opsi yang diterima.
3. Arahkan review, refusal, jawaban tidak lengkap, timeout, dan kesalahan API ke antrean manusia. Jangan mengubahnya menjadi kategori bawaan yang terlihat sukses.
4. Tahan hasil yang belum memenuhi ambang evaluasi tim. Ambang harus dikalibrasi dengan data berlabel; angka seperti 0,9 tidak otomatis berarti 90% tiket dirutekan benar.
5. Catat rute usulan, versi instruksi, keputusan reviewer, dan alasan koreksi tanpa menyalin data pelanggan yang tidak perlu.

Pertimbangkan biaya setiap jenis kesalahan. Salah mengirim pertanyaan resi ke tim teknis membuang waktu; gagal mengenali dugaan pengambilalihan akun bisa lebih berat. Buat jalur eskalasi khusus untuk kasus sensitif, terlepas dari keyakinan klasifikasi umum.

Hubungkan ke workflow secara bertahap

Alur konseptualnya: tiket masuk, minimalkan data, minta klasifikasi, validasi respons, periksa kebijakan review, lalu tulis saran rute ke catatan internal.

Untuk n8n, pola yang dapat diuji adalah HTTP Request untuk request API, If untuk memeriksa syarat review, lalu Switch untuk memetakan label yang lolos. Atur fallback Switch ke Extra Output dan sambungkan ke antrean manusia; perilaku default untuk item tanpa kecocokan adalah mengabaikannya. Jalur kesalahan request tetap perlu ditangani terpisah.

Ini adalah usulan integrasi berdasarkan fungsi node, belum diuji pada API, versi, atau kredensial Anda. Artikel ini tidak menyediakan node Decisions bawaan atau workflow siap impor.

Mulai dalam mode observasi: manusia tetap merutekan tiket, sementara sistem hanya mencatat sarannya. Bandingkan keduanya tanpa mengubah antrean pelanggan. Setelah kualitas terbukti, aktifkan perubahan internal untuk kategori berisiko rendah yang disepakati. Pertahankan cara sederhana untuk kembali ke triase manual.

Gunakan identitas tiket untuk mencegah penulisan catatan ganda saat retry. Batasi percobaan ulang, tampilkan kegagalan kepada operator, dan pastikan antrean review punya penanggung jawab. Antrean yang aman secara teknis tetap gagal secara operasional bila tidak ada yang membacanya.

Ukur hasil sebelum memperluas otomasi

Bandingkan pilot dengan proses manual atau aturan kata kunci yang sudah ada. Catat:

• Salah rute per kategori, termasuk jenis kesalahan yang paling mahal.
• Tiket yang ditahan untuk review dan kapasitas staf untuk menanganinya.
• Waktu sampai tiket diterima tim yang tepat, termasuk antrean dan koreksi.
• Kasus ambigu yang memerlukan konteks tambahan.
• Biaya API aktual serta waktu pemeliharaan dan peninjauan.

Tetapkan kriteria lulus sebelum melihat hasil. Jangan menghapus antrean review hanya agar persentase otomasi naik. Jika bahasa pelanggan, produk, atau kategori berubah, ulangi evaluasi. Kecepatan pemanggilan model saja belum menjelaskan waktu penyelesaian tiket.

Latihan triase support bersama Fahmi

Hubungi Fahmi Fahreza untuk membahas pelatihan AI automation dengan satu proses support yang ingin dipelajari. Bawa kategori, contoh aman, dan ukuran keberhasilan agar diskusi berangkat dari pekerjaan nyata. Materi praktik dapat dibahas sesuai kebutuhan dan akses alat tim.

Untuk fondasi workflow, baca AI agent dengan n8n untuk bisnis. Untuk sesi tim, lihat pelatihan AI untuk perusahaan.