Zoho CRM atau Sistem Kustom? Cara Memilih antara Membeli dan Membangun

Pilihannya lebih luas daripada membeli CRM atau menulis keseluruhan sistem. Sebuah bisnis dapat mengonfigurasi Zoho CRM, membuat aplikasi khusus, atau menggunakan CRM untuk pekerjaan penjualan dan aplikasi terpisah untuk operasi khusus. Batasan yang tepat bergantung pada catatan, keputusan, dan pengguna yang terlibat.

Mulailah dengan daftar alur kerja penting. Pisahkan tugas penjualan konvensional, seperti manajemen kontak dan tindak lanjut proposal, dari pekerjaan khusus seperti inspeksi peralatan atau penghitungan layanan yang rumit. Kemudian tanyakan apakah persyaratan yang tidak biasa tersebut penting bagi bisnis atau merupakan pengecualian yang dapat ditangani dengan lebih sederhana.

Evaluasi juga siapa yang akan mengelola sistem setelah mulai digunakan. Sistem yang memenuhi kebutuhan formulir saat ini tetapi bergantung pada satu pengembang yang sulit dihubungi untuk setiap perubahan memiliki risiko berbeda dari konfigurasi yang dapat dipelihara administrator Anda.

Kemampuan Zoho CRM yang dipublikasikan mencakup prospek, transaksi, aktivitas, pelaporan, dan penyesuaian. Ini memberikan titik awal untuk pekerjaan penjualan konvensional. Bisnis masih harus menentukan tahapan, tanggung jawab, izin, dan laporan.

Selidiki konfigurasi ketika masalah utama tim Anda adalah tidak adanya tindak lanjut, catatan yang tidak konsisten, atau visibilitas yang buruk di seluruh jalur penjualan. Aplikasi kustom baru dapat menimbulkan masalah yang sama jika tidak ada yang sepakat bagaimana penjualan harus beroperasi.

Uji pengecualian sebelum memutuskan bahwa konfigurasi sudah cukup. Bisakah Anda mempertahankan revisi proposal, mengelola beberapa peluang untuk satu pelanggan, dan membatasi akses berdasarkan peran? Periksa edisi yang dipilih dan upaya administrasi yang diperlukan. Kumpulan skrip yang banyak dapat mengubah profil pemeliharaan dari apa yang awalnya tampak seperti pengaturan standar.

Operasi khusus mungkin memiliki catatan dan siklus hidupnya sendiri. Inspeksi lokasi, misalnya, dapat melibatkan aset, lokasi, foto, temuan, dan tindakan tindak lanjut. Memasukkan semua hal tersebut ke dalam peluang penjualan dapat membuat CRM lebih sulit untuk dipahami.

Zoho Creator menyediakan alat untuk membangun formulir, alur kerja, laporan, dan aplikasi. Platform ini dapat dipertimbangkan untuk kebutuhan tersebut, tetapi pengembangan low-code tetap memerlukan perancangan, pengujian, pengaturan hak akses, dan pemeliharaan. Aplikasi yang cepat dibuat belum tentu siap digunakan dalam bisnis.

Jelaskan setiap jenis data operasional sesuai prosesnya. Siapa yang membuatnya? Informasi apa yang wajib lengkap? Apakah data boleh diubah setelah disetujui? Informasi apa yang perlu dilihat tim yang berhubungan dengan pelanggan? Jawabannya membantu menentukan kebutuhan aplikasi terpisah dan data yang perlu dipertukarkan dengan CRM.

Pertimbangkan bisnis layanan lapangan. Contoh hipotetis ini menunjukkan salah satu cara membagi pekerjaan dan bukan proyek yang telah diterapkan untuk klien. Tim penjualan memakai CRM untuk mengelola pelanggan, proposal, dan pekerjaan yang disepakati. Teknisi memerlukan tampilan berbeda: kunjungan yang ditugaskan, peralatan yang diperiksa, bukti dari lokasi, dan pekerjaan yang belum selesai.

Desain yang mungkin menyimpan catatan penjualan di CRM dan catatan inspeksi di aplikasi Creator. Serah terima yang disepakati membuat atau menghubungkan pekerjaan operasional menggunakan pengidentifikasi yang stabil. Aplikasi ini hanya mengembalikan status dan informasi yang dibutuhkan oleh tim penjualan atau manajemen akun.

