Sistem Rekod Revenue Operations: CRM, Aliran Kerja, dan Seni Bina Data

Sistem rekod revenue operations ialah seni bina yang ditadbir urus untuk kebenaran hasil.

Bagi kebanyakan syarikat, CRM adalah terasnya. Tetapi bukan setiap fakta hasil tergolong hanya dalam CRM. Billing mungkin memiliki data langganan. Customer success mungkin memiliki data kesihatan. Automasi pemasaran mungkin memiliki keahlian kempen. BI mungkin memiliki pelaporan yang disatukan.

RevOps menentukan bagaimana sistem-sistem itu bekerja bersama.

Penyelidikan penjajaran teknologi RevOps oleh Forrester berguna kerana soalan sistem rekod bukan sekadar soalan alat semata-mata. Ia adalah soalan model operasi. Penyelidikan model operasi RevOps oleh Forrester turut menekankan perkara yang sama dari sudut tadbir urus: sistem hanya berfungsi apabila pemilikan, proses, dan hak membuat keputusan jelas.

Fakta operasi utama

• Sistem rekod revenue operations ialah seni bina yang ditadbir urus bagi tempat kerja berlaku, tempat kebenaran berada, dan bagaimana pelaporan menggabungkan sistem.
• CRM biasanya menjadi teras bagi akaun, kenalan, opportunity, pemilikan, dan pipeline, tetapi billing, CS, automasi pemasaran, dan BI mungkin memiliki kebenaran lain.
• Model sistem rekod sepatutnya menentukan peraturan baca/tulis, pemilikan integrasi, pengendalian konflik, dan amaran pelaporan.
• RevOps sepatutnya mendokumenkan sistem mana yang digunakan untuk aliran kerja, sistem mana yang digunakan untuk kebenaran, dan lapisan mana yang digunakan untuk pelaporan eksekutif.

Lapisan seni bina

Model sistem rekod sepatutnya didokumenkan dalam Sumber Kebenaran untuk Data Hasil.

Aliran kerja berbanding kebenaran

Pisahkan tempat orang bekerja daripada tempat nilai rasmi itu berada.

Pembahagian ini mengelakkan pemaksaan satu sistem untuk melakukan semua kerja. CRM mungkin menjadi sistem aliran kerja bagi jualan, tetapi kewangan mungkin masih memiliki nilai hasil akhir. CS mungkin menguruskan kesihatan dalam platform CS, manakala BI menggabungkan kesihatan itu dengan data pembaharuan untuk kepimpinan.

Sistem rekod berbanding sumber kebenaran

Istilah-istilah ini berkait tetapi tidak sama.

Sistem rekod ialah aplikasi atau pangkalan data yang memiliki jenis data tertentu. Model sumber kebenaran menerangkan sistem mana yang menang bagi setiap soalan perniagaan.

Sebagai contoh:

Model sumber kebenaran ialah buku peraturan. Sistem rekod ialah tempat data itu berada.

Mengapa satu alat sahaja tidak mencukupi

Ramai pasukan mahukan satu alat menjadi jawapan kepada segalanya. Itu biasanya gagal.

CRM kukuh untuk akaun, kenalan, opportunity, pemilik, aktiviti, dan pipeline, selagi pengurusan rekod pendua menghalang objek-objek itu daripada berpecah-pecah. Ia mungkin bukan tempat terbaik untuk invois, jadual langganan, telemetri penggunaan, tiket sokongan, acara produk, atau data penutupan kewangan.

RevOps sepatutnya mengelakkan memaksa setiap fakta ke dalam CRM. Sebaliknya, ia sepatutnya menentukan:

• Sistem mana memiliki fakta itu
• Medan mana yang disegerakkan ke dalam CRM untuk aliran kerja
• Medan mana yang disegerakkan ke dalam BI untuk pelaporan
• Sistem mana yang boleh mengubah nilai itu
• Sistem mana yang hanya boleh dibaca
• Bagaimana konflik diselesaikan

Ini melindungi kedua-dua kebolehgunaan dan kepercayaan.

Peraturan keputusan seni bina

Gunakan peraturan berikut:

Matlamatnya bukan kesucian. Matlamatnya ialah kerja yang boleh dipercayai.

CRM sebagai teras operasi

Bagi kebanyakan pasukan B2B, CRM ialah teras operasi.

Ia biasanya memiliki:

• Rekod akaun dan kenalan
• Rekod opportunity
• Pemilik dan wilayah
• Peringkat pipeline
• Kategori ramalan
• Aktiviti dan tugasan
• Penghalaan lead dan serah tugas jualan
• Konteks serah tugas closed-won

