Pengurusan Rekod Pendua: Cara RevOps Menghalang Pemecahan CRM

Rekod pendua bukan sekadar menjadikan CRM kelihatan bersepah.

Ia memecahkan kebenaran pelanggan. Satu akaun mempunyai aktiviti jualan. Satu lagi akaun mempunyai risiko pembaharuan. Yang ketiga mempunyai kenalan pengebilan. Seorang lead berada di luar akaun walaupun syarikat itu sudah berada dalam pipeline. Pemasaran mengira tiga orang. Jualan melihat dua pemilik. Kejayaan pelanggan terlepas sejarah itu.

Kemudian sistem hasil mula membuat keputusan daripada konteks yang berpecah.

Pengurusan rekod pendua ialah cara RevOps mengekalkan data akaun, kenalan, lead, dan peluang terikat kepada satu realiti operasi. Ia bukan sekadar tugas pembersihan. Ia adalah sistem kawalan untuk penghalaan, pemarkahan, pelaporan, pemilikan, serah tugas, pengalaman pelanggan, dan kepercayaan hasil.

Penyelidikan penjajaran teknologi RevOps oleh Forrester relevan kerana rekod pendua menjejaskan penghalaan, pelaporan, automasi, dan konteks pelanggan merentasi enjin hasil. Model tanggungjawab RevOps oleh Forrester turut menegaskan mengapa dasar rekod pendua perlu merentasi fungsi.

Fakta operasi utama

• Rekod pendua bukan kekusutan rekod. Ia memecahkan konteks pelanggan.
• Akaun pendua biasanya membawa lebih banyak risiko berbanding kenalan pendua kerana ia menyentuh pipeline, pengebilan, pembaharuan, dan pemilikan.
• Peraturan penggabungan perlu ditulis sebelum pembersihan bermula.
• Kawalan import, penukaran, enrichment, dan integrasi lebih penting daripada projek dedupe sekali sahaja.
• Kadar penciptaan pendua yang menurun adalah isyarat yang lebih kuat berbanding kiraan penggabungan yang tinggi.

Mengapa rekod pendua adalah masalah hasil

Rekod pendua mencipta kerosakan operasi dalam lima cara.

Pendua yang paling mahal bukan sentiasa yang paling ketara. Akaun pendua tanpa pipeline terbuka masih boleh berbahaya jika ia memiliki kenalan pembaharuan, sejarah sokongan, hubungan pengebilan, atau atribusi sumber.

Itulah sebabnya pengurusan pendua tergolong dalam lapisan operasi yang sama dengan kebersihan data CRM dan tadbir urus medan CRM. Kerja dedupe hanya boleh bertahan apabila medan, aliran kerja, dan peraturan pemilikan di sebaliknya jelas.

Jenis pendua utama

RevOps perlu mentakrifkan jenis pendua sebelum memilih peraturan.

Jenis pendua yang berbeza memerlukan isyarat pengesanan, pemilik perniagaan, dan keputusan penggabungan yang berbeza.

Pendua lead kepada kenalan

Lead baharu memasuki sistem melalui borang walaupun orang itu sudah wujud sebagai kenalan. Jika sistem tidak memadankan mereka, orang itu mungkin dihalakan sebagai lead baharu sedangkan pemilik akaun sudah mempunyai hubungan itu.

Ini biasa apabila:

• Kenalan yang diketahui menggunakan e-mel peribadi
• Kenalan menghantar borang baharu dengan domain berbeza
• Automasi pemasaran mencipta lead tanpa menyemak kenalan CRM
• Peraturan penukaran lead tidak lengkap
• Pengesanan pendua hanya menyemak padanan e-mel tepat

Pendua lead-kepada-kenalan menjejaskan penghalaan dan tindak balas. Ia juga boleh mencipta pengalaman pelanggan yang janggal apabila seseorang yang sudah berbual dengan jualan dilayan seperti lead masuk baharu.

Pendua kenalan

Orang yang sama wujud dua kali kerana variasi e-mel, sejarah import, enrichment, atau penciptaan manual.

Pendua kenalan memecahkan sejarah aktiviti. Satu rekod mempunyai kehadiran webinar. Satu lagi mempunyai e-mel jualan. Yang lain mempunyai nota sokongan. Jika pemasaran, jualan, dan kejayaan pelanggan masing-masing melihat versi berbeza, pasukan kehilangan ingatan hubungan.

