Bagaimana Saya Mengotomatisasi Alur Kerja Email 13 Bahasa Hanya Menggunakan AI dan Alat Microsoft

Melokalisasi kampanye email di berbagai wilayah dulu merupakan tugas yang lambat dan berulang dengan banyak langkah manual. Beberapa pengulas bekerja pada versi terpisah, konten yang sama ditulis ulang beberapa kali, dan mengelola konsistensi di hingga 13 bahasa memerlukan koordinasi yang signifikan.

Alih-alih memperkenalkan platform baru atau alat eksternal, saya menjalankan eksperimen internal: \n Bisakah lokalisasi diotomatisasi hanya menggunakan alat yang sudah tersedia di dalam lingkungan Microsoft enterprise standar?

Prototipe ini terutama mengandalkan SharePoint, Power Automate, dan Teams, dengan satu komponen tambahan - GPT-4.1 mini yang diakses melalui Azure OpenAI - digunakan secara ketat untuk langkah QA yang terkontrol. Ini memungkinkan proses mendapat manfaat dari penalaran berbasis LLM sambil menjaga semua data tetap berada dalam lingkungan enterprise yang sama.

Untuk mendukung alur kerja ini, saya menyiapkan perpustakaan SharePoint terstruktur bernama Email translations dengan folder yang mewakili setiap tahap siklus hidup lokalisasi:

| Folder | Tujuan | |----|----| | 01IncomingEN | File sumber bahasa Inggris; pemicu Power Automate | | 02AIDrafts | Draf terjemahan otomatis dari Copilot + GPT | | 03InReview | File yang menunggu peninjauan regional | | 04Approved | Terjemahan final yang disetujui | | 99Archive | Versi yang diarsipkan atau ditolak |

File berpindah secara otomatis di antara folder-folder ini tergantung pada statusnya.

Tujuannya bukan untuk membangun sistem lokalisasi yang sempurna - hanya untuk melihat sejauh mana prototipe bisa berjalan menggunakan alat internal.

Hasilnya berhasil menghilangkan sebagian besar pekerjaan berulang dan menciptakan proses peninjauan yang jauh lebih terstruktur.

Masalah: Proses, Bukan Bahasa

Melokalisasi konten secara manual di banyak wilayah menciptakan beberapa masalah konsisten:

• Setiap wilayah mengedit file mereka sendiri, sehingga beberapa versi berbeda ada pada saat yang sama.
• Ketika teks sumber berubah, tidak semua wilayah memperbarui versi mereka, yang menyebabkan konten tidak sesuai.
• File disimpan di tempat berbeda dan dengan nama berbeda, sehingga sulit mengidentifikasi versi mana yang terbaru.
• Peninjauan membutuhkan waktu, terutama ketika tim berada di zona waktu berbeda.
• Mengulang pengeditan yang sama di banyak file meningkatkan risiko kesalahan kecil

Percobaan 1: Terjemahan Hanya dengan Copilot

Meskipun Copilot sekarang berjalan pada model seri GPT-5 yang lebih baru, prototipe ini dibangun pada versi sebelumnya, dan perilaku terjemahan mencerminkan kemampuan awal tersebut.

Versi pertama alur kerja sangat sederhana:

1. File diunggah ke 01IncomingEN.
2. Power Automate dipicu secara otomatis.
3. Copilot menghasilkan terjemahan untuk setiap wilayah.

Karena pemicu SharePoint dapat aktif sebelum file selesai diunggah, alur kerja menyertakan pemeriksaan penyelesaian ukuran file (tunggu hingga ukuran > 0 sebelum melanjutkan).

Namun, masalah utama segera menjadi jelas: terjemahan Copilot tidak cukup andal untuk lokalisasi end-to-end.

Masalah umum termasuk:

• CTA diterjemahkan terlalu harfiah
• nada dan gaya bervariasi antar bahasa
• placeholder dihapus atau diubah
• perbedaan format dalam daftar, spasi, dan struktur

Ini membuat Copilot hanya berguna untuk menghasilkan draf pertama. \n Lapisan pemeriksaan kualitas kedua diperlukan.

Percobaan 2: Menambahkan GPT-4.1 Mini untuk QA

Versi berikutnya menambahkan langkah peninjauan:

1. Copilot → terjemahan awal
2. GPT-4.1 mini (Azure) → QA dan pemeriksaan konsistensi

GPT-4.1 mini meningkatkan:

• konsistensi nada
• pelestarian placeholder
• stabilitas format
• keselarasan dengan makna sumber

Prompt perlu disesuaikan untuk menghindari penulisan ulang yang tidak perlu, tetapi setelah penyesuaian, output menjadi cukup konsisten untuk digunakan dalam alur kerja.

Pekerjaan Teknik: Membuat Alur Kerja Andal