Ini tidak bermaksud CRM memiliki setiap kebenaran hasil. Ia bermaksud CRM ialah tempat ramai pasukan menyelaraskan tindakan.

Lapisan aliran kerja

Aliran kerja ialah tempat kebanyakan model sistem rekod menjadi rosak.

Sesuatu medan mungkin dimiliki oleh billing, tetapi jualan mungkin perlu melihatnya sebelum pembaharuan. Sesuatu isyarat kesihatan mungkin dimiliki oleh CS, tetapi kewangan mungkin memerlukannya untuk perancangan. Sesuatu medan kempen mungkin dimiliki oleh automasi pemasaran, tetapi jualan memerlukannya untuk konteks sumber.

RevOps sepatutnya menentukan fakta mana yang disalin atau dipaparkan ke dalam sistem aliran kerja dan fakta mana yang kekal dalam sistem asalnya.

Lapisan BI dan pelaporan

BI selalunya menjadi tempat terbaik untuk pelaporan gabungan, tetapi BI tidak sepatutnya menjadi sumber kebenaran yang tidak diurus.

RevOps dan kewangan sepatutnya menentukan:

• Metrik mana yang dikira dalam BI
• Medan mana yang diimport daripada setiap sistem
• Transformasi mana yang diluluskan
• Dashboard mana yang menjadi sumber kebenaran eksekutif
• Amaran mana yang muncul dalam laporan

Jika logik BI berbeza daripada dashboard CRM tanpa dokumentasi, kepercayaan akan menurun.

Tadbir urus integrasi

Integrasi boleh mewujudkan konflik data.

Tadbir urus:

• Arah penulisan
• Kekerapan penyegerakan
• Pemetaan medan
• Peraturan konflik
• Pengendalian ralat
• Pemilik penyegerakan yang gagal
• Kelulusan perubahan

Sebagai contoh, jika automasi pemasaran dan CRM kedua-duanya boleh mengubah sumber lead, syarikat memerlukan peraturan tentang nilai mana yang menang. Jika billing dan CRM kedua-duanya menyimpan jumlah kontrak, kewangan perlu menentukan nilai perancangan.

Konteks Rework

Platform CRM dan aliran kerja seperti Rework boleh menyokong RevOps apabila peringkat kitaran hayat, penghalaan, tugasan, pemilikan, dan konteks pelanggan ditadbir urus dalam satu permukaan operasi. Seni bina itu masih bergantung kepada proses dan peraturan data yang jelas.

Rework sepatutnya dilayan sebagai permukaan kerja untuk pergerakan pelanggan dan hasil apabila pasukan menggunakannya sedemikian. Tetapi RevOps masih perlu menentukan data mana yang datang daripada billing, pemasaran, CS, kewangan, atau BI apabila sistem-sistem itu memiliki fakta kekal itu.

Kesilapan yang lazim

Menganggap CRM sebagai sumber kebenaran bagi segalanya. Ini mewujudkan kesesuaian yang buruk untuk kewangan, billing, dan data penggunaan produk.

Membiarkan BI mentakrifkan semula metrik secara senyap. Laporan menjadi terputus daripada sistem aliran kerja.

Tiada peraturan konflik. Dua sistem menulis nilai yang berbeza dan pasukan memilih mana-mana yang menyokong hujah mereka.

Tiada pemilik integrasi. Ralat penyegerakan menjadi tidak kelihatan sehingga pelaporan rosak.

Tiada kamus data. Orang tidak dapat mencari definisi terkini.

Pelan pelaksanaan

Mulakan dengan soalan hasil yang kritikal:

1. Di mana pemilikan akaun berada?
2. Di mana peringkat opportunity berada?
3. Di mana kategori ramalan berada?
4. Di mana jumlah langganan berada?
5. Di mana kesihatan pelanggan berada?
6. Di mana sumber lead berada?
7. Di mana pelaporan lembaga berada?

Petakan setiap soalan kepada satu sistem, pemilik, peraturan edit, dan laporan.

Senarai semak kesediaan

Sebelum menerbitkan model:

• Elemen data kritikal sudah dipetakan.
• Hak edit sudah jelas.
• Peraturan konflik sudah ditulis.
• Transformasi BI sudah didokumenkan.
• Kewangan sudah meluluskan definisi kewangan.
• RevOps memiliki tadbir urus perubahan.
• Pasukan tahu di mana untuk memeriksa kebenaran.