Dasar penggabungan kenalan perlu mengekalkan:

• E-mel perniagaan yang disahkan
• E-mel alternatif jika berguna
• Status kebenaran dan langganan
• Sejarah aktiviti
• Sejarah kempen
• Hubungan akaun
• Peranan kenalan

Pendua kenalan sering lebih mudah digabungkan berbanding pendua akaun, tetapi ia masih memerlukan peraturan kelangsungan medan.

Pendua akaun

Syarikat yang sama wujud sebagai beberapa akaun kerana perbezaan penamaan, domain, anak syarikat, wilayah, import legasi, atau struktur pengebilan.

Pendua akaun adalah jenis pendua berisiko paling tinggi bagi kebanyakan pasukan B2B. Ia menjejaskan:

• Pipeline
• Ramalan
• Pemilikan territori
• Pemasaran berasaskan akaun
• Kesihatan pelanggan
• Risiko pembaharuan
• Pengebilan dan kontrak
• Sejarah sokongan
• Pelaporan eksekutif

Menggabungkan rekod akaun tanpa semakan perniagaan boleh merosakkan konteks selama bertahun-tahun.

Pendua peluang

Dua peluang mewakili pergerakan pembelian yang sama.

Pendua peluang menggembungkan pipeline, mengelirukan ramalan, dan menyukarkan pemeriksaan pengurus. Ia sering berlaku apabila pelbagai wakil jualan bekerja dengan kenalan berbeza pada akaun yang sama, pembaharuan dikelirukan dengan pengembangan, atau permintaan masuk mencipta peluang kedua sementara deal sedia ada aktif.

Pendua peluang memerlukan semakan pengurus jualan kerana keputusan itu bukan sekadar teknikal. Pengurus perlu memutuskan sama ada benar-benar terdapat dua pergerakan pembelian atau satu deal yang berpecah.

Pendua merentasi sistem

CRM, platform automasi pemasaran, platform kejayaan pelanggan, sistem pengebilan, dan data warehouse mungkin masing-masing mewakili pelanggan yang sama secara berbeza.

Pendua ini mungkin tidak kelihatan dari dalam satu sistem sahaja.

Contoh: CRM menggunakan "Acme," pengebilan menggunakan "Acme LLC," kejayaan pelanggan menggunakan "Acme North America," dan data warehouse memetakan penggunaan produk kepada "acme.com." Setiap rekod mungkin sah dalam sistemnya sendiri, tetapi pasukan hasil tidak dapat menyesuaikan pelanggan itu tanpa model identiti yang dikongsi.

Pendua merentasi sistem adalah masalah data sumber kebenaran hasil, bukan sekadar masalah pembersihan CRM.

Bina dasar padanan

Pengurusan pendua bermula dengan peraturan padanan.

Isyarat padanan biasa:

• Alamat e-mel
• Domain e-mel
• Laman web syarikat
• Nama syarikat
• Nombor telefon
• Profil LinkedIn
• Domain pengebilan
• Pemilik akaun
• Negara atau wilayah
• Akaun induk
• Nombor cukai atau ID pelanggan jika tersedia

Setiap isyarat mempunyai had. E-mel kuat untuk seseorang, tetapi lemah apabila orang menggunakan alias. Domain berguna untuk akaun B2B, tetapi lemah untuk konglomerat, agensi, universiti, peruncit semula, dan syarikat dengan pelbagai jenama. Nama syarikat perlu, tetapi perbezaan ejaan dan entiti undang-undang mencipta bunyi bising.

Gunakan tahap keyakinan.

Jangan biarkan padanan kabur menjadi penggabungan automatik untuk rekod penting. Tandakan dahulu, kemudian semak.

Padankan secara berbeza mengikut objek

Dasar padanan tidak sepatutnya menggunakan satu peraturan untuk setiap objek.

Perbezaan ini penting kerana penggabungan kenalan yang salah mengganggu, tetapi penggabungan akaun yang salah boleh merosakkan pipeline, pembaharuan, pengebilan, dan pelaporan sejarah.

Tentukan peraturan penggabungan sebelum pembersihan

Menggabungkan rekod bukan sekadar memadam pendua.

RevOps memerlukan dasar kelangsungan medan: nilai mana yang bertahan apabila rekod bercanggah?

Contoh:

• Pemilik akaun: kekalkan pemilik aktif, bukan pemilik paling lama.
• Sumber lead: kekalkan sumber asal dan simpan sumber terkini secara berasingan.
• Peringkat lifecycle: kekalkan peringkat sah yang paling maju.
• Status pelanggan: sistem pengebilan atau langganan mungkin menang.
• E-mel kenalan: kekalkan e-mel perniagaan yang disahkan.
• Sejarah aktiviti: kekalkan semua aktiviti apabila mungkin.
• Nota: tambah atau kekalkan, jangan timpa.
• Kebenaran: kekalkan status kebenaran sah yang paling ketat.
• Kategori ramalan: kekalkan nilai semasa yang diluluskan pengurus.

Jika peraturan penggabungan tidak jelas, pembersihan boleh memusnahkan konteks.

Gunakan jadual kelangsungan medan

Untuk penggabungan berisiko tinggi, jadual kelangsungan medan menghalang tekaan.

Jadual ini perlu wujud sebelum sprint pembersihan bermula. Jika tidak, setiap penggabungan menjadi perbalahan baharu.

Halang pendua pada titik kemasukan

Program pendua terbaik menghalang pendua sebelum ia memasuki CRM.

Kawalan merangkumi:

• Padanan borang terhadap kenalan sedia ada
• Padanan domain akaun sebelum penciptaan lead
• Pengesahan import
• Domain atau laman web syarikat wajib untuk penciptaan akaun
• Amaran pendua pada penciptaan rekod manual
• Padanan lead-ke-akaun
• Peraturan hierarki akaun
• Semakan enrichment sebelum menimpa
• Peraturan penukaran untuk kenalan yang diketahui

Pencegahan penting kerana pembersihan sahaja tidak dapat mengejar sistem yang terus mencipta pendua.

Kawal penangkapan borang

Borang mencipta banyak pendua kerana orang tidak selalu menghantar e-mel atau nama syarikat yang sama.

Proses penangkapan borang yang baik perlu:

• Mengesahkan format e-mel
• Menangkap laman web atau domain syarikat apabila sesuai
• Mengekalkan sumber asal
• Memadankan kenalan yang diketahui sebelum penciptaan lead baharu
• Menandakan e-mel peribadi untuk padanan akaun
• Mengelakkan penciptaan akaun baharu daripada setiap variasi nama syarikat
• Menghalakan padanan yang tidak pasti kepada semakan

Ini paling penting bagi borang niat tinggi seperti permintaan demo, permintaan harga, hubungi jualan, pertanyaan rakan kongsi, dan permintaan sokongan pelanggan.

Kawal import

Import boleh mencipta beribu-ribu pendua dalam beberapa minit.

Sebelum sebarang muat naik senarai, perlukan:

• Pemilik import
• Sumber senarai
• Tujuan import
• Pemetaan medan
• Semakan pendua
• Peraturan kemas kini rekod sedia ada
• Nota kebenaran atau pematuhan jika diperlukan
• Pelan rollback ralat

Jangan biarkan "nama bersih baharu" menjadi satu-satunya matlamat import. Senarai yang mencipta pendua boleh membuat volum kempen kelihatan baik sambil melemahkan sistem hasil.

Kawal enrichment

Enrichment boleh membantu memadankan rekod, tetapi ia juga boleh mencipta padanan palsu.

Isu pendua yang biasa didorong oleh enrichment:

• Domain syarikat generik dipetakan kepada akaun yang salah
• Anak syarikat digabungkan ke dalam akaun induk tanpa persetujuan jualan
• Jawatan kenalan ditimpa oleh data lapuk
• Nama akaun dinormalisasikan dengan cara yang merosakkan hierarki sedia ada
• E-mel peribadi dipadankan dengan syarikat yang salah

Gunakan enrichment sebagai isyarat, bukan autoriti yang tidak dipersoalkan.

Kawal integrasi

Integrasi mencipta pendua apabila sistem tidak bersetuju tentang identiti.

Bagi setiap sistem yang bersambung, dokumenkan:

• Rekod mana yang boleh dicipta
• Rekod mana yang boleh dikemas kini
• Medan mana yang boleh ditimpa
• Kunci padanan mana yang digunakan
• Apa berlaku apabila tiada padanan ditemui
• Siapa memiliki ralat penyegerakan

