Automasi Aliran Kerja: 10 Automasi yang Setiap CRM Perlu Ada pada Hari Pertama

Automasi Aliran Kerja: 10 Automasi yang Setiap CRM Perlu Ada pada Hari Pertama

Turn this article into takeaways for your work.

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

Sebuah pasukan jualan dalaman yang terdiri daripada 12 wakil menambah 10 automasi ini kepada HubSpot CRM mereka dalam tempoh dua minggu. Sebelum automasi, wakil mereka purata 45 minit sehari untuk kerja admin: menghalakan lead masuk secara manual, mencipta tugas susulan selepas demo, mengemas kini pemilik urusan selepas perubahan wilayah, dan merekodkan peralihan tarikh penutupan. Selepas itu: 23 minit sehari. Itu bermakna 22 jam seminggu merentasi pasukan dibebaskan untuk kerja jualan yang sebenar. Penyelidikan McKinsey tentang automasi jualan mendapati bahawa kira-kira 30% tugas jualan boleh diautomasikan dengan teknologi sedia ada, dengan kesan tertinggi dalam penghalaan lead, penjadualan susulan, dan kebersihan pipeline. Untuk konteks tentang kos keupayaan automasi yang sama merentasi platform, baca TCO sebenar sesebuah CRM.

Pengiraannya tidak rumit. Masalahnya, kebanyakan pasukan mengautomasikan tiga perkara (penugasan lead, penciptaan urusan, dan e-mel alu-aluan) dan kemudian menganggap mereka sudah melaksanakan automasi. Panduan ini merangkumi 10 automasi yang benar-benar membawa perubahan.

Cara Berfikir tentang Automasi CRM

Setiap automasi CRM mempunyai tiga bahagian yang sama:

Pencetus: Peristiwa atau keadaan yang memulakan automasi. Kenalan baharu dicipta. Peringkat urusan berubah. Nilai medan dikemas kini. Tarikh tertentu dicapai.

Syarat: Penapis pilihan yang mengecilkan bila automasi dijalankan. "Hanya jika sumber lead = Web Masuk." "Hanya jika nilai urusan > $5,000." "Hanya jika syarikat mempunyai lebih daripada 50 pekerja."

Tindakan: Apa yang berlaku. Mencipta tugas. Menghantar pemberitahuan. Mengemas kini medan. Mendaftarkan dalam urutan. Memutarkan kepada wakil.

Tetapkan pencetus dan syarat dengan betul sebelum bimbang tentang tindakan. Kebanyakan automasi yang rosak bukan rosak kerana tindakannya salah. Ia rosak kerana pencetus beroperasi terlalu meluas (semuanya ditandakan) atau syarat terlalu longgar (rekod yang salah terjejas).

Dalam HubSpot, ini dibina dalam Workflow (Automasi → Workflow). Dalam Salesforce, ia dibina dalam Flow Builder. Dokumentasi Flow Builder Salesforce ialah rujukan kanonik untuk membina automasi yang dipicu rekod. Dalam Pipedrive, ia terletak di bawah Automasi. Logiknya sama; antara muka penggunanya berbeza.


Automasi 1: Penugasan Lead mengikut Wilayah atau Round-Robin

Pencetus: Kenalan baharu dicipta dengan Status Lead = "Baharu" Syarat: Sumber Lead tidak kosong (kecualikan kenalan yang dicipta secara manual tanpa sumber) Tindakan: Tugaskan Pemilik Kenalan berdasarkan wilayah (medan negeri/rantau) atau putarkan melalui senarai wakil

Automasi ini menghapuskan barisan penghalaan lead secara manual. Tanpanya, seseorang (biasanya pengurus atau ketua SDR) menyemak barisan lead dan menyeret nama kepada wakil. Orang itu menjadi hambatan. Mereka juga tidak konsisten. Bagi pasukan yang membina proses lead yang lebih lengkap, panduan automasi penghalaan lead merangkumi logik penghalaan sepenuhnya, termasuk model berasaskan wilayah, berasaskan akaun, dan round-robin.

Persediaan dalam HubSpot: Gunakan tindakan workflow "Rotate record to owner" untuk round-robin, atau tambah cabang mengikut nilai medan wilayah untuk menugaskan wakil tertentu kepada rantau tertentu.

Persediaan dalam Salesforce: Gunakan Assignment Rules (Lead Assignment Rules di bawah Setup). Cipta entri peraturan mengikut kriteria wilayah/industri/saiz dengan wakil atau queue tertentu sebagai penerima tugasan. Modul pengurusan lead Salesforce Trailhead merangkumi konfigurasi lengkap peraturan penugasan.

