Otomatisasi RevOps: Apa yang Diotomatisasi dan Apa yang Tetap Perlu Sentuhan Manusia

Otomatisasi RevOps berhasil ketika prosesnya sudah jelas lebih dulu.

Jika aturan kualifikasi masih samar, otomatisasi hanya akan merutekan kebingungan lebih cepat. Jika field serah terima kurang terdefinisi, otomatisasi akan mengirim konteks yang tidak lengkap lebih cepat. Jika tahap forecast bersifat subjektif, otomatisasi membuat keyakinan yang buruk terlihat presisi.

Panduan Gartner tentang mengurangi kompleksitas revenue enablement relevan karena otomatisasi seharusnya mengurangi friksi, bukan menambah lebih banyak sistem yang harus dikelola tim. Riset model operasi RevOps dari Forrester juga menegaskan bahwa kepemilikan dan proses harus ada sebelum otomatisasi diskalakan.

Fakta operasional utama

  • Otomatisasikan pekerjaan berulang hanya setelah aturannya jelas, datanya dipercaya, dan jalur pengecualiannya terdefinisi.
  • Mulai dengan alur kerja yang sudah memiliki kebocoran terukur: proses lead-to-opportunity, lead routing, eskalasi SLA, serah terima closed-won, kebersihan forecast, dan pengingat perpanjangan.
  • Otomatisasi harus mendukung model SLA full-funnel, bukan menggantikan kepemilikan. Peringatan dan tugas tetap membutuhkan pemilik yang bertanggung jawab.
  • Setiap otomatisasi harus merujuk kembali ke kamus data pendapatan dan aturan sumber kebenaran. Jika definisi field tidak jelas, otomatisasi akan mewarisi ambiguitas itu.
  • Otomatisasi berdampak tinggi membutuhkan jalur persetujuan manusia, terutama ketika mengubah kepemilikan, komunikasi pelanggan, kategori forecast, alur kerja harga, atau perlakuan akun strategis.

Kandidat otomatisasi yang baik

  • Lead routing
  • Pengingat dan eskalasi SLA
  • Deteksi duplikat
  • Prompt field wajib
  • Pembuatan tugas serah terima closed-won
  • Peringatan risiko perpanjangan
  • Peringatan kebersihan forecast
  • Refresh dashboard

Tetap pertahankan penilaian manusia untuk

  • Keputusan strategi
  • Penilaian deal yang kompleks
  • Panggilan hubungan pelanggan
  • Pengecualian diskon
  • Perubahan ICP
  • Override forecast

Gunakan AI dalam Revenue Operations untuk lapisan berikutnya.

Prinsip otomatisasi

Otomatisasikan hanya setelah tiga hal jelas:

  • Aturannya disepakati.
  • Datanya dapat diandalkan.
  • Jalur pengecualiannya terdefinisi.

Jika salah satu hal ini hilang, otomatisasi mungkin menciptakan lebih banyak pekerjaan ulang. Lead yang dirutekan oleh aturan wilayah yang buruk tetap membutuhkan penugasan ulang manual. Tugas serah terima yang dibuat dari data tidak lengkap tetap membutuhkan seseorang untuk mengejar konteksnya. Peringatan forecast berdasarkan definisi tahap yang lemah bisa menciptakan kebisingan.

Otomatisasi seharusnya menghilangkan pekerjaan berulang, meningkatkan waktu respons, dan membuat aturan operasional konsisten. Otomatisasi tidak seharusnya menyembunyikan keputusan yang tidak jelas.

Matriks keputusan otomatisasi

Sebelum membangun otomatisasi, nilai alur kerja berdasarkan empat pertanyaan. Ini juga memberi masukan pada keputusan build vs buy untuk RevOps yang lebih luas, karena beberapa alur kerja lebih baik dilayani oleh alat yang dibeli daripada dibangun sendiri.

Matriks Keputusan Otomatisasi Pendapatan digambarkan dengan bingkai penyortiran empat kuadran besar yang menempatkan satu token alur kerja berulang di sel siap-otomatisasi berwarna koral, tanpa label teks