Arsitekturnya sederhana, tetapi beberapa masalah muncul selama penggunaan nyata dan memerlukan perbaikan.

Perilaku platform:

• Pemicu SharePoint tidak selalu mulai segera, sehingga pemeriksaan dan percobaan ulang ditambahkan.
• Perutean Teams gagal ketika saluran diganti namanya, sehingga pemetaan harus diperbarui.

Masalah desain:

• Beberapa langkah paralel gagal pada percobaan pertama, sehingga logika percobaan ulang diperkenalkan.
• Respons JSON terkadang kehilangan bidang yang diharapkan, sehingga validasi ditambahkan.
• Nama file tidak konsisten, sehingga format penamaan tunggal ditetapkan.

Setelah penyesuaian ini, alur kerja berjalan dengan andal dalam kondisi normal.

Arsitektur Prototipe Final

Di bawah ini adalah struktur kerja lengkap dari sistem.

1. Unggah & Penerimaan SharePoint

Proses dimulai ketika file diunggah ke Email translations / 01IncomingEN

Power Automate kemudian:

• memeriksa bahwa file telah sepenuhnya diunggah (penjaga byte-nol)
• mengambil metadata
• mengekstrak teks
• mengidentifikasi wilayah target

SharePoint bertindak sebagai sumber kebenaran tunggal untuk semua tahap.

2. Orkestrasi Power Automate

Power Automate mengontrol setiap bagian alur kerja:

• membaca sumber bahasa Inggris
• memanggil Copilot untuk draf terjemahan
• mengirim draf ke GPT-4.1 mini untuk QA
• membuat cabang per wilayah
• mengirim email output ke tim lokal
• memposting kartu persetujuan Teams
• menangkap "approve" atau "request changes"
• menyimpan file yang disetujui di 04_Approved
• menyimpan versi yang diperbarui di 03InReview
• mengarsipkan versi lama di 99_Archive

Semua perutean, percobaan ulang, dan transisi status ditangani oleh Power Automate.

3. Tahap Terjemahan Copilot

Copilot menerjemahkan konten yang diekstrak dan mempertahankan sebagian besar struktur email - daftar, spasi, dan format - lebih baik daripada GPT saja.

4. Tahap QA GPT-4.1 Mini

GPT-4.1 mini memeriksa:

• konsistensi nada
• keselarasan makna
• stabilitas format
• integritas placeholder

Ini menciptakan draf yang lebih andal untuk peninjauan regional.

5. Peninjauan Regional (Email + Teams)

Untuk setiap wilayah, Power Automate:

• mengirim file terjemahan melalui email
• memposting kartu adaptif Teams dengan Approve / Request changes

Jika perubahan diajukan, file yang diperbarui kembali ke 03InReview dan masuk kembali ke alur kerja.

6. Penyimpanan Final

Terjemahan yang disetujui disimpan di 04_Approved menggunakan format penamaan yang konsisten.

Versi yang ditolak atau usang dipindahkan ke 99_Archive. Ini memastikan jejak audit yang lengkap dan bersih.

Hasil

Setelah menguji prototipe dalam alur kerja nyata:

• waktu terjemahan turun dari berhari-hari menjadi menit
• lebih sedikit konflik versi
• penulisan ulang manual minimal
• siklus peninjauan lebih cepat
• semua data diproses di dalam lingkungan Microsoft

Ini tidak menggantikan sistem lokalisasi khusus, tetapi menghilangkan sejumlah besar pekerjaan manual berulang.

Keterbatasan

• beberapa bahasa masih memerlukan penyesuaian gaya
• persetujuan Teams bergantung pada waktu respons pengulas
• alur membutuhkan logika percobaan ulang untuk kesalahan sementara
• konsistensi nada bervariasi pada email yang panjang atau kompleks

Ini dapat diterima untuk sebuah prototipe.

Langkah Selanjutnya: Memori Terminologi

Peningkatan yang direncanakan berikutnya adalah perpustakaan terminologi berbasis vektor yang berisi:

• glosarium
• nama produk
• istilah terbatas
• frasa khusus wilayah
• kelompok sinonim
• aturan nada

Kedua model akan menggunakan perpustakaan ini sebelum menghasilkan atau memeriksa terjemahan.

Pemikiran Akhir

Proyek ini adalah eksperimen internal untuk memahami seberapa banyak alur kerja lokalisasi yang dapat diotomatisasi hanya menggunakan alat Microsoft standar dan satu LLM yang dihosting di Azure. Prototipe ini secara signifikan mengurangi upaya manual dan meningkatkan konsistensi di seluruh wilayah tanpa menambahkan perangkat lunak baru.

Ini bukan platform lokalisasi lengkap - tetapi menunjukkan apa yang dapat dicapai dengan alur kerja sederhana dan terstruktur dengan baik di dalam tumpukan enterprise yang ada.

\