Bahasa Melayu

RevOps dan AI: Mengapa Penjajaran Data Perlu Dilakukan Sebelum Pelaksanaan Alat

Pasukan RevOps menyemak penjajaran data AI dan dashboard kualiti data Pipeline

Janji AI dalam operasi pendapatan adalah spesifik: forecast yang lebih baik, semakan Pipeline yang lebih pantas, keterlihatan tingkah laku rep, pemindahan automatik antara pemasaran dan jualan, serta isyarat masa nyata yang memberitahu deal mana yang berisiko sebelum terlepas. Setiap pembekal CRM dan perisikan jualan utama sedang menuju ke arah ini. Teknologinya adalah nyata.

Namun terdapat jurang antara janji tersebut dengan apa yang kebanyakan pemimpin RevOps alami apabila mereka melaksanakan AI ke atas stack pendapatan sedia ada mereka. Jurang itu bukan pada AI. Ia ada pada data.

AI untuk operasi pendapatan pada asasnya adalah sistem pengecaman corak yang beroperasi ke atas data pendapatan. Jika data tersebut bersih, konsisten dan lengkap, AI akan menemui corak. Jika ia berselerak, dimasukkan dengan tidak konsisten, tersimpan dalam sistem berasingan atau mempunyai medan yang tidak lengkap, AI akan mengukuhkan bunyi latar belakang bukannya mengenal pasti isyarat. Kebanyakan syarikat pertengahan pasaran melaksanakan AI ke atas data yang tidak direka untuk menyokongnya, kemudian tertanya-tanya mengapa AI tidak memenuhi janji pembekal.

Apa yang "Penjajaran Data" Sebenarnya Bermaksud dalam RevOps

Pasukan RevOps menggunakan istilah "penjajaran data" secara longgar. Ia boleh bermaksud apa sahaja, daripada menyegerakkan rekod CRM dengan automasi pemasaran sehinggalah memastikan jualan dan kewangan bersetuju tentang apa yang dikira sebagai pendapatan. Untuk AI khususnya, penjajaran data mempunyai makna yang lebih tepat.

Model AI untuk kerja pendapatan memerlukan empat perkara daripada data. Mereka memerlukan konsistensi (medan yang sama bermaksud perkara yang sama merentas setiap sistem, setiap rep dan setiap deal). Mereka memerlukan kelengkapan (medan yang digunakan untuk melatih model benar-benar diisi, bukan dibiarkan kosong). Mereka memerlukan kekinian (rekod mencerminkan apa yang sedang berlaku sekarang, bukan apa yang berlaku enam bulan lalu sebelum seseorang berhenti mengemas kininya). Dan mereka memerlukan liputan (data mewakili keseluruhan rangkaian perniagaan, bukan hanya deal yang ditutup atau akaun yang tidak melakukan Churn).

Kebanyakan sistem RevOps pertengahan pasaran gagal dalam sekurang-kurangnya dua daripada kriteria ini. Kegagalan yang paling biasa ialah konsistensi. Definisi peringkat deal berubah dari masa ke masa. Apa yang bermaksud "layak" bagi seorang rep berbeza daripada apa yang bermaksud bagi rep lain. "Pembuat keputusan dihubungi" ditandai pada tahap berbeza dalam proses bergantung pada siapa yang membuat kemasukan. Dalam pasukan jualan yang mempunyai 200 rep, ketidakkonsistenan kecil ini terkumpul menjadi set data yang kelihatan mempunyai 50,000 titik data tetapi sebenarnya mempunyai 50,000 perkara yang sedikit berbeza yang diukur dengan label yang sama.

Apabila anda menambah lapisan forecasting AI di atas data yang ditakrifkan secara tidak konsisten, model itu belajar untuk meramal berdasarkan bunyi latar belakang. Ia mungkin mencapai ketepatan yang boleh diterima dalam jangka pendek kerana pertimbangan manusia telah tertanam dalam ketidakkonsistenan tersebut. Tetapi ia tidak akan membuat generalisasi, tidak akan bertambah baik dan akan gagal apabila sesuatu berubah.