Persediaan dalam Pipedrive: Di bawah Automasi → cipta workflow yang dipicu oleh "Deal created" atau "Lead added" dengan tindakan menugaskan kepada pemilik berdasarkan kriteria penapis.

Satu syarat penting: hanya jalankan ini untuk lead yang sumbernya telah diisi. Kenalan yang dicipta oleh admin atau melalui import selalunya tidak perlu dihalakan.


Automasi 2: Penciptaan Urusan daripada Kenalan yang Layak

Pencetus: Sifat kenalan "Status Lead" berubah kepada "Layak" (atau nama peringkat setara anda) Syarat: Tiada urusan terbuka yang sudah dikaitkan dengan kenalan ini Tindakan: Cipta rekod Urusan, kaitkan dengan kenalan dan syarikat mereka, tetapkan Pemilik Urusan = Pemilik Kenalan, tetapkan Peringkat Pipeline = peringkat aktif pertama

Automasi ini menukar aliran kerja lead anda kepada aliran kerja pipeline tanpa memerlukan wakil mencipta urusan secara manual. Syarat yang mencegah urusan pendua ("tiada urusan terbuka yang sudah dikaitkan") adalah penting. Tanpanya, anda akan mencipta urusan pendua setiap kali status lead dikemas kini.

Dalam HubSpot, gunakan tindakan workflow "Create record" → Deal, kemudian gunakan "Associate record" untuk memaut kenalan dan syarikat. Tetapkan formula nama urusan supaya mengambil daripada nama syarikat kenalan atau gabungan beberapa medan. Dokumentasi workflow HubSpot menerangkan persediaan tindakan penciptaan rekod secara menyeluruh.

Dalam Salesforce, ini dilakukan melalui Flow atau proses yang mencipta Opportunity apabila Lead ditukar.


Automasi 3: Penciptaan Tugas Berasaskan Peringkat

Pencetus: Peringkat pipeline urusan berubah kepada peringkat tertentu Syarat: Tiada yang diperlukan (atau jenis urusan = "Perniagaan Baharu" jika anda mahu mengecualikan pembaharuan) Tindakan: Cipta tugas untuk pemilik urusan dengan arahan khusus dan tarikh akhir

Apabila urusan memasuki "Penemuan Selesai," tindakan wakil seterusnya sepatutnya jelas: hantar agenda untuk panggilan susulan, atau jadualkan semakan teknikal. Penciptaan tugas berasaskan peringkat bermakna wakil tidak perlu mengingati apa yang perlu dilakukan seterusnya. CRM memberitahu mereka. Automasi ini hanya berfungsi dengan baik apabila peringkat pipeline anda dibina berdasarkan pencapaian pembeli dan bukan aktiviti wakil: jika peringkat tidak jelas, tugas yang dicipta apabila peringkat berubah juga menjadi tidak jelas.

Bina satu workflow tugas bagi setiap peralihan peringkat yang mempunyai tindakan seterusnya yang jelas dan konsisten. Jangan cipta tugas untuk setiap peringkat. Cipta hanya untuk peringkat yang langkah seterusnya sama tanpa mengira butiran urusan.

Contoh tugas mengikut peringkat:

  • Penemuan Selesai → Tugas: "Hantar ringkasan penemuan dan jadualkan demo penyelesaian" (tarikh akhir dalam 24 jam)
  • Demo Selesai → Tugas: "Hantar e-mel susulan dengan dokumentasi kes penggunaan dan gambaran keseluruhan harga" (tarikh akhir dalam 48 jam)
  • Cadangan Diterima → Tugas: "Jadualkan panggilan semakan kontrak dan hantar MSA kepada pasukan perundangan" (tarikh akhir dalam 72 jam)

Dalam HubSpot: tindakan workflow "Create task" → tugaskan kepada pemilik urusan, tetapkan tarikh akhir relatif, tambah keterangan tugas beserta arahan. Dalam Salesforce: tindakan Flow "Create Task" dengan ActivityDate ditetapkan sebagai formula.


Automasi 4: Amaran Urusan Tertangguh

Pencetus: "Tarikh Aktiviti Terakhir" urusan lebih daripada X hari yang lalu DAN peringkat pipeline bukan Closed Won atau Closed Lost Syarat: Urusan berada dalam peringkat aktif (kecualikan Closed Won/Lost secara eksplisit) Tindakan: Cipta tugas untuk pemilik urusan yang ditandakan sebagai keutamaan tinggi: "Tiada aktiviti dalam X hari. Urusan mungkin terhenti."

