İnşa Etmeyin, Entegre Edin – CRM Entegrasyonu İçin Bir Kılavuz

Diyelim ki tüm endüstrilerde robot satan bir girişim için çalışıyorsunuz. Çeşitli müşterilerden sipariş alırsınız ve bir operasyon ekibi siparişleri değerlendirir ve müşterilerinize tam olarak doğru robotu almak için üçüncü taraf sağlayıcılarla çalışır.

MVP'yi oluşturmak stresli ama aynı zamanda çok eğlenceliydi. Yatırımcılarınız heyecanlı ve sizi para yağmuruna tutuyor. Bir sonraki aşama başlar. Karlılık konusunda daha fazla görünürlüğe ihtiyacınız var ve daha karmaşık faturalandırmaya ihtiyaç duyan daha büyük müşteriler edinmek istiyorsunuz. Aynı zamanda, daha yüksek marjlı robotların satışını sağlamak için oldukça karmaşık bir ürün yol haritanız var. Kaynaklar kıt, ancak yine de şirketi çalışır durumda tuttuğunuzdan emin olmanız gerekiyor.

Küçük şirketler için sıklıkla vaaz edildiği gibi, iyi olduğunuz şeylere odaklanmak büyük bir başparmak kuralıdır. Peki ya şirketinizin günlük operasyonlarını devam ettiren tüm alanlar? Kesinlikle bir Müşteri İlişkileri Yönetimi (CRM) sistemi veya muhasebe sistemi kurmak istemezsiniz. Sonuçta, tüm sorunları çözen birçok ürün var. Ancak bu sistemler mevcut sipariş sisteminizle birlikte nasıl çalışacak?

Üçüncü taraf entegrasyonunun kullanışlı olduğu yer burasıdır. Öyleyse, bazı yaygın tuzaklardan kaçınıp kaçınamayacağımızı görelim.

CRM Entegrasyonu

Gereksiz satışlar (içerik pazarlama, sosyal medya reklamları veya haber bültenleri) veya temaslı satışlar (soğuk arama, konferanslara katılma veya mevcut müşterileri telefonla takip etme) yapıyor olsanız da, bir CRM sistemi size çok şey verebilir. Mevcut müşterilerle nasıl yaptığınız ve yeni müşterileri ikna etme konusunda ne kadar başarılı olduğunuz hakkında görünürlük.

Çoğu zaman, bir CRM sisteminin seçimi çoğunlukla satış ve pazarlama departmanına bırakılır. Genel olarak, bunda yanlış bir şey yok. Sonuçta, bu insanlar geliri nasıl artıracaklarını en iyi bilirler ve mevcut en iyi desteğe ihtiyaç duyarlar. Ancak en iyi yazılım bile robot sipariş sisteminizle birlikte düzgün çalışmıyorsa hiçbir değeri yoktur.

Teknik Departmanınızı Karara Dahil Edin

İster CTO, isterse özel bir mühendis olsun, onları en baştan döngüde tutun. Gelecekte iki sistemin birlikte nasıl çalışacağı konusunda size daha fazla fikir vermeleri çok muhtemeldir.

Ve mühendisler için bir kelime: Üçüncü taraf çözümlere karşı açık fikirli olun. API'leri en iyi olmadığı veya kullanıcı arayüzleri çirkin olduğu için bunları reddetmek kolaydır. Ancak, mevcut sistemler etrafında zarif çözümler bulmak çok faydalı olabilir.

Yine de, bir karar vermeden önce konuşmanın faydalı olabileceği birkaç konu var. “Buna ihtiyacımız var mı?” gibi genel konular. ele alınması gerekiyor. Ancak, kapsamın ne olduğu hakkında zaten bir fikre sahip olmak da iyi bir fikirdir. İki yönlü bir senkronizasyona ihtiyaç var mı, yoksa üçüncü taraf sistem sadece sipariş sistemini mi takip edecek? Kapsam ortadan kalktığında, web kancaları veya API sınırlarının değerlendirilmesi gibi uygulama ayrıntıları hakkında da teknik bir tartışma yapılması gerekir.

Hiç Özel Bir Entegrasyona İhtiyacınız Var mı?