Turn this article into takeaways for your work.

Each assistant summarizes the article only for you and suggests best practices for your work.

Pertanyaan Sinyal baik Sinyal buruk
Apakah aturannya jelas? Orang bisa mendeskripsikan pemicu dan tindakan yang diharapkan dalam satu kalimat Tim tidak sepakat tentang apa yang seharusnya terjadi
Apakah datanya dapat diandalkan? Field wajib lengkap dan definisi stabil Field kunci hilang, basi, atau subjektif
Apakah jalur pengecualian diketahui? Ada pemilik bernama untuk kasus tepi Pengecualian pergi ke siapa pun yang menyadarinya lebih dulu
Apakah nilainya terukur? Waktu yang dihemat, peningkatan SLA, pengurangan error, atau pengurangan risiko bisa dilacak Manfaatnya samar atau hanya berdasarkan preferensi

Prioritaskan alur kerja dengan aturan yang jelas, data yang dapat diandalkan, pengecualian yang diketahui, dan nilai yang terukur. Tunda alur kerja dengan kriteria yang tidak jelas, keputusan yang sensitif terhadap hubungan, data lemah, atau downside tinggi dari tindakan yang salah.

Backlog otomatisasi yang berguna harus memisahkan tiga kelompok:

Kelompok Yang harus dilakukan
Siap diotomatisasi Bangun, uji, dan pantau
Butuh desain proses Definisikan aturan, pemilik, field, dan jalur pengecualian terlebih dahulu
Tetap manusia Gunakan template, panduan, atau pengingat alih-alih tindakan otomatis

Ini mencegah otomatisasi menjadi respons terhadap frustrasi. Alur kerja yang menyakitkan tidak selalu siap untuk otomatisasi. Terkadang yang dibutuhkan adalah definisi, field yang lebih baik, sumber kebenaran yang lebih bersih, atau perubahan perilaku manajer.

Otomatisasi berdasarkan alur kerja

Alur kerja Otomatisasi yang baik Penilaian manusia
Lead routing Mencocokkan berdasarkan wilayah, segmen, pemilik akun, kapasitas Penanganan pengecualian untuk akun strategis
Manajemen SLA Pengingat, eskalasi, laporan SLA terlewat Memutuskan mengapa SLA gagal
Kebersihan CRM Peringatan duplikat, prompt field basi Keputusan merge untuk akun kompleks
Serah terima Pembuatan tugas, pemeriksaan konteks wajib Memutuskan kesiapan untuk deal yang tidak biasa
Kebersihan forecast Peringatan field hilang, peringatan commit basi Override kategori forecast
Perpanjangan Peringatan risiko, pembuatan tugas perpanjangan Strategi penyelamatan komersial

Pembagian ini membuat otomatisasi tetap praktis dan menjaga manusia tetap pada keputusan berdampak tinggi.

Mulai dengan alur kerja bervolume tinggi

Kandidat awal yang baik:

  • Lead routing
  • Serah terima pemesanan rapat
  • Pengingat SLA
  • Deteksi duplikat
  • Prompt field wajib opportunity
  • Pembuatan serah terima closed-won
  • Pengingat tanggal perpanjangan
  • Peringatan kualitas data forecast

Alur kerja ini biasanya memiliki aturan yang jelas dan hasil yang terlihat. Alur kerja ini juga menciptakan fondasi untuk otomatisasi yang lebih canggih nantinya.

Hindari mengotomatisasi proses yang tidak jelas

Jangan otomatisasikan:

  • Kualifikasi lead yang samar
  • Kesiapan serah terima yang tidak terdefinisi
  • Pergerakan tahap yang subjektif
  • Persetujuan diskon kompleks tanpa kebijakan yang jelas
  • Override forecast
  • Komunikasi pelanggan dengan risiko hubungan tinggi
  • Perubahan data tanpa jejak audit

Otomatisasi harus mengikuti kejelasan proses. Otomatisasi tidak seharusnya menciptakannya.

Penanganan pengecualian

Setiap otomatisasi membutuhkan jalur pengecualian.

