Ubah permintaan Slack menjadi produk internal dengan mengenali permintaan berulang, membuat satu antrean, dan menambahkan otomatisasi hanya setelah alur kerja berjalan.
Beberapa permintaan di Slack terasa sepele. Lalu pertanyaan yang sama mulai muncul setiap hari: "Bisakah Anda menambahkan akses?" "Bisakah Anda memperbaiki laporan ini?" "Bisakah Anda membuat workspace baru?" Bantuan yang awalnya cepat berubah menjadi sistem tidak resmi tanpa struktur.
Masalah pertama adalah tersebar. Permintaan datang lewat pesan langsung, channel tim, grup privat, dan thread samping. Ada yang menyertakan konteks, ada yang tidak. Orang ingat pernah melihat permintaan, tapi tidak di mana asalnya atau apakah sudah ada yang menanganinya. Pekerjaan hilang karena tidak pernah masuk ke satu antrean yang jelas.
Masalah kedua adalah detail yang kurang. Orang meminta cepat, seringkali sebelum tahu informasi mana yang penting. Jadi orang yang mengerjakan harus mengejar informasi dasar seperti siapa yang perlu akses, sistem mana yang terkait, atau kapan perubahan dibutuhkan. Tugas lima menit berubah jadi bolak-balik panjang.
Urgensi memperburuk situasi. Pesan paling berisik lompat ke depan, padahal belum tentu paling penting. Permintaan yang tenang tapi penting tertinggal. Seiring waktu, tim berhenti bekerja berdasarkan prioritas dan mulai bereaksi pada orang yang terakhir memposting dengan tekanan terbesar.
Lalu ada status. Tanpa antrean bersama, pertanyaan sederhana jadi sulit dijawab:
Kurangnya visibilitas itu menciptakan pekerjaan ulang, keterlambatan, dan frustrasi di kedua sisi. Pemohon merasa diabaikan. Tim yang menangani merasa terus-terusan terganggu. Yang tampak seperti masalah chat sebenarnya masalah alur kerja.
Mulai dari permintaan yang muncul terus-menerus. Jangan menebak. Tinjau pesan nyata dari dua sampai empat minggu terakhir dan lihat apa yang sebenarnya diminta orang.
Jendela tinjauan singkat biasanya cukup. Itu menunjukkan permintaan yang terjadi setiap minggu tanpa menarik pengecualian lama yang tak lagi penting.
Saat memindai pesan, kelompokkan permintaan berdasarkan tipe. Anda tidak perlu kategori yang sempurna. Anda hanya perlu pandangan praktis tentang apa yang berulang: permintaan akses, pengambilan laporan, cek persetujuan, pembaruan data kecil, pengaturan workspace baru, dan tugas serupa.
Sheet sederhana sudah memadai. Untuk setiap permintaan, catat:
Poin terakhir seringkali lebih penting daripada yang diduga banyak tim. Jika beberapa orang yang sama terus memenuhi permintaan yang sama, Anda mungkin sudah melihat kerangka produk internal. Anda bisa melihat di mana pengetahuan berada, di mana keterlambatan terjadi, dan di mana proses terlalu bergantung pada satu orang.
Polanya muncul cepat. Tim penjualan mungkin terus meminta bagian keuangan untuk pengecualian harga yang sama. Karyawan baru mungkin terus menghubungi IT untuk izin aplikasi yang sama. Manajer mungkin meminta operasi untuk pembaruan status mingguan yang serupa dengan kata-kata sedikit berbeda.
Lewati kasus tepi yang jarang untuk sekarang. Jika sebuah permintaan muncul sekali sebulan dan membutuhkan penanganan khusus, tinggalkan. Tujuannya menemukan pekerjaan umum, membosankan, dan mudah dijelaskan. Itu tempat terbaik untuk mulai, karena permintaan yang berulang lebih mudah distandarisasi, lebih mudah diukur, dan lebih mungkin mendapat manfaat dari proses penerimaan yang jelas.
Mulailah lebih kecil dari yang terasa mengesankan. Kasus penggunaan pertama yang terbaik bukanlah masalah paling berisik di perusahaan. Ini yang sering terjadi, mengikuti beberapa langkah jelas, dan berakhir dengan hasil yang bisa disepakati orang.
Pilihan awal yang kuat biasanya punya jalur persetujuan sederhana. Satu orang meminta sesuatu, satu orang memeriksa, dan satu orang menyelesaikannya. Jika lima tim harus ikut menimbang, Anda belum membangun alur permintaan yang bersih. Anda masih memetakan proses yang berantakan.
Coba deskripsikan hasilnya dalam satu kalimat. Jika kalimat itu terasa samar, permintaan kemungkinan terlalu luas.
"Setujui dan buat inbox bersama baru untuk sebuah tim" adalah contoh awal yang baik. "Bantu kami meningkatkan komunikasi pelanggan" bukanlah. Yang pertama punya akhir yang jelas. Yang kedua bisa berarti sepuluh hal berbeda.
Sebuah tipe permintaan biasanya cukup kecil jika:
Setelah memilih use case, pilih satu metrik untuk dipantau. Buat sederhana. Waktu tunggu adalah titik awal yang kuat karena semua orang memahaminya. Jika masalah besar adalah kesalahan, lacak pekerjaan ulang sebagai gantinya, misalnya seberapa sering tim harus kembali meminta detail yang hilang.
Use case pertama ini tidak perlu membuktikan segalanya. Ia hanya perlu menunjukkan bahwa proses penerimaan yang terstruktur bekerja lebih baik daripada pesan Slack yang tersebar. Jika versi kecilnya berhasil, Anda akan punya data nyata, lebih sedikit opini, dan jalan menuju otomatisasi yang jauh lebih mudah.
Perbaikan pertama sederhana: beri orang satu pintu masuk. Mereka tidak perlu menebak apakah harus mengirim DM, memposting di channel tim, atau menandai siapa pun yang terlihat sedang kosong. Satu form, satu saluran penerimaan, atau satu kotak permintaan sudah cukup. Alatnya kurang penting dibanding konsistensi.
Antrean itu harus menanyakan detail dasar yang sama setiap kali. Jaga singkat, tapi berguna: apa yang dibutuhkan, mengapa dibutuhkan, kapan dibutuhkan, dan siapa yang harus menyetujui jika perlu persetujuan. Saat detail itu hilang, bolak-balik dimulai lagi.
Label status juga membantu, tapi hanya jika sederhana dan jelas. Sebagian besar tim tidak butuh sistem kompleks. Mereka hanya perlu tahu apa yang terjadi:
Gunakan kata yang mudah dipahami sehingga siapa pun bisa melihat antrean sekilas. Jika permintaan duduk terlalu lama, status harus membuat alasannya jelas.
Sama pentingnya, tetapkan satu orang atau satu tim untuk triase antrean. Itu bukan berarti mereka mengerjakan semua pekerjaan. Itu berarti mereka bertanggung jawab pada respons pertama, memeriksa apakah permintaan lengkap, dan meneruskannya ke tempat yang tepat. Tanpa pemilik yang jelas, antrean bersama dengan cepat menjadi tumpukan yang tak ada yang merasa bertanggung jawab.
Uji sederhana: jika karyawan baru bergabung besok, apakah mereka bisa mengirim permintaan tanpa bertanya ke mana harus mengirim atau apa yang harus disertakan? Jika jawabannya tidak, perbaiki itu sebelum Anda mengotomatisasi apa pun. Proses penerimaan yang berantakan hanya jadi proses berantakan yang lebih cepat saat Anda otomatisasi.
Sebelum otomatisasi, jalankan proses secara manual selama seminggu atau dua. Itu menunjukkan seperti apa permintaan nyata, di mana orang terjebak, dan bagian mana yang benar-benar layak dijadikan sistem.
Mulai dengan satu format penerimaan. Bisa berupa form singkat, template yang disematkan, atau pesan Slack standar yang orang salin dan isi. Yang penting konsistensi: nama pemohon, apa yang mereka butuhkan, mengapa, tenggat waktu, dan persetujuan jika perlu.
Lalu periksa permintaan baru pada waktu tetap alih-alih bereaksi sepanjang hari. Misalnya, tinjau antrean pada pukul 10:00 dan 15:00. Itu melindungi fokus dan mengajarkan tim bahwa permintaan bergerak melalui proses, bukan lewat ping acak.
Gunakan jalur yang sama setiap kali:
Saat Anda bekerja, tulis langkah yang sebenarnya Anda lakukan. Buat sederhana. Jika Anda selalu memeriksa persetujuan manajer, menyalin data dari satu alat ke alat lain, atau menanyakan pertanyaan tindak lanjut yang sama, catat itu. Tindakan berulang itulah bahan mentah untuk alur kerja yang lebih baik nanti.
Juga lacak gesekan dengan bahasa sederhana. Catat detail yang hilang, keterlambatan persetujuan, kepemilikan yang tidak jelas, dan pertanyaan yang muncul berulang kali. Setelah satu batch kecil, pola terlihat cepat.
Tanda bahwa Anda siap otomatisasi adalah ketika langkah-langkah berhenti berubah. Jika sebagian besar permintaan mengikuti jalur yang sama, Anda punya sesuatu yang cukup stabil untuk dibangun. Sampai saat itu, kerja manual bukan buang-buang waktu. Ini cara Anda belajar apa yang sebenarnya dibutuhkan sistem.
Jika permintaan yang sama terus muncul, keputusan di baliknya tidak boleh cuma ada di kepala satu orang. Tuliskan cek yang Anda lakukan setiap kali, sesuai urutan yang sebenarnya Anda pakai. Itu mengubah kebiasaan menjadi proses yang bisa diikuti orang lain.
Mulailah dengan pertanyaan yang mengubah hasil. Apakah permintaan lengkap? Apakah orang punya persetujuan? Apakah tenggat berkaitan dengan onboarding, penggajian, atau pekerjaan pelanggan? Jika cek-cek itu terjadi pada sebagian besar permintaan, mereka layak dimasukkan ke aturan.
Cara sederhana mengatur aturan adalah memisahkan:
Ini mencegah proses penerimaan terhenti karena celah kecil. Jika seorang manajer lupa menambahkan satu detail yang membantu tapi sudah menyertakan karyawan, tim, dan level akses, permintaan mungkin masih bisa dilanjutkan.
Selanjutnya, tulis balasan standar untuk hasil yang paling sering Anda lihat. Biasanya itu berarti disetujui, perlu info, saluran salah, duplikat, atau perlu ditinjau. Jaga tiap balasan singkat dan spesifik agar orang tahu langkah berikutnya.
Misalnya, alih-alih menulis respons baru setiap kali, gunakan pesan seperti "Disetujui. Akses akan disiapkan hari ini" atau "Perlu satu detail lagi sebelum kami mulai: persetujuan manajer."
Tidak setiap langkah harus menjadi aturan. Biarkan penilaian manusia tetap ada di tempatnya: pengecualian, akses sensitif, tenggat tidak biasa, atau permintaan yang melanggar kebijakan. Aturan yang baik tidak mengeluarkan orang dari proses. Mereka menghilangkan bolak-balik yang bisa dihindari.
Akses karyawan baru seringkali menjadi produk internal pertama yang tepat. Hampir tiap perusahaan menghadapinya, langkahnya berulang, dan biaya kelupaan terlihat jelas di hari pertama.
Bayangkan versi lama. Seorang manajer mengirim pesan Slack seperti, "Sam mulai Senin. Bisa atur untuknya?" Lalu tiga tim berbeda menanyakan pertanyaan lanjutan, seseorang lupa satu sistem, dan Sam menghabiskan pagi pertama menunggu akses.
Setup yang lebih baik dimulai dengan satu antrean yang jelas. Manajer mengirim permintaan di tempat yang sama setiap kali, dan form menanyakan hanya detail yang penting: peran, tanggal mulai, dan sistem mana yang dibutuhkan.
Perubahan kecil itu melakukan dua hal berguna. Menghapus bolak-balik yang memperlambat semua orang, dan menciptakan catatan bersih tentang apa yang diminta dan kapan.
Untuk peran standar, jalurnya harus membosankan dalam arti baik. Jika permintaan untuk sales rep, desainer, atau agen dukungan, paket persetujuan dan akses yang sama bisa mengikuti langkah yang sama setiap kali. Contohnya:
Di sinilah proses mulai terasa seperti produk, bukan seperti permintaan kasihan. Orang tahu di mana mengirim permintaan, informasi apa yang dibutuhkan, dan berapa lama jalur biasa berlangsung.
Tidak setiap permintaan harus otomatis. Kontraktor sementara, peran lintas-tim, dan akses ke sistem sensitif tetap harus ditangani pemilik manusia. Jika sebagian besar permintaan mengikuti satu jalur dan hanya pengecualian yang butuh penanganan khusus, Anda siap menyempurnakannya lebih jauh.
Otomatisasi paling membantu ketika pekerjaan sudah mengikuti pola jelas. Jika tim masih mengubah langkah, berdebat soal kepemilikan, atau menangani setiap permintaan berbeda, otomatisasi hanya akan mengunci kebingungan.
Aturan sederhana: jalankan proses secara manual sampai orang bisa menjelaskannya dengan cara yang sama setiap kali. Ketika alurnya terasa membosankan, dapat diprediksi, dan mudah diajarkan, biasanya sudah siap untuk otomatisasi.
Hal pertama yang diotomatisasi adalah tugas berisiko rendah yang membuang waktu tapi tidak memerlukan penilaian. Dalam alur permintaan, itu biasanya pengingat, konfirmasi, dan pembaruan status.
Saat seseorang mengirim permintaan, sistem bisa mengirim tanda terima, mencatat perkiraan waktu penyelesaian, dan memposting pembaruan saat permintaan berpindah dari baru ke sedang diproses ke selesai. Itu menghemat pesan tindak lanjut tanpa mengubah cara keputusan dibuat.
Otomatisasi awal yang baik sering meliputi:
Routing sebaiknya menyusul. Jika permintaan masih bolak-balik antar orang, atau tim terus berganti siapa yang menyetujui apa, routing otomatis malah akan menciptakan pekerjaan pembersihan. Tunggu sampai jalur manual stabil dan sebagian besar permintaan mengikuti penyerahan yang sama.
Pertahankan override manual sejak hari pertama. Beberapa permintaan akan selalu berantakan, mendesak, atau tidak biasa. Orang perlu cara sederhana untuk keluar dari aturan, memperbaiki masalah, dan melanjutkan. Jika sistem tidak bisa menangani pengecualian, pengguna akan berhenti mempercayainya.
Sebelum memperluas otomatisasi, tinjau kegagalan. Lihat permintaan yang diarahkan salah, tertunda, atau ditutup dengan jawaban keliru. Kesalahan itu menunjukkan di mana proses masih tidak jelas. Otomatisasi harus mendukung alur kerja yang sudah berjalan, bukan menciptakan satu baru.
Sebagian besar tim tidak macet karena permintaan terlalu kompleks. Mereka macet karena mencoba memperbaiki semuanya sekaligus.
Salah satu kesalahan umum adalah berkembang terlalu cepat. Tim mencampur permintaan akses, permintaan desain, persetujuan pembelian, dan laporan bug ke dalam satu proses. Kedengarannya efisien, tapi tiap tipe permintaan punya aturan, pemilik, dan waktu yang berbeda.
Kesalahan lain adalah menerima permintaan dari mana saja. Jika orang bisa bertanya lewat DM, channel acak, dan grup, seseorang akan selalu harus berburu detail kemudian.
Otomatisasi terlalu dini juga jebakan. Jika persetujuan masih bergantung pada penilaian kasus per kasus, otomatisasi hanya mempercepat keputusan buruk. Dan saat status tetap tidak terlihat, orang bertanya lagi karena mereka tidak bisa tahu apakah permintaan dilihat, disetujui, atau terblokir.
Contoh sederhana menunjukkan bagaimana semuanya runtuh. Bayangkan karyawan baru butuh akses aplikasi, laptop, dan undangan channel Slack. Jika tiap bagian datang lewat pesan berbeda, tim menghabiskan lebih banyak waktu merangkai permintaan daripada mengerjakannya. Jika aturan persetujuan juga samar, langkah otomatis bisa mengirim permintaan ke orang yang salah atau menyetujui sesuatu yang seharusnya ditinjau dulu.
Solusinya biasanya membosankan, dan itu tanda bagus. Mulai dengan satu tipe permintaan. Gunakan satu jalur penerimaan. Minta detail kunci yang sama setiap kali. Buat aturan persetujuan cukup sederhana sehingga anggota tim baru bisa mengikutinya tanpa menebak.
Sama pentingnya, tunjukkan kemajuan dengan jelas. Bahkan status dasar seperti diterima, dalam peninjauan, atau selesai mengurangi pesan tindak lanjut dan membangun kepercayaan.
Jika sebuah proses masih sering membutuhkan pengecualian, ia belum siap untuk otomatisasi berat. Rapikan aturannya dulu. Lalu otomatisasi bagian yang sudah bekerja sama setiap kali.
Sebelum menambah tim, tipe permintaan, atau otomatisasi besar, berhenti dan uji dasar-dasarnya. Proses yang bekerja untuk orang yang membuatnya bisa saja membingungkan orang lain.
Periksa beberapa hal sederhana:
Poin pertama lebih penting daripada yang banyak tim perkirakan. Jika karyawan baru atau manajer sibuk tidak bisa mengikuti proses sendiri, sistem belum siap berkembang. Alurnya harus terasa jelas, bahkan bagi orang yang melihatnya pertama kali.
Jaga penerimaan tetap singkat. Orang cenderung menggunakan proses permintaan ketika form meminta detail yang jelas dan berguna, bukan lima pertanyaan tambahan yang jarang penting.
Kepemilikan adalah tempat banyak sistem rusak. "Dalam peninjauan" berarti sedikit kecuali satu orang atau satu tim bertanggung jawab memajukan itu. Jika tidak ada yang memiliki sebuah status, permintaan akan tertahan di sana.
Pengecualian juga butuh perhatian. Akan selalu ada kasus aneh, permintaan mendesak, atau orang yang kurang konteks. Beri kasus-kasus itu jalur cadangan supaya tidak memulai ulang seluruh percakapan di Slack.
Dan lindungi langkah yang masih perlu keputusan manusia. Memaksakan otomatisasi terlalu awal biasanya menciptakan pekerjaan ulang, bukan kecepatan.
Setelah alur bekerja secara manual, jangan lompat langsung ke sistem besar. Pertahankan satu antrean dan satu permintaan yang berulang, dan haluskan jalur itu dulu. Itu cara paling aman mengubah pekerjaan Slack berulang menjadi sesuatu yang dapat diandalkan.
Gunakan permintaan yang sudah masuk sebagai panduan. Jika orang terus meninggalkan detail yang sama, tambahkan field untuk itu. Jika peninjau terus membuat pilihan yang sama, ubah pilihan itu menjadi aturan sederhana. Lalu lintas nyata menunjukkan apa yang layak masuk proses dan apa yang cuma kebisingan.
Versi berikutnya yang baik biasanya hanya menambahkan beberapa hal:
Tambahkan otomatisasi sedikit demi sedikit. Jika permintaan akses selalu butuh persetujuan manajer dulu, otomatisasikan langkah itu. Jika beberapa permintaan masih perlu penilaian, biarkan manual. Tujuannya bukan mengotomatisasi segalanya, tapi menghilangkan langkah berulang dan menjaga pengecualian terlihat.
Jika alur terus tumbuh, mungkin sudah pantas dibuat aplikasi internal sendiri. Tools seperti Koder.ai bisa membantu di sini. Tim bisa memakai chat untuk membuat aplikasi web, server, atau mobile sederhana untuk proses itu, lalu terus menyempurnakannya saat pola permintaan baru muncul alih-alih menumpuk lebih banyak pekerjaan di Slack.
Produk internal terbaik biasanya mulai kecil: satu antrean, satu tipe permintaan, penggunaan nyata, lalu perluasan hati-hati. Itu terasa lebih lambat selama seminggu, tapi jauh lebih cepat selama setahun ke depan.
Karena chat menyembunyikan pekerjaan. Permintaan tersebar di DM, channel, dan thread samping sehingga kepemilikan, status, dan prioritas tidak jelas. Satu antrean membuat permintaan lebih mudah dilacak, diselesaikan, dan diukur.
Pilih sesuatu yang sering terjadi, sederhana, dan dapat diulang. Contoh yang baik memiliki awal jelas, akhir jelas, dan jalur persetujuan yang kecil, misalnya akses karyawan baru atau pengaturan inbox bersama.
Tinjau pesan nyata dari dua hingga empat minggu terakhir dan kelompokkan berdasarkan tipe. Fokus pada permintaan umum yang mudah dideskripsikan dan abaikan kasus satu kali yang jarang terjadi untuk saat ini.
Ringkas tetapi lengkap. Tanyakan apa yang dibutuhkan orang, mengapa mereka membutuhkannya, kapan dibutuhkan, dan siapa yang menyetujuinya jika perlu persetujuan. Tujuannya mengumpulkan detail yang menghentikan bolak-balik tambahan.
Tidak perlu. Anda bisa mulai dengan satu form, satu saluran penerimaan, atau satu kotak masuk bersama. Yang penting semua orang memakai titik masuk yang sama dan format permintaan dasar yang seragam.
Jalankan secara manual selama satu atau dua minggu pertama. Itu memberi contoh nyata, menunjukkan di mana permintaan terhambat, dan membantu melihat langkah mana yang konsisten tiap kali.
Mulailah dengan bagian yang paling aman dan berisiko rendah. Otomatisasi awal yang baik meliputi konfirmasi penerimaan, pengingat, dan pembaruan status yang jelas. Biarkan persetujuan dan routing tetap manual sampai alurnya stabil.
Segala sesuatu yang masih memerlukan penilaian manusia harus tetap manual. Biasanya ini termasuk akses sensitif, tenggat tidak biasa, pengecualian kebijakan, dan permintaan yang tidak masuk jalur normal.
Anda siap saat proses terasa membosankan dalam arti baik: seorang pemohon baru bisa mengirim tanpa bantuan, tiap status punya pemilik yang jelas, dan sebagian besar permintaan mengikuti jalur yang sama.
Saat volume permintaan terus meningkat dan aturan sudah stabil, aplikasi internal khusus bisa menghemat waktu. Koder.ai dapat membantu tim membangun aplikasi web, server, atau mobile dari chat, lalu menyempurnakannya seiring alur kerja menjadi lebih jelas.