Ini tergolong dalam reka bentuk sistem rekod operasi hasil. Jika sistem tidak bersetuju tentang identiti, pembersihan pendua tidak akan bertahan.

Uruskan pendua akaun dengan berhati-hati

Pendua akaun layak mendapat perhatian ekstra kerana akaun sering berhubung dengan peluang, kontrak, tiket, pengebilan, penggunaan produk, dan aliran kerja kejayaan pelanggan.

Sebelum menggabungkan rekod akaun, periksa:

• Peluang terbuka
• Sejarah closed-won
• Tarikh pembaharuan
• Hubungan pengebilan
• Status pelanggan
• Akaun induk atau anak
• Pemilik akaun
• Tiket sokongan
• Kesihatan kejayaan pelanggan
• Urutan atau kempen aktif
• Data penggunaan produk
• Entiti kontrak

Untuk akaun strategik, perlukan semakan manusia. Penggabungan yang salah boleh merosakkan pelaporan dan konteks pelanggan selama bertahun-tahun.

Putuskan bila tidak menggabungkan

Sesetengah rekod kelihatan seperti pendua tetapi patut kekal berasingan.

Contoh:

• Syarikat induk dan anak syarikat dengan pasukan pembelian berbeza
• Akaun global dan unit perniagaan serantau
• Rekod rakan kongsi dan rekod pelanggan akhir
• Akaun agensi dan pelanggan
• Dua kenalan dengan nama serupa di syarikat yang sama
• Peluang berasingan untuk produk atau bahagian berbeza
• Entiti undang-undang dan entiti jenama di mana pengebilan memerlukan kedua-duanya

Program pendua yang kukuh merangkumi dasar "jangan gabung." Dasar itu sama penting dengan dasar penggabungan.

Uruskan hierarki akaun

Sesetengah masalah pendua sebenarnya adalah masalah hierarki.

Akaun besar mungkin memerlukan:

• Akaun induk global
• Akaun anak serantau
• Akaun anak syarikat
• Entiti pengebilan
• Hubungan rakan kongsi
• Pusat pembelian
• Peluang lini produk

Jika RevOps cuba memaksa setiap entiti berkaitan ke dalam satu rekod akaun, CRM mungkin kelihatan lebih bersih sementara model operasi menjadi lebih teruk.

Soalannya bukan "Bolehkah akaun ini digabungkan?" Soalan yang lebih baik ialah "Hubungan apa yang perlu dimiliki akaun ini supaya jualan, kejayaan pelanggan, kewangan, dan pelaporan semuanya dapat berfungsi?"

Semak pendua sebagai irama operasi

Pembersihan pendua tidak sepatutnya menunggu panik suku tahunan.

Semakan mingguan perlu memberi tumpuan kepada risiko aktif:

• Lead pendua keyakinan tinggi yang baharu
• Akaun pendua dengan peluang terbuka
• Kenalan pendua dalam urutan aktif
• Peluang pendua dalam ramalan semasa

Semakan bulanan perlu memeriksa corak:

• Kadar pendua mengikut sumber
• Kadar pendua mengikut import
• Kadar pendua mengikut integrasi
• Kadar pendua mengikut wilayah atau segmen
• Ralat penggabungan
• Rekod dicipta secara manual tanpa padanan

Semakan suku tahunan perlu mengemas kini dasar:

• Ambang padanan
• Peraturan kelangsungan medan
• Piawaian hierarki akaun
• Peraturan import
• Dasar enrichment
• Kebenaran pentadbir

Pendua adalah tingkah laku sistem. Semak sistem itu, bukan sekadar rekod.

Kad skor pendua

Kad skor yang berguna merangkumi:

• Kadar pendua mengikut objek
• Pendua baharu yang dicipta setiap minggu
• Pendua yang digabungkan setiap minggu
• Sumber pendua
• Purata masa untuk menyemak pendua
• Akaun pendua dengan pipeline terbuka
• Kenalan pendua dalam kempen aktif
• Kadar ralat penggabungan
• Rekod disekat semasa import
• Baki tertunggak pendua akaun strategik

Metrik paling penting bukan berapa banyak pendua yang digabungkan RevOps. Ia adalah sama ada penciptaan pendua sedang menurun.

Bina baris gilir semakan pendua

Pengurusan pendua berfungsi lebih baik apabila rekod berisiko mengalir ke dalam baris gilir semakan dan bukannya berselerak dalam laporan.