Pertanyaan:

  • Apa yang terjadi ketika pencocokan akun gagal?
  • Siapa yang menyelesaikan konflik duplikat?
  • Siapa yang menyetujui pengecualian routing?
  • Apa yang terjadi ketika data wajib hilang?
  • Siapa yang meninjau sinkronisasi yang gagal?
  • Bagaimana pengguna melakukan override otomatisasi?
  • Di mana override dicatat?

Penanganan pengecualian adalah tempat banyak otomatisasi gagal. Jalur normal berjalan baik, tetapi kasus tepi menciptakan pembersihan manual dan kehilangan kepercayaan.

Tata kelola otomatisasi

RevOps harus memelihara registri otomatisasi.

Sertakan:

  • Nama otomatisasi
  • Tujuan bisnis
  • Pemicu
  • Pemilik aturan
  • Pemilik sistem
  • Field data yang digunakan
  • Dampak hilir
  • Jalur pengecualian
  • Tanggal terakhir ditinjau
  • Pemilik kegagalan

Registri ini mencegah logika alur kerja yang tersembunyi. Registri ini juga membantu anggota tim RevOps baru memahami mengapa sistem berperilaku seperti itu.

Pengujian otomatisasi

Sebelum peluncuran:

  • Uji kasus umum.
  • Uji kasus tepi.
  • Uji data buruk.
  • Uji masalah izin.
  • Uji rollback.
  • Uji kualitas notifikasi.
  • Uji dampak pelaporan.

Jalankan otomatisasi dalam mode shadow jika memungkinkan. Misalnya, tunjukkan siapa yang akan menerima lead yang dirutekan sebelum merutekannya secara otomatis. Bandingkan hasil yang diharapkan dengan hasil aktual, lalu luncurkan ketika aturannya sudah dipercaya.

Otomatisasi dan adopsi

Otomatisasi harus meningkatkan pengalaman pengguna.

Jika rep menerima terlalu banyak peringatan, mereka akan mengabaikan semuanya. Jika manajer mendapat laporan yang bising, mereka berhenti memeriksanya. Jika pengguna tidak memahami mengapa otomatisasi terjadi, mereka mungkin bekerja mengelilingi sistem.

Otomatisasi yang baik menjelaskan dirinya sendiri:

  • Mengapa catatan ini dirutekan
  • Mengapa tugas ini dibuat
  • Mengapa field ini wajib
  • Mengapa peringatan ini muncul
  • Tindakan apa yang diharapkan

Otomatisasi yang jelas membangun kepercayaan.

Mengukur nilai otomatisasi

Ukur apakah otomatisasi meningkatkan alur kerja.

Metrik yang berguna:

  • Waktu respons
  • Penyelesaian SLA
  • Jumlah penugasan ulang manual
  • Tingkat duplikat
  • Kelengkapan serah terima
  • Masalah kualitas data forecast
  • Penyelesaian tugas perpanjangan
  • Tingkat override pengguna
  • Tingkat error
  • Waktu pemeliharaan admin

Jika otomatisasi menghemat waktu rep tetapi menciptakan pembersihan admin, nilainya mungkin lebih rendah dari yang diharapkan.

Otomatisasi dan AI

AI bisa memperluas otomatisasi, tetapi juga meningkatkan kebutuhan tata kelola.

Gunakan AI secara hati-hati untuk:

  • Saran pembersihan data
  • Ringkasan riset akun
  • Sinyal risiko deal
  • Ringkasan risiko perpanjangan
  • Saran tindakan berikutnya
  • Deteksi anomali forecast

Pertahankan persetujuan untuk tindakan berdampak tinggi seperti mengubah kategori forecast, mengirim komunikasi pelanggan yang sensitif, mengubah harga, atau menugaskan ulang akun strategis.

Desain human-in-the-loop

Tinjauan manusia harus dirancang ke dalam otomatisasi berdampak tinggi sejak awal.

Otomatisasi Pendapatan Human-in-the-Loop digambarkan dengan estafet lebar di mana gigi otomatisasi menyerahkan tongkat pengecualian ke simbol tangan penilaian manusia sebelum alur kerja berlanjut

