Teslimat ve CRM entegrasyonu: hangi veriler aktarılır ve alışveriş nasıl kurulur

CRM ile saha operasyonu ayrı yaşayınca ne bozulur

CRM müşteriyle ilişkiden sorumludur: satış fırsatları, kişiler, süre ve ödemeye dair mutabakatlar orada tutulur. Saha yönetim sistemi ise icradan sorumludur: kim gidecek, hangi sırayla, işin yapıldığı neyle kanıtlanacak. Bu iki halka birbirine bağlanmadığı sürece aralarında verileri elle taşıyan bir insan durur ve bu taşımanın bedeli yalnızca harcanan zamandan ibaret değildir.

Kopukluğun tipik sonuçları şöyle görünür:

• Çift giriş ve yazım hataları. İkinci kez yazılan bir adres, hata ihtimali taşıyan bir adrestir. Saha çalışanı yanlış yere gider, mesele ise artık yolda çözülmek zorunda kalır.
• Durumların gecikmesi. Temsilci siparişte ne olduğunu göremez ve müşteriye net bir yanıt yerine «şimdi öğrenip döneyim» der. Bu cümlenin her tekrarı, sevkiyat masasına bir telefon demektir.
• Kaybolan talepler. Satış fırsatı «sevke verildi» aşamasına geçmiştir ama sevkiyat sorumlusuna ulaşmamıştır: müşteri arayana kadar kimse fark etmez.
• Tutmayan raporlar. CRM'de bir sevkiyat sayısı, operasyon sisteminde başka bir sayı vardır ve farkı yalnızca ayrıntıları iyi hatırlayan bir çalışan açıklayabilir.

Entegrasyon bu elle çalışan ara katmanı ortadan kaldırır: satış fırsatı ilgili aşamaya geldiği anda talep sevkiyat sorumlusunun ekranında belirir, işin sonucu ise kimsenin anlatmasına gerek kalmadan müşteri kartına geri döner. Geri kalan her şey — bildirimler, analitik, arayüz kolaylıkları — bu temel alışverişin üzerine kurulan bir katmandır. Bu yüzden entegrasyonu «hangi düğmelere basılacak» sorusundan değil, «hangi bilgiler hangi yöne akmalı» sorusundan başlayarak tasarlamak gerekir.

CRM ile saha sistemi arasında hangi veriler akar

Alışveriş neredeyse her zaman çift yönlüdür ve iki kısa listeyle anlatmak işe yarar: CRM'den ne çıkıyor, geriye ne dönüyor. CRM'den saha sistemine genellikle şunlar aktarılır:

• talep ya da sipariş: numarası, iş tipi, içeriği, temsilcinin notu;
• işin yapılacağı adres ve erişim ayrıntıları — blok, kat, giriş kartı, yerinde kimin aranacağı;
• alıcının iletişim bilgileri ve üzerinde anlaşılan zaman aralığı;
• tahsilatı saha çalışanı yapıyorsa tutar ve ödeme yöntemi;
• aciliyet ya da öncelik işareti — sevkiyat sorumlusu neyin yarına ertelenemeyeceğini görsün diye.

Geriye, saha sisteminden CRM'e ise icraya dair olgular döner:

• atanan saha çalışanı ve tahmini varış zamanı;
• durumlar: işe alındı, yola çıktı, adreste, tamamlandı, tamamlanmadı;
• kapalı listeden seçilen tamamlanmama nedeni — ret, ulaşılamadı, adres bulunamadı, müşteri talebiyle erteleme;
• kanıtlar: fotoğraflı rapor, alıcı imzası, işaretlemenin zamanı ve konumu;
• saha çalışanı topladıysa yerinde alınan ödeme.

Müşteri ve adres kartotekleri için ayrıca anlaşmak gerekir. İki tarafta birden açılıyorlarsa, mükerrer kayıtlar daha ilk ayda ortaya çıkar: «Papatya Ltd.» ve «Ltd. Papatya» farklı geçmişe sahip iki kayda dönüşür ve müşteri bazlı her raporu elle toplamak gerekir. Kartoteğin sahibi olarak bir sistemi, tüketicisi olarak diğerini belirlemek çok daha kolaydır.

Haftalarca sürecek yazışmadan kurtaran pratik bir yöntem: işe başlamadan önce alanları dört sütunlu bir tabloya dökün — CRM'deki adı, saha sistemindeki adı, akış yönü, değer boşsa ne yapılacağı. Bu tek sayfalık belge, entegrasyonun teknik şartnamesinin ta kendisidir.

Alışveriş yöntemleri: API, webhook ve dosya aktarımı

Teknik olarak sistemleri birkaç yoldan bağlayabilirsiniz. Seçim modaya değil, verilere ne kadar hızlı ihtiyaç duyduğunuza ve CRM'inizin hangi imkânları sunduğuna bağlıdır.

• API üzerinden alışveriş. Sistemler birbirine doğrudan başvurur. En esnek seçenek: istediğiniz alan kümesi aktarılır, mantık tamamen sizin kontrolünüzdedir. Karşılığında kurulum ve hangi olayda hangi metodun çağrıldığını anlamak gerekir.
• Webhook'lar. CRM, fırsatın ilgili aşamaya geçtiğini kendisi bildirir; saha sistemi de durum değişikliğini. Veriler gereksiz sorgulama olmadan neredeyse anında güncellenir, ancak yeniden deneme mantığını baştan düşünmek gerekir: alıcı taraf erişilemez durumdaysa olay izsiz kaybolmamalıdır.
• Dosya aktarımı. Talepler zamanlanmış biçimde toplu halde, örneğin bir tablodan gider. En hızlı başlangıç: geliştirme gerektirmez, siparişler sabaha hazır olduğunda ve gün içinde nadiren değiştiğinde uygundur.
• Ara konnektör. Ayrı bir köprü servis biçimleri uzlaştırır, eşleşmeleri ve kuralları saklar. Kaynak tek değilse mantıklıdır: taleplerin bir kısmı CRM'den, bir kısmı muhasebe sisteminden, bir kısmı sitedeki formdan gelir.

Evrensel bir yanıt yok ama basit bir pusula var. Müşteri durumu aynı gün bekliyorsa ve temsilci «siparişim nerede» aramalarını yanıtlıyorsa, olay tabanlı alışverişe ihtiyacınız var. Akış bir gün önceden oluşuyor ve istikrarlıysa dosya aktarımı yeter; onu karmaşıklaştırmak ise ancak çözemediği somut bir ihtiyaç ortaya çıktığında anlamlıdır.

itlogist; AmoCRM, Bitrix24, 1C ve Excel ile entegrasyonu destekler — talepler alışılmış kaynaktan, elle yeniden yazılmadan işe düşer. Talebin sonrasında ne olduğu — çalışanlara dağıtımı, harita üzerinde gerçek zamanlı rotalar, fotoğraflı rapor ve kontrol listeleri içeren saha çalışanı mobil uygulaması, durumları gösteren müşteri portalı — itlogist'in imkânları sayfasında toplanmıştır.

Doğrunun kaynağı, eşleşme anahtarı ve hata yönetimi

Entegrasyon sorunlarının çoğu teknik değil, mutabakata dairdir. Aşağıda, yanıtları alışverişin her gün gözetim gerektirmeden çalışıp çalışmayacağını belirleyen dört soru var.

• Eşleşme anahtarı. Saha sistemindeki talep, CRM'deki fırsatla hangi alan üzerinden eşleşiyor — fırsat numarası, iç kimlik, sipariş numarası. Anahtar tek, değişmez olmalı ve iki yöne de aktarılmalıdır. Telefon ya da adres üzerinden eşleştirme, aynı müşterinin tekrarlanan siparişlerinde dağılır.
• Her alan için doğrunun kaynağı. Adreste kim yetkili, teslim zamanında kim, tutarda kim. Temsilci CRM'de zaman aralığını değiştirdiyse, sevkiyat sorumlusu da saha sisteminde değiştirdiyse, kazanan sonradan tıklayan değil, kuralla belirlenmiş olan olmalıdır.
• Tek bir durum modeli. CRM'deki huni aşamaları ile icra durumları farklı şeylerdir. Açık bir eşleştirme tablosu gerekir: hangi operasyonel durum fırsatı hangi aşamaya taşır ve hangi geçişler yasaktır. Aksi halde her yeniden teslim denemesinde fırsat geriye doğru kaymaya başlar.
• Hata anındaki davranış. Adres boşsa, müşteri bulunamazsa ya da alıcı taraf yanıt vermezse ne olur. İşleyen senaryo şudur: talep sessizce kaybolmaz, yeniden deneme kuyruğuna ya da elle incelenecek listeye düşer ve bu listeden sorumlu biri vardır.

Geç akla gelen iki şey daha var. Birincisi, yeniden gönderim mükerrer kayıt oluşturmamalı: olay iki kez geldiyse ikinci deneme yeni bir talep açmak yerine mevcut olanı güncellemek zorundadır. İkincisi, erişim yetkileri: entegrasyon hesabı yalnızca alışveriş için gerekli olanı görür ve değiştirir, erişimi de bir gün parolasıyla birlikte ayrılacak belirli bir çalışana bağlı değildir.

Devreye alma sırası: tek senaryodan tüm akışa

Entegrasyonu hemen tüm genişliğiyle başlatmamak gerekir. İşleyen sıralama şöyledir ve genellikle birkaç kısa yinelemeye sığar.

• Tek bir senaryoyu baştan sona yazın. En yaygın sipariş tipini alın ve CRM'deki aşamadan tamamlanma işaretine kadar izleyin. Standart dışı durumları — iadeler, kısmi retler, tekrar ziyaretler — ikinci adımda ekleyin.
• Alan haritasında mutabık kalın. İşte o dört sütunlu tablo. İki taraf da onaylamadan kuruluma başlamak erkendir.
• Verileri düzene sokun. Normalleştirilmiş adresler, güncel telefonlar, erişim notları. Entegrasyon çöpün aktarımını da hızlandırır: kötü adres yalnızca saha çalışanına daha çabuk ulaşır.
• Test akışında deneyin. İki yönde on kadar talep, bilerek hatalı olanlar dahil: adressiz, mükerrer, atamadan sonra iptal edilmiş.
• Elle taşımayı kaldırın. Alışveriş çalışmaya başlar başlamaz eski yöntem iptal edilmelidir. Paralel iki şema her zaman veri farkıyla ve hangisinin doğru olduğu tartışmasıyla biter.
• Destek konusunda anlaşın. Hata kuyruğuna kim bakıyor, ne kadar hızlı tepki veriyor, sistemlerden biri erişilemez olduğunda ne yapıyor.

Sonucu ölçmek için öncesinde ve sonrasında kaydedilen birkaç basit gösterge yeter: fırsatın ilgili aşamaya geçmesinden talebin sevkiyat masasında görünmesine kadar ne kadar süre geçiyor, kaç sipariş elle açılıyor, temsilciler durum sormak için sevkiyat masasını ne sıklıkla arıyor. Genellikle ilk değişen bu sonuncusudur — bilginin artık insanlar üzerinden değil, sistem üzerinden aktığı da oradan görülür.

Buradaki giriş eşiği sanıldığından düşüktür: başlangıç 7 gün sürer, uzun vadeli sözleşme olmadan; platform ise 5 ila 100 saha çalışanı olan ekipler için tasarlanmıştır. Yani CRM bağlantısını canlı sipariş akışında deneyip bir ay içinde kaydettiğiniz başlangıç değerleriyle karşılaştırabilirsiniz.