Jangan Membangun, Mengintegrasikan – Panduan untuk Integrasi CRM

Diterbitkan: 2022-03-11

Katakanlah Anda bekerja untuk startup yang menjual robot di semua industri. Anda menerima pesanan dari berbagai klien, dan tim operasi mengevaluasi pesanan dan bekerja dengan penyedia pihak ketiga untuk mendapatkan robot yang tepat bagi klien Anda.

Membangun MVP sangat menegangkan tetapi juga sangat menyenangkan. Investor Anda senang dan menghujani Anda dengan uang. Fase berikutnya dimulai. Anda membutuhkan lebih banyak visibilitas pada profitabilitas dan Anda ingin mendapatkan klien yang lebih besar yang membutuhkan faktur yang lebih canggih. Pada saat yang sama, Anda memiliki peta jalan produk yang cukup canggih untuk memungkinkan penjualan robot dengan margin lebih tinggi. Sumber daya langka, tetapi Anda masih perlu memastikan agar perusahaan tetap berjalan.

Seperti yang sering diberitakan untuk perusahaan kecil, berfokus pada hal-hal yang Anda kuasai adalah aturan praktis yang bagus. Tetapi bagaimana dengan semua area yang membuat operasi sehari-hari perusahaan Anda tetap berjalan? Anda tentu tidak ingin membangun sistem Customer Relationship Management (CRM) atau sistem akuntansi. Lagi pula, ada banyak produk di luar sana yang menyelesaikan semua masalah. Tetapi bagaimana sistem ini akan bekerja sama dengan sistem pesanan Anda yang sudah ada?

Di sinilah integrasi pihak ketiga berguna. Jadi, mari selami dan lihat apakah kita dapat menghindari beberapa perangkap umum.

Integrasi CRM

Baik Anda melakukan penjualan dengan sentuhan rendah (pemasaran konten, iklan media sosial, atau buletin) atau penjualan dengan sentuhan tinggi (panggilan dingin, menghadiri konferensi, atau menindaklanjuti klien yang ada melalui telepon), sistem CRM dapat memberi Anda banyak visibilitas tentang bagaimana Anda lakukan dengan klien yang ada dan seberapa sukses Anda dengan meyakinkan klien baru.

Seringkali, pemilihan sistem CRM sebagian besar diserahkan kepada departemen penjualan dan pemasaran. Secara umum, tidak ada yang salah dengan itu. Lagi pula, orang-orang ini paling tahu cara meningkatkan pendapatan dan membutuhkan dukungan terbaik yang tersedia. Tetapi bahkan perangkat lunak terbaik pun tidak ada artinya jika tidak bekerja dengan baik dengan sistem pemesanan robot Anda.

Sertakan Departemen Teknologi Anda dalam Keputusan

Baik itu CTO atau insinyur khusus, pertahankan mereka dari awal. Mereka sangat mungkin memberi Anda lebih banyak wawasan tentang bagaimana kedua sistem akan bekerja bersama di masa depan.

Dan sepatah kata untuk para insinyur: Tetap berpikiran terbuka terhadap solusi pihak ketiga. Sangat mudah untuk mengabaikannya karena API mereka bukan yang terbaik atau UI mereka jelek. Namun, menemukan solusi elegan di sekitar sistem yang ada bisa sangat bermanfaat.

Namun demikian, ada beberapa topik yang dapat bermanfaat untuk dibicarakan sebelum membuat keputusan. Topik umum seperti "Apakah kita membutuhkan ini sama sekali?" perlu ditangani. Tapi itu juga ide yang baik untuk sudah memiliki gambaran tentang apa ruang lingkupnya. Apakah perlu sinkronisasi dua arah, atau akankah sistem pihak ketiga hanya mengikuti sistem pesanan? Setelah cakupan keluar, diskusi teknis juga perlu dilakukan tentang detail implementasi seperti webhook atau evaluasi batas API.

Apakah Anda Membutuhkan Integrasi Khusus?

Ketika berbicara tentang integrasi, tidak mengherankan bahwa sudah ada platform yang menjanjikan untuk memecahkan beberapa masalah yang mungkin Anda temui. Saat ini, Zapier dan IFTTT adalah yang paling menjanjikan.