Gunakan persetujuan manusia ketika otomatisasi:

  • Mengirim atau mengubah komunikasi yang dihadapi pelanggan.
  • Mengubah kategori forecast atau metrik yang dihadapi dewan.
  • Menugaskan ulang akun strategis atau opportunity aktif.
  • Memicu alur kerja harga, diskon, atau kontrak.
  • Menggabungkan catatan di mana riwayat akun mungkin terpengaruh.
  • Menandai pelanggan untuk risiko churn dalam pelaporan eksekutif.
  • Membuat pipeline ekspansi dari sinyal pelanggan.

Human-in-the-loop tidak berarti lambat. Ini berarti otomatisasi menyiapkan keputusan dan pemiliknya menyetujui tindakan tersebut. Misalnya, alur kerja perpanjangan berbantuan AI bisa merangkum penurunan penggunaan, beban support, kehilangan sponsor, dan waktu kontrak. Manajer CSM tetap memutuskan rencana penyelamatan dan eskalasi komersial. Peringatan forecast bisa menandai deal commit dengan bukti lemah. Manajer sales tetap memutuskan apakah deal tersebut tetap commit.

Pengalaman persetujuan harus spesifik:

Output otomatisasi Keputusan manusia
Saran merge duplikat Setujui merge, tolak, atau minta tinjauan
Saran rute untuk lead strategis Terima pemilik, override, atau eskalasi
Peringatan risiko forecast Konfirmasi risiko, perbarui kategori, atau abaikan dengan alasan
Ringkasan risiko perpanjangan Tugaskan pemilik penyelamatan, perbarui risiko, atau tandai tanpa tindakan
Sinyal ekspansi Buat opportunity, tugaskan tindak lanjut, atau tolak sinyal

Jika langkah manusia tidak jelas, pengguna akan mengabaikannya. Jika otomatisasi menjelaskan mengapa ia terpicu dan keputusan apa yang dibutuhkan, manusia bisa bergerak lebih cepat tanpa kehilangan penilaian.

Kesalahan umum

Mengotomatisasi sebelum kesepakatan proses. Alur kerja bergerak lebih cepat tetapi tetap salah.

Tidak ada jalur pengecualian. Kasus tepi menjadi kekacauan manual.

Terlalu banyak peringatan. Pengguna mengabaikan sistem.

Tidak ada jejak audit. Para pemimpin tidak bisa menjelaskan apa yang berubah.

Tidak ada pemilik. Otomatisasi rusak setelah perubahan proses.

Tidak ada irama tinjauan. Aturan lama terus berjalan setelah bisnis berubah.

Daftar periksa kesiapan

Sebelum meluncurkan otomatisasi:

  • Aturan sudah terdokumentasi.
  • Sumber data dipercaya.
  • Pemilik sudah ditunjuk.
  • Jalur pengecualian terdefinisi.
  • Kasus uji lengkap.
  • Jejak audit ada.
  • Pengguna memahami tindakan yang diharapkan.
  • Dampak pelaporan diketahui.
  • Irama tinjauan terjadwal.

Apa yang harus dibuktikan daftar periksa ini

Otomatisasi RevOps harus membuat model operasi yang disepakati lebih cepat dan lebih konsisten. Jika aturannya tidak jelas, datanya lemah, atau jalur pengecualiannya hilang, perbaiki itu dulu.

Model kematangan otomatisasi

Tim biasanya matang melalui beberapa tahap.

Tahap Perilaku
Manual Pekerjaan terjadi melalui pengingat, spreadsheet, dan tindak lanjut individu
Terpicu Aturan sederhana membuat tugas, peringatan, atau penugasan
Terkelola Otomatisasi memiliki pemilik, pengujian, log audit, dan irama tinjauan
Lintas fungsi Alur kerja menghubungkan sales, marketing, CS, finance, dan sistem
Berbantuan AI menyarankan tindakan sementara manusia menyetujui perubahan berdampak tinggi

Tujuannya bukan mencapai tahap paling canggih di mana-mana. Tujuannya adalah menggunakan tingkat otomatisasi yang tepat untuk setiap alur kerja.

