Cara Bikin AI Draft Email yang Nulis Pakai Gaya Kita, Bukan Gaya Robot

Saya suka automation. Tapi saya kurang suka automation yang sok pintar lalu bikin malu.

Itu juga yang sering saya rasain waktu lihat demo AI untuk email. Kelihatannya keren di awal. Bisa baca inbox, bisa bikin balasan, bisa auto ini auto itu. Tapi begitu lihat isi draft-nya, rasanya langsung ketahuan. Terlalu rapi, terlalu generik, terlalu “assistant banget”, dan kadang yang paling ngeselin, tone-nya sama sekali bukan tone kita.

Buat email bisnis, itu bahaya.

Soalnya problem utama email bukan sekadar ngebalas lebih cepat. Problem utamanya adalah ngebalas cepat tanpa kehilangan suara asli, konteks thread, dan sense of risk.

Di artikel ini saya mau tunjukin flow yang menurut saya jauh lebih waras.

Bukan auto-send. Bukan AI yang dikasih kebebasan kebanyakan. Tapi flow yang fokus ke hal-hal yang benar-benar penting:

• filter email dulu
• baca full thread, bukan cuma email terakhir
• cek bahasa dan konteks bisnis
• pakai referensi dari email yang benar-benar pernah kita kirim
• bikin draft di thread Gmail yang sama
• kirim notifikasi ke Telegram setelah draft jadi

Kalau kamu mau versi yang lebih teknis, full English, dan lebih detail level implementasi, saya juga bikin companion tutorial di GitHub:

https://github.com/fanani-radian/openclaw-sumopod/blob/main/tutorials/gmail-ai-draft-real-voice.md

Kalau kamu butuh VPS buat OpenClaw, QwenPaw, atau automation stack kayak begini, daftar lewat link affiliate kita aja di sini:

https://blog.fanani.co/sumopod

Artikel ini fokus ke cara berpikir dan alur yang gampang dicerna. Jadi kalau GitHub version itu workshop teknis, versi blog ini lebih kayak saya ngajak kamu duduk bentar lalu bongkar kenapa flow ini actually works.

Kenapa Banyak AI Email Workflow Terasa Salah

Saya rasa problem-nya ada tiga.

1. Mereka terlalu cepat masuk ke drafting

Begitu ada email masuk, langsung lempar ke model. Itu kesalahan pertama.

Padahal inbox itu isinya campur aduk. Ada promosi, ada notifikasi, ada OTP, ada receipt, ada FYI, ada thread yang sebenarnya belum perlu dibalas, dan ada email yang memang butuh respons. Kalau semua diperlakukan sama, AI-nya bukan jadi pintar. Dia cuma jadi mahal dan noisy.

2. Mereka baca satu email, bukan satu percakapan

Email bisnis itu jarang berdiri sendiri. Selalu ada jejak di belakangnya. Siapa pernah janji apa, bahasa yang biasa dipakai apa, nada percakapan formal atau santai, konteks perusahaan mana yang dibawa, semua itu hidup di thread.

Kalau sistem cuma baca satu body lalu improvisasi, hasilnya pasti goyang.

3. Mereka belajar tone dari prompt generik, bukan dari email asli kita

Ini yang paling fatal.

Karena tone email itu beda dari tone blog, beda dari tone WhatsApp, beda dari tone caption, dan beda juga dari tone “professional AI” yang biasa dibikin model kalau nggak dikasih grounding.

Saya nggak butuh AI yang bisa nulis email “bagus” menurut internet. Saya butuh AI yang bisa nulis email yang kedengeran kayak saya.

Jadi Flow yang Benar Itu Kayak Apa?

Menurut saya, flow yang waras itu justru kelihatannya sederhana.

Urutannya begini:

1. ambil kandidat email unread yang memang layak diproses
2. buang noise dulu dengan hard filter
3. ambil full thread context
4. cek language, company context, dan risk
5. kasih model referensi tone dari sent mail
6. generate draft reply yang pendek, langsung, dan aman
7. bikin draft di Gmail thread yang sama
8. kirim notifikasi ke Telegram

Kalau urutan ini dibalik, hasilnya biasanya jelek.

Misalnya kamu draft dulu baru mikir risk belakangan. Itu sama aja ngebut dulu baru cari rem. Tidak smart.

