Dövizle fiyatlanan yapay zekâ kredileri: Satın almadan önce maliyeti nasıl hesaplarsınız?

TL;DR (Quick Summary)

Dövizle alınan yapay zekâ kredilerinde asıl mesele etiket fiyatı değil, aylık maliyetin ne kadar isabetli tahmin edilebildiğidir. Karar için kullanım hacmi, davranış farkları, tükenme anı ve kur etkisi birlikte modellenmelidir.

• Önce yanıtlanacak satın alma sorusunu netleştirin → Ucuzluk değil öngörülebilirlik aranır
• Krediyi değil süreci ölçün → Hacim kadar kullanım davranışı belirler
• Üç fiyatlama yapısını aynı çerçevede karşılaştırın → Fiyat modeli görünürlüğü değiştirir
• Aylık maliyeti hesaplamak için tek sayı değil üç senaryo kurun → Baz, yoğun ve tükenme ayrı
• Maliyeti doğru okumak için metrikleri birlikte yorumlayın → Tek metrik yanlış güven verir
• Döviz riski ve sözleşme şartlarını hesap dışı bırakmayın → TL bütçeyi sözleşme belirler
• İmzadan önce yazılı isteyin → Belirsizlikleri taahhüde çevirin
• SSS → Kritik satın alma sorularının kısa yanıtı

Takeaway

Sağlam satın alma kararı, kredi paketini değil kullanım sistemini fiyatlamaktan geçer. Yazılı kurallar, senaryo hesabı ve tüketim görünürlüğü yoksa ucuz görünen model pahalıya dönebilir.

Önce yanıtlanacak satın alma sorusunu netleştirin: Bu kredi modeli bizim kullanım desenimizde gerçekten öngörülebilir mi?

Satın alma masasında soru genelde “paket uygun mu?” olur. Dövizle fiyatlanan yapay zekâ kredilerinde daha doğru soru şudur: Bu modeli aylık ve çeyreklik toplam maliyet olarak kabul edilebilir doğrulukla tahmin edebiliyor muyuz? Cevap net değilse düşük görünen birim fiyatın anlamı sınırlıdır.

İki belirsizlik birlikte çalışır. İlki kullanım hacmi ve davranışıdır. Ekip aynı aracı her ay aynı yoğunlukta kullanmaz; yeniden denemeler artabilir, daha ağır iş akışları devreye girebilir, yeni kullanıcılar eklenebilir.

İkincisi döviz kurudur. Fatura yabancı para cinsinden sabit görünse bile bütçe TL olarak tutuluyorsa gerçek maliyet dalgalanır. Kullanımı anlasanız bile kuru hesaba katmıyorsanız tablo eksik kalır. Kuru modelliyor ama tüketimi okuyamıyorsanız sonuç yine zayıftır.

Karar üç boyutta verilmelidir:

• Beklenen maliyet normal ayda ne ödeyeceğinizi gösterir.
• Kötü senaryo maliyeti yoğun kullanımda veya davranış sapmasında bütçenin nereye çıkabileceğini gösterir.
• Kredi bittiğinde operasyon etkisi ise iş sürekliliğini belirler: sistem duruyor mu, pahalı aşım mı açılıyor, üst pakete mi geçiliyor?

Satın alma ekibinin ihtiyacı “bir aksiyon yaklaşık şu kadar” anlatımı değil, kullanım desenine göre tahmin aralığıdır. Aralık genişse risk fiyatın kendisinden çok görünürlük eksikliğidir.

Dövizli Yapay Zekâ Kredisi Maliyet Hesaplama Tablosu

Kapsamlı ve adım adım kılavuzu almak için e-posta adresinizi girin.

You acknowledge that you have read and understood Bitrix24 Privacy Policy

Krediyi değil süreci ölçün: Hangi işlem hacimleri ve davranışlar maliyet tahmini için gerçekten gerekli?

Toplam kullanıcı sayısı veya aylık aksiyon adedi çoğu durumda yetmez. Kredi tüketimi, ürünün hangi iş akışında nasıl kullanıldığına bağlıdır. Başlangıç noktası “kaç kredi alalım?” değil, “hangi süreç ne kadar tüketim yaratır?” olmalıdır.