Tiga Masalah Data yang RevOps Perlu Selesaikan Dahulu

Terdapat masalah penjajaran data yang biasa menghalang pelaksanaan AI. Ia bukan satu-satunya masalah, tetapi ia yang paling berkesan untuk diselesaikan.

Masalah 1: Anjakan definisi peringkat. Setiap CRM mempunyai struktur peringkat Pipeline. Kebanyakannya mempunyainya dalam dokumentasi. Hampir tiada yang menerapkannya secara konsisten dalam amalan. Jalankan audit ringkas: tarik semua deal yang berpindah dari "cadangan dihantar" ke "closed lost" dan baca nota-nota tersebut. Anda akan menemui deal di mana "cadangan dihantar" ditandai apabila rep menghantar e-mel awalan, deal di mana ia ditandai apabila cadangan formal diserahkan, dan deal di mana rep menandainya secara retroaktif apabila deal itu sudah hampir tutup. Itu tiga perkara berbeza yang dilabelkan dengan cara yang sama.

Membaikinya memerlukan pembersihan takrifan (kriteria masuk dan keluar yang jelas untuk setiap peringkat) dan program perubahan tingkah laku (rep perlu memahami mengapa konsistensi penting untuk forecasting, bukan hanya diberitahu untuk mengisi medan). Panduan rutin kebersihan CRM merangkumi aspek disiplin operasi. Perubahan tingkah laku adalah lebih sukar dan biasanya memerlukan penglibatan pengurus.

Masalah 2: Data isyarat yang tersimpan secara berasingan. Model AI untuk kesihatan Pipeline dan risiko Churn memerlukan isyarat dari seluruh stack pendapatan, bukan hanya dari CRM. Penglibatan e-mel, penggunaan produk (jika berkaitan), jumlah tiket sokongan, tarikh pembaharuan kontrak, masa pembayaran invois, penglibatan pemasaran. Kebanyakan syarikat pertengahan pasaran mempunyai data ini dalam sistem berasingan tanpa pengecam bersama yang menghubungkan kenalan dalam CRM dengan tingkah laku kenalan yang sama dalam platform sokongan atau alat pemasaran.

Membina hubungan ini adalah teras seni bina data RevOps. Ini bukan kerja yang glamor dan sering memerlukan sumber teknikal yang tidak dikawal oleh pasukan RevOps. Tetapi ia adalah prasyarat bagi AI yang dapat memberikan amaran awal yang tulen tentang akaun yang berisiko daripada hanya mengecam corak dalam medan CRM yang rep kemas kini secara tidak konsisten.

Masalah 3: Jurang data sejarah. Model AI memerlukan data sejarah untuk belajar. Model yang meramal deal mana yang akan ditutup perlu melihat cukup banyak deal yang ditutup untuk belajar corak apa yang meramal penutupan. Jika CRM anda tidak diselenggara dengan baik dua tahun lalu (banyak yang tidak), set data sejarah yang model AI akan latih adalah terlalu tidak boleh dipercayai.

Terdapat dua pendekatan. Anda boleh membersihkan data sejarah, yang mahal dan tidak sempurna. Atau anda boleh menerima bahawa model forecasting AI pertama anda akan lebih lemah kerana ia melatih pada sejarah yang penuh gangguan, menggunakan pertimbangan manusia untuk mengatasi output model semasa tempoh awal, dan melabur dalam data bersih ke hadapan dengan pemahaman bahawa model bertambah baik dari masa ke masa apabila data yang lebih bersih terkumpul. Pendekatan kedua biasanya lebih praktikal untuk syarikat pertengahan pasaran.

Mengapa RevOps Bertanggungjawab, Bukan IT