Entegrasyon söz konusu olduğunda, karşılaşabileceğiniz bazı sorunları çözmeyi vaat eden halihazırda mevcut platformların olması şaşırtıcı değildir. Şu anda, Zapier ve IFTTT en umut verici olanlardır.

Çözmeye çalıştığınız soruna bağlı olarak robot sipariş sisteminiz entegrasyona dahil bile olmayabilir. Bülten abonelerinizi Salesforce veya HubSpot gibi bir CRM sistemi ile yönettiğinizi ve Mailchimp gibi bir e-posta servis sağlayıcısı aracılığıyla onlara ulaşmanın daha kolay bir yolunu istediğinizi varsayalım, Zapier'de bu konuda size yardımcı olacak tonlarca mevcut entegrasyon var. Bu noktadan itibaren, Zapier bağlayıcısı olan bir sağlayıcı seçmek, ileriye dönük iyi bir yoldur.

Özel verileri entegre etme söz konusu olsa bile (sipariş edilen robotlar ve fiyatları), Zapier Web kancaları entegrasyonunuz için bir aracı görevi görebilir.

Öte yandan, zaten üçüncü bir tarafa veri gönderiyorsanız, neden doğrudan CRM sistemine göndermiyorsunuz? Senkronize etmek istediğiniz veri ne kadar fazlaysa, doğrudan entegrasyon o kadar faydalı olacaktır.

Bu da beni bir sonraki noktama getiriyor.

İki Yönlü Senkronizasyona İhtiyacınız Var mı?

Genellikle bir entegrasyon, tüm müşterilerimizi CRM sistemimize alabilir miyiz gibi basit bir gereksinimle başlar. , tipik olarak bireysel robot siparişlerinin değerleriyle birleştirilir ve müşteri segmentasyon araçlarını kullanmayı kolaylaştırır.

Ancak, er ya da geç, insanlar bir CRM paketinin tipik olarak sunduğu iletişim yönetimi araçlarını kullanmak isteyeceklerdir. Bunlar, veri tekilleştirme, sosyal medya verileriyle iletişim bilgilerini değiştirme, teslimat adreslerini normalleştirme veya yalnızca eski kişileri silme gibi özellikleri içerir.

Bir CRM sisteminde kişileri değiştirmek büyük olasılıkla başka bir sistemdeki iletişim bilgilerini değiştirmeniz gerekeceği anlamına gelir, yani değişikliklerin her iki yönde de olması gerekir.

Bunun için uygulama çabası, basit tek yönlü bir senkronizasyonun çok ötesindedir, bu nedenle bu, yeni bir sistemi stratejik olarak nasıl kullanmak istediğinizi düşünmek için mükemmel bir noktadır.

CRM Değişikliklerinden Nasıl Haberdar Olacaksınız?

İki yönlü bir senkronizasyona karar verirseniz, bir takip sorusu vardır: CRM tarafında bir şeylerin değiştiğini nasıl anlarsınız?

Çoğu sistem sağlayıcı bunun için araçlara sahiptir, ancak ani değişiklikler için en iyisi web kancalarıdır - esasen, ilgili değişiklikler hakkında size bilgi vermek için yapılandırılabilen bir HTTP bildirim sistemi (bazı sistemler için, hatta alan bazında bile) .

Sistem web kancaları sunmuyorsa, en azından yakın zamanda güncellenen tüm varlıkların bir listesini alıp alamayacağınızı kontrol edin. Bu şekilde, yalnızca kendi verilerinizi güncellemek için tüm kişileri ve anlaşmaları gözden geçirmeniz gerekmez. Ancak sistemi düzenli aralıklarla sorgulamanız gerekeceğini lütfen unutmayın.

Bu durumda sipariş sisteminiz yine değişecek ve CRM sistemi üzerinde bir API çağrısı ile veri oluşturacaktır. Ancak CRM sisteminden gelen tüm değişiklikler, tanımlanmış bir aralıkta sorgulanacaktır.

Dikkat edilmesi gereken nokta, güncellemelerin bu aralıkla sınırlı olacağı ve geçici veri tutarsızlığına yol açabileceğidir. Örneğin, CRM sisteminizden sipariş sisteminize günde yalnızca bir kez eşitleme yaptığınızda, sipariş sisteminizde baktığınız veriler 24 saate kadar eski olabilir.