Baris gilir perlu menunjukkan:

• Jenis pendua
• Tahap keyakinan
• Objek yang terjejas
• Sumber penciptaan
• Pemilik
• Status pipeline atau pelanggan
• Tarikh aktiviti terakhir
• Tindakan yang disyorkan
• Penyemak
• SLA

Ini membolehkan RevOps mengasingkan risiko pendua yang mendesak daripada pembersihan biasa.

Baris gilir tidak sepatutnya dimiliki hanya oleh pentadbir CRM. RevOps boleh menjalankan baris gilir itu, tetapi pemilik perniagaan patut menyelesaikan rekod yang tidak jelas.

Triage sebelum menggabungkan

Tidak setiap pendua layak mendapat tindakan segera.

Gunakan triage:

1. Adakah terdapat pipeline atau status pelanggan aktif? Jika ya, semak sebelum menggabungkan.
2. Adakah terdapat data pengebilan, kontrak, atau kebenaran? Jika ya, libatkan pemilik data itu.
3. Adakah padanan itu berkeyakinan tinggi? Jika tidak, jangan gabung secara automatik.
4. Adakah sumber atau sejarah aktiviti akan terjejas? Jika ya, kekalkan sebelum menggabungkan.
5. Adakah rekod itu mewakili hierarki dan bukan pendua? Jika ya, cipta hubungan dan bukannya menggabungkan.

Triage melindungi kelajuan dan keselamatan pada masa yang sama. Pendua orang berisiko rendah boleh bergerak dengan pantas. Pendua akaun strategik perlu diperlahankan sehingga konteks perniagaan jelas.

Baca kad skor mengikut sumber

Jumlah pendua berguna, tetapi analisis peringkat sumber lebih baik.

Ini memberitahu RevOps di mana pencegahan perlu diperbaiki.

Sprint pembersihan yang praktikal

Jalankan pembersihan secara berperingkat.

1. Segmen pendua mengikut objek dan risiko.
2. Mulakan dengan pendua orang berkeyakinan tinggi.
3. Semak pendua akaun dengan peluang terbuka secara berasingan.
4. Tentukan peraturan penggabungan sebelum menyentuh akaun strategik.
5. Kekalkan sumber dan sejarah aktiviti.
6. Jejak rekod tidak jelas yang belum selesai.
7. Kenal pasti bagaimana pendua memasuki sistem.
8. Tambah kawalan pencegahan.

Sprint pembersihan belum selesai apabila pendua digabungkan. Ia selesai apabila RevOps dapat menjelaskan apa yang menciptanya dan apa yang berubah untuk menghalang pengulangan.

Contoh: akaun pendua dengan pipeline terbuka

Katakan Acme Inc. wujud sebagai dua akaun. Satu rekod mempunyai peluang terbuka. Yang lain mempunyai tiga kenalan, nota mesyuarat terdahulu, dan nota risiko kejayaan pelanggan daripada pilot terdahulu.

Penggabungan mudah mungkin kelihatan jelas, tetapi RevOps perlu memeriksa pemilikan, sejarah peluang, medan sumber, aktiviti, dan hierarki akaun sebelum bertindak. Jika rekod yang salah bertahan, pasukan mungkin kehilangan atribusi atau konteks sejarah. Jika pemilik peluang berubah secara senyap, pengurus jualan mungkin kehilangan keterlihatan.

Keputusan pembersihan perlu melibatkan pemilik perniagaan, bukan sekadar pentadbir sistem.

Contoh: lead pendua daripada akaun sedia ada

Seorang VP daripada akaun sasaran sedia ada menghantar borang demo dengan alamat e-mel peribadi. Jika CRM tidak memadankan rekod itu, lead mungkin memasuki baris gilir masuk standard. Wakil jualan baharu membuat susulan, sementara pemilik akaun yang dinamakan sudah mempunyai peluang aktif.

Ini bukan sekadar masalah pendua. Ia adalah masalah penghalaan, pemilikan akaun, dan pengalaman pelanggan.

Pencegahan mungkin memerlukan padanan domain, pengendalian e-mel peribadi, padanan lead-ke-akaun, dan laluan pengecualian untuk akaun strategik. Bagi pasukan dengan volum masuk yang tinggi, ini perlu berkait dengan automasi penghalaan lead, kerana logik penghalaan hanya sebaik logik identiti sebelumnya.