Contoh lead routing

Lead routing adalah otomatisasi pertama yang umum, tetapi jarang hanya berupa aturan teknis.

Routing mungkin bergantung pada:

  • Wilayah
  • Kepemilikan akun bernama
  • Segmen
  • Minat produk
  • Keterlibatan partner
  • Kapasitas rep
  • Opportunity terbuka yang sudah ada
  • Status pelanggan
  • Sumber

Sebelum otomatisasi, RevOps harus mendokumentasikan urutan prioritas. Misalnya, kepemilikan akun bernama mungkin mengesampingkan geografi. Status pelanggan mungkin mengesampingkan sumber lead. Akun strategis mungkin membutuhkan tinjauan manual.

Setelah peluncuran, lacak tingkat penugasan ulang. Tingkat penugasan ulang yang tinggi berarti logika routing atau data sumber perlu ditinjau.

Contoh otomatisasi serah terima

Otomatisasi serah terima closed-won bisa membuat tugas untuk onboarding, CS, billing, dan implementasi.

Tetapi serah terima hanya berhasil jika konteks wajib ada:

  • Tanggal mulai kontrak
  • Produk yang dibeli
  • Use case
  • Kriteria keberhasilan
  • Catatan implementasi
  • Kontak billing
  • Sponsor eksekutif
  • Risiko atau janji yang dibuat selama sales

Otomatisasi harus memeriksa kesiapan sebelum membuat pekerjaan hilir. Mengirim serah terima yang tidak lengkap lebih cepat tidak membantu pelanggan.

Contoh otomatisasi kebersihan forecast

Peringatan kebersihan forecast bisa menandai:

  • Deal commit tanpa langkah berikutnya
  • Tanggal closing di masa lalu
  • Deal tahap akhir dengan aktivitas lama
  • Deal skenario terbaik dengan bukti hilang
  • Perubahan jumlah besar
  • Deal yang didorong berkali-kali

Peringatan ini harus disampaikan ke manajer sebelum rapat forecast. Tujuannya adalah meningkatkan inspeksi, bukan mempermalukan rep.

Contoh otomatisasi perpanjangan

Alur kerja perpanjangan bisa membuat pengingat berdasarkan tanggal kontrak, status kesehatan, sinyal penggunaan, dan kepemilikan akun.

Otomatisasi yang berguna:

  • Pembuatan tugas perpanjangan
  • Peringatan risiko ketika penggunaan turun
  • Pengingat sponsor eksekutif
  • Tugas rencana penyelamatan untuk akun merah
  • Notifikasi finance untuk risiko perpanjangan besar
  • Prompt ekspansi untuk akun dengan adopsi tinggi

Penilaian manusia tetap penting karena risiko perpanjangan sering mencakup konteks hubungan.

Desain peringatan

Peringatan harus langka dan dapat ditindaklanjuti.

Peringatan yang baik memiliki:

  • Alasan
  • Pemilik
  • Tindakan yang diharapkan
  • Tanggal jatuh tempo
  • Tautan ke catatan
  • Aturan penekanan
  • Jalur eskalasi

Peringatan buruk mengatakan "risiko deal terdeteksi" tanpa menjelaskan mengapa. Peringatan baik mengatakan "deal commit tidak memiliki rapat berikutnya dan tanggal closing bergeser dua kali; manajer harus memeriksa bukti waktu sebelum rapat forecast."

Pemeliharaan

Otomatisasi membutuhkan pemeliharaan karena aturan bisnis berubah.

Tinjau otomatisasi ketika:

  • Wilayah berubah
  • Segmen berubah
  • Produk baru diluncurkan
  • Kategori forecast berubah
  • Field CRM berubah
  • Sistem dimigrasikan
  • Tim direorganisasi
  • Aturan SLA berubah
  • Alur kerja AI ditambahkan

Otomatisasi lama adalah sumber umum dari perilaku sistem yang aneh. Irama tinjauan mencegah logika tersembunyi menjadi utang operasional.

Manajemen perubahan

Pengguna harus tahu apa yang dilakukan otomatisasi dan mengapa.