Tanpa automasi ini, urusan yang terhenti duduk diam dalam pipeline dan mengembungkan ramalan anda. Pengurus menemuinya dalam semakan urusan dan terpaksa menegur wakil secara manual. Automasi ini mengetengahkan masalah sebelum ia menjadi kejutan pipeline.

Ambang X bergantung pada tempoh kitaran anda. Untuk kitaran SMB 30 hari, tandakan pada 5 hari tanpa aktiviti. Untuk kitaran perusahaan 90 hari, tandakan pada 14 hari.

Dalam HubSpot: gunakan workflow "Deal-based" yang dipicu mengikut jadual tetap (harian), ditapis mengikut tarikh aktiviti terakhir yang lebih daripada X hari lalu. Ini ialah penapis julat tarikh, bukan pencetus peristiwa.

Dalam Salesforce: bina Flow berjadual yang berjalan setiap hari dan membuat pertanyaan terhadap Opportunity yang memenuhi kriteria, kemudian mencipta Task.


Automasi 5: Peringatan Susulan Selepas Demo

Pencetus: Peringkat pipeline urusan berubah kepada "Demo Selesai" (atau setara anda) Syarat: Tiada Tindakan: Cipta tugas untuk pemilik urusan dengan tarikh akhir 24 jam selepas perubahan peringkat: "Susulan selepas demo: ringkaskan liputan kes penggunaan, sahkan langkah seterusnya, hantar kajian kes yang berkaitan"

Susulan 24 jam selepas demo ialah salah satu tindakan dengan leverage tertinggi dalam jualan B2B. Pembeli paling terlibat dalam tempoh 24 jam selepas melihat sesuatu penyelesaian. Kajian Harvard Business Review tentang tindak balas jualan mendapati bahawa wakil yang menindaklanjuti dalam masa sejam selepas interaksi pembeli adalah 7x lebih berkemungkinan melayakkan lead tersebut berbanding mereka yang menunggu walaupun beberapa jam. Wakil yang menindaklanjuti dalam tetingkap itu menukar pada kadar yang lebih tinggi. Namun peringatan susulan manual mudah dilupakan.

Automasi ini memastikan tiada demo dibiarkan tanpa susulan tanpa tugas dicipta. Ia mudah, bersasaran, dan ROI-nya langsung.


Automasi 6: Penglibatan Semula Lead Selepas 30 Hari Sejuk

Pencetus: Sifat kenalan "Status Lead" = "Terbuka" DAN "Tarikh Aktiviti Terakhir" lebih daripada 30 hari yang lalu Syarat: Kenalan tidak didaftarkan dalam mana-mana urutan aktif Tindakan: Daftarkan kenalan dalam urutan e-mel "penglibatan semula" (3-4 e-mel dalam tempoh 2 minggu)

Jika lead anda masuk melalui pelbagai saluran, elok anda membaca panduan menyingkirkan lead multisaluran yang berpendua sebelum membina automasi ini. Urutan penglibatan semula boleh dijalankan dua kali pada orang yang sama jika kenalan pendua wujud merentasi saluran.

Lead yang senyap tidak semestinya sudah mati. Selalunya mereka hanya kehilangan keutamaan. Urutan penglibatan semula yang ringan (bukan promosi jualan yang berat, tetapi lebih kepada pendekatan "masih memikirkan tentang X?") boleh mengaktifkan semula peratusan kenalan sejuk yang bermakna.

Dalam HubSpot: gunakan pencetus pendaftaran dalam workflow berasaskan kenalan. Tambah syarat untuk menyemak sama ada kenalan sedang berada dalam urutan aktif sebelum mendaftarkan. Anda tidak mahu pendaftaran berganda.

Dalam Salesforce: picu pendaftaran Cadence (Sales Engagement) melalui Flow, dengan semakan keahlian cadence semasa terlebih dahulu.

Dalam Pipedrive: gunakan automasi untuk mencipta aktiviti susulan dan menandakan wakil, kemudian gunakan alat e-mel yang disambungkan untuk urutan itu sendiri.


Automasi 7: Pemberitahuan Urusan Baharu kepada Slack atau Teams

Pencetus: Urusan baharu dicipta DAN peringkat pipeline = peringkat aktif pertama Syarat: Nilai urusan melebihi ambang (pilihan: hanya beritahu untuk urusan melebihi $5k, sebagai contoh) Tindakan: Hantar mesej Slack atau Teams ke saluran yang ditetapkan dengan butiran urusan: nama urusan, syarikat, nilai, pemilik

