Bir SMM panelin servis listesinde bir hizmet “Package”, diğeri “Default” veya normal servis olarak adlandırılabilir. İki satır da benzer platform için sunulsa bile kullanıcıdan istenen bilgiler ve fiyatlandırma farklıdır. Package servis tipi, birçok API yapısında sabit kapsamlı ve tek fiyatlı bir siparişi ifade eder; normal servislerde ise miktar seçimi temel alanlardan biridir. Ancak Package sözcüğünü gören herkes aynı hizmetin satıldığını varsaymamalıdır. Paket içeriği sağlayıcıya göre değişebilir ve bazen yalnızca tek platforma ait belirli bir işlemden oluşur. Bu rehber, satın alma öncesi ekrana bakarken karşılaşılan farkları ve API’de bunların nasıl yönetileceğini açıklar.
Normal servis (Default) nasıl çalışır?
Default türünde kullanıcı çoğunlukla servis seçer, uygun hedef bağlantısını girer ve miktar yazar. Miktar katalogda belirtilen minimum ve maksimum aralığı içinde olmalıdır. Fiyat birçok panelde 1.000 birim başına gösterildiğinden toplam ücret hesaplanırken miktar dikkate alınır. Örneğin tamamen örnek olarak 1.000 birim fiyatı 1,80 dolar olan bir hizmette 500 birimin ücreti 0,90 dolar olabilir. Gerçek fiyat ve hesaplama kuralı panelin ekranından doğrulanmalıdır.
Normal servis esnek miktar seçimi sağlayabilir, ancak bu onun her zaman daha kaliteli veya daha ucuz olduğu anlamına gelmez. Minimum miktar yüksekse küçük bir deneme yapmak mümkün olmayabilir. Başlangıç süresi, refill, iptal durumu ve hizmetin hedef bağlantı türü ayrıca değerlendirilir. Kullanıcı yalnızca miktarı değiştirebildiği için “her zaman ihtiyacıma tam uyar” sonucuna varmamalıdır; platform sınırları ve hizmet açıklaması yine belirleyicidir.
Package servis tipi neyi değiştirir?
Sektörde yaygın kullanılan bazı SMM API v2 belgelerinde Package türü, service ve link alanlarıyla verilen, sabit fiyatlı bir sipariş olarak tanımlanır. Bu modelde miktar çoğu zaman kullanıcıdan bağımsızdır; sabit kapsam servis açıklamasında belirtilir. Başka bir deyişle Package hizmetinde fiyatı “birim fiyat × seçilen miktar” şeklinde hesaplamak her zaman doğru değildir. Bazı altyapılar miktarı teknik olarak 1 kabul eder; kullanıcı panelde ayrı bir miktar kutusu görmeyebilir.
Paketin adı içinde “100”, “500” veya başka bir sayı bulunması ise tek başına güvenilir veri değildir. O sayı örnek bir kapasiteyi, kampanya adını veya servis sağlayıcının tanımını temsil edebilir. Gerçek kapsam, koşullar ve maliyet servis açıklamasında netleşmelidir. Panel yöneticisi bu alanı boş bırakırsa müşterinin “500’lük paket aldım, neden 500’lük ikinci hizmet de gelmedi?” gibi yanlış beklentileri oluşabilir. Paket adının pazarlama dili ile API tipi birbirinden ayrılmalıdır.
Package her zaman birden fazla servisin birleşimi mi?
Hayır. Günlük dilde “sosyal medya paketi” dendiğinde birkaç hizmetin bir arada sunulması anlaşılabilir. API dokümantasyonundaki Package, teknik olarak tek bir sipariş tipi de olabilir. Örneğin önceden tanımlı, sabit miktarlı tek hizmet Package olarak sınıflandırılabilir. Bu nedenle iki farklı kavramın aynı kelimeyi paylaşması satın alma kararını zorlaştırabilir. Müşteri ekranında paketin hangi hizmetleri kapsadığı ve hangi sonuçların beklenebileceği açıkça yazılmalıdır.
Birden fazla hizmet içeren pazarlama paketi hazırlanıyorsa bunun arka planda birden fazla siparişe bölünüp bölünmediği ayrıca önemlidir. İki servisli bir kampanya paketi, sağlayıcı API’sinde iki ayrı Default siparişi olarak çalışabilir. Bu durum Package adlı tek API servis türüyle teknik olarak aynı değildir. Aradaki fark doğru anlatılmazsa iade, durum sorgusu ve raporlama karmaşıklaşır. Kullanıcıya tek ürün satılmış olsa da sağlayıcı tarafındaki iş kayıtlarının sayısı farklı olabilir.
Fiyat tablosunda nelere bakılmalı?
Normal servisin fiyatı 1.000 birim üzerinden gösterilirken Package servisin fiyatı bütün siparişi kapsayabilir. Aynı tabloda bunları yan yana görmek kafa karıştırır. Örneğin normal serviste 1.000 birim için 2 dolar, Package için 1,50 dolar yazıyor olsun. Bu iki fiyat, paketin kapsamı bilinmeden karşılaştırılamaz. Paket yalnızca 200 birimlik iş içeriyorsa birim maliyeti aslında daha yüksek olabilir. Diğer taraftan pakette ek özellikler bulunuyorsa yalnızca adet karşılaştırması yine eksik kalır.
Fiyat değerlendirmesinde para birimi, kısmi tamamlanma politikası, minimum sipariş, servis başlangıcı ve fiyatın değişip değişmediği de dikkate alınmalıdır. Aynı hizmetin farklı panellerde neden farklı etiketlerle satıldığını fiyatlandırma araştırmamızda açıklıyoruz. Kıyaslamanın doğru yapılabilmesi için müşteriye gösterilen ölçü birimi net olmalıdır: “1K başına fiyat” ile “tek paket fiyatı” aynı sütunda açıklamasız verilmemelidir.
API entegrasyonunda form alanları nasıl belirlenir?
Bir reseller sistemi sağlayıcıdan servis kataloğunu aldığında yalnızca service ve rate alanlarını değil, type değerini de incelemelidir. Default türünde quantity beklenirken Package türünde bu alanın gerekmemesi yaygın bir örnektir. Yazılım bütün hizmetler için aynı formu gösterirse müşteri gereksiz miktar girebilir veya sipariş API tarafından reddedilebilir. Formun servis tipine göre değişmesi hem hata oranını hem de destek yükünü azaltır.
Bazı sistemlerde teknik tip adı değişebilir; bu nedenle yalnızca metin karşılaştırması yerine dokümantasyonun belirttiği giriş şeması kullanılmalıdır. Package adının herhangi bir servisin görünen isminde geçmesi, type alanının da Package olduğu anlamına gelmez. Entegratör, gerçek tipi kaynak veriden almalı ve test ederek onaylamalıdır. Daha temel API mantığını öğrenmek için SMM panel API rehberimize bakabilirsiniz.
Yanlış servis tipi eşleşmesi hangi hataları doğurur?
Bir panel sağlayıcıda Package olarak bulunan hizmeti kendi kataloğunda Default olarak tanımlamış olsun. Müşteri miktar girer, panel bu miktarı API’ye gönderir ancak sağlayıcı kabul etmez veya göz ardı eder. Başarılı yanıt dönen bazı sistemlerde bile müşteri beklediği miktarın teslim edilmesini isteyebilir; çünkü ekranda kendisinin seçtiği sayı görünmüştür. Bu tür uyuşmazlıklar teknik sorun kadar iletişim sorunudur. Siparişin hangi alanlarla oluşturulduğunun loglarda görülmesi gerekir.
Tersi durumda, miktar seçilebilen standart servis yanlışlıkla sabit paket gibi sunulursa kullanıcı uygun adet belirleyemez. Servis ID eşleşmesini değiştirmeden yalnızca ekranda fiyatı düzeltmek sorunu çözmeyebilir. Panel yöneticisi eski siparişleri silmeden katalog kaydını güncellemeli, aktif işlemleri ise kendi oluşturulduğu koşullarla korumalıdır. Bu süreçte servis kataloğu güncelliği rehberindeki değişiklik kontrol mantığı faydalıdır.
Paket seçimi için dört gerçekçi senaryo
Senaryo bir: Kullanıcı küçük bir miktarla servis denemek istiyor. Default türünde minimum sipariş sınırı uygunsa istediği miktarı seçebilir. Package türünde ise sabit kapsam nedeniyle daha fazla veya daha az sipariş vermesi mümkün olmayabilir. Burada “paket daha ucuz” sloganı, ihtiyacına tam uymayan bir satın alma kararına yol açabilir. Öncelikle gerçek ihtiyaca uygunluk ve işlemin koşulları karşılaştırılmalıdır.
Senaryo iki: Bayi, sabit kapsamlı hizmeti per-1000 fiyat gibi müşterilerine yansıtıyor. Fiyat sistemi paketteki olası miktarı tekrar çarptığında yanlış tahsilat oluşabilir. Senaryo üç: Sağlayıcı hizmeti Package’ten Default’e çevirir ama bayi eski tip bilgisini kullanmaya devam eder. Yeni siparişler hata verirken müşteri arayüzü değişiklikten habersiz kalabilir. Senaryo dört: Bir kampanya paketinde iki hizmet vardır; siparişin yalnızca biri tamamlandığında genel paket durumu tek kelimeyle “tamamlandı” gösterilirse müşteriye eksik bilgi verilmiş olur.
Refill ve iptal koşulları tipten bağımsız mıdır?
Bir hizmetin Package olması onun otomatik olarak refill garantili veya iptal edilebilir olduğu anlamına gelmez. refill ve cancel özellikleri ayrı alanlar olarak sunulabilir. Default hizmetlerde de bu koşullar farklılaşabilir. Kullanıcı, yalnızca fiyat veya tip adı üzerinden garanti çıkarmamalıdır. Servis açıklamasında başlangıç süresi, teslimat koşulları ve olası düşüşle ilgili sınırlar ayrı belirtilmelidir. Paket fiyatı sabit olsa bile hizmet sonrasında karşılaşılabilecek durumlar tek bir kategoriye sığmaz.
İptal veya kısmi sonuçla ilgili şüphede önce gerçek sipariş durumu kontrol edilmelidir. SMM panel sipariş durumları rehberindeki Pending, Processing ve Partial ayrımı burada da geçerlidir. Bir Package siparişin kısmi tamamlanması durumunda olası tutar düzeltmesi yalnızca basit bir “kalan miktar” formülüyle yapılamayabilir; sağlayıcının sözleşme ve fiyat kuralı esastır. Otomatik iade vaatleri dikkatle değerlendirilmelidir.
Paket sayfası nasıl daha anlaşılır yapılır?
İyi bir servis sayfası önce paketin açık kapsamını ve hedef bağlantı tipini belirtir. Ardından ücretin tek sipariş için mi yoksa birim bazında mı hesaplandığını gösterir. Minimum ve maksimum alanları yalnızca gerçekten uygunsa kullanıcıya açar. Hizmetin kategori etiketi ile teknik sipariş tipi birbirini doğrular. Böylece müşteri “paket” kelimesinin günlük anlamıyla sistemin API anlamını karıştırmaz. Gereksiz süslü vaatlerden çok net ve doğrulanabilir bilgi verilmesi satın alma sürecini kolaylaştırır.
Bayi yazılımında form alanları type bilgisine göre değiştiriliyorsa yanlış tip eşleştirmelerine karşı uyarı da bulunmalıdır. Örneğin beklenmedik type değeri geldiğinde sistem varsayılan formu zorla açmak yerine hizmeti inceleme kuyruğuna alabilir. Bu yaklaşım satış kaybını önlemese bile yanlış sipariş maliyetini azaltır. Kontrolün düzenli yapılması servis sayısının fazla olduğu panellerde önemlidir; küçük bir tip hatası onlarca müşteriyi etkileyebilir.
Kısa karşılaştırma tablosu
| Başlık | Default | Package |
|---|---|---|
| Miktar | Çoğunlukla seçilir | Çoğunlukla sabittir |
| Ücret | Çoğu zaman adet üzerinden | Tek paket fiyatı olabilir |
| API alanı | Quantity çoğunlukla gerekir | Quantity gerekmeyebilir |
Sık sorulan sorular
SMM Panel Package nedir?
Bazı API sistemlerinde miktarı önceden tanımlanmış ve sabit fiyatla satılan sipariş tipidir. Paket kapsamı mutlaka servis açıklamasından okunmalıdır.
Normal serviste neden miktar yazıyorum?
Default türünde kullanıcı genellikle minimum ve maksimum aralık içinde adet belirler. Hesaplanan ücret bu miktara göre değişebilir.
Package daha ucuz mudur?
Kesin değil. Karşılaştırma için paket kapsamı, toplam ücret ve normal servisin birim fiyatı birlikte ele alınmalıdır.
Package birden fazla platformu kapsar mı?
Zorunlu olarak hayır. Teknik Package türü tek bir sabit kapsamlı servisi de ifade edebilir.
Package servisinde refill var mı?
Tip adı bunu belirlemez. Refill koşulu hizmete özel olarak kontrol edilmelidir.
API’de Package için quantity zorunlu mu?
Yaygın bazı v2 şemalarında Package service ve link ile çalışır; kesin gereksinim sağlayıcının API dokümantasyonuna bağlıdır.
Sonuç
SMM panelde Package ve normal servis arasındaki temel fark, satın alma girdileri ve fiyatın nasıl belirlendiğiyle ilgilidir. Default çoğunlukla miktar seçimine dayanırken Package sabit kapsamlı olabilir. Bunun dışında kalite, hız, iade ve refill koşulları tip adından doğrudan çıkarılamaz. Müşterinin doğru karar vermesi için servis adı değil kapsam, ücret birimi ve hedef türü açık olmalıdır. Panel işletenler içinse doğru type eşleştirmesi, gereksiz hata ve destek taleplerini azaltan temel bir katalog kontrolüdür.
Yeniden satış yapan panel için fiyat tutarlılığı denetimi
Bir reseller, sağlayıcı kataloğunda Default ve Package satırlarını aynı kategori altında gösteriyorsa otomatik fiyatlama kurallarını ayrı oluşturmalıdır. Normal servise yüzde bazlı marj eklenirken hesaplama genellikle 1.000 birim fiyatına uygulanır; Package türünde ise marj tek sipariş bedeline eklenebilir. Örneğin sağlayıcının sabit paket maliyeti 1,20 dolar ve satış marjı yüzde 25 olarak belirlenmişse örnek satış fiyatı 1,50 dolardır. Bu işlem, satın alınan paketin kendi kapsamına ek hizmet dahil edildiği anlamına gelmez. Kur dönüşümü, ödeme giderleri ve varsa vergiler ayrıca hesaplanmalıdır.
Kontrol sistemi özellikle sıfır miktar, boş type, eski fiyat önbelleği veya sağlayıcının biçim değiştirdiği servisleri işaretlemelidir. Böylece kullanıcı sipariş verirken yanlış toplamla karşılaşmaz. Fiyat güncellemesi yapılırken hâlihazırda açılmış siparişlerin geçmiş ücretlerini geriye dönük değiştirmemek gerekir; satış kaydı gerçekleştiği andaki şartların belgesi olarak korunmalıdır. Bu ayrım operasyonel raporlama ve müşteri anlaşmazlıkları açısından önemlidir.
Müşteri hangi servisi ne zaman tercih etmeli?
Bir müşteri için doğru tercih, satın alma ekranındaki en büyük indirim yüzdesi değil, ihtiyacının açık tanımlanmasıdır. Belirli miktarı seçmek ve farklı büyüklüklerde deneme yapmak istiyorsa miktar aralığı uygun bir Default servisi daha anlaşılır olabilir. Önceden tanımlanmış sabit bir kapsamı tek bedelle satın almak istiyorsa Package modeli değerlendirmeye alınabilir. Ancak her durumda hedef platformun kuralları, yapay etkileşimlerin hesap üzerindeki olası etkileri ve hizmetin vaatlerinin doğrulanabilirliği dikkate alınmalıdır. Katalog açıklaması belirsizse siparişten önce destek ekibine kapsam sorulmalı; yalnızca Package ismi üzerinden içerik veya sonuç çıkarılmamalıdır. Karar kaydı saklandığında daha sonra çıkan uyuşmazlıkların hangi beklentiden kaynaklandığı daha kolay anlaşılır.