Bergantung pada masalah yang Anda coba selesaikan, sistem pesanan robot Anda mungkin bahkan tidak terlibat dalam integrasi. Katakanlah Anda mengelola pelanggan buletin Anda dengan sistem CRM seperti Salesforce atau HubSpot dan hanya ingin cara yang lebih nyaman untuk menjangkau mereka melalui penyedia layanan email seperti Mailchimp, Zapier memiliki banyak integrasi yang ada untuk membantu Anda dalam hal itu. Dari titik ini, memilih penyedia yang memiliki konektor Zapier adalah cara yang baik.

Dan bahkan jika harus mengintegrasikan data khusus (robot yang dipesan dan harganya), Zapier Webhooks dapat bertindak sebagai perantara untuk integrasi Anda.

Di sisi lain, jika Anda sudah mengirim data ke pihak ketiga, mengapa tidak mengirimkannya langsung ke sistem CRM? Semakin banyak data yang ingin Anda sinkronkan, integrasi langsung akan semakin berguna.

Yang membawa saya ke poin saya berikutnya.

Apakah Anda Membutuhkan Sinkronisasi Dua Arah?

Biasanya, integrasi dimulai dengan persyaratan sederhana seperti Bisakah kami memasukkan semua klien kami ke dalam sistem CRM kami? , biasanya digabungkan dengan nilai pesanan robot individu, sehingga memudahkan penggunaan alat segmentasi klien.

Namun, cepat atau lambat, orang mungkin ingin menggunakan alat manajemen kontak yang biasanya ditawarkan oleh rangkaian CRM. Ini termasuk fitur seperti deduplikasi, mengubah detail kontak dengan data media sosial, menormalkan alamat pengiriman, atau hanya sekadar menghapus kontak lama.

Mengubah kontak dalam sistem CRM kemungkinan besar berarti Anda perlu mengubah detail kontak di sistem lain, yaitu, perubahan harus berjalan dua arah.

Upaya implementasi untuk ini jauh melampaui sinkronisasi satu arah yang sederhana, jadi ini adalah poin yang sangat baik untuk memikirkan bagaimana Anda ingin menggunakan sistem baru secara strategis.

Bagaimana Anda Akan Diberitahu tentang Perubahan dari CRM?

Jika Anda memutuskan untuk melakukan sinkronisasi dua arah, ada pertanyaan lanjutan: Bagaimana Anda tahu bahwa ada sesuatu yang berubah di sisi CRM?

Sebagian besar penyedia sistem memiliki alat untuk ini, tetapi yang terbaik untuk perubahan segera adalah webhook—pada dasarnya, sistem pemberitahuan HTTP yang dapat dikonfigurasi untuk memberi tahu Anda tentang perubahan yang relevan (untuk beberapa sistem, bahkan berdasarkan bidang demi bidang) .

Panduan untuk Integrasi CRM

Jika sistem tidak menawarkan webhook, setidaknya periksa apakah Anda bisa mendapatkan daftar semua entitas yang baru saja diperbarui. Dengan cara ini, Anda tidak harus melalui semua kontak dan penawaran hanya untuk memperbarui data Anda sendiri. Tetapi harap diingat bahwa Anda perlu melakukan polling sistem secara berkala.

Dalam hal ini, sistem pesanan Anda akan tetap berubah dan membuat data melalui panggilan API pada sistem CRM. Tetapi semua perubahan dari sistem CRM akan disurvei dalam interval yang ditentukan.

Panduan untuk Integrasi CRM

Yang perlu diperhatikan adalah bahwa pembaruan akan dibatasi pada interval ini dan dapat menyebabkan inkonsistensi data sementara. Misalnya, ketika Anda hanya menyinkronkan sekali sehari dari sistem CRM ke sistem pesanan Anda, data yang Anda lihat di sistem pesanan Anda dapat berumur hingga 24 jam.

Bergantung pada fitur apa yang ditawarkan sistem, tugas integrasi dapat bervariasi dalam kompleksitas dan waktu implementasi. Pastikan untuk memeriksa apa yang ditawarkan sistem sebelumnya dan periksa kembali paket yang ingin Anda beli. Misalnya, beberapa sistem CRM menawarkan webhook di tingkat yang dibayar lebih tinggi.