Sistemin sunduğu özelliklere bağlı olarak, entegrasyon görevinin karmaşıklığı ve uygulama süresi değişebilir. Sistemin önceden neler sunduğunu kontrol ettiğinizden ve satın almayı düşündüğünüz planı iki kez kontrol ettiğinizden emin olun. Örneğin, bazı CRM sistemleri, daha yüksek ücretli katmanlarda web kancaları sunar.

Burada bir örnek, genel olarak web kancaları sunan ancak web kancası özelliği yalnızca Enterprise paketinde bulunan HubSpot'un CRM'sidir. Muhasebe araçları Zoho Books, en alt kademelerinde (web kancalarını içeren) beş otomatik iş akışı sunacaktır.

Verileriniz İyi Şekilde mi?

Harici bir sistemde veri kümeleri oluşturmaya gelince, verilerin kendi sisteminizde nasıl göründüğünü bilmek iyidir. Neyse ki, kişileri ve anlaşmaları sunmanın çok fazla farklı yolu yoktur, ancak her zaman soruna neden olan bir alan e-posta alanıdır.

Farklı sistemlerin geçerli bir e-posta adresinin ne olduğu konusunda farklı fikirleri vardır ve işte bir spoiler uyarısı - müşterileriniz size her türden geçersiz e-posta adresi sağlamış olabilir. Pek çok CRM sistemi, geçersiz bir e-posta adresiyle bir kişinin oluşturulmasını reddeder (ve elbette, CRM sağlayıcısı neyin geçerli olup olmadığını tanımlar).

İpucu: Mümkünse, yalnızca onaylanmış e-posta adreslerini CRM'nizle senkronize edin. Bu, uzun vadede sizi çok fazla acıdan kurtaracaktır.

API Sınırlamaları

Son olarak, API sınırlamaları, mümkün olduğunca erken ele alınması gereken bir şeydir.

Bir API (temelde herhangi bir entegrasyon için sahip olunması gereken) olduğunu varsayarsak, API'nin sınırlamalarına bakmakta fayda var. Çoğu startup, çoğu CRM sisteminin temel API limitleriyle başa çıkabilir. Örnek olarak, HubSpot, ücretsiz katmanlarında bile 24 saatlik periyot başına 250.000 API çağrısı sunar. Öte yandan, aramaları saniyede 10 ile sınırlar (OAuth kullanıyorsanız 100). Pazar lideri Salesforce, her 24 saatte yalnızca 100.000'e izin verir, ancak daha fazlasını satın almayı teklif eder.

Çoğu zaman, bu sınırlamalara kolayca girersiniz, ancak dikkate alınması gereken bir şey var: İlk koşunuz ne olacak? Başlangıçta, CRM'inize çok sayıda temas ve anlaşma göndereceksiniz (ve eğer sorun varsa muhtemelen birden çok kez). Sonuç olarak, günlük API sınırına ulaşabilirsiniz.

Bunu azaltmak için küçük bir veri seti ile test edebilir ve uygulama boyunca sayıyı API'nin limiti dahilinde kalacak şekilde yavaşça artırabilirsiniz. İlk geçiş için, birkaç gün veya bir hafta sonu planlayın. Alternatif olarak, sağlayıcıya ulaşın ve niyetlerinizi bildirin. Değerlendirme aşamasındayken (ve henüz sistem için ödeme yapmadığınızda), API ödeneğinizi biraz artırmaya istekli olabilirler.

CRM Uygulaması

Diyelim ki hepiniz aynı fikirdesiniz. Harika bir CRM aracı seçtiniz ve mühendisler bunun kolayca entegre edilebileceğinden eminler. Kapsamı yalnızca müşteri verilerini ve kabul edilen robot siparişlerini iletecek şekilde belirlemeye karar verdiniz. Bu nedenle, iki yönlü senkronizasyon gerekli değildir ve adres değişiklikleri yalnızca kendi sipariş sisteminizde ele alınacaktır.