Sebelum rancangan digunakan, tentukan siapa yang mengubah jadwal kunjungan dan apa yang terjadi jika pelanggan membatalkan setelah teknisi mulai bekerja. Sistem mana yang menjadi sumber utama alamat kontak? Bagaimana kegagalan pembaruan dideteksi dan dicoba ulang tanpa membuat pekerjaan duplikat?

Gunakan pertanyaan-pertanyaan itu untuk menguji batasannya. Jika setiap perubahan operasional memerlukan rekonsiliasi manual antara dua sistem, desain integrasi mungkin perlu disederhanakan. Jika bisnis dapat memenuhi kebutuhannya dalam satu aplikasi, mungkin tidak ada alasan untuk memperkenalkan aplikasi kedua.

Perbandingan ini menjelaskan tanggung jawab, bukan peringkat biaya tetap. Kompleksitas dapat membuat pendekatan apa pun menjadi mahal. Sistem kustom mungkin dapat dibenarkan, namun kasus tersebut harus menjelaskan mengapa persyaratan tersebut tidak dapat dipenuhi melalui konfigurasi, perluasan, atau perubahan pada proses.

Untuk setiap informasi yang dibagikan, tentukan sistem yang menjadi acuan dan pihak yang boleh mengubahnya. Gunakan ID data yang tetap, karena nama dan alamat email dapat berubah atau sama dengan data lain. Sepakati penanganan data yang dihapus, digabungkan, atau dikoreksi.

Tentukan peristiwa yang memicu pertukaran dan waktu yang diperlukan. Pembaruan pelaporan harian memiliki kebutuhan yang berbeda dari pekerjaan yang harus terlihat sebelum teknisi berangkat berkunjung. Nyatakan bagaimana pengguna akan mengenali pembaruan yang tertunda dan di mana kegagalan akan ditinjau.

Uji duplikat dan coba ulang. Jika koneksi gagal setelah membuat catatan tetapi sebelum menerima konfirmasi, percobaan ulang tidak boleh membuat salinan lain secara diam-diam. Sertakan perilaku tersebut dalam tes penerimaan dan tugaskan seseorang untuk menjaga koneksi setelah go-live.

Dalam kasus operasi akuntansi kami memublikasikan contoh penggunaan informasi Creator, CRM, dan sistem akuntansi untuk mendukung pekerjaan lintas entitas bisnis. Arsitektur untuk perusahaan lain tetap memerlukan rancangan tersendiri.

Perkirakan biaya menjalankan dan mengubah sistem, bukan hanya pembangunan awal. Sertakan langganan, lingkungan, layanan integrasi, waktu administrator, dokumentasi dan dukungan. Sepakati perubahan mana yang dapat dilakukan oleh administrator bisnis dan mana yang memerlukan pengembangan.

Tentukan cara menguji pembaruan sebelum digunakan pengguna. Perubahan kecil pada kolom wajib dapat memengaruhi formulir, impor, laporan, dan integrasi. Identifikasi komponen yang terdampak dan catat keputusan agar penerus tidak perlu menyimpulkan rancangan hanya dari kode.

Uji juga rencana peralihan saat kerja sama berakhir. Pastikan organisasi dapat mengekspor data yang diperlukan, menyimpan kode dan dokumentasi sesuai kesepakatan, serta memberi akses kepada administrator pengganti. Hal ini perlu direncanakan meskipun Anda mengharapkan kerja sama jangka panjang dengan tim implementasi awal.

Sebelum memilih suatu pendekatan, tulislah catatan keputusan singkat. Nyatakan alur kerja, alternatif yang dipertimbangkan dan alasan pilihan yang dipilih. Sertakan asumsi yang dapat mengubah keputusan, seperti volume transaksi, konektivitas lapangan, atau persyaratan persetujuan baru.

• Sebutkan persyaratan yang harus ditunjukkan, termasuk pengecualian.
• Pisahkan konfigurasi dari kode khusus dan pisahkan keduanya dari pekerjaan integrasi.
• Tetapkan penanggung jawab setiap sistem dan definisi data bersama.
• Sepakati cara menguji dan menerima pendekatan yang diusulkan.
• Identifikasi apa yang dapat ditunda tanpa mencegah rilis pertama berfungsi.

Dalam pekerjaan CRM dan Creator Zolution, pembahasan rancangan dimulai dari batas tersebut. Bawa contoh pekerjaan nyata dan sistem yang digunakan saat ini ke diskusi penentuan ruang lingkup; langkah selanjutnya adalah menguji persyaratan terhadap pendekatan paling sederhana yang bisa diterapkan.