Contoh di sini adalah CRM HubSpot, yang menawarkan webhook secara umum tetapi fitur webhook hanya tersedia dalam paket Enterprise mereka. Alat akuntansi Zoho Books akan menawarkan lima alur kerja otomatis (termasuk webhook) di tingkat terendahnya.

Apakah Data Anda Dalam Kondisi Baik?

Saat membuat kumpulan data di sistem eksternal, ada baiknya mengetahui seperti apa tampilan data di sistem Anda sendiri. Untungnya, tidak ada terlalu banyak cara berbeda untuk menyajikan kontak dan penawaran, tetapi satu bidang yang selalu menyebabkan masalah adalah bidang email.

Sistem yang berbeda memiliki gagasan yang berbeda tentang apa itu alamat email yang valid, dan inilah peringatan spoiler—klien Anda mungkin telah memberi Anda semua jenis alamat email yang tidak valid. Banyak sistem CRM akan menolak pembuatan kontak dengan alamat email yang tidak valid (dan tentu saja, penyedia CRM menentukan mana yang valid dan mana yang tidak).

Tip: Jika memungkinkan, hanya sinkronkan alamat email yang dikonfirmasi ke CRM Anda. Ini akan menghemat banyak rasa sakit dalam jangka panjang.

Batasan API

Terakhir, keterbatasan API adalah sesuatu yang perlu ditangani sedini mungkin.

Dengan asumsi ada API (yang pada dasarnya harus dimiliki untuk integrasi apa pun), akan bermanfaat untuk melihat batasan API. Sebagian besar startup dapat mengatasi batasan API dasar dari sebagian besar sistem CRM. Sebagai contoh, HubSpot menawarkan 250.000 panggilan API per periode 24 jam bahkan di tingkat gratisnya. Di sisi lain, ini juga membatasi panggilan hingga 10 per detik (100 jika Anda menggunakan OAuth). Pemimpin pasar Salesforce hanya mengizinkan 100.000 setiap 24 jam tetapi menawarkan untuk membeli lebih banyak.

Sebagian besar waktu, Anda akan dengan mudah jatuh dalam batasan itu, tetapi ada satu hal yang perlu dipertimbangkan: Bagaimana dengan lari awal Anda? Pada awalnya, Anda akan mendorong banyak kontak dan kesepakatan ke CRM Anda (dan mungkin beberapa kali jika ada masalah). Akibatnya, Anda mungkin mencapai batas API harian.

Untuk mengurangi hal ini, Anda dapat menguji dengan kumpulan data kecil dan perlahan-lahan meningkatkan jumlahnya selama implementasi agar tetap berada dalam batas API. Untuk migrasi awal, rencanakan selama beberapa hari atau di akhir pekan. Atau, hubungi penyedia dan beri tahu mereka niat Anda. Saat Anda berada dalam tahap evaluasi (dan belum membayar sistem), mereka mungkin bersedia sedikit meningkatkan tunjangan API Anda.

Implementasi CRM

Katakanlah Anda semua setuju. Anda memilih alat CRM yang hebat, dan para insinyur yakin bahwa itu dapat diintegrasikan dengan lebih mudah. Anda memutuskan untuk membatasinya untuk hanya mendorong data pelanggan dan menerima pesanan robot. Oleh karena itu, sinkronisasi dua arah tidak diperlukan, dan perubahan alamat hanya akan ditangani dalam sistem pesanan Anda sendiri.

Masih ada beberapa praktik terbaik yang harus diikuti selama fase implementasi.

Cobalah Semuanya di Lingkungan Uji

Dalam kebanyakan kasus, sistem CRM hanya akan digunakan setelah integrasi Anda selesai dan siap digunakan. Untuk kasus penggunaan ini, mungkin tampak menarik untuk hanya menggunakan sistem produksi selama pengembangan. Lagi pula, tidak ada data produksi yang dapat Anda pengaruhi. Setelah pengembangan selesai, Anda cukup menghapus semua data pengujian yang Anda buat, menjalankan migrasi awal, dan mengarahkan sistem pesanan Anda ke lingkungan ini.