Uygulama aşamasında izlenecek birkaç en iyi uygulama var.

Her Şeyi Test Ortamında Deneyin

Çoğu durumda, CRM sistemi ancak entegrasyonunuz tamamlandıktan ve kullanıma hazır hale geldikten sonra kullanılacaktır. Bu kullanım durumu için, geliştirme sırasında sadece üretim sistemini kullanmak çekici görünebilir. Sonuçta, etkileyebileceğiniz hiçbir üretim verisi yok. Geliştirme tamamlandıktan sonra, oluşturduğunuz tüm test verilerini kaldıracak, ilk geçişi gerçekleştirecek ve sipariş sisteminizi bu ortama yönlendireceksiniz.

Bu yaklaşımla ilgili birkaç sorun var:

1. Sadece kutuyu yoldan aşağı atıyorsun. Canlı yayınınız sorunsuz geçse bile, er ya da geç, entegrasyonunuzun bir kısmını değiştirmek için bir özellik isteği olacaktır. Özellik isteğinin yeterince büyük olduğu göz önüne alındığında, muhtemelen başka bir test aşamasına ihtiyacınız olacak. Bu noktada ayrı bir test sistemi kaçınılmazdır; aksi takdirde, üretim verilerini karıştırabilirsiniz. Öyleyse neden ilk özelliği uygulamanız istenene kadar kurulumda bekleyesiniz?

   

2. Dağınık bir konfigürasyonla sonuçlanırsınız. CRM sisteminizin, sipariş sisteminizin ihtiyaçlarına uygun bir tür yapılandırmaya ihtiyacı olması çok muhtemeldir. Durum adlarının ayarlanması, genellikle özel alanların oluşturulması vb. gerekebilir. Çoğu geliştiricinin CRM sistemine alışması gerekeceğinden, uzun vadede ihtiyaç duyulmayan bir konfigürasyon eklenecektir. Gerçekte, bu kullanılmayan yapılandırma daha sonra kaldırılmaz ve hatta sonsuza kadar CRM'nizde kalabilir. Yapılandırmayı test sisteminden üretime kopyalama ek adımını zorlayarak, büyük olasılıkla üretim sisteminizde daha ince bir yapılandırma elde edersiniz.
   
   Testinizden üretim sisteminize yapılandırmayı kopyalamayı unutursanız, bunun sizin için dezavantajlı olabileceğine ve üretim hatalarına neden olacağına dikkat edilmelidir.
   
   Konfigürasyon öğelerini karşılaştırmanıza ve kopyalamanıza yardımcı olacak bazı CRM sistemleri olsa da, genel olarak önemli öğeleri unutmamak için konfigürasyonlarınızı yazmanız faydalı olacaktır. Çoğu CRM, yapılandırmalarına bir API sağlar, böylece bu adımı otomatikleştirmek mümkündür.

3. Üretim verilerini kirletme riskiniz daha yüksektir. Bir entegrasyon üzerinde çalışan ikinci bir iki geliştirici düşünün. Robot sipariş sisteminin bir aşamalandırma sistemine zaten sahipsiniz. Bu evreleme, CRM'nize de bağlıdır. Entegrasyonunuz gönderildikten sonra, üç sistemin de bağlantısını kesmeyi hatırlamanız gerekecek, aksi takdirde (şimdi) üretim CRM'nizde test verileri oluşturabilirsiniz.

Tüm bu sorunlar, baştan bir test sistemine karşı geliştirilerek önlenebilir. Üretim sadece en sonunda, her şey canlıya geçmeden hemen önce tanıtılır. Bu şekilde, temiz bir yapılandırma elde edersiniz, yerel sistemlerin bağlantısını kesmeyi unutma riskiyle karşılaşmazsınız ve yeni özellikleri uygularken bir uyarı alırsınız.

Varlıkları Eşleştirmek için Kimlik Tanımlayın

Şimdi asıl entegrasyon kodunu yazmaya başlayalım. Kişileri bir CRM sistemiyle senkronize etme örneğini ele alalım. Muhtemelen, yeni kişiler oluşturmanız ve mevcut kişileri güncellemeniz gerekecek. Bir oluşturmayı bir güncellemeden ayırt etmek için iki varlığı bağlamanız gerekir. Bu şekilde sisteminizdeki kontağın harici sistemde olup olmadığını kontrol edebilirsiniz.

