Tedarikçi sözleşmesi imzalamadan önce nelere dikkat etmelisiniz?

E-pin ve dijital ürün satışına başlarken çoğu girişimci enerjisini siteye, reklama ve fiyatlandırmaya harcar; tedarikçiyle imzalanacak sözleşmeyi ise "standart bir kağıt işi" sanıp göz ardı eder. Oysa mağazanızın can damarı budur: stok kesintisi, API'nin çökmesi ya da fiyat farkının kime yazılacağı gibi sorular gerçek para kaybına dönüşür. Bu yazıda bir tedarikçi sözleşmesini imzalamadan önce satır satır kontrol etmeniz gereken maddeleri, gerçek senaryolarla anlatıyoruz.

Sözleşmede "kağıt üstünde iyi" görünen ama pratikte sizi çıplak bırakan maddeler hangileri?

Turkpin, Pinabi gibi büyük e-pin toptancılarının standart sözleşme şablonları genelde tedarikçi lehine yazılır — bu normaldir, çünkü şablonu onlar hazırlar. Sorun, bu şablonu okumadan imzalamakta. En sık gözden kaçan üç madde şunlardır:

• Tek taraflı fiyat değişikliği hakkı: Tedarikçi, önceden haber vermeden ürün fiyatını değiştirebiliyor mu? Değiştirebiliyorsa sizin sitenizdeki fiyat ne kadar geriden takip edecek?
• Stok garantisi olmaması: "Stok mevcut olduğu sürece" ifadesi, sipariş anında ürünün olmama riskini tamamen size (ve dolayısıyla müşterinize) yükler.
• Mücbir sebep tanımının genişliği: Bazı sözleşmelerde "sistem bakımı", "yayıncı tarafındaki gecikme" gibi ifadeler mücbir sebep sayılıp tedarikçiyi her türlü sorumluluktan muaf tutar.

Bu maddeleri görmezden gelmek demek, müşteriniz "param nerede" diye yazdığında elinizde hiçbir dayanak kalmaması demektir. Pinova gibi bir sistemle çalışıyorsanız bile, alt tedarikçi sözleşmesi sizin mağazanızın hukuki zemini olmaya devam eder — yazılım sadece süreci otomatikleştirir, sorumluluğu değiştirmez.

Gerçek hayattan bir örnek vermek gerekirse: bir dijital ürün mağazası, sözleşmesinde "stok mevcut olduğu sürece" ibaresini fark etmeden imzalamış ve yoğun bir kampanya döneminde yüzlerce sipariş almış, ancak siparişlerin dörtte biri stokta olmayan ürünlere düşmüştü. Tedarikçi sözleşmeye dayanarak sorumluluk kabul etmemiş, tüm iade süreci ve müşteri memnuniyetsizliği mağazanın üstünde kalmıştı. Bu tarz senaryolar, sözleşme okuma alışkanlığının neden bir lüks değil zorunluluk olduğunu gösterir.

Fiyat ve stok garantisi olmadan bu işe nasıl güvenle devam edersiniz?

Fiyat ve stok konusunda net taahhüt almak, bir e-pin mağazasının hayatta kalması için pazarlık masasında en çok direnmeniz gereken iki başlıktır. İdeal bir sözleşmede şunlar açıkça yazmalı: fiyat değişikliği en az kaç saat/gün önceden bildirilecek, bildirim hangi kanaldan (API webhook, e-posta, panel) yapılacak, ve stok tükendiğinde sipariş otomatik reddedilip parayı iade mi edecek yoksa beklemede mi kalacak.

Burada gözden kaçırılan bir ayrıntı da "yansıma hızı"dır: tedarikçi fiyatı değiştirdiğinde, bu değişikliğin API üzerinden size ulaşması ile sizin sitenizdeki fiyatın güncellenmesi arasında geçen süre de bir risk penceresidir. Elle güncelleme yapan mağazalarda bu pencere saatlerce açık kalabilir; bu süre içinde eski (düşük) fiyattan gelen siparişler doğrudan zarara dönüşür. Sözleşmeye "gerçek zamanlı fiyat API'si sağlanacaktır" gibi bir madde eklettirmek, en azından teknik olarak bu riski en aza indirmenizi sağlar.

Sözleşmede bu garantiler yazılı olsa da, onu operasyonel olarak takip edecek bir sisteminiz yoksa garanti kağıt üzerinde kalır. Bu yüzden hukuki metin kadar, o metni gerçek zamanlı uygulayacak teknik altyapı da önemlidir.