Ada beberapa masalah dengan pendekatan ini:

  1. Anda hanya menendang kaleng di jalan. Bahkan jika go-live Anda berjalan lancar, cepat atau lambat, akan ada permintaan fitur untuk mengubah bagian dari integrasi Anda. Mengingat permintaan fitur cukup besar, Anda mungkin memerlukan fase pengujian lain. Pada titik ini, sistem pengujian terpisah tidak dapat dihindari; jika tidak, Anda mungkin akan mengacaukan data produksi. Jadi mengapa menunggu dengan pengaturan sampai Anda diminta untuk mengimplementasikan fitur pertama?

  2. Anda berakhir dengan konfigurasi yang berantakan. Sangat mungkin bahwa sistem CRM Anda memerlukan semacam konfigurasi yang sesuai dengan kebutuhan sistem pesanan Anda. Nama status mungkin perlu disesuaikan, bidang khusus biasanya perlu dibuat, dan seterusnya. Karena sebagian besar pengembang perlu membiasakan diri dengan sistem CRM, konfigurasi akan ditambahkan yang tidak diperlukan dalam jangka panjang. Pada kenyataannya, konfigurasi yang tidak digunakan ini tidak dihapus nanti dan bahkan mungkin tetap berada di CRM Anda selamanya. Dengan memaksakan langkah tambahan untuk mereplikasi konfigurasi dari sistem pengujian ke produksi, kemungkinan besar Anda akan mendapatkan konfigurasi yang lebih ramping pada sistem produksi Anda.

    Perlu dicatat bahwa ini juga dapat merugikan Anda jika Anda lupa menyalin konfigurasi dari pengujian Anda ke sistem produksi Anda, dan Anda akan berakhir dengan kesalahan produksi.

    Meskipun ada beberapa sistem CRM yang akan membantu Anda membandingkan dan menyalin item konfigurasi, secara umum, akan berguna untuk menuliskan konfigurasi Anda agar tidak melupakan item penting. Sebagian besar CRM menyediakan API untuk konfigurasinya sehingga memungkinkan untuk mengotomatiskan langkah ini.

  3. Anda berisiko lebih tinggi mengotori data produksi. Bayangkan untuk sesaat dua pengembang mengerjakan integrasi. Anda sudah memiliki sistem staging dari sistem pemesanan robot. Pementasan ini terhubung ke CRM Anda juga. Setelah integrasi Anda dikirimkan, Anda harus ingat untuk memutuskan ketiga sistem, atau Anda mungkin akan membuat data uji pada CRM produksi (sekarang) Anda.

Semua masalah ini dapat dihindari dengan mengembangkan sistem pengujian sejak awal. Produksi hanya diperkenalkan di bagian paling akhir, tepat sebelum semuanya ditayangkan. Dengan cara ini, Anda mendapatkan konfigurasi yang bersih, tidak mengambil risiko lupa untuk memutuskan sambungan sistem lokal, dan mendapatkan informasi awal saat menerapkan fitur baru.

Tentukan ID untuk Entitas yang Cocok

Sekarang, mari kita mulai menulis kode integrasi yang sebenarnya. Mari kita ambil contoh sinkronisasi kontak ke sistem CRM. Agaknya, Anda perlu membuat kontak baru dan memperbarui kontak yang ada. Untuk membedakan pembuatan dari pembaruan, Anda perlu menautkan kedua entitas. Dengan begitu, Anda dapat memeriksa apakah kontak di sistem Anda ada di sistem eksternal.

Meskipun tampaknya menarik untuk hanya menggunakan alamat email (bagaimanapun juga, ini adalah pengidentifikasi umum untuk catatan kontak), ada solusi yang lebih umum—untuk setiap catatan, Anda menyinkronkan ke penangguhan sistem eksternal dan ID di database Anda sendiri.

Jadi, ubah tabel kontak Anda dengan kolom bernama crm_id atau external_id . Pendekatan ini memiliki beberapa keuntungan:

  • Karena ini adalah ID, itu tidak akan berubah (tidak seperti alamat email atau nomor telepon).
  • Anda dapat melihat apakah Anda perlu membuat atau memperbarui entitas tanpa melakukan panggilan API terlebih dahulu (jika bidang id eksternal kosong, Anda dapat menganggap kontak tidak ada).