Step 1: Filter Dulu, Jangan Sok Pintar Duluan

Saya lebih percaya filter yang jujur daripada AI yang terlalu percaya diri.

Yang dimaksud hard filter di sini itu simpel banget. Jangan proses email yang jelas-jelas tidak butuh balasan.

Contohnya:

• promotions
• social update
• no-reply sender
• OTP
• receipt
• verification code
• pure system notification
• thread yang terakhir justru email kita sendiri dan sekarang tinggal nunggu mereka

Flow filter-nya seperti ini:

Bagian ini penting, karena kalau dari awal kamu sudah bersih, sisa workflow jadi lebih waras.

Banyak orang pengen langsung masuk ke LLM, classifier, embeddings, prompt engineering, padahal problem utamanya cuma belum bisa bilang “email ini nggak usah diproses”.

Yang lucu, begitu filter ini bener, jumlah email yang benar-benar layak didraft sering kali kecil. Dan itu bagus. Artinya sistemmu tidak sibuk pamer. Sistemmu sibuk bantu.

Step 2: Baca Thread, Bukan Cuma Email Terakhir

Ini lompatan kualitas paling besar.

Saya serius.

Kalau kamu cuma lihat email terakhir, kamu bakal kehilangan hal-hal yang sebenarnya menentukan jawaban:

• apakah sebelumnya sudah ada penawaran harga
• apakah delivery pernah dijanjikan
• apakah lawan bicara pakai English atau Indonesian
• apakah konteksnya RFM, UST, REFOREL, RFS, atau personal
• apakah kita sedang menjelaskan, menolak, follow up, atau klarifikasi

Makanya di workflow ini ada step khusus buat normalize thread jadi JSON context.

Secara praktis, thread context builder ini ngelakuin beberapa hal:

• ambil full thread dari Gmail via Gog CLI
• extract header penting seperti from, to, subject, date
• deteksi mana latest inbound message
• kumpulin beberapa sent example terakhir
• tebak bahasa
• tebak company context
• kasih risk flag kalau ada keyword sensitif

Jadi saat model nanti mulai nulis, dia nggak nulis dari ruang kosong. Dia nulis dari konteks yang sudah dibersihkan.

Ini bedanya besar banget.

Karena AI yang nulis dari konteks lengkap biasanya terdengar seperti assistant yang ngerti percakapan. AI yang nulis dari satu snippet biasanya terdengar seperti orang baru masuk meeting pas menit terakhir.

Step 3: Tone Itu Harus Diambil dari Email Asli, Bukan dari Blog

Ini decision penting yang menurut saya wajib dibedain.

Blog ini pakai gaya saya yang lebih analitis dan lebih panjang. Tapi email saya tidak seperti itu.

Email kerja biasanya lebih:

• formal
• direct
• calm
• singkat
• nggak banyak fluff
• nggak pakai basa-basi AI

Jadi jangan campur dua dunia ini.

Saya malah sengaja pisahin rules-nya. Email tone tidak boleh diwarisi dari tone blog. Dia harus belajar dari sent items.

Karena di sent items itulah kelihatan pola yang real:

• kalau thread-nya English, jawabnya English
• kalau vendor lokal atau client lokal, jawabnya Indonesian
• opener sering formal, misalnya Dear Pak ... atau Dear Xendit Team
• closer juga sederhana, misalnya Regards, atau Best Regards,
• no fake warmth
• no nonsense sentence kayak “I hope this email finds you well”

Tone router-nya kira-kira begini:

Menurut saya ini jauh lebih masuk akal daripada bikin satu prompt super panjang yang isinya suruh model “sound professional, but warm, but concise, but helpful, but human”. Itu prompt kayak orang bingung.

Lebih baik kasih bukti real. Nih, ini gaya email yang benar. Ikutin ini.

Step 4: Risk Gate Itu Wajib, Bukan Optional

Kalau email menyangkut hal-hal sensitif, workflow harus berubah mode.

Yang saya anggap high-risk misalnya:

• quotation
• price atau pricing
• invoice
• payment
• transfer
• delivery
• contract
• agreement
• dispute
• penalty
• topik legal atau komitmen yang belum jelas

Begitu ada keyword atau pola yang mengarah ke situ, sistem tidak perlu panik. Tapi sistem harus lebih hati-hati.

Artinya apa?

Artinya draft yang dihasilkan harus:

• lebih pendek
• lebih konservatif
• tidak ngarang angka
• tidak ngarang timeline
• tidak ngarang janji
• kalau datanya kurang, mending minta klarifikasi singkat

Ini menurut saya pembeda penting antara automation yang usable dan automation yang ujungnya bikin orang takut pakai.

Kalau AI kamu santai banget saat ngebahas harga, transfer, atau kontrak tanpa guardrail, itu bukan canggih. Itu sembrono.

Step 5: Draft Dibuat di Gmail Thread yang Sama

Ini detail yang kelihatannya kecil, tapi impact-nya gede.

Saya nggak mau draft numpuk di tool lain lalu ujung-ujungnya harus copy-paste manual ke Gmail. Kalau workflow sudah tahu thread mana yang mau dibalas, draft-nya harus muncul di tempat yang benar.

Yaitu di Gmail thread yang sama.

Begitu draft masuk langsung ke Gmail, operator tinggal buka thread, baca cepat, edit kalau perlu, lalu kirim. Friksi turun banyak.

Dan ini penting buat trust.

Karena begitu output akhirnya hidup di interface yang memang dipakai sehari-hari, automation terasa jadi bagian dari kerja. Bukan eksperimen yang berdiri sendiri.

Saya lebih suka workflow yang invisible-but-useful kayak gini daripada workflow yang tampil keren di dashboard tapi malah nambah langkah kerja.

Step 6: Telegram Notification Setelah Draft Jadi

Saya sengaja bikin ini mandatory.

Karena draft yang dibuat diam-diam itu kurang ajar sedikit.

Kalau sistem habis bikin draft, operator harus tahu. Bukan nanti pas kebetulan buka Gmail. Bukan pas iseng cek folder Drafts. Tapi langsung dapat signal.

Flow notifikasinya sederhana:

Isi notifikasi yang ideal menurut saya cukup ini:

• siapa pengirimnya
• subject-nya apa
• language: ID atau EN
• risk level: low atau high
• draft berhasil dibuat atau tidak
• kalau high-risk, kasih note bahwa review disarankan

Selesai.

Nggak perlu overreporting. Telegram bukan tempat baca audit log sepanjang satu layar.

Cukup kasih sinyal yang bikin saya tahu:

“oke, ada draft masuk, topiknya ini, risk-nya segini, tinggal saya review.”

Itu udah cukup banget.

Gimana Rasanya Dipakai di Dunia Nyata?

Menurut saya ini justru bagian yang paling meyakinkan.

Sebelum itu, ada satu hal yang perlu saya tegaskan. Workflow ini bukan cuma soal teknologi, tapi soal menjaga identitas komunikasi.

Karena banyak orang sekarang nyampur semua gaya nulis jadi satu. Padahal harusnya dipisah.

• gaya blog untuk artikel panjang
• gaya chat untuk obrolan cepat
• gaya email untuk komunikasi kerja

Kalau semuanya dilebur, hasilnya jadi aneh. Email terasa terlalu editorial. Blog terasa terlalu kaku. Chat terasa terlalu formal. Dan AI biasanya makin memperparah masalah itu kalau referensinya tidak dipisah dari awal.

Makanya saya sengaja bikin boundary yang jelas. Email voice tetap email voice.

Menurut saya ini justru bagian yang paling meyakinkan.

Begitu workflow ini hidup, pengalaman operator berubah dari:

• buka inbox
• lihat puluhan unread
• bingung mulai dari mana
• buka satu-satu
• mikir tone-nya harus seperti apa
• ngetik dari nol

menjadi:

• scan candidate email yang memang penting
• pilih thread
• biarkan sistem siapkan draft awal
• baca hasilnya 20 sampai 60 detik
• edit kecil kalau perlu
• kirim

Itu beda banget.

Yang hemat bukan cuma waktu ngetik. Yang hemat juga energi mikir untuk mulai.

Dan buat saya, blank page itu sering jadi musuh paling nyebelin dalam email. Bukan karena saya nggak bisa nulis, tapi karena saya nggak mau mulai dari nol sepuluh kali sehari.

Kalau sistem bisa ngasih first draft yang nadanya sudah dekat, konteksnya sudah bener, dan risk-nya sudah kebaca, operator tinggal masuk sebagai editor terakhir. Itu posisi kerja yang jauh lebih enak.