Masalah penjajaran data dalam operasi pendapatan terasa seperti masalah infrastruktur. Ia wujud dalam pangkalan data dan sistem. Naluri ialah untuk menyerahkannya kepada IT.

Naluri tersebut salah atas sebab yang khusus: bahagian penjajaran data dalam RevOps yang paling sukar adalah tingkah laku, bukan teknikal. Memastikan rep mengemas kini peringkat deal secara konsisten, memastikan pemasar menerapkan konvensyen status Lead yang sepadan dengan cara jualan berfikir tentang kelayakan, memastikan customer success merekod data penglibatan dengan cara yang bersepadu dengan pandangan jualan tentang akaun: ini adalah perubahan workflow dan budaya. IT boleh membina integrasi, tetapi mereka tidak boleh mengubah cara 80 jurujual berfikir tentang kemasukan data.

RevOps bertanggungjawab kerana RevOps adalah fungsi yang berada di persimpangan proses, sistem dan pasukan Go-to-Market. Penjajaran data adalah pada asasnya masalah proses dan tadbir urus, bukan masalah teknologi. Teknologi sering kali merupakan bahagian yang mudah.

Ini juga bermaksud bahawa pemimpin RevOps yang ingin menjadikan AI berfungsi memerlukan sokongan eksekutif dan autoriti merentas fungsi. Penjajaran data yang memerlukan kepimpinan jualan untuk menguatkuasakan standard kebersihan CRM baharu memerlukan kepimpinan jualan untuk menyokongnya. Penjajaran data yang memerlukan pemasaran untuk mengubah konvensyen lead scoring mereka memerlukan pemasaran untuk melihat nilainya. Itu adalah masalah koordinasi yang dipimpin RevOps, bukan projek yang dijalankan di sudut.

Perspektif CRM nativ AI untuk syarikat pertengahan pasaran merangkumi bagaimana rupa keadaan akhir apabila penjajaran data dilakukan dengan baik. Tetapi jalan menuju keadaan tersebut melalui kerja penjajaran yang sukar yang diterangkan di sini.

Bagaimana Rupa Sprint Penjajaran Data

Pendekatan yang betul untuk kebanyakan pasukan RevOps pertengahan pasaran adalah sprint yang berfokus sebelum pelaksanaan AI, bukan program transformasi data berbilang tahun. Matlamatnya bukan data yang sempurna. Matlamatnya adalah data yang cukup bersih untuk AI menemui corak yang nyata.

Sprint biasa berjalan 6-8 minggu dengan kumpulan kerja RevOps-IT yang kecil. Hasilnya adalah penilaian kesediaan data yang merangkumi: pemeriksaan konsistensi medan demi medan untuk input yang diperlukan oleh pembekal AI, audit rekod sejarah untuk mengenal pasti tempoh masa yang cukup bersih untuk latihan model, peta integrasi untuk isyarat merentas sistem yang diperlukan oleh model AI, dan framework tadbir urus yang mentakrifkan pemilikan dan penguatkuasaan untuk kualiti data yang berterusan.

Penilaian tersebut memberitahu anda perkara yang boleh anda gunakan AI sekarang, perkara yang memerlukan pemulihan sebelum pelaksanaan dan apakah keperluan penyelenggaraan yang berterusan. Kebanyakan pasukan RevOps terkejut mendapati bahawa 70-80% pelaksanaan AI yang mereka inginkan boleh disokong oleh data sedia ada mereka setelah sejumlah kecil masalah konsistensi diperbaiki.

20-30% yang memerlukan kerja infrastruktur yang lebih mendalam boleh dijadualkan ke fasa berikutnya. Bermula dengan apa yang boleh dilaksanakan sekarang membina keyakinan organisasi dan menghasilkan kemenangan cepat yang membiayai kerja yang lebih sukar.

Penentangan Pasukan Jualan yang Akan Anda Hadapi