Sebelum:

pelanggan
BigInt pengenal
Rangkaian nama
Rangkaian surel

Setelah:

pelanggan
BigInt pengenal
Rangkaian nama
Rangkaian surel
Rangkaian hubspot_id

Misalnya, katakanlah Anda adalah pengembang Ruby on Rails yang mengerjakan aplikasi yang perlu menyinkronkan pelanggan lama dan baru ke HubSpot.

Contoh kode yang disederhanakan dapat terlihat seperti ini:

 class HubspotSync def sync(customer) hubspot_return = if customer.hubspot_id.present? update(customer, customer.hubspot_id) else create(customer) end customer.update(hubspot_id: hubspot_return['companyId']) end private def create(customer) response = HTTParpty.post("https://api.hubapi.com/companies/v2/companies", map(company)) handle_response(response) end def update(customer, hubspot_id) response = HTTParpty.put("https://api.hubapi.com/companies/v2/companies/#{hubspot_id}", map(company)) handle_response(response) end def handle_response(response) raise RuntimeError, "Unexpected Status code: #{response.code}" if response.code >= 500 JSON.parse(response.body) end def map(company) # mapping code goes here { properties: [ name: 'name', value: company.name ] } end end

Perhatikan bagaimana kami mengambil keuntungan dari menyimpan companyId yang dikembalikan dari HubSpot. Tidak hanya membantu kami untuk menentukan apakah kami ingin memperbarui atau membuat perusahaan di HubSpot, tetapi kami juga dapat melihat di tabel database entitas mana yang sudah disinkronkan ke HubSpot dan mana yang masih hilang.

Saat Memetakan Bidang, Lakukan Gaya Bebas

Saya telah melihat proyek di mana implementasi didahului dengan membuat spreadsheet Excel raksasa yang menentukan kolom mana yang akan dituju dalam sistem CRM, dengan anotasi tentang bagaimana data harus diubah.

Pada kenyataannya, hanya ada beberapa cara untuk mewakili kontak dan kesepakatan. Jadi, daripada menghabiskan banyak waktu untuk memikirkan bagaimana tepatnya Anda ingin memetakan, mengapa tidak memulai dengan eksperimen? Beri pengembang ruang untuk mengetahui pemetaan tetapi juga tetap berhubungan sehingga pertanyaan dapat muncul lebih awal.

Setidaknya untuk bidang kontak umum (nama, alamat email, nomor telepon, alamat), pemetaan akan sangat sederhana, dan transformasi biasanya sepele.

Dalam hal pemetaan status untuk kesepakatan, sedikit lebih banyak komunikasi akan membantu (terkadang, status pertama disebut open , terkadang new , dan terkadang, model status tidak cocok 100% sehingga Anda harus mengelompokkan status bersama-sama ). Alih-alih menemukan solusi sempurna, lihat data Anda saat ini dan lihat bagaimana data tersebut paling cocok dengan model data CRM. Lagi pula, Anda adalah perusahaan yang gesit, bukan?

Pada contoh di atas, Anda dapat melihat metode peta yang mengubah model Rails kita menjadi hash biasa yang dipahami oleh HubSpot. Untuk kasus penggunaan khusus ini, satu-satunya item yang disinkronkan adalah namanya. Untuk penggunaan yang lebih maju, Anda mungkin ingin memasukkan lebih banyak bidang, tetapi untuk hasil yang bagus, mulailah dengan tebakan terpelajar dan sering berkomunikasi dengan pihak bisnis untuk detailnya.

Pertimbangkan Percobaan Ulang

Mari turun ke tingkat yang lebih teknis: menerapkan sinkronisasi aktual antara sistem Anda dan CRM. Hampir pasti bahwa integrasi akan dilakukan melalui koneksi HTTP. Sebagian besar sistem menyediakan HTTP API, dan semua bahasa pemrograman akan memungkinkan Anda melakukan panggilan HTTP dengan sangat mudah.