Contoh: peluang pendua

Pelanggan semasa bertanya tentang produk kedua. Seorang AE mencipta peluang pengembangan. Seorang CSM mencatatkan pergerakan pembelian yang sama sebagai pengembangan pembaharuan. Pengaruh pemasaran melekat kepada satu peluang, sementara ramalan menunjukkan kedua-duanya.

CRM kini menunjukkan lebih banyak pipeline berbanding realiti.

Pembaikannya bukan penggabungan membuta tuli. Pengurus jualan perlu memutuskan sama ada ini satu pergerakan pembelian, dua pergerakan pembelian, atau pembaharuan dengan pengembangan. RevOps perlu mengekalkan aktiviti dan konteks sumber, kemudian mengemas kini peraturan penciptaan peluang yang membenarkan perpecahan itu.

Pembersihan peluang pendua perlu berkait dengan proses lead-ke-peluang, terutamanya di mana permintaan masuk mencipta pipeline untuk akaun sedia ada.

Contoh: pendua pelanggan merentasi sistem

Seorang pelanggan wujud sebagai "Northstar Health" dalam CRM, "Northstar Health LLC" dalam pengebilan, dan "Northstar Enterprise" dalam kejayaan pelanggan.

Setiap sistem berfungsi secara tempatan. Tetapi dashboard eksekutif tidak dapat menyesuaikan tempahan, risiko pembaharuan, dan penggunaan produk tanpa pemetaan manual.

Ini bukan penggabungan CRM biasa. Ia adalah masalah identiti pelanggan. RevOps memerlukan kunci pelanggan yang dikongsi, pemilikan sistem, dan proses untuk keputusan entiti undang-undang, hierarki akaun, dan entiti pelaporan.

Pengurusan pendua mengikut peringkat lifecycle

Risiko pendua berubah merentasi lifecycle.

Inilah sebabnya pengurusan pendua tergolong dalam model operasi RevOps, bukan sekadar pembersihan pentadbir.

Keputusan dasar untuk didokumenkan

RevOps perlu mendokumenkan keputusan sukar:

• Bolehkah lead ditukar secara automatik kepada kenalan sedia ada?
• Bolehkah kenalan dengan e-mel berbeza digabungkan?
• Siapa meluluskan penggabungan akaun strategik?
• Sistem mana yang menang untuk status pelanggan?
• Bagaimana anak syarikat dikendalikan?
• Adakah akaun serantau rekod berasingan atau akaun anak?
• Apa berlaku kepada sejarah sumber selepas penggabungan?
• Siapa menyemak kesilapan penggabungan?
• Medan mana yang memerlukan kelulusan perniagaan sebelum ditimpa?

Keputusan ini menghalang setiap sprint pembersihan daripada bermula semula.

Peranan tadbir urus pendua

Pengurusan pendua memerlukan peranan yang jelas.

RevOps perlu memiliki dasar pendua, ambang padanan, aliran kerja penggabungan, dan kad skor. Pengurus jualan perlu memutuskan konflik pemilikan yang tidak jelas. Marketing ops perlu menyemak sumber lead dan sejarah kempen sebelum penggabungan yang menjejaskan atribusi. Kejayaan pelanggan perlu menyemak akaun pelanggan aktif sebelum penggabungan akaun. Kewangan perlu menyemak rekod pelanggan dan pengebilan apabila data langganan atau invois terlibat.

Pentadbir sistem tidak sepatutnya dipaksa membuat setiap keputusan perniagaan bersendirian. Pentadbir boleh menggabungkan rekod. Mereka tidak selalu dapat memutuskan sejarah pelanggan, pemilik, atau nilai sumber mana yang patut bertahan.

Jejak audit penggabungan

Penggabungan berisiko tinggi perlu meninggalkan jejak audit.

Tangkap:

• Rekod yang digabungkan
• Pelulus
• Sebab
• Pemilik yang bertahan
• Keputusan kelangsungan medan
• Pemuliharaan sumber
• Tarikh
• Sebarang isu hiliran

Ini bukan kerja kertas semata-mata. Apabila penggabungan mencipta isu pelaporan, RevOps perlu tahu apa yang berubah dan mengapa.

Kesilapan biasa pengurusan pendua

Menggabungkan secara automatik terlalu agresif. Pembersihan pantas boleh memusnahkan konteks.