Contoh Bentuk Draft yang Bagus Itu Seperti Apa?

Draft yang bagus bukan draft yang paling panjang. Bukan juga draft yang paling sopan.

Draft yang bagus itu biasanya punya karakter ini:

• buka dengan sapaan yang sesuai
• jawab inti email secepat mungkin
• kalau ada data kurang, minta klarifikasi singkat
• kalau ada next step, tulis jelas
• tutup dengan sopan, tapi nggak teatrikal

Misalnya ada vendor lokal tanya status atau minta konfirmasi sederhana. Draft yang bagus biasanya cukup 4 sampai 8 kalimat. Tidak perlu paragraf penuh basa-basi.

Kalau thread-nya high-risk, misalnya nyangkut harga atau delivery, draft yang bagus malah cenderung lebih hati-hati. Dia tidak buru-buru memberi angka. Dia tidak sok yakin. Dia memilih aman.

Menurut saya ini penting banget dipahami, karena banyak orang keburu menilai kualitas draft dari “wah, kok detail banget”. Padahal di email bisnis, terlalu detail dengan data yang belum pasti itu sering lebih bahaya daripada draft pendek yang minta klarifikasi.

Step 7: Kenapa Saya Nggak Pilih Auto-Send

Karena email bisnis itu bukan tempat untuk gambling kecil-kecilan.

Saya tahu daya tarik auto-send itu besar. Rasanya lebih future-proof, lebih “AI native”, lebih spektakuler waktu didemo. Tapi jujur aja, di banyak use case, auto-send itu problem yang salah buat diselesaikan dulu.

Yang kita butuhin pertama kali bukan robot yang berani kirim. Yang kita butuhin adalah asisten yang bisa nyiapin jawaban dengan cepat dan tepat.

Kalau draft-nya sudah bagus, review manusia tinggal 20 sampai 60 detik.

That is the sweet spot.

Kita dapat semua manfaat utama:

• hemat waktu ngetik
• tidak mulai dari blank page
• tone lebih konsisten
• context lebih kebaca
• risk masih dikontrol

Dan kita menghindari downside paling mahal:

• salah janji
• salah angka
• salah bahasa
• salah company context
• salah kirim sesuatu yang harusnya belum dikirim

Menurut saya, itu deal yang jauh lebih waras.

Siapa yang Cocok Pakai Flow Kayak Gini?

Menurut saya, flow ini cocok banget buat orang yang:

• punya inbox kerja yang lumayan aktif
• sering jawab email dengan pola yang mirip
• megang beberapa konteks bisnis atau beberapa company identity
• pengen lebih cepat, tapi nggak mau kehilangan kontrol
• benci draft email yang terlalu AI banget

Kalau use case kamu cuma jawab 2 email per minggu, ya mungkin ini overkill. Santai aja. Nggak semua hal harus diotomasi.

Tapi kalau kamu tiap hari buka inbox dan ngerasa energi habis buat nulis balasan yang sebenarnya polanya mirip-mirip, workflow kayak gini mulai terasa sangat masuk akal.

Terutama buat founder, operator, GM, admin senior, atau personal assistant yang harus jaga kualitas respons tapi juga butuh speed.

Step 8: Bagaimana Bentuk Workflow Lengkapnya

Kalau disederhanakan banget, workflow harian ini bentuknya seperti loop operasional kecil.

Secara manual atau semi-otomatis, alurnya seperti ini:

1. scan unread inbox candidate
2. pilih thread yang memang perlu respons
3. build normalized thread context
4. minta model bikin draft berdasarkan context + tone rules
5. simpan hasilnya sebagai body text
6. create Gmail draft in-thread
7. render summary
8. send Telegram notification

Kalau suatu saat mau dijadikan cron atau heartbeat-safe workflow, tinggal bungkus proses ini. Fondasinya sudah bener dulu.

Dan menurut saya memang harus begitu. Jangan mulai dari scheduler megah kalau logic dasarnya belum matang.

Bagian yang Menurut Saya Paling Penting Bukan Teknologinya

Aneh ya, kita ngomongin AI email workflow, tapi poin paling penting justru bukan model apa yang dipakai.

Yang paling penting itu mindset desainnya.

Prinsip 1: jangan kasih AI kebebasan di layer yang salah