Yalnızca e-posta adresini kullanmak çekici görünse de (sonuçta bu, bir kişi kaydı için ortak bir tanımlayıcıdır), daha genel bir çözüm vardır; her kayıt için, kendi veritabanınızdaki harici bir sistem muhafazası ve kimliğiyle eşitlenirsiniz.

Bu nedenle, kişi tablonuzu crm_id veya external_id adlı bir sütunla değiştirin. Bu yaklaşımın birkaç avantajı vardır:

• Kimlik olduğu için değişmez (bir e-posta adresi veya telefon numarasının aksine).
• Önce bir API çağrısı yapmadan varlığı oluşturmanız veya güncellemeniz gerekip gerekmediğini görebilirsiniz (harici kimlik alanı boşsa ilgili kişinin olmadığını varsayabilirsiniz).

Önce:

Sonrasında:

Örneğin, mevcut ve yeni müşterileri HubSpot ile senkronize etmesi gereken bir uygulama üzerinde çalışan bir Ruby on Rails geliştiricisi olduğunuzu varsayalım.

Basitleştirilmiş bir kod örneği şöyle görünebilir:

 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

companyId döndürülen şirket kimliğini kaydetme avantajından nasıl yararlandığımıza dikkat edin. HubSpot'ta bir şirket oluşturmak veya güncellemek isteyip istemediğimizi belirlememize yardımcı olmakla kalmaz, aynı zamanda veritabanı tablosunda hangi varlıkların HubSpot ile zaten senkronize edildiğini ve hangilerinin hala eksik olduğunu görebiliriz.

Alanları Haritalamaya Geldiğinde, Serbest Stile Gidin

Verilerin nasıl dönüştürülmesi gerektiğine dair ek açıklamalarla birlikte, CRM sisteminde hangi sütunların nereye gideceğini tanımlayan dev bir Excel elektronik tablosu oluşturarak uygulamanın önce geldiği projeler gördüm.

Gerçekte, kişileri ve anlaşmaları temsil etmenin yalnızca birkaç yolu vardır. Tam olarak nasıl haritalamak istediğinizi düşünmek için çok zaman harcamak yerine, neden bir deneyle başlamıyorsunuz? Geliştiriciye eşlemeyi anlaması için biraz yer verin, ancak soruların erken ortaya çıkması için iletişimde kalın.

En azından genel iletişim alanları (ad, e-posta adresi, telefon numarası, adres) için eşleştirme çok basit olacaktır ve dönüşümler genellikle önemsizdir.

Anlaşmalar için durum eşleme söz konusu olduğunda, biraz daha fazla iletişim yardımcı olur (bazen ilk durum open , bazen new olarak adlandırılır ve bazen durum modeli %100 eşleşmez, bu nedenle durumları birlikte gruplamanız gerekir) ). Mükemmel bir çözüm bulmak yerine, mevcut verilerinize bakın ve bunların CRM'nin veri modeline en iyi nasıl uyacağına bakın. Ne de olsa çevik bir şirketsiniz, değil mi?

Yukarıdaki örnekte, Rails modelimizi HubSpot tarafından anlaşılan normal bir karmaya dönüştüren bir harita yöntemi görebilirsiniz. Bu özel kullanım durumu için, senkronize edilen tek öğe addır. Daha gelişmiş kullanım için, muhtemelen daha fazla alan eklemek istersiniz, ancak harika bir sonuç için, eğitimli bir tahminle başlayın ve ayrıntılar için iş dünyası ile sık sık iletişim kurun.

Yeniden Denemeyi Düşünün

Daha teknik seviyeye geçelim: sisteminiz ve CRM arasındaki gerçek senkronizasyonu uygulamak. Entegrasyonun bir HTTP bağlantısı üzerinden gerçekleşeceği neredeyse kesin. Çoğu sistem bir HTTP API'si sağlar ve tüm programlama dilleri, HTTP çağrılarını çok kolay yapmanıza izin verir.