Sebelum peluncuran:

  • Jelaskan alur kerja.
  • Tunjukkan contoh.
  • Jelaskan penanganan pengecualian.
  • Latih manajer.
  • Definisikan jalur dukungan.
  • Amati perilaku pengguna setelah peluncuran.

Jika pengguna bekerja mengelilingi otomatisasi, periksa alasannya. Mereka mungkin menolak perubahan, tetapi mereka juga mungkin mengungkap aturan yang buruk.

Backlog otomatisasi

Pelihara backlog dengan:

  • Alur kerja
  • Titik masalah
  • Pemilik
  • Volume
  • Risiko
  • Kesiapan data
  • Nilai yang diharapkan
  • Pemilik pemeliharaan
  • Prioritas

Ini menjaga keputusan otomatisasi tetap disiplin. Permintaan paling keras tidak seharusnya secara otomatis menjadi build berikutnya.

Seperti apa yang baik itu

Otomatisasi yang baik mengurangi pengejaran manual, meningkatkan waktu respons, dan membuat kepemilikan lebih jelas. Manajer memercayai peringatan karena spesifik. Pengguna memahami mengapa tugas muncul. RevOps bisa mengaudit perubahan. Pengecualian memiliki pemilik. Aturan lama ditinjau sebelum membusuk.

Itulah standarnya.

Contoh otomatisasi berdasarkan tim

Contoh marketing:

  • Membuat tugas tindak lanjut kampanye untuk respons yang memenuhi syarat.
  • Memberi peringatan ketika data sumber hilang.
  • Menandai pengiriman formulir dari opportunity terbuka yang sudah ada.
  • Memberi tahu pemilik ketika akun yang sangat sesuai terlibat.

Contoh sales:

  • Merutekan lead berdasarkan kepemilikan akun dan kapasitas.
  • Membuat pengingat untuk langkah berikutnya yang basi.
  • Menandai deal commit yang kehilangan bukti.
  • Mengeskalasi SLA respons yang terlewat.

Contoh customer success:

  • Membuat tugas perpanjangan berdasarkan tanggal kontrak.
  • Memberi peringatan atas penurunan penggunaan untuk akun kunci.
  • Memberi tahu pemilik akun tentang sinyal ekspansi.
  • Membuat tugas serah terima setelah closed-won.

Contoh finance:

  • Memberi tahu finance tentang deal closed-won besar.
  • Menandai informasi billing yang hilang.
  • Mengirim ringkasan risiko perpanjangan.
  • Melacak status kontrak atau order form.

Otomatisasi ini berguna karena menghubungkan aturan operasional dengan tindakan yang jelas.

Desain otomatisasi berbasis risiko

Klasifikasikan otomatisasi berdasarkan risiko.

Otomatisasi berisiko rendah membuat pengingat atau saran. Otomatisasi berisiko sedang menugaskan kepemilikan, memperbarui field non-kritis, atau memicu tugas internal. Otomatisasi berisiko tinggi memengaruhi pelanggan, forecast, harga, kepemilikan akun strategis, atau pengakuan pendapatan.

Gunakan lebih banyak persetujuan dan pencatatan seiring meningkatnya risiko.

Risiko Contoh Kontrol
Rendah Pengingat langkah berikutnya yang basi Pemilik dasar dan penekanan
Sedang Lead routing Jalur pengecualian dan log audit
Tinggi Perubahan kategori forecast Persetujuan manusia wajib

Ini menjaga kecepatan otomatisasi agar tidak menciptakan dampak bisnis yang tidak terkendali.

Hubungkan model risiko ini dengan data pendapatan sumber kebenaran. Semakin tinggi risikonya, semakin penting untuk mengetahui sistem mana yang menang, definisi field mana yang berlaku, dan di mana jejak audit berada.

Pemantauan kegagalan

Pantau mode kegagalan:

  • Otomatisasi tidak berjalan.
  • Otomatisasi berjalan dua kali.
  • Otomatisasi menggunakan data basi.
  • Otomatisasi membuat pemilik yang salah.
  • Otomatisasi mengirim terlalu banyak peringatan.
  • Otomatisasi rusak setelah perubahan field.
  • Otomatisasi menciptakan efek samping pelaporan.