Mengabaikan sistem sumber. Pendua terus kembali daripada import atau integrasi.

Tiada peraturan kelangsungan medan. Keputusan penggabungan menjadi tidak konsisten.

Melayan semua pendua secara sama rata. Akaun strategik pendua tidak sama dengan lead webinar pendua.

Membersihkan tanpa pencegahan. Isu yang sama berulang bulan depan.

Tiada pemilik untuk pendua tidak jelas. Rekod berisiko terus tidak diselesaikan kerana tiada siapa dapat memutuskan.

Memaksa hierarki ke dalam keputusan penggabungan. Entiti induk, anak, anak syarikat, rakan kongsi, dan pengebilan mungkin memerlukan hubungan, bukan satu rekod.

Mengukur hanya volum penggabungan. Kiraan penggabungan yang tinggi boleh menyembunyikan hakikat bahawa penciptaan pendua masih meningkat.

Rupa yang baik

Pengurusan pendua yang baik menjadikan CRM lebih tenang.

Wakil jualan melihat satu akaun. Pengurus memeriksa satu pipeline. Pengaruh pemasaran digulung kepada rekod yang betul. Kejayaan pelanggan mendapat sejarah penuh. Kewangan tidak menyesuaikan nama pelanggan pendua. Automasi bertindak daripada konteks yang betul.

Pelanggan tidak perlu menjelaskan hubungan yang sama dua kali.

Pengurusan pendua yang baik juga mencipta lebih sedikit pengecualian dari semasa ke semasa. Baki tertunggak pendua mengecil, tetapi lebih penting lagi, kadar penciptaan pendua menurun. Itu bermaksud penangkapan, import, padanan, hierarki, dan pemilikan sistem bertambah baik bersama-sama.

Model kematangan pengurusan pendua

Kebanyakan pasukan boleh beralih daripada pembersihan kepada pencegahan dengan mengawal import, penukaran lead, dan penciptaan akaun. Beralih kepada tadbir urus identiti mengambil masa lebih lama kerana ia memerlukan penjajaran merentasi CRM, automasi pemasaran, pengebilan, kejayaan pelanggan, dan BI.

Pakej penyelesaian pendua

Pembersihan pendua perlu ditadbir urus, bukan dikendalikan sebagai kerja pentadbiran rawak.

Bagi setiap kategori pendua, tentukan:

• Peraturan padanan.
• Ambang keyakinan.
• Medan yang menentukan rekod yang bertahan.
• Medan yang tidak sepatutnya ditimpa secara automatik.
• Pemilik untuk semakan.
• Peraturan kelulusan penggabungan.
• Keperluan log audit.
• Laluan rollback.

Ini melindungi sejarah akaun, atribusi, pemilikan, dan data ramalan sambil tetap mengurangkan bunyi bising pendua.

Soalan Lazim

Siapa yang memiliki pengurusan pendua?

RevOps perlu memiliki dasar dan irama operasi. Pentadbir sistem mengekalkan peraturan padanan. Jualan, pemasaran, kejayaan pelanggan, dan kewangan perlu memiliki keputusan tidak jelas dalam kawasan mereka apabila konteks perniagaan penting.

Mengapa pendua begitu merosakkan?

Pendua memecahkan konteks. Sebaik sahaja konteks berpecah, setiap aliran kerja yang menggunakan rekod itu menjadi kurang boleh dipercayai: penghalaan, pemarkahan, pelaporan, ramalan, serah tugas, pembaharuan, dan komunikasi pelanggan.

Patutkah pendua sentiasa digabungkan secara automatik?

Ya, tetapi hanya apabila keyakinan tinggi dan risiko perniagaan rendah. Padanan orang yang tepat dengan e-mel disahkan mungkin selamat dalam banyak sistem. Akaun strategik, pelanggan aktif, peluang terbuka, rekod pengebilan, dan data kebenaran biasanya memerlukan semakan.

Apakah metrik pendua terbaik?

Jejak kadar penciptaan pendua baharu mengikut sumber. Volum penggabungan memberitahu anda berapa banyak pembersihan berlaku. Kadar penciptaan memberitahu anda sama ada sistem itu semakin sihat.

Ketahui lebih lanjut

• Medan Wajib Berbanding Medan Berguna
• Kamus Data Hasil
• Audit Proses Hasil
• Metrik RevOps