Ne yazık ki, bir CRM sistemine ne kadar para harcarsanız harcayın, sonunda ona ulaşılamayacak. Bu bir noktada olacak ve bu konuda yapabileceğiniz hiçbir şey yok. Bu nedenle, entegrasyonunuzu geliştirirken bunu da hesaba katabilirsiniz.

Bunun pratikte anlamı şudur: bir API'yi her aradığınızda, bir sorun olması durumunda aramanızın yeniden denendiğinden emin olun (diğer taraftan 500 durum kodu). Yeniden denemeleri uygulamak, genellikle seçtiğiniz dildeki üçüncü taraf kitaplıkları tarafından sağlanan bir şeydir.

Yeniden denemeye ek olarak, tam olarak ne olduğunu günlüğe kaydetmeyi düşünebilirsiniz. İlk denemede zaten çözülmüş bir hata hakkında bildirim almak sinir bozucu olabilir.

Bu nedenle, hata kanalınızı çözülmüş sorunlarla spam göndermek yerine, sistemin ne kadar güvenilir olduğunu anlamak için tüm açıklamaları yeniden deneme sayısıyla kaydedin - az önce çok para ödediğiniz bir sistem.

Örnek olarak oluşturduğumuz sınıfı alırsak ve Ruby on Rails bağlamında kalırsak, çağrıyı bir ActiveJob ve çağrının sonunda başarılı olacağından oldukça emin olabiliriz. handle_response yöntemi, beklenmeyen bir durum kodu olması durumunda bir hata oluşturur ve ActiveJob , üstel bir geri çekilme ile yeniden denemeyi dener. Daha gelişmiş bir çözüm için, 4xx durum kodlarını da göz önünde bulundurmalısınız, böylece yeniden deneme engellenir ve bunun yerine bir hata mesajı verilir.

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

Sistemin Gerçekten Kullanıldığından Emin Olun

Tamam, hepsini gönderdiğinizi varsayalım. Çalışmanızla çok gurur duyuyorsunuz ve sistem devreye giriyor. Şimdi ne olacak? Bu sadece başlangıç. Çünkü ne kadar test yapıyor olursanız olun, her zaman hatalar ve istenen değişiklikler olacaktır.

Sorun şu ki, sisteminizi gerçekten kullanmadığınız sürece bunları öğrenemeyeceksiniz. Ve bu her türlü nedenden dolayı olur - satış departmanı şu anda onu kullanmaya başlamak için çok meşgul, strateji değişti ve hatta yeni sistemler zaten değerlendiriliyor.

Bu nedenle, uzun vadede olası sorunları önlemek için, sistemin üretim kullanımını engelleyen tüm engelleri ortadan kaldırdığınızdan emin olun. Yeni gereksinimlerin uyumlu hale getirilmesi için ekipler arasında sık sık iletişim kurun. Ve sistemin sizin için çalışmayacağını öğrenirseniz, entegrasyonu kapatın. Kulağa sert gelebilir ve çok sinir bozucu olabilir, ancak her zaman veri tutarsızlığı sorunlarını düzeltmek ve geçici çözümlerle uğraşmak zorunda kalmaktan daha az sinir bozucu.

Toplama

Sonuç olarak, bir entegrasyon projesi harika bir projedir ve ters gidebilecek pek çok şey vardır. Birkaç nedenden dolayı mühendisler arasında pek popüler değil, ancak bir uygulamanın yanınızda oturan kişilerin üretkenliği üzerinde olumlu bir etkisi olduğunu görmek ödüllendirici olabilir.

Bu nedenle mühendisler için şu gibi somut sorular sorarak CRM veya faturalandırma sistemi gibi harici bir sistemin ihtiyaçlarını anlamaya çalışın: Bu ürün hayatınızı nasıl kolaylaştıracak? Rakipleri düşündünüz mü? Neden çalışmıyorlar?

Müdahil olan diğer herkes için—mühendisleri mümkün olduğunca erken görevlendirin, kırmızı çizgileri işaret ettiklerinde onlara güvenin ve entegrasyonun uygulanmasının işinizi çok daha zorlaştıracağını gördüğünüzde ucuz bir planı tercih etmeyin. uzun koşu.