Mobile Legends elması satan işletmelerin çoğu otomasyonu bir düğme sanır. "Panel otomatik teslimat yapıyor mu?" diye sorar, cevap "evet" olunca işin bittiğini düşünür. Oysa otomatik teslimat bir özellik değil, birbirine bağlı beş-altı adımın hepsinin hatasız çalışması gereken bir zincirdir. O zincirin tek halkası insan müdahalesine muhtaçsa, sistem "otomatik" değildir; sadece bekleme yerini değiştirmiştir.
Bu yazıda Mobile Legends gibi UID tabanlı, yüksek frekanslı bir ürünün arkasındaki akışı teknik olarak parçalayacağım: sipariş nesnesi nerede doğar, ödeme doğrulaması hangi anda otorite olur, tedarikçi çağrısı kaç kez denenir, hata durumunda kim karar verir, kayıt hangi alanlarla tutulur. Amacım sana bir ürün satmak değil; iyi kurulmuş bir e-pin satış scriptinin içinde ne olduğunu göstermek. Pinova bu akışı hazır sunan bir dijital ürün satış yazılımıdır, ama kurguyu anlamadan hiçbir yazılım seni kurtarmaz.
Otomasyon Dediğin Şey Neden Çoğu Panelde Sadece Süs?
Birçok panelde "otomatik teslimat" şu anlama gelir: ödeme geldiğinde sistem stok tablosundan bir kod çeker ve müşteriye gösterir. Bu, kod tabanlı ürünler için yeterlidir. Ama Mobile Legends elması kod değildir; UID ve sunucu numarasına yapılan bir yüklemedir. Yani teslimat bir veriyi açmak değil, dışarıdaki bir sisteme başarılı bir işlem yaptırmaktır. Bu ikisi mimari olarak aynı şey değildir.
Fark şurada ortaya çıkar: kod teslimatında işlem ya olur ya olmaz, arada durum yoktur. Yükleme teslimatında ise "gönderildi ama doğrulanmadı", "tedarikçi kuyruğa aldı", "UID geçersiz", "bölge uyuşmuyor" gibi yarım durumlar vardır. Bu ara durumları modellemeyen bir yapı, her belirsizlikte insana sorar. Sonuç: gün içinde yüz siparişin on beşi senin ekranında bekler ve otomasyon iddiası çöker.
Mobile Legends Siparişinde Hangi Adım Gerçekten İnsan İstiyor?
Zinciri açalım. Bir: müşteri UID ve sunucu numarasını girer. İki: sistem bu bilgiyi biçim olarak doğrular ve mümkünse oyuncu adını geri çekip müşteriye onaylatır. Üç: ödeme alınır ve ödeme sağlayıcısının kendi durum sorgusu tek otorite kabul edilir. Dört: sipariş kuyruğa yazılır. Beş: tedarikçi çağrısı yapılır, sonuç kaydedilir. Altı: başarı durumunda müşteriye bildirim, başarısızlıkta yeniden deneme veya iade.
Bu altı adımın beşi tamamen makineye bırakılabilir. İnsan kararı gerektiren tek nokta, tedarikçinin kesin olmayan cevap döndüğü ve yeniden denemenin çifte yükleme riski taşıdığı durumdur. İyi kurulmuş bir akış, bu tek durumu "manuel inceleme" kuyruğuna ayırır ve geri kalan her şeyi kendi yürütür. Kötü kurulmuş akış ise bütün belirsizliği aynı sepete atar; sen de sabah kalktığında kırk siparişi elle ayıklarsın.
| Adım | Otorite | Hata durumunda davranış | İnsan gerekir mi? |
|---|---|---|---|
| UID + sunucu girişi | Müşteri onayı | Biçim hatasında sipariş açılmaz | Hayır |
| Oyuncu adı doğrulama | Tedarikçi sorgusu | Doğrulanamazsa uyarı gösterilir | Hayır |
| Ödeme doğrulama | Sağlayıcı durum sorgusu | Beklemede kalır, teslim başlamaz | Hayır |
| Kuyruğa yazma | Kendi veritabanın | Tekrarlanabilir kayıt anahtarı | Hayır |
| Tedarikçi yükleme çağrısı | Tedarikçi işlem kodu | Sınırlı sayıda yeniden deneme | Hayır |
| Belirsiz cevap | Karar yok | Manuel inceleme kuyruğu | Evet |
| Bildirim ve iade | Kural motoru | Süre aşımında bakiye iadesi | Hayır |
Bayi API'sine Bağlanmadan Otomasyon Kurulabilir mi?
Kısmen. Tedarikçin API vermiyorsa tam otomasyon mümkün değildir, ama yarı otomasyon ciddi kazanç sağlar. Bu modelde sistem siparişi alır, ödemeyi doğrular, UID'yi kayda geçirir ve sana tek ekranda "yapılacaklar" listesi çıkarır. Sen yalnızca tedarikçi panelinde yüklemeyi yapar, sistemde tek tuşla "teslim edildi" işaretlersin. Müşteri bildirimini, faturayı, stok düşümünü ve raporu yazılım halleder.
API varsa hikaye değişir. O zaman kritik konu yeniden deneme güvenliğidir. Her siparişe kendi ürettiğin tekil bir işlem anahtarı verirsin ve tedarikçiye giden her çağrıda aynı anahtarı gönderirsin. Bağlantı koptuğunda tekrar denediğinde tedarikçi aynı anahtarı görüp işlemi ikinci kez uygulamaz. Bu tek önlem, otomasyonun en pahalı hatası olan çifte yüklemeyi ortadan kaldırır. Bir epin yazılım altyapısını değerlendirirken ilk soracağın teknik soru bu olmalı.
Mobile Legends siparişinde geçen sürenin dağılımı
- Ödeme doğrulama beklemesi 50%
- Tedarikçi yükleme çağrısı 25%
- Kuyruk ve sıra bekleme 15%
- Bildirim ve kayıt 10%
Tek Bir Kuyruk Neden Bütün Gece Vardiyasını Bitiriyor?
Kuyruk, otomasyonun kalbidir ve en çok atlanan parçadır. Kuyruksuz bir yapıda sipariş ödeme sonrası doğrudan tedarikçiye gider. Tedarikçi yavaşsa müşteri ekranda bekler, sayfa zaman aşımına düşer, müşteri yeniden dener ve sen iki sipariş görürsün. Kuyruklu yapıda ise sipariş anında "alındı" durumuna geçer, müşteriye net bir beklenti verilir ve işleyici arka planda çalışır.
Kuyruğun ikinci faydası hız sınırıdır. Tedarikçiler genelde dakikada belirli sayıda isteğe izin verir. Kuyruk bu sınırı bilir ve istekleri ona göre serpiştirir; sınır aşımı yüzünden reddedilen ve elle toplanması gereken sipariş yığını oluşmaz. Üçüncü faydası ise öncelik yönetimidir: yüksek tutarlı veya tekrar eden müşterinin siparişini öne alabilirsin. Gece bandını insansız geçirmek isteyen her e-pin satış yazılımı bu üç davranışı içermek zorundadır.
"Başarılı olana kadar dene" kuralı tedarikçi arızasında yüzlerce boş çağrı üretir. Doğrusu: en fazla üç deneme, aralar giderek uzasın, üçüncü denemeden sonra sipariş manuel inceleme kuyruğuna düşsün ve müşteriye dürüst bir bekleme mesajı gitsin.
Hata Anında Sistemin Ne Yapacağına Kim Karar Veriyor?
Otomasyonun olgunluğu başarılı siparişte değil, hatalı siparişte belli olur. Bunun için her hata tipine önceden bir davranış yazman gerekir. UID geçersizse sipariş iptal edilir ve tutar bakiyeye döner. Bölge uyuşmazlığında müşteriye doğru bölgeyi seçmesi için bilgi verilir. Tedarikçi bakımdaysa ürün geçici olarak satıştan çekilir, mevcut siparişler beklemede tutulur. Bakiye yetersizse yönetici uyarılır ve kuyruk durdurulur.
Bu kuralları yazmadığın her hata tipi, otomatik olarak sana gelen bir mesaj demektir. Deneyimli satıcılar zamanla şunu fark eder: otomasyon kurmak aslında karar yazmaktır. Kod değil, politika. Yazılımın sağladığı şey ise bu politikaları uygulayacak sağlam bir iskelet ve her adımın izlenebildiği bir kayıt defteri. Detayları özellikler bölümünde inceleyebilirsin.
Otomasyonun Gizli Kazancı: Ölçülebilir Süre ve Ölçülebilir Hata
Manuel çalışan bir işletme kendi performansını bilmez. "Genelde hızlı teslim ediyoruz" der ama ortalamayı söyleyemez. Otomasyon kurulduğunda her siparişin oluşma, ödeme onayı, tedarikçi cevabı ve teslim zamanı kayda geçer. Artık ortalaman vardır, en kötü yüzde onun vardır, hangi saatte yavaşladığını görürsün. Bu ölçüm, reklam metninde "ortalama 40 saniyede teslim" yazabilmenin de tek dürüst yoludur.
İkinci gizli kazanç hata oranının görünür olmasıdır. Tedarikçi bazlı başarısızlık oranını gördüğünde hangi tedarikçiyle çalışmaya devam edeceğine duyguyla değil veriyle karar verirsin. Aşağıdaki kontrol listesi, otomasyon kurgunu teknik olarak denetlemek için kullanabileceğin kısa bir tarama.
| Teknik kontrol | Soru | Durum |
|---|---|---|
| Tekil işlem anahtarı | Aynı sipariş iki kez yüklenebilir mi? | Kritik |
| Ödeme otoritesi | Onay, sağlayıcının durum sorgusundan mı geliyor? | Kritik |
| Kuyruk ve hız sınırı | Tedarikçi limiti aşıldığında ne oluyor? | Kritik |
| Ara durum modeli | "Belirsiz" durum ayrı kuyrukta mı? | Kritik |
| Otomatik iade kuralı | Süre aşımında bakiye dönüyor mu? | Önemli |
| Adım bazlı zaman kaydı | Ortalama teslim süresini ölçebiliyor musun? | Önemli |
| Tedarikçi bakım modu | Ürün otomatik satıştan çekiliyor mu? | Önemli |
Otomasyon kurgunu sıfırdan yazmak yerine hazır iskelet üzerine kur
Pinova; kuyruk, yeniden deneme güvenliği, ara durum yönetimi ve adım bazlı kayıt gibi teknik parçaları hazır getiren lisanslı bir e-pin scriptidir. Lisans ve sürüm farklarını fiyat bölümünden karşılaştırabilirsin.
Tedarikçim API vermiyorsa otomasyon anlamsız mı olur?
Hayır. Ödeme doğrulama, kayıt, bildirim, fatura ve raporlama yine otomatikleşir. Sadece yükleme adımı elde kalır ve tek ekranda toplanır. Bu bile sipariş başına harcanan süreyi ciddi biçimde düşürür.
Çifte yükleme riskini nasıl tamamen kapatırım?
Her siparişe kendi ürettiğin tekil bir işlem anahtarı ver ve tedarikçiye giden her çağrıda aynı anahtarı gönder. Yeniden denemeler bu anahtarla yapılır; tedarikçi aynı anahtarı ikinci kez işlemez.
Sipariş neden ödeme sonrası doğrudan tedarikçiye gitmesin?
Çünkü tedarikçi yavaşladığında müşteri ekranda bekler, sayfa zaman aşımına düşer ve tekrar deneme sonucu mükerrer sipariş oluşur. Kuyruk bu riski ortadan kaldırır ve hız sınırını yönetir.
Manuel inceleme kuyruğu otomasyonun başarısızlığı mı?
Tersine, olgunluk göstergesidir. Belirsiz cevapların kontrollü biçimde tek bir yere toplanması, o siparişlerin bütün akışa karışmasından çok daha güvenlidir.
Bu kurguyu yazıyla anlatmak mümkün ama gerçekten kavramak için akışı çalışırken görmek gerekir: siparişin kuyrukta nasıl durum değiştirdiğini, belirsiz cevabın nereye düştüğünü ve raporun neyi gösterdiğini canlı demo üzerinde test edebilir, sonra lisans adımına geçebilirsin.