Setiap inisiatif penjajaran data yang menyentuh cara rep jualan merekod aktiviti akan menghasilkan penentangan. Rep akan mengatakan keperluan baharu mengambil masa terlalu lama, tidak mencerminkan cara deal sebenarnya berfungsi, dan mewujudkan birokrasi yang menghalang jualan. Sebahagian daripada ini adalah sah. Kebanyakannya adalah geseran biasa perubahan tingkah laku.

Pembingkaian yang berjaya bukan "CRM memerlukan data yang lebih baik". Ia adalah "AI yang akan membantu anda menutup lebih banyak deal dengan lebih cepat memerlukan data ini untuk berfungsi bagi pihak anda". Itu adalah cadangan nilai yang berbeza. Yang pertama adalah permintaan syarikat. Yang kedua adalah manfaat peribadi.

Tetapi ia hanya berjaya jika AI benar-benar memberikan nilai yang kelihatan kepada rep cukup cepat sehingga mereka menghubungkan disiplin data dengan manfaat tersebut. Jika terdapat kelewatan 12 bulan antara meningkatkan kebersihan data dan melihat output AI yang lebih baik, hubungan tersebut tidak akan bertahan. Reka bentuk pilot harus dengan sengaja mewujudkan gelung Feedback pantas di mana rep melihat peningkatan ketepatan AI hampir dalam masa nyata hasil daripada disiplin data mereka.

Tingkah laku pengurus lebih penting daripada latihan rep di sini. Jika pengurus menggunakan semakan Pipeline untuk mengukuhkan kualiti data (merujuk ketepatan forecast AI secara eksplisit, membuat susulan pada medan yang kosong atau tidak konsisten), rep mendapat isyarat dengan cepat. Jika pengurus mengabaikan masalah kualiti data dalam semakan Pipeline, rep juga akan berbuat demikian.

Audit kesediaan AI untuk pasukan jualan memasukkan kebersihan data sebagai salah satu dimensi kesediaan, yang merupakan pembingkaian yang betul. Kebersihan data adalah isu kesediaan AI, bukan sekadar isu pentadbiran CRM.

Selepas Penjajaran Data: Apa yang AI Sebenarnya Ubah dalam RevOps

Apabila penjajaran data tersedia, keupayaan AI yang dipedulikan oleh pemimpin RevOps sebenarnya berfungsi.

Ketepatan forecasting bertambah baik kerana model mengecam corak pada data yang konsisten dan lengkap bukannya anggaran yang penuh gangguan. Mesyuarat semakan Pipeline menjadi lebih pendek kerana rep dan pengurus boleh mempercayai skor kesihatan deal yang dijana oleh AI bukannya menghabiskan 20 minit berdebat sama ada deal itu benar-benar berada di peringkat 3. Amaran akaun berisiko menjadi boleh diambil tindakan kerana model mempunyai data isyarat yang cukup untuk membezakan akaun yang benar-benar berisiko daripada akaun yang hanya mempunyai tiket sokongan yang terbuka.

Ini adalah hasil produktiviti dan pendapatan yang bermakna. Ia juga rapuh. Kualiti data merosot dari masa ke masa tanpa tadbir urus yang aktif. Kerja membina infrastruktur penjajaran diimbangi oleh kerja menyelenggaranya. Organisasi RevOps yang menganggap tadbir urus data sebagai projek sekali sahaja dan bukannya disiplin berterusan melihat ketepatan AI merosot dalam masa 6-12 bulan apabila kualiti data melayang kembali ke keadaan sebelumnya.

Framework pengukuran untuk pelaburan AI RevOps secara langsung berkaitan dengan pendekatan pengukuran pulangan yang CFO perlukan untuk sebarang perbelanjaan AI. Framework CFO untuk mengukur pulangan AI dan kerja penjajaran data RevOps yang diterangkan di sini adalah dua sisi masalah yang sama: cara membina pelaburan AI yang menjana pulangan yang boleh dipertahankan dan diukur dan bukannya sekadar aktiviti dan bunyi latar belakang.

Ketahui Lebih Lanjut