Sistem rekod itu berkesan apabila pasukan berhenti mengeksport data untuk menentukan sistem mana yang mereka percayai.

Contoh seni bina

Seni bina pasaran pertengahan yang praktikal mungkin kelihatan seperti berikut:

Seni bina itu berfungsi apabila setiap sistem mempunyai tugas dan serah tugas ditadbir urus.

Kawalan operasi

RevOps sepatutnya mengekalkan kawalan di sekeliling seni bina:

• Pemilikan medan
• Pemilikan integrasi
• Kebenaran penulisan
• Kelulusan perubahan
• Pemantauan penyegerakan
• Pengendalian ralat
• Pemilikan laporan
• Kemas kini kamus data

Kawalan ini menghalang kemerosotan perlahan. Kebanyakan masalah sistem rekod tidak datang daripada satu kegagalan besar. Ia datang daripada perubahan kecil yang tidak diurus: satu medan ditambah di sini, satu aliran kerja diubah di sana, satu ralat penyegerakan diabaikan selama berminggu-minggu.

Katalog sistem rekod

Cipta satu katalog:

Katalog ini membantu pemimpin RevOps, sistem, dan kewangan baharu memahami seni bina dengan cepat.

Senario kegagalan

Senario yang lazim:

CRM dan billing tidak sepadan tentang ARR. Kewangan sepatutnya menentukan angka mana yang digunakan untuk perancangan dan bagaimana CRM menerima konteks komersial yang dikemas kini.

Automasi pemasaran menulis semula sumber. RevOps sepatutnya mengunci sumber asal atau mencipta peraturan kemas kini yang ketat.

Kesihatan CS berada di luar pelaporan hasil. Perancangan risiko pembaharuan dan pengembangan terlepas realiti pelanggan.

BI mentransformasi metrik tanpa dokumentasi. Pelaporan eksekutif menjadi sukar diselaraskan dengan dashboard operasi.

Ralat integrasi tidak dipantau. Pasukan menemui jurang data semasa pelaporan lembaga.

Mesyuarat tadbir urus

Jalankan semakan tadbir urus sistem bulanan bagi perubahan yang menjejaskan data hasil:

• Medan baharu
• Aliran kerja baharu
• Perubahan integrasi
• Perubahan definisi dashboard
• Penambahan alat
• Perubahan kebenaran penulisan
• Isu kualiti data

Ini bukan mesyuarat permintaan alat. Ia adalah mesyuarat perlindungan seni bina.

Turutan pelancaran

Untuk membina model:

1. Inventori sistem.
2. Petakan soalan hasil kritikal.
3. Tetapkan pemilikan sumber rekod.
4. Kenal pasti konflik penulisan.
5. Dokumenkan integrasi.
6. Tambah entri kamus data.
7. Selaraskan kewangan dan RevOps tentang peraturan pelaporan.
8. Terbitkan model itu.
9. Semak setiap bulan.

Peraturan turutan pelancaran

Model sistem rekod sepatutnya memudahkan kerja, bukan melambatkannya. Pasukan sepatutnya tahu di mana untuk memasukkan data, di mana untuk memeriksa kebenaran, dan di mana untuk menaikkan konflik. Jika model itu hanya wujud dalam gambar rajah seni bina, ia tidak akan mengubah tingkah laku.

Matriks pemilikan

Model sistem rekod sepatutnya merangkumi matriks pemilikan:

Matriks ini mengelakkan masalah lazim: semua orang menggunakan sistem itu, tetapi tiada sesiapa memiliki kualitinya.

Apa yang tergolong dalam CRM

CRM sepatutnya menyimpan data yang diperlukan untuk aliran kerja hasil:

• Pemilik akaun
• Pemilik opportunity
• Peringkat kitaran hayat
• Peringkat pipeline
• Kategori ramalan
• Langkah seterusnya
• Tarikh tutup
• Risiko deal
• Medan serah tugas closed-won
• Pemilik pembaharuan atau keterlihatan pembaharuan

Ia tidak semestinya menyimpan setiap acara penggunaan produk, baris invois, tiket sokongan, atau pelarasan penutupan kewangan. Itu mungkin tergolong di tempat lain dan hanya menyegerakkan konteks ringkasan ke dalam CRM.

Apa yang tergolong di luar CRM

Sesetengah data sepatutnya kekal dalam sistem khusus:

• Jadual billing
• Status invois
• Log penggunaan produk
• Sejarah kes sokongan
• Dokumen kontrak
• Data penutupan kewangan
• Penglibatan kempen yang terperinci