Satın almadan önce şu girdiler toplanmalıdır: toplam işlem sayısı, kullanıcı veya ekip başına ortalama kullanım, tepe dönem hacmi, tekrar deneme oranı, istisna ve manuel müdahale oranı. Örneğin müşteri destek ekibi aynı talebi tek seferde çözmüyor ve operatör çıktıyı sık sık yeniden üretiyorsa nominal işlem sayısı değişmeden kredi tüketimi yükselir.

Aynı iş akışında tüketimi değiştiren davranışlar ayrıca ayrılmalıdır. Uzun prompt kullanımı, aynı görevi birkaç kez yeniden çalıştırma, çok aşamalı akışlar, daha gelişmiş model seçimi veya ek özelliklerin açılması faturayı oynatabilir. “Ayda 10 bin işlem yapıyoruz” cümlesi tek başına satın alma hesabı değildir; bu işlemlerin kaçının ağır, hafif veya tekrar denemeli olduğu da gerekir.

Ibbaka’nın 2025 sonu değerlendirmesi, kredi bazlı fiyatlamada şeffaflığın neden kritik olduğunu vurguluyor. Alıcılar bir işlemin kaç kredi tüketeceğini ve mevcut bakiyenin ne zaman biteceğini önceden görebilmek istiyor. Aynı değerlendirmeye göre SaaS fiyatları 2025’te ortalama %8-12 artarken; indirimlerin kaldırılması, kullanım limitlerinin sıkılaştırılması ve özelliklerin ek ücretlere ayrılması alıcıların reel maliyetlerini %20-30 yükseltti. Bu nedenle satın alma hesabında yalnızca başlangıç fiyatını değil, tüketim kurallarını ve ek ücretleri de değerlendirin.

Sıçrama yaratan dönemler de ortalamanın içine gömülmemelidir. Kampanya, dönem sonu yoğunluğu, yeni ekip alıştırma süreci veya yeni kullanım senaryoları normal aya benzemez. Bu dönemleri ayrı senaryo olarak modellemek, satın alma kararını sakin ay ortalamasına değil operasyonun gerçek dalgalanmasına dayandırır.

Örneğin, farklı ekiplerin yapay zekâ kullanımını ayrı görevler ve sorumlular üzerinden izlemek, tüketimin hangi iş akışında arttığını anlamayı kolaylaştırır. Bitrix24 görev ve proje yönetimi ile görevleri, sorumluları ve iş akışlarını tek yerde takip edebilirsiniz.

Üç fiyatlama yapısını aynı çerçevede karşılaştırın: kredi, işlem başı ve hibrit model size neyi gösterir, neyi gizler?

Aynı ürün kredi bazlı, işlem başı veya hibrit olarak fiyatlanabilir. Karşılaştırma için hepsini ortak ölçüye çevirmek gerekir. Aksi takdirde paket fiyatları yan yana dursa da gerçekte ne satın alındığı netleşmez.

Kredi bazlı model

Burada asıl metrik paket büyüklüğü değil, iş başına efektif kredi tüketimidir. Kredi farklı aksiyonlara farklı oranlarda dağılabilir. Daha uzun içerik, farklı model seçimi veya yeniden üretim aynı paket içinde birim maliyeti değiştirir.

İşlem başı fiyatlama

Bu yöntemde görünürlük daha yüksektir. Ancak satıcının “işlem” tanımı kritik hâle gelir. Farklı özellikler, dosya işleme, gelişmiş model, ek doğrulama veya çok aşamalı akışlar ayrı fiyatlanıyorsa model sade görünür ama fatura katmanlı gelir.

Hibrit model

Sabit taahhüt ve aşım ücreti birlikte okunmalıdır. Düşük kullanımda, kullanılmayan kapasite pahalılaşır; yüksek kullanımda ise aşım belirleyici olur. Model baz kapasiteyi güvenceye alabilir ancak belirsiz kullanım yaşayan ekiplerde sürpriz aşım üretebilir.

"Bitrix24'ün ihtiyaçlarımıza en uygun yazılım olduğunu gördüm.

Müdür Yardımcısı - BT Departmanı, Mr. Pham Xuan Tung

Saigon Newport Corporation

Ücretsiz kayıt

Aylık maliyeti hesaplamak için tek sayı değil üç senaryo kurun: baz, yoğun kullanım ve tükenme senaryosu

Tek tahmin, özellikle dövizle alınan kredi modellerinde yanlış güven üretir. Daha sağlam yaklaşım baz, yoğun kullanım ve tükenme senaryolarını birlikte kurmaktır.

Baz senaryo

Mevcut veya beklenen işlem hacminden başlar. Her süreç için ortalama tüketim çarpılır, toplam kredi veya işlem yükü çıkarılır. Sonuç yalnızca döviz cinsinden bırakılmamalı, TL karşılığıyla da izlenmelidir. Çünkü satın alma onayı çoğu zaman TL bütçe disipliniyle verilir.

Örneğin ayda 12.000 işlem ve işlem başına ortalama 0,8 kredi tüketimi, toplam 9.600 kredi ihtiyacı yaratır. Aylık 12.000 kredilik paketin 120 USD olduğu varsayılırsa paket maliyeti 120 USD olur. Kullanılmayan 2.400 kredi ise sözleşmede devretme hakkı yoksa atıl kapasiteye dönüşür.

Yoğun kullanım senaryosu

Sadece daha fazla işlem eklemek değildir. Tepe hacim, tekrar deneme artışı, kullanıcıların daha ağır kullanım biçimlerine kayması ve yeni kullanıcı etkisi de hesaba katılmalıdır. İşlem sayısı sınırlı artsa bile yeniden çalıştırma alışkanlığı tüketimi beklenenden hızlı yükseltebilir.

Önceki örnekten devam ettiğimizde, işlem hacmi %25, tekrar deneme (retry) oranı %15 artarsa tüketim de 12.000 × 1,25 × 1,15 × 0,8 = 13.800 krediye çıkar. Paket sınırı 1.800 kredi aşılır. Aşımın kredi başına 0,015 USD olduğu varsayılırsa toplam aylık maliyet 147 USD'ye yükselir.

Tükenme senaryosu

Çoğu satın alma dosyasında eksik kalır. Kredi bittiğinde hizmet tamamen duruyor mu? Aşım daha pahalı tarifeden mi işliyor? Sistem otomatik üst pakete mi geçiyor? Elle onay olmadan ek tüketim açılabiliyor mu? Bu cevaplar hem maliyeti hem iç kontrol düzenini etkiler.

12.000 kredilik paket, işlem başına 0,8 kredi tüketiminde tekrar denemeler hariç 15.000 işlemde tükenir. Kredi bittiğinde hizmet duruyorsa operasyon kesintisi meydana gelir. Otomatik aşım açılıyorsa ek maliyet riski oluşur. Bu nedenle aşım tarifesini, otomatik tüketim ayarlarını ve uyarı eşiklerini satın alma öncesinde netleştirin.

Örneğin ikinci haftada daha kapsamlı ve kredi tüketimi yüksek bir modele geçen bir müşteri destek ekibini ele alalım. Başlangıçtaki kullanım tahmini değişmediği için ekip, aylık kredilerinin 20. haftada tükendiğini fark eder ve sistem otomatik aşım ücretini devreye alır. Ay sonunda aşım bedeli, kurun yükselmesi nedeniyle TL bütçesinde öngörülenden çok daha yüksek bir tutara dönüşür. Buradaki hata yalnızca tüketimi düşük tahmin etmek değil; model değişikliğini, kredi tükenme eşiğini ve kur riskini aynı maliyet planında değerlendirmemektir.

Bu üç senaryo birlikte kurulduğunda satın alma ekibi normal ayı, sıkışık ayı ve kırılma noktasını aynı tabloda görür.

Maliyeti doğru okumak için metrikleri birlikte yorumlayın: tek başına birim fiyat sizi yanıltabilir

Birim fiyat, paket etiketi veya toplam kredi alımı tek başına yeterli değildir. Görünürlük, birkaç metriğin birlikte okunmasıyla oluşur. Temel ilişki şudur: toplam süreç hacmi, işlem başına ortalama tüketim, varyans, kredi tükenme tarihi, aşım oranı ve efektif birim maliyet.

Hacim, iş yükünü; ortalama tüketim, kullanım normunu; varyans, bu normun oynaklığını; tükenme tarihi, paketin ay sonuna dayanıp dayanmadığını; aşım oranı, planın ne kadar sık bozulduğunu; efektif birim maliyet ise finansal sonucu gösterir.

Bazı kalıplar erken uyarı verir. Hacim sabitken maliyet artıyorsa süreç karmaşıklaşmış, pahalı özellikler kullanılmaya başlanmış veya tekrar deneme oranı büyümüş olabilir. Kredi beklenenden erken bitiyorsa sorun tahmin modelinden çok kullanım dağılımının başta yanlış okunması olabilir. Ortalamalar sakin görünürken birkaç ağır kullanıcı toplam maliyeti yukarı çekebilir.

Satış veya müşteri operasyonlarında yapay zekâ kullanımı belirli aşamalarda yoğunlaşıyorsa süreç bazlı takip maliyet artışının nereden geldiğini görünür kılar. Bitrix24 satış hattı yönetimi, fırsatların hangi aşamada beklediğini ve tekrarlayan takip işlerinin nerede biriktiğini izlemek için kullanılabilir.

Satıcının teknik kullanım metrikleri ile finansal karar metrikleri aynı değildir. Gösterge panelinde “başarılı çağrı”, “kredi”, “işlem”, “iş akışı” veya “özellik kullanımı” görülebilir. Finans ekibi ise bunların faturaya nasıl döndüğünü, hangi ekipte ne kadar maliyet ürettiğini ve tahakkuk mantığını görmek ister. Bu dönüşüm net değilse rapor vardır ama maliyet görünürlüğü yoktur.

İç raporda satıcı metriğini doğrudan taşımak yerine muhasebeleştirilebilir maliyet görünümüne çevirmek gerekir. Soru “kaç kullanım yaptık?” değil, “hangi kullanım kalıbı hangi fiili birim maliyeti üretti?” olmalıdır.

KORIX’in yayımladığı bir müşteri destek vakasında, yapay zekâ kullanımının ilk ayındaki 300 dolarlık maliyet, 12. ayda özellik devreye alınmasının ardından artan işlem hacmiyle 14.000 dolara çıktı. Yani hacim yalnızca iki haftada 40 katına ulaştı. Bu vaka; kullanım limitleri, tüketim uyarıları ve işlem başına maliyet kontrolleri kurulmadığında düşük başlangıç maliyetinin yanıltıcı olabileceğini gösteriyor.

Döviz riski ve sözleşme şartlarını hesap dışı bırakmayın: satın alma onayını asıl bunlar değiştirebilir

Aynı kullanım hacmi için döviz bazında makul görünen model, TL bütçede sorun yaratabilir. Kullanım stabil kalsa bile ödeme anındaki kur, tahmin edilen maliyet ile gerçekleşen maliyet arasını açabilir. Bu yüzden modele yalnızca kullanım değil, kur senaryosu da eklenmelidir.

Bakılması gereken sadece anlık kur değildir. Ödeme tarihi, fatura para birimi, ön ödeme veya sonradan ödeme yapısı, kullanım dönemi ile tahsilat dönemi arasındaki fark nakit akışını değiştirir. Hizmet bir ay kullanılıp sonraki dönemde tahsil ediliyorsa başka, peşin kredi alınıp sonra tüketiliyorsa başka planlama gerekir.

Sözleşme maddeleri fiili birim maliyeti doğrudan etkiler. Krediler dönem sonunda yanıyor mu, devrediliyor mu, iadesi var mı, havuz mantığında mı çalışıyor? Paket yükseltme veya indirme hangi tarihten itibaren geçerli? Kullanılmayan krediler taşınmıyorsa düşük kullanım aylarında görünmeyen israf oluşur. Devreden kredi ise tepe dönemi için tampon yaratabilir.

Bir teklif dosyasında yalnızca “1000 kredi şu kadar dolar” yazıyorsa maliyetin küçük bir kısmı görünür. Gerçek maliyet, kur etkisi ile sözleşme davranışının birleşiminde ortaya çıkar. Kur riskini yönetmek için sözleşmede hangi kurun (TCMB veya banka satış kuru) ve hangi tarihin (fatura veya ödeme tarihi) esas alınacağını netleştirin. Mümkünse sabit kur veya tavan kur talep edin.

Örneğin 10.000 USD tutarındaki fatura için 52 TL/USD tavanı kabul edilirse maliyet 520.000 TL ile sınırlanır. Alternatif olarak vadeli işlem ile kur sabitlemeyi değerlendirin, işlem maliyetini de bütçeye ekleyin.

İmzadan önce yazılı isteyin: satıcıya sorulacak sorular ve alınacak taahhütler

Satın alma riskini azaltmanın en pratik yolu, kritik noktaları sunumda değil yazılı yanıtta toplamaktır. Maliyet çıktığında referans alınacak şey sözlü anlatım değil yazılı kurallardır.

İlk grup sorular tüketim mantığına ilişkindir. Hangi aksiyon kaç kredi tüketir? Tüketim hangi değişkenlere göre artar veya azalır? Farklı model, özellik, entegrasyon ya da dosya türleri ayrı mı fiyatlanır? Minimum taahhüt nedir? Aşım hangi kuralla hesaplanır? Bu başlıklar olmadan kredi paketini finansal olarak karşılaştırmak mümkün değildir.

İkinci grup sorular operasyonel risk içindir. Kredi bittiğinde sistem nasıl davranır? Hizmet durur mu, uyarı verir mi, kontrollü aşım açılır mı? Eşik tanımları yapılabiliyor mu? Kullanım limiti ekip veya kullanıcı bazında konabiliyor mu? Admin onayı olmadan aşım devreye girebiliyor mu? Beklenmedik duruş ile kontrolsüz aşım farklı riskler üretir.

Üçüncü grup sorular raporlama ve denetim görünürlüğüyle ilgilidir. Günlük ve aylık kullanım dökümü veriliyor mu? Ekip, birim veya kullanıcı bazında kırılım alınabiliyor mu? API veya dışa aktarma var mı? Fatura kalemleri tüketim verisiyle mutabakat kurulacak kadar ayrıntılı mı? Satıcı yalnızca toplam bakiye gösteriyorsa iç maliyet dağıtımı zayıf kalır.

Kredi eşiği aşıldığında sorumlu kişiye görev atanması veya onay sürecinin başlatılması, kontrolsüz tüketim riskini azaltmaya yardımcı olabilir fakat bu akışın kullanılan sistem ve entegrasyonlarla gerçekten desteklendiğini doğrulayın. Bitrix24 CRM otomasyonu, belirli koşullarda görev, bildirim ve süreç adımlarını otomatikleştirmek için değerlendirilebilir.

Yazılı taahhüt isterken amaç yorum alanını daraltmaktır. İyi satın alma dosyası, belirsizliği soruya; soruyu da taahhüde dönüştürür. Satıcıdan şu maddeleri yazılı olarak netleştirmesini isteyin:

• Fiyatlama: Kredi tüketimi, ek ücretler ve aşım tarifesi.
• Rate limit: İşlem sınırları ve limit aşımında sistemin davranışı.
• Uyarılar: Gerçek zamanlı, e-posta veya webhook bildirimi; otomatik durdurma eşiği.
• Aşım kontrolü: Ek tüketim için ön onay mekanizması.
• SLA: Hizmet kullanılabilirliği, kesinti sonrası geri dönüş süresi ve telafi koşulları.
• Raporlama: Ekip veya kullanıcı bazında tüketim dökümü.
• Değişiklikler: Fiyat ve tüketim kuralları değiştiğinde bildirim süresi.

En önemlisi ise sözlü güvencelerle yetinmeyin, kritik koşulları sözleşmeye bağlayın.

SSS