Bu rehberi okuduğunuzda, Zoho Desk ile diğer sistemler arasındaki sınırı doğru çizebileceksiniz. Entegrasyon projelerinde teknik kısım nadiren sorun çıkarır; iki sistemi bağlamak çoğu zaman bir yapılandırma işidir. Sorun çıkaran, hangi bilginin hangi sistemde sahibi olduğunun kararlaştırılmamış olmasıdır. Sahibi belli olmayan veri iki yerde birden güncellenir, iki yer birbirini ezer ve bir süre sonra kimse hangisinin doğru olduğunu bilemez. Bu rehber önce sınırı, sonra bağlantıyı, en sonda genişletmeyi ele alıyor.
Her Verinin Tek Bir Sahibi Olmalı
Entegrasyon tasarımının tek kuralı budur. Bir bilgi iki sistemde de düzenlenebiliyorsa, er ya da geç çelişki oluşur. Sahiplik kararı verildiğinde diğer sistem o bilgiyi yalnızca okur.
Zoho CRM ve Zoho Desk birlikte kullanıldığında sahiplik ayrımı genellikle şu şekilde kurulur.
| Bilgi | Sahibi | Diğer sistemde |
|---|---|---|
| Müşteri şirket bilgileri | CRM | Desk'te okunur, düzenlenmez |
| Sözleşme, satış geçmişi, ciro | CRM | Desk'te bağlam olarak görünür |
| Destek talebi ve yazışması | Desk | CRM'de özet olarak görünür |
| Hizmet seviyesi ve destek sözleşmesi | Duruma göre | Nerede yönetiliyorsa orada, tek yerde |
| İletişim kişisi | CRM | Desk'e senkronlanır, tekilliği CRM korur |
Satış ile Destek Sınırı
Sahada en çok tartışılan sınır budur: bir müşteri talebi ne zaman destek talebi, ne zaman satış fırsatıdır? Cevap, talebin içeriğinde değil sonucunda saklıdır.
Destek talebidir
Müşteri zaten satın aldığı bir şeyin çalışmasını bekliyorsa. Sonuç, mevcut durumun düzelmesidir. Ücret doğursa bile bu bir onarımdır, satış değil.
Satış fırsatıdır
Müşteri sahip olmadığı bir şeyi almak istiyorsa. Sonuç, yeni bir anlaşmadır. Destek ekibi bunu fark eder ama süreci CRM'de satış yürütür.
Bu ayrımın operasyonel karşılığı şudur: destek temsilcisi bir satış sinyali fark ettiğinde talebi kapatıp CRM'de bir kayıt açmaz; talebi işaretler ve satış tarafına bildirim gider. İki süreç paralel yürür, biri diğerinin yerine geçmez. Aksi halde ya destek talebi satış sürecinde kaybolur ya da satış fırsatı destek kuyruğunda ölür.
Destek temsilcisine satış hedefi vermek, bu sınırı en hızlı bozan uygulamadır. Müşteri sorun çözmek için yazdığı yerde satış baskısı hissettiğinde, destek kanalına olan güveni biter ve bunun geri kazanılması yıllar alır.
CRM Entegrasyonunu Kurarken
Sınır çizildikten sonra bağlantı teknik bir işe dönüşür. Yine de dört karar entegrasyonu açmadan önce verilmelidir.
Hangi yönde akacak
Çift yönlü senkron, en çok soruna yol açan ve en az gerekli olan kurulumdur.
Çoğu operasyonda tek yön yeterlidir: müşteri ve hesap bilgisi CRM'den Desk'e akar, talep özeti Desk'ten CRM'e görünür. Çift yönlü alan senkronu yalnızca gerçekten gerekliyse ve tek bir alan için açılır.
Eşleşme anahtarı ne olacak
Yanlış anahtar, iki sistemde mükerrer kayıt üretir.
Genellikle e-posta adresi kullanılır. Aynı kişinin iki adresi varsa veya şirket ortak bir adres kullanıyorsa eşleşme bozulur; bu durumlar baştan tespit edilmelidir.
Kimin görebileceği belirlenecek
Entegrasyon, iki sistemin erişim modelini birleştirir ve bu istenmeyen açılmalar yaratabilir.
Desk'te bir departmanı görmeyen temsilci, CRM üzerinden o müşterinin geçmişine ulaşabiliyorsa erişim sınırı fiilen delinmiş demektir.
Bozulduğunda ne olacak
Entegrasyonlar sessizce durur ve bunu genellikle haftalar sonra fark edersiniz.
Senkronun çalıştığını gösteren bir kontrol noktası kurun. En basiti, günlük olarak iki sistemdeki kayıt sayısını karşılaştırmaktır.
Diğer Entegrasyonlar ve Marketplace
Zoho Desk, hazır bağlantılar üzerinden birçok sisteme bağlanır: iletişim ve toplantı araçları, geliştirme takip sistemleri, analiz araçları, telefon santralleri. Marketplace üzerinden kurulan eklentiler bu işi kolaylaştırır ancak her eklenti bir bakım yüküdür.
- Her eklenti bir bağımlılıktır. Sağlayıcı desteği bıraktığında veya sürüm değiştiğinde etkilenirsiniz. Kritik bir sürecin tek dayanağı üçüncü taraf bir eklenti olmamalıdır.
- Yetki kapsamını okuyun. Bir eklentinin hangi veriye eriştiği kurulum sırasında görünür. Talep içeriğine erişen bir eklenti, müşteri verisine erişiyor demektir.
- Kullanılmayanı kaldırın. Denenip bırakılmış eklentiler, yetkileri açık kalmış halde durur. Çeyreklik gözden geçirmede listelenmelidir.
- Önce dahili çözümü deneyin. İhtiyacın bir kural veya makro ile karşılanıp karşılanamayacağı, eklenti kurmadan önce kontrol edilir.
Geliştirme takip sistemiyle kurulan bağlantı özel bir yer tutar. Müşteriden gelen arıza bildiriminin geliştirme tarafına iletilip sonucunun geri dönmesi, destek ekibinin en çok ihtiyaç duyduğu akıştır. Bu bağlantı kurulmadığında temsilci "geliştirme ekibine ilettim" der ve o talebin akıbetini bir daha öğrenemez.
Geliştirici Alanı: Ne Zaman Kod Yazılır
Hazır yapılandırmanın yetmediği noktada özel geliştirme devreye girer: özel fonksiyonlar, dış sistemlere giden çağrılar, ekran içine gömülen bileşenler ve API üzerinden kurulan akışlar. Bu yeteneklerin sürüm eşiklerini sözleşme öncesinde teyit edin; kurulum planınızı doğrudan etkiler.
Kod yazma kararı için ölçü şudur: bu ihtiyaç yapılandırmayla karşılanabiliyorsa kod yazılmaz. Yazılan her satır, bakımını üstlenecek birini gerektirir ve o kişi ayrıldığında sistemde açıklanamayan bir davranış kalır.
Kod gerektiren durumlar
Dış sistemden anlık veri çekmek, karmaşık hesaplama yapmak, standart dışı bir onay akışını yürütmek, başka bir uygulamada kayıt oluşturmak.
Kod gerektirmeyen durumlar
Alan güncelleme, bildirim gönderme, etiketleme, atama. Bunların tamamı kural ve makro ile yapılır ve yapılmalıdır.
Özel geliştirme yapıldığında üç şey mutlaka bırakılır: ne yaptığını anlatan bir açıklama, hangi durumda tetiklendiğinin kaydı ve hata durumunda ne olacağının tanımı. Sessizce başarısız olan bir fonksiyon, hiç olmayan fonksiyondan daha tehlikelidir; çünkü çalıştığını sanırsınız.
API entegrasyonlarında yetkilendirme kapsamını en dar biçimde tanımlayın ve kimlik bilgilerini kod içine yazmayın. Destek sistemine yazma yetkisi olan bir anahtarın sızması, tüm müşteri yazışmasına erişim anlamına gelir.
Mobil ve Sahadan Erişim
Destek ekibinin masa başında olmadığı operasyonlarda mobil erişim bir ek değil, gerekliliktir. Ancak mobil kurulumun kendine özgü kararları vardır.
- Mobilde ne yapılabileceğini sınırlayın. Talebi görmek ve kısa yanıt vermek mobil işidir; toplu güncelleme ve yapılandırma değişikliği değildir.
- Bildirim yorgunluğuna dikkat edin. Her talep için anlık bildirim açıldığında ekip bildirimleri kapatır ve kritik olanı da kaçırır. Yalnızca atanan ve eskale edilen talepler için bildirim yeterlidir.
- Cihaz kaybı senaryosunu düşünün. Mobil erişimi olan hesaplarda iki adımlı doğrulama ve uzaktan oturum kapatma yolu tanımlı olmalıdır.
- Mesai dışı beklentiyi netleştirin. Telefonda bildirim alan temsilci, akşam gelen talebe bakmak zorunda mı? Bu soru yazılı yanıtlanmazsa ekip kendi kuralını koyar.
Entegrasyon Öncesi Kontrol Listesi
Bağlantıyı açmadan önce şu altı maddenin tamamı yazılı olarak yanıtlanmış olmalıdır. Biri eksikse entegrasyon açılmaz.
Sahiplik
Her alanın sahibi hangi sistem. Diğer taraf okur mu, yazar mı.
Yön
Veri hangi yöne akıyor. Çift yön gerçekten gerekli mi.
Anahtar
Kayıtlar hangi alan üzerinden eşleşiyor. Çakışma olursa ne olur.
Erişim
Bağlantı sonrası kim neyi görebilir hale geliyor.
İzleme
Senkron durduğunda bunu kim, nasıl fark edecek.
Geri alma
Entegrasyon kapatılırsa hangi veri nerede kalır.
Bu liste, gördüğümüz başarısız entegrasyonların tamamında en az bir maddesi eksik olan listedir. En sık eksik olan beşinci maddedir: kimse senkronun durduğunu fark etmez ve iki sistem sessizce ayrışır.
Buraya kadar olan on iki rehber, bir destek operasyonunun kurulum sırasını oluşturuyor. Başa dönmek isterseniz Zoho Desk'e Doğru Başlangıç rehberinden yeniden başlayabilirsiniz.