Biarkan dia bantu drafting. Jangan langsung kasih dia hak kirim.

Prinsip 2: evidence beats vibes

Tone jangan ditebak. Ambil dari sent items.

Prinsip 3: context beats raw prompt

Thread history lebih berharga daripada prompt yang puitis.

Prinsip 4: operator trust itu metrik utama

Kalau hasilnya technically oke tapi bikin operator tidak percaya, workflow tetap gagal.

Prinsip 5: boring systems often win

Hard filters, JSON context, risk keywords, draft only, Telegram ping. Kedengarannya nggak seksi. Tapi justru itu yang bikin sistemnya kepakai.

Kalau Mau Mulai, Mulai dari Versi Kecil Dulu

Menurut saya versi v1 yang paling masuk akal itu jangan kebanyakan fitur.

Cukup punya ini dulu:

• unread inbox scan
• skip rule yang jelas
• thread context builder
• bahasa dan risk detection
• tone note dari sent mail
• draft creation di Gmail
• Telegram notification

Sudah.

Kalau mau lebih kebayang, ini starter checklist yang menurut saya paling waras:

• Gog CLI sudah bisa akses Gmail account yang benar
• query unread inbox tidak ikut promotions dan social
• thread context JSON keluar dengan field yang rapi
• language detection minimal masuk akal
• company context tidak sering salah tebak
• risk keyword list sudah mencakup pricing, payment, delivery, contract
• hasil draft masuk ke thread Gmail yang sama
• Telegram notification keluar setiap draft dibuat
• operator masih bisa review dalam hitungan detik

Kalau checklist itu lolos, v1 kamu sudah usable.

Dan itu menurut saya poin yang sering dilupain. Banyak orang nunggu sistemnya terasa sempurna dulu baru mau dipakai. Padahal justru dengan v1 yang usable, kamu mulai bisa lihat pola edit manusia yang sesungguhnya. Dari situ baru kelihatan apakah tone masih kurang tegas, apakah Telegram summary terlalu panjang, apakah risk flag terlalu sensitif, atau apakah company context masih suka meleset.

Jadi jangan buru-buru ngejar sistem final. Kejar sistem yang cukup aman untuk dipakai, lalu belajar dari real review habit.

Begitu itu stabil, baru mikir layer berikutnya, misalnya:

• signature selection per company
• VIP sender priority
• calendar lookup untuk meeting request
• canned answers untuk kasus berulang
• feedback learning dari edit operator

Kalau kamu lompat ke sana duluan, kamu cuma bikin sistem makin berat sebelum fondasinya trusted.

Tiga Kesalahan yang Sebaiknya Jangan Diulang

1. Menganggap semua unread email harus diproses

Nggak perlu. Banyak email justru harus dibuang dari jalur AI secepat mungkin.

2. Minta model “jadilah human” tanpa kasih contoh email asli

Model bukan cenayang. Kalau mau tone-nya benar, kasih referensi yang benar.

3. Fokus ke model choice, lupa ke workflow shape

Model bagus tetap bisa hasilkan workflow jelek kalau entry filter, context builder, dan risk gate-nya kacau.

Menurut saya ini salah satu pelajaran paling useful dari project beginian. Sering kali kualitas akhir bukan datang dari model yang paling canggih, tapi dari urutan sistem yang paling disiplin.

Penutup

Saya rasa flow ini menarik karena dia tidak mencoba jadi hero.

Dia cuma fokus ngelakuin satu hal dengan benar: mempersiapkan balasan email yang terasa seperti ditulis oleh kita sendiri, dengan konteks yang cukup, lalu menyerahkannya ke manusia untuk review terakhir.

Buat saya, itu definisi automation yang matang.

Bukan yang paling berisik. Tapi yang paling kepake.

Kalau kamu pengen versi yang lebih teknis, full command-level, dan lebih detail implementasinya, langsung baca companion tutorial di GitHub:

https://github.com/fanani-radian/openclaw-sumopod/blob/main/tutorials/gmail-ai-draft-real-voice.md

Kalau kamu mau jalanin stack semacam ini di VPS dan sekalian support konten kita, daftar lewat link ini:

https://blog.fanani.co/sumopod

Menurut saya, mulai dari draft-only itu keputusan yang tepat. Build trust dulu. Auto-send belakangan, kalau memang suatu hari benar-benar perlu.