Mücevher markalarında POS ve CRM, üç ortak kimlik ve tek yönlü ve hatası izlenen bir aktarım düzeniyle entegre edilir. Ortak kimlikler ürünün varyant kodu, mağazanın kodu ve satışın sipariş ya da fiş numarasıdır. Akış ERP’den siteye ve POS’a stok, POS’tan ve e ticaret altyapısından kayıt sistemine satış, kayıt sisteminden reklam sistemlerine eşleşen olay şeklinde kurulur. Her bildirim tekilleştirilir, başarısız olan bir hata kuyruğuna düşer ve iade, değişim, kapora ve kısmi ödeme satıştan ayrı olaylar olarak eşleştirilir. Entegrasyonun zor kısmı yazılım değil, kimliklerdir. POS’taki ürün kodu sitedekiyle aynı değilse, fişe randevu kodu yazılmıyorsa ve iade satışın yanına bağlanmıyorsa en pahalı entegrasyon bile yanlış bir rapor üretir.
Pırlanta ve tasarım mücevher markalarında ölçüm altyapısı, kayıt sistemi ve reklam entegrasyonu kuruyorum. İstanbul’da iki mağazası olan bir pırlanta markasında online satış Shopify üzerinde çalışıyor, mağazalarda ayrı bir POS ve ön muhasebe yazılımı kullanılıyordu. Eşleşen satışlar HubSpot’ta toplanıp her gün Google’a ve Meta’ya gönderildi. Mayıs’ta dijital kaynaklı mağaza müşterisinin yüzde 84’ü eşleştirilebiliyordu. Bütün süreci mücevher dijital pazarlama vaka analizinde anlattım. Bu yazıda entegrasyonun teknik tarafını anlatıyorum.
POS ile CRM neden birbirinden habersizdir?
Çünkü ikisi farklı işler için kurulmuştur. POS fişi kesmek, ödemeyi almak ve stoktan düşmek için vardır. Müşterinin kim olduğunu, hangi reklamı gördüğünü ve hangi danışmanla mesajlaştığını bilmez. Kayıt sistemi ise konuşmayı, randevuyu ve danışmanı bilir ama mağazada kesilen fişi görmez. Vakadaki markada başlangıçta iki mağazanın aylık cirosu 11,16 milyon TL’ydi ve satışın hangi kısmının reklamdan geldiğini bilen kimse yoktu. GA4 ve iki reklam paneli de her biri kendi satın alma sayısını raporluyordu ve mağaza satışı hiçbir yerde görünmüyordu.
SKU, mağaza ve sipariş kimliği nasıl kurulur?
Her biri tek bir yerde doğacak ve hiç değişmeyecek şekilde. Kimliğin doğduğu sistem onun sahibidir, diğer sistemler yalnızca okur.
| Kimlik | Nerede doğar? | Nerede kullanılır? |
|---|---|---|
| Varyant kodu | ERP | Site, POS, ürün feedi, kayıt sistemi ve ayırtma |
| Mağaza kodu | ERP | POS fişi, stok, randevu, mağaza sayfası ve İşletme Profili |
| Online sipariş numarası | E ticaret altyapısı | Ödeme, iade, değişim ve reklam sistemine giden satın alma |
| POS fiş numarası | POS | Mağaza defteri ve eşleşen mağaza satışı |
| Randevu kodu | Kayıt sistemi | Mesaj, hatırlatma ve POS fişinin açıklama alanı |
| Kişi kimliği | Kayıt sistemi | Konuşma, randevu, satış ve onay durumu |
Vakadaki markanın kataloğunda 612 model ve 2.140 varyant vardı. Mağaza bazında stok ürün sayfasında ve müşteri hizmetleri panelinde her varyantın hangi mağazada denenebildiğini gösteriyordu ve bilgi ERP’den saatte bir güncelleniyordu. Bu ancak POS’taki ürün kodu sitedeki varyant koduyla aynı olduğu için mümkündü. Varyant kimliğinin ürün feedindeki yerini pırlanta ürün feedi yazısında anlattım.
Veri hangi yönde akmalı?
Her bilginin tek bir kaynaktan çıkıp diğerlerine gittiği tek yönlü yollarla. İki sistemin aynı alanı birbirine yazması, hangisinin doğru olduğunun bilinmediği döngüler doğurur.
| Kaynak | Hedef | Ne akar? | Ne sıklıkla? |
|---|---|---|---|
| ERP | Site, POS ve feed | Stok, fiyat ve yerine koyma maliyeti | Stok saatte bir, fiyat günlük sabit zamanlarda |
| E ticaret altyapısı | Kayıt sistemi | Sipariş, ödeme onayı, iade, değişim | Olay anında |
| POS | Kayıt sistemi | Fiş, ürün, tutar, randevu kodu | Olay anında ya da günde birkaç kez |
| Mesaj kutusu | Kayıt sistemi | Konuşma, randevu, ayırtma, onay | Olay anında |
| Kayıt sistemi | Google ve Meta | Onaylı ve eşleşen satış olayları | Her gün |
Vakadaki markada fiyat altın kuruna bağlıydı ve gün içinde altı kez değişiyordu. Fiyat değişimi sabah ve öğleden sonra olmak üzere günde iki sabitlemeye indirildi, feed fiyatla aynı anda gönderildi. Ben aynı sabitlemeyi POS fiyatına da uyguluyorum, böylece mağazada ve sitede aynı saatte aynı fiyat görünür.
Webhook ve hata kuyruğu nasıl kurulur?
Her bildirimin bir kimliği, her başarısızlığın bir kaydı olacak şekilde. Olay anında akan veriler çoğu zaman webhook denen sunucudan sunucuya giden bildirimlerle taşınır. E ticaret altyapısı bir sipariş ödendiğinde ya da iade oluştuğunda kayıt sistemine haber verir. Bu bildirimler gecikebilir, sırası karışabilir ya da aynı olay iki kez gelebilir. Entegrasyon bunu baştan varsayarak kurulur.
- Tekilleştirme. Her bildirim olay kimliğiyle kaydedilir, aynı kimlik ikinci kez gelirse işlenmez.
- Sıra kontrolü. İade bildirimi siparişten önce gelirse bekletilir ve sipariş geldiğinde işlenir.
- Hata kuyruğu. İşlenemeyen her bildirim nedeniyle birlikte bir kuyruğa düşer ve belirli aralıklarla yeniden denenir.
- Günlük mutabakat. Her sabah POS’taki fiş sayısı ve tutarı kayıt sistemindekiyle, e ticaret altyapısındaki sipariş sayısı da kayıt sistemindekiyle karşılaştırılır.
- Uyarı. Kuyrukta bir günden uzun bekleyen kayıt ya da tutmayan mutabakat sorumluya bildirilir.
Bu beş adım benim kullandığım düzendir. Vakadaki markada sessiz hatanın ne kadar pahalı olabileceği Meta tarafında görüldü. Mağaza satışları başlangıçta haftalık toplu dosyayla gönderiliyordu ve Ocak’ın ilk üç haftasında gönderilen 163 olayın 97’si reddedildi, çünkü Meta yedi günden eski bir olay zamanını kabul etmiyor ve böyle bir olay içeren isteğin tamamını reddediyor. Olaylar gitmiş gibi duruyor, ama hiçbir kampanyaya ulaşmıyordu. Yükleme her sabah çalışan günlük bir işe çevrilince sorun bitti.
| Hata defteri ölçüsü | Pay | Payda |
|---|---|---|
| Kuyruğa düşme oranı | İşlenemeyen bildirim | Gelen bütün bildirimler |
| Mutabakat farkı | POS ile kayıt sistemi arasındaki fiş farkı | POS’taki fiş sayısı |
| Reddedilen olay oranı | Reklam sisteminin reddettiği olay | Gönderilen olay |
| Kodlu fiş oranı | Randevu kodu girilmiş fiş | Dijital randevudan gelen müşteriye kesilen fiş |
İade ve kısmi ödeme nasıl eşleştirilir?
Satışın kendisine bağlı ayrı olaylar olarak. Mücevherde satış nadiren tek bir ödemeyle ve tek bir sonuçla biter. Ayırtma, kapora, değişim, kısmi iade ve ters ibraz aynı satışın etrafında dolaşır. Her biri satışın kimliğine bağlanmazsa rapor ya satışı iki kez sayar ya da iadeyi hiç görmez.
| Durum | Kayıt sisteminde ne olur? | Reklam sistemine ne gider? |
|---|---|---|
| Online sipariş, ödeme onayı | Satış, ödeme onayı ve sahtecilik incelemesinden sonra | Satın alma, bir kez |
| Mağazada ayırtma ya da kapora | Ayırtma kaydı, satış değil | Gitmez |
| Kalan ödemeyle mağazada satış | Tek satış, ayırtmaya bağlı | Eşleşen mağaza satışı, toplam tutarla |
| Kısmi iade | Satış tutarı iade edilen ürün kadar düşer | Değer düzeltmesi |
| Tam iade ya da ters ibraz | Satış iptal | Dönüşüm geri alınır |
| Mağazada değişim | Online siparişin değişimi, yeni satış değil | Gitmez |
Vakadaki markada bir online sipariş ancak ödeme onayından ve sahtecilik incelemesinden geçince satış sayıldı. Başlangıçta dönüşüm sipariş anında gönderiliyor, iade ve ters ibraz hiç geri alınmıyordu, oysa online siparişlerin yüzde 18’i iade oluyordu. Geçmiş iade ve ters ibrazlar dönüşüm düzeltmesiyle geri alındı. Google’da yüklenmiş bir dönüşümü geri almak ya da değerini değiştirmek ilk kayıttan sonraki 55 gün içinde mümkün, bu yüzden iade akışı da günlük çalışmalıdır. Ödemenin kendisinde de dikkat gerekir. Kuyum ürünlerinde kredi kartı taksidi yasal olarak sınırlıdır ve reklamda ya da sitede bu sınırın ötesinde bir taksit vaadi kullanılmaz.
Yerine koyma maliyeti entegrasyona nasıl girer?
ERP’den her gün, varyant kodu üzerinden. Vakadaki markada muhasebe her ürünün maliyetini stoğa girdiği günkü fiyatla tutuyordu. Altın yükselirken bu yöntem eski stoğu olduğundan karlı gösteriyordu. Alyans grubunun brüt kâr marjı stoğa giriş maliyetiyle yüzde 44, yerine koyma maliyetiyle yüzde 30 çıkıyordu. Katkı defteri her satıştan iadeyi, ürünün bugünkü yerine koyma maliyetini, sigortalı kargoyu, ödeme komisyonunu ve mağaza satış primini düşüyordu. Bu hesabın yapılabilmesi için maliyet kayıt sistemine satışla aynı varyant koduyla gelmelidir.
Entegrasyonu kim sahiplenir?
Teknik akışı bir kişi, kimliklerin girilmesini ise mağaza ekibi. Vakadaki markada kurulan sistem ilk iki haftada beklendiği gibi çalışmadı, çünkü randevu kodu satışların yalnızca yüzde 38’inde POS’a girilmişti. Neden teknik değil insaniydi. Danışmanlar kodun girildiği satışın primlerini böleceğini düşünüyordu. Prim kuralı yazılı hale gelince Şubat’ta kod girme oranı yüzde 91’e çıktı. Entegrasyonun sahibi bu yüzden yalnızca teknik ekip olamaz. Mağaza müdürü kodlu fiş oranını haftalık toplantıda okur. Mücevher için Klaviyo ve CRM’in hangi işlerde kullanıldığını ayrı bir yazıda ele alıyorum.
POS ve CRM entegrasyonunda en sık hangi hatalar yapılır?
- POS’ta ve sitede farklı ürün kodları kullanmak. Mağaza stoğu sitede görünmez, satış ürüne bağlanmaz.
- İki sistemin aynı alanı birbirine yazması. Hangi değerin doğru olduğu bilinmez.
- Bildirimleri tekilleştirmemek. Aynı satış iki kez sayılır.
- Hata kuyruğu tutmamak. Kaybolan kayıt aylar sonra fark edilir.
- Kaporayı satış saymak. Satış ödeme tamamlanmadan raporda görünür.
- İadeyi reklam sistemine geri yansıtmamak. Sistem iade edilen siparişi başarı diye öğrenir.
- Haftalık toplu yükleme yapmak. Meta yedi günden eski olayları reddeder.
Entegrasyon markanızda nasıl kurulur?
Önce ERP, POS, e ticaret altyapısı ve mesaj kutusundaki ürün, mağaza ve kişi kimliklerini yan yana koyun ve aynı olmayanları eşitleyin. Sonra aktarım tablosunu yazın, her alanın tek bir kaynağı olsun. Ardından webhook bildirimlerini tekilleştirmeyle, sıra kontrolüyle ve hata kuyruğuyla kurun, her sabah çalışan bir mutabakat ve reklam sistemlerine günlük yükleme ekleyin. İade, değişim, kapora ve kısmi ödeme kurallarını yazmak ve kodlu fiş oranını mağaza toplantısına koymak bu düzenin son adımıdır. Eşleştirme kurallarının mantığını pırlanta mağaza satışı ölçümü yazısında, GA4 ile reklam panellerinin neden farklı rakam gösterdiğini pırlanta GA4 ve reklam verisi farkı yazısında anlatıyorum. Online tarafta ödemenin nerede yarım kaldığını ise pırlanta sitelerinde ödeme terkinin nasıl azaltılacağını anlattığım yazıda ayrıca ele alıyorum.
Entegrasyon tarafındaki çalışma biçimimi hizmet sayfasının mücevher markaları için CRM ve mağaza satışı ölçümü bölümünde bulabilirsiniz. Ölçümün bütün stratejideki yeri mücevher pazarlaması rehberinde anlatılıyor.
Sık sorulan sorular
POS ile CRM’i bağlamak için pahalı bir entegrasyon yazılımı gerekir mi?
Çoğu zaman gerekmez. Asıl iş ortak kimliklerin kurulması ve tek yönlü bir akışın yazılmasıdır. Vakadaki markada eşleşen satışlar HubSpot’ta toplandı, Google’a Data Manager üzerinden çevrimdışı dönüşüm olarak, Meta’ya Conversions API ile gönderildi.
Haftalık toplu yükleme ölçümü bozar mı?
Meta tarafında bozar. Vakadaki markada mağaza satışları haftalık dosyayla gönderildiğinde Ocak’ın ilk üç haftasında 163 olayın 97’si reddedildi, çünkü Meta yedi günden eski olay zamanını kabul etmiyor. Yükleme günlük işe çevrilince reddedilme durdu.
Kapora alındığında satış olarak mı kaydedilir?
Kaydedilmez. Kapora bir ayırtmadır ve kendi kaydı olarak tutulur. Satış, kalan ödeme alınıp fiş kesildiğinde ayırtmaya bağlı tek bir kayıt olarak yazılır ve reklam sistemine de o zaman toplam tutarla gider.
İade edilen online sipariş reklam sisteminden nasıl düşülür?
Dönüşüm düzeltmesiyle. Vakadaki markada online siparişlerin yüzde 18’i iade oluyordu ve başlangıçta bunlar hiç geri alınmıyordu. Geçmiş iade ve ters ibrazlar düzeltmeyle geri alındı. Google’da bu düzeltme ilk kayıttan sonraki 55 gün içinde yapılabildiği için iade akışı günlük çalışmalıdır.
Entegrasyonun doğru çalıştığı hangi kayıtlarla doğrulanır?
Hata kuyruğu, günlük uzlaştırma raporu ve iade kaydıyla. Ben POS’taki işlem sayısını CRM’e ulaşan işlem sayısıyla her gün karşılaştırıyor, farkı hata kuyruğundaki kayıtlarla açıklıyorum. İade ve kısmi ödemelerin doğru siparişe bağlandığını her hafta rastgele seçtiğim işlemlerle kontrol ediyorum. Açıklanamayan fark kalırsa entegrasyonu tamamlanmış saymıyorum.
Kaynaklar
Bu yazıdaki platform ve mevzuat bilgilerini Ekim 2026’da aşağıdaki resmi kaynaklardan kontrol ettim.
Reklamların satış getirmiyor mu?
Reklam hesabını birlikte inceleyelim, nerede bütçe kaybettiğini netçe görelim.
Ücretsiz Ön Görüşme