Çoğu kişi Telegram botunun bir satış sistemi olduğunu sanır. Çalışıyor gibi görünüyor: kullanıcı /start yazıyor, menü açılıyor, ürün seçiyor, ödeme yapıyor, kod düşüyor. İlk elli siparişte her şey kusursuz. Bot ucuz, hızlı, kurulumu bir gecede biter. Ama bot bir arayüzdür; sipariş, stok, tahsilat ve muhasebe katmanlarını taşıyan bir altyapı değildir. Bu ayrımı kaçırdığın an teknik borç birikmeye başlar ve faturayı hep en yoğun günde ödersin.
Bot mimarisinin sorunu kodun kalitesi değil, durumun nerede tutulduğudur. Tek bir süreç, çoğu zaman tek bir JSON ya da hafızada tutulan sözlük, sıralı çalışan mesaj kuyruğu. Bu yapı düşük hacimde mükemmel davranır. Hacim arttığında eşzamanlılık, yeniden deneme ve tutarlılık problemleri ortaya çıkar; aynı kod aynı e-pini iki kişiye satar. Aşağıda bu çatlakları tek tek açacağım, sonra botu kapatmadan dijital ürün satış yazılımına nasıl geçileceğini mimari olarak anlatacağım.
Telegram botu bir satış altyapısı mı, yoksa sadece arayüz mü?
Bir satış sisteminin taşıması gereken minimum katmanlar şunlar: kimlik, sepet, sipariş durumu, stok kilidi, tahsilat mutabakatı, teslimat kaydı, iade süreci, raporlama. Telegram botu bunların hiçbirini tanımlamaz; sadece kullanıcıyla konuşur. Sen bu katmanları bot kodunun içine gömdüğünde aslında bir yazılım yazmış olursun, ama test edilmemiş, kayıt tutmayan, yedeklenmeyen bir yazılım.
Doğru kurgu şudur: bot bir istemci olarak kalır, kararları veren tarafta gerçek bir e-pin satış yazılımı durur. Kullanıcı bota yazdığında bot sadece istek taşır; stok kilidini, ödeme doğrulamasını ve teslimatı sunucu tarafındaki sistem yapar. Bu ayrım yapıldığı anda hem bot sadeleşir hem işin denetlenebilir hale gelir. Pinova'nın rolü de burada netleşiyor: e-pin satmaz, e-pin satan işletmenin karar katmanını sağlar.
Bot mantığı neden belirli bir hacimden sonra çatlıyor?
İlk kırılma noktası eşzamanlılık. İki kullanıcı aynı saniyede son adet ürüne talip olduğunda bot tipik olarak "stok var mı?" diye bakar, evet cevabını alır ve ikisine de kod verir. Veritabanı düzeyinde satır kilidi veya atomik güncelleme olmadan bu durum kaçınılmazdır. Sonuç: iki müşteriye satılmış tek kod, iki şikâyet ve zedelenmiş itibar.
İkinci kırılma yeniden deneme davranışıdır. Telegram mesaj teslimini garanti etmez; ağ hatasında istemci aynı isteği tekrar gönderebilir. Idempotency anahtarı tanımlanmamış bir botta bu, tek ödemeye karşılık iki teslimat demektir. Üçüncüsü ise süreç ölümü: bot düştüğünde yarım kalan siparişin hangi aşamada olduğunu kimse bilmez, çünkü durum hafızadaydı. Bir dijital ürün satış scripti bu üç sorunu tasarım gereği çözer; sipariş her adımda kalıcı bir durumla kaydedilir.
| Teknik konu | Telegram botu | Satış yazılımı | Risk |
|---|---|---|---|
| Stok kilidi | Genellikle yok | Atomik rezervasyon | Çift satış |
| Idempotency | Tanımsız | Sipariş anahtarı ile tekil | Çift teslimat |
| Ödeme mutabakatı | Elle kontrol | Geçit callback doğrulaması | Ödemesiz teslim |
| Durum kalıcılığı | Hafıza veya dosya | Veritabanı, işlem güvenli | Kayıp sipariş |
| Yetki ve rol | Kullanıcı kimliği listesi | Rol bazlı panel yetkisi | İç kötüye kullanım |
| Belge ve kayıt | Yok | Sipariş ve tahsilat kaydı | Mali uyum sorunu |
| Raporlama | Elle sayım | Ürün ve marj raporu | Kör yönetim |
| Yedekleme | Manuel | Zamanlanmış | Stok kaybı |
Ödeme, kayıt ve muhasebe: botun göremediği üç duvar hangileri?
Telegram tarafında en sık görülen pratik, IBAN paylaşıp dekont beklemek. Bu yöntem düşük hacimde yürür, ama iki ciddi sorunu var. Birincisi mutabakat: kimin hangi siparişe ödeme yaptığını eşleştirmek elle yapılan, hataya açık bir iş. İkincisi güven: ön ödeme isteyen bir bota yeni müşteri kolay para yatırmaz, bu yüzden dönüşüm düşer.
Kartlı ödeme geçidi ise bir alan adı, bir yasal metin seti ve sunucu tarafında doğrulanabilir bir callback ister; Telegram botu bu gereksinimleri tek başına karşılamaz. Gerçek bir epin yazılım altyapısında ödeme geçidinin bildirimi sunucu tarafından imza kontrolüyle doğrulanır, sipariş durumu ancak o zaman "ödendi" olur ve teslimat tetiklenir. Bu zincir olmadığı sürece "ödedim ama gelmedi" tartışmaları hiç bitmez.
Bot tabanlı satışta yaşanan sorunların dağılımı
- Stok ve çift teslimat hataları 50%
- Ödeme eşleştirme sorunları 25%
- Süreç düşmesi ve kayıp sipariş 15%
- Yetki ve kayıt eksikliği 10%
Stok ve e-pin havuzu neden tek doğruluk kaynağı olmak zorunda?
E-pin işinde en değerli varlık kod havuzudur ve bu havuzun tek bir yerde, tek bir doğruluk kaynağı olarak tutulması gerekir. Bot bir tarafta, Excel dosyası başka tarafta, tedarikçi paneli üçüncü tarafta olduğunda kaçınılmaz olarak sapma oluşur. Kod kullanılmış mı, rezerve mi, iade mi — bu üç durumu ayıramayan hiçbir sistem güvenilir sayılmaz.
Doğru model şu: her kodun durumu (boşta, rezerve, teslim, iptal) veritabanında tutulur; teslimat sırasında kod önce rezerve edilir, ödeme onayı gelince teslim işaretlenir, iptalde havuza geri döner. Tedarikçi API'si varsa stok anlık çekilir, yoksa yükleme dosyası tekilleştirilerek işlenir. Bu disiplin kurulduğunda gece 03.00'te gelen yüz sipariş bile hata üretmez, çünkü kararı insan değil sistem verir.
Botu kapatmadan geçiş mimarisi nasıl kurulur?
Kimse cirosunu riske atarak göç yapmak istemez, buna gerek de yok. Geçişi üç aşamada yürütmek en güvenli yol. Birinci aşamada yazılımı kur, ürünleri ve kod havuzunu içine aktar, sipariş akışını gerçek ödemeyle test et. Bu aşamada bot hâlâ eski haliyle çalışmaya devam eder; sadece stok yönetimini artık panelden yapıyorsundur.
İkinci aşamada botu istemciye dönüştür: bot artık kod dağıtmaz, kullanıcıyı ürünün site üzerindeki sayfasına yönlendirir ya da yazılımın API'si üzerinden sipariş oluşturur. Üçüncü aşamada bot tamamen bir bildirim ve destek kanalı olur: sipariş durumu, kampanya duyurusu, bakiye hatırlatması. Bu kurguda Telegram'ın en güçlü yanı — anında erişim — korunur, kırılgan yanı — altyapı rolü — ortadan kalkar.
Kod havuzunu bota bakan dosyalardan çıkarıp tek bir veritabanına taşı. Bu tek hamle çift satış hatalarının büyük kısmını daha geçiş bitmeden bitirir.
| Geçiş kontrol maddesi | Doğrulama yöntemi | Öncelik |
|---|---|---|
| Kod havuzu tek kaynakta mı? | Panelde stok sayımı ile karşılaştır | Kritik |
| Eşzamanlı satış testi yapıldı mı? | Son adet ürüne iki paralel istek | Kritik |
| Ödeme callback imzası doğrulanıyor mu? | Sahte bildirimle dene | Kritik |
| Aynı sipariş iki kez tetiklenirse? | Idempotency anahtarı kontrolü | Yüksek |
| Bot API anahtarı sunucuda mı? | Depo ve istemci tarafını tara | Yüksek |
| Yedekleme zamanlanmış mı? | Geri yükleme provası | Yüksek |
| Rol bazlı yetki tanımlı mı? | Personel hesabıyla dene | Orta |
| Bot bildirim kanalına dönüştü mü? | Sipariş durumu mesajını test et | Orta |
Botun arayüz olsun, kararı yazılım versin
Atomik stok yönetimi, doğrulanmış ödeme akışı, otomatik teslimat ve rol bazlı panel tek bir altyapıda hazır.
Telegram botumu tamamen silmem gerekir mi?
Hayır, silmemelisin. Bot müşteriye en hızlı ulaşan kanalın. Yapman gereken tek şey rolünü değiştirmek: teslimat ve stok kararını yazılıma bırak, bot bildirim ve yönlendirme yapsın.
Bot ile yazılımı birbirine nasıl bağlarım?
Yazılımın sipariş ve stok uç noktaları üzerinden. Bot kullanıcının isteğini alır, sunucuya iletir, dönen sonucu mesaj olarak gösterir. Böylece iki kanal aynı veriyi kullanır, sapma olmaz.
Eski sipariş geçmişimi taşıyabilir miyim?
Bot kayıtların dosya veya veritabanı halinde duruyorsa müşteri ve sipariş kaydı olarak aktarılabilir. Aktarım öncesi tekilleştirme yapmak, raporların doğru çıkması için şarttır.
Geçiş sırasında satış kesintisi olur mu?
Doğru sırayla yapılırsa olmaz. Bot çalışmaya devam ederken yazılım kurulur ve test edilir; yönlendirme ancak testler geçtikten sonra açılır. Kurulum ve test genelde aynı hafta tamamlanır.
Telegram botu işi başlatmak için harika bir araç; işi büyütmek için yeterli bir altyapı değil. Atomik stok yönetiminin, doğrulanmış ödeme akışının ve kayıt tutan bir sipariş motorunun pratikte nasıl çalıştığını görmek istiyorsan canlı demo üzerinden bir sipariş oluştur, sonra aynı senaryoyu kendi botunda dene; farkı tek bir denemede net göreceksin.