Inilah automasi yang memenangi sokongan wakil terhadap keseluruhan sistem. Wakil suka melihat urusan baharu mereka diumumkan dalam Slack. Pengurus menyukainya kerana ia menunjukkan pipeline sedang hidup. Dan ia mencipta gelung pengukuhan positif yang kecil: urusan baharu = sambutan dalam saluran.

Dalam HubSpot: gunakan integrasi Slack dalam Workflow. Tindakannya ialah "Send Slack message" dengan sifat urusan digabungkan.

Dalam Salesforce: integrasi Salesforce → Slack atau Flow yang memanggil webhook Slack.

Pastikan mesej ringkas: "Urusan baharu: [Nama Syarikat] - [Nilai Urusan] - Pemilik: [Nama Wakil]." Elakkan teks panjang yang diabaikan orang.


Automasi 8: Amaran Tarikh Penutupan Ditolak

Pencetus: Sifat urusan "Tarikh Penutupan" dikemas kini Syarat: Urusan sebelum ini ditetapkan untuk ditutup bulan ini ATAU tarikh penutupan telah dialihkan lebih daripada dua kali (memerlukan medan "bilangan perubahan tarikh penutupan" yang bertambah) Tindakan: Beritahu pengurus pemilik urusan melalui Slack atau e-mel: "Tarikh penutupan ditolak pada [Nama Urusan]. Tarikh baharu: [Tarikh]. Pemilik: [Wakil]."

Peralihan tarikh penutupan ialah petunjuk awal masalah ramalan. Satu kali ditolak adalah normal. Dua kali sudah menjadi corak. Tiga kali bermakna urusan itu mungkin langsung tidak ditutup suku ini. Ini berkait rapat dengan budaya kebersihan pipeline. Automasi menangkap simptomnya, tetapi budayalah yang menentukan sama ada pengurus benar-benar bertindak.

Membina medan "bilangan perubahan tarikh penutupan" memerlukan satu automasi tambahan: apabila tarikh penutupan berubah, tambahkan medan pembilang sebanyak 1. Kemudian automasi amaran menyemak sama ada pembilang itu melebihi 2.

Dalam HubSpot: dua workflow. Pertama: picu pada perubahan Close Date, tindakan "Increment number property" pada medan tersuai "Close Date Changes." Kedua: picu apabila medan itu melebihi 2, tindakan "Notify rep manager."

Ini antara automasi yang lebih bernilai untuk pengurus jualan. Ia mengetengahkan urusan yang ditolak secara sistematik tanpa memerlukan soal siasat mingguan terhadap setiap wakil.


Automasi 9: Penandaan Urusan Hilang dan Sebab Hilang Diwajibkan

Pencetus: Peringkat pipeline urusan berubah kepada "Closed Lost" Syarat: Medan "Sebab Hilang" kosong Tindakan: Hantar tugas kepada wakil: "Urusan ditutup hilang. Sila dokumentasikan sebab hilang sebelum menutup tugas ini." Halang kemajuan peringkat sehingga medan diisi (melalui medan wajib pada perubahan peringkat dalam HubSpot, atau peraturan pengesahan dalam Salesforce).

Data sebab hilang antara input paling berharga untuk menambah baik proses jualan anda. Dan ia secara konsisten paling kurang ditangkap. Wakil menutup urusan sebagai hilang dan terus bergerak. Tiada siapa yang mendokumentasikan sebabnya.

Automasi ini tidak menyelesaikan masalah sepenuhnya, tetapi ia mewujudkan geseran pada saat yang tepat. Wakil sedang berada dalam rekod urusan untuk menandakannya hilang. Tugas muncul serta-merta meminta sebab hilang. Kebanyakan wakil akan mengisinya.

Versi penguatkuasaan ketat: dalam HubSpot, konfigurasikan peringkat pipeline untuk mewajibkan medan Lost Reason sebelum membenarkan urusan bergerak ke Closed Lost. Dalam Salesforce, gunakan peraturan pengesahan yang menghalang penyimpanan Opportunity sebagai Closed Lost tanpa medan Close Reason diisi.


Automasi 10: Serah Terima Onboarding kepada Customer Success

Pencetus: Peringkat pipeline urusan berubah kepada "Closed Won" Syarat: Jenis urusan = "Perniagaan Baharu" (langkau pembaharuan atau pengembangan) Tindakan: Cipta rekod Onboarding baharu (atau tugas dalam platform CS anda), tugaskan kepada wakil CS yang sesuai berdasarkan wilayah atau saiz akaun, beritahu saluran CS dalam Slack, dan kemas kini Urusan dengan pemilik CS

Automasi ini ialah jambatan antara jualan dan CS. Tanpanya, urusan yang ditutup terperangkap dalam limbo CRM sementara pengurus jualan menghantar e-mel kepada CS secara manual untuk berkata "kami menang yang ini." Dengannya, serah terima berlaku secara automatik, segera, dan didokumentasikan.

Agar ini berfungsi dengan baik, anda memerlukan: peraturan wilayah atau penugasan CS (logik yang sama seperti penghalaan lead), saluran Slack atau sistem berasaskan tugas untuk CS menerima akaun baharu, dan struktur rekod serah terima yang jelas (apakah maklumat yang CS perlukan pada hari pertama?).

Dalam HubSpot: cipta workflow yang dipicu pada Closed Won yang mencipta Ticket atau rekod objek tersuai untuk onboarding, menugaskannya kepada medan carian pemilik CS, dan menghantar pemberitahuan Slack ke saluran pasukan CS.

Dalam Salesforce: Flow yang mencipta Case atau objek Onboarding tersuai, mengisi medan akaun utama, dan menugaskan kepada queue CS.


Perangkap Biasa

Automasi yang beroperasi terlalu meluas. Jika automasi penugasan lead anda dijalankan pada setiap kenalan yang pernah dicipta (bukan hanya lead masuk yang baharu), anda akan mula menugaskan semula kenalan sedia ada di tengah-tengah urusan yang aktif. Sentiasa tambah syarat yang mengehadkan automasi kepada rekod yang betul.

Lebihan pemberitahuan. Penyelidikan Deloitte Insights tentang produktiviti tempat kerja digital menunjukkan bahawa keletihan pemberitahuan merupakan antara punca utama ketidakterlibatan teknologi dalam pasukan jualan. Jika anda membina 10 automasi yang semuanya menghantar mesej Slack, wakil akan berhenti membaca Slack. Simpan pemberitahuan untuk tindakan yang memerlukan respons manusia dalam masa beberapa jam. Tugas lebih sesuai untuk perkara yang memerlukan respons dalam masa sehari. E-mel lebih sesuai untuk perkara yang memerlukan dokumentasi.

Automasi yang tiada siapa matikan selepas percubaan. Apabila anda menjalankan pasukan perintis sebelum pelancaran penuh, anda akan membina automasi ujian. Dokumentasikan setiap automasi yang anda cipta. Sebelum pelancaran penuh, audit senarai automasi dan nyahaktifkan apa-apa yang merupakan ujian. Automasi yatim berjalan pada masa yang tidak dijangka dan menyebabkan masalah kualiti data.

Membina kerumitan sebelum mengesahkan pencetus. Uji setiap automasi dengan satu rekod sebelum mengaktifkannya untuk seluruh pangkalan data. Sejarah pendaftaran HubSpot dan log nyahpepijat Salesforce membantu anda mengesahkan bahawa pencetus berjalan dengan betul dan tindakan dilaksanakan seperti yang dijangka.

Apa yang Perlu Dilakukan Seterusnya

Selepas membina automasi ini, audit log automasi setiap minggu selama 30 hari pertama. Sejarah pendaftaran Workflow HubSpot dan log nyahpepijat Salesforce menunjukkan rekod mana yang mencetuskan automasi mana dan sama ada tindakan dilaksanakan. Anda mencari pendaftaran yang tidak dijangka, tindakan yang dijalankan pada rekod yang salah, dan pemberitahuan yang tiada siapa mengakuinya.

Selepas 30 hari, anda akan mempunyai data yang cukup untuk menala syarat, melaraskan ambang, dan mengesahkan automasi mana yang menghasilkan perubahan tingkah laku yang anda inginkan.

Langkah utama seterusnya ialah pelancaran kepada seluruh pasukan. Lihat panduan pelancaran dan penerimaan CRM tentang cara beralih daripada CRM yang telah dikonfigurasi kepada CRM yang benar-benar digunakan oleh seluruh pasukan anda.

Ketahui Lebih Lanjut

About the author

Calvin D.

Calvin D.

Head of Enterprise Solutions

Calvin D. is Head of Enterprise Solutions at Rework, writing for sales directors and CROs. Calvin covers how B2B companies choose and implement software, buy SaaS, migrate data, and run the sales process, plus deal closing and pipeline management, with a focus on decisions that still hold up as the sales organization grows.