Sayangnya, tidak peduli berapa banyak uang yang Anda keluarkan untuk sistem CRM, pada akhirnya, itu tidak akan terjangkau. Ini akan terjadi di beberapa titik dan tidak ada yang dapat Anda lakukan untuk itu. Jadi, Anda mungkin juga mempertimbangkan hal ini ketika Anda mengembangkan integrasi Anda.

Artinya dalam praktiknya adalah—setiap kali Anda memanggil API, pastikan panggilan Anda dicoba lagi jika ada masalah (500 kode status dari sisi lain). Menerapkan percobaan ulang adalah sesuatu yang biasanya disediakan oleh perpustakaan pihak ketiga dari bahasa pilihan Anda.

Panduan untuk Integrasi CRM

Selain hanya mencoba lagi, Anda mungkin ingin mempertimbangkan untuk mencatat apa yang sebenarnya terjadi. Mendapatkan pemberitahuan tentang kesalahan yang telah diselesaikan pada percobaan ulang pertama dapat membuat frustasi.

Jadi, alih-alih mengirim spam ke saluran kesalahan Anda dengan masalah yang diselesaikan, catat semua info dengan jumlah percobaan ulang untuk merasakan seberapa andal sistemnya - sistem yang baru saja Anda bayarkan dengan banyak uang.

Jika kita mengambil kelas yang kita buat sebagai contoh dan kita tetap dalam konteks Ruby on Rails, kita cukup membungkus panggilan dalam ActiveJob dan cukup yakin panggilan akan berhasil pada akhirnya. Metode handle_response akan memunculkan kesalahan jika kode status tidak terduga, dan ActiveJob akan mencoba mencoba lagi dengan backoff eksponensial. Untuk solusi yang lebih maju, Anda juga harus mempertimbangkan kode status 4xx sehingga percobaan ulang dicegah dan pesan kesalahan muncul sebagai gantinya.

 class HubspotSyncJob < ApplicationJob def perform(customer) HubspotSync.new.sync(customer) end End

Pastikan Sistem Benar-Benar Digunakan

Oke, anggap saja Anda mengirimkan semuanya. Anda sangat bangga dengan pekerjaan Anda, dan sistemnya ditayangkan. Sekarang apa? Ini baru permulaan. Karena tidak peduli berapa banyak pengujian yang Anda lakukan, akan selalu ada bug dan perubahan yang diminta.

Masalahnya adalah, Anda tidak akan mengetahuinya kecuali Anda benar-benar menggunakan sistem Anda. Dan ini terjadi karena berbagai alasan—departemen penjualan saat ini terlalu sibuk untuk mulai menggunakannya, strategi diubah, atau bahkan sistem baru sedang dievaluasi.

Jadi, untuk menghindari potensi masalah dalam jangka panjang, pastikan Anda telah menghilangkan semua hambatan yang menghalangi penggunaan sistem produksi. Sering berkomunikasi antar tim untuk menyelaraskan persyaratan baru. Dan jika Anda mengetahui bahwa sistem tidak akan bekerja untuk Anda, matikan integrasi. Kedengarannya kasar dan bisa terasa sangat membuat frustrasi, tetapi itu tidak terlalu membuat frustrasi daripada selalu harus memperbaiki masalah inkonsistensi data dan menangani solusi.

Membungkus

Pada akhirnya, proyek integrasi adalah proyek yang sangat buruk, dan ada banyak hal yang bisa salah. Ini tidak terlalu populer di kalangan insinyur karena sejumlah alasan, tetapi dapat bermanfaat untuk melihat bahwa implementasi memiliki dampak positif pada produktivitas orang yang duduk di sebelah Anda.

Jadi bagi para insinyur—cobalah memahami kebutuhan sistem eksternal seperti CRM atau sistem faktur dengan mengajukan pertanyaan konkret seperti: Bagaimana produk ini akan membuat hidup Anda lebih mudah? Sudahkah Anda mempertimbangkan pesaing? Mengapa mereka tidak bekerja?

Untuk semua orang yang terlibat—masukkan teknisi sedini mungkin, percayai mereka saat mereka menunjukkan garis merah, dan jangan memilih paket murah saat Anda dapat melihat bahwa penerapan integrasi akan membuatnya jauh lebih sulit dalam jangka panjang.