Setiap otomatisasi penting harus memiliki pemilik yang bisa melihat kegagalan. Kegagalan tersembunyi mengikis kepercayaan dengan cepat.

Standar dokumentasi

Dokumentasikan setiap otomatisasi dalam bahasa yang sederhana:

  • Kapan dimulai
  • Aturan apa yang digunakan
  • Catatan apa yang diubah
  • Siapa yang menerima output
  • Tindakan pengguna apa yang diharapkan
  • Cara melakukan override
  • Siapa yang mendukungnya

Dokumentasi mencegah sistem menjadi cerita rakyat.

Urutan peluncuran

Urutan peluncuran yang sederhana:

  1. Definisikan aturan.
  2. Konfirmasi sumber data.
  3. Uji kasus normal.
  4. Uji kasus tepi.
  5. Jalankan dalam mode shadow.
  6. Latih pengguna.
  7. Luncurkan dengan pemantauan.
  8. Tinjau setelah dua minggu.

Urutan ini lebih lambat daripada sekadar menyalakan sakelar, tetapi mencegah pembersihan yang bisa dihindari.

Tinjauan kesehatan otomatisasi

Tinjau kesehatan otomatisasi setiap bulan.

Tanyakan peringatan mana yang diabaikan, tugas mana yang ditutup, catatan mana yang membutuhkan koreksi manual, aturan mana yang menciptakan pengecualian, dan alur kerja mana yang menghemat waktu. Pertahankan otomatisasi yang berguna. Hapus otomatisasi yang bising. Sesuaikan aturan ketika bisnis berubah.

Otomatisasi minimum yang layak

Mulai dengan satu alur kerja, satu pemilik, satu pemicu, satu tindakan yang diharapkan, satu jalur pengecualian, dan satu metrik keberhasilan. Itu sudah cukup untuk belajar. Memperluas sebelum alur kerja pertama dipercaya biasanya menciptakan kebisingan.

Jaga otomatisasi pertama tetap mudah dijelaskan, mudah dipantau, dan mudah dibalikkan. Kepercayaan tumbuh dari eksekusi yang bersih.

Pertanyaan tinjauan otomatisasi

Gunakan pertanyaan-pertanyaan ini dalam tinjauan kesehatan otomatisasi bulanan:

  • Otomatisasi mana yang menghemat waktu atau mengurangi risiko?
  • Peringatan mana yang diabaikan?
  • Tugas mana yang dibuat tetapi tidak diselesaikan?
  • Alur kerja mana yang menghasilkan paling banyak override?
  • Kegagalan mana yang berasal dari data buruk?
  • Kegagalan mana yang berasal dari kepemilikan yang tidak jelas?
  • Otomatisasi mana yang harus dipensiunkan?
  • Pekerjaan manual mana yang sekarang siap untuk otomatisasi?

Tinjauan ini harus mengarah pada tindakan. Hapus peringatan yang bising. Perbarui aturan yang basi. Tambahkan pemilik di mana pengecualian macet. Pensiunkan otomatisasi yang tidak lagi cocok dengan motion bisnis. Jangan biarkan logika alur kerja lama terus berjalan hanya karena tidak ada yang ingat siapa yang membangunnya.

Otomatisasi yang baik seharusnya membuat sistem pendapatan lebih tenang, bukan lebih bising. Lebih sedikit pengejaran manual, lebih sedikit serah terima tersembunyi, lebih sedikit catatan basi, lebih sedikit kegagalan mengejutkan. Jika otomatisasi menambah lebih banyak peringatan daripada keputusan, itu tidak melakukan tugasnya.

Skor prioritas

Ketika backlog bertambah, nilai kandidat otomatisasi sebelum membangun.

Gunakan model sederhana:

Faktor Skor tinggi berarti
Volume Alur kerja terjadi cukup sering untuk penting
Risiko Kegagalan menciptakan dampak pendapatan, pelanggan, forecast, atau kepatuhan
Kejelasan aturan Pemicu dan tindakan yang diharapkan disepakati
Kesiapan data Field cukup lengkap untuk dipercaya
Kejelasan pengecualian Kasus tepi memiliki pemilik
Dampak pengguna Otomatisasi membuat pekerjaan lebih mudah, bukan lebih bising
Biaya pemeliharaan Aturan bisa didukung setelah peluncuran

Prioritaskan alur kerja bervolume tinggi, berisiko tinggi, dan beraturan jelas terlebih dahulu. Tunda alur kerja berisiko tinggi ketika kesiapan data lemah. Hindari otomatisasi bervolume rendah kecuali risikonya material, seperti perpanjangan besar, akun strategis, atau alur kerja yang berdampak pada finance.

Model penilaian ini juga membantu RevOps menjelaskan trade-off. Seorang pemimpin mungkin menginginkan otomatisasi karena alur kerja saat ini menjengkelkan. Pemimpin lain mungkin membutuhkan otomatisasi karena serah terima yang terlewat memengaruhi pendapatan. Skor ini memberi tim cara bersama untuk memilih.

Yang harus dipensiunkan

Tata kelola otomatisasi harus mencakup penghapusan.

Pensiunkan atau desain ulang otomatisasi ketika:

  • Pengguna mengabaikan peringatan sebagian besar waktu.
  • Tingkat override tinggi.
  • Aturan bisnis berubah.
  • Definisi field berubah.
  • Otomatisasi menciptakan pekerjaan duplikat.
  • Laporan atau alur kerja yang didukungnya tidak lagi digunakan.
  • Otomatisasi menciptakan lebih banyak pengecualian daripada tindakan yang selesai.

Otomatisasi lama lebih sulit dilihat daripada laporan lama. Dashboard yang basi mungkin diabaikan, tetapi alur kerja yang basi bisa terus mengubah catatan, menugaskan pemilik, dan membuat tugas. RevOps harus memperlakukan penghapusan sebagai bagian dari siklus hidup otomatisasi, bukan pekerjaan pembersihan untuk nanti.

Standar praktisnya sederhana: setiap otomatisasi harus tetap memiliki pemilik yang jelas, aturan yang aktual, output yang terlihat, dan alasan untuk ada. Jika tim tidak bisa menjelaskan empat hal ini, hentikan alur kerja sampai seseorang bisa.

Paket persetujuan otomatisasi

Sebelum mengotomatisasi alur kerja pendapatan, RevOps harus mendokumentasikan:

Paket Persetujuan Otomatisasi Pendapatan digambarkan dengan kotak kontrol otomatisasi terbuka dengan enam komponen berbeda dan satu sakelar rollback darurat berwarna koral

Item Yang harus didefinisikan
Alur kerja Langkah manual mana yang berubah
Pemicu Event apa yang memulai otomatisasi
Aturan Kondisi apa yang harus benar
Pemilik Siapa yang memiliki hasilnya
Pengecualian Apa yang terjadi ketika aturan gagal
Jejak audit Apa yang dicatat
Rollback Bagaimana alur kerja dijeda atau dibalikkan

Ini mencegah otomatisasi menyembunyikan kebingungan proses. Jika pemicu, aturan, pemilik, dan pengecualian tidak jelas, alur kerja belum siap untuk diotomatisasi.

Pertanyaan yang Sering Diajukan tentang Otomatisasi RevOps

Apa yang harus diotomatisasi RevOps terlebih dahulu?

Mulai dengan alur kerja bervolume tinggi dan beraturan jelas seperti lead routing, eskalasi SLA, dan pembuatan tugas serah terima.

Apa yang tidak boleh diotomatisasi?

Apa pun yang aturannya belum disepakati, datanya lemah, atau konsekuensi dari tindakan yang salah tinggi.

Pelajari lebih lanjut

About the author

Tracy N

Tracy N

Principal Solution Architect

Tracy N is Principal Solution Architect at Rework, focused on GTM engineering and revenue operations. Tracy writes about how marketing, sales, customer success, and product hand work to each other, how revenue operations keeps those handoffs measurable, and the AI foundations a team needs before automating its go-to-market motion.