CRM mungkin memerlukan ringkasan, pautan, atau status, tetapi bukan keseluruhan set data itu.

Peraturan pergerakan data

Bagi setiap integrasi, dokumenkan:

• Objek sumber
• Objek sasaran
• Pemetaan medan
• Arah penyegerakan
• Kekerapan penyegerakan
• Pemilik ralat
• Peraturan konflik
• Kesan perniagaan jika penyegerakan gagal

Ini menghalang pemilikan integrasi daripada menjadi pengetahuan yang tersimpan secara tidak formal.

Contoh operasi peraturan pergerakan data

Jika kesihatan CS berubah kepada risiko tinggi, CRM mungkin memerlukan penanda risiko pembaharuan supaya jualan dan kewangan dapat melihatnya. CS kekal sebagai pemilik model kesihatan, tetapi CRM memerlukan isyarat aliran kerja itu.

Jika billing mengemas kini jumlah langganan, kewangan kekal sebagai pemilik kebenaran komersial. CRM mungkin memerlukan ARR yang dikemas kini untuk perancangan akaun, tetapi bukan sebagai sistem kewangan akhir.

Jika pemasaran menangkap sumber asal, RevOps sepatutnya melindungi nilai itu daripada suntingan sambil lewa kerana atribusi dan keputusan belanjawan bergantung kepadanya.

Senarai semak pergerakan data

Sebelum pelaksanaan:

• Katalog sistem sudah wujud.
• Medan kritikal mempunyai pemilik.
• Arah penulisan sudah jelas.
• Peraturan konflik sudah didokumenkan.
• Ralat penyegerakan mempunyai pemilik.
• Formula BI jelas kelihatan.
• Pengguna CRM tahu apa yang perlu dimasukkan.
• Kewangan tahu angka mana yang rasmi.

Model sistem rekod itu matang apabila pasukan menggunakan sistem yang betul kerana ia lebih mudah, bukan kerana RevOps sentiasa mengingatkan mereka.

Amaran praktikal

Jangan reka semula seni bina hanya berdasarkan gambar rajah. Periksa bagaimana kerja sebenar berlaku. Di mana rep mengemas kini deal? Di mana CS merekod risiko? Di mana kewangan mempercayai nilai kontrak? Di mana kepimpinan memeriksa prestasi?

Seni bina sepatutnya mengikut pemilikan kekal dan aliran kerja sebenar. Jika sesuatu model kelihatan kemas tetapi memaksa pasukan ke dalam jalan pintas yang janggal, ia akan gagal.

Senarai semak risiko

Sebelum menganggap seni bina itu selesai, sahkan bahawa setiap soalan hasil kritikal mempunyai jawapan:

• Di mana nilai itu dimasukkan?
• Siapa boleh mengeditnya?
• Sistem mana yang menang?
• Di mana ia muncul dalam aliran kerja?
• Di mana ia muncul dalam pelaporan?
• Siapa membaikinya apabila ia rosak?

Jika mana-mana jawapan itu tidak jelas, model sistem rekod belum cukup lengkap untuk berkembang.

Model itu juga sepatutnya diuji semasa onboarding. Seorang pemimpin hasil baharu sepatutnya dapat memahami sistem mana yang memiliki pipeline, billing, kesihatan pelanggan, data sumber, dan pelaporan eksekutif tanpa perlu bertanya lima pasukan yang berbeza. Jika onboarding masih bergantung kepada pengetahuan tidak formal, seni bina itu memerlukan dokumentasi yang lebih jelas.

Pakej keputusan seni bina

Sebelum mengubah sistem rekod hasil, sediakan satu pakej ringkas:

Pakej ini sepatutnya disemak sebelum menambah integrasi, mengubah medan CRM, atau memindahkan data hasil ke platform baharu. Keputusan sistem rekod bukan sekadar pilihan teknikal. Ia mengubah bagaimana pasukan mempercayai, mengedit, dan bertindak ke atas data hasil.

Soalan Lazim

Adakah CRM sistem rekod bagi hasil?

Selalunya bagi data pipeline dan opportunity, ya. Tetapi billing, CS, automasi pemasaran, dan BI mungkin memiliki bahagian lain daripada kebenaran hasil.

Siapa memiliki model sistem rekod?

RevOps sepatutnya memilikinya dengan input daripada kewangan, IT, pemasaran, jualan, dan CS.

Ketahui lebih lanjut

• Tech Stack Hasil
• Kamus Data Hasil
• Tadbir Urus Medan CRM