API çöktüğünde ya da yanıt geciktiğinde fatura kime kesilir?

E-pin sektöründe en sinir bozucu an, müşteri "ödemeyi yaptım, kodum nerede" diye yazdığında tedarikçi API'sinin yanıt vermemesidir. Bu durumda üç taraf vardır: siz, tedarikçi, müşteri. Sözleşmede bu üçgende sorumluluğun nasıl paylaşıldığı net olmalı:

• API kesintisi kaç dakikayı/saati aşarsa tedarikçi "hizmet kesintisi" kabul ediyor ve tazminat/telafi öngörüyor mu?
• Kesinti sırasında alınan ama teslim edilemeyen siparişler için tedarikçi geç teslimat mı yapacak, yoksa iptal mi edecek?
• Kesinti kaynaklı müşteri şikayetleri (iade talebi, banka itirazı/chargeback) tedarikçinin mi sizin mi sorumluluğunuzda?

Gerçekte çoğu küçük-orta tedarikçi sözleşmesi bu konuda sessiz kalır, yani "belirtilmeyen her şey satıcı mağazanın sorunu" anlamına gelir. Bu yüzden sözleşmeye ek olarak, kendi tarafınızda bir tampon mekanizma kurmanız gerekir: sipariş API'ye ulaşamazsa müşteriden parayı hemen tahsil etmeyip beklemeye almak, ya da otomatik iade tetiklemek gibi. Pinova'daki sipariş kuyruğu ve yeniden deneme (retry) mantığı tam olarak bu boşluğu kapatmak için var — API yanıt vermezse sipariş kaybolmaz, sırada bekler ve tekrar denenir.

Kurumsal alım süreçlerinde bu konu genelde bir "hizmet seviyesi taahhüdü" (SLA) yüzdesiyle ifade edilir: örneğin "aylık uptime %99,5'in altına düşerse sonraki ay faturasından indirim yapılır" gibi. E-pin sektöründe bu düzeyde resmi SLA veren tedarikçi sayısı azdır, ama en azından sözlü ya da yazılı bir "ortalama kesinti süresi" beklentisi konuşmak, hangi tedarikçinin gerçekten güvenilir olduğunu anlamanızı kolaylaştırır. Yeni bir tedarikçiyle çalışmaya başlamadan önce, mevcut kullanıcı yorumlarını ve forumlardaki şikayetleri taramak da sözleşmedeki iyi niyetli ifadelerin pratikte ne kadar karşılık bulduğunu gösterir.

Yanlış teslimat ya da fiyat farkında zararı kim üstlenir?

Bir e-pin yanlış teslim edilirse (kırık kod, yanlış bölge, kullanılmış kod) ya da tedarikçi ürünü zamlayıp sizin panelinize geç yansıtırsa, zarar nereye yazılır? Sözleşmede bulunması gereken üç koruma maddesi:

• Geçersiz kod garantisi: Tedarikçi tarafından teslim edilen kod çalışmıyorsa, ücretsiz yenisi kaç iş günü içinde verilir?
• Ceza bedeli tavanı: Yanlış teslimattan doğan müşteri mağduriyeti için tedarikçinin ödeyeceği tazminatın bir üst sınırı var mı, yoksa sınırsız mı?
• Fiyat farkı devri: Sipariş anındaki fiyatla teslimat anındaki fiyat arasında oluşan farkı kim karşılıyor — siz mi, tedarikçi mi?

Bu maddeler yoksa, pratikte zararın tamamı satıcı mağazaya (yani size) kalır; çünkü müşteri parasını sizden aldı, sizden geri ister. Tedarikçiyle yaşadığınız anlaşmazlık ise ayrı, uzun ve genelde sonuçsuz bir süreçtir. Bu yüzden sözleşme imzalamadan önce, tedarikçinin geçmiş müşterilerinden (varsa) referans almak da işe yarar — özellikle "yanlış kod" ve "ceza bedeli" konusunda gerçekte nasıl davrandıklarını sormak.

Anlaşmazlık anında en değerli şey kanıttır. Tedarikçiyle yazışmalarınızı, API yanıtlarını ve sipariş loglarını sistematik olarak saklamıyorsanız, "biz öyle demedik" karşısında elinizde hiçbir şey kalmaz. Bu yüzden manuel çalışan mağazaların çoğu, anlaşmazlık çıktığında geriye dönük kanıt sunamadıkları için haklı oldukları durumlarda bile kaybeder. Otomatik sipariş/işlem geçmişi tutan bir sistemle çalışmak, sözleşmedeki hakları fiilen kullanılabilir kılan en pratik önlemdir.

