tentang proyek tersebut
Produk klien adalah SaaS di bidang B2B, yang beroperasi dengan format biaya berlangganan. Pengguna mendaftar, melewati otorisasi, mengisi ulang akunnya dan menggunakan layanan.
Tugas kita adalah membantu klien "mengumpulkan" analitik. Untuk melakukan ini, perlu untuk membangun proses pusat panggilan, menerapkan CRM, dan "menyatukan" analitik ujung ke ujung dengan indikator kunci.
Struktur proses
Sebelum melakukan analitik, Anda perlu menyiapkan lanskap untuk mengumpulkannya: menyusun proses penjualan dan menyiapkan integrasi dengan layanan. Kami menemukan beberapa masalah dalam proses:
- Manajer terganggu oleh tahapan saluran penjualan yang tidak perlu, dan pekerjaan mereka tidak dipantau dengan cara apa pun;
- Laporan penjualan diunduh secara manual dari panel admin setiap hari;
- Ada beberapa peristiwa konversi untuk mengumpulkan analitik.
Selanjutnya dibuat peta dengan struktur interaksi semua sistem.
Ini menunjukkan logika apa yang harus diikuti oleh peristiwa dan pada tahap apa analis itu pergi. Kami mengambil data dasar dari CRM dan menghubungkannya dengan data tentang iklan dan konversi. Menyatukannya di myBI, menampilkannya di Power BI.
Corong penjualan
Penjualan pelanggan dilakukan di Enybox CRM, kami mentransfernya ke amoCRM untuk kemudahan integrasi. Kami berhasil mengumpulkan logika penjualan menjadi tiga corong.
Tiga corong berturut-turut Corong
pertama adalah konsultasi. Saya perlu membawa klien untuk mendaftar di platform. Corong kedua adalah memperbaiki pembayaran pertama. Kemudian pengguna mengonfirmasi pendaftarannya. Dan kami, pada gilirannya, merayakan saat pembayaran dan setiap pengisian baru.
Bagaimana analitik seharusnya bekerja
| "Peristiwa" awal | "Peristiwa" terakhir |
|---|---|
| Formulir umpan balik | Formulir umpan balik |
| Pendaftaran dalam layanan | Pendaftaran dalam layanan |
| Setoran pertama | |
| Pengujian (opsional dengan pengisian ulang kecil) | |
| Top-up berulang | |
| Penolakan untuk menggunakan (pemanasan melalui OP) |
Agar sistem analitik berfungsi normal, Anda perlu mengumpulkan semua peristiwa = menandai tindakan konversi. Peristiwa sudah memasuki sistem analitik, tetapi awalnya hanya ada dua jenis, yang tidak cukup untuk laporan.
Menampilkan data
Contoh dashboard
Setelah mengumpulkan data tentang konversi, perlu dibuat laporan dari mereka. Alat visualisasi data utama adalah Microsoft Power BI.
Pada saat konversi, ID terpisah dibuat di situs untuk menyinkronkan sistem periklanan dan CRM. Dengan ID ini, kami menghubungkan data pengeluaran dan pendapatan. Jadi kami menghubungkan data dan dapat membuat laporan di atasnya.
Unit ekonomi. Penyimpanan
Grafik retensi bergulir layanan dari 1 hingga 12 bulan
Retensi menunjukkan seberapa banyak pengguna terlibat dalam aplikasi dan seberapa sering mereka kembali ke aplikasi tersebut. Tetapi karena fakta bahwa layanan berfungsi dalam format pengisian ulang, saya harus mengubah indikator ini menjadi retensi bergulir. Ini menunjukkan sama seperti retensi, tetapi menyiratkan bahwa sepanjang waktu pengguna tidak mengisi akun, dia juga menggunakan layanan.
Konversi ke setoran pertama
Konversi tersebut sangat bergantung pada jumlah pelanggan baru dan awal pembayaran mereka. Selama 9 bulan pertama, kami menerima sekitar 430 pendaftaran baru dan 90 pembayaran dari pengguna baru setiap bulan. Konversi ke pembelian di bulan pendaftaran adalah 20%, menurut data selama 12 bulan.
Selain indikator standar
Anda dapat melihat analitik pada sentuhan klien baik pada saat transisi sederhana ke situs, dan pada saat pendaftaran dan pembayaran lebih lanjut. Kami mengumpulkan data untuk menemukan rantai konversi paling banyak:
Pengguna melihat iklan → pergi ke situs → setelah beberapa saat masuk dan melihat dalam konteks → terdaftar, tetapi tidak membayar → pemanasan dengan surat → menawarkan test drive → diuji → OP "menyerah" untuk pembayaran pertama → 3 tahun pembayaran yang stabil.
Ada yang salah
Pada awalnya, pemrakarsa proyek menunda mulai sampai musim gugur (mereka melamar di musim semi). "Kesenjangan" dalam pekerjaan seperti itu terjadi lebih dari satu kali. Tapi kami tidak memikirkannya dan menerima begitu saja. Masalah utama adalah komunikasi dan birokrasi dalam proses klien kami. Ini adalah bagaimana Anda dapat menggambarkan seluruh periode waktu pengerjaan sebuah proyek:
Perkembangan lambat
Kesenjangan dalam pengembangan disebabkan oleh struktur pekerjaan klien. Kami bekerja sama dengan tim klien dan beberapa tugas hanya dapat dilakukan di pihaknya karena keamanan proses yang tinggi.
Kehilangan dua sprint - kalah sebulan
Semua manajer dan pengembang di pihak mereka bekerja dalam iterasi dua minggu. Tetapi mereka terus-menerus menempatkan proyek kami sebagai prioritas terakhir dan seringkali tugas kami tidak termasuk dalam "sprint".
Komunikasi yang buruk dan kurangnya keahlian
Selama proyek berlangsung, manajer klien (pemangku kepentingan) telah berubah lima kali. Mungkin semua orang tahu bahwa perasaan ketika proyek yang sedang Anda kerjakan tiba-tiba menjadi tidak menarik bagi klien. Tapi itu pun bisa diselesaikan.
Lebih sulit menghadapi inkompetensi pemangku kepentingan. Salah satunya adalah seorang eksekutif hebat yang mengetahui produknya dengan baik. Tetapi dia bahkan tidak memahami prinsip dasar membangun proses penjualan. Kami menghabiskan beberapa pertemuan untuk membujuknya menghapus panggung dengan status “Apa kabar?” Dari saluran penjualan.
Bayangkan sales funnel seperti gambar di atas. Pada salah satu tahap, manajer perlu mencari tahu "bagaimana kabar klien". Menurut Anda, apa yang akan terjadi pada analisis konversi corong ini?
Manajer akan mengetahui "apa kabar" dari klien alih-alih memindahkannya melalui corong, statusnya tidak sepele. Tidak jelas kapan harus mengatakannya: setelah kontak pertama atau setelah kualifikasi. Akibatnya, penawaran "melompat" bolak-balik sepanjang corong atau hanya berdiri, bukan gerakan berurutan.
Selama proses penjualan, tidak mungkin menetapkan tahapan perantara di mana transaksi akan diakumulasikan. Jika tidak, semua analitik akan menjadi berantakan, dan manajer akan kehilangan banyak kontak.
Fakapas dari sisi kami
Kami tidak memperhitungkan bandwidth sistem. Untuk satu acara platform di puncaknya, kami mengirim hingga 10 permintaan ke amoCRM untuk menjalankan logika proses bisnis.
100.000 peristiwa per hari * 10 permintaan ke amoCRM = 1.000.000 permintaan per hari
1.000.000 permintaan per hari / 10 permintaan per detik (batas AMO) = 100.000 detik = ± 27 jam
Hasil: sinkronisasi tidak akan pernah berakhir
Awalnya dipilih amoCRM, sebagai "melewati" batas permintaan ke sistem. Namun selama pengembangan proyek, persyaratan dan fungsi telah meningkat dan kami "menemui" batasnya.
Kami telah memilih alat yang salah. AmoCRM secara fisik tidak cocok untuk menangani sejumlah besar permintaan.Juga, kesalahannya adalah kami mengembangkan semuanya di GO, dan satu spesialis bertanggung jawab untuk ini. Ketika dia pergi, ada segunung kode warisan yang tidak bisa dimengerti oleh siapa pun. Tapi, sayangnya, atau untungnya, ini tidak perlu.
Semuanya bangkrut lagi
Kasus ini adalah contoh lain dari proyek yang telah terkubur dalam persetujuan dan tumpukan manajemen yang tidak perlu.
Kami kekurangan keahlian teknis. Kepada klien - stabilitas dalam manajemen dan keinginan untuk menyelesaikan proyek.
Tapi ini pengalaman. Berkat dia, sekarang tugas seperti itu terlihat sepele mungkin, dan kami telah mereproduksi solusi serupa di proyek lain.
Bagaimana kegagalan bisa dihindari
Agar tidak mengulangi kasus seperti itu di masa mendatang, kami telah menyoroti aspek-aspek yang harus diperhatikan saat bekerja dengan klien perusahaan.
- : ; . , .
- . — . — . . .
- . KPI — .
- Pikirkan ke depan. Bahkan saat mengembangkan MVP, Anda perlu melihat kemacetan yang mungkin muncul di masa mendatang. Proyek ini selalu berkembang dan penting untuk menyediakan struktur agar tidak menulis ulang semua kode dari awal.
Penulis artikel ini adalah Fyodor Anisimov, pemasar LAND PRO.