Ödeme vadesi ve bakiye sistemi sözleşmede nasıl kilitlenmeli?

E-pin tedarikçileriyle çalışma iki modelden birine dayanır: ön ödemeli bakiye (cüzdana para yatırıp oradan harcama) ya da vadeli fatura (ay sonunda toplu ödeme). Her iki modelde de sözleşmede netleştirilmesi gereken noktalar farklıdır:

• Bakiye modelinde: Yatırdığınız bakiye iade edilebilir mi (örneğin işbirliğini sonlandırırsanız), yoksa "kullan ya da kaybet" mi? Bakiyeye faiz ya da vade sonu kesinti uygulanıyor mu?
• Vadeli modelde: Ödeme günü kaçırılırsa hesap ne zaman dondurulur? Kısmi ödeme kabul ediliyor mu?
• Kur farkı: Fiyatlar dolar/euro bazlıysa, kur hangi kaynaktan ve hangi saatte sabitleniyor?

Bu maddeler özellikle çok tedarikçili çalışan mağazalar için kritik: her tedarikçinin kendi bakiye/vade kuralı olduğunda, elle takip etmek neredeyse imkansız hale gelir. Pinova'nın site cüzdanı ve tedarikçi entegrasyon modülü, sizin kendi bakiyenizi (müşterilerinizin cüzdanını) tedarikçiye yatırdığınız bakiyeden ayrı tutar — böylece hangi tarafta ne kadar risk taşıdığınızı her an görebilirsiniz.

Bir diğer önemli nokta da mutabakat (reconciliation) sıklığıdır. Ay sonunda tedarikçinin faturasıyla kendi sipariş kayıtlarınız uyuşmuyorsa, farkın nereden geldiğini bulmak günler alabilir — özellikle elle Excel tutuyorsanız. Sözleşmede tedarikçinin size düzenli (haftalık ya da aylık) dökümlü işlem raporu sunmasını şart koşmak, bu mutabakat sürecini basitleştirir. Kendi tarafınızda da her siparişin tedarikçi referans numarasıyla eşleştiği bir kayıt tutmak, olası bir anlaşmazlıkta işinizi kolaylaştırır.

Sözleşmeyi sonlandırmak istediğinizde sizi hangi sürpriz bekler?

İlişkiyi başlatırken kimse ayrılığı düşünmez, ama iş dünyasında tedarikçi değişikliği sık yaşanan bir durumdur — daha iyi fiyat, daha stabil API ya da daha güvenilir bir firma bulduğunuzda geçiş yapmak isteyebilirsiniz. Bu noktada sözleşmenin fesih maddesi belirleyicidir:

• Fesih için minimum bildirim süresi ne kadar (7 gün mü, 30 gün mü, hiç yok mu)?
• Hesabınızda kalan bakiye fesih sonrası kaç gün içinde iade edilir?
• Cezai şart (erken fesih tazminatı) var mı, varsa tutarı nedir?
• API erişimi fesihle birlikte anında mı kesiliyor, yoksa bekleyen siparişler tamamlanana kadar açık mı kalıyor?

Bu maddeler eksikse, tedarikçi değiştirmek istediğinizde parası bloke olmuş, bekleyen siparişleri tamamlanmamış bir mağazayla baş başa kalabilirsiniz. Deneyimli satıcılar, hiçbir zaman tek tedarikçiye tam bağımlı kalmaz; en az iki tedarikçiyle paralel sözleşme yaparlar ki biri sorun çıkardığında diğerine anında geçiş yapılabilsin. Bunu manuel yönetmek zor olsa da, çoklu tedarikçi API entegrasyonunu destekleyen bir altyapıyla teknik geçiş dakikalar sürer.

Son olarak, fesih maddesiyle birlikte genelde göz ardı edilen bir başka konu da veri ve rekabet kısıtlamalarıdır. Bazı sözleşmelerde "ilişki sona erdikten sonra X ay boyunca rakip tedarikçiyle çalışılamaz" gibi gizli bir rekabet yasağı maddesi bulunabilir. Bu tür bir madde, özellikle büyümekte olan bir mağaza için ciddi bir kısıtlama yaratır; imzalamadan önce mutlaka fark edilmesi gerekir. Aynı şekilde, sizin sitenizde biriken sipariş/müşteri verilerinin tedarikçiyle paylaşılıp paylaşılmadığı, fesih sonrası bu verilerin ne olacağı da sorulması